From bwalton at opencsw.org Fri Jan 1 02:46:20 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 31 Dec 2009 20:46:20 -0500 Subject: [csw-maintainers] how to use the gnu linker? or is there anything else what can be done? In-Reply-To: <6af4270912310934p2a8f9bb9r104b102b49558d4a@mail.gmail.com> References: <6af4270912310856jdca43b9s5361db04adf5d72d@mail.gmail.com> <1262280366-sup-6237@ntdws12.chass.utoronto.ca> <6af4270912310934p2a8f9bb9r104b102b49558d4a@mail.gmail.com> Message-ID: <1262310175-sup-6266@ntdws12.chass.utoronto.ca> Excerpts from rupert THURNER's message of Thu Dec 31 12:34:01 -0500 2009: > i am using GARCOMPILER = GCC, is this different? No, that'll work fine, defaulting to gcc4. > i think the options are hardcoded, yes. therefor i thought gld might > fix this - and it would be easy :) Ok, if you're already using gcc, then the problem you're fighting is likely an assumption in configure that when gcc is used, the linker is gnu-ld. I'd first look to see if configure has a 'magic' option that can help. Next, I'd look at fixing the assumption in the configure script (submitting upstream if you craft something general). I've had trouble trying to override which ld gets used. If you do resort to this and make it work, I'd be interested in hearing/seeing. 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 Jan 1 14:54:03 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 1 Jan 2010 14:54:03 +0100 Subject: [csw-maintainers] clean without cleaning the downloaded file, unpackaged file ? In-Reply-To: <6af4270912311004k73ae3a67m677af8f684c931fc@mail.gmail.com> References: <6af4270912311004k73ae3a67m677af8f684c931fc@mail.gmail.com> Message-ID: <1490E460-2521-4D98-88B7-3A147A33337C@opencsw.org> Hi Rupert, Am 31.12.2009 um 19:04 schrieb rupert THURNER: > how can the build result can be cleaned without deleting the > downloaded file, This is not a problem as you should do a gmake garchive which archives the downladed sources to /home/src and grabs it from there at download time. > or maybe even avoiding unzipping it again? i try to > build qt4 as base for kde4, and the download is more than 100 mb. For this kind there is no special target. I would recommend to just gmake clean && gmake again after you tweak args. > as i got an error on build8s, i also tried to build on build10s, and i > am wondering if it is correct that it says "sparvc8": > > rupert at build10s:~/mgar/pkg/qt4/trunk > $ gmake package > gar/gar.pkg.mk:682: *** You are building this package on a > non-requested platform host 'build10s'. The follow platforms were > requested: > gar/gar.pkg.mk:682: *** - solaris8-sparc to be build on host 'build8s' Yes. Because the default build hosts for Sparc are on Solaris 8 only: If you want to build on another Solaris release you have to adjust PACKAGING_PLATFORMS. Just grep for this in the Makefiles for examples. Best regards -- Dago From rupert at opencsw.org Fri Jan 1 16:07:19 2010 From: rupert at opencsw.org (rupert THURNER) Date: Fri, 1 Jan 2010 16:07:19 +0100 Subject: [csw-maintainers] parallel build not working any more? Message-ID: <6af4271001010707k445229a7v3f83048503da36a9@mail.gmail.com> for some time setting PARALLELMFLAGS="-l -j $(psrinfo | wc -l)" enabled parallel builds. since a couple of weeks this seems not to work any more. i am trying to build qt4, and apr on build8s with either "gmake package" or "gmake platforms" and 90% of the system is idle, one thread is used. how could one enable this again ? rupert. From rupert at opencsw.org Fri Jan 1 18:58:46 2010 From: rupert at opencsw.org (rupert THURNER) Date: Fri, 1 Jan 2010 18:58:46 +0100 Subject: [csw-maintainers] pkgmk: ERROR: unable to obtain temporary file resources, errno=28 Message-ID: <6af4271001010958x2ca2c707u62a1d25b29f12604@mail.gmail.com> where does this error come from? pkgmk: ERROR: unable to obtain temporary file resources, errno=28 rupert at build8s:~/mgar/pkg/apr/trunk $ gmake repackage ==> Reset packaging state for CSWapr (rupert-build8s) [===== NOW BUILDING: apr-1.3.9 =====] [prerequisite] complete for apr. [fetch] complete for apr. [checksum] complete for apr. [checksum-global] complete for apr. [checksum-modulated] complete for apr. [===== NOW BUILDING: apr-1.3.9 MODULATION global: ISA= =====] [extract-modulated] complete for apr. [===== Building modulation 'isa-sparcv8' on host 'build8s' =====] gmake PLATFORM=solaris8-sparc MODULATION=isa-sparcv8 ISA=sparcv8 merge-modulated gmake[1]: Entering directory `/home/rupert/mgar/pkg/apr/trunk' [===== NOW BUILDING: apr-1.3.9 MODULATION isa-sparcv8: ISA=sparcv8 =====] [extract-modulated] complete for apr. [patch-modulated] complete for apr. [configure-modulated] complete for apr. [test-modulated] complete for apr. ==> fixconfig: /home/rupert/mgar/pkg/apr/trunk/work/solaris8-sparc/install-isa-sparcv8/opt/csw/lib ==> fixconfig: /home/rupert/mgar/pkg/apr/trunk/work/solaris8-sparc/install-isa-sparcv8/opt/csw/bin gmake[1]: Leaving directory `/home/rupert/mgar/pkg/apr/trunk' [===== Building modulation 'isa-sparcv9' on host 'build8s' =====] gmake PLATFORM=solaris8-sparc MODULATION=isa-sparcv9 ISA=sparcv9 merge-modulated gmake[1]: Entering directory `/home/rupert/mgar/pkg/apr/trunk' [===== NOW BUILDING: apr-1.3.9 MODULATION isa-sparcv9: ISA=sparcv9 =====] [extract-modulated] complete for apr. [patch-modulated] complete for apr. [configure-modulated] complete for apr. [test-modulated] complete for apr. ==> fixconfig: /home/rupert/mgar/pkg/apr/trunk/work/solaris8-sparc/install-isa-sparcv9/opt/csw/lib/64 ==> fixconfig: /home/rupert/mgar/pkg/apr/trunk/work/solaris8-sparc/install-isa-sparcv9/opt/csw/bin/sparcv9 gmake[1]: Leaving directory `/home/rupert/mgar/pkg/apr/trunk' [merge-license] complete for apr. [merge] complete for apr. ==> Processing CSWapr.gspec mkp: processing file://work/solaris8-sparc/build-global/CSWapr.gspec mkp: set ENV{bitname} = 'apr' mkp: set ENV{pkgname} = 'CSWapr' mkp: include file://%{PKGLIB}/csw_dyngspec.gspec mkp: replacing %{PKGLIB} with '/home/rupert/mgar/pkg/apr/trunk/gar/pkglib' mkp: include file://%{PKGLIB}/csw_vars.gspec mkp: replacing %{PKGLIB} with '/home/rupert/mgar/pkg/apr/trunk/gar/pkglib' mkp: replacing %{GARCH} with 'sparc' mkp: set ENV{arch} = 'sparc' mkp: replacing %{SPKG_DESC} with 'Apache Portable Runtime' mkp: set ENV{desc} = 'Apache Portable Runtime' mkp: replacing %{SPKG_PKGFILE} with '%{bitname}-%{SPKG_VERSION},%{SPKG_REVSTAMP}-%{SPKG_OSNAME}-%{arch}-UNCOMMITTED.pkg' mkp: replacing %{bitname} with 'apr' mkp: replacing %{SPKG_VERSION} with '1.3.9' mkp: replacing %{SPKG_REVSTAMP} with 'REV=2010.01.01' mkp: replacing %{SPKG_OSNAME} with 'SunOS5.8' mkp: replacing %{arch} with 'sparc' mkp: set ENV{pkgfile} = 'apr-1.3.9,REV=2010.01.01-SunOS5.8-sparc-UNCOMMITTED.pkg' mkp: replacing %{bitname} with 'apr' mkp: set ENV{RC_INIT_SCRIPT} = 'cswapr' mkp: replacing %{bitname} with 'apr' mkp: set ENV{SMF_SCRIPT} = 'svc-cswapr' mkp: replacing %{bitname} with 'apr' mkp: set ENV{SMF_MANIFEST} = 'cswapr.xml' mkp: include file://%{PKGLIB}/csw_prototype.gspec mkp: replacing %{PKGLIB} with '/home/rupert/mgar/pkg/apr/trunk/gar/pkglib' mkp: include file://%{PKGLIB}/std_depend.gspec mkp: replacing %{PKGLIB} with '/home/rupert/mgar/pkg/apr/trunk/gar/pkglib' mkp: Processing prototype mkp: WARNING: Using existing CSWapr.prototype-sparc mkp: Processing depend mkp: WARNING: Using existing CSWapr.depend mkp: Processing pkginfo mkp: WARNING: Using existing CSWapr.pkginfo mkp: Writing admin entries to CSWapr.prototype-sparc mkp: exec( pkgmk -d /home/rupert/spool/5.8-sparc -r /home/rupert/mgar/pkg/apr/trunk/work/solaris8-sparc/pkgroot -b /home/rupert/mgar/pkg/apr/trunk/work/solaris8-sparc/pkgroot -f /home/rupert/mgar/pkg/apr/trunk/work/solaris8-sparc/build-global/CSWapr.prototype-sparc WORKDIR_FIRSTMOD=../build-isa-sparcv8 ) ## Building pkgmap from package prototype file. pkgmk: ERROR: unable to obtain temporary file resources, errno=28 ## Packaging was not successful. mkp: ERROR: Failed to create CSWapr using /home/rupert/mgar/pkg/apr/trunk/work/solaris8-sparc/build-global/CSWapr.prototype-sparc gmake: *** [package-CSWapr] Error 2 From maciej at opencsw.org Fri Jan 1 21:33:27 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 1 Jan 2010 20:33:27 +0000 Subject: [csw-maintainers] pkgmk: ERROR: unable to obtain temporary file resources, errno=28 In-Reply-To: <6af4271001010958x2ca2c707u62a1d25b29f12604@mail.gmail.com> References: <6af4271001010958x2ca2c707u62a1d25b29f12604@mail.gmail.com> Message-ID: On Fri, Jan 1, 2010 at 5:58 PM, rupert THURNER wrote: > where does this error come from? > pkgmk: ERROR: unable to obtain temporary file resources, errno=28 Can you try trussing it? truss -o /var/tmp/mkp.truss From maciej at opencsw.org Fri Jan 1 21:33:56 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 1 Jan 2010 20:33:56 +0000 Subject: [csw-maintainers] pkgmk: ERROR: unable to obtain temporary file resources, errno=28 In-Reply-To: References: <6af4271001010958x2ca2c707u62a1d25b29f12604@mail.gmail.com> Message-ID: On Fri, Jan 1, 2010 at 8:33 PM, Maciej (Matchek) Blizinski wrote: > On Fri, Jan 1, 2010 at 5:58 PM, rupert THURNER wrote: >> where does this error come from? >> pkgmk: ERROR: unable to obtain temporary file resources, errno=28 > > Can you try trussing it? > > truss -o /var/tmp/mkp.truss I think I found the problem (that's build8s): maciej at build8s [build8s]:~ > df -k /var/tmp Filesystem kbytes used avail capacity Mounted on / 11188159 11188159 0 100% / From maciej at opencsw.org Fri Jan 1 21:38:14 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 1 Jan 2010 20:38:14 +0000 Subject: [csw-maintainers] pkgmk: ERROR: unable to obtain temporary file resources, errno=28 In-Reply-To: References: <6af4271001010958x2ca2c707u62a1d25b29f12604@mail.gmail.com> Message-ID: [+buildfarm] On Fri, Jan 1, 2010 at 8:33 PM, Maciej (Matchek) Blizinski wrote: > On Fri, Jan 1, 2010 at 8:33 PM, Maciej (Matchek) Blizinski > wrote: >> On Fri, Jan 1, 2010 at 5:58 PM, rupert THURNER wrote: >>> where does this error come from? >>> pkgmk: ERROR: unable to obtain temporary file resources, errno=28 >> >> Can you try trussing it? >> >> truss -o /var/tmp/mkp.truss > > I think I found the problem (that's build8s): > > maciej at build8s [build8s]:~ > df -k /var/tmp > Filesystem ? ? ? ? ? ?kbytes ? ?used ? avail capacity ?Mounted on > / ? ? ? ? ? ? ? ? ? ?11188159 11188159 ? ? ? 0 ? 100% ? ?/ > From dam at opencsw.org Fri Jan 1 22:34:55 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 1 Jan 2010 22:34:55 +0100 Subject: [csw-maintainers] pkgmk: ERROR: unable to obtain temporary file resources, errno=28 In-Reply-To: References: <6af4271001010958x2ca2c707u62a1d25b29f12604@mail.gmail.com> Message-ID: Hi, Am 01.01.2010 um 21:38 schrieb Maciej (Matchek) Blizinski: > [+buildfarm] > > On Fri, Jan 1, 2010 at 8:33 PM, Maciej (Matchek) Blizinski > wrote: >> On Fri, Jan 1, 2010 at 8:33 PM, Maciej (Matchek) Blizinski >> wrote: >>> On Fri, Jan 1, 2010 at 5:58 PM, rupert THURNER >>> wrote: >>>> where does this error come from? >>>> pkgmk: ERROR: unable to obtain temporary file resources, errno=28 >>> >>> Can you try trussing it? >>> >>> truss -o /var/tmp/mkp.truss >> >> I think I found the problem (that's build8s): >> >> maciej at build8s [build8s]:~ > df -k /var/tmp >> Filesystem kbytes used avail capacity Mounted on >> / 11188159 11188159 0 100% / Fixed. I guess I will set quota on Hudson now :-( Best regards -- Dago From dam at opencsw.org Fri Jan 1 22:38:59 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 1 Jan 2010 22:38:59 +0100 Subject: [csw-maintainers] parallel build not working any more? In-Reply-To: <6af4271001010707k445229a7v3f83048503da36a9@mail.gmail.com> References: <6af4271001010707k445229a7v3f83048503da36a9@mail.gmail.com> Message-ID: Hi Rupert, Am 01.01.2010 um 16:07 schrieb rupert THURNER: > for some time setting > PARALLELMFLAGS="-l -j $(psrinfo | wc -l)" > enabled parallel builds. > > since a couple of weeks this seems not to work any more. i am trying > to build qt4, and apr on build8s with either "gmake package" or "gmake > platforms" and 90% of the system is idle, one thread is used. how > could one enable this again ? This currently does not work as PARALLELMFLAGS is not propagated with platforms. Meanwhile you can set this in your .garrc which should then work an on all your recipes or temporarily in the Makefile you are working on. I opened a bug for this: Best regards -- Dago From maciej at opencsw.org Sat Jan 2 12:10:00 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 2 Jan 2010 11:10:00 +0000 Subject: [csw-maintainers] Our mailing list footer Message-ID: Our mailing list footer has been recently changed and now looks like this: _______________________________________________ maintainers mailing list maintainers at lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers This mailing lists archive is PUBLIC. Two issues: 1. There's an apostrophe missing in one of the words. 2. Somebody's capslock must've been jammed. Please fix. From rupert at opencsw.org Sat Jan 2 12:18:24 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 2 Jan 2010 12:18:24 +0100 Subject: [csw-maintainers] what is different on buildfarm? mercurial tests take long - or fail Message-ID: <6af4271001020318k5f9fe830gd5378c9bf96e267b@mail.gmail.com> while testing mercurial-1.4.2 i noticed that the tests take long - or forever on build8s. and they fail with network errors on build10s. as i did not have time to wait if they end at 8s, i breaked them and i tried 1.4.1 as well, which also did not complete in a reasonable time. so i wonder what might cause this. the new python? the new ipv6? something else? here the output of a "ps" while waiting for something to happen: rupert at build8s:~/tmp $ /usr/ucb/ps aguxwwwww | grep test rupert 7748 0.0 0.016920 2096 ? S 02:50:25 0:00 /opt/csw/bin/python /tmp/hgtests.8Qqkub/install/bin/hg serve -p 20137 -d --pid-file=hg.pid -E errors.log --daemon-pipefds=3,4 rupert 9810 0.0 0.0 2168 1536 pts/35 S 04:23:46 0:00 grep test rupert 12261 0.0 0.0 2232 1704 pts/60 S 04:11:39 0:00 /bin/sh /home/rupert/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build-isa-sparcv8/mercurial-1.4.1/tests/test-push-http rupert 12341 0.0 0.116920 6064 ? S 04:11:48 0:00 /opt/csw/bin/python /tmp/hgtests.ZTfh5M/install/bin/hg serve -p 20092 -d --pid-file=hg.pid -E errors.log --daemon-pipefds=3,4 rupert 12356 0.0 0.111784 8416 pts/60 S 04:11:49 0:00 /opt/csw/bin/python /tmp/hgtests.ZTfh5M/install/bin/hg --cwd ../test2 push http://localhost:20092/ rupert 15345 0.0 0.116920 2464 ? S 03:37:32 0:00 /opt/csw/bin/python /tmp/hgtests.vKPSKj/install/bin/hg serve -p 20095 -d --pid-file=hg.pid -E errors.log --daemon-pipefds=3,4 rupert 17196 0.0 0.1 9208 5376 pts/60 S 04:04:44 0:01 python run-tests.py -j30 rupert 18094 0.0 0.110232 6008 pts/60 S 04:04:56 0:01 /opt/csw/bin/python run-tests.py --jobs=1 --port=20059 --with-hg=/tmp/hgtests.ZTfh5M/install/bin/hg --timeout=180 --child=15 --port=20092 --tmpdir /tmp/hgtests.ZTfh5M/child11 test-audit-path test-command-template test-convert-hg-startrev test-diff-newlines test-git-export test-http-clone-r test-issue619 test-merge5 test-mv-cp-st-diff test-push-http test-resolve test-trusted.py rupert 18123 0.0 0.110232 5312 pts/60 S 04:04:57 0:01 /opt/csw/bin/python run-tests.py --jobs=1 --port=20059 --with-hg=/tmp/hgtests.ZTfh5M/install/bin/hg --timeout=180 --child=30 --port=20137 --tmpdir /tmp/hgtests.ZTfh5M/child26 test-branchmap test-convert-bzr-ghosts test-copy test-empty-file test-hgweb-auth.py test-inotify-issue1371 test-merge-force test-mq-qclone-http test-patch test-rebase-parameters test-static-http rupert 23378 0.0 0.0 2232 1128 pts/60 S 04:06:03 0:00 /bin/sh /home/rupert/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build-isa-sparcv8/mercurial-1.4.1/tests/test-mq-qclone-http rupert 24084 0.0 0.1 9360 4992 pts/60 S 04:06:13 0:00 python /home/rupert/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build-isa-sparcv8/mercurial-1.4.1/tests/get-with-headers.py localhost:20137 /?style=raw on build10s, using the tip of the crew repository, i get "network is not reachable" errors: rupert at build10s:~/hg-crew-10s $ python setup.py build ... rupert at build10s:~/hg-crew-10s/tests $ python run-tests.py -j 30 .. ERROR: /home/rupert/hg-crew-10s/tests/test-bad-pull output changed and returned error code 1 --- /home/rupert/hg-crew-10s/tests/test-bad-pull.out +++ /home/rupert/hg-crew-10s/tests/test-bad-pull.err @@ -1,5 +1,6 @@ -abort: error: Connection refused +abort: error: Network is unreachable 255 copy: No such file or directory -abort: HTTP Error 404 +abort: error: Network is unreachable 0 +/home/rupert/hg-crew-10s/tests/test-bad-pull: kill: no such process !... ERROR: /home/rupert/hg-crew-10s/tests/test-branchmap output changed and returned error code 1 ERROR: /home/rupert/hg-crew-10s/tests/test-webraw output changed --- /home/rupert/hg-crew-10s/tests/test-webraw.out +++ /home/rupert/hg-crew-10s/tests/test-webraw.err @@ -1,10 +1,18 @@ -200 Script output follows -content-type: text/plain -content-length: 157 -content-disposition: inline; filename="some \"text\".txt" - -This is just some random text -that will go inside the file and take a few lines. -It is very boring to read, but computers don't -care about things like that. -host - - [date] "GET /?f=a23bf1310f6e;file=sub/some%20%22text%22.txt;style=raw HTTP/1.1" 200 - +Traceback (most recent call last): + File "/home/rupert/hg-crew-10s/tests/get-with-headers.py", line 17, in + conn.request("GET", sys.argv[2]) + File "/opt/csw/lib/python/httplib.py", line 898, in request + self._send_request(method, url, body, headers) + File "/opt/csw/lib/python/httplib.py", line 935, in _send_request + self.endheaders() + File "/opt/csw/lib/python/httplib.py", line 892, in endheaders + self._send_output() + File "/opt/csw/lib/python/httplib.py", line 764, in _send_output + self.send(msg) + File "/opt/csw/lib/python/httplib.py", line 723, in send + self.connect() + File "/opt/csw/lib/python/httplib.py", line 704, in connect + self.timeout) + File "/opt/csw/lib/python/socket.py", line 514, in create_connection + raise error, msg +socket.error: [Errno 128] Network is unreachable rupert. From maciej at opencsw.org Sat Jan 2 12:28:31 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 2 Jan 2010 11:28:31 +0000 Subject: [csw-maintainers] Readline in sqlite3, changes to other people's packages Message-ID: I noticed that the readline frontend (the "sqlite3" command) doesn't have readline, so I recompiled it with readline support. http://sourceforge.net/apps/trac/gar/changeset/7799 I want readline because it's useful when working with the "sqlite3" utility to examine database contents. I've put it into testing. Ruper later bumped up the version to .21, so I've rebuilt sqlite3 again. I was thinking about a more general case. Let's say there's a package that I'm willing to put some work into, such as this one. It's much quicker to just fix the issue myself than ti file a bug and wait for the maintainer to respond. However, when I submit the package for release, I become the maintainer instead. Can we have a process in which: - I can introduce a change to a package and rebuild it - the package maintainer (here: Dago) approves the change - I submit it for release - I don't become the maintainer. Maciej From maciej at opencsw.org Sat Jan 2 12:40:41 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 2 Jan 2010 11:40:41 +0000 Subject: [csw-maintainers] Better shared object dependency checking in checkpkg out for testing In-Reply-To: References: Message-ID: On Tue, Dec 29, 2009 at 11:58 PM, Maciej (Matchek) Blizinski wrote: > I have one more bit to implement: checking the data modification > timestamp of /var/sadm/install/contents and updating the cache. This is done. I've implemented all the features I wanted, I would like to focus on merging my change to the main v2 branch. Here's the list of changes: http://sourceforge.net/apps/trac/gar/log/csw/mgar/gar/v2-checkpkg I haven't received any comments about the new code, which makes me think that people haven't tried it yet. My question to Dago: What would you like to be done with relation to merging back to v2? From ihsan at opencsw.org Sun Jan 3 21:34:14 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 03 Jan 2010 21:34:14 +0100 Subject: [csw-maintainers] Our mailing list footer In-Reply-To: References: Message-ID: <4B40FF46.5070400@opencsw.org> Am 02.01.10 12:10, schrieb Maciej (Matchek) Blizinski: > Our mailing list footer has been recently changed and now looks like this: [...] > Two issues: > 1. There's an apostrophe missing in one of the words. > 2. Somebody's capslock must've been jammed. Please fix. This is fixed now. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Mon Jan 4 10:33:53 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 4 Jan 2010 10:33:53 +0100 Subject: [csw-maintainers] [csw-buildfarm] what is different on buildfarm? mercurial tests take long - or fail In-Reply-To: <6af4271001020318k5f9fe830gd5378c9bf96e267b@mail.gmail.com> References: <6af4271001020318k5f9fe830gd5378c9bf96e267b@mail.gmail.com> Message-ID: <841FE230-13C7-4CEC-9202-B01167FE8730@opencsw.org> Hi Rupert, Am 02.01.2010 um 12:18 schrieb rupert THURNER: > while testing mercurial-1.4.2 i noticed that the tests take long - or > forever on build8s. and they fail with network errors on build10s. > > as i did not have time to wait if they end at 8s, i breaked them and i > tried 1.4.1 as well, which also did not complete in a reasonable time. > > so i wonder what might cause this. the new python? the new ipv6? > something else? You may want to try test8s which doesn't have the novelties above. If you want to have net access from the build machines you have to use a proxy. Best regards -- Dago From dam at opencsw.org Mon Jan 4 10:36:09 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 4 Jan 2010 10:36:09 +0100 Subject: [csw-maintainers] Readline in sqlite3, changes to other people's packages In-Reply-To: References: Message-ID: <2C53ED9C-D99A-4B88-9C7F-4849E55EB024@opencsw.org> Hi Maciej, Am 02.01.2010 um 12:28 schrieb Maciej (Matchek) Blizinski: > I noticed that the readline frontend (the "sqlite3" command) doesn't > have readline, so I recompiled it with readline support. > > http://sourceforge.net/apps/trac/gar/changeset/7799 > > I want readline because it's useful when working with the "sqlite3" > utility to examine database contents. > > I've put it into testing. Ruper later bumped up the version to .21, > so I've rebuilt sqlite3 again. Excellent example as sqlite3 is already team-maintained: > I was thinking about a more general case. Let's say there's a package > that I'm willing to put some work into, such as this one. It's much > quicker to just fix the issue myself than ti file a bug and wait for > the maintainer to respond. However, when I submit the package for > release, I become the maintainer instead. Can we have a process in > which: > > - I can introduce a change to a package and rebuild it > - the package maintainer (here: Dago) approves the change > - I submit it for release > - I don't become the maintainer. Phil? Even a change of the maintainer would be ok for me. We could just add you to the team. Best regards -- Dago From dam at opencsw.org Mon Jan 4 10:50:45 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 4 Jan 2010 10:50:45 +0100 Subject: [csw-maintainers] Better shared object dependency checking in checkpkg out for testing In-Reply-To: References: Message-ID: Hi Maciej, Am 02.01.2010 um 12:40 schrieb Maciej (Matchek) Blizinski: > On Tue, Dec 29, 2009 at 11:58 PM, Maciej (Matchek) Blizinski > wrote: >> I have one more bit to implement: checking the data modification >> timestamp of /var/sadm/install/contents and updating the cache. > > This is done. If you fiddle with the contents make sure you check for pkgserv and issue "pkgadm sync" if necessary. > I've implemented all the features I wanted, I would like > to focus on merging my change to the main v2 branch. Here's the list > of changes: > > http://sourceforge.net/apps/trac/gar/log/csw/mgar/gar/v2-checkpkg > > I haven't received any comments about the new code, which makes me > think that people haven't tried it yet. > > My question to Dago: What would you like to be done with relation to > merging back to v2? Please merge it back. It looks good enough to be tried and we can fix problems on-the-fly as the result doesn't affect package contents. Best regards -- Dago From maciej at opencsw.org Mon Jan 4 14:14:07 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 4 Jan 2010 13:14:07 +0000 Subject: [csw-maintainers] Better shared object dependency checking in checkpkg out for testing In-Reply-To: References: Message-ID: On Mon, Jan 4, 2010 at 9:50 AM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 02.01.2010 um 12:40 schrieb Maciej (Matchek) Blizinski: >> >> On Tue, Dec 29, 2009 at 11:58 PM, Maciej (Matchek) Blizinski >> wrote: >>> >>> I have one more bit to implement: checking the data modification >>> timestamp of /var/sadm/install/contents and updating the cache. >> >> This is done. > > If you fiddle with the contents make sure you check for pkgserv and > issue "pkgadm sync" if necessary. There's no fiddling in the sense of modifying the file. There's a cache of this file being built, and every time the file changes, there's a need to update the cache. >> I've implemented all the features I wanted, I would like >> to focus on merging my change to the main v2 branch. ?Here's the list >> of changes: >> >> http://sourceforge.net/apps/trac/gar/log/csw/mgar/gar/v2-checkpkg >> >> I haven't received any comments about the new code, which makes me >> think that people haven't tried it yet. >> >> My question to Dago: What would you like to be done with relation to >> merging back to v2? > > Please merge it back. It looks good enough to be tried and we can > fix problems on-the-fly as the result doesn't affect package contents. Cool. I've merged the branch into v2. I'll keep the v2-checkpkg branch around in case I want to make additional changes. I'm thinking of doing the following things: - porting individual checks from the monolithic part to plugins, probably taking code from Ben's git repository - implementing overrides - adding logs which can be inspected after checkpkg has finished Maciej From maciej at opencsw.org Mon Jan 4 16:43:35 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 4 Jan 2010 15:43:35 +0000 Subject: [csw-maintainers] GAR: Changes to checkpkg: shared libraries and modularity Message-ID: If you don't use GAR, you can stop reading now. The v2-checkpkg branch has been merged to v2 today. It means that the new shared library checking code is now live. The next time you update your GAR sources, the new code will be pulled in. The new code doesn't affect the way the packages are made, it only affects the way the new packages are being checked. There are two main differences: 1. There is new library checking code. It's emulating the way the shared libraries are searched on the filesystem. The first time you run it on each machine, it builds a cache of /var/sadm/install/contents, so please be patient and give it up to two minutes to complete. Subsequent runs will be fast, and in fact, faster than the previous code, because it doesn't read the contents file each time. One of the main differences in output is that the new check displays dependencies it thinks are unnecessary. I found it a useful feature. For instance, I found out that syslog-ng was reported to have an unnecessary dependency on CSWtcpwrap. Upon close examination, it turned out that syslog-ng was supposed to have tcp wrapper support, but it was just not compiled in. If checkpkg hasn't tipped me off, I wouldn't have known or fixed this issue. I'm sure other people will be able to catch some problems by looking at this part of checkpkg's output. The new code outputs also information about dependencies between binary files: which files uses which shared library, and which package provides the library in question. I suspect that the new code might be slightly more picky and may produce more false positives than the previous one. If you run into a false-positive, or any kind of problem with library-related checks, please drop me a line. I've got small debugging infrastructure integrated into the new checkpkg files. 2. Modular checks have been introduced. The gar/bin/checkpkg.d directory contains now separate checks. The checks are executable files, which can be written in any language. Communication is over command line flags and system exit codes. Output from each check is collected and displayed at the end of the run of checkpkg. It won't stop on the first failure; all errors will be collected and displayed at the end. The intention of the modular checks is that people can introduce their own checks without having the problem of unexpected interactions with other checks or global variables. This should make it easier to collaborate: each person can program in their own favorite language, and it's easy to develop new tests. Each test evaluates a set of packages, not just an individual package. It makes checks slightly more complex, because they have to loop over the list of packages to check. However, the set tests are necessary anyway, and I think it's a better approach to have only one type of test rather than two. If people think that individual tests are also useful, let's discuss it. I haven't integrated any of Ben's code yet, but I've looked at it and borrowed some ideas. I would like to start incorporating his cswpkgtest code. I think that some tweaks to lib/pkg_testfuncs.sh should make his existing tests compatible with checkpkg.d. If you have any questions, I'll be happy to answer them. Maciej From bonivart at opencsw.org Mon Jan 4 16:55:23 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 4 Jan 2010 16:55:23 +0100 Subject: [csw-maintainers] GAR: Changes to checkpkg: shared libraries and modularity In-Reply-To: References: Message-ID: <625385e31001040755y4d0e602ayfe4ea510aa315ef@mail.gmail.com> On Mon, Jan 4, 2010 at 4:43 PM, Maciej (Matchek) Blizinski wrote: > The v2-checkpkg branch has been merged to v2 today. Great work! -- /peter From phil at bolthole.com Mon Jan 4 18:45:52 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 4 Jan 2010 09:45:52 -0800 Subject: [csw-maintainers] Better shared object dependency checking in checkpkg out for testing In-Reply-To: References: Message-ID: On Tue, Dec 29, 2009 at 3:58 PM, Maciej (Matchek) Blizinski wrote: >... ?I've created a v2-checkpkg branch in gar and >>> re-implemented the part of checkpkg which analyzes shared library >>> dependencies. ?My implementation takes into account the RPATH set in >>> the analyzed shared libraries, which allows it to correctly identify >>> GCC runtime dependencies. >>>...(n more!) >> > > The main worry I have about the code is that has grew in line count > beyond what I initially anticipated, heheheh.. I am not surprised.. I knew it would be long and ugly, which is why I put off attempting to write a better one for so long ;-) > and I doubt that it's easy to > understand at the first glance. ?There is a number of unit tests, > which should make code refactoring easier. Given the complexity, yet utility of this code... you might consider making it a completely standalone util. I know you mentioned "modules" down the road, but this particular bit is possibly more useful to a wider audience, so it could be beneficial that way. call it "checkpkgdeps", perhaps ? From phil at bolthole.com Mon Jan 4 18:56:24 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 4 Jan 2010 09:56:24 -0800 Subject: [csw-maintainers] Readline in sqlite3, changes to other people's packages In-Reply-To: References: Message-ID: On Sat, Jan 2, 2010 at 3:28 AM, Maciej (Matchek) Blizinski wrote: > I was thinking about a more general case. ?Let's say there's a package > that I'm willing to put some work into, such as this one. ?It's much > quicker to just fix the issue myself than ti file a bug and wait for > the maintainer to respond. ?However, when I submit the package for > release, I become the maintainer instead. ?Can we have a process in > which: > > - I can introduce a change to a package and rebuild it > - the package maintainer (here: Dago) approves the change > - I submit it for release > - I don't become the maintainer. > In my opinion, the right thing to do, would be for "the maintainer" to rebuild the package with your changes. Contrariwise, even if you dont wish to be the maintainer... If you are willing to do the work to repackage the thin to fix a bug, and [the current maintainer] is not.. you are de facto a better "maintainer" than the current one, and the best thing to do is for you to become the maintainer. Or learn patience, if the maintainer says they can get to it in a few days ;-) From maciej at opencsw.org Mon Jan 4 19:59:07 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 4 Jan 2010 18:59:07 +0000 Subject: [csw-maintainers] Better shared object dependency checking in checkpkg out for testing In-Reply-To: References: Message-ID: On Mon, Jan 4, 2010 at 5:45 PM, Philip Brown wrote: > I know you mentioned "modules" down the road, but this particular bit > is possibly more useful to a wider audience, so it could be beneficial > that way. > > call it "checkpkgdeps", perhaps ? It certainly could be used standalone. However, its primary use is to be part of a larger test suite - a modular checkpkg. It doesn't do certain things, for example it doesn't extract the package the way checkpkg does. To be standalone and useful, it would need be armored with the unpacking code. The unpacking code is already there in checkpkg, perhaps we can reuse it? From phil at bolthole.com Mon Jan 4 20:25:42 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 4 Jan 2010 11:25:42 -0800 Subject: [csw-maintainers] Better shared object dependency checking in checkpkg out for testing In-Reply-To: References: Message-ID: On Mon, Jan 4, 2010 at 10:59 AM, Maciej (Matchek) Blizinski wrote: > On Mon, Jan 4, 2010 at 5:45 PM, Philip Brown wrote: >> I know you mentioned "modules" down the road, but this particular bit >> is possibly more useful to a wider audience, so it could be beneficial >> that way. >> >> call it "checkpkgdeps", perhaps ? > > It certainly could be used standalone. ?However, its primary use is to > be part of a larger test suite - ?a modular checkpkg. ?It doesn't do > certain things, for example it doesn't extract the package the way > checkpkg does. ?To be standalone and useful, it would need be armored > with the unpacking code. ?The unpacking code is already there in > checkpkg, perhaps we can reuse it? If you like. Or you could use the system pkgtrans on a pkg file, but fail if gzipped. Or you could make it a little plainer and just expect a directory, and let the caller deal with providing the package in directory format. From rupert at opencsw.org Mon Jan 4 20:48:07 2010 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 4 Jan 2010 20:48:07 +0100 Subject: [csw-maintainers] [csw-buildfarm] what is different on buildfarm? mercurial tests take long - or fail In-Reply-To: <841FE230-13C7-4CEC-9202-B01167FE8730@opencsw.org> References: <6af4271001020318k5f9fe830gd5378c9bf96e267b@mail.gmail.com> <841FE230-13C7-4CEC-9202-B01167FE8730@opencsw.org> Message-ID: <6af4271001041148x907e364ha7d09da31400df6b@mail.gmail.com> On Mon, Jan 4, 2010 at 10:33, Dagobert Michelsen wrote: > Hi Rupert, > > Am 02.01.2010 um 12:18 schrieb rupert THURNER: >> >> while testing mercurial-1.4.2 i noticed that the tests take long - or >> forever on build8s. and they fail with network errors on build10s. >> >> as i did not have time to wait if they end at 8s, i breaked them and i >> tried 1.4.1 as well, which also did not complete in a reasonable time. >> >> so i wonder what might cause this. the new python? the new ipv6? something >> else? > > You may want to try test8s which doesn't have the novelties above. > If you want to have net access from the build machines you have to > use a proxy. huhm .... the results are differing with the version built on build8s: 1. test8s, see below and http://mercurial.pastebin.com/m41cc23ac 2. build8s, see http://mercurial.pastebin.com/m6ed3c83a, just times ot / stops should we try to change one parameter by one, and rerun the tests? rupert at login:~ $ ssh test8s ... rupert at build8st:~/hg-crew-8s/tests $ python run-tests.py -j 30 ... Skipped test-convert-p4: missing feature: Perforce server and client Skipped test-convert-bzr-ghosts: missing feature: Canonical's Bazaar client Skipped test-inotify-issue1208: missing feature: inotify extension support Skipped test-highlight: missing feature: Pygments source highlighting library Skipped test-casefolding: missing feature: case insensitive file system Skipped test-convert-bzr-merges: missing feature: Canonical's Bazaar client Skipped test-inotify-issue1371: missing feature: inotify extension support Skipped test-convert-bzr-directories: missing feature: Canonical's Bazaar client Skipped test-convert-tla: missing feature: GNU Arch tla client Skipped test-inotify-dirty-dirstate: missing feature: inotify extension support Skipped test-convert-bzr-114: missing feature: Canonical's Bazaar client >= 1.14 Skipped test-inotify-debuginotify: missing feature: inotify extension support Skipped test-convert-svn-branches: missing feature: subversion python bindings Skipped test-convert-svn-move: missing feature: subversion python bindings Skipped test-convert-bzr: missing feature: Canonical's Bazaar client Skipped test-convert-svn-tags: missing feature: subversion python bindings Skipped test-inotify: missing feature: inotify extension support Skipped test-convert-baz: missing feature: GNU Arch baz client Skipped test-convert-svn-startrev: missing feature: subversion python bindings Skipped test-convert-svn-source: missing feature: subversion python bindings Skipped test-convert-bzr-treeroot: missing feature: Canonical's Bazaar client Skipped test-inotify-issue1542: missing feature: inotify extension support Skipped test-convert-svn-sink: missing feature: subversion python bindings Skipped test-inotify-lookup: missing feature: inotify extension support Skipped test-convert-darcs: missing feature: darcs client Skipped test-convert-p4-filetypes: missing feature: Perforce server and client Skipped test-convert-hg-svn: missing feature: subversion python bindings Skipped test-convert-mtn: missing feature: monotone client (> 0.31) Skipped test-inotify-issue1556: missing feature: inotify extension support Skipped test-gendoc: missing feature: Docutils rst2html tool Skipped test-convert-svn-encoding: missing feature: subversion python bindings Skipped test-no-symlinks: system supports symbolic links Failed test-convert-cvs: output changed Failed test-subrepo-svn: output changed and returned error code 2 Failed test-patch-offset: output changed and returned error code 2 # Ran 361 tests, 32 skipped, 3 failed. From hson at opencsw.org Mon Jan 4 22:25:55 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Mon, 04 Jan 2010 22:25:55 +0100 Subject: [csw-maintainers] Upstream check for sourceforge not working? Message-ID: <4B425CE3.8050201@opencsw.org> Anyone else noticed that there is something wrong with the upstream check for sourceforge packages? I haven't gotten any mail regarding updated sourceforge packages in a while now and when I runt "gmake check-upstream" manually I don't get any output at all. From william at wbonnet.net Mon Jan 4 22:36:05 2010 From: william at wbonnet.net (William Bonnet) Date: Mon, 04 Jan 2010 22:36:05 +0100 Subject: [csw-maintainers] Upstream check for sourceforge not working? In-Reply-To: <4B425CE3.8050201@opencsw.org> References: <4B425CE3.8050201@opencsw.org> Message-ID: <4B425F45.7050400@wbonnet.net> Hi Roger Could you please tell me which packages have problems ? > Anyone else noticed that there is something wrong with the upstream > check for sourceforge packages? There are a some packages which have a problem with the upstream check. There are at least two known bugs. . If catalog name is different from garname, then the maintainer will not always be reported accurately. . Some url are just not working... I'm still working on a new version. Maybe for early february. > I haven't gotten any mail regarding updated sourceforge packages in a > while now and when I runt "gmake check-upstream" manually I don't get > any output at all. This can be normal... once you have run check-upstream, a timestamp is created. If you run gmake check-upstream again, it will not report anything if the version has not changed. You should do a gmake clean before running it again. 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 hson at opencsw.org Mon Jan 4 23:22:48 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Mon, 04 Jan 2010 23:22:48 +0100 Subject: [csw-maintainers] Upstream check for sourceforge not working? In-Reply-To: <4B425F45.7050400@wbonnet.net> References: <4B425CE3.8050201@opencsw.org> <4B425F45.7050400@wbonnet.net> Message-ID: <4B426A38.3030504@opencsw.org> William Bonnet wrote: > Hi Roger > > Could you please tell me which packages have problems ? > >> Anyone else noticed that there is something wrong with the upstream >> check for sourceforge packages? > There are a some packages which have a problem with the upstream check. > There are at least two known bugs. > > . If catalog name is different from garname, then the maintainer will > not always be reported accurately. > > . Some url are just not working... > > I'm still working on a new version. Maybe for early february. >> I haven't gotten any mail regarding updated sourceforge packages in a >> while now and when I runt "gmake check-upstream" manually I don't get >> any output at all. > This can be normal... once you have run check-upstream, a timestamp is > created. If you run gmake check-upstream again, it will not report > anything if the version has not changed. You should do a gmake clean > before running it again. Well, lets take an example, lcms. In the Makefile, i have: GARNAME = lcms GARVERSION = 1.18 UPSTREAM_MASTER_SITES = $(SF_PROJECT_SHOWFILE)=26279 UPSTREAM_USE_SF = 1 UFILES_REGEX = (\d+(?:\.\d+)*) Taking a look at http://sourceforge.net/projects/lcms/files/ (where http://sourceforge.net/project/showfiles.php?group_id=26289 is redirected) the latest release is 1.19 I've checked upstream_watch and from what I can tell, it's supposed to get some output from "$wget_command -qO- $url 2>/dev/null | grep class | grep selected | grep li | grep Download | " However the output from sourceforge must have changed because running that command gives no output at all and running the wget manually and checking the output tells me that upstream_watch cannot work with their current design. From rupert at opencsw.org Mon Jan 4 23:53:47 2010 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 4 Jan 2010 23:53:47 +0100 Subject: [csw-maintainers] [csw-buildfarm] what is different on buildfarm? mercurial tests take long - or fail In-Reply-To: <0DEA3BF3-1EC8-42F7-A160-1CC681304F3F@opencsw.org> References: <6af4271001020318k5f9fe830gd5378c9bf96e267b@mail.gmail.com> <841FE230-13C7-4CEC-9202-B01167FE8730@opencsw.org> <6af4271001041148x907e364ha7d09da31400df6b@mail.gmail.com> <0DEA3BF3-1EC8-42F7-A160-1CC681304F3F@opencsw.org> Message-ID: <6af4271001041453o5324cc98t19981f6f67762853@mail.gmail.com> On Mon, Jan 4, 2010 at 21:38, Dagobert Michelsen wrote: > Hi Rupert, > > Am 04.01.2010 um 20:48 schrieb rupert THURNER: >> >> huhm .... the results are differing with the version built on build8s: >> 1. test8s, see below and http://mercurial.pastebin.com/m41cc23ac >> 2. build8s, see http://mercurial.pastebin.com/m6ed3c83a, just times ot / >> stops >> >> should we try to change one parameter by one, and rerun the tests? > > You can do > ?ssh root at test8s > now. You should be using the machine alone at the moment. Please don't FUBR > it. did: pkgrm CSWpython pkgutil -U -i python did not upgrade the dependent upgrades pkgutil suggested: CSWreadline-6.1,REV=2010.01.01 CSWsqlite3rt-3.6.21,REV=2010.01.04 CSWosslrt-0.9.8l,REV=2009.12.08 and you were right, the hg tests just stops. but i am completely lost why this would happen. it seems to be (at least) the push-http test: rupert at build8st:~/hg-crew-8s/tests $ python run-tests.py test-push-http rupert at build8st:~ $ /usr/ucb/ps aguxwwwww | grep rupert rupert 22253 0.1 0.111784 8496 pts/76 S 15:39:36 0:00 /opt/csw/bin/python /tmp/hgtests.iyfh65/install/bin/hg --cwd ../test2 push http://localhost:20059/ rupert 22165 0.0 0.110232 6952 pts/76 S 15:39:11 0:00 python run-tests.py test-push-http rupert 22210 0.0 0.0 2232 1656 pts/76 S 15:39:26 0:00 /bin/sh /home/rupert/hg-crew-8s/tests/test-push-http rupert 22254 0.0 0.0 5432 1624 pts/73 O 15:39:43 0:00 /usr/ucb/ps -aguxwwwww rupert 3135 0.0 0.116920 2904 ? S 15:02:26 0:00 /opt/csw/bin/python /tmp/hgtests.DAKOec/install/bin/hg serve -p 20101 -d --pid-file=hg.pid -E errors.log --daemon-pipefds=3,4 rupert 21190 0.0 0.112624 3176 ? S 15:33:05 0:00 /opt/csw/sbin/sshd -R rupert 21192 0.0 0.1 3768 2840 pts/73 S 15:33:05 0:00 -bash rupert 22209 0.0 0.0 2232 1656 pts/76 S 15:39:26 0:00 /bin/sh -c "/home/rupert/hg-crew-8s/tests/test-push-http" rupert 22244 0.0 0.116920 6272 ? S 15:39:35 0:00 /opt/csw/bin/python /tmp/hgtests.iyfh65/install/bin/hg serve -p 20059 -d --pid-file=hg.pid -E errors.log --daemon-pipefds=3,4 rupert 22252 0.0 0.0 2240 1608 pts/76 S 15:39:36 0:00 sed -e s,:[0-9][0-9]*/,/, rupert 22255 0.0 0.0 2168 1456 pts/73 S 15:39:43 0:00 grep rupert rupert 23303 0.0 0.012624 1632 ? S 14:59:42 0:00 /opt/csw/sbin/sshd -R rupert 23305 0.0 0.0 3832 1952 pts/76 S 14:59:43 0:00 -bash then i upgraded the dependencies too. but no change in the output. rupert. From rupert at opencsw.org Mon Jan 4 23:57:47 2010 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 4 Jan 2010 23:57:47 +0100 Subject: [csw-maintainers] [csw-buildfarm] what is different on buildfarm? mercurial tests take long - or fail In-Reply-To: <0DEA3BF3-1EC8-42F7-A160-1CC681304F3F@opencsw.org> References: <6af4271001020318k5f9fe830gd5378c9bf96e267b@mail.gmail.com> <841FE230-13C7-4CEC-9202-B01167FE8730@opencsw.org> <6af4271001041148x907e364ha7d09da31400df6b@mail.gmail.com> <0DEA3BF3-1EC8-42F7-A160-1CC681304F3F@opencsw.org> Message-ID: <6af4271001041457h4535abdar558fdb87b70cf151@mail.gmail.com> On Mon, Jan 4, 2010 at 21:38, Dagobert Michelsen wrote: > Hi Rupert, > > Am 04.01.2010 um 20:48 schrieb rupert THURNER: >> >> huhm .... the results are differing with the version built on build8s: >> 1. test8s, see below and http://mercurial.pastebin.com/m41cc23ac >> 2. build8s, see http://mercurial.pastebin.com/m6ed3c83a, just times ot / >> stops >> >> should we try to change one parameter by one, and rerun the tests? > > You can do > ?ssh root at test8s > now. You should be using the machine alone at the moment. Please don't FUBR > it. > did: pkgrm CSWpython pkgutil -U -i python did not upgrade the related upgrades pkgutil suggested: CSWreadline-6.1,REV=2010.01.01 CSWsqlite3rt-3.6.21,REV=2010.01.04 CSWosslrt-0.9.8l,REV=2009.12.08 and you were right, the hg tests just stops. but i am completely lost why this would happen. it seems to be (at least) the push-http test: rupert at build8st:~/hg-crew-8s/tests $ python run-tests.py test-push-http rupert at build8st:~ $ /usr/ucb/ps aguxwwwww | grep rupert rupert 22253 0.1 0.111784 8496 pts/76 S 15:39:36 0:00 /opt/csw/bin/python /tmp/hgtests.iyfh65/install/bin/hg --cwd ../test2 push http://localhost:20059/ rupert 22165 0.0 0.110232 6952 pts/76 S 15:39:11 0:00 python run-tests.py test-push-http rupert 22210 0.0 0.0 2232 1656 pts/76 S 15:39:26 0:00 /bin/sh /home/rupert/hg-crew-8s/tests/test-push-http rupert 22254 0.0 0.0 5432 1624 pts/73 O 15:39:43 0:00 /usr/ucb/ps -aguxwwwww rupert 3135 0.0 0.116920 2904 ? S 15:02:26 0:00 /opt/csw/bin/python /tmp/hgtests.DAKOec/install/bin/hg serve -p 20101 -d --pid-file=hg.pid -E errors.log --daemon-pipefds=3,4 rupert 21190 0.0 0.112624 3176 ? S 15:33:05 0:00 /opt/csw/sbin/sshd -R rupert 21192 0.0 0.1 3768 2840 pts/73 S 15:33:05 0:00 -bash rupert 22209 0.0 0.0 2232 1656 pts/76 S 15:39:26 0:00 /bin/sh -c "/home/rupert/hg-crew-8s/tests/test-push-http" rupert 22244 0.0 0.116920 6272 ? S 15:39:35 0:00 /opt/csw/bin/python /tmp/hgtests.iyfh65/install/bin/hg serve -p 20059 -d --pid-file=hg.pid -E errors.log --daemon-pipefds=3,4 rupert 22252 0.0 0.0 2240 1608 pts/76 S 15:39:36 0:00 sed -e s,:[0-9][0-9]*/,/, rupert 22255 0.0 0.0 2168 1456 pts/73 S 15:39:43 0:00 grep rupert rupert 23303 0.0 0.012624 1632 ? S 14:59:42 0:00 /opt/csw/sbin/sshd -R rupert 23305 0.0 0.0 3832 1952 pts/76 S 14:59:43 0:00 -bash then i upgraded the dependencies as well. but the result did not change, the test just hang. rupert. From maciej at opencsw.org Tue Jan 5 09:53:00 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 5 Jan 2010 08:53:00 +0000 Subject: [csw-maintainers] [csw-buildfarm] what is different on buildfarm? mercurial tests take long - or fail In-Reply-To: <6af4271001041457h4535abdar558fdb87b70cf151@mail.gmail.com> References: <6af4271001020318k5f9fe830gd5378c9bf96e267b@mail.gmail.com> <841FE230-13C7-4CEC-9202-B01167FE8730@opencsw.org> <6af4271001041148x907e364ha7d09da31400df6b@mail.gmail.com> <0DEA3BF3-1EC8-42F7-A160-1CC681304F3F@opencsw.org> <6af4271001041457h4535abdar558fdb87b70cf151@mail.gmail.com> Message-ID: On Mon, Jan 4, 2010 at 10:57 PM, rupert THURNER wrote: > then i upgraded the dependencies as well. but the result did not > change, the test just hang. My mantra is: what does truss say? From dam at opencsw.org Tue Jan 5 15:46:41 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 5 Jan 2010 15:46:41 +0100 Subject: [csw-maintainers] FYI: Automatic deletion of released packages from testing/ References: <201001051430.o05EUIPC008639@mirror.opencsw.org> Message-ID: Hi, automatic deletion of released packages is now active. So just leave packages in testing/ after copying them over to newpkgs/ and don't bother deleting them. Only *identical* packages are deleted. Files like these keep laying around, please remove them manually: Anfang der weitergeleiteten E-Mail: > Newer PKG released. Testing: mercurial-1.4.1,REV=2009.12.16-SunOS5.8-i386-CSW.pkg.gz > Released: mercurial-1.4.2,REV=2010.01.02-SunOS5.8-sparc-CSW.pkg.gz > Newer PKG released. Testing: mercurial-1.4.1,REV=2009.12.16-SunOS5.8-sparc-CSW.pkg.gz > Released: mercurial-1.4.2,REV=2010.01.02-SunOS5.8-sparc-CSW.pkg.gz Best regards -- Dago From phil at bolthole.com Tue Jan 5 17:27:08 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 5 Jan 2010 08:27:08 -0800 Subject: [csw-maintainers] FYI: Automatic deletion of released packages from testing/ In-Reply-To: References: <201001051430.o05EUIPC008639@mirror.opencsw.org> Message-ID: On Tue, Jan 5, 2010 at 6:46 AM, Dagobert Michelsen wrote: > Hi, > > automatic deletion of released packages is now active. So just > leave packages in testing/ after copying them over to newpkgs/ > and don't bother deleting them. Only *identical* packages are > deleted. Might be nice to either keep an exceptions file, or provide a separate "experimental" location, then? I'd like to keep the samba old packages around. From ihsan at opencsw.org Tue Jan 5 20:43:02 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Tue, 05 Jan 2010 20:43:02 +0100 Subject: [csw-maintainers] maintenance on the mail/web server Message-ID: <4B439646.9030804@opencsw.org> Hello, Between 18:00 and 21:00 GMT there will be an outage of the mail server for approximately 1 hour. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Tue Jan 5 21:14:37 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 5 Jan 2010 21:14:37 +0100 Subject: [csw-maintainers] FYI: Automatic deletion of released packages from testing/ In-Reply-To: References: <201001051430.o05EUIPC008639@mirror.opencsw.org> Message-ID: <670E7EA4-6062-4D9D-B68B-3D64B9B3AA93@opencsw.org> Hi Phil, Am 05.01.2010 um 17:27 schrieb Philip Brown: > On Tue, Jan 5, 2010 at 6:46 AM, Dagobert Michelsen wrote: >> automatic deletion of released packages is now active. So just >> leave packages in testing/ after copying them over to newpkgs/ >> and don't bother deleting them. Only *identical* packages are >> deleted. > > Might be nice to either keep an exceptions file, or provide a separate > "experimental" location, then? > I'd like to keep the samba old packages around. You are missing the point: Only packages officially released and resynced back to the farm are deleted from testing/, everything else is not touched, but needs to be removed manually if necessary. Best regards -- Dago From dam at opencsw.org Tue Jan 5 21:56:02 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 5 Jan 2010 21:56:02 +0100 Subject: [csw-maintainers] libproxy in testing Message-ID: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> Hi, I just build libproxy which can be used by many other packages for automatic proxy configuration location. Unfortunately it is written according to C99, which is only compilable on Solaris 10+. For Solaris 8/9 major code changes and GNULibs substitutes would be needed. Thoughts? libproxy-0.3.0,REV=2010.01.05-SunOS5.10-sparc-CSW.pkg.gz libproxy-0.3.0,REV=2010.01.05-SunOS5.10-i386-CSW.pkg.gz Best regards -- Dago From bwalton at opencsw.org Tue Jan 5 22:01:51 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 05 Jan 2010 16:01:51 -0500 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> Message-ID: <1262725258-sup-3515@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Tue Jan 05 15:56:02 -0500 2010: > be needed. Thoughts? 10 only. If the devs aren't interested in older platforms and you have no personal need, why go through the headache? -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 Jan 5 22:03:16 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 5 Jan 2010 22:03:16 +0100 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <1262725258-sup-3515@ntdws12.chass.utoronto.ca> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> <1262725258-sup-3515@ntdws12.chass.utoronto.ca> Message-ID: <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> Hi Ben, Am 05.01.2010 um 22:01 schrieb Ben Walton: > Excerpts from Dagobert Michelsen's message of Tue Jan 05 15:56:02 -0500 2010: > >> be needed. Thoughts? > > 10 only. If the devs aren't interested in older platforms and you > have no personal need, why go through the headache? The question is: Do we want to release it and make separate releases of packages for Solaris 8/9 vs. 10 which require it? Best regards -- Dago From bwalton at opencsw.org Tue Jan 5 22:13:18 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 05 Jan 2010 16:13:18 -0500 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> <1262725258-sup-3515@ntdws12.chass.utoronto.ca> <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> Message-ID: <1262725840-sup-6428@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Tue Jan 05 16:03:16 -0500 2010: > The question is: Do we want to release it and make separate releases > of packages for Solaris 8/9 vs. 10 which require it? I guess that depends on how popular it gets? Are there many packages that leverage it? -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dam at opencsw.org Tue Jan 5 22:21:01 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 5 Jan 2010 22:21:01 +0100 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <1262725840-sup-6428@ntdws12.chass.utoronto.ca> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> <1262725258-sup-3515@ntdws12.chass.utoronto.ca> <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> <1262725840-sup-6428@ntdws12.chass.utoronto.ca> Message-ID: <770D1EA9-1422-4196-B97E-E301D9087FA2@opencsw.org> Hi Ben, Am 05.01.2010 um 22:13 schrieb Ben Walton: > Excerpts from Dagobert Michelsen's message of Tue Jan 05 16:03:16 -0500 2010: > >> The question is: Do we want to release it and make separate releases >> of packages for Solaris 8/9 vs. 10 which require it? > > I guess that depends on how popular it gets? Are there many packages > that leverage it? It looks like it gets quite popular: http://code.google.com/p/libproxy/wiki/Applications I asked on-list wheter they would accept patches for pre-C99 compat. Best regards -- Dago From bwalton at opencsw.org Tue Jan 5 22:27:20 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 05 Jan 2010 16:27:20 -0500 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <770D1EA9-1422-4196-B97E-E301D9087FA2@opencsw.org> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> <1262725258-sup-3515@ntdws12.chass.utoronto.ca> <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> <1262725840-sup-6428@ntdws12.chass.utoronto.ca> <770D1EA9-1422-4196-B97E-E301D9087FA2@opencsw.org> Message-ID: <1262726786-sup-7146@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Tue Jan 05 16:21:01 -0500 2010: Hi Dago, > It looks like it gets quite popular: > http://code.google.com/p/libproxy/wiki/Applications Yes that is popular and importantly, some of the apps leveraging it are also quite popular. > I asked on-list wheter they would accept patches for pre-C99 > compat. Good luck! :) 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 skayser at opencsw.org Wed Jan 6 01:47:38 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 06 Jan 2010 01:47:38 +0100 Subject: [csw-maintainers] GAR: Changes to checkpkg: shared libraries and modularity In-Reply-To: References: Message-ID: <4B43DDAA.6040208@opencsw.org> Maciej (Matchek) Blizinski wrote on 04.01.2010 16:43: > The v2-checkpkg branch has been merged to v2 today. It means that the > new shared library checking code is now live. The next time you > update your GAR sources, the new code will be pulled in. > > [...] > > One of the main differences in output is that the new check displays > dependencies it thinks are unnecessary. I found it a useful feature. > For instance, I found out that syslog-ng was reported to have an > unnecessary dependency on CSWtcpwrap. Upon close examination, it > turned out that syslog-ng was supposed to have tcp wrapper support, > but it was just not compiled in. If checkpkg hasn't tipped me off, I > wouldn't have known or fixed this issue. I'm sure other people will > be able to catch some problems by looking at this part of checkpkg's > output. Yes!! Thanks for the time you put into this! checkpkg just did the same for me with mbuffer. Dependency to openssl_rt had become obsolete with version bumps and this would have gone unnoticed if it was only for me. > The new code outputs also information about dependencies between > binary files: which files uses which shared library, and which package > provides the library in question. > > I suspect that the new code might be slightly more picky and may > produce more false positives than the previous one. If you run into a > false-positive, or any kind of problem with library-related checks, > please drop me a line. I've got small debugging infrastructure > integrated into the new checkpkg files. Two minor things. First, the mbuffer package doesn't contain any library, still checkpkg tries to check something (the binary?) for a SONAME. ... INFO:root:The mbuffer shared library doesn't provide a SONAME. INFO:root:The mbuffer shared library doesn't provide a SONAME. ... Second, and this is really minor (but I guess trivial to attack with your python foo), could you get rid of the Unicode u prefix in front of the provided-by-package names? ... Analysis of sonames needed by the package set: libresolv.so.2 is provided by u'SUNWcsl' and required by: mbuffer libmhash.so.2 is provided by u'CSWlibmhash' and required by: mbuffer libnsl.so.1 is provided by u'SUNWcsl' and required by: mbuffer librt.so.1 is provided by u'SUNWcsl' and required by: mbuffer libsocket.so.1 is provided by u'SUNWcsl' and required by: mbuffer libm.so.1 is provided by u'SUNWlibms' and required by: mbuffer libpthread.so.1 is provided by u'SUNWcsl' and required by: mbuffer libc.so.1 is provided by u'SUNWcsl' and required by: mbuffer ... Sebastian From skayser at opencsw.org Wed Jan 6 12:12:30 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 06 Jan 2010 12:12:30 +0100 Subject: [csw-maintainers] GAR and isaexec: merging to $ISA subdirs doesn't work Message-ID: <4B44701E.1070100@opencsw.org> Hi, I just removed NO_ISAEXEC=1 from the mbuffer package to make it a regular 32-/64-bit package with isaexec as a wrapper. The resulting package looks just like before though. No isaexec symlink and the default $ISA in bin/. What's wrong? Running "gmake spotless package" leads to the same result. Current build description is checked in [1]. $ tree work/solaris8-sparc/pkgroot/ work/solaris8-sparc/pkgroot/ `-- opt `-- csw |-- bin | |-- mbuffer | `-- sparcv9 | `-- mbuffer $ file work/solaris8-sparc/pkgroot/opt/csw/bin/mbuffer work/solaris8-sparc/pkgroot/opt/csw/bin/mbuffer: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped $ file work/solaris8-sparc/pkgroot/opt/csw/bin/sparcv9/mbuffer work/solaris8-sparc/pkgroot/opt/csw/bin/sparcv9/mbuffer: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, stripped $ zgrep bin/ ~/pkgs/mbuffer-20091227\,REV\=2010.01.06-SunOS5.8-sparc-CSW.pkg.gz ... 1 f none /opt/csw/bin/mbuffer 0755 root bin 72608 13869 1262774610 1 f none /opt/csw/bin/sparcv9/mbuffer 0755 root bin 86176 27717 1262774652 ... Sebastian [1]https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/mbuffer/trunk/Makefile From dam at opencsw.org Wed Jan 6 22:36:03 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 6 Jan 2010 22:36:03 +0100 Subject: [csw-maintainers] GAR and isaexec: merging to $ISA subdirs doesn't work In-Reply-To: <4B44701E.1070100@opencsw.org> References: <4B44701E.1070100@opencsw.org> Message-ID: <080DF858-63AB-4867-9B3F-3ABA7A43E645@opencsw.org> Hi Sebastian, Am 06.01.2010 um 12:12 schrieb Sebastian Kayser: > I just removed NO_ISAEXEC=1 from the mbuffer package to make it a > regular 32-/64-bit package with isaexec as a wrapper. The resulting > package looks just like before though. No isaexec symlink and the > default $ISA in bin/. What's wrong? Running "gmake spotless package" > leads to the same result. Current build description is checked > in [1]. I guess you hit this bug: Please try "gmake repackage" unless it has been fixed. Best regards -- Dago From ihsan at opencsw.org Wed Jan 6 22:38:09 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 06 Jan 2010 22:38:09 +0100 Subject: [csw-maintainers] maintenance on the mail/web server In-Reply-To: <4B439646.9030804@opencsw.org> References: <4B439646.9030804@opencsw.org> Message-ID: <4B4502C1.5020104@opencsw.org> Am 05.01.10 20:43, schrieb Ihsan Dogan: > Between 18:00 and 21:00 GMT there will be an outage of the mail server > for approximately 1 hour. Everything is up and running again. I'm very sorry for the long delay. The PHP package is by the broken: ihsan at bender:~$ ldd /opt/csw/php5/lib/php/extensions/no-debug-non-zts-20060613/mysql.so libmysqlclient.so.15 => (file not found) libc.so.1 => /lib/libc.so.1 libm.so.2 => /lib/libm.so.2 /platform/SUNW,Sun-Fire-T200/lib/libc_psr.so.1 Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Wed Jan 6 22:46:23 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 6 Jan 2010 22:46:23 +0100 Subject: [csw-maintainers] maintenance on the mail/web server In-Reply-To: <4B4502C1.5020104@opencsw.org> References: <4B439646.9030804@opencsw.org> <4B4502C1.5020104@opencsw.org> Message-ID: Hi Ihsan, Am 06.01.2010 um 22:38 schrieb Ihsan Dogan: > Am 05.01.10 20:43, schrieb Ihsan Dogan: > >> Between 18:00 and 21:00 GMT there will be an outage of the mail server >> for approximately 1 hour. > > Everything is up and running again. I'm very sorry for the long delay. > > The PHP package is by the broken: > ihsan at bender:~$ ldd > /opt/csw/php5/lib/php/extensions/no-debug-non-zts-20060613/mysql.so > libmysqlclient.so.15 => (file not found) > libc.so.1 => /lib/libc.so.1 > libm.so.2 => /lib/libm.so.2 > /platform/SUNW,Sun-Fire-T200/lib/libc_psr.so.1 There seems to be a legacy link missing. This is in your mysql.so: [4] RUNPATH /opt/csw/lib:/opt/csw/bdb44/lib:/opt/csw/lib/mysql [5] RPATH /opt/csw/lib:/opt/csw/bdb44/lib:/opt/csw/lib/mysql Please make ln -s /opt/csw/mysql5/lib/mysql /opt/csw/lib/mysql in the meantime unless there is an official fix. Maciej: Shouldn't there be a "legacy compat link" somewhere in the mysql package? Best regards -- Dago From skayser at opencsw.org Wed Jan 6 23:03:05 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 06 Jan 2010 23:03:05 +0100 Subject: [csw-maintainers] GAR and isaexec: merging to $ISA subdirs doesn't work In-Reply-To: <080DF858-63AB-4867-9B3F-3ABA7A43E645@opencsw.org> References: <4B44701E.1070100@opencsw.org> <080DF858-63AB-4867-9B3F-3ABA7A43E645@opencsw.org> Message-ID: <4B450899.5030501@opencsw.org> Hi Dago, Dagobert Michelsen wrote on 06.01.2010 22:36: > Am 06.01.2010 um 12:12 schrieb Sebastian Kayser: >> I just removed NO_ISAEXEC=1 from the mbuffer package to make it a >> regular 32-/64-bit package with isaexec as a wrapper. The resulting >> package looks just like before though. No isaexec symlink and the >> default $ISA in bin/. What's wrong? Running "gmake spotless package" >> leads to the same result. Current build description is checked >> in [1]. > > I guess you hit this bug: > > > Please try "gmake repackage" unless it has been fixed. indeed, "gmake repackage" did the trick. Thank you. The bug seems to be triggered not only by "gmake platforms" btw., I had also tried a plain "gmake package" to no avail. I have added this as a comment to the bug. Sebastian From maciej at opencsw.org Thu Jan 7 13:48:49 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 7 Jan 2010 12:48:49 +0000 Subject: [csw-maintainers] maintenance on the mail/web server In-Reply-To: References: <4B439646.9030804@opencsw.org> <4B4502C1.5020104@opencsw.org> Message-ID: On Wed, Jan 6, 2010 at 9:46 PM, Dagobert Michelsen wrote: > There seems to be a legacy link missing. This is in your mysql.so: > > [4] ? ? RUNPATH ? ? ? ? /opt/csw/lib:/opt/csw/bdb44/lib:/opt/csw/lib/mysql > [5] ? ? RPATH ? ? ? ? ? /opt/csw/lib:/opt/csw/bdb44/lib:/opt/csw/lib/mysql > > Please make > > ?ln -s /opt/csw/mysql5/lib/mysql /opt/csw/lib/mysql > > in the meantime unless there is an official fix. > > Maciej: Shouldn't there be a "legacy compat link" somewhere in the mysql > package? I can add one. But -- what should the CSWmysql51 package contain? You can have a link from /opt/csw/lib/mysql to both /opt/csw/mysql5/lib/mysql and /opt/csw/mysql51/lib/mysql at the same time. From maciej at opencsw.org Thu Jan 7 13:49:33 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 7 Jan 2010 12:49:33 +0000 Subject: [csw-maintainers] maintenance on the mail/web server In-Reply-To: References: <4B439646.9030804@opencsw.org> <4B4502C1.5020104@opencsw.org> Message-ID: On Thu, Jan 7, 2010 at 12:48 PM, Maciej (Matchek) Blizinski wrote: > On Wed, Jan 6, 2010 at 9:46 PM, Dagobert Michelsen wrote: >> There seems to be a legacy link missing. This is in your mysql.so: >> >> [4] ? ? RUNPATH ? ? ? ? /opt/csw/lib:/opt/csw/bdb44/lib:/opt/csw/lib/mysql >> [5] ? ? RPATH ? ? ? ? ? /opt/csw/lib:/opt/csw/bdb44/lib:/opt/csw/lib/mysql >> >> Please make >> >> ?ln -s /opt/csw/mysql5/lib/mysql /opt/csw/lib/mysql >> >> in the meantime unless there is an official fix. >> >> Maciej: Shouldn't there be a "legacy compat link" somewhere in the mysql >> package? > > I can add one. ?But -- what should the CSWmysql51 package contain? You > can have a link from /opt/csw/lib/mysql to both > /opt/csw/mysql5/lib/mysql and /opt/csw/mysql51/lib/mysql at the same > time. Um, I meant, you cannot have a link from one place to two places at the same time. From dam at opencsw.org Thu Jan 7 14:47:16 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 7 Jan 2010 14:47:16 +0100 Subject: [csw-maintainers] BO Buildfarm will be down tomorrow for LDom update Message-ID: <4610F26C-0F72-4B02-AB82-72C14942A20D@opencsw.org> Hi, I am finally going to update the T5220 for LDoms and OpenSolaris. As "login" is affected the BO buildfarm will be down tomorrow 2010/01/08 between 9 AM MET and 6 PM MET. Please use login.go.opencsw.org in the meantime for something important. Best regards -- Dago From maciej at opencsw.org Thu Jan 7 16:33:13 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 7 Jan 2010 15:33:13 +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. Turns out, you can customize xterm and tell it which characters belong to words and which don't. man xterm, look for "charClass". The quick fix is: echo >> ~/.Xresources "xterm*charClass: 45:48" xrdb -merge ~/.Xresources If you use xterm, it should be useful for you. By the way, it turned out some time ago that the dot is also a legal character as far as pkgnames are concerned. I learned that when creating a catalog with SUNW packages. From dam at opencsw.org Thu Jan 7 21:51:00 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 7 Jan 2010 21:51:00 +0100 Subject: [csw-maintainers] Ganglia for sparcv9 In-Reply-To: <4AE87999.6020401@opencsw.org> References: <4AE87999.6020401@opencsw.org> Message-ID: <777D637C-111E-4F5B-8562-501B9F42351E@opencsw.org> Hi Daniel, Am 28.10.2009 um 18:04 schrieb Daniel Pocock: > I've added > > BUILD64 = 1 > > to my Ganglia package Makefile, so that I can build 64 bit support. > > This is important because Ganglia makes calls to kstat and that needs to be done from 64 bit code when running on a 64 bit kernel. > > However, I'm finding that some dependencies are not 64 bit. The key ones that I am currently stuck on: > > /opt/csw/apache2/lib/libapr-1.so.0 Ok, this is done now. > /opt/csw/lib/sparcv8/libsasl2.so.2 I have prepared the package, but as I don't use I need testers. Do you have experience with SASL? > /opt/csw/lib/sparcv8/libnet.so This is a hard one as I wrote before: Roger did some work towards it, but didn't finish updating the library. You can read about the troubles he ran into by following this thread: > Can anyone assist with this or make any comments on these issues? Ihsan: For rrdtool I just opened a case for 64 bit libs: Looks like we are getting closer... Best regards -- Dago From maciej at opencsw.org Fri Jan 8 00:54:07 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 7 Jan 2010 23:54:07 +0000 Subject: [csw-maintainers] GAR: Changes to checkpkg: shared libraries and modularity In-Reply-To: <4B43DDAA.6040208@opencsw.org> References: <4B43DDAA.6040208@opencsw.org> Message-ID: On Wed, Jan 6, 2010 at 12:47 AM, Sebastian Kayser wrote: > Two minor things. First, the mbuffer package doesn't contain any > library, still checkpkg tries to check something (the binary?) for a SONAME. > > ... > INFO:root:The mbuffer shared library doesn't provide a SONAME. > INFO:root:The mbuffer shared library doesn't provide a SONAME. > ... Right, the code currently doesn't distinguish shared libraries and executables; at some point it was assumed that if it is a shared library, it will provide a SONAME, but there are cases where it's not true, Oracle shared libraries for instance. I moved this message to the debug level, it's not needed for normal operation. > Second, and this is really minor (but I guess trivial to attack with > your python foo), could you get rid of the Unicode u prefix in front of > the provided-by-package names? > > ... > Analysis of sonames needed by the package set: > libresolv.so.2 is provided by u'SUNWcsl' and required by: > ?mbuffer > libmhash.so.2 is provided by u'CSWlibmhash' and required by: > ?mbuffer > libnsl.so.1 is provided by u'SUNWcsl' and required by: > ?mbuffer > librt.so.1 is provided by u'SUNWcsl' and required by: > ?mbuffer > libsocket.so.1 is provided by u'SUNWcsl' and required by: > ?mbuffer > libm.so.1 is provided by u'SUNWlibms' and required by: > ?mbuffer > libpthread.so.1 is provided by u'SUNWcsl' and required by: > ?mbuffer > libc.so.1 is provided by u'SUNWcsl' and required by: > ?mbuffer > ... Done. It was also a debug-ish thing, where I wanted to make sure that I can see a difference between "SUNWcsl" and "SUNWcsl ", etc. I'm glad you like it! Any further thoughts or comments? From dam at opencsw.org Fri Jan 8 18:44:57 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 8 Jan 2010 18:44:57 +0100 Subject: [csw-maintainers] BO Buildfarm available again In-Reply-To: <4610F26C-0F72-4B02-AB82-72C14942A20D@opencsw.org> References: <4610F26C-0F72-4B02-AB82-72C14942A20D@opencsw.org> Message-ID: Hi, Am 07.01.2010 um 14:47 schrieb Dagobert Michelsen: > I am finally going to update the T5220 for LDoms and OpenSolaris. > As "login" is affected the BO buildfarm will be down tomorrow > 2010/01/08 > between 9 AM MET and 6 PM MET. The T5220 is now split into two LDoms: One LDom with the existing Solaris 10 instance carrying all of the Sparc stuff which was already there (now restricted to 12 GB Ram and 20 Strands) and one LDom with OpenSolaris 06/09 Sparc still installing with 3 GB Ram and 8 Strands. Additionally, all zones have been patched with the current patchset. Please let me know if you encounter anything strange. Best regards -- Dago From ihsan at opencsw.org Sat Jan 9 22:40:26 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sat, 09 Jan 2010 22:40:26 +0100 Subject: [csw-maintainers] maintenance on the mail/web server In-Reply-To: References: <4B439646.9030804@opencsw.org> <4B4502C1.5020104@opencsw.org> Message-ID: <4B48F7CA.5010801@opencsw.org> Am 06.01.10 22:46, schrieb Dagobert Michelsen: >> The PHP package is by the broken: >> ihsan at bender:~$ ldd >> /opt/csw/php5/lib/php/extensions/no-debug-non-zts-20060613/mysql.so >> libmysqlclient.so.15 => (file not found) >> libc.so.1 => /lib/libc.so.1 >> libm.so.2 => /lib/libm.so.2 >> /platform/SUNW,Sun-Fire-T200/lib/libc_psr.so.1 > > There seems to be a legacy link missing. This is in your mysql.so: > > [4] RUNPATH /opt/csw/lib:/opt/csw/bdb44/lib:/opt/csw/lib/mysql > [5] RPATH /opt/csw/lib:/opt/csw/bdb44/lib:/opt/csw/lib/mysql > > Please make > > ln -s /opt/csw/mysql5/lib/mysql /opt/csw/lib/mysql > > in the meantime unless there is an official fix. I've fixed with setting LD_LIBRARY_PATH variable in the FastCGI start script. > Maciej: Shouldn't there be a "legacy compat link" somewhere in the mysql > package? Well, we would need an updated PHP package. :-) Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Sat Jan 9 22:50:39 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sat, 09 Jan 2010 22:50:39 +0100 Subject: [csw-maintainers] Ganglia for sparcv9 In-Reply-To: <777D637C-111E-4F5B-8562-501B9F42351E@opencsw.org> References: <4AE87999.6020401@opencsw.org> <777D637C-111E-4F5B-8562-501B9F42351E@opencsw.org> Message-ID: <4B48FA2F.2020806@opencsw.org> Am 07.01.10 21:51, schrieb Dagobert Michelsen: > Ihsan: For rrdtool I just opened a case for 64 bit libs: > I'll have a look in that tomorrow. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From hson at opencsw.org Sat Jan 9 23:41:46 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Sat, 09 Jan 2010 23:41:46 +0100 Subject: [csw-maintainers] libcairo dependency on /usr/openwin/lib/libX11.so... Message-ID: <4B49062A.9020805@opencsw.org> Since the packages in /opt/csw/X11/lib got updated and more and more packages started to get linked to those, I've started updating my packages but often gotten into trouble with the following error. Undefined first referenced symbol in file XSolarisIASetProcessInfo /usr/openwin/lib/libX11.so.4 At first I just made some changes so that /usr/openwin/lib/libXext.so got added to the link-phase, but then I started to wonder why some of the newly updated packages still required those old libraries. It seems that the problem is libcairo and libxrender. When libcairo is built, it needs libXrender and finds one in /opt/csw/lib (which according to dago's comments in the Makefile is kept there for compatibility issues). But that lib is linked to libX11.so.4 (openwin version) and not libX11.so.6 (csw version) which the libXrender under /opt/csw/X11/lib is not. The reason for this is simple, gar adds $(prefix)/X11/lib after $(prefix)/lib and thus libcairo gets linked to the old libXrender library. I've committed some changes to the Makefile which fixes this problem. Dago, could you repackage and update buildfarm (maybe start on build8st and build8xt so we can work our way through all dependencies before releasing?) From skayser at opencsw.org Sun Jan 10 00:00:02 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 10 Jan 2010 00:00:02 +0100 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last Message-ID: <4B490A72.6000602@opencsw.org> Hi, our mailing list archive boosts at least a dozen of threads on libtool. Here comes another one from someone to whom the exact inner libtool workings are a mystery. When I try to build dante with kerberos support (enabled per default), libtool IMHO messes up the call to ld which then fails to find the CSW kerberos libraries. /bin/bash ../libtool --tag=CC --mode=link /opt/studio/SOS11/SUNWspro/bin/cc -DSOCKS_CLIENT=1 -DSOCKS_SERVER=0 -DSOCKSLIBRARY_DYNAMIC=0 -xO3 -xarch=v8 -Xt -xarch=v8 -L/opt/csw/lib -L/opt/csw/lib -R/opt/csw/lib -R/opt/csw/lib/ -R/opt/csw/lib -L/opt/csw/lib -z combreloc -z text -z ignore -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lkrb5support -lresolv -lsocket -lnsl -o libsocks.la -rpath /opt/csw/lib -version-info 1:1:1 config_parse.lo config_scan.lo Raccept.lo Rbind.lo Rgetpeername.lo Rgetsockname.lo Rrresvport.lo io.lo address.lo authneg.lo client.lo clientconfig.lo clientprotocol.lo udp.lo userio.lo connectchild.lo config.lo log.lo protocol.lo socket.lo udp_util.lo util.lo Rbindresvport.lo Rconnect.lo Rgethostbyname.lo debug.lo Rcompat.lo msproxy_clientprotocol.lo hostcache.lo broken.lo serr.lo httpproxy.lo tostring.lo addressmatch.lo Rlisten.lo upnp.lo gssapi.lo iobuf.lo ../libscompat/libscompat.la -L/opt/csw/lib -R/opt/csw/lib -R/opt/csw/lib/ -R/opt/csw/lib -L/opt/csw/li b -z combreloc -z text -z ignore -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lkrb5support -lresolv -lsocket -lnsl -lpam -lnsl -lsocket -lresolv -ldl /usr/ccs/bin/ld -G -h libsocks.so.0 -o .libs/libsocks.so.0.1.1 .libs/config_parse.o .libs/config_scan.o .libs/Raccept.o .libs/Rbind.o .libs/Rgetpeername.o .libs/Rgetsockname.o .libs/Rrresvport.o .libs/io.o .libs/address.o .libs/authneg.o .libs/client.o .libs/clientconfig.o .libs/clientprotocol.o .libs/udp.o .libs/userio.o .libs/connectchild.o .libs/config.o .libs/log.o .libs/protocol.o .libs/socket.o .libs/udp_util.o .libs/util.o .libs/Rbindresvport.o .libs/Rconnect.o .libs/Rgethostbyname.o .libs/debug.o .libs/Rcompat.o .libs/msproxy_clientprotocol.o .libs/hostcache.o .libs/broken.o .libs/serr.o .libs/httpproxy.o .libs/tostring.o .libs/addressmatch.o .libs/Rlisten.o .libs/upnp.o .libs/gssapi.o .libs/iobuf.o -z allextract ../libscompat/.libs/libscompat.a -z defaultextract -R/opt/csw/lib -R/opt/csw/lib/ -ldl -lresolv -lsocket -lnsl -lpam -lkrb5support -lcom_err -lk5crypto -lkrb5 -lgssapi_krb5 -L/opt/csw/lib -lc ld: fatal: library -lkrb5support: not found ld: fatal: library -lcom_err: not found ld: fatal: library -lk5crypto: not found ld: fatal: library -lkrb5: not found ld: fatal: library -lgssapi_krb5: not found ld: fatal: File processing errors. No output written to .libs/libsocks.so.0.1.1 gmake[3]: *** [libsocks.la] Error 1 gmake[3]: Leaving directory `/home/skayser/mgar/pkg/dante/trunk/work/solaris8-sparc/build-isa-sparcv8/dante-1.2.0/lib' To me it looks like libtool is rearranging linker flags. When it calls /usr/ccs/bin/ld it puts -L/opt/csw/lib after all the -l options which obviously breaks any references to CSW libs. The invocation of libtool itself still contains the correct -L/-l order. Any idea how to fix or circumvent this? $ work/solaris8-sparc/build-isa-sparcv8/dante-1.2.0/libtool --version ltmain.sh (GNU libtool) 1.5.26 (1.1220.2.493 2008/02/01 16:58:18) Sebastian From william at wbonnet.net Sun Jan 10 00:58:02 2010 From: william at wbonnet.net (William Bonnet) Date: Sun, 10 Jan 2010 00:58:02 +0100 Subject: [csw-maintainers] Upstream check for sourceforge not working? In-Reply-To: <4B426A38.3030504@opencsw.org> References: <4B425CE3.8050201@opencsw.org> <4B425F45.7050400@wbonnet.net> <4B426A38.3030504@opencsw.org> Message-ID: <4B49180A.7030905@wbonnet.net> Hi Roger > However the output from sourceforge must have changed because running > that command gives no output at all and running the wget manually and > checking the output tells me that upstream_watch cannot work with > their current design. That's right, something changed in the design of the web page and it no longer works. I have to modify my checks. Thanks for reporting this. 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 skayser at opencsw.org Sun Jan 10 11:54:24 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 10 Jan 2010 11:54:24 +0100 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: <4B490A72.6000602@opencsw.org> References: <4B490A72.6000602@opencsw.org> Message-ID: <4B49B1E0.20907@opencsw.org> Sebastian Kayser wrote on 10.01.2010 00:00: > When I try to build dante with kerberos support (enabled per default), > libtool IMHO messes up the call to ld which then fails to find the CSW > kerberos libraries. > > > /bin/bash ../libtool --tag=CC --mode=link /opt/studio/SOS11/SUNWspro/bin/cc -DSOCKS_CLIENT=1 -DSOCKS_SERVER=0 -DSOCKSLIBRARY_DYNAMIC=0 -xO3 -xarch=v8 -Xt -xarch=v8 -L/opt/csw/lib -L/opt/csw/lib -R/opt/csw/lib -R/opt/csw/lib/ -R/opt/csw/lib -L/opt/csw/lib -z combreloc -z text -z ignore -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lkrb5support -lresolv -lsocket -lnsl -o libsocks.la -rpath /opt/csw/lib -version-info 1:1:1 config_parse.lo config_scan.lo Raccept.lo Rbind.lo Rgetpeername.lo Rgetsockname.lo Rrresvport.lo io.lo address.lo authneg.lo client.lo clientconfig.lo clientprotocol.lo udp.lo userio.lo connectchild.lo config.lo log.lo protocol.lo socket.lo udp_util.lo util.lo Rbindresvport.lo Rconnect.lo Rgethostbyname.lo debug.lo Rcompat.lo msproxy_clientprotocol.lo hostcache.lo broken.lo serr.lo httpproxy.lo tostring.lo addressmatch.lo Rlisten.lo upnp.lo gssapi.lo iobuf.lo ../libscompat/libscompat.la -L/opt/csw/lib -R/opt/csw/lib -R/opt/csw/lib/ -R/opt/csw/lib -L/opt/csw/ li > b -z combreloc -z text -z ignore -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lkrb5support -lresolv -lsocket -lnsl -lpam -lnsl -lsocket -lresolv -ldl > /usr/ccs/bin/ld -G -h libsocks.so.0 -o .libs/libsocks.so.0.1.1 .libs/config_parse.o .libs/config_scan.o .libs/Raccept.o .libs/Rbind.o .libs/Rgetpeername.o .libs/Rgetsockname.o .libs/Rrresvport.o .libs/io.o .libs/address.o .libs/authneg.o .libs/client.o .libs/clientconfig.o .libs/clientprotocol.o .libs/udp.o .libs/userio.o .libs/connectchild.o .libs/config.o .libs/log.o .libs/protocol.o .libs/socket.o .libs/udp_util.o .libs/util.o .libs/Rbindresvport.o .libs/Rconnect.o .libs/Rgethostbyname.o .libs/debug.o .libs/Rcompat.o .libs/msproxy_clientprotocol.o .libs/hostcache.o .libs/broken.o .libs/serr.o .libs/httpproxy.o .libs/tostring.o .libs/addressmatch.o .libs/Rlisten.o .libs/upnp.o .libs/gssapi.o .libs/iobuf.o -z allextract ../libscompat/.libs/libscompat.a -z defaultextract -R/opt/csw/lib -R/opt/csw/lib/ -ldl -lresolv -lsocket -lnsl -lpam -lkrb5support -lcom_err -lk5crypto -lkrb5 -lgssapi_krb5 -L/opt/csw/lib -lc > ld: fatal: library -lkrb5support: not found > ld: fatal: library -lcom_err: not found > ld: fatal: library -lk5crypto: not found > ld: fatal: library -lkrb5: not found > ld: fatal: library -lgssapi_krb5: not found > ld: fatal: File processing errors. No output written to .libs/libsocks.so.0.1.1 > gmake[3]: *** [libsocks.la] Error 1 > gmake[3]: Leaving directory `/home/skayser/mgar/pkg/dante/trunk/work/solaris8-sparc/build-isa-sparcv8/dante-1.2.0/lib' > > > To me it looks like libtool is rearranging linker flags. When it calls > /usr/ccs/bin/ld it puts -L/opt/csw/lib after all the -l options which > obviously breaks any references to CSW libs. The invocation of libtool > itself still contains the correct -L/-l order. Any idea how to fix or > circumvent this? > > $ work/solaris8-sparc/build-isa-sparcv8/dante-1.2.0/libtool --version > ltmain.sh (GNU libtool) 1.5.26 (1.1220.2.493 2008/02/01 16:58:18) The Debian patch section for Dante showed that they patch ./configure to use the platform libtool instead of the one shipped with Dante. That's what I ended up doing also. $ gsed -ie 's,^LIBTOOL=.*,LIBTOOL=/opt/csw/bin/libtool,' \ work/solaris8-sparc/build-isa-sparcv8/dante-1.2.0/configure $ grep ^LIBTOOL= \ work/solaris8-sparc/build-isa-sparcv8/dante-1.2.0/configure LIBTOOL=/opt/csw/bin/libtool The problem went away. There still is a downrev libtool in $(WORKSRC) which seems to get re-generated by ./configure, but looking at the build logs its the /opt/csw/bin/libtool which now takes care of the linking. Sebastian From bwalton at opencsw.org Sun Jan 10 15:42:35 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 10 Jan 2010 09:42:35 -0500 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: <4B49B1E0.20907@opencsw.org> References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> Message-ID: <1263134474-sup-4605@ntdws12.chass.utoronto.ca> Excerpts from Sebastian Kayser's message of Sun Jan 10 05:54:24 -0500 2010: > The problem went away. There still is a downrev libtool in $(WORKSRC) > which seems to get re-generated by ./configure, but looking at the build > logs its the /opt/csw/bin/libtool which now takes care of the linking. Given the issues we constantly hit with libtool, I always find myself wondering if it was ever a benefit instead of a burden. Any grey-beards care to offer some historical perspective on this? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Joerg.Schilling at fokus.fraunhofer.de Sun Jan 10 15:45:28 2010 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Sun, 10 Jan 2010 15:45:28 +0100 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: <1263134474-sup-4605@ntdws12.chass.utoronto.ca> References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> <1263134474-sup-4605@ntdws12.chass.utoronto.ca> Message-ID: <4b49e808.V0Z29z8bBAlJHmV1%Joerg.Schilling@fokus.fraunhofer.de> Ben Walton wrote: > Given the issues we constantly hit with libtool, I always find myself > wondering if it was ever a benefit instead of a burden. Any > grey-beards care to offer some historical perspective on this? One of the main reasons for stying with the Schily makefile system concept from 1993 is that it allows to put the knowledge about the various linkers inside the make rules and to sty independend from libtool. From my experiences, libtool is only without pain if you are on Linux. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From bwalton at opencsw.org Sun Jan 10 15:50:06 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 10 Jan 2010 09:50:06 -0500 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: <4b49e808.V0Z29z8bBAlJHmV1%Joerg.Schilling@fokus.fraunhofer.de> References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> <1263134474-sup-4605@ntdws12.chass.utoronto.ca> <4b49e808.V0Z29z8bBAlJHmV1%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <1263134971-sup-3553@ntdws12.chass.utoronto.ca> Excerpts from Joerg.Schilling's message of Sun Jan 10 09:45:28 -0500 2010: > libtool. From my experiences, libtool is only without pain if you > are on Linux. And yet even the Debian folks seem to eschew libtool...? -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 hson at opencsw.org Mon Jan 11 01:29:56 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Mon, 11 Jan 2010 01:29:56 +0100 Subject: [csw-maintainers] libcairo dependency on /usr/openwin/lib/libX11.so... In-Reply-To: <4B49062A.9020805@opencsw.org> References: <4B49062A.9020805@opencsw.org> Message-ID: <4B4A7104.7090604@opencsw.org> On 2010-01-09 23:41, Roger H?kansson wrote: > I've committed some changes to the Makefile which fixes this problem. > Seems I was a little bit hasty in my assessment... My first fix will make libcairo use /opt/csw/X11/lib/libXrender.so at link time, but not runtime. I've tested with a second one where made sure that -R/opt/csw/X11/lib would be first in runtimepath but still, when linking librsvg for instance, the wrong libXrender.so will be picked. So as far as I can see it, in order to "fix" the problem, all packages which link to libXrender.so or to a another lib which link to libXrender.so, must make sure that /opt/csw/X11/lib before /opt/csw/lib in RUNPATH and not the opposite. Or we just remove /opt/csw/lib/libXrender.so* which probably would break a ton of packages. For now (and until someone tells me it's a bad idea) I'll make sure my packages have X11/lib first in runpath From james at opencsw.org Mon Jan 11 16:42:31 2010 From: james at opencsw.org (James Lee) Date: Mon, 11 Jan 2010 15:42:31 GMT Subject: [csw-maintainers] [csw-buildfarm] BO Buildfarm available again In-Reply-To: References: <4610F26C-0F72-4B02-AB82-72C14942A20D@opencsw.org> Message-ID: <20100111.15423100.2872566158@gyor.oxdrove.co.uk> On 08/01/10, 17:44:57, Dagobert Michelsen wrote regarding Re: [csw-buildfarm] [csw-maintainers] BO Buildfarm available again: > The T5220 is now split into two LDoms: One LDom with the existing > Solaris 10 > instance carrying all of the Sparc stuff which was already there (now > restricted to 12 GB Ram and 20 Strands) and one LDom with OpenSolaris > 06/09 Sparc still installing with 3 GB Ram and 8 Strands. Any reason for the restriction? James. From maciej at opencsw.org Mon Jan 11 16:56:33 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 11 Jan 2010 15:56:33 +0000 Subject: [csw-maintainers] Building glib2 Message-ID: I would like to get the newest gnome-terminal working, so I started looking at the endless chain of dependencies. gnome-terminal --> vte --> glib2. I started working on glib2-2.23.1, and after stamping out a couple issues, I got it to build. Sadly, one of the unit tests is failing: https://bugzilla.gnome.org/show_bug.cgi?id=606488 There's also a bug in mantis for future reference: http://www.opencsw.org/mantis/view.php?id=3771 I think the issue could use some more eyeballs. The code under tests is gio, the input-output library. TEST: utf8-input-stream... (pid=196) /utf8-input-stream/read-ascii: OK /utf8-input-stream/read-utf8: OK /utf8-input-stream/read-utf8-partial: OK /utf8-input-stream/read-invalid-start: OK /utf8-input-stream/read-invalid-middle: OK /utf8-input-stream/read-invalid-end: OK /utf8-input-stream/read-invalid-partial: OK /utf8-input-stream/read-small-valid: ** ERROR:utf8-input-stream.c:171:test_read_small_valid: assertion failed ("\xc3\xa8\xc3\xa8" == buf): ("\303\250\303\250" == "\303\250\303\250ar") FAIL GTester: last random seed: R02S5b7291138f726ccdccce512cd75e3f31 gmake[7]: *** [test] Error 143 gmake[7]: Leaving directory `/home/maciej/src/opencsw/pkg/glib2/trunk/work/solaris8-sparc/build-isa-sparcv8/glib-2.23.1/gio/tests' The problem is repeatable, happens every time. Do you have any suggestions or ideas? Maciej From maciej at opencsw.org Mon Jan 11 17:48:13 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 11 Jan 2010 16:48:13 +0000 Subject: [csw-maintainers] GAR: Preprocessing a postinstall file In-Reply-To: <1260585404-sup-1926@ntdws12.chass.utoronto.ca> References: <1260585404-sup-1926@ntdws12.chass.utoronto.ca> Message-ID: On Sat, Dec 12, 2009 at 2:53 AM, Ben Walton wrote: > Excerpts from Maciej (Matchek) Blizinski's message of Fri Dec 11 20:27:14 -0500 2009: >> Suppose I have a file CSWfoo.postinstall, which has some variables >> which need to be substituted before the file can be shipped. >> Something along the lines of: >> >> mycommand=@bindir@/foo > > Use the dynamic adm script capability in GAR. I've found a side effect of this capability: The preprocessed scripts are copied to /home/src on "gmake garchive". It holds for postgresql and gitosis. I'm guessing that you've never done gmake garchive for docbook. From bwalton at opencsw.org Mon Jan 11 17:55:20 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 11 Jan 2010 11:55:20 -0500 Subject: [csw-maintainers] GAR: Preprocessing a postinstall file In-Reply-To: References: <1260585404-sup-1926@ntdws12.chass.utoronto.ca> Message-ID: <1263228843-sup-2059@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Mon Jan 11 11:48:13 -0500 2010: > I've found a side effect of this capability: The preprocessed scripts > are copied to /home/src on "gmake garchive". It holds for postgresql > and gitosis. I'm guessing that you've never done gmake garchive for > docbook. Interesting. Certainly unintentional. I'll see if I can spot why this happens tonight and correct it. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Mon Jan 11 17:56:10 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 11 Jan 2010 16:56:10 +0000 Subject: [csw-maintainers] GAR: Basic custom tests for packages In-Reply-To: <242BF313-F6AA-492A-BCAE-2F4FF1498BC9@opencsw.org> References: <1256179371-sup-7948@ntdws12.chass.utoronto.ca> <242BF313-F6AA-492A-BCAE-2F4FF1498BC9@opencsw.org> Message-ID: On Thu, Oct 22, 2009 at 8:12 AM, Dagobert Michelsen wrote: > Hi Maciej, hi Ben, > > Am 22.10.2009 um 04:44 schrieb Ben Walton: > >> Am 22.10.2009 um 01:04 schrieb Maciej (Matchek) Blizinski: >>> >>> Let's suppose I wanted to write some basic checks for a package. For >>> instance, that I expect there to be a certain file in the prototype, >>> with such and such name and such and such attributes (ownership, >>> permissions, etc). I guess I would do something like: >>> >>> TEST_SCRIPTS = custom >>> >>> test-custom: >>> ? ? ? test code here >>> >>> How do I access things like the prototype, or files at the location >>> from where they're already merged? >> >> I think you'd want to work with the state of things after the merge. >> I don't think the stuff in build-global is guaranteed to be there >> until after that step. ?I don't know if there are pre/post merge >> targets though. > > Yes. Because the normal cycle for a software is > ?configure > ?compile > ?test > ?install > the procedure is the same in GAR. Now to your questions: > >>> For instance, that I expect there to be a certain file in the prototype, >>> with such and such name and such and such attributes (ownership, >>> permissions, etc) > > The prototype (if dynamic) is built during 'package' and there is currently > no hook in-between after dynamic creation of the packaging source files > and the package creation. You could check after package-creation in > post-package. Can a hook be created between the prototype creation and the package creation? Say, just after the creation of the per-package prototype files, so that I can also check that certain files have landed in the specific packages. >>> How do I access things like the prototype, or files at the location >>> from where they're already merged? > > From the global modulation the prototype can be accessed as > ?$(WORKDIR)/prototype > and the package specific prototypes as > ?$(WORKDIR)/CSWmypkg.prototype How do I know I'm in the global modulation? > The merge location is available during global or specific modulations as > $(PKGROOT). > > I suggest you write your test as post-package to ensure it has been built > correctly. However, if it proves useful we could also insert another > step before package creation like > ?pkgverify-CSWmypkg: I've been recently bitten by something that would've been prevented easily using this kind of a test, so I'll get back to it soon. Maciej From hson at opencsw.org Mon Jan 11 23:22:07 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Mon, 11 Jan 2010 23:22:07 +0100 Subject: [csw-maintainers] libcairo dependency on /usr/openwin/lib/libX11.so... In-Reply-To: <4B4A7104.7090604@opencsw.org> References: <4B49062A.9020805@opencsw.org> <4B4A7104.7090604@opencsw.org> Message-ID: <4B4BA48F.5090703@opencsw.org> Roger H?kansson wrote: > On 2010-01-09 23:41, Roger H?kansson wrote: >> I've committed some changes to the Makefile which fixes this problem. >> > > Seems I was a little bit hasty in my assessment... > My first fix will make libcairo use /opt/csw/X11/lib/libXrender.so at > link time, but not runtime. > I've tested with a second one where made sure that -R/opt/csw/X11/lib > would be first in runtimepath but still, when linking librsvg for > instance, the wrong libXrender.so will be picked. > > So as far as I can see it, in order to "fix" the problem, all packages > which link to libXrender.so or to a another lib which link to > libXrender.so, must make sure that /opt/csw/X11/lib before /opt/csw/lib > in RUNPATH and not the opposite. > Or we just remove /opt/csw/lib/libXrender.so* which probably would break > a ton of packages. > > For now (and until someone tells me it's a bad idea) I'll make sure my > packages have X11/lib first in runpath Just to clarify, I've added (and committed) this to the Makefile for libcairo: EXTRA_SOS_LD_FLAGS = -L$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) EXTRA_SOS_LD_OPTIONS = -R$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) This will give us a libcairo.so with /opt/csw/X11/lib first in RUNPATH. Then the packages using libcairo only need to have -L/opt/csw/X11/lib first during build (i.e same setting as libcairo for EXTRA_SOS_LD_FLAGS, but not EXTRA_SOS_LD_OPTIONS) Runtime everything seems to be ok (on my build machines where I've built and reinstalled packages as I built them) using these options. But that's only my quick observations. From maciej at opencsw.org Tue Jan 12 15:37:05 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 12 Jan 2010 14:37:05 +0000 Subject: [csw-maintainers] GAR: Category-level post-merge target Message-ID: Is it possible to add a category-level post-merge target? I would like there to be a post-merge target that is executed with my custom category, but I would like the individual packages to have separate post-merge targets. Is there such target already, or if not, can I create it in GAR? Say, category-post-merge? Maciej From phil at bolthole.com Tue Jan 12 18:31:28 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 12 Jan 2010 09:31:28 -0800 Subject: [csw-maintainers] libcairo dependency on /usr/openwin/lib/libX11.so... In-Reply-To: <4B4A7104.7090604@opencsw.org> References: <4B49062A.9020805@opencsw.org> <4B4A7104.7090604@opencsw.org> Message-ID: On Sun, Jan 10, 2010 at 4:29 PM, Roger H?kansson wrote: >>... > Seems I was a little bit hasty in my assessment... > My first fix will make libcairo use /opt/csw/X11/lib/libXrender.so at link > time, but not runtime. Side comment/tip: make sure that ALL DEPENDANCIES of libcairo, are using "our" version of libX, etc, rather than the /usr/openwin ones. Otherwise that can mess you up. Sadly, it's not enough to have the deps' version "up to date". you also have to have them using the compatible libs for themselves. so you might need to take over some. From phil at bolthole.com Tue Jan 12 18:32:52 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 12 Jan 2010 09:32:52 -0800 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: <1263134474-sup-4605@ntdws12.chass.utoronto.ca> References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> <1263134474-sup-4605@ntdws12.chass.utoronto.ca> Message-ID: On Sun, Jan 10, 2010 at 6:42 AM, Ben Walton wrote: > > Given the issues we constantly hit with libtool, I always find myself > wondering if it was ever a benefit instead of a burden. ?Any > grey-beards care to offer some historical perspective on this? > "libtool evil". this is why our official documented guidelines are, "REMOVE .la files from your packages" !!! From hson at opencsw.org Tue Jan 12 23:13:57 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Tue, 12 Jan 2010 23:13:57 +0100 Subject: [csw-maintainers] libcairo dependency on /usr/openwin/lib/libX11.so... In-Reply-To: References: <4B49062A.9020805@opencsw.org> <4B4A7104.7090604@opencsw.org> Message-ID: <4B4CF425.5080304@opencsw.org> Philip Brown wrote: > On Sun, Jan 10, 2010 at 4:29 PM, Roger H?kansson wrote: >>> ... >> Seems I was a little bit hasty in my assessment... >> My first fix will make libcairo use /opt/csw/X11/lib/libXrender.so at link >> time, but not runtime. > > Side comment/tip: > > make sure that ALL DEPENDANCIES of libcairo, are using "our" version > of libX, etc, rather than the /usr/openwin ones. Otherwise that can > mess you up. > > Sadly, it's not enough to have the deps' version "up to date". you > also have to have them using the compatible libs for themselves. so > you might need to take over some. Correct, that's why I sent the mail regarding how to fix the problem, so other maintainers know how to solve the problem in their package. The bigger issue is that there are probably packages already out there which are linked to "our" libX while many old packages depending on the newly updated packages, don't. Since the list of packages linked to libX11.so.4 are huge, there is a ton of work to update them all. I've been thinking of this a bit and see three options. First, let the recommendation be, "EXTRA_INC, EXTRA_LIB and EXTRA_PKG_CONFIG_DIRS shouldn't be set to our X11 unless you package a package which don't have any packages depending on it". This means that it will more or less take forever before we can break the dependency on libX11.so.4. Second option is to say "ok, let whatever package breaks, break and let the maintainers for those packages repackage ASAP plus make an collective effort repackaging packages without a current mantainer". The third option is to get two new farm machines (or use build8st/build8xt) where we can start rebuilding and installing packages "from the root", i.e packages which many packages depends on. This also means we need to branch off packages in GAR to create a "X11-repackage" branch for each package. So the question is what road we should take... From jeff at cjsa.com Wed Jan 13 07:42:41 2010 From: jeff at cjsa.com (Jeffery Small) Date: Wed, 13 Jan 2010 06:42:41 GMT Subject: [csw-maintainers] dbus Message-ID: There was a problem with the dbus package that kept the service from shutting down. This would keep Solaris from haulting because it waited for the service shutdown command to return and it never did. This is with version 1.2.12,REV=2009.03.25. This has apparently been fixed. So I upgraded libdbus to 1.2.12,REV=2009.08.10 and then tried to upgrade the dbus package. However, the first thing that the upgrade processes attempts is to shutdown the current dbus service - and this operation never returns so the upgrade never executes! If, as root, I manually run the command: svcadm disable svc:/system/cswdbus this returns. But the command which is used in the dbus package: svcadm disable -t svc:/system/cswdbus hangs. Even when I have issued the first disable command, when I check: svcs svc:/system/cswdbus STATE STIME FMRI online* 22:09:08 svc:/system/cswdbus:default although when I take a look at the complete listing of services with a simple svcs command, the cswdbus service is not reported? Apparently the service is actually stopped but some bookkeeping does not get completed so svcadm and svcs are confused about the actual state of things. I tried editing the command from the uncompressed package datastream file: dbus-1.2.12,REV=2009.08.10-SunOS5.8-sparc-CSW.pkg.gz.tmp but when I rerun the upgrade command, it unpack another version from dbus-1.2.12,REV=2009.08.10-SunOS5.8-sparc-CSW.pkg.gz I tried uncompressing the master package, editing the command in the datastream and then recompressed the file, but when I run the upgrade, it must check the package checksum, see that it is off and it downloads a fresh copy of the package, overwriting all of my attempts to edit the install script. So how is someone supposed to upgrade this package? I can't be the first person attempting to upgrade this package since last August. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From maciej at opencsw.org Wed Jan 13 11:27:24 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 13 Jan 2010 10:27:24 +0000 Subject: [csw-maintainers] A new check: package file name must match the architecture in pkginfo Message-ID: I've been bitten again by the package architecture mislabeling problem: the i386 package was given a *-sparc-CSW.pkg.gz file name. To prevent the problem from happening in the future, I've added a new test to checkpkg. https://sourceforge.net/apps/trac/gar/changeset/7984 If you want your packages to be checked with it, you need to update the gar subdirectory in your subversion clients. Maciej From maciej at opencsw.org Wed Jan 13 11:37:53 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 13 Jan 2010 10:37:53 +0000 Subject: [csw-maintainers] Determining the architecture of a binary Message-ID: I'd like to write a new check, to make sure that the actual binaries inside a package match the architecture declared in the pkginfo file. Unfortunately, the file command's output is not as reliable as I'd like it to. For instance, on build8s, it can tell when a binary is i386, but it doesn't say the same about an amd64 binary. maciej at build8s [build8s]:~ > file ~maciej/src/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/solaris8-i386/install-isa-i386/opt/csw/mysql5/bin/mysql | cut -d: -f2 ELF 32-bit LSB executable 80386 Version 1, dynamically linked, stripped maciej at build8s [build8s]:~ > file ~maciej/src/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/solaris8-i386/install-isa-amd64/opt/csw/mysql5/bin/amd64/mysql | cut -d: -f2 ELF 64-bit LSB executable Version 1, dynamically linked, stripped We don't have our own, up-to-date file (or gfile), do we? Is there a better way of determining binary's architecture? (/usr/ccs/bin/dump?) Maciej From skayser at opencsw.org Wed Jan 13 12:07:54 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 13 Jan 2010 12:07:54 +0100 Subject: [csw-maintainers] Determining the architecture of a binary In-Reply-To: References: Message-ID: <20100113110754.GD18224@sebastiankayser.de> Hi Maciej, * Maciej (Matchek) Blizinski wrote: > I'd like to write a new check, to make sure that the actual binaries > inside a package match the architecture declared in the pkginfo file. > Unfortunately, the file command's output is not as reliable as I'd > like it to. For instance, on build8s, it can tell when a binary is > i386, but it doesn't say the same about an amd64 binary. > > maciej at build8s [build8s]:~ > file > ~maciej/src/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/solaris8-i386/install-isa-i386/opt/csw/mysql5/bin/mysql > | cut -d: -f2 > ELF 32-bit LSB executable 80386 Version 1, dynamically linked, stripped > maciej at build8s [build8s]:~ > file > ~maciej/src/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/solaris8-i386/install-isa-amd64/opt/csw/mysql5/bin/amd64/mysql > | cut -d: -f2 > ELF 64-bit LSB executable Version 1, dynamically linked, stripped > > We don't have our own, up-to-date file (or gfile), do we? > > Is there a better way of determining binary's architecture? (/usr/ccs/bin/dump?) great to see that you are enhancing the checks. The more we do catch upfront the better it is for all involved people (maintainer and release manager). You could have a look at the ELF header via elfdump. All outputs are from build8s. $ /usr/ccs/bin/elfdump -e ~maciej/src/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/solaris8-i386/install-isa-i386/opt/csw/mysql5/bin/mysql | grep e_machine e_machine: EM_386 e_version: EV_CURRENT $ /usr/ccs/bin/elfdump -e ~maciej/src/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/solaris8-i386/install-isa-amd64/opt/csw/mysql5/bin/amd64/mysql | grep e_machine e_machine: EM_AMD64 e_version: EV_CURRENT $ /usr/ccs/bin/elfdump -e ~maciej/src/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/solaris8-sparc/install-isa-sparcv8/opt/csw/mysql5/bin/mysql | grep e_machine e_machine: EM_SPARC e_version: EV_CURRENT $ /usr/ccs/bin/elfdump -e ~maciej/src/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/solaris8-sparc/install-isa-sparcv9/opt/csw/mysql5/bin/sparcv9/mysql | grep e_machine e_machine: EM_SPARCV9 e_version: EV_CURRENT Sebastian From james at opencsw.org Wed Jan 13 13:49:31 2010 From: james at opencsw.org (James Lee) Date: Wed, 13 Jan 2010 12:49:31 GMT Subject: [csw-maintainers] Determining the architecture of a binary In-Reply-To: References: Message-ID: <20100113.12493100.2174588176@gyor.oxdrove.co.uk> On 13/01/10, 10:37:53, Maciej "(Matchek)" Blizinski wrote regarding [csw-maintainers] Determining the architecture of a binary: > I'd like to write a new check, to make sure that the actual binaries > inside a package match the architecture declared in the pkginfo file. > Unfortunately, the file command's output is not as reliable as I'd > like it to. For instance, on build8s, it can tell when a binary is > i386, but it doesn't say the same about an amd64 binary. > maciej at build8s [build8s]:~ > file > ~maciej/src/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/solaris8-i386/i ns tall-isa-i386/opt/csw/mysql5/bin/mysql > | cut -d: -f2 > ELF 32-bit LSB executable 80386 Version 1, dynamically linked, stripped > maciej at build8s [build8s]:~ > file > ~maciej/src/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/solaris8-i386/i ns tall-isa-amd64/opt/csw/mysql5/bin/amd64/mysql > | cut -d: -f2 > ELF 64-bit LSB executable Version 1, dynamically linked, stripped "LSB" goes with i386 and "MSB" goes with sparc. I guess it stands for least and most significant bit for the endian. If it's 64 bit and not sparc then what else is it? James. From hson at opencsw.org Wed Jan 13 13:50:22 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Wed, 13 Jan 2010 13:50:22 +0100 Subject: [csw-maintainers] Determining the architecture of a binary In-Reply-To: References: Message-ID: <4B4DC18E.4040408@opencsw.org> Maciej (Matchek) Blizinski wrote: > I'd like to write a new check, to make sure that the actual binaries > inside a package match the architecture declared in the pkginfo file. > Unfortunately, the file command's output is not as reliable as I'd > like it to. For instance, on build8s, it can tell when a binary is > i386, but it doesn't say the same about an amd64 binary. As far as I know "ELF 64-bit LSB" can only be an amd64 binary, sparc binaries are all MSB. From hson at opencsw.org Wed Jan 13 13:51:20 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Wed, 13 Jan 2010 13:51:20 +0100 Subject: [csw-maintainers] Determining the architecture of a binary In-Reply-To: <20100113.12493100.2174588176@gyor.oxdrove.co.uk> References: <20100113.12493100.2174588176@gyor.oxdrove.co.uk> Message-ID: <4B4DC1C8.1050207@opencsw.org> James Lee wrote: > > "LSB" goes with i386 and "MSB" goes with sparc. I guess it stands for > least and most significant bit for the endian. Correct. From dam at opencsw.org Wed Jan 13 16:33:19 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 13 Jan 2010 16:33:19 +0100 Subject: [csw-maintainers] [csw-buildfarm] BO Buildfarm available again In-Reply-To: <20100111.15423100.2872566158@gyor.oxdrove.co.uk> References: <4610F26C-0F72-4B02-AB82-72C14942A20D@opencsw.org> <20100111.15423100.2872566158@gyor.oxdrove.co.uk> Message-ID: <3863F96D-2DD6-441B-A1FE-3BB0575193A2@opencsw.org> Hi James, Am 11.01.2010 um 16:42 schrieb James Lee: > On 08/01/10, 17:44:57, Dagobert Michelsen wrote > regarding > Re: [csw-buildfarm] [csw-maintainers] BO Buildfarm available again: > >> The T5220 is now split into two LDoms: One LDom with the existing >> Solaris 10 >> instance carrying all of the Sparc stuff which was already there (now >> restricted to 12 GB Ram and 20 Strands) and one LDom with OpenSolaris >> 06/09 Sparc still installing with 3 GB Ram and 8 Strands. > > Any reason for the restriction? Because the machine doesn't have more resources ;-) There is also a control domain with 1 GB Ram and 4 Strands which sums up to 16 GB and 32 strands total. Best regards -- Dago From dam at opencsw.org Wed Jan 13 16:42:47 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 13 Jan 2010 16:42:47 +0100 Subject: [csw-maintainers] GAR: Basic custom tests for packages In-Reply-To: References: <1256179371-sup-7948@ntdws12.chass.utoronto.ca> <242BF313-F6AA-492A-BCAE-2F4FF1498BC9@opencsw.org> Message-ID: Hi Maciej, Am 11.01.2010 um 17:56 schrieb Maciej (Matchek) Blizinski: >>>> For instance, that I expect there to be a certain file in the >>>> prototype, >>>> with such and such name and such and such attributes (ownership, >>>> permissions, etc) >> >> The prototype (if dynamic) is built during 'package' and there is >> currently >> no hook in-between after dynamic creation of the packaging source >> files >> and the package creation. You could check after package-creation in >> post-package. > > Can a hook be created between the prototype creation and the package > creation? Say, just after the creation of the per-package prototype > files, so that I can also check that certain files have landed in the > specific packages. Yes, but currently only on a per-package base as the prototype creation and packaging is done in one step, one package after another. It would be possible to installed a hook here, of course: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/gar.pkg.mk#L711 >>>> How do I access things like the prototype, or files at the location >>>> from where they're already merged? >> >> From the global modulation the prototype can be accessed as >> $(WORKDIR)/prototype >> and the package specific prototypes as >> $(WORKDIR)/CSWmypkg.prototype > > How do I know I'm in the global modulation? Just see if $(MODULATION) == "global" >> The merge location is available during global or specific >> modulations as >> $(PKGROOT). >> >> I suggest you write your test as post-package to ensure it has been >> built >> correctly. However, if it proves useful we could also insert another >> step before package creation like >> pkgverify-CSWmypkg: > > I've been recently bitten by something that would've been prevented > easily using this kind of a test, so I'll get back to it soon. Ok. Best regards -- Dago From dam at opencsw.org Wed Jan 13 16:48:35 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 13 Jan 2010 16:48:35 +0100 Subject: [csw-maintainers] libcairo dependency on /usr/openwin/lib/libX11.so... In-Reply-To: <4B4BA48F.5090703@opencsw.org> References: <4B49062A.9020805@opencsw.org> <4B4A7104.7090604@opencsw.org> <4B4BA48F.5090703@opencsw.org> Message-ID: <380ED26A-1249-4794-BDBC-B17770BDD823@opencsw.org> Hi Roger, Am 11.01.2010 um 23:22 schrieb Roger H?kansson: > Roger H?kansson wrote: >> On 2010-01-09 23:41, Roger H?kansson wrote: >>> I've committed some changes to the Makefile which fixes this >>> problem. >>> >> Seems I was a little bit hasty in my assessment... >> My first fix will make libcairo use /opt/csw/X11/lib/libXrender.so >> at link time, but not runtime. >> I've tested with a second one where made sure that -R/opt/csw/X11/ >> lib would be first in runtimepath but still, when linking librsvg >> for instance, the wrong libXrender.so will be picked. >> So as far as I can see it, in order to "fix" the problem, all >> packages which link to libXrender.so or to a another lib which link >> to libXrender.so, must make sure that /opt/csw/X11/lib before /opt/ >> csw/lib in RUNPATH and not the opposite. >> Or we just remove /opt/csw/lib/libXrender.so* which probably would >> break a ton of packages. >> For now (and until someone tells me it's a bad idea) I'll make sure >> my packages have X11/lib first in runpath > > Just to clarify, I've added (and committed) this to the Makefile for > libcairo: > EXTRA_SOS_LD_FLAGS = -L$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) > EXTRA_SOS_LD_OPTIONS = -R$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) > > This will give us a libcairo.so with /opt/csw/X11/lib first in > RUNPATH. > > Then the packages using libcairo only need to have -L/opt/csw/X11/lib > first during build (i.e same setting as libcairo for > EXTRA_SOS_LD_FLAGS, but not EXTRA_SOS_LD_OPTIONS) > Runtime everything seems to be ok (on my build machines where I've > built > and reinstalled packages as I built them) using these options. But > that's only my quick observations. I guess it would be generally helpful to put EXTRA libraries in front of the standard path at /opt/csw/lib as opposed to appending it. Best regards -- Dago From dam at opencsw.org Wed Jan 13 17:37:59 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 13 Jan 2010 17:37:59 +0100 Subject: [csw-maintainers] GAR: Category-level post-merge target In-Reply-To: References: Message-ID: <46DC478A-8525-4400-8382-850A9F498F74@opencsw.org> Hi Maciej, Am 12.01.2010 um 15:37 schrieb Maciej (Matchek) Blizinski: > Is it possible to add a category-level post-merge target? I would > like there to be a post-merge target that is executed with my custom > category, but I would like the individual packages to have separate > post-merge targets. Is there such target already, or if not, can I > create it in GAR? Say, category-post-merge? I guess I don't understand what you mean "by category". From my understanding the category is defined in CATEGORY and controls some file to include for category-specific behaviour. That means there is no such thing as a "category phase" like there is a phase for extract, patch, configure, etc. Or do you mean a harcoded _post-merge-category target which is always called can can be overwritten inside a category? This is easily doable if you need it. Best regards -- Dago From dam at opencsw.org Wed Jan 13 17:39:33 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 13 Jan 2010 17:39:33 +0100 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> <1263134474-sup-4605@ntdws12.chass.utoronto.ca> Message-ID: Hi Phil, Am 12.01.2010 um 18:32 schrieb Philip Brown: > On Sun, Jan 10, 2010 at 6:42 AM, Ben Walton > wrote: >> >> Given the issues we constantly hit with libtool, I always find myself >> wondering if it was ever a benefit instead of a burden. Any >> grey-beards care to offer some historical perspective on this? > > "libtool evil". > > this is why our official documented guidelines are, > "REMOVE .la files from your packages" !!! He he, and just now I get a bug report for a package that doesn't work without the .la-files: Best regards -- Dago From dam at opencsw.org Wed Jan 13 17:45:31 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 13 Jan 2010 17:45:31 +0100 Subject: [csw-maintainers] dbus In-Reply-To: References: Message-ID: Hi Jeff, Am 13.01.2010 um 07:42 schrieb Jeffery Small: > There was a problem with the dbus package that kept the service from > shutting > down. ... > So how is someone supposed to upgrade this package? I can't be the > first > person attempting to upgrade this package since last August. This was announced together with the updated package on users@ in September: Am 03.09.2009 um 23:01 schrieb William Bonnet: > Hi, > > A new version of the dbus packages will be pushed to current catalog > in the next hours. This version fixes the fllowing bug > > 0003626: dbus daemon will not stop on reboot/init 6 blocking the > shutdown ( http://opencsw.org/bugtrack/view.php?id=3626 ). > > > This bugs prevents dbus from stop correctly. If dbus is running, it > will be stop during update, thus update may freeze. In order to > avoid this situation, you have to be sure that you don't have dbus > running, or if it is running, you will have to kill it by hand > before the upgrade. You can retrieve the pid to kill with the > following command : > > bash-3.00# cat /opt/csw/var/run/dbus/pid > 1592 > > or > > bash-3.00# ps -elf | grep dbus-daemon > 0 S messageb 1592 1 0 40 20 ? 634 ? > 22:55:25 ? 0:00 /opt/csw/bin/dbus-daemon --system > > Please "kill -9" the dbus process before running package upgrade. > > Kind regards > W. > > -- > William http://www.wbonnet.net > > http://www.sunwizard.net Le site fran?ais des amateurs de stations > Unix > http://www.opencsw.org Community SoftWare for Solaris > http://www.guses.org French speaking Solaris User Group > > > _______________________________________________ > users mailing list > users at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/users Hope this helps. Best regards -- Dago From hson at opencsw.org Wed Jan 13 17:46:05 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Wed, 13 Jan 2010 17:46:05 +0100 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> <1263134474-sup-4605@ntdws12.chass.utoronto.ca> Message-ID: <4B4DF8CD.5040500@opencsw.org> Dagobert Michelsen wrote: > Hi Phil, > > Am 12.01.2010 um 18:32 schrieb Philip Brown: >> On Sun, Jan 10, 2010 at 6:42 AM, Ben Walton wrote: >>> >>> Given the issues we constantly hit with libtool, I always find myself >>> wondering if it was ever a benefit instead of a burden. Any >>> grey-beards care to offer some historical perspective on this? >> >> "libtool evil". >> >> this is why our official documented guidelines are, >> "REMOVE .la files from your packages" !!! > > He he, and just now I get a bug report for a package that doesn't work > without the .la-files: > Same as ImageMagick, they use libtool runtime to load internal modules. So MERGE_EXCLUDE_LIBTOOL need to be set to MERGE_EXCLUDE_LIBTOOL ?= $(libdir)/lib.*\.la instead of MERGE_EXCLUDE_LIBTOOL ?= $(libdir)/.*\.la From hson at opencsw.org Wed Jan 13 17:51:48 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Wed, 13 Jan 2010 17:51:48 +0100 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: <4B4DF8CD.5040500@opencsw.org> References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> <1263134474-sup-4605@ntdws12.chass.utoronto.ca> <4B4DF8CD.5040500@opencsw.org> Message-ID: <4B4DFA24.5040601@opencsw.org> Roger H?kansson wrote: > Dagobert Michelsen wrote: >> Hi Phil, >> >> Am 12.01.2010 um 18:32 schrieb Philip Brown: >>> On Sun, Jan 10, 2010 at 6:42 AM, Ben Walton wrote: >>>> >>>> Given the issues we constantly hit with libtool, I always find myself >>>> wondering if it was ever a benefit instead of a burden. Any >>>> grey-beards care to offer some historical perspective on this? >>> >>> "libtool evil". >>> >>> this is why our official documented guidelines are, >>> "REMOVE .la files from your packages" !!! >> >> He he, and just now I get a bug report for a package that doesn't work >> without the .la-files: >> > > Same as ImageMagick, they use libtool runtime to load internal modules. > So MERGE_EXCLUDE_LIBTOOL need to be set to > MERGE_EXCLUDE_LIBTOOL ?= $(libdir)/lib.*\.la instead of > MERGE_EXCLUDE_LIBTOOL ?= $(libdir)/.*\.la Note: Thats not a general solution, packages with 64-bit libs or packages which have libraries in other places need to have MERGE_EXCLUDE_LIBTOOL properly set. "MERGE_EXCLUDE_LIBTOOL ?= $(libdir).*/lib.*\.la" might be a more general solution From maciej at opencsw.org Wed Jan 13 17:53:00 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 13 Jan 2010 16:53:00 +0000 Subject: [csw-maintainers] GAR: Category-level post-merge target In-Reply-To: <46DC478A-8525-4400-8382-850A9F498F74@opencsw.org> References: <46DC478A-8525-4400-8382-850A9F498F74@opencsw.org> Message-ID: On Wed, Jan 13, 2010 at 4:37 PM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 12.01.2010 um 15:37 schrieb Maciej (Matchek) Blizinski: >> >> Is it possible to add a category-level post-merge target? I would >> like there to be a post-merge target that is executed with my custom >> category, but I would like the individual packages to have separate >> post-merge targets. ?Is there such target already, or if not, can I >> create it in GAR? ?Say, category-post-merge? > > I guess I don't understand what you mean "by category". From my > understanding the category is defined in CATEGORY and controls > some file to include for category-specific behaviour. That means > there is no such thing as a "category phase" like there is a > phase for extract, patch, configure, etc. > > Or do you mean a harcoded _post-merge-category target which is > always called can can be overwritten inside a category? This > is easily doable if you need it. Yes, that's what I meant. Something like the currently existing category-level depends, used by the python class. From dam at opencsw.org Wed Jan 13 18:00:12 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 13 Jan 2010 18:00:12 +0100 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: <4B4DFA24.5040601@opencsw.org> References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> <1263134474-sup-4605@ntdws12.chass.utoronto.ca> <4B4DF8CD.5040500@opencsw.org> <4B4DFA24.5040601@opencsw.org> Message-ID: Hi Roger, Am 13.01.2010 um 17:51 schrieb Roger H?kansson: > Roger H?kansson wrote: >> Dagobert Michelsen wrote: >>> Hi Phil, >>> >>> Am 12.01.2010 um 18:32 schrieb Philip Brown: >>>> On Sun, Jan 10, 2010 at 6:42 AM, Ben Walton >>>> wrote: >>>>> >>>>> Given the issues we constantly hit with libtool, I always find >>>>> myself >>>>> wondering if it was ever a benefit instead of a burden. Any >>>>> grey-beards care to offer some historical perspective on this? >>>> >>>> "libtool evil". >>>> >>>> this is why our official documented guidelines are, >>>> "REMOVE .la files from your packages" !!! >>> >>> He he, and just now I get a bug report for a package that doesn't >>> work >>> without the .la-files: >>> >> Same as ImageMagick, they use libtool runtime to load internal >> modules. >> So MERGE_EXCLUDE_LIBTOOL need to be set to >> MERGE_EXCLUDE_LIBTOOL ?= $(libdir)/lib.*\.la instead of >> MERGE_EXCLUDE_LIBTOOL ?= $(libdir)/.*\.la > > Note: Thats not a general solution, packages with 64-bit libs or > packages which have libraries in other places need to have > MERGE_EXCLUDE_LIBTOOL properly set. > > "MERGE_EXCLUDE_LIBTOOL ?= $(libdir).*/lib.*\.la" might be a more > general solution I would like to keep the general solution of excluding all libtool-files and let the maintainer decide this on a case-by-case basis. Including .la-files should be the exception. Best regards -- Dago From hson at opencsw.org Wed Jan 13 18:03:13 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Wed, 13 Jan 2010 18:03:13 +0100 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> <1263134474-sup-4605@ntdws12.chass.utoronto.ca> <4B4DF8CD.5040500@opencsw.org> <4B4DFA24.5040601@opencsw.org> Message-ID: <4B4DFCD1.40303@opencsw.org> Dagobert Michelsen wrote: > Hi Roger, > > Am 13.01.2010 um 17:51 schrieb Roger H?kansson: > >> Roger H?kansson wrote: >>> Dagobert Michelsen wrote: >>>> Hi Phil, >>>> >>>> Am 12.01.2010 um 18:32 schrieb Philip Brown: >>>>> On Sun, Jan 10, 2010 at 6:42 AM, Ben Walton >>>>> wrote: >>>>>> >>>>>> Given the issues we constantly hit with libtool, I always find myself >>>>>> wondering if it was ever a benefit instead of a burden. Any >>>>>> grey-beards care to offer some historical perspective on this? >>>>> >>>>> "libtool evil". >>>>> >>>>> this is why our official documented guidelines are, >>>>> "REMOVE .la files from your packages" !!! >>>> >>>> He he, and just now I get a bug report for a package that doesn't work >>>> without the .la-files: >>>> >>> Same as ImageMagick, they use libtool runtime to load internal modules. >>> So MERGE_EXCLUDE_LIBTOOL need to be set to >>> MERGE_EXCLUDE_LIBTOOL ?= $(libdir)/lib.*\.la instead of >>> MERGE_EXCLUDE_LIBTOOL ?= $(libdir)/.*\.la >> >> Note: Thats not a general solution, packages with 64-bit libs or >> packages which have libraries in other places need to have >> MERGE_EXCLUDE_LIBTOOL properly set. >> >> "MERGE_EXCLUDE_LIBTOOL ?= $(libdir).*/lib.*\.la" might be a more >> general solution > > I would like to keep the general solution of excluding all libtool-files > and let the maintainer decide this on a case-by-case basis. Including > .la-files should be the exception. > Correct, with "general solution", I meant "starting point solution for those cases that need to keep some .la-files" There are only a few cases where .la-files need to be kept in the package. From hson at opencsw.org Wed Jan 13 18:10:39 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Wed, 13 Jan 2010 18:10:39 +0100 Subject: [csw-maintainers] BUILD64 Message-ID: <4B4DFE8F.80201@opencsw.org> Some info someone else might find usable... According to "GAR Variable Reference", BUILD64 should be set to 1 to build 64-bit targets, but actually the current GAR code doesn't care what you set it to, just that its set. If you check out something that has BUILD64=1 set and want to build a 32-bit-only package, I couldn't find any way except edit the Makefile before building. So I patched my local gar.conf.mk to fix this. "$if( $(BUILD64)...." is changed to "$if( eq($(BUILD64),1)...." With that change, setting "BUILD64=0" in ~/.garrc or prepending before gmake, will let you build a 32-bit-only package. (my personal x86-build server isn't 64-bit ready so I can only run Solaris8 and Solaris10 in 32-bit-mode) From jeff at cjsa.com Wed Jan 13 20:57:36 2010 From: jeff at cjsa.com (Jeffery Small) Date: Wed, 13 Jan 2010 19:57:36 GMT Subject: [csw-maintainers] dbus References: Message-ID: Dagobert Michelsen writes: >This was announced together with the updated package on users@ >in September: >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 [...] Thanks Dagobert. I'm sorry that I missed the announcement back in September. I followed the procedures and did get the updated package installed. I really appreciate the quick response. Two comments: 1) It would be good to get the news section for packages up and running so that information like this could be used to list important information like this. 2) Is there some reason that the test for the bad installed version of dbus was not performed by the package's install script and then have the script automatically check for a running process and kill it as part of the upgrade procedure, rather than force the user to perform a manual intervention? I ask this as a general question regarding all packages that might require a non-standard form of intervention during installation. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From skayser at opencsw.org Wed Jan 13 21:13:33 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 13 Jan 2010 21:13:33 +0100 Subject: [csw-maintainers] dbus In-Reply-To: References: Message-ID: <4B4E296D.9030708@opencsw.org> Jeffery Small wrote on 13.01.2010 20:57: > Dagobert Michelsen writes: > >> This was announced together with the updated package on users@ >> in September: > >> 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 [...] > > Thanks Dagobert. > > I'm sorry that I missed the announcement back in September. I followed the > procedures and did get the updated package installed. I really appreciate > the quick response. Two comments: > > 1) It would be good to get the news section for packages up and running so > that information like this could be used to list important information like > this. +1 The NEWS link on www.opencsw.org/packages/ points to the Mantis news page for a package. Each maintainer should be able to populate this section for his packages already. That's where important news about that package could go. Nothing fancy, but better than it is right now. What I also really would like to see is a changelog.CSW shipped with each package which is somehow hooked into the release process. The NEWS section could then be automatically updated. I just had a troubleshooting session with someone who updated amavisd-new and from the package side it took me some time of distilling the important items in the GAR logs to see what had changed. That's where the NEWS would have been helpful also. > 2) Is there some reason that the test for the bad installed version of > dbus was not performed by the package's install script and then have the > script automatically check for a running process and kill it as part of > the upgrade procedure, rather than force the user to perform a manual > intervention? I ask this as a general question regarding all packages that > might require a non-standard form of intervention during installation. The bad dbus package was already installed and in my case it was the uninstallation that hung. Nothing that the new package could have dealt with, or? Sebastian From skayser at opencsw.org Wed Jan 13 22:59:02 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 13 Jan 2010 22:59:02 +0100 Subject: [csw-maintainers] CSW packaged MTAs and /usr (continued from "CSWcswclassutils: it wants to write in /usr") Message-ID: <4B4E4226.40600@opencsw.org> Greetings, as our postfix packages needs some makeover, there is something I took away from the discussion about cswclassutils and /usr [1] which relates to our MTAs in general: #1 Automatically messing with system binaries is considered evil. (e.g. /usr/lib/sendmail, /usr/bin/mailq, and /usr/sbin/newaliases) #2 A CSW MTA that doesn't replace /usr/lib/sendmail isn't really integrated with the system (i.e. not guaranteed to catch all mail originating from the system) Currently the postfix package automatically tries to move away the system binaries and to link its own binaries into place. While this tries to fully integrate with the system, it violates rule #1. There are also a couple of bugs open against the package where this procedure fails in sparse zone enviroments [2]. With an updated postfix package I would like to make the package as simple as possible and leave control to the user. Therefor I would like to emit a notification message on package installation, either pointing the user to a README.CSW, a script, an additional integration package, or simply to echo commands that one can issue to integrate postfix with the system. Now I am wondering what these commands should do. Should they mimic the current behavior of mv .OFF && ln or would it rather be preferable to say pkgrm && ln I am specifically thinking about the latter option because of Solaris patches. What would happen if we left the system sendmail packages in place and simply moved away the binaries? Wouldn't a sendmail patch notice the installed sendmail package and overwrite our link with possibly patched binaries? Granted, pkgrm wouldn't make it easy for a user to revert back to system sendmail .. just trying to get a feeling for the different approaches. Feedback very welcome! Sebastian [1] http://thread.gmane.org/gmane.os.solaris.opencsw.maintainers/4955 [2] http://www.opencsw.org/mantis/set_project.php?project_id=147 From skayser at opencsw.org Thu Jan 14 00:02:27 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 14 Jan 2010 00:02:27 +0100 Subject: [csw-maintainers] dbus In-Reply-To: <4B4E296D.9030708@opencsw.org> References: <4B4E296D.9030708@opencsw.org> Message-ID: <4B4E5103.1010704@opencsw.org> Sebastian Kayser wrote on 13.01.2010 21:13: > Jeffery Small wrote on 13.01.2010 20:57: >> Dagobert Michelsen writes: >> >>> This was announced together with the updated package on users@ >>> in September: >>> 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 [...] >> Thanks Dagobert. >> >> I'm sorry that I missed the announcement back in September. I followed the >> procedures and did get the updated package installed. I really appreciate >> the quick response. Two comments: >> >> 1) It would be good to get the news section for packages up and running so >> that information like this could be used to list important information like >> this. > > +1 > > The NEWS link on www.opencsw.org/packages/ points to the Mantis > news page for a package. Each maintainer should be able to populate this > section for his packages already. That's where important news about that > package could go. Nothing fancy, but better than it is right now. Sorry, seems as if I was a bit hasty. While you should be able to populate the NEWS for each of your packages in the bug tracker (and view these news via "Main" after selecting one package in the drop down list to the upper right), the links from the individual package pages on opencsw.org/packages/ don't seem to be working yet (as the notes next to the links obviously point out). Will need to give it some thought and will post an update once I have done so (probably in about a week - during winter camp). Sebastian From bwalton at opencsw.org Thu Jan 14 00:41:46 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 13 Jan 2010 18:41:46 -0500 Subject: [csw-maintainers] CSW packaged MTAs and /usr (continued from "CSWcswclassutils: it wants to write in /usr") In-Reply-To: <4B4E4226.40600@opencsw.org> References: <4B4E4226.40600@opencsw.org> Message-ID: <1263425934-sup-3926@ntdws12.chass.utoronto.ca> Excerpts from Sebastian Kayser's message of Wed Jan 13 16:59:02 -0500 2010: > or would it rather be preferable to say > > pkgrm && ln This should be: ... && ln -s since the binaries won't be delivered to /usr. I personally still think this stinks (I use exim, but it's the same pita)...anyway, like many other things on solaris, I'll continue to hit them with my cfengine hammer. > I am specifically thinking about the latter option because of Solaris > patches. What would happen if we left the system sendmail packages in > place and simply moved away the binaries? Wouldn't a sendmail patch > notice the installed sendmail package and overwrite our link with > possibly patched binaries? Granted, pkgrm wouldn't make it easy for a Yes, the package tools would overwrite the link and restore the system sendmail. There is a setting that can be toggled to prevent this...I'd have to look it up as I'm not sure what it is off the top of my head. Since we need to live with these unfortunate rules, I think your approach of simplifying the package and providing 'guidelines' via README.CSW is the best option. 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. From bwalton at opencsw.org Thu Jan 14 01:36:44 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 13 Jan 2010 19:36:44 -0500 Subject: [csw-maintainers] new mailing list? Message-ID: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> Hi All, I'd like to propose a new, internal-only mailing list. The purpose of the list would be to record all package release requests. This would replace the current practice of private mails to Phil. This list would be open to posting from any @opencsw.org address, but would be subscribed on request by maintainers as desired, not automatically. There are a few reasons I'd like to see this happen: 1. Packages that are rejected are typically rejected for common reasons. The more people the see these, the better we'll get over time as we stop making the same mistakes. 2. History preservation. 3. Team maintainership memory. Presently, if mails are private between $release_manager and $maintainer, a $maintainer2 may not know why a package is not being released. A list archive could resolve this. This follows from #2. 4. More visible maintainer activity. This is an easy way to keep an eye on who's releasing what. This info can be gotten other ways of course, but this is a more passive approach to seeing the same info. 5. Openness. It pulls back the curtains a bit more on some of the backend happenings. Thoughts from others? 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 skayser at opencsw.org Thu Jan 14 02:45:42 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 14 Jan 2010 02:45:42 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> Message-ID: <4B4E7746.4030605@opencsw.org> Ben Walton wrote on 14.01.2010 01:36: > I'd like to propose a new, internal-only mailing list. The purpose of > the list would be to record all package release requests. This would > replace the current practice of private mails to Phil. This list > would be open to posting from any @opencsw.org address, but would be > subscribed on request by maintainers as desired, not automatically. > > There are a few reasons I'd like to see this happen: Sounds good. > 1. Packages that are rejected are typically rejected for common > reasons. The more people the see these, the better we'll get over > time as we stop making the same mistakes. And Maciej can keep updating checkpkg to implement checks for those common reasons (at least those that can be determined via a script). ;) Sweet! > 2. History preservation. > 3. Team maintainership memory. Presently, if mails are private > between $release_manager and $maintainer, a $maintainer2 may not > know why a package is not being released. A list archive could > resolve this. This follows from #2. That's a good one. I remember Benny and Mike tag teaming sendmail (lot of impetus behind it). Benny started the build recipe, Mike wanted to do the final touchings and then release the package. In fact, Mike committed quite some changes to the build recipe, but when he vanished into sabbatical shortly after, the package wasn't released and Benny didn't know a thing about the current state (had it been submitted for release? were there any remaining problems with it?). The impetus was pretty much lost from what I could tell from his face. If it was for a release mailing list, he could have at least quickly seen whether the package was already considered for release (and learn about potential release critical issues that he would have needed to take care of). Even if he would have seen that the package hadn't even been submitted he would have known right away that he could just pick up from the existing build recipe. IMHO makes things easier compared to pinging phil (or any release manager for that matter) via email and waiting for the timezones to shift in the right place for a reply. Easier for both parties. > 5. Openness. It pulls back the curtains a bit more on some of the > backend happenings. Openness/transparency is always good (unless you are in the secret service business of course ;) ). That's btw. one reason why I will be trying hard to publish on-time news during winter camp this time (plus some sort of "video conferencing" test-setup), so that all those who can't make it, can get a better feeling of what is happening behind those "winter camp curtains" :) Sebastian From skayser at opencsw.org Thu Jan 14 03:03:11 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 14 Jan 2010 03:03:11 +0100 Subject: [csw-maintainers] CSW packaged MTAs and /usr (continued from "CSWcswclassutils: it wants to write in /usr") In-Reply-To: <1263425934-sup-3926@ntdws12.chass.utoronto.ca> References: <4B4E4226.40600@opencsw.org> <1263425934-sup-3926@ntdws12.chass.utoronto.ca> Message-ID: <4B4E7B5F.4020105@opencsw.org> Ben Walton wrote on 14.01.2010 00:41: > Excerpts from Sebastian Kayser's message of Wed Jan 13 16:59:02 -0500 2010: >> or would it rather be preferable to say >> >> pkgrm && ln > > This should be: > > ... && ln -s > > since the binaries won't be delivered to /usr. I personally still > think this stinks (I use exim, but it's the same pita)...anyway, like > many other things on solaris, I'll continue to hit them with my > cfengine hammer. As with the similar discussion about cups, system integration could also be handled by an optional "integration package". For starters, my main focus is to produce a simplified and updated postfix package. >> I am specifically thinking about the latter option because of Solaris >> patches. What would happen if we left the system sendmail packages in >> place and simply moved away the binaries? Wouldn't a sendmail patch >> notice the installed sendmail package and overwrite our link with >> possibly patched binaries? Granted, pkgrm wouldn't make it easy for a > > Yes, the package tools would overwrite the link and restore the system > sendmail. There is a setting that can be toggled to prevent > this...I'd have to look it up as I'm not sure what it is off the top > of my head. If such an option exists, that would help alot. Than we could simply say "move old binaries away, symlink our binaries, and set this option". Provides an easy rollback option to system sendmail, though users would need to make sure to re-apply patches which they might have missed in the meantime. > Since we need to live with these unfortunate rules, I think your > approach of simplifying the package and providing 'guidelines' via > README.CSW is the best option. Thanks for the feedback, Ben. Sebastian From skayser at opencsw.org Thu Jan 14 04:16:45 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 14 Jan 2010 04:16:45 +0100 Subject: [csw-maintainers] GAR: Changes to checkpkg: shared libraries and modularity In-Reply-To: References: Message-ID: <4B4E8C9D.2030904@opencsw.org> Hi Maciej, Maciej (Matchek) Blizinski wrote on 04.01.2010 16:43: > The v2-checkpkg branch has been merged to v2 today. It means that the > new shared library checking code is now live. The next time you > update your GAR sources, the new code will be pulled in. > > [...] > > If you have any questions, I'll be happy to answer them. checkpkg-libs.py seems to have troubles picking up some libs. libdb-4.2.so is in /opt/csw/bdb42/lib and libpq.so.5 is in /opt/csw/postgresql/lib. Excerpt of the results from running checkpkg on a postfix package: ~skayser/pkgs/postfix-2.6.2\,REV\=2010.01.14-SunOS5.8-sparc-UNCOMMITTED.pkg.gz Analysis of sonames needed by the package set: ... libdb-4.2.so is required by set(['spawn', 'postmulti', 'postkick', 'postlog', 'postconf', 'bounce', 'qmqpd', 'nqmgr', 'flush', 'proxymap', 'scache', 'anvil', 'verify', 'postalias', 'postcat', 'virtual', 'pickup', 'oqmgr', 'master', 'postqueue', 'postmap', 'local', 'showq', 'sendmail', 'smtpd', 'lmtp', 'postdrop', 'trivial-rewrite', 'postfix', 'postlock', 'pipe', 'tlsmgr', 'error', 'discard', 'postsuper', 'cleanup']), but we don't know what provides it. ... libpq.so.5 is required by set(['spawn', 'postmulti', 'postkick', 'postlog', 'postconf', 'bounce', 'qmqpd', 'nqmgr', 'flush', 'proxymap', 'scache', 'anvil', 'verify', 'postalias', 'postcat', 'virtual', 'pickup', 'oqmgr', 'master', 'postqueue', 'postmap', 'local', 'showq', 'sendmail', 'smtpd', 'lmtp', 'postdrop', 'trivial-rewrite', 'postfix', 'postlock', 'pipe', 'tlsmgr', 'error', 'discard', 'postsuper', 'cleanup']), but we don't know what provides it. ... CSWpostfix: SUGGESTION: you may want to add some or all of the following as depends: (Feel free to ignore SUNW or SPRO packages) > SUNWcslx The following packages might be unnecessary dependencies: ? CSWbdb4 ? CSWlibpq The following sonames don't belong to any package: ! libdb-4.2.so ! libpq.so.5 Traceback (most recent call last): File "gar/bin/checkpkg.d/checkpkg-libs.py", line 206, in main() File "gar/bin/checkpkg.d/checkpkg-libs.py", line 195, in main "any package: %s" % checker.soname)) AttributeError: 'CheckpkgBase' object has no attribute 'soname' LOG END: /var/tmp/dissect.22044/checkpkg-libs.py.log ERROR: One or more tests have failed. gmake: *** [pkgcheck] Error 2 Observed on build8s. Besides tweaking the lib detection, could you fix/catch the error? And maybe get rid of the surrounding set() in the error messages (re-format the output to match its appearance to the regular "libfoo is required by" output?)? Sebastian From bonivart at opencsw.org Thu Jan 14 10:04:30 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 14 Jan 2010 10:04:30 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> Message-ID: <625385e31001140104u61ac1128g3bac618b544a960e@mail.gmail.com> On Thu, Jan 14, 2010 at 1:36 AM, Ben Walton wrote: > > Hi All, > > I'd like to propose a new, internal-only mailing list. ?The purpose of > the list would be to record all package release requests. ?This would > replace the current practice of private mails to Phil. ?This list > would be open to posting from any @opencsw.org address, but would be > subscribed on request by maintainers as desired, not automatically. +1 -- /peter From maciej at opencsw.org Thu Jan 14 12:11:11 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 14 Jan 2010 11:11:11 +0000 Subject: [csw-maintainers] GAR: Changes to checkpkg: shared libraries and modularity In-Reply-To: <4B4E8C9D.2030904@opencsw.org> References: <4B4E8C9D.2030904@opencsw.org> Message-ID: On Thu, Jan 14, 2010 at 3:16 AM, Sebastian Kayser wrote: > Hi Maciej, > > Maciej (Matchek) Blizinski wrote on 04.01.2010 16:43: >> The v2-checkpkg branch has been merged to v2 today. ?It means that the >> new shared library checking code is now live. ?The next time you >> update your GAR sources, the new code will be pulled in. >> >> [...] >> >> If you have any questions, I'll be happy to answer them. > > checkpkg-libs.py seems to have troubles picking up some libs. > libdb-4.2.so is in /opt/csw/bdb42/lib and libpq.so.5 is in > /opt/csw/postgresql/lib. > > Excerpt of the results from running checkpkg on a postfix package: > ~skayser/pkgs/postfix-2.6.2\,REV\=2010.01.14-SunOS5.8-sparc-UNCOMMITTED.pkg.gz Thanks for the path, I could reproduce the issue. > CSWpostfix: > SUGGESTION: you may want to add some or all of the following as depends: > ? (Feel free to ignore SUNW or SPRO packages) >> SUNWcslx > The following packages might be unnecessary dependencies: > ? CSWbdb4 > ? CSWlibpq > The following sonames don't belong to any package: > ! libdb-4.2.so > ! libpq.so.5 There were two problems. One was that '/opt/csw/postgresql/lib/' != '/opt/csw/postgresql/lib'. I added code to handle trailing slashes (and double slashes too). The RPATH of postgresql binaries was: 'runpath': ['/opt/csw/lib/$ISALIST', '/opt/csw/lib', '/opt/csw/bdb4/lib', '/opt/csw/mysql5/lib/mysql', '/opt/csw/postgresql/lib/', /* <-- the problem! */ '/usr/lib/$ISALIST', '/usr/lib', '/lib/$ISALIST', '/lib'] The second problem was that my code did not know about the symlink from /opt/csw/bdb4 to /opt/csw/bdb42. For now, there's a relatively dumb code which substitutes paths like this one. I didn't go for reimplementing the complete symlink handling. Here's the change: https://sourceforge.net/apps/trac/gar/changeset/7999 The new output is as expected: CSWpostfix: SUGGESTION: you may want to add some or all of the following as depends: (Feel free to ignore SUNW or SPRO packages) > CSWbdb42 > SUNWcslx The following packages might be unnecessary dependencies: ? CSWbdb4 > Traceback (most recent call last): > ?File "gar/bin/checkpkg.d/checkpkg-libs.py", line 206, in > ? ?main() > ?File "gar/bin/checkpkg.d/checkpkg-libs.py", line 195, in main > ? ?"any package: %s" % checker.soname)) > AttributeError: 'CheckpkgBase' object has no attribute 'soname' > > LOG END: /var/tmp/dissect.22044/checkpkg-libs.py.log > > ERROR: One or more tests have failed. > gmake: *** [pkgcheck] Error 2 > > > > Observed on build8s. Besides tweaking the lib detection, could you > fix/catch the error? Fixed. > And maybe get rid of the surrounding set() in > the error messages (re-format the output to match its appearance > to the regular "libfoo is required by" output?)? Yup, good idea, but I'm putting in on the todo stack for now. From hson at opencsw.org Thu Jan 14 13:55:00 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Thu, 14 Jan 2010 13:55:00 +0100 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> <1262725258-sup-3515@ntdws12.chass.utoronto.ca> <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> Message-ID: <4B4F1424.2080109@opencsw.org> Dagobert Michelsen wrote: > Hi Ben, > > Am 05.01.2010 um 22:01 schrieb Ben Walton: >> Excerpts from Dagobert Michelsen's message of Tue Jan 05 15:56:02 -0500 2010: >> >>> be needed. Thoughts? >> 10 only. If the devs aren't interested in older platforms and you >> have no personal need, why go through the headache? > > The question is: Do we want to release it and make separate releases > of packages for Solaris 8/9 vs. 10 which require it? > libproxy is a requirement for some gnome-packages which would mean that we can't upgrade upgrade them without libproxy, and since some of those packages have dependencies on other packages which might get upgraded we would soon end up with a lot of Solaris8-packages which doesn't work. From james at opencsw.org Thu Jan 14 15:05:21 2010 From: james at opencsw.org (James Lee) Date: Thu, 14 Jan 2010 14:05:21 GMT Subject: [csw-maintainers] [csw-buildfarm] BO Buildfarm available again In-Reply-To: <3863F96D-2DD6-441B-A1FE-3BB0575193A2@opencsw.org> References: <4610F26C-0F72-4B02-AB82-72C14942A20D@opencsw.org> <20100111.15423100.2872566158@gyor.oxdrove.co.uk> <3863F96D-2DD6-441B-A1FE-3BB0575193A2@opencsw.org> Message-ID: <20100114.14052100.2348471893@gyor.oxdrove.co.uk> On 13/01/10, 15:33:19, Dagobert Michelsen wrote regarding Re: [csw-maintainers] [csw-buildfarm] BO Buildfarm available again: > >> The T5220 is now split into two LDoms: One LDom with the existing > >> Solaris 10 > >> instance carrying all of the Sparc stuff which was already there (now > >> restricted to 12 GB Ram and 20 Strands) and one LDom with OpenSolaris > >> 06/09 Sparc still installing with 3 GB Ram and 8 Strands. > > > > Any reason for the restriction? > Because the machine doesn't have more resources ;-) Excuse me the machine does, prior to enhancement each virtual machine had 60% more available CPUs. > There is also > a control domain with 1 GB Ram and 4 Strands which sums up to > 16 GB and 32 strands total. Ah yes so LDOMs are restrictive. Sorry I've only read the marketing bumph which suggests resources are shared. That is on the misleading side of truthful as there is no dynamic sharing of CPU and memory. Where load is sporadic as for build hard partitioning is a waste of a good machine. James. From pfelecan at opencsw.org Thu Jan 14 15:47:42 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 14 Jan 2010 15:47:42 +0100 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: (Philip Brown's message of "Tue, 12 Jan 2010 09:32:52 -0800") References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> <1263134474-sup-4605@ntdws12.chass.utoronto.ca> Message-ID: Philip Brown writes: > On Sun, Jan 10, 2010 at 6:42 AM, Ben Walton wrote: >> >> Given the issues we constantly hit with libtool, I always find myself >> wondering if it was ever a benefit instead of a burden. ?Any >> grey-beards care to offer some historical perspective on this? >> > > "libtool evil". saying that, is evil. -- Peter From pfelecan at opencsw.org Thu Jan 14 15:49:27 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 14 Jan 2010 15:49:27 +0100 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: <4B4DFCD1.40303@opencsw.org> ("Roger =?iso-8859-1?Q?H=E5kanss?= =?iso-8859-1?Q?on=22's?= message of "Wed, 13 Jan 2010 18:03:13 +0100") References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> <1263134474-sup-4605@ntdws12.chass.utoronto.ca> <4B4DF8CD.5040500@opencsw.org> <4B4DFA24.5040601@opencsw.org> <4B4DFCD1.40303@opencsw.org> Message-ID: Roger H?kansson writes: >> Dagobert Michelsen wrote: >> I would like to keep the general solution of excluding all libtool-files >> and let the maintainer decide this on a case-by-case basis. Including >> .la-files should be the exception. >> > > Correct, with "general solution", I meant "starting point solution for > those cases that need to keep some .la-files" > There are only a few cases where .la-files need to be kept in the package. and for those cases it's a real PITA to convince the gate keeper of the day. -- Peter From pfelecan at opencsw.org Thu Jan 14 16:10:53 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 14 Jan 2010 16:10:53 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> (Ben Walton's message of "Wed, 13 Jan 2010 19:36:44 -0500") References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> Message-ID: Ben Walton writes: > Hi All, > > I'd like to propose a new, internal-only mailing list. The purpose of > the list would be to record all package release requests. [...] > Thoughts from others? completely supporting this proposal. therefore: +INF -- Peter From maciej at opencsw.org Thu Jan 14 19:15:32 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 14 Jan 2010 18:15:32 +0000 Subject: [csw-maintainers] GAR and isaexec: merging to $ISA subdirs doesn't work In-Reply-To: <4B450899.5030501@opencsw.org> References: <4B44701E.1070100@opencsw.org> <080DF858-63AB-4867-9B3F-3ABA7A43E645@opencsw.org> <4B450899.5030501@opencsw.org> Message-ID: On Wed, Jan 6, 2010 at 10:03 PM, Sebastian Kayser wrote: > Hi Dago, > > Dagobert Michelsen wrote on 06.01.2010 22:36: >> Am 06.01.2010 um 12:12 schrieb Sebastian Kayser: >>> I just removed NO_ISAEXEC=1 from the mbuffer package to make it a >>> regular 32-/64-bit package with isaexec as a wrapper. The resulting >>> package looks just like before though. No isaexec symlink and the >>> default $ISA in bin/. What's wrong? Running "gmake spotless package" >>> leads to the same result. Current build description is checked >>> in [1]. >> >> I guess you hit this bug: >> ? >> >> Please try "gmake repackage" unless it has been fixed. > > indeed, "gmake repackage" did the trick. Thank you. With this kind of a volatile problem, having a check would be good. This is more or less what I was getting at with the post-prototype pre-package check in GAR. If the problem happens regularly, we need to at least detect the problem every time it happens. Dago, do you have an implementation idea from the top of your head? From phil at bolthole.com Thu Jan 14 19:37:20 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 14 Jan 2010 10:37:20 -0800 Subject: [csw-maintainers] new mailing list? In-Reply-To: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> Message-ID: On Wednesday, January 13, 2010, Ben wrote ... > There are a few reasons I'd like to see this happen: > > 1. Packages that are rejected are typically rejected for common > ? reasons. ?The more people the see these, the better we'll get over > ? time as we stop making the same mistakes. I don't thnk this will help. for one thing it's usually the new maintainers that make the mist mistakes . they're not going to go back and read the archives. secondly the is enough maintainer email flying around as is. I would guess most mantainers would choose NOT to be subscribed to such a boring list From bwalton at opencsw.org Thu Jan 14 19:45:10 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 14 Jan 2010 13:45:10 -0500 Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> Message-ID: <1263494521-sup-2239@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Jan 14 13:37:20 -0500 2010: > I don't thnk this will help. > for one thing it's usually the new maintainers that make the mist > mistakes . they're not going to go back and read the archives. But, other maintainers could cull a rejection-FAQ from it that new maintainers would like/use. The number of people that know the common issues right now is ~1. With the list, that number can grow. > secondly the is enough maintainer email flying around as is. I would > guess most mantainers would choose NOT to be subscribed to such a > boring list But they don't have to be. As long as any @opencsw.org address can post, those interested could subscribe. The benefit of archiving the info is still obtained. A small change in operation for a fair amount of benefit, imo. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rupert at opencsw.org Thu Jan 14 20:15:55 2010 From: rupert at opencsw.org (rupert THURNER) Date: Thu, 14 Jan 2010 20:15:55 +0100 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> <1263134474-sup-4605@ntdws12.chass.utoronto.ca> <4B4DF8CD.5040500@opencsw.org> <4B4DFA24.5040601@opencsw.org> Message-ID: <6af4271001141115s5bdcacdbu4fcaae6ec696b336@mail.gmail.com> On Wed, Jan 13, 2010 at 18:00, Dagobert Michelsen wrote: > Hi Roger, > > Am 13.01.2010 um 17:51 schrieb Roger H?kansson: > > > Roger H?kansson wrote: >> >>> Dagobert Michelsen wrote: >>> >>>> Hi Phil, >>>> >>>> Am 12.01.2010 um 18:32 schrieb Philip Brown: >>>> >>>>> On Sun, Jan 10, 2010 at 6:42 AM, Ben Walton >>>>> wrote: >>>>> >>>>>> >>>>>> Given the issues we constantly hit with libtool, I always find myself >>>>>> wondering if it was ever a benefit instead of a burden. Any >>>>>> grey-beards care to offer some historical perspective on this? >>>>>> >>>>> >>>>> "libtool evil". >>>>> >>>>> this is why our official documented guidelines are, >>>>> "REMOVE .la files from your packages" !!! >>>>> >>>> >>>> He he, and just now I get a bug report for a package that doesn't work >>>> without the .la-files: >>>> >>>> >>> Same as ImageMagick, they use libtool runtime to load internal modules. >>> So MERGE_EXCLUDE_LIBTOOL need to be set to >>> MERGE_EXCLUDE_LIBTOOL ?= $(libdir)/lib.*\.la instead of >>> MERGE_EXCLUDE_LIBTOOL ?= $(libdir)/.*\.la >>> >> >> Note: Thats not a general solution, packages with 64-bit libs or packages >> which have libraries in other places need to have MERGE_EXCLUDE_LIBTOOL >> properly set. >> >> "MERGE_EXCLUDE_LIBTOOL ?= $(libdir).*/lib.*\.la" might be a more general >> solution >> > > I would like to keep the general solution of excluding all libtool-files > and let the maintainer decide this on a case-by-case basis. Including > .la-files should be the exception. > > svn-1.6.7 also was complaining about a missing .la file, while svn-1.6.6 did not. i had no time to track down if this was caused by a libtool upgrade in between the build, or the subversion build changed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Thu Jan 14 22:09:41 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 14 Jan 2010 22:09:41 +0100 Subject: [csw-maintainers] BUILD64 In-Reply-To: <4B4DFE8F.80201@opencsw.org> References: <4B4DFE8F.80201@opencsw.org> Message-ID: <91C693DD-4514-4467-AF89-C5FA16190383@opencsw.org> Hi Roger, Am 13.01.2010 um 18:10 schrieb Roger H?kansson: > Some info someone else might find usable... > > According to "GAR Variable Reference", BUILD64 should be set to 1 to > build 64-bit targets, but actually the current GAR code doesn't care > what you set it to, just that its set. > If you check out something that has BUILD64=1 set and want to build > a 32-bit-only package, I couldn't find any way except edit the > Makefile before building. > So I patched my local gar.conf.mk to fix this. > "$if( $(BUILD64)...." is changed to "$if( eq($(BUILD64),1)...." > > With that change, setting "BUILD64=0" in ~/.garrc or prepending > before gmake, will let you build a 32-bit-only package. > (my personal x86-build server isn't 64-bit ready so I can only run > Solaris8 and Solaris10 in 32-bit-mode) Feel free to commit that change to the main tree. Best regards -- Dago From dam at opencsw.org Thu Jan 14 22:23:24 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 14 Jan 2010 22:23:24 +0100 Subject: [csw-maintainers] dbus In-Reply-To: <4B4E296D.9030708@opencsw.org> References: <4B4E296D.9030708@opencsw.org> Message-ID: <3BCBB553-3744-467A-8874-E9B99D961E43@opencsw.org> Hi, Am 13.01.2010 um 21:13 schrieb Sebastian Kayser: > Jeffery Small wrote on 13.01.2010 20:57: >> Dagobert Michelsen writes: >> >>> This was announced together with the updated package on users@ >>> in September: >> >>> 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 [...] >> >> Thanks Dagobert. >> >> I'm sorry that I missed the announcement back in September. I >> followed the >> procedures and did get the updated package installed. I really >> appreciate >> the quick response. Two comments: >> >> 1) It would be good to get the news section for packages up and >> running so >> that information like this could be used to list important >> information like >> this. > > +1 > > The NEWS link on www.opencsw.org/packages/ points to the > Mantis > news page for a package. Each maintainer should be able to populate > this > section for his packages already. That's where important news about > that > package could go. Nothing fancy, but better than it is right now. This is definitely a good idea. We also have http://wiki.opencsw.org/packages Too many places for so simple things... > What I also really would like to see is a changelog.CSW shipped with > each package which is somehow hooked into the release process. The > NEWS > section could then be automatically updated. I just had a > troubleshooting session with someone who updated amavisd-new and from > the package side it took me some time of distilling the important > items > in the GAR logs to see what had changed. That's where the NEWS would > have been helpful also. The package news section should IMHO have one entry per release. The ChangeLog is usually updated on every edit session which may or may not result in a released package, so I'd propose a modified approach here. >> 2) Is there some reason that the test for the bad installed version >> of >> dbus was not performed by the package's install script and then >> have the >> script automatically check for a running process and kill it as >> part of >> the upgrade procedure, rather than force the user to perform a manual >> intervention? I ask this as a general question regarding all >> packages that >> might require a non-standard form of intervention during >> installation. > > The bad dbus package was already installed and in my case it was the > uninstallation that hung. Nothing that the new package could have > dealt > with, or? I think so, yes. Upgrade-triggers would help circumvent these kinds of problems. Best regards -- Dago From dam at opencsw.org Thu Jan 14 22:27:27 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 14 Jan 2010 22:27:27 +0100 Subject: [csw-maintainers] CSW packaged MTAs and /usr (continued from "CSWcswclassutils: it wants to write in /usr") In-Reply-To: <4B4E4226.40600@opencsw.org> References: <4B4E4226.40600@opencsw.org> Message-ID: <25605C8E-E185-455C-9B62-0407D2918CE0@opencsw.org> Hi Sebastian, Am 13.01.2010 um 22:59 schrieb Sebastian Kayser: > as our postfix packages needs some makeover, there is something I took > away from the discussion about cswclassutils and /usr [1] which > relates > to our MTAs in general: > > #1 Automatically messing with system binaries is considered evil. > (e.g. /usr/lib/sendmail, /usr/bin/mailq, and /usr/sbin/newaliases) > > #2 A CSW MTA that doesn't replace /usr/lib/sendmail isn't really > integrated with the system (i.e. not guaranteed to catch all mail > originating from the system) > > Currently the postfix package automatically tries to move away the > system binaries and to link its own binaries into place. While this > tries to fully integrate with the system, it violates rule #1. There > are > also a couple of bugs open against the package where this procedure > fails in sparse zone enviroments [2]. > > With an updated postfix package I would like to make the package as > simple as possible and leave control to the user. Therefor I would > like > to emit a notification message on package installation, either > pointing > the user to a README.CSW, a script, an additional integration package, > or simply to echo commands that one can issue to integrate postfix > with > the system. > > Now I am wondering what these commands should do. Should they mimic > the > current behavior of > > mv .OFF && ln > > or would it rather be preferable to say > > pkgrm && ln I would go as far as pkgrm && pkgutil -i > I am specifically thinking about the latter option because of Solaris > patches. What would happen if we left the system sendmail packages in > place and simply moved away the binaries? Wouldn't a sendmail patch > notice the installed sendmail package and overwrite our link with > possibly patched binaries? Yes. > Granted, pkgrm wouldn't make it easy for a > user to revert back to system sendmail .. just trying to get a feeling > for the different approaches. It is easy. Just pkgadd the previous sendmail from Solaris. As we discussed there should be a catalog ("extra"? "solreplace"?) with the stub packages being incompatible with the Solaris provided ones and doing the integration. Best regards -- Dago From dam at opencsw.org Thu Jan 14 22:28:44 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 14 Jan 2010 22:28:44 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> Message-ID: <8B61B45D-AC95-4267-9868-8F3C24C263BF@opencsw.org> Hi Ben, Am 14.01.2010 um 01:36 schrieb Ben Walton: > I'd like to propose a new, internal-only mailing list. The purpose of > the list would be to record all package release requests. This would > replace the current practice of private mails to Phil. This list > would be open to posting from any @opencsw.org address, but would be > subscribed on request by maintainers as desired, not automatically. > > There are a few reasons I'd like to see this happen: > > 1. Packages that are rejected are typically rejected for common > reasons. The more people the see these, the better we'll get over > time as we stop making the same mistakes. > 2. History preservation. > 3. Team maintainership memory. Presently, if mails are private > between $release_manager and $maintainer, a $maintainer2 may not > know why a package is not being released. A list archive could > resolve this. This follows from #2. > 4. More visible maintainer activity. This is an easy way to keep an > eye on who's releasing what. This info can be gotten other ways of > course, but this is a more passive approach to seeing the same > info. > 5. Openness. It pulls back the curtains a bit more on some of the > backend happenings. > > Thoughts from others? I fully support this. Best regards -- Dago From dam at opencsw.org Thu Jan 14 22:39:22 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 14 Jan 2010 22:39:22 +0100 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <4B4F1424.2080109@opencsw.org> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> <1262725258-sup-3515@ntdws12.chass.utoronto.ca> <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> <4B4F1424.2080109@opencsw.org> Message-ID: <6383CAAE-CCA4-42A2-B9E6-538AE742A8CB@opencsw.org> Hi Roger, Am 14.01.2010 um 13:55 schrieb Roger H?kansson: > Dagobert Michelsen wrote: >> Hi Ben, >> Am 05.01.2010 um 22:01 schrieb Ben Walton: >>> Excerpts from Dagobert Michelsen's message of Tue Jan 05 15:56:02 >>> -0500 2010: >>> >>>> be needed. Thoughts? >>> 10 only. If the devs aren't interested in older platforms and you >>> have no personal need, why go through the headache? >> The question is: Do we want to release it and make separate releases >> of packages for Solaris 8/9 vs. 10 which require it? > > libproxy is a requirement for some gnome-packages which would mean > that we can't upgrade upgrade them without libproxy, and since some > of those packages have dependencies on other packages which might > get upgraded we would soon end up with a lot of Solaris8-packages > which doesn't work. The alternatives would be: (1) wait until the project switches to C++ (should be done pretty soon) where the standard is supported by SOS11. (2) Use GCC to compile libproxy. This would pull in gcc*rt, but would work fine. (3) Start with Solaris 10. By definition we start at Solaris 9, although the download stats say almost all people use Solaris 10 by now (see http://wiki.opencsw.org/suggestions mirror stats if you are curious). I'd go in that order. Let me know if you need libproxy now, then I'd start with (2). Best regards -- Dago From dam at opencsw.org Thu Jan 14 22:43:09 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 14 Jan 2010 22:43:09 +0100 Subject: [csw-maintainers] [csw-buildfarm] BO Buildfarm available again In-Reply-To: <20100114.14052100.2348471893@gyor.oxdrove.co.uk> References: <4610F26C-0F72-4B02-AB82-72C14942A20D@opencsw.org> <20100111.15423100.2872566158@gyor.oxdrove.co.uk> <3863F96D-2DD6-441B-A1FE-3BB0575193A2@opencsw.org> <20100114.14052100.2348471893@gyor.oxdrove.co.uk> Message-ID: Hi James, Am 14.01.2010 um 15:05 schrieb James Lee: > On 13/01/10, 15:33:19, Dagobert Michelsen wrote > regarding > Re: [csw-maintainers] [csw-buildfarm] BO Buildfarm available again: > >>>> The T5220 is now split into two LDoms: One LDom with the existing >>>> Solaris 10 >>>> instance carrying all of the Sparc stuff which was already there >>>> (now >>>> restricted to 12 GB Ram and 20 Strands) and one LDom with >>>> OpenSolaris >>>> 06/09 Sparc still installing with 3 GB Ram and 8 Strands. >>> >>> Any reason for the restriction? > >> Because the machine doesn't have more resources ;-) > > Excuse me the machine does, prior to enhancement each virtual machine > had 60% more available CPUs. Is this a problem for you? Are you really using that many parallel threads? If it proves useful I could lower the assignments from OSOL to the Solaris 10 LDom. >> There is also >> a control domain with 1 GB Ram and 4 Strands which sums up to >> 16 GB and 32 strands total. > > Ah yes so LDOMs are restrictive. Sorry I've only read the marketing > bumph which suggests resources are shared. Yes, the machine is shared like "there are two OS instances on shared hardware". The hardware is not shared, but partitioned. > That is on the misleading > side of truthful as there is no dynamic sharing of CPU and memory. > Where load is sporadic as for build hard partitioning is a waste of a > good machine. I had the impression that the T5220 wasn't used that much at all. Most of the time the load is beneath 3 or 4 (from 32 in the previous configuration). If you have suggestions on how to better utilize the resources I am all ears. Best regards -- Dago From dam at opencsw.org Thu Jan 14 22:43:48 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 14 Jan 2010 22:43:48 +0100 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> <1263134474-sup-4605@ntdws12.chass.utoronto.ca> <4B4DF8CD.5040500@opencsw.org> <4B4DFA24.5040601@opencsw.org> <4B4DFCD1.40303@opencsw.org> Message-ID: Hi Peter, Am 14.01.2010 um 15:49 schrieb Peter FELECAN: > Roger H?kansson writes: >>> Dagobert Michelsen wrote: >>> I would like to keep the general solution of excluding all libtool- >>> files >>> and let the maintainer decide this on a case-by-case basis. >>> Including >>> .la-files should be the exception. >>> >> >> Correct, with "general solution", I meant "starting point solution >> for >> those cases that need to keep some .la-files" >> There are only a few cases where .la-files need to be kept in the >> package. > > and for those cases it's a real PITA to convince the gate keeper of > the > day. If the presence of .la-files is a necessity for the package there is not much to discuss, I suppose... Best regards -- Dago From dam at opencsw.org Thu Jan 14 22:45:30 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 14 Jan 2010 22:45:30 +0100 Subject: [csw-maintainers] GAR and isaexec: merging to $ISA subdirs doesn't work In-Reply-To: References: <4B44701E.1070100@opencsw.org> <080DF858-63AB-4867-9B3F-3ABA7A43E645@opencsw.org> <4B450899.5030501@opencsw.org> Message-ID: Hi Maciej, Am 14.01.2010 um 19:15 schrieb Maciej (Matchek) Blizinski: > On Wed, Jan 6, 2010 at 10:03 PM, Sebastian Kayser > wrote: >> Dagobert Michelsen wrote on 06.01.2010 22:36: >>> Am 06.01.2010 um 12:12 schrieb Sebastian Kayser: >>>> I just removed NO_ISAEXEC=1 from the mbuffer package to make it a >>>> regular 32-/64-bit package with isaexec as a wrapper. The resulting >>>> package looks just like before though. No isaexec symlink and the >>>> default $ISA in bin/. What's wrong? Running "gmake spotless >>>> package" >>>> leads to the same result. Current build description is checked >>>> in [1]. >>> >>> I guess you hit this bug: >>> >> > >>> >>> Please try "gmake repackage" unless it has been fixed. >> >> indeed, "gmake repackage" did the trick. Thank you. > > With this kind of a volatile problem, having a check would be good. > This is more or less what I was getting at with the post-prototype > pre-package check in GAR. If the problem happens regularly, we need > to at least detect the problem every time it happens. > > Dago, do you have an implementation idea from the top of your head? Yes, we take your manifest and make a unit test out of it doing a "gmake package" and see if the prototype contains the isaexec-stuff. Best regards -- Dago From dam at opencsw.org Thu Jan 14 22:47:13 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 14 Jan 2010 22:47:13 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> Message-ID: <4AFEFC3A-5330-47F4-9BDB-989959DC02AD@opencsw.org> Hi Phil, Am 14.01.2010 um 19:37 schrieb Philip Brown: > On Wednesday, January 13, 2010, Ben wrote > ... >> There are a few reasons I'd like to see this happen: >> >> 1. Packages that are rejected are typically rejected for common >> reasons. The more people the see these, the better we'll get over >> time as we stop making the same mistakes. > > I don't thnk this will help. > for one thing it's usually the new maintainers that make the mist > mistakes . they're not going to go back and read the archives. > > secondly the is enough maintainer email flying around as is. I would > guess most mantainers would choose NOT to be subscribed to such a > boring list But some would want to (like me). Best regards -- Dago From william at wbonnet.net Thu Jan 14 23:24:07 2010 From: william at wbonnet.net (William Bonnet) Date: Thu, 14 Jan 2010 23:24:07 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <4AFEFC3A-5330-47F4-9BDB-989959DC02AD@opencsw.org> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <4AFEFC3A-5330-47F4-9BDB-989959DC02AD@opencsw.org> Message-ID: <4B4F9987.3040908@wbonnet.net> Hi I do like this proposal, thus thumb up and +1. It would be a nice information source for maintainers especially if some of us produces a FAQ, and it would also be useful for people working on internal tools. > But some would want to (like me). Some would want to, even if most would not. This is a typical situation in which we should consider that the needs of the few should be taken in account regarding to the needs of the many. Because it could help the few to improve quality of what the provide to the many ;) Cheers, -- 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 maciej at opencsw.org Thu Jan 14 23:59:59 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 14 Jan 2010 22:59:59 +0000 Subject: [csw-maintainers] new mailing list? In-Reply-To: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Jan 14, 2010 at 12:36 AM, Ben Walton wrote: > 1. Packages that are rejected are typically rejected for common > ? reasons. ?The more people the see these, the better we'll get over > ? time as we stop making the same mistakes. and > 4. More visible maintainer activity. This is an easy way to keep an > eye on who's releasing what. This info can be gotten other ways of > course, but this is a more passive approach to seeing the same > info. Sharing the package submission e-mail with other maintainers was my first instinct, but I got rebuked for "spamming the maintainers mailing list". A separate list would be good, because it makes the spamming argument go away. > 2. History preservation. > 3. Team maintainership memory. Presently, if mails are private > between $release_manager and $maintainer, a $maintainer2 may not > know why a package is not being released. A list archive could > resolve this. This follows from #2. This might be quite important at some point. For example, who was the previous maintainer of package X? When were specific versions submitted and released? > 5. Openness. ?It pulls back the curtains a bit more on some of the > ? backend happenings. I predict this argument will be attacked by Phil, as he generally pushes everything towards closedness. But I'm for transparency, and I'm generally interested in all the works and updates of other packages. Most of the time the mailing list will be along the lines of "here's a new package", "ok", but I'm sure that every now and then there are in-depth technical discussions which might be interesting and educating for the rest of maintainers, especially the new ones. In short, +1. Maciej From skayser at opencsw.org Fri Jan 15 01:13:48 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 15 Jan 2010 01:13:48 +0100 Subject: [csw-maintainers] dbus In-Reply-To: <3BCBB553-3744-467A-8874-E9B99D961E43@opencsw.org> References: <4B4E296D.9030708@opencsw.org> <3BCBB553-3744-467A-8874-E9B99D961E43@opencsw.org> Message-ID: <4B4FB33C.70400@opencsw.org> Dagobert Michelsen wrote on 14.01.2010 22:23: > Am 13.01.2010 um 21:13 schrieb Sebastian Kayser: >> The NEWS link on www.opencsw.org/packages/ points to the >> Mantis >> news page for a package. Each maintainer should be able to populate >> this >> section for his packages already. That's where important news about >> that >> package could go. Nothing fancy, but better than it is right now. > > This is definitely a good idea. We also have > http://wiki.opencsw.org/packages > Too many places for so simple things... True. Even if there are multiple places, one central place which ties them all together would be helpful. packages.debian.org is IMHO a brilliant example. >> What I also really would like to see is a changelog.CSW shipped with >> each package which is somehow hooked into the release process. The >> NEWS >> section could then be automatically updated. I just had a >> troubleshooting session with someone who updated amavisd-new and from >> the package side it took me some time of distilling the important >> items >> in the GAR logs to see what had changed. That's where the NEWS would >> have been helpful also. > > The package news section should IMHO have one entry per release. > The ChangeLog is usually updated on every edit session which may > or may not result in a released package, so I'd propose a modified > approach here. The changelog.CSW I am referring to also contains one block of information per package release - with all the relevant changes that happened since the last package release (examples see [1,2,3]). I took the idea from Yann's recipes ([4,5]) which in turn were likely inspired by Debian's changelog.Debian file. This block of information could simply be turned into a Mantis package news entry upon release. The file itself is a bit of fiddling at first, but when you have a template/script that assists you, it's more easy to do. It would of course be easier without, but for the benefit of the users (and ourselves) it is IMHO worth it. My very, very primitive script approach which helps me to construct the changelog can be found at http://dpaste.com/145339/. Sebastian [1]http://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/xterm/trunk/files/changelog.CSW [2]http://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/watch/trunk/files/changelog.CSW [3]http://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/sudosh2/trunk/files/changelog.CSW [4]http://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/screen/trunk/files/changelog.CSW [5]http://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/openssl/trunk/files/changelog.CSW From hson at opencsw.org Fri Jan 15 03:35:32 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 15 Jan 2010 03:35:32 +0100 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <6383CAAE-CCA4-42A2-B9E6-538AE742A8CB@opencsw.org> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> <1262725258-sup-3515@ntdws12.chass.utoronto.ca> <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> <4B4F1424.2080109@opencsw.org> <6383CAAE-CCA4-42A2-B9E6-538AE742A8CB@opencsw.org> Message-ID: <4B4FD474.20507@opencsw.org> Dagobert Michelsen wrote: > Hi Roger, > > Am 14.01.2010 um 13:55 schrieb Roger H?kansson: >> Dagobert Michelsen wrote: >>> Hi Ben, >>> Am 05.01.2010 um 22:01 schrieb Ben Walton: >>>> Excerpts from Dagobert Michelsen's message of Tue Jan 05 15:56:02 >>>> -0500 2010: >>>> >>>>> be needed. Thoughts? >>>> 10 only. If the devs aren't interested in older platforms and you >>>> have no personal need, why go through the headache? >>> The question is: Do we want to release it and make separate releases >>> of packages for Solaris 8/9 vs. 10 which require it? >> >> libproxy is a requirement for some gnome-packages which would mean >> that we can't upgrade upgrade them without libproxy, and since some of >> those packages have dependencies on other packages which might get >> upgraded we would soon end up with a lot of Solaris8-packages which >> doesn't work. > > The alternatives would be: > (1) wait until the project switches to C++ (should be done pretty soon) > where the standard is supported by SOS11. > (2) Use GCC to compile libproxy. This would pull in gcc*rt, but would > work fine. > (3) Start with Solaris 10. By definition we start at Solaris 9, although > the download stats say almost all people use Solaris 10 by now > (see http://wiki.opencsw.org/suggestions mirror stats if you are > curious). And (4) Use my patches to build Solaris8-packages. There are only minor changes needed to get it working. The ones I've got are not that generic that they could be submitted upstream, but for our purposes they work. However, I can't get the Makefile working so packaging on both Solaris 8 and 10 works with the same Makefile (maybee not needed if only Solaris8-packages are to be released). But I can commit my changes so you can finish the work. From bwalton at opencsw.org Fri Jan 15 04:37:31 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 14 Jan 2010 22:37:31 -0500 Subject: [csw-maintainers] GAR: Preprocessing a postinstall file In-Reply-To: References: <1260585404-sup-1926@ntdws12.chass.utoronto.ca> Message-ID: <1263526608-sup-2225@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Mon Jan 11 11:48:13 -0500 2010: > I've found a side effect of this capability: The preprocessed scripts > are copied to /home/src on "gmake garchive". It holds for postgresql > and gitosis. I'm guessing that you've never done gmake garchive for > docbook. This should be corrected with r8008. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Fri Jan 15 10:22:22 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 15 Jan 2010 09:22:22 +0000 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: References: <1257540745-sup-2047@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Nov 6, 2009 at 11:43 PM, Maciej (Matchek) Blizinski wrote: > 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 Dago has recently asked me about restoring this symlink. It's certainly technically possible, but let me ask this question: This symlink, if I understand correctly, makes it impossible to have multiple MySQL databases installed at the same time, because /opt/csw/lib/mysql is "the MySQL database", which is something people were arguing against (notably, Phil). If the presence of MySQL libraries in /opt/csw/lib/mysql is necessary, why not install MySQL with to the common /opt/csw prefix instead? Either we have one default version of MySQL or we don't. If we don't, the symlink shall not exist. If we do, let's install one MySQL version into /opt/csw, and alternative versions (e.g. 4) to private prefixes. Thoughts? Maciej From maciej at opencsw.org Fri Jan 15 11:09:23 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 15 Jan 2010 10:09:23 +0000 Subject: [csw-maintainers] new mailing list? In-Reply-To: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Jan 14, 2010 at 12:36 AM, Ben Walton wrote: > Thoughts from others? To summarize, people who have expressed support for the idea are: 1. Ben 2. Dagobert 3. Maciej 4. Peter Bonivart 5. Peter Felecan 6. William 7. Sebastian People not supporting the idea: 1. Phil It's a classic example when somebody makes a proposal, the vast majority of maintainers support the idea, Phil says no, and the topic dies a quiet death. I would like this not to happen any more. If the 7:1 support is not enough to accept the proposal and go ahead, I would suggest that we exercise the board vote on the subject. Maciej From dam at opencsw.org Fri Jan 15 11:12:10 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 15 Jan 2010 11:12:10 +0100 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: References: <1257540745-sup-2047@ntdws12.chass.utoronto.ca> Message-ID: Hi Maciej, Am 15.01.2010 um 10:22 schrieb Maciej (Matchek) Blizinski: > On Fri, Nov 6, 2009 at 11:43 PM, Maciej (Matchek) Blizinski > wrote: >> 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 > > Dago has recently asked me about restoring this symlink. It's > certainly technically possible, but let me ask this question: > > This symlink, if I understand correctly, makes it impossible to have > multiple MySQL databases installed at the same time, because > /opt/csw/lib/mysql is "the MySQL database", which is something people > were arguing against (notably, Phil). No, this is just transitional for packages that have /opt/csw/lib/mysql as runpath. It will be discarded when all these packages have been redone. Otherwise all these packages will remain broken. Best regards -- Dago From maciej at opencsw.org Fri Jan 15 11:16:09 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 15 Jan 2010 10:16:09 +0000 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: References: <1257540745-sup-2047@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Jan 15, 2010 at 10:12 AM, Dagobert Michelsen wrote: >> This symlink, if I understand correctly, makes it impossible to have >> multiple MySQL databases installed at the same time, because >> /opt/csw/lib/mysql is "the MySQL database", which is something people >> were arguing against (notably, Phil). > > No, this is just transitional for packages that have > /opt/csw/lib/mysql as runpath. It will be discarded when > all these packages have been redone. Otherwise all these > packages will remain broken. Would it be hard to get a list of these packages? If it's something like 2 or 3 packages, it might better to update them instead of dancing with symlinks. From maciej at opencsw.org Fri Jan 15 12:00:20 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 15 Jan 2010 11:00:20 +0000 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: References: <1257540745-sup-2047@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Jan 15, 2010 at 10:16 AM, Maciej (Matchek) Blizinski wrote: > On Fri, Jan 15, 2010 at 10:12 AM, Dagobert Michelsen wrote: >>> This symlink, if I understand correctly, makes it impossible to have >>> multiple MySQL databases installed at the same time, because >>> /opt/csw/lib/mysql is "the MySQL database", which is something people >>> were arguing against (notably, Phil). >> >> No, this is just transitional for packages that have >> /opt/csw/lib/mysql as runpath. It will be discarded when >> all these packages have been redone. Otherwise all these >> packages will remain broken. > > Would it be hard to get a list of these packages? ?If it's something > like 2 or 3 packages, it might better to update them instead of > dancing with symlinks. Wasn't that hard. Find the dependencies of CSWmysql5rt, find the .so files inside them, run ldd. The result is that there are 2 packages which can't find the mysql library: CSWphp5mysql CSWpmdbdmysql Both are lacking active maintainers, but both are in GAR. How about rebuilding them instead? Is anyone up for it? From pfelecan at opencsw.org Fri Jan 15 12:02:44 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 15 Jan 2010 12:02:44 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <4B4F9987.3040908@wbonnet.net> (William Bonnet's message of "Thu, 14 Jan 2010 23:24:07 +0100") References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <4AFEFC3A-5330-47F4-9BDB-989959DC02AD@opencsw.org> <4B4F9987.3040908@wbonnet.net> Message-ID: William Bonnet writes: > This is a typical situation in which we should consider that the needs > of the few should be taken in account regarding to the needs of the > many. Because it could help the few to improve quality of what the > provide to the many ;) This situation is, as you have learned in elementary classes, similar to that which created the favorable conditions for the French Revolution or the English one, but that was something that James studied ages ago. -- Peter From james at opencsw.org Fri Jan 15 13:03:17 2010 From: james at opencsw.org (James Lee) Date: Fri, 15 Jan 2010 12:03:17 GMT Subject: [csw-maintainers] [csw-buildfarm] BO Buildfarm available again In-Reply-To: References: <4610F26C-0F72-4B02-AB82-72C14942A20D@opencsw.org> <20100111.15423100.2872566158@gyor.oxdrove.co.uk> <3863F96D-2DD6-441B-A1FE-3BB0575193A2@opencsw.org> <20100114.14052100.2348471893@gyor.oxdrove.co.uk> Message-ID: <20100115.12031700.1966285364@gyor.oxdrove.co.uk> On 14/01/10, 21:43:09, Dagobert Michelsen wrote regarding Re: [csw-maintainers] [csw-buildfarm] BO Buildfarm available again: > >>>> The T5220 is now split into two LDoms: One LDom with the existing > >>>> Solaris 10 > >>>> instance carrying all of the Sparc stuff which was already there > >>>> (now > >>>> restricted to 12 GB Ram and 20 Strands) and one LDom with > >>>> OpenSolaris > >>>> 06/09 Sparc still installing with 3 GB Ram and 8 Strands. > >>> > >>> Any reason for the restriction? > > > >> Because the machine doesn't have more resources ;-) > > > > Excuse me the machine does, prior to enhancement each virtual machine > > had 60% more available CPUs. > Is this a problem for you? Are you really using that many parallel > threads? Yes, but only at times. OpenOffice.org is the worst and uses all threads for long periods (when the disc isn't dying). Looking at my current terminal output tiff says "build8s --> 20 jobs" several times but not for long as the whole build only takes 6 mins for everything. Problem is the wrong word. Only recently has the build farm had enough disc space and I've built OOo on my own Pentium 2 333MHz, it took 4 days not 6 hours but did get there. So it's not a problem but more is better, 5 minutes is better than 6 minutes and it won't be too fast until it's quicker than pressing a key. > > Ah yes so LDOMs are restrictive. Sorry I've only read the marketing > > bumph which suggests resources are shared. > Yes, the machine is shared like "there are two OS instances on shared > hardware". The hardware is not shared, but partitioned. > > That is on the misleading > > side of truthful as there is no dynamic sharing of CPU and memory. > > Where load is sporadic as for build hard partitioning is a waste of a > > good machine. > I had the impression that the T5220 wasn't used that much at all. Most > of the time the load is beneath 3 or 4 Exactly the problem I mean by sporadic load. Something like a busy email server will have a continual somewhat random stream of messages and will have a meaningful average load. A build the machine is idle until it's used, then it's busy. The load average means little, being low means no one is working. You should only take the load average of when it's busy which sounds silly but is right because the load when no one is using the machine doesn't matter. This is where average isn't important, as with the average number of legs on people, or rating the fire brigade by the percentage of time they are actually putting out fires. If it's a natural consequence of using LDoms then so be it. It's a shame they can't dynamically share threads, as with unrestricted zones, because for very uneven loads it's what is needed. James. From dam at opencsw.org Fri Jan 15 13:33:19 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 15 Jan 2010 13:33:19 +0100 Subject: [csw-maintainers] [csw-buildfarm] BO Buildfarm available again In-Reply-To: <20100115.12031700.1966285364@gyor.oxdrove.co.uk> References: <4610F26C-0F72-4B02-AB82-72C14942A20D@opencsw.org> <20100111.15423100.2872566158@gyor.oxdrove.co.uk> <3863F96D-2DD6-441B-A1FE-3BB0575193A2@opencsw.org> <20100114.14052100.2348471893@gyor.oxdrove.co.uk> <20100115.12031700.1966285364@gyor.oxdrove.co.uk> Message-ID: <1184D760-8C65-494D-8DAA-7BB4F95C0EDE@opencsw.org> Hi James, Am 15.01.2010 um 13:03 schrieb James Lee: > On 14/01/10, 21:43:09, Dagobert Michelsen wrote > regarding >> Is this a problem for you? Are you really using that many parallel >> threads? > > Yes, but only at times. OpenOffice.org is the worst and uses all > threads for long periods (when the disc isn't dying). Looking at my > current terminal output tiff says "build8s --> 20 jobs" several times > but not for long as the whole build only takes 6 mins for everything. > > Problem is the wrong word. Only recently has the build farm had > enough > disc space I can now easily add more space as I didn't assign everything that has been installed. Just let me know if you plan big projects ;-) > and I've built OOo on my own Pentium 2 333MHz, it took 4 > days not 6 hours but did get there. So it's not a problem but more > is better, 5 minutes is better than 6 minutes and it won't be too fast > until it's quicker than pressing a key. I see. For now I can move the CPUs from the OSOL LDom to the Solaris LDom until it is more heavily used. >>> That is on the misleading >>> side of truthful as there is no dynamic sharing of CPU and memory. >>> Where load is sporadic as for build hard partitioning is a waste >>> of a >>> good machine. > >> I had the impression that the T5220 wasn't used that much at all. >> Most >> of the time the load is beneath 3 or 4 > > Exactly the problem I mean by sporadic load. Something like a busy > email > server will have a continual somewhat random stream of messages and > will > have a meaningful average load. A build the machine is idle until > it's > used, then it's busy. The load average means little, being low > means no > one is working. You should only take the load average of when it's > busy > which sounds silly but is right because the load when no one is > using the > machine doesn't matter. This is where average isn't important, as > with > the average number of legs on people, or rating the fire brigade by > the > percentage of time they are actually putting out fires. > > If it's a natural consequence of using LDoms then so be it. It's a > shame they can't dynamically share threads, as with unrestricted > zones, > because for very uneven loads it's what is needed. I can move CPUs around on request if that helps. If it really shows to be a problem I will add another machine, but first I'd like to try it with this configuration. Best regards -- Dago From dam at opencsw.org Fri Jan 15 13:36:58 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 15 Jan 2010 13:36:58 +0100 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <4B4FD474.20507@opencsw.org> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> <1262725258-sup-3515@ntdws12.chass.utoronto.ca> <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> <4B4F1424.2080109@opencsw.org> <6383CAAE-CCA4-42A2-B9E6-538AE742A8CB@opencsw.org> <4B4FD474.20507@opencsw.org> Message-ID: <9B5249C5-C71A-4324-BC63-4D279E28461C@opencsw.org> Hi Roger, Am 15.01.2010 um 03:35 schrieb Roger H?kansson: > Dagobert Michelsen wrote: >> Hi Roger, >> Am 14.01.2010 um 13:55 schrieb Roger H?kansson: >>> Dagobert Michelsen wrote: >>>> Hi Ben, >>>> Am 05.01.2010 um 22:01 schrieb Ben Walton: >>>>> Excerpts from Dagobert Michelsen's message of Tue Jan 05 >>>>> 15:56:02 -0500 2010: >>>>> >>>>>> be needed. Thoughts? >>>>> 10 only. If the devs aren't interested in older platforms and you >>>>> have no personal need, why go through the headache? >>>> The question is: Do we want to release it and make separate >>>> releases >>>> of packages for Solaris 8/9 vs. 10 which require it? >>> >>> libproxy is a requirement for some gnome-packages which would mean >>> that we can't upgrade upgrade them without libproxy, and since >>> some of those packages have dependencies on other packages which >>> might get upgraded we would soon end up with a lot of Solaris8- >>> packages which doesn't work. >> The alternatives would be: >> (1) wait until the project switches to C++ (should be done pretty >> soon) >> where the standard is supported by SOS11. >> (2) Use GCC to compile libproxy. This would pull in gcc*rt, but would >> work fine. >> (3) Start with Solaris 10. By definition we start at Solaris 9, >> although >> the download stats say almost all people use Solaris 10 by now >> (see http://wiki.opencsw.org/suggestions mirror stats if you are >> curious). > > And (4) Use my patches to build Solaris8-packages. > There are only minor changes needed to get it working. The ones I've > got are not that generic that they could be submitted upstream, but > for our purposes they work. > However, I can't get the Makefile working so packaging on both > Solaris 8 and 10 works with the same Makefile (maybee not needed if > only Solaris8-packages are to be released). > But I can commit my changes so you can finish the work. Great, please do! I had the impression this was harder. Just take it over and release at will. Best regards -- Dago From bwalton at opencsw.org Fri Jan 15 14:42:35 2010 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 15 Jan 2010 08:42:35 -0500 Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> Message-ID: <1263562770-sup-2674@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Fri Jan 15 05:09:23 -0500 2010: > dies a quiet death. I would like this not to happen any more. If the > 7:1 support is not enough to accept the proposal and go ahead, I would > suggest that we exercise the board vote on the subject. While we should exercise this mechanism if required, I don't see that it is. The support has been almost unanimous. Given that there is only a single registered 'nay' vote and that procedural changes consist of _only_ sending the mail to a list instead of an individual, I'd like to ask Ihsan to create the list, with myself, Dago and Phil as members to start. I suspect some of the others that voiced support are ok with being on the list too, but I won't speak for them. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pfelecan at opencsw.org Fri Jan 15 14:45:10 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 15 Jan 2010 14:45:10 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <1263562770-sup-2674@ntdws12.chass.utoronto.ca> (Ben Walton's message of "Fri, 15 Jan 2010 08:42:35 -0500") References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> Message-ID: Ben Walton writes: > I suspect some of the others that voiced support are ok with being on > the list too, but I won't speak for them. I would like to be subscribed to this list. TIA -- Peter From maciej at opencsw.org Fri Jan 15 14:51:16 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 15 Jan 2010 13:51:16 +0000 Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Jan 15, 2010 at 1:45 PM, Peter FELECAN wrote: > Ben Walton writes: > >> I suspect some of the others that voiced support are ok with being on >> the list too, but I won't speak for them. > > I would like to be subscribed to this list. TIA Me too, please. From bonivart at opencsw.org Fri Jan 15 14:52:50 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 15 Jan 2010 14:52:50 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> Message-ID: <625385e31001150552x6d6b926bk949703867818e0e7@mail.gmail.com> On Fri, Jan 15, 2010 at 2:51 PM, Maciej (Matchek) Blizinski wrote: > On Fri, Jan 15, 2010 at 1:45 PM, Peter FELECAN wrote: >> Ben Walton writes: >> >>> I suspect some of the others that voiced support are ok with being on >>> the list too, but I won't speak for them. >> >> I would like to be subscribed to this list. TIA > > Me too, please. And me. -- /peter From dam at opencsw.org Fri Jan 15 16:03:52 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 15 Jan 2010 16:03:52 +0100 Subject: [csw-maintainers] Missing dependencies in X11 packages Message-ID: Hi William, I got some bug reports about missing dependencies in X11 packages: http://www.opencsw.org/mantis/view.php?id=4155 http://www.opencsw.org/mantis/view.php?id=4136 http://www.opencsw.org/mantis/view.php?id=4135 Could you please make sure that you don't have these issues when releasing the brand-new X11? Best regards -- Dago From hson at opencsw.org Fri Jan 15 18:08:30 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 15 Jan 2010 18:08:30 +0100 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <9B5249C5-C71A-4324-BC63-4D279E28461C@opencsw.org> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> <1262725258-sup-3515@ntdws12.chass.utoronto.ca> <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> <4B4F1424.2080109@opencsw.org> <6383CAAE-CCA4-42A2-B9E6-538AE742A8CB@opencsw.org> <4B4FD474.20507@opencsw.org> <9B5249C5-C71A-4324-BC63-4D279E28461C@opencsw.org> Message-ID: <4B50A10E.7030208@opencsw.org> Dagobert Michelsen wrote: > Hi Roger, > > Am 15.01.2010 um 03:35 schrieb Roger H?kansson: > >> Dagobert Michelsen wrote: >>> Hi Roger, >>> Am 14.01.2010 um 13:55 schrieb Roger H?kansson: >>>> Dagobert Michelsen wrote: >>>>> Hi Ben, >>>>> Am 05.01.2010 um 22:01 schrieb Ben Walton: >>>>>> Excerpts from Dagobert Michelsen's message of Tue Jan 05 15:56:02 >>>>>> -0500 2010: >>>>>> >>>>>>> be needed. Thoughts? >>>>>> 10 only. If the devs aren't interested in older platforms and you >>>>>> have no personal need, why go through the headache? >>>>> The question is: Do we want to release it and make separate releases >>>>> of packages for Solaris 8/9 vs. 10 which require it? >>>> >>>> libproxy is a requirement for some gnome-packages which would mean >>>> that we can't upgrade upgrade them without libproxy, and since some >>>> of those packages have dependencies on other packages which might >>>> get upgraded we would soon end up with a lot of Solaris8-packages >>>> which doesn't work. >>> The alternatives would be: >>> (1) wait until the project switches to C++ (should be done pretty soon) >>> where the standard is supported by SOS11. >>> (2) Use GCC to compile libproxy. This would pull in gcc*rt, but would >>> work fine. >>> (3) Start with Solaris 10. By definition we start at Solaris 9, although >>> the download stats say almost all people use Solaris 10 by now >>> (see http://wiki.opencsw.org/suggestions mirror stats if you are >>> curious). >> >> And (4) Use my patches to build Solaris8-packages. >> There are only minor changes needed to get it working. The ones I've >> got are not that generic that they could be submitted upstream, but >> for our purposes they work. >> However, I can't get the Makefile working so packaging on both Solaris >> 8 and 10 works with the same Makefile (maybee not needed if only >> Solaris8-packages are to be released). >> But I can commit my changes so you can finish the work. > > Great, please do! I had the impression this was harder. Just take > it over and release at will. I committed it last night. Do you have any example on how to modulate PATCHFILES depending not only on arch but also on OS? It's not required to build Solaris 8 packages, but for completeness if someone checks out the code and tries to build on Solaris 10 it will fail right now. I've pushed the packages to newpkgs From dam at opencsw.org Fri Jan 15 18:24:10 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 15 Jan 2010 18:24:10 +0100 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <4B50A10E.7030208@opencsw.org> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> <1262725258-sup-3515@ntdws12.chass.utoronto.ca> <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> <4B4F1424.2080109@opencsw.org> <6383CAAE-CCA4-42A2-B9E6-538AE742A8CB@opencsw.org> <4B4FD474.20507@opencsw.org> <9B5249C5-C71A-4324-BC63-4D279E28461C@opencsw.org> <4B50A10E.7030208@opencsw.org> Message-ID: <5BFDE348-4B8F-45EE-A643-9CB3427CE08E@opencsw.org> Hi Roger, Am 15.01.2010 um 18:08 schrieb Roger H?kansson: > Do you have any example on how to modulate PATCHFILES depending not > only on arch but also on OS? > It's not required to build Solaris 8 packages, but for completeness > if someone checks out the code and tries to build on Solaris 10 it > will fail right now. This is not straightforward as the whole selection is per-modulation and the Solaris release is something you usually don't modulate over. You could have platform-specific build recipes like in libmpeg2/trunk/Makefile. The trick is to set PATCHFILES to the patches to be applied to the current platform and ALLFILES_PATCHFILES to all patches to be add to "checksums". Could you please have a look first? Let me know if you have any troubles. Best regards -- Dago From hson at opencsw.org Fri Jan 15 21:21:45 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 15 Jan 2010 21:21:45 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <625385e31001150552x6d6b926bk949703867818e0e7@mail.gmail.com> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <625385e31001150552x6d6b926bk949703867818e0e7@mail.gmail.com> Message-ID: <4B50CE59.9030608@opencsw.org> Peter Bonivart wrote: > On Fri, Jan 15, 2010 at 2:51 PM, Maciej (Matchek) Blizinski > wrote: >> On Fri, Jan 15, 2010 at 1:45 PM, Peter FELECAN wrote: >>> Ben Walton writes: >>> >>>> I suspect some of the others that voiced support are ok with being on >>>> the list too, but I won't speak for them. >>> I would like to be subscribed to this list. TIA >> Me too, please. > > And me. > And me From william at wbonnet.net Sat Jan 16 19:43:11 2010 From: william at wbonnet.net (William Bonnet) Date: Sat, 16 Jan 2010 19:43:11 +0100 Subject: [csw-maintainers] Missing dependencies in X11 packages In-Reply-To: References: Message-ID: <4B5208BF.7050702@wbonnet.net> Hi Dago > Hi William, > > I got some bug reports about missing dependencies in X11 packages: > > http://www.opencsw.org/mantis/view.php?id=4155 > http://www.opencsw.org/mantis/view.php?id=4136 > http://www.opencsw.org/mantis/view.php?id=4135 > > Could you please make sure that you don't have these issues when > releasing the brand-new X11? Sure, i'll process these bugs. 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 trygvis at opencsw.org Sun Jan 17 16:09:19 2010 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Sun, 17 Jan 2010 16:09:19 +0100 Subject: [csw-maintainers] pcb-20081128 in testing/ Message-ID: <4B53281F.8060000@opencsw.org> Hi I've finally managed to get a working package of pcb with some pre/post install hacks. I also had to include a couple of patches that was needed when building larger boards with large netlists: http://git.gpleda.org/?p=pcb.git;a=commit;h=d053b4e41da10fd033429cb4b88c6e3b52769eb7 http://git.gpleda.org/?p=pcb.git;a=commit;h=40347a55413e152c7b5fc2bac074c75c7687b766 -- Trygve From dam at opencsw.org Sun Jan 17 17:36:23 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 17 Jan 2010 17:36:23 +0100 Subject: [csw-maintainers] Docbook test failing Message-ID: Hi, I am currently rebuilding mutt and the autoconf-test for docbook doesn't detect the docbook stylesheet, although it is installed. > build8s% pkginfo | grep -i docbook > application CSWdocbookdsssl docbookdsssl - Norman Walsh's > modular stylesheets for DocBook > application CSWdocbookdtds docbookdtds - SGML and XML document > type definitions for DocBook. > application CSWdocbookxsl docbookxsl - Norman Walsh's XSL > stylesheets for DocBook XML > application CSWdocbookxsldoc docbookxsldoc - Documentation for > the Docbook XSL stylesheets The test looks like this: > AC_MSG_CHECKING([for openjade docbook stylesheets]) > dslosfile=`ospcat --public-id="-//Norman Walsh//DOCUMENT DocBook > Print Stylesheet//EN"` > DSLROOT=`echo $dslosfile | sed -n -e "s/.*SOIBASE='\(@<:@^'@:>@*\) > \/catalog'.*/\1/p"` > # ospcat may spit out an absolute path without an SOIBASE > if test -z "$DSLROOT" > then > DSLROOT=`echo $dslosfile | sed -e 's|\(.*\)/print/ > docbook.dsl|\1|'` > fi > if test -f $DSLROOT/print/docbook.dsl > then > AC_MSG_RESULT([in $DSLROOT]) > have_openjade="yes" > else > AC_MSG_RESULT([not found: PDF documentation will not be built.]) > fi But the result of the first line is empty: > build8s% ospcat --public-id="-//Norman Walsh//DOCUMENT DocBook Print > Stylesheet//EN" Any idea why this is failing? Best regards -- Dago From skayser at opencsw.org Sun Jan 17 18:09:46 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 17 Jan 2010 18:09:46 +0100 Subject: [csw-maintainers] GAR: Least invasive way to pre-pend extra lib directories to LDFLAGS/LD_OPTIONS? Message-ID: <4B53445A.2010307@opencsw.org> Hi, a general GAR question. I know about EXTRA_LIBS which _appends_ the given directories to the default LDFLAGS and LD_OPTIONS while also considering a possible $ISALIST for each of these directories. Is there any variable which does the same, but pre-pends the given directories? For test purposes, I would like to have a binary with /opt/csw/bdb47/lib as the first component in the runpath (but i would like to avoid fiddling with LDFLAGS and LD_OPTIONS manually so to preserve as much of the defaults as possible). Sebastian From bwalton at opencsw.org Sun Jan 17 18:44:04 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 17 Jan 2010 12:44:04 -0500 Subject: [csw-maintainers] Docbook test failing In-Reply-To: References: Message-ID: <1263749957-sup-7540@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Sun Jan 17 11:36:23 -0500 2010: > > AC_MSG_CHECKING([for openjade docbook stylesheets]) > > dslosfile=`ospcat --public-id="-//Norman Walsh//DOCUMENT DocBook > > Print Stylesheet//EN"` I truss'd this call and it's failing because it doesn't look for the catalog files corectly. /1: open("catalog", O_RDONLY) Err#2 ENOENT /1: open("./catalog", O_RDONLY) Err#2 ENOENT /1: open("/opt/csw/share/sgml/catalog", O_RDONLY) Err#2 ENOENT /1: open("/opt/csw/share/xml/catalog", O_RDONLY) Err#2 ENOENT /1: open("/opt/csw/etc/sgml/catalog", O_RDONLY) Err#2 ENOENT It should be looking in /etc/opt/csw/sgml/catalog. Looks like a bug in CSWopensp. I thought this mess was in the past, but I must have overlooked something. I can work with Peter F to remedy this. Additionally, I could symlink /opt/csw/etc/{xml,sgml} -> /etc/opt/csw/{xml,sgml}, which would hide things like this. I'm not sure if hiding them is good though. 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 maciej at opencsw.org Sun Jan 17 19:57:00 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 17 Jan 2010 18:57:00 +0000 Subject: [csw-maintainers] GAR: Least invasive way to pre-pend extra lib directories to LDFLAGS/LD_OPTIONS? In-Reply-To: <4B53445A.2010307@opencsw.org> References: <4B53445A.2010307@opencsw.org> Message-ID: On Sun, Jan 17, 2010 at 5:09 PM, Sebastian Kayser wrote: > Hi, > > a general GAR question. I know about EXTRA_LIBS which _appends_ the > given directories to the default LDFLAGS and LD_OPTIONS while also > considering a possible $ISALIST for each of these directories. Is there > any variable which does the same, but pre-pends the given directories? > > For test purposes, I would like to have a binary with /opt/csw/bdb47/lib > as the first component in the runpath (but i would like to avoid > fiddling with LDFLAGS and LD_OPTIONS manually so to preserve as much of > the defaults as possible). There's a more high-level way to add paths to the runtime linker, it's documented here: http://sourceforge.net/apps/trac/gar/wiki/RuntimeLinkerPathes ...but it doesn't say anything about the resulting path order. From dam at opencsw.org Sun Jan 17 21:14:39 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 17 Jan 2010 21:14:39 +0100 Subject: [csw-maintainers] GAR: Least invasive way to pre-pend extra lib directories to LDFLAGS/LD_OPTIONS? In-Reply-To: <4B53445A.2010307@opencsw.org> References: <4B53445A.2010307@opencsw.org> Message-ID: <61493F41-495D-440F-A431-76F824C2704A@opencsw.org> Hi Sebastian, Am 17.01.2010 um 18:09 schrieb Sebastian Kayser: > a general GAR question. I know about EXTRA_LIBS which _appends_ the > given directories to the default LDFLAGS and LD_OPTIONS while also > considering a possible $ISALIST for each of these directories. Is > there > any variable which does the same, but pre-pends the given directories? Not yet. > For test purposes, I would like to have a binary with /opt/csw/bdb47/ > lib > as the first component in the runpath (but i would like to avoid > fiddling with LDFLAGS and LD_OPTIONS manually so to preserve as much > of > the defaults as possible). I have the feeling that it is generally a good idea to prepend manually set directories to the linker list as the contained libraries may be only there (which would cause no damage) or the would be more specialized like the general one (what is failing right now). That's why I think it would be good to change the order of directory pathes as linker parameters. As this change is somewhat invasive I would like some feedback of some senior packages (read: all of you :-) Best regards -- Dago From dam at opencsw.org Sun Jan 17 21:30:56 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 17 Jan 2010 21:30:56 +0100 Subject: [csw-maintainers] Determining the architecture of a binary In-Reply-To: References: Message-ID: Hi Maciej, Am 13.01.2010 um 11:37 schrieb Maciej (Matchek) Blizinski: > We don't have our own, up-to-date file (or gfile), do we? There doesn't seem to be a "GNU File" command, but I have packaged the latest one from http://www.darwinsys.com/file/ which seems pretty good in testing: file-5.03,REV=2010.01.17-SunOS5.8-sparc-CSW.pkg.gz file-5.03,REV=2010.01.17-SunOS5.8-i386-CSW.pkg.gz Best regards -- Dago From william at wbonnet.net Sun Jan 17 22:28:45 2010 From: william at wbonnet.net (William Bonnet) Date: Sun, 17 Jan 2010 22:28:45 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <1263562770-sup-2674@ntdws12.chass.utoronto.ca> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> Message-ID: <4B53810D.2010706@wbonnet.net> Hi > Given that there is only a single registered 'nay' vote and that > procedural changes consist of _only_ sending the mail to a list > instead of an individual, I'd like to ask Ihsan to create the list, > with myself, Dago and Phil as members to start. > More generally, i would like to suggest that each of our process that needs email communication, should be using "functional" email addresses rather than "personal" (or "named") addresses. Whether the functional address is a mailing list or not. Taking apart some difference of approach :) this would in any cases help us to improve process, and will handle easily cases like holidays, illness or whatever 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 Sun Jan 17 22:32:41 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 17 Jan 2010 16:32:41 -0500 Subject: [csw-maintainers] new mailing list? In-Reply-To: <4B53810D.2010706@wbonnet.net> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B53810D.2010706@wbonnet.net> Message-ID: <1263763930-sup-5284@ntdws12.chass.utoronto.ca> Excerpts from William Bonnet's message of Sun Jan 17 16:28:45 -0500 2010: Hi William, > More generally, i would like to suggest that each of our process > that needs email communication, should be using "functional" email > addresses rather than "personal" (or "named") addresses. Whether the > functional address is a mailing list or not. This makes a great deal of sense. 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 Sun Jan 17 22:42:41 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 17 Jan 2010 22:42:41 +0100 Subject: [csw-maintainers] Ganglia for sparcv9 In-Reply-To: <4B48FA2F.2020806@opencsw.org> References: <4AE87999.6020401@opencsw.org> <777D637C-111E-4F5B-8562-501B9F42351E@opencsw.org> <4B48FA2F.2020806@opencsw.org> Message-ID: <4B538451.7030002@opencsw.org> Am 09.01.10 22:50, schrieb Ihsan Dogan: >> Ihsan: For rrdtool I just opened a case for 64 bit libs: >> > > I'll have a look in that tomorrow. I'm running into a problem with Pango. We discussed this issue here before, but I don't remember how it ended. http://pastebin.ca/1755178 Any ideas? Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Sun Jan 17 22:57:27 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 17 Jan 2010 22:57:27 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <1263562770-sup-2674@ntdws12.chass.utoronto.ca> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> Message-ID: <4B5387C7.4010801@opencsw.org> Am 15.01.10 14:42, schrieb Ben Walton: >> dies a quiet death. I would like this not to happen any more. If the >> 7:1 support is not enough to accept the proposal and go ahead, I would >> suggest that we exercise the board vote on the subject. > > While we should exercise this mechanism if required, I don't see that > it is. The support has been almost unanimous. > > Given that there is only a single registered 'nay' vote and that > procedural changes consist of _only_ sending the mail to a list > instead of an individual, I'd like to ask Ihsan to create the list, > with myself, Dago and Phil as members to start. Ok, then I'm going to create a new list. Is internal at lists.opencsw.org fine? Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From trygvis at opencsw.org Sun Jan 17 23:01:08 2010 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Sun, 17 Jan 2010 23:01:08 +0100 Subject: [csw-maintainers] gtkwave-3.2.3 in testing/ Message-ID: <4B5388A4.9070402@opencsw.org> Hi Please test, in particular on SPARC. -- Trygve From trygvis at opencsw.org Sun Jan 17 23:03:01 2010 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Sun, 17 Jan 2010 23:03:01 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <4B5387C7.4010801@opencsw.org> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B5387C7.4010801@opencsw.org> Message-ID: <4B538915.6060209@opencsw.org> Ihsan Dogan wrote: > Am 15.01.10 14:42, schrieb Ben Walton: > >>> dies a quiet death. I would like this not to happen any more. If the >>> 7:1 support is not enough to accept the proposal and go ahead, I would >>> suggest that we exercise the board vote on the subject. >> While we should exercise this mechanism if required, I don't see that >> it is. The support has been almost unanimous. >> >> Given that there is only a single registered 'nay' vote and that >> procedural changes consist of _only_ sending the mail to a list >> instead of an individual, I'd like to ask Ihsan to create the list, >> with myself, Dago and Phil as members to start. > > Ok, then I'm going to create a new list. > Is internal at lists.opencsw.org fine? As the list is for new packages and we have a concept called "newpkgs" I think the list should be named "newpkgs" as it specifically is for new packages. -- Trygve From bwalton at opencsw.org Sun Jan 17 23:18:58 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 17 Jan 2010 17:18:58 -0500 Subject: [csw-maintainers] new mailing list? In-Reply-To: <4B538915.6060209@opencsw.org> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B5387C7.4010801@opencsw.org> <4B538915.6060209@opencsw.org> Message-ID: <1263766699-sup-2733@ntdws12.chass.utoronto.ca> Excerpts from Trygve Laugst?l's message of Sun Jan 17 17:03:01 -0500 2010: > As the list is for new packages and we have a concept called > "newpkgs" I think the list should be named "newpkgs" as it > specifically is for new packages. I had been things releases, but I prefer newpkgs too. +1 from me. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bwalton at opencsw.org Sun Jan 17 23:49:28 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 17 Jan 2010 17:49:28 -0500 Subject: [csw-maintainers] Docbook test failing In-Reply-To: <1263749957-sup-7540@ntdws12.chass.utoronto.ca> References: <1263749957-sup-7540@ntdws12.chass.utoronto.ca> Message-ID: <1263768279-sup-4850@ntdws12.chass.utoronto.ca> Excerpts from Ben Walton's message of Sun Jan 17 12:44:04 -0500 2010: > It should be looking in /etc/opt/csw/sgml/catalog. Looks like a bug > in CSWopensp. I thought this mess was in the past, but I must have Doh! It's not in GAR... I've opened a bug on this (the breakage, not the lack of GAR recipe). -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 hson at opencsw.org Mon Jan 18 02:38:45 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Mon, 18 Jan 2010 02:38:45 +0100 Subject: [csw-maintainers] Ganglia for sparcv9 In-Reply-To: <4B538451.7030002@opencsw.org> References: <4AE87999.6020401@opencsw.org> <777D637C-111E-4F5B-8562-501B9F42351E@opencsw.org> <4B48FA2F.2020806@opencsw.org> <4B538451.7030002@opencsw.org> Message-ID: <4B53BBA5.6010607@opencsw.org> Ihsan Dogan wrote: > Am 09.01.10 22:50, schrieb Ihsan Dogan: > >>> Ihsan: For rrdtool I just opened a case for 64 bit libs: >>> >> I'll have a look in that tomorrow. > > I'm running into a problem with Pango. We discussed this issue here > before, but I don't remember how it ended. > > http://pastebin.ca/1755178 > The lib does contain what you need, but I'm pretty sure that if you check config.log you will find that every test have failed due to: Undefined first referenced symbol in file XSolarisIASetProcessInfo /usr/openwin/lib/libX11.so.4 The problem is related to what I wrote last week regarding libcairo. Until the libcairo-problem is fixed, you might be able to get around it by adding this to your Makefile EXTRA_SOS_LD_FLAGS = -L$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) CONFIGURE_ARGS += --x-includes=$(prefix)/X11/include CONFIGURE_ARGS += --x-libraries=$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) Using those changes I'm able to build rrdtool using what's in GAR. However, until libcairo is fixed, you probably also need to add EXTRA_SOS_LD_OPTIONS = -R$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) From dam at opencsw.org Mon Jan 18 08:13:37 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 18 Jan 2010 08:13:37 +0100 Subject: [csw-maintainers] Ganglia for sparcv9 In-Reply-To: <4B53BBA5.6010607@opencsw.org> References: <4AE87999.6020401@opencsw.org> <777D637C-111E-4F5B-8562-501B9F42351E@opencsw.org> <4B48FA2F.2020806@opencsw.org> <4B538451.7030002@opencsw.org> <4B53BBA5.6010607@opencsw.org> Message-ID: <0F5D65D6-DCCC-4AC0-A836-7EFFA2AD25F2@opencsw.org> Hi Roger, Am 18.01.2010 um 02:38 schrieb Roger H?kansson: > Ihsan Dogan wrote: >> Am 09.01.10 22:50, schrieb Ihsan Dogan: >>>> Ihsan: For rrdtool I just opened a case for 64 bit libs: >>>> >>> I'll have a look in that tomorrow. >> I'm running into a problem with Pango. We discussed this issue here >> before, but I don't remember how it ended. >> http://pastebin.ca/1755178 > > The lib does contain what you need, but I'm pretty sure that if you > check config.log you will find that every test have failed due to: > > Undefined first referenced > symbol in file > XSolarisIASetProcessInfo /usr/openwin/lib/libX11.so.4 > > The problem is related to what I wrote last week regarding libcairo. > > Until the libcairo-problem is fixed, you might be able to get around > it > by adding this to your Makefile > > EXTRA_SOS_LD_FLAGS = -L$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) > CONFIGURE_ARGS += --x-includes=$(prefix)/X11/include > CONFIGURE_ARGS += --x-libraries=$(abspath $(prefix)/X11/lib/$ > (MM_LIBDIR)) > > Using those changes I'm able to build rrdtool using what's in GAR. > > However, until libcairo is fixed, you probably also need to add > EXTRA_SOS_LD_OPTIONS = -R$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) I see you have already done some work on it. Does it work? Please take it over at will. Best regards -- Dago From dam at opencsw.org Mon Jan 18 08:38:10 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 18 Jan 2010 08:38:10 +0100 Subject: [csw-maintainers] Anybody there with too much spare time? Message-ID: <9A5C2A02-9E13-41DC-ADF5-C8BF37E0205F@opencsw.org> Hi folks, grok this: 3D-Visualization of GIT activity, the result is... impressive... Examples videos are on the page. Best regards -- Dago From maciej at opencsw.org Mon Jan 18 08:58:30 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 18 Jan 2010 07:58:30 +0000 Subject: [csw-maintainers] new mailing list? In-Reply-To: <1263766699-sup-2733@ntdws12.chass.utoronto.ca> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B5387C7.4010801@opencsw.org> <4B538915.6060209@opencsw.org> <1263766699-sup-2733@ntdws12.chass.utoronto.ca> Message-ID: On Sun, Jan 17, 2010 at 10:18 PM, Ben Walton wrote: > Excerpts from Trygve Laugst?l's message of Sun Jan 17 17:03:01 -0500 2010: > >> As the list is for new packages and we have a concept called >> "newpkgs" I think the list should be named "newpkgs" as it >> specifically is for new packages. > > I had been things releases, but I prefer newpkgs too. ?+1 from me. Yes, makes sense. We've been using the keyword newpkgs in the past, let's stick to it. From dam at opencsw.org Mon Jan 18 09:01:05 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 18 Jan 2010 09:01:05 +0100 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <5BFDE348-4B8F-45EE-A643-9CB3427CE08E@opencsw.org> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> <1262725258-sup-3515@ntdws12.chass.utoronto.ca> <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> <4B4F1424.2080109@opencsw.org> <6383CAAE-CCA4-42A2-B9E6-538AE742A8CB@opencsw.org> <4B4FD474.20507@opencsw.org> <9B5249C5-C71A-4324-BC63-4D279E28461C@opencsw.org> <4B50A10E.7030208@opencsw.org> <5BFDE348-4B8F-45EE-A643-9CB3427CE08E@opencsw.org> Message-ID: <53446B3F-A718-4372-9DBF-8EB9D70BA020@opencsw.org> Hi Roger, could you please release libproxy to current/ at will so I can rebuild neon against it? Best regards -- Dago From maciej at opencsw.org Mon Jan 18 10:10:45 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 18 Jan 2010 09:10:45 +0000 Subject: [csw-maintainers] Determining the architecture of a binary In-Reply-To: References: Message-ID: On Sun, Jan 17, 2010 at 8:30 PM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 13.01.2010 um 11:37 schrieb Maciej (Matchek) Blizinski: >> >> We don't have our own, up-to-date file (or gfile), do we? > > There doesn't seem to be a "GNU File" command, but I have packaged > the latest one from > ?http://www.darwinsys.com/file/ > which seems pretty good in testing: > > file-5.03,REV=2010.01.17-SunOS5.8-sparc-CSW.pkg.gz > file-5.03,REV=2010.01.17-SunOS5.8-i386-CSW.pkg.gz Cool, that's the one. Thanks! I won't be relying on it for the architecture detection, though. I've found hachoir, a Python library which parses files and returns a data structure with all the data, similar to elfdump, but I won't have to parse the text output. From glaw at opencsw.org Mon Jan 18 10:23:24 2010 From: glaw at opencsw.org (Gary Law) Date: Mon, 18 Jan 2010 09:23:24 +0000 Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> Message-ID: add me and +1 for calling it newpkgs -- glaw at opencsw.org From hson at opencsw.org Mon Jan 18 10:38:26 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Mon, 18 Jan 2010 10:38:26 +0100 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <53446B3F-A718-4372-9DBF-8EB9D70BA020@opencsw.org> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> <1262725258-sup-3515@ntdws12.chass.utoronto.ca> <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> <4B4F1424.2080109@opencsw.org> <6383CAAE-CCA4-42A2-B9E6-538AE742A8CB@opencsw.org> <4B4FD474.20507@opencsw.org> <9B5249C5-C71A-4324-BC63-4D279E28461C@opencsw.org> <4B50A10E.7030208@opencsw.org> <5BFDE348-4B8F-45EE-A643-9CB3427CE08E@opencsw.org> <53446B3F-A718-4372-9DBF-8EB9D70BA020@opencsw.org> Message-ID: <4B542C12.3050705@opencsw.org> Dagobert Michelsen wrote: > Hi Roger, > > could you please release libproxy to current/ at will so I can > rebuild neon against it? It's already in newpkgs pending release, but I've pushed the latest build today. From maciej at opencsw.org Mon Jan 18 14:26:31 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 18 Jan 2010 13:26:31 +0000 Subject: [csw-maintainers] file-5.03 Message-ID: On Sun, Jan 17, 2010 at 8:30 PM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 13.01.2010 um 11:37 schrieb Maciej (Matchek) Blizinski: >> >> We don't have our own, up-to-date file (or gfile), do we? > > There doesn't seem to be a "GNU File" command, but I have packaged > the latest one from > ?http://www.darwinsys.com/file/ > which seems pretty good in testing: > > file-5.03,REV=2010.01.17-SunOS5.8-sparc-CSW.pkg.gz > file-5.03,REV=2010.01.17-SunOS5.8-i386-CSW.pkg.gz checkpkg doesn't work with it. It exports two colons instead of one in the output, and checkpkg doesn't detect a gzip file any more. The fix: Index: bin/checkpkg =================================================================== --- bin/checkpkg (revision 8048) +++ bin/checkpkg (working copy) @@ -90,7 +90,9 @@ set_variables_for_individual_package_check() { f=$1 - file $f |sed 's/^.*://' |grep gzip >/dev/null + file $f \ + | sed 's/^[^:]*://' \ + | grep gzip >/dev/null if [ $? -eq 0 ] ; then TMPARCHIVE=$CHECKPKG_TMPDIR/`basename $f` if [[ -f $TMPARCHIVE ]] ; then Committed in r8075. From hson at opencsw.org Mon Jan 18 14:41:46 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Mon, 18 Jan 2010 14:41:46 +0100 Subject: [csw-maintainers] libcairo in /testing (was Re: Ganglia for sparcv9) In-Reply-To: <0F5D65D6-DCCC-4AC0-A836-7EFFA2AD25F2@opencsw.org> References: <4AE87999.6020401@opencsw.org> <777D637C-111E-4F5B-8562-501B9F42351E@opencsw.org> <4B48FA2F.2020806@opencsw.org> <4B538451.7030002@opencsw.org> <4B53BBA5.6010607@opencsw.org> <0F5D65D6-DCCC-4AC0-A836-7EFFA2AD25F2@opencsw.org> Message-ID: <4B54651A.6060707@opencsw.org> Dagobert Michelsen wrote: > Hi Roger, > > Am 18.01.2010 um 02:38 schrieb Roger H?kansson: >> Ihsan Dogan wrote: >>> Am 09.01.10 22:50, schrieb Ihsan Dogan: >>>>> Ihsan: For rrdtool I just opened a case for 64 bit libs: >>>>> >>>> I'll have a look in that tomorrow. >>> I'm running into a problem with Pango. We discussed this issue here >>> before, but I don't remember how it ended. >>> http://pastebin.ca/1755178 >> >> The lib does contain what you need, but I'm pretty sure that if you >> check config.log you will find that every test have failed due to: >> >> Undefined first referenced >> symbol in file >> XSolarisIASetProcessInfo /usr/openwin/lib/libX11.so.4 >> >> The problem is related to what I wrote last week regarding libcairo. >> >> Until the libcairo-problem is fixed, you might be able to get around it >> by adding this to your Makefile >> >> EXTRA_SOS_LD_FLAGS = -L$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) >> CONFIGURE_ARGS += --x-includes=$(prefix)/X11/include >> CONFIGURE_ARGS += --x-libraries=$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) >> >> Using those changes I'm able to build rrdtool using what's in GAR. >> >> However, until libcairo is fixed, you probably also need to add >> EXTRA_SOS_LD_OPTIONS = -R$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) > > I see you have already done some work on it. Does it work? > Please take it over at will. Well, it works as far as I can tell, but a potential problem is how old dependencies are affected (see my previous mails regarding libX11.so.4/libXrender.so.1) I'll push the packages as is to /testing so someone else can do some more testing. The difference between this package and the current one is just that /opt/csw/X11/lib(/opt/csw/X11/lib/64) is first in RUNPATH in order to work around the fact that there is a libXrender.so.1 in /opt/csw/lib which is linked to libX11.so.4 in /usr/openwin instead of "our" own in /opt/csw/X11. But this still isn't a complete solution in order to link with libcairo without linking with libX11 from openwin. This version of libcairo only takes care of the runtime problem, when building apps/lib using libcairo you still need to prepend -L/opt/csw/X11/lib (-R/opt/csw/X11/lib if your app/lib uses X11 stuff in other places and not just as a result of linking with libcairo) to your link command. One way to do it when using GAR is to set: EXTRA_SOS_LD_FLAGS = -L$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) (and if needed: EXTRA_SOS_LD_OPTIONS = -R$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) ) From schwindt at dfki.uni-kl.de Mon Jan 18 18:33:28 2010 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Mon, 18 Jan 2010 18:33:28 +0100 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: Your message of "Mon, 21 Dec 2009 14:03:14 GMT." Message-ID: <201001181733.o0IHXS5r003576@dfki.uni-kl.de> [...] > * pysvn: minor version upgrade > * replaces the old subversion bindings with the pysvn project files. Which does break trac - btw. removing pysvn and install pythonsvn fixed the trac installation. I was lucky - the production system do not run this python .) Nicolai From maciej at opencsw.org Mon Jan 18 18:40:18 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 18 Jan 2010 17:40:18 +0000 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: <201001181733.o0IHXS5r003576@dfki.uni-kl.de> References: <201001181733.o0IHXS5r003576@dfki.uni-kl.de> Message-ID: On Mon, Jan 18, 2010 at 5:33 PM, Nicolai Schwindt wrote: > [...] >> * pysvn: minor version upgrade >> ?* replaces the old subversion bindings with the pysvn project files. > > Which does break trac - btw. > removing pysvn and install pythonsvn fixed the trac installation. > > I was lucky - the production system do not run this python .) The plan was to upgrade Trac and make it depend on pythonsvn. pysvn and pythonsvn can be installed alongside, removing or installing pysvn doesn't do anything with relation to Trac. But it's still depending on pysvn from what I can see on the packages page: http://www.opencsw.org/packages/trac The updated Trac is in testing. Rupert, ping? From schwindt at dfki.uni-kl.de Mon Jan 18 18:46:27 2010 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Mon, 18 Jan 2010 18:46:27 +0100 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: Your message of "Mon, 18 Jan 2010 17:40:18 GMT." Message-ID: <201001181746.o0IHkRpD003749@dfki.uni-kl.de> > The plan was to upgrade Trac and make it depend on pythonsvn. pysvn > and pythonsvn can be installed alongside, removing or installing pysvn > doesn't do anything with relation to Trac. > > But it's still depending on pysvn from what I can see on the packages page: > http://www.opencsw.org/packages/trac Exactly - and 'pkg-get -u' pulls in the pysvn 1.7.1,REV=2009.12.24. which breaks trac. Nicolai From maciej at opencsw.org Mon Jan 18 18:52:51 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 18 Jan 2010 17:52:51 +0000 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: <201001181746.o0IHkRpD003749@dfki.uni-kl.de> References: <201001181746.o0IHkRpD003749@dfki.uni-kl.de> Message-ID: On Mon, Jan 18, 2010 at 5:46 PM, Nicolai Schwindt wrote: > >> The plan was to upgrade Trac and make it depend on pythonsvn. pysvn >> and pythonsvn can be installed alongside, removing or installing pysvn >> doesn't do anything with relation to Trac. >> >> But it's still depending on pysvn from what I can see on the packages page: >> http://www.opencsw.org/packages/trac > > Exactly - and 'pkg-get -u' ?pulls in the ?pysvn 1.7.1,REV=2009.12.24. which > breaks trac. Does it really break it? I thought it would be neutral. From schwindt at dfki.uni-kl.de Mon Jan 18 20:52:36 2010 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Mon, 18 Jan 2010 20:52:36 +0100 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: Your message of "Mon, 18 Jan 2010 17:52:51 GMT." Message-ID: <201001181952.o0IJqa9b005155@dfki.uni-kl.de> [...] > > Does it really break it? I thought it would be neutral. "No module named svn" will be displayed on each page. The wiki itself stays readable. Nicolai From maciej at opencsw.org Mon Jan 18 20:59:48 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 18 Jan 2010 19:59:48 +0000 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: <201001181952.o0IJqa9b005155@dfki.uni-kl.de> References: <201001181952.o0IJqa9b005155@dfki.uni-kl.de> Message-ID: On Mon, Jan 18, 2010 at 7:52 PM, Nicolai Schwindt wrote: > [...] >> >> Does it really break it? ?I thought it would be neutral. > > "No module named svn" will be displayed on each page. > The wiki itself stays readable. I see. I think it's the lack of pythonsvn, not the presence of pysvn. From ihsan at opencsw.org Mon Jan 18 22:22:39 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Mon, 18 Jan 2010 22:22:39 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> Message-ID: <4B54D11F.3000608@opencsw.org> Am 18.01.10 10:23, schrieb Gary Law: > and +1 for calling it newpkgs newpkgs exists already: https://lists.opencsw.org/mailman/listinfo/newpkgs Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From bwalton at opencsw.org Mon Jan 18 22:27:45 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 18 Jan 2010 16:27:45 -0500 Subject: [csw-maintainers] new mailing list? In-Reply-To: <4B54D11F.3000608@opencsw.org> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B54D11F.3000608@opencsw.org> Message-ID: <1263850046-sup-8178@ntdws12.chass.utoronto.ca> Excerpts from Ihsan Dogan's message of Mon Jan 18 16:22:39 -0500 2010: > newpkgs exists already: https://lists.opencsw.org/mailman/listinfo/newpkgs pkgreleases ? -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Mon Jan 18 23:36:56 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 18 Jan 2010 22:36:56 +0000 Subject: [csw-maintainers] new mailing list? In-Reply-To: <1263850046-sup-8178@ntdws12.chass.utoronto.ca> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B54D11F.3000608@opencsw.org> <1263850046-sup-8178@ntdws12.chass.utoronto.ca> Message-ID: On Mon, Jan 18, 2010 at 9:27 PM, Ben Walton wrote: > Excerpts from Ihsan Dogan's message of Mon Jan 18 16:22:39 -0500 2010: > >> newpkgs exists already: https://lists.opencsw.org/mailman/listinfo/newpkgs > > pkgreleases ? The existing newpkgs list sounds like it really means pkgreleases, perhaps it could be renamed. (can you move list archives too?) The new list would be something along the lines of pkgsubmissions (which is long, but descriptive). From skayser at opencsw.org Tue Jan 19 00:08:51 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 19 Jan 2010 00:08:51 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B54D11F.3000608@opencsw.org> <1263850046-sup-8178@ntdws12.chass.utoronto.ca> Message-ID: <4B54EA03.9090001@opencsw.org> Maciej (Matchek) Blizinski wrote on 18.01.2010 23:36: > On Mon, Jan 18, 2010 at 9:27 PM, Ben Walton wrote: >> Excerpts from Ihsan Dogan's message of Mon Jan 18 16:22:39 -0500 2010: >> >>> newpkgs exists already: https://lists.opencsw.org/mailman/listinfo/newpkgs >> pkgreleases ? > > The existing newpkgs list sounds like it really means pkgreleases, > perhaps it could be renamed. (can you move list archives too?) +1 > The new list would be something along the lines of pkgsubmissions > (which is long, but descriptive). In case of a recipient address I like the concept of "short", so while we are juggling with names, what about? submit at opencsw.org Could also be just an alias for pkgsubmissions (that way all the pkg* relevant mailing lists would have the same prefix). Once the thread is on the list, the reply-to is set properly so the alias used to address the list initially shouldn't matter. Sebastian From bwalton at opencsw.org Tue Jan 19 01:27:49 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 18 Jan 2010 19:27:49 -0500 Subject: [csw-maintainers] new mailing list? In-Reply-To: <4B54EA03.9090001@opencsw.org> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B54D11F.3000608@opencsw.org> <1263850046-sup-8178@ntdws12.chass.utoronto.ca> <4B54EA03.9090001@opencsw.org> Message-ID: <1263860820-sup-7722@ntdws12.chass.utoronto.ca> Excerpts from Sebastian Kayser's message of Mon Jan 18 18:08:51 -0500 2010: > > The new list would be something along the lines of pkgsubmissions > we are juggling with names, what about? > > submit at opencsw.org Comprising to submitpkg@ ? -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 Jan 19 09:04:26 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 19 Jan 2010 09:04:26 +0100 Subject: [csw-maintainers] X11 installed and farm has been updated Message-ID: <3B37F5DF-A1E6-4D53-8CDC-A7931A4B1228@opencsw.org> Hi, I just upgraded all buildservers to the most recent packages and installed some of the new ones like libproxy. Let me know if you need anything more. William: I just installed all the new X11 proto packages for you :-) Best regards -- Dago From schwindt at dfki.uni-kl.de Tue Jan 19 10:21:56 2010 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Tue, 19 Jan 2010 10:21:56 +0100 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: Your message of "Mon, 18 Jan 2010 19:59:48 GMT." Message-ID: <201001190921.o0J9LuLK012292@dfki.uni-kl.de> [...] > I see. I think it's the lack of pythonsvn, not the presence of pysvn. May be I implied too much : updating pysvn ( as package name ) installs a python new module which no longer has the name svn ( as module name ). A new trac package with updated dependencies to pythonsvn could solve this. Nicolai From hson at opencsw.org Tue Jan 19 16:26:17 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Tue, 19 Jan 2010 16:26:17 +0100 Subject: [csw-maintainers] [csw-devel] SF.net SVN: gar:[8091] csw/mgar/pkg/libsoup2/trunk In-Reply-To: <4B55C08C.9000907@baltic-online.de> References: <4B55B966.6060505@gmail.com> <4B55BBF2.40504@gmail.com> <4B55C08C.9000907@baltic-online.de> Message-ID: <4B55CF19.2060905@opencsw.org> Jan Holzhueter wrote: > Hi, > > Am 19.01.10 15:04, schrieb Roger H?kansson: > >>> Noticed that you committed some stuff for libsoup2, I've been working >>> on releasing a updated version, but I've not committed my stuff yet. > Sorry didn't know you where working on it. > I will leave my work as it is atm and you can scrap or enhance it :) No problem, its a work in progress, I'm updating some packages which have a huge list of requirements and libsoup >2.4 was one of them so I started looking into that. >>> However I was going to update libsoup to current and scrap libsoup2 as >>> a separate package since there is only a few packages needing >>> libsoup2. So keeping them as separate packages is in my world not >>> necessary. > I don't now how many packages need libsoup2. A few weeks ago someone > drop by in the irc chat and reported that rhythmbox seems to be broken. > So I looked at bulding a new one since the CSW Version is kind of old. > Thats why I started updating libsoup2. > > So I don't know what to do with libsoup2 > Maybe you should forward this to maintainers@ > as I can't post there I think. To see what others think. Regarding the dependencies to libsoup (1.99) and libsoup2 (2.2.96), there are one package which need libsoup, multisync. There are four packages which need libsoup2, all of them evolution plus related plugins. My plan was to release a new libsoup-package which include the old libraries plus a empty dummy libsoup2-package which only has a dependency to libsoup so the evolution-stuff won't be broken (although, I don't know if it still works, there are a bunch of bugs reported for those packages). Then when the evolution-packages are updated (also on my TODO) they will have libsoup as a dependency and not libsoup2. But this maybe isn't the "right" way to do it (that's why I also send this to the maintainer's list)... From phil at bolthole.com Tue Jan 19 17:06:58 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 19 Jan 2010 08:06:58 -0800 Subject: [csw-maintainers] file-5.03 In-Reply-To: References: Message-ID: Just make sure your tweak works on the "gzip" package itself. gzip-blahblah*.pkg which is NOT gzipped, so will trigger error on false positive! :-) On Mon, Jan 18, 2010 at 5:26 AM, Maciej (Matchek) Blizinski wrote: > On Sun, Jan 17, 2010 at 8:30 PM, Dagobert Michelsen wrote: >> Hi Maciej, >> >> Am 13.01.2010 um 11:37 schrieb Maciej (Matchek) Blizinski: >>> >>> We don't have our own, up-to-date file (or gfile), do we? >> >> There doesn't seem to be a "GNU File" command, but I have packaged >> the latest one from >> ?http://www.darwinsys.com/file/ >> which seems pretty good in testing: >> >> file-5.03,REV=2010.01.17-SunOS5.8-sparc-CSW.pkg.gz >> file-5.03,REV=2010.01.17-SunOS5.8-i386-CSW.pkg.gz > > checkpkg doesn't work with it. > > It exports two colons instead of one in the output, and checkpkg > doesn't detect a gzip file any more. > > The fix: > > Index: bin/checkpkg > =================================================================== > --- bin/checkpkg ? ? ? ?(revision 8048) > +++ bin/checkpkg ? ? ? ?(working copy) > @@ -90,7 +90,9 @@ > > ?set_variables_for_individual_package_check() { > ? ? ? ?f=$1 > - ? ? ? file $f |sed 's/^.*://' |grep gzip >/dev/null > + ? ? ? file $f \ > + ? ? ? ? ? | sed 's/^[^:]*://' \ > + ? ? ? ? ? | grep gzip >/dev/null > ? ? ? ?if [ $? -eq 0 ] ; then > ? ? ? ? ? ? ? ?TMPARCHIVE=$CHECKPKG_TMPDIR/`basename $f` > ? ? ? ? ? ? ? ?if [[ -f $TMPARCHIVE ]] ; then > > Committed in r8075. > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From phil at bolthole.com Tue Jan 19 18:07:25 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 19 Jan 2010 09:07:25 -0800 Subject: [csw-maintainers] GAR: Least invasive way to pre-pend extra lib directories to LDFLAGS/LD_OPTIONS? In-Reply-To: <61493F41-495D-440F-A431-76F824C2704A@opencsw.org> References: <4B53445A.2010307@opencsw.org> <61493F41-495D-440F-A431-76F824C2704A@opencsw.org> Message-ID: On Sun, Jan 17, 2010 at 12:14 PM, Dagobert Michelsen wrote: >>.... > That's why I think it would be good to change the order of directory > pathes as linker parameters. As this change is somewhat invasive I would > like some feedback of some senior packages (read: all of you :-) > Gee, this sounds a whoole lot like a coupla years ago, when my recommendations were, "force certain paths in /opt/csw to be first, via LD_OPTIONS in your build environment, because it's canonical and tends to work reguardless of whatever twisted sub-build-tool is used." but people complained. Yet here we are again. ahaha. :-) From phil at bolthole.com Tue Jan 19 18:24:28 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 19 Jan 2010 09:24:28 -0800 Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Jan 14, 2010 at 2:59 PM, Maciej (Matchek) Blizinski wrote: > >> 5. Openness. ?It pulls back the curtains a bit more on some of the >> ? backend happenings. > > I predict this argument will be attacked by Phil, as he generally > pushes everything towards closedness. You dont know me as well as you think you do :-P >It's a classic example when somebody makes a proposal, the vast >majority of maintainers support the idea, Phil says no, and the topic >dies a quiet death. I would like this not to happen any more. I will mention here that the most common reason for this sort of cycle, is that I point out potential problems in the proposal, and no-one can come up with decent fixes for the problems in the proposal that I bring up. So then the flawed proposal dies. And in a logically based system, that is a GOOD thing. Flawed proposals SHOULD "die a quiet death". Not every proposal should succeed; even initially popular ones. That being said... I didnt even say "no this list should not be created or used". I only pointed out that it wont fully achieve specific things that Ben stated he thought it would do. It was nice to see that on this proposal, people actually replied to my comments in a useful manner, calmly and rationally. This is GOOD! I LIKE this! :-) My goal is not "stop all proposals", but only "point out any flaws in them that I can see". If people actually address those flaws, then I will cheerfully support a proposal I may have been initially against. PS: "submitpkg" as the new list name seems fairly good to me. From dam at opencsw.org Tue Jan 19 20:30:23 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 19 Jan 2010 20:30:23 +0100 Subject: [csw-maintainers] GAR: Least invasive way to pre-pend extra lib directories to LDFLAGS/LD_OPTIONS? In-Reply-To: References: <4B53445A.2010307@opencsw.org> <61493F41-495D-440F-A431-76F824C2704A@opencsw.org> Message-ID: <2F10C918-0DBE-41A9-A81D-75D04B6D6CF1@opencsw.org> Hi Phil, Am 19.01.2010 um 18:07 schrieb Philip Brown: > On Sun, Jan 17, 2010 at 12:14 PM, Dagobert Michelsen > wrote: >>> .... >> That's why I think it would be good to change the order of directory >> pathes as linker parameters. As this change is somewhat invasive I >> would >> like some feedback of some senior packages (read: all of you :-) > > > Gee, this sounds a whoole lot like a coupla years ago, when my > recommendations were, > "force certain paths in /opt/csw to be first, via LD_OPTIONS in your > build environment, because it's canonical and tends to work > reguardless of whatever twisted sub-build-tool is used." > but people complained. > > Yet here we are again. > ahaha. :-) Not quite. We are talking here about the order of directories passed via LD_OPTIONS to put more specialized directories in front and /opt/csw/lib at the end. It is not about LD_OPTIONS or LDFLAGS. Best regards -- Dago From phil at bolthole.com Tue Jan 19 21:42:39 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 19 Jan 2010 12:42:39 -0800 Subject: [csw-maintainers] GAR: Least invasive way to pre-pend extra lib directories to LDFLAGS/LD_OPTIONS? In-Reply-To: <2F10C918-0DBE-41A9-A81D-75D04B6D6CF1@opencsw.org> References: <4B53445A.2010307@opencsw.org> <61493F41-495D-440F-A431-76F824C2704A@opencsw.org> <2F10C918-0DBE-41A9-A81D-75D04B6D6CF1@opencsw.org> Message-ID: On Tue, Jan 19, 2010 at 11:30 AM, Dagobert Michelsen wrote: > Hi Phil, > *wave* > Am 19.01.2010 um 18:07 schrieb Philip Brown: > >> Gee, this sounds a whoole lot like a coupla years ago, when my >> recommendations were, >> "force certain paths in /opt/csw to be first, via LD_OPTIONS in your >> build environment, because it's canonical and tends to work >> reguardless of whatever twisted sub-build-tool is used." >> but people complained. >> >> Yet here we are again. >> ahaha. :-) > > Not quite. We are talking here about the order of directories passed via > LD_OPTIONS to put more specialized directories in front and /opt/csw/lib > at the end. It is not about LD_OPTIONS or LDFLAGS. > seems to me, the "least invasive way", would be to let the builder set them directly, and not to have it in "the build system" at all. Or, if it is in the build system, have ONE SINGLE top level override, that only gets set in extreme cases, and gets set only on a per-project basis. (ie: no "default" use of it). From phil at bolthole.com Tue Jan 19 21:44:16 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 19 Jan 2010 12:44:16 -0800 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: References: <1257540745-sup-2047@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Jan 15, 2010 at 1:22 AM, Maciej (Matchek) Blizinski wrote: > > This symlink, if I understand correctly, makes it impossible to have > multiple MySQL databases installed at the same time, because > /opt/csw/lib/mysql is "the MySQL database", which is something people > were arguing against (notably, Phil). I was? > Either we have one default version of MySQL or we don't. ?If we don't, > the symlink shall not exist. ?If we do, let's install one MySQL > version into /opt/csw, and alternative versions (e.g. 4) to private > prefixes. > > Thoughts? I think the default should be done only via symlinks, or other appropriate wrappers/pointeres to the "real" location. From phil at bolthole.com Tue Jan 19 21:47:15 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 19 Jan 2010 12:47:15 -0800 Subject: [csw-maintainers] CSW packaged MTAs and /usr (continued from "CSWcswclassutils: it wants to write in /usr") In-Reply-To: <4B4E4226.40600@opencsw.org> References: <4B4E4226.40600@opencsw.org> Message-ID: On Wed, Jan 13, 2010 at 1:59 PM, Sebastian Kayser wrote: > > With an updated postfix package I would like to make the package as > simple as possible and leave control to the user. Therefor I would like > to emit a notification message on package installation, either pointing > the user to a README.CSW, a script, an additional integration package, > or simply to echo commands that one can issue to integrate postfix with > the system. a script would be best, IMO. > patches. What would happen if we left the system sendmail packages in > place and simply moved away the binaries? Wouldn't a sendmail patch > notice the installed sendmail package and overwrite our link with > possibly patched binaries? actually it would probably complain that the target binaries it was replacing, dont match, and then refuse to patch. but depending on the particular patch, it might. > Granted, pkgrm wouldn't make it easy for a > user to revert back to system sendmail .. just trying to get a feeling > for the different approaches. offering pkgrm as an option, sounds like a good thing. Also though, particularly for the "no pkgrm" option.. make sure to provide an UNinstall script, to match up with the (/usr) install script please. From skayser at opencsw.org Tue Jan 19 22:34:26 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 19 Jan 2010 22:34:26 +0100 Subject: [csw-maintainers] OpenCSW Winter Camp - 23/24 Jan 2010, final infos and preparations Message-ID: <4B562562.8010900@opencsw.org> Hi guys, while the snow here in Munich is melting away, winter camp is coming closer. Some details: current plan is to meet on Friday evening at our office in Munich and go for dinner nearby (Dago and Maciej will join us once they have made their way from the airport). After that we will drive to the conference place/hotel together (about 1hr south of Munich, two cars). Departure from the hotel will be Sunday 4pm. Details and directions are online on the wiki page [1,2]. I have booked single rooms for the people who are currently listed on the winter camp page. If anyone else decided to join in the meantime, please let me know. For all those others, I will try to post some more frequent updates about what's going on (plus photos) during the camp. What we also might try is to _test drive_ a web stream / conferencing setup (just for the fun of it, might come in handy for one of the future camps or to record a talk). Anyone out there with a recommendation on neat tools to do so? If there are any questions, don't hesitate to ask. Looking forward to Friday! Sebastian [1] http://opencsw.wikidot.com/wintercamp-2009 [2] http://opencsw.wikidot.com/wintercamp-2009-directions From james at opencsw.org Wed Jan 20 13:25:16 2010 From: james at opencsw.org (James Lee) Date: Wed, 20 Jan 2010 12:25:16 GMT Subject: [csw-maintainers] new mailing list? In-Reply-To: <4B53810D.2010706@wbonnet.net> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B53810D.2010706@wbonnet.net> Message-ID: <20100120.12251600.3567085334@gyor.oxdrove.co.uk> On 17/01/10, 21:28:45, William Bonnet wrote regarding Re: [csw-maintainers] new mailing list?: > > Given that there is only a single registered 'nay' vote and that > > procedural changes consist of _only_ sending the mail to a list > > instead of an individual, I'd like to ask Ihsan to create the list, > > with myself, Dago and Phil as members to start. > > > More generally, i would like to suggest that each of our process that > needs email communication, should be using "functional" email addresses > rather than "personal" (or "named") addresses. Whether the functional > address is a mailing list or not. This is a good idea and was called role based last time it was suggested here. Business email should be sent to a role but received by a person. I also suggested that package maintenance represents a role and so package email should go to ${package}@opencsw.org and be forwarded to a person. The key here is the person can change without changing the email address. Roles based addressing is not the same as having a mailing list behind it. This request seems like a classic example of wanting to see something because you can't and not because once seen there is any net benefit to logging every action. There are some activities that do not need to be logged in detail and broadcast, for example I had a poo this morning, does anyone want to see my log? I guess the majority of new package emails are "here is a package" followed by "thank you" which anyone can infer happened by the pattern of releases. Actually we don't know if it happened and neither does it matter as the important event is release which is already broadcast and public. Any useful transmission will be masked in a stream of boring traffic. Subscribe? No thank you. There may be some messages associated with refusal. If broadcast and recorded by a mailing list there is the potential for public humiliation. Brilliant idea, this might cause people to think before submitting a package! Can we have a naughty step on the web site? Any useful information should be condensed from the flow and put on the maintainers' list or a "How (not) to make a package" web page. I'll start here with common problems and top tips: 1. put the right arch binary in the right package 2. use the package for several days before release, install with pkg-get 3. remove your package (important as can't fix after install) 4. check that the new package does not disrupt any dependants, eg by changing a library's SONAME. 5. think. Eg in the package dir, run: find . -type f | xargs file find . -ls (look at locations and sizes) find . -type f | xargs file | nawk -F: '/ELF/{print $1}' and on each result: dump -Lv ... ldd -r ... and think. James. From william at wbonnet.net Wed Jan 20 14:18:07 2010 From: william at wbonnet.net (William Bonnet) Date: Wed, 20 Jan 2010 14:18:07 +0100 Subject: [csw-maintainers] X11 installed and farm has been updated In-Reply-To: <3B37F5DF-A1E6-4D53-8CDC-A7931A4B1228@opencsw.org> References: <3B37F5DF-A1E6-4D53-8CDC-A7931A4B1228@opencsw.org> Message-ID: <4B57028F.7040308@wbonnet.net> Hi > William: I just installed all the new X11 proto packages for you :-) > Thanks a lot Next batch of compilation is running cheers W. > > Best regards > > -- Dago > > From dam at opencsw.org Wed Jan 20 15:21:38 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 20 Jan 2010 15:21:38 +0100 Subject: [csw-maintainers] Problem compiling remake In-Reply-To: <6cd6de211001191857j35ff7838va94dab9a7b7a9adb@mail.gmail.com> References: <6cd6de211001070921i456ddc16s62ea6fbf4a2b71b2@mail.gmail.com> <829A8165-DBAA-4535-9312-038FEB31A5C8@opencsw.org> <6cd6de211001191857j35ff7838va94dab9a7b7a9adb@mail.gmail.com> Message-ID: Hi folks, I mailed with the author of remake (the make debugger) and he has compilation problems I have never seen before: Am 20.01.2010 um 03:57 schrieb Rocky Bernstein: > When I try to compile that I get errors due to some sort of error in > strings.h pulled in from > the readline config file config/readline.h: > > In file included from /opt/csw/include/readline/chardefs.h:35, > from /opt/csw/include/readline/keymaps.h:35, > from /opt/csw/include/readline/readline.h:37, > from ./config/readline.h:10, > from debugger/cmd.c:51: > /usr/include/strings.h:24: error: expected declaration specifiers or > '...' before '(' token > > If you immediately see what's wrong let me know. A log from "./ > configure" and from "make" > can be found on login.opencsw.org:~rocky/src/build/ > remake-3.81+dbg-0.2/configure.log > and make.log Any advice is welcome here. (Please reply-all as Rocky is not on maintainers@) Best regards -- Dago From maciej at opencsw.org Wed Jan 20 15:46:49 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 20 Jan 2010 14:46:49 +0000 Subject: [csw-maintainers] new mailing list? In-Reply-To: <20100120.12251600.3567085334@gyor.oxdrove.co.uk> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B53810D.2010706@wbonnet.net> <20100120.12251600.3567085334@gyor.oxdrove.co.uk> Message-ID: On Wed, Jan 20, 2010 at 12:25 PM, James Lee wrote: > I guess the majority of new package emails are "here is a package" > followed by "thank you" which anyone can infer happened by the pattern > of releases. ?Actually we don't know if it happened and neither does > it matter as the important event is release which is already broadcast > and public. ?Any useful transmission will be masked in a stream of > boring traffic. ?Subscribe? ?No thank you. It's true that in most cases it will be boring, but I think it's important to have the submission information available, of anyone wants to access it. The problem with sendmail effort comes to mind. The release is one important broadcast, but a package submission is also an important event, if you think about the dynamics of the maintainer group. > There may be some messages associated with refusal. ?If broadcast and > recorded by a mailing list there is the potential for public humiliation. Humiliation of whom do you mean? There would be nothing the contents of the submitted packages. If there was anything horribly broken about the package, it would be seen by the public at the testing/ stage. This rules out the mailing list as a humiliation cause. > Brilliant idea, this might cause people to think before submitting a > package! ?Can we have a naughty step on the web site? > > Any useful information should be condensed from the flow and put on the > maintainers' list or a "How (not) to make a package" web page. ?I'll > start here with common problems and top tips: > > 1. put the right arch binary in the right package > 2. use the package for several days before release, install with pkg-get > 3. remove your package (important as can't fix after install) > 4. check that the new package does not disrupt any dependants, eg > ? by changing a library's SONAME. > 5. think. ?Eg in the package dir, run: > ? ? ?find . -type f | xargs file > ? ? ?find . -ls ? (look at locations and sizes) > ? ? ?find . -type f | xargs file | nawk -F: '/ELF/{print $1}' > ? ? ? ? and on each result: > ? ? ? ? ? ?dump -Lv ... > ? ? ? ? ? ?ldd -r ... > ? and think. Everything that can be automated, should be automated. Documenting isn't a bad idea, but the things you've described above, thinking aside, are mundane and boring. Doing them each time for each package is a waste of braincycles and keystrokes. Having a maintainer candidate reading through a long description of how a package is built, would result in the candidates never applying. Now when I look back on my beginnings as a maintainer, I remember that I looked around the website and quickly decided that the documentation there is describing manual steps, which is clearly not the way it's done, so I better avoid looking at it altogether. Instead, I looked specifically for the source code repository. It wasn't obvious, because the words "source code" or "repository" are nowhere to be found on the website. If you look for "site:www.opencsw.org repository -mantis", there only hits are from the package pages, the subversion package being the first. Once I found the repository, I found the directory with the package that interested me and tried to run it. When It failed, I started pulling apart the GAR code to understand what it does, and fixing any errors I came across. And I ended up with decent looking packages. If I were to base my package build attempts on the contents of www.opencsw.org, I would give up building for OpenCSW and instead hack a bunch of scripts to build the package only for myself. I don't mean that I don't support documenting things. It's good to have a detailed description of the policy: what the policy is, and what are the reasons behind it. However, I oppose putting such description forward as an operational document. The new maintainers, who are most likely to make the most of mistakes, should be presented with a relatively short description how to build a package, leaving the checking to checkpkg. It's hard enough to get people to install Sun Studio and gar_devel, keeping the entry bar low for people who want to try building a package for fun is an important aspect of making the community grow. To recap, the boring mailing list is for visibility, traceability, cross-pollination and coordination, while all the lessons learned should be transformed into code which makes sure that the spotted problems will never happen again. Maciej From james at opencsw.org Wed Jan 20 17:39:04 2010 From: james at opencsw.org (James Lee) Date: Wed, 20 Jan 2010 16:39:04 GMT Subject: [csw-maintainers] Problem compiling remake In-Reply-To: References: <6cd6de211001070921i456ddc16s62ea6fbf4a2b71b2@mail.gmail.com> <829A8165-DBAA-4535-9312-038FEB31A5C8@opencsw.org> <6cd6de211001191857j35ff7838va94dab9a7b7a9adb@mail.gmail.com> Message-ID: <20100120.16390400.3062200435@gyor.oxdrove.co.uk> On 20/01/10, 14:21:38, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Problem compiling remake: > Am 20.01.2010 um 03:57 schrieb Rocky Bernstein: > > When I try to compile that I get errors due to some sort of error in > > strings.h pulled in from > > the readline config file config/readline.h: > > > > In file included from /opt/csw/include/readline/chardefs.h:35, > > from /opt/csw/include/readline/keymaps.h:35, > > from /opt/csw/include/readline/readline.h:37, > > from ./config/readline.h:10, > > from debugger/cmd.c:51: > > /usr/include/strings.h:24: error: expected declaration specifiers or > > '...' before '(' token in make.h # define bcmp(s1, s2, n) memcmp ((s1), (s2), (n)) should be # define bcmp(s1, s2, n) memcmp (s1, s2, n) and in a few other places the same. make.h is included before the system header so corrupts the function prototypes, it's turning the prototypes into type casts. Solaris has bcmp anyway so you can drop the whole of that section, perhaps the bit that identifies the system is wrong. James. From james at opencsw.org Wed Jan 20 17:47:01 2010 From: james at opencsw.org (James Lee) Date: Wed, 20 Jan 2010 16:47:01 GMT Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B53810D.2010706@wbonnet.net> <20100120.12251600.3567085334@gyor.oxdrove.co.uk> Message-ID: <20100120.16470100.3668465799@gyor.oxdrove.co.uk> On 20/01/10, 14:46:49, Maciej "(Matchek)" Blizinski wrote regarding Re: [csw-maintainers] new mailing list?: > It's true that in most cases it will be boring, but I think it's > important to have the submission information available, of anyone > wants to access it. The problem with sendmail effort comes to mind. > The release is one important broadcast, but a package submission is > also an important event, if you think about the dynamics of the > maintainer group. No, it's not important. No one outside the group needs to know. > > There may be some messages associated with refusal.?If broadcast and > > recorded by a mailing list there is the potential for public humiliation. > Humiliation of whom do you mean? Presumably the idiot that submits a sparc package with intel binaries. If you are not embarrassed to submit packages with such fundamental mistakes your standards are low. > There would be nothing the contents > of the submitted packages. If there was anything horribly broken > about the package, it would be seen by the public at the testing/ > stage. Oh yes? If this were true no package would ever fail which isn't true, so the initial assertion is also untrue. > > Any useful information should be condensed from the flow and put on the > > maintainers' list or a "How (not) to make a package" web page. ?I'll > > start here with common problems and top tips: ... > Everything that can be automated, should be automated. Documenting > isn't a bad idea, but the things you've described above, thinking > aside, are mundane and boring. Doing them each time for each package > is a waste of braincycles and keystrokes. Yes it's boring and mundane. Please explain why someone else should do this for you? More importantly why I have been. You seem to not understand anything about the effort involved in QA. > To recap, the boring mailing list is for visibility, traceability, > cross-pollination and coordination, while all the lessons learned > should be transformed into code which makes sure that the spotted > problems will never happen again. Visibility of what? I'm confused as to what you think exists that is being kept from you - and I'm not saying you shouldn't see it, only that it obscures useful information. James. From phil at bolthole.com Wed Jan 20 18:25:21 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 20 Jan 2010 09:25:21 -0800 Subject: [csw-maintainers] new mailing list? In-Reply-To: <20100120.12251600.3567085334@gyor.oxdrove.co.uk> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B53810D.2010706@wbonnet.net> <20100120.12251600.3567085334@gyor.oxdrove.co.uk> Message-ID: On Wed, Jan 20, 2010 at 4:25 AM, James Lee wrote: > > This is a good idea and was called role based last time it was suggested > here. ?Business email should be sent to a role but received by a person. > I also suggested that package maintenance represents a role and so > package email should go to ${package}@opencsw.org and be forwarded to a > person. ?The key here is the person can change without changing the > email address. > potentially nice idea.. but in practical terms, it ends up being a HUGE spam burden, with little benefit to having a direct email interface. Are you saying you dont like the existing interface of, webbrowse to www.opencsw.org/packages/{package} click "email maintainer" ? From james at opencsw.org Wed Jan 20 20:09:23 2010 From: james at opencsw.org (James Lee) Date: Wed, 20 Jan 2010 19:09:23 GMT Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B53810D.2010706@wbonnet.net> <20100120.12251600.3567085334@gyor.oxdrove.co.uk> Message-ID: <20100120.19092300.3761741195@gyor.oxdrove.co.uk> On 20/01/10, 17:25:21, Philip Brown wrote regarding Re: [csw-maintainers] new mailing list?: > > This is a good idea and was called role based last time it was suggested > > here. Business email should be sent to a role but received by a person. > > I also suggested that package maintenance represents a role and so > > package email should go to ${package}@opencsw.org and be forwarded to a > > person. The key here is the person can change without changing the > > email address. > potentially nice idea.. but in practical terms, it ends up being a > HUGE spam burden Good point. > Are you saying you dont like the existing interface of, > webbrowse to www.opencsw.org/packages/{package} > click "email maintainer" Not that, although now the email goes to the last maintainer and it doesn't change until a new packages is built. Divorcing the address from the package could make it easier to change the route. The packages contain the personal emails and we can't change. When someone takes a sabbatical the destination should be swapped. We could also have several people receiving the emails in the case of a maintainer team - or a mailing list. I subscribe to upstream announce lists and the address goes with the package not me. I'm not sure if package addresses are better, generally I like to split roles from handlers in the email routing. Package addresses are not as important as webmaster@, newpks@, release@, mirrors@, buildfarm@, mantis@, publicity@, anyrole at . James. From rocky at gnu.org Wed Jan 20 21:41:22 2010 From: rocky at gnu.org (Rocky Bernstein) Date: Wed, 20 Jan 2010 15:41:22 -0500 Subject: [csw-maintainers] Problem compiling remake In-Reply-To: <20100120.16390400.3062200435@gyor.oxdrove.co.uk> References: <6cd6de211001070921i456ddc16s62ea6fbf4a2b71b2@mail.gmail.com> <829A8165-DBAA-4535-9312-038FEB31A5C8@opencsw.org> <6cd6de211001191857j35ff7838va94dab9a7b7a9adb@mail.gmail.com> <20100120.16390400.3062200435@gyor.oxdrove.co.uk> Message-ID: <6cd6de211001201241u16c368afj712845458dee2fba@mail.gmail.com> Thanks for the clue. I now see what's going on. It is proving tougher because all of those headers which come from GNU make rather than my patches on top of that. On Wed, Jan 20, 2010 at 11:39 AM, James Lee wrote: > On 20/01/10, 14:21:38, Dagobert Michelsen wrote > regarding > Re: [csw-maintainers] Problem compiling remake: > > > Am 20.01.2010 um 03:57 schrieb Rocky Bernstein: > > > > When I try to compile that I get errors due to some sort of error in > > > strings.h pulled in from > > > the readline config file config/readline.h: > > > > > > In file included from /opt/csw/include/readline/chardefs.h:35, > > > from /opt/csw/include/readline/keymaps.h:35, > > > from /opt/csw/include/readline/readline.h:37, > > > from ./config/readline.h:10, > > > from debugger/cmd.c:51: > > > /usr/include/strings.h:24: error: expected declaration specifiers or > > > '...' before '(' token > > > in make.h > # define bcmp(s1, s2, n) memcmp ((s1), (s2), (n)) > > should be > # define bcmp(s1, s2, n) memcmp (s1, s2, n) > > and in a few other places the same. make.h is included before the > system header so corrupts the function prototypes, it's turning the > prototypes into type casts. > > > Solaris has bcmp anyway so you can drop the whole of that section, > perhaps the bit that identifies the system is wrong. > > > > > James. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at bolthole.com Wed Jan 20 22:30:04 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 20 Jan 2010 13:30:04 -0800 Subject: [csw-maintainers] maintainers email addrs on packages Message-ID: On Wed, Jan 20, 2010 at 11:09 AM, James Lee wrote: > On 20/01/10, 17:25:21, Philip Brown wrote regarding Re: >... >> Are you saying you dont like the existing interface of, > >> webbrowse to www.opencsw.org/packages/{package} >> click "email maintainer" > > Not that, although now the email goes to the last maintainer and > it doesn't change until a new packages is built. ?Divorcing the > address from the package could make it easier to change the route. > > The packages contain the personal emails and we can't change. > But we shouldnt need to "fix" that, as an organization. When a package is updated by a new maintainer, the "correct" maintainer email gets into the package. If someone is asking for support on a package, the first thing they should do is upgrade to the latest "current" version of the package. So the only time this is an issue is when the maintainer has retired/disappeared ... in which case, we as an organization, can redirect their email, so it's still ok in theory. > When someone takes a sabbatical the destination should be swapped. "redirect their organizational email". Same as in any other organization, when a person goes on "sabbatical" or extended leave. > We could also have several people receiving the emails in the case > of a maintainer team - or a mailing list. Hrrrm.. I can ALMOST visualize supporting MULTIPLE email addrs in the EMAIL= field of pkginfo. mantis DOES support having multiple people as manager of a package. However to get it to work end-to-end, our www.opencsw.org/packages/xxx scripting would have to be rewritten, rather majorly. Im not feeling up to that. If someone wants to update/take it over, that would be relatively fine by me though. > I subscribe to upstream announce lists and the address goes with > the package not me. Umm.. yikes. roles being subscribed to mailing lists, doesnt sound like a good idea to me personally. From skayser at opencsw.org Thu Jan 21 00:51:00 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 21 Jan 2010 00:51:00 +0100 Subject: [csw-maintainers] maintainers email addrs on packages In-Reply-To: References: Message-ID: <4B5796E4.6010701@opencsw.org> Philip Brown wrote on 20.01.2010 22:30: > On Wed, Jan 20, 2010 at 11:09 AM, James Lee wrote: >> We could also have several people receiving the emails in the case >> of a maintainer team - or a mailing list. > > Hrrrm.. I can ALMOST visualize supporting MULTIPLE email addrs in the > EMAIL= field of pkginfo. mantis DOES support having multiple people as > manager of a package. No ... please. Let's eventually de-couple our meta information handling from the bug handling in Mantis - not work it even more deeper into it. I would have wanted to assign global maintainer privileges to all CSW maintainers for a while now, so that bug handling across packages/projects gets easier. Currently though, our "package-to-maintainer" mapping is based on those privileges in Mantis, so I can't easily manage permissions in Mantis without risking to mess up the mappings. > However to get it to work end-to-end, our > www.opencsw.org/packages/xxx scripting would have to be rewritten, > rather majorly. Im not feeling up to that. > > If someone wants to update/take it over, that would be relatively fine > by me though. Any specifics on what you would need from a package release perspective? Sebastian From skayser at opencsw.org Thu Jan 21 01:27:21 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 21 Jan 2010 01:27:21 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <20100120.16470100.3668465799@gyor.oxdrove.co.uk> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B53810D.2010706@wbonnet.net> <20100120.12251600.3567085334@gyor.oxdrove.co.uk> <20100120.16470100.3668465799@gyor.oxdrove.co.uk> Message-ID: <4B579F69.9020604@opencsw.org> James Lee wrote on 20.01.2010 17:47: > On 20/01/10, 14:46:49, Maciej "(Matchek)" Blizinski > wrote regarding Re: [csw-maintainers] new mailing list?: >>> There may be some messages associated with refusal. If broadcast and >>> recorded by a mailing list there is the potential for public humiliation. > >> Humiliation of whom do you mean? > > Presumably the idiot that submits a sparc package with intel binaries. > If you are not embarrassed to submit packages with such fundamental > mistakes your standards are low. Could we please just drop the harsh word "humiliation" (and the attitude that usually comes along with it wherever one ventures)? There is always something to learn, everyone makes mistakes from time to time and those who are learning should _not_ feel like they are at the eager eyes of those who know better and who are just waiting to humiliate them. >>> Any useful information should be condensed from the flow and put on the >>> maintainers' list or a "How (not) to make a package" web page. I'll >>> start here with common problems and top tips: > > ... > >> Everything that can be automated, should be automated. Documenting >> isn't a bad idea, but the things you've described above, thinking >> aside, are mundane and boring. Doing them each time for each package >> is a waste of braincycles and keystrokes. > > Yes it's boring and mundane. Please explain why someone else should > do this for you? More importantly why I have been. You seem to not > understand anything about the effort involved in QA. >From what I understand, Maciej tried to point out that if something is "boring and mundane" and can be automated, why not let's do it and save everyone's braincycles and keystrokes, especially yours and Phil's. He also offered a hand at extending checkpkg so that it can catch more of those commonly encountered issues. I doubt very much that he doesn't appreciate what the two of you are doing. Sebastian From james at opencsw.org Thu Jan 21 11:50:06 2010 From: james at opencsw.org (James Lee) Date: Thu, 21 Jan 2010 10:50:06 GMT Subject: [csw-maintainers] new mailing list? In-Reply-To: <4B579F69.9020604@opencsw.org> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B53810D.2010706@wbonnet.net> <20100120.12251600.3567085334@gyor.oxdrove.co.uk> <20100120.16470100.3668465799@gyor.oxdrove.co.uk> <4B579F69.9020604@opencsw.org> Message-ID: <20100121.10500600.265148322@gyor.oxdrove.co.uk> On 21/01/10, 00:27:21, Sebastian Kayser wrote regarding Re: [csw-maintainers] new mailing list?: > >>> recorded by a mailing list there is the potential for public humiliation. > > > >> Humiliation of whom do you mean? > > > > Presumably the idiot that submits a sparc package with intel binaries. > > If you are not embarrassed to submit packages with such fundamental > > mistakes your standards are low. > Could we please just drop the harsh word "humiliation" (and the attitude > that usually comes along with it wherever one ventures)? There is always > something to learn, everyone makes mistakes from time to time and those No, it is used on purpose to emphasise my point. People make mistakes, we know that, we accept that. What is not useful is to make a list of someone's short comings and put them on a advertising billboard. > who are learning should _not_ feel like they are at the eager eyes of > those who know better and who are just waiting to humiliate them. Exactly my point, glad you agree. > >>> Any useful information should be condensed from the flow and put on the > >>> maintainers' list or a "How (not) to make a package" web page. I'll > >>> start here with common problems and top tips: > > > > ... > > > >> Everything that can be automated, should be automated. Documenting > >> isn't a bad idea, but the things you've described above, thinking > >> aside, are mundane and boring. Doing them each time for each package > >> is a waste of braincycles and keystrokes. > > > > Yes it's boring and mundane. Please explain why someone else should > > do this for you? More importantly why I have been. You seem to not > > understand anything about the effort involved in QA. > >From what I understand, Maciej tried to point out that if something is > "boring and mundane" and can be automated, why not let's do it and save > everyone's braincycles and keystrokes, especially yours and Phil's. He > also offered a hand at extending checkpkg so that it can catch more of > those commonly encountered issues. I doubt very much that he doesn't > appreciate what the two of you are doing. Automating in only part of the story. People have repeatedly suggested automation is the answer to everything, well firstly much of my test *is* automated. This is not the hard (boring and mundane) part, what takes the time is understanding the output, moderating the marginal cases and effecting rectification. Secondly if you have a automated test procedure that installs a package, answers questions, reads the readmes and follows any instructions as a human would then uses the software and finds all errors please present it. James. From james at opencsw.org Thu Jan 21 11:51:49 2010 From: james at opencsw.org (James Lee) Date: Thu, 21 Jan 2010 10:51:49 GMT Subject: [csw-maintainers] maintainers email addrs on packages In-Reply-To: References: Message-ID: <20100121.10514900.3025170389@gyor.oxdrove.co.uk> On 20/01/10, 21:30:04, Philip Brown wrote regarding Re: [csw-maintainers] maintainers email addrs on packages: > > Not that, although now the email goes to the last maintainer and > > it doesn't change until a new packages is built. ?Divorcing the > > address from the package could make it easier to change the route. > > > > The packages contain the personal emails and we can't change. > But we shouldnt need to "fix" that, as an organization. > When a package is updated by a new maintainer, the "correct" > maintainer email gets into the package. > If someone is asking for support on a package, the first thing they > should do is upgrade to the latest "current" version of the package. What if it is the current? Then the old maintainer is still listed in the package. > > When someone takes a sabbatical the destination should be swapped. > "redirect their organizational email". > Same as in any other organization, when a person goes on "sabbatical" > or extended leave. That can only be done on a per user basis, it's not possible to route some one way and others another. It also means any personal messages are redirected. A break might mean a break from work but not all contact. > > I subscribe to upstream announce lists and the address goes with > > the package not me. > Umm.. yikes. roles being subscribed to mailing lists, doesnt sound > like a good idea to me personally. ${user}@opencsw.org is already a redirect. It's no different. James. From phil at bolthole.com Thu Jan 21 18:44:10 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 21 Jan 2010 09:44:10 -0800 Subject: [csw-maintainers] maintainers email addrs on packages In-Reply-To: <20100121.10514900.3025170389@gyor.oxdrove.co.uk> References: <20100121.10514900.3025170389@gyor.oxdrove.co.uk> Message-ID: On Thu, Jan 21, 2010 at 2:51 AM, James Lee wrote: > On 20/01/10, 21:30:04, Philip Brown wrote regarding Re: > [csw-maintainers] maintainers email addrs on packages: >> Umm.. yikes. roles being subscribed to mailing lists, doesnt sound >> like a good idea to me personally. > > ${user}@opencsw.org is already a redirect. ?It's no different. > > but $user at opencsw.org is not publically advertised as a support interface. Remember that we never directly expose maintainer addresses on our web site It makes a difference, spamwise. From phil at bolthole.com Thu Jan 21 18:46:49 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 21 Jan 2010 09:46:49 -0800 Subject: [csw-maintainers] maintainers email addrs on packages In-Reply-To: <4B5796E4.6010701@opencsw.org> References: <4B5796E4.6010701@opencsw.org> Message-ID: On Wed, Jan 20, 2010 at 3:51 PM, Sebastian Kayser wrote: > Philip Brown wrote on 20.01.2010 22:30: >> On Wed, Jan 20, 2010 at 11:09 AM, James Lee wrote: >>> We could also have several people receiving the emails in the case >>> of a maintainer team - or a mailing list. >> >> Hrrrm.. I can ALMOST visualize supporting MULTIPLE email addrs in the >> EMAIL= field of pkginfo. mantis DOES support having multiple people as >> manager of a package. > > No ... please. Let's eventually de-couple our meta information handling > from the bug handling in Mantis - not work it even more deeper into it. > One way or another, we need "one central, official place to record who 'owns' a package". It makes sense that it be a database. Since we ALREADY have a database that keeps track of that sort of thing.. the mantis database... and that information MUST be kept current there.... it doesn't make sense, from the standpoint of "good information management practices" to make another separate database. It would require even more synchronization between things. Simpler is better. From skayser at opencsw.org Thu Jan 21 21:06:36 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 21 Jan 2010 21:06:36 +0100 Subject: [csw-maintainers] maintainers email addrs on packages In-Reply-To: References: <4B5796E4.6010701@opencsw.org> Message-ID: <4B58B3CC.8020006@opencsw.org> Philip Brown wrote on 21.01.2010 18:46: > On Wed, Jan 20, 2010 at 3:51 PM, Sebastian Kayser wrote: >> Philip Brown wrote on 20.01.2010 22:30: >>> On Wed, Jan 20, 2010 at 11:09 AM, James Lee wrote: >>>> We could also have several people receiving the emails in the case >>>> of a maintainer team - or a mailing list. >>> Hrrrm.. I can ALMOST visualize supporting MULTIPLE email addrs in the >>> EMAIL= field of pkginfo. mantis DOES support having multiple people as >>> manager of a package. >> No ... please. Let's eventually de-couple our meta information handling >> from the bug handling in Mantis - not work it even more deeper into it. >> > > One way or another, we need "one central, official place to record who > 'owns' a package". It makes sense that it be a database. One central database, totally agreed. > Since we ALREADY have a database that keeps track of that sort of > thing.. the mantis database... and that information MUST be kept > current there.... it doesn't make sense, from the standpoint of "good > information management practices" to make another separate database. > It would require even more synchronization between things. > Simpler is better. Currently I can't just grant every maintainer global maintainer privileges for easier bug handling in Mantis as it will break the package assignments which are (as of today) also tracked by using the privilege levels in Mantis. In other words, we are at a latent risk of possible meta data breakage because of things gone wrong in a 3rd party bug handling tool. When thinking about a dedicated CSW meta database and Mantis, the only synchronization required that comes to my mind would be a sync of maintainers to the list of people with global maintainer privileges in Mantis (except for the couple of Mantis admin users). Doesn't sound hard to me. Sebastian From phil at bolthole.com Thu Jan 21 21:27:19 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 21 Jan 2010 12:27:19 -0800 Subject: [csw-maintainers] maintainers email addrs on packages In-Reply-To: <4B58B3CC.8020006@opencsw.org> References: <4B5796E4.6010701@opencsw.org> <4B58B3CC.8020006@opencsw.org> Message-ID: On Thu, Jan 21, 2010 at 12:06 PM, Sebastian Kayser wrote: > >> Since we ALREADY have a database that keeps track of that sort of >> thing.. the mantis database... and that information MUST be kept >> current there.... it doesn't make sense, from the standpoint of "good >> information management practices" to make another separate database. >> It would require even more synchronization between things. >> Simpler is better. > > Currently I can't just grant every maintainer global maintainer > privileges for easier bug handling in Mantis err, what? I dont understand why you even bring that up. Maybe you should look again at the mantis database level setup? mantis supports both "global manager" priviledges, and project-specific manager privileges. that's how we do things right now. "proj-specific mananger" == "owner". mantis supports having more than one "proj-specific manager". So there would be no fixes needed to mantis itself. It would need code changes to the package "registration" process,and changes to the "package web page display" code. But both of those things will need changes anyway, if we ever support multiple people "owning" a package. From skayser at opencsw.org Thu Jan 21 22:03:36 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 21 Jan 2010 22:03:36 +0100 Subject: [csw-maintainers] maintainers email addrs on packages In-Reply-To: References: <4B5796E4.6010701@opencsw.org> <4B58B3CC.8020006@opencsw.org> Message-ID: <4B58C128.4090709@opencsw.org> Philip Brown wrote on 21.01.2010 21:27: > On Thu, Jan 21, 2010 at 12:06 PM, Sebastian Kayser wrote: >>> Since we ALREADY have a database that keeps track of that sort of >>> thing.. the mantis database... and that information MUST be kept >>> current there.... it doesn't make sense, from the standpoint of "good >>> information management practices" to make another separate database. >>> It would require even more synchronization between things. >>> Simpler is better. >> Currently I can't just grant every maintainer global maintainer >> privileges for easier bug handling in Mantis > > err, what? I dont understand why you even bring that up. Maintainers can't for example move a bug from a package they own to another package (which they don't own) where the bug might belong to. They are restricted to "their" packages. > Maybe you should look again at the mantis database level setup? > mantis supports both "global manager" priviledges, and > project-specific manager privileges. > that's how we do things right now. "proj-specific mananger" == "owner". > > mantis supports having more than one "proj-specific manager". > > So there would be no fixes needed to mantis itself. > It would need code changes to the package "registration" process,and > changes to the "package web page display" code. Let me try to put it in words again: in Mantis I would like to grant global maintainer privileges to every OpenCSW maintainer so that they can work more freely and more flexible on all bugs and packages. If I do so, Mantis will _automatically_ remove all the project-level maintainer privileges. >From a Mantis privilege perspective the project-level privileges are simply not required any more. However, as we have semantically overloaded these project-level privileges, things fall apart elsewhere: the package to maintainer relationship will vanish. We have seen this happen with Dago when we gave him global privileges. > But both of those things will need changes anyway, if we ever support > multiple people "owning" a package. So while we are at it, the person you called out for (in assistance for refactoring the packages/ and maintainers/ pages) might as well consider to implement a dedicated CSW meta db (meta sounds more heavyweight than it actually is) in order to make things more robust. At least that's what I would hope for, but it's up to him then. Sebastian From phil at bolthole.com Thu Jan 21 22:47:28 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 21 Jan 2010 13:47:28 -0800 Subject: [csw-maintainers] maintainers email addrs on packages In-Reply-To: <4B58C128.4090709@opencsw.org> References: <4B5796E4.6010701@opencsw.org> <4B58B3CC.8020006@opencsw.org> <4B58C128.4090709@opencsw.org> Message-ID: On Thu, Jan 21, 2010 at 1:03 PM, Sebastian Kayser wrote: > > Let me try to put it in words again: in Mantis I would like to grant > global maintainer privileges to every OpenCSW maintainer so that they > can work more freely and more flexible on all bugs and packages. oh. well, that's an entirely different matter. >If I do > so, Mantis will _automatically_ remove all the project-level maintainer > privileges. However, if you were to plan this, you could easily make a database backup of existing maintainer privs, then do the change, then reapply the individual-project flags afterwards in one batch one. That being said.... IF we were to do this, it would be then more rational to retire the whole "individual project manager" paradigm. HOWEVER.... that has other side effects. Such as, how to separate "people who have global ability to do [stuff like move bugs around]". vs people who are REALLY supposed to be "global admins" ? Woudl be nicer if there were simply the ability to enable "transfer bugs to other proj" in mantis without having to give global admin. >> But both of those things will need changes anyway, if we ever support >> multiple people "owning" a package. > > So while we are at it, the person you called out for (in assistance for > refactoring the packages/ and maintainers/ pages) might as well consider > to implement a dedicated CSW meta db (meta sounds more heavyweight than > it actually is) in order to make things more robust. At least that's > what I would hope for, but it's up to him then. Eh.. technically, we already have a per-package database in existance for other reasons, so it would in reality most likely mean going back to using that as the canonical place for "who owns a package?" From maciej at opencsw.org Fri Jan 22 09:07:00 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 22 Jan 2010 08:07:00 +0000 Subject: [csw-maintainers] Distributing a Python library with GAR, pkgutil, and others Message-ID: When I started writing Python code for OpenCSW such as comparepkg, submitpkg and build_sun_catalog, I started extracting common classes and functions into a library, which is now named opencsw.py: https://opencsw.svn.sourceforge.net/svnroot/opencsw/utilities/ The idea behind a library is to reuse code. I'd like now to use opencsw.py for checkpkg, but I don't know what's the best way of distributing it. For it to be distributed the same way that GAR is, I'd have to make a copy and commit it to the gar repository. Otherwise, I could make a package and make GAR depend on it. But this would make it more difficult to develop the library, because I'd have to go through the long cycle of develop-test-release-install. When I'm developing something relying on opencsw.py, I'm usually also updating the library and adding new functions, so freezing it would be a problem for development. I could add a svn:externals to mgar/v2/... but this would mean that each time a code checkout/update is make, two slow and annoying svn:externals are downloaded. I'd like to avoid that. To recap: - make a copy of the file - easy to do now, but hard to maintain in the future - make a package - makes it hard to develop code - svn:externals - easy to do, easy to develop and easy to maintain, but slow/annoying for people to use Do you have any other/better ideas? Maciej From bwalton at opencsw.org Fri Jan 22 16:06:41 2010 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 22 Jan 2010 10:06:41 -0500 Subject: [csw-maintainers] Distributing a Python library with GAR, pkgutil, and others In-Reply-To: References: Message-ID: <1264172665-sup-6689@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Fri Jan 22 03:07:00 -0500 2010: > I could add a svn:externals to mgar/v2/... but this would mean that > each time a code checkout/update is make, two slow and annoying > svn:externals are downloaded. I'd like to avoid that. Please no! :) > To recap: > - make a copy of the file - easy to do now, but hard to maintain in > the future > - make a package - makes it hard to develop code > - svn:externals - easy to do, easy to develop and easy to maintain, > but slow/annoying for people to use This is the same problem that GAR as a whole faces. I don't have a good answer and as you know, we simply treat GAR as an in-flight object...until we nail down something for GAR, I'd suggest just sticking it with the rest of the mgar/ tree. When we solve the GAR problem (have a stabilized tool that can be packaged), we could re-evaluate then. Not likely much help, but that's my $0.02 CDN. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. From phil at bolthole.com Fri Jan 22 19:31:56 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 22 Jan 2010 10:31:56 -0800 Subject: [csw-maintainers] Distributing a Python library with GAR, pkgutil, and others In-Reply-To: <1264172665-sup-6689@ntdws12.chass.utoronto.ca> References: <1264172665-sup-6689@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Jan 22, 2010 at 7:06 AM, Ben Walton wrote: > > This is the same problem that GAR as a whole faces. ?I don't have a > good answer and as you know, we simply treat GAR as an in-flight > object...until we nail down something for GAR, I'd suggest just > sticking it with the rest of the mgar/ tree. ?When we solve the GAR > problem (have a stabilized tool that can be packaged), we could > re-evaluate then. > Aaaand.. who is working on that, and when is it estimated to happen? [as far as I know, "no-one", and "never" :-( ] Perhaps, Maciej, this might give you a little motivation to work on that problem as well? kill two birds with one stone? ;-) From bwalton at opencsw.org Fri Jan 22 19:43:58 2010 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 22 Jan 2010 13:43:58 -0500 Subject: [csw-maintainers] Distributing a Python library with GAR, pkgutil, and others In-Reply-To: References: <1264172665-sup-6689@ntdws12.chass.utoronto.ca> Message-ID: <1264185435-sup-3518@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Jan 22 13:31:56 -0500 2010: > [as far as I know, "no-one", and "never" :-( ] Dago did some preliminary work on this, but I don't know where it stands. It's a fast moving target at times though, so a package for it could be quite annoying. Having it tracked via svn makes it lighter on its feet...if we could track it as a package _and_ keep it easy to keep updated, that'd be ideal. The lag for mirrors, or the overhead of a manual install is what makes it less than ideal as a package. In some ways it's like automake and friends. My box here has 1.11, but if I want to fiddle with coreutils to compare something between solaris and linux, it yells and says I need 1.11.1. It's a bleeding edge kind of dev tool. > Perhaps, Maciej, this might give you a little motivation to work on > that problem as well? kill two birds with one stone? ;-) Great if so, but it's not a simple problem to solve nicely for all that use it. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Fri Jan 22 20:03:17 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 22 Jan 2010 11:03:17 -0800 Subject: [csw-maintainers] Distributing a Python library with GAR, pkgutil, and others In-Reply-To: <1264185435-sup-3518@ntdws12.chass.utoronto.ca> References: <1264172665-sup-6689@ntdws12.chass.utoronto.ca> <1264185435-sup-3518@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Jan 22, 2010 at 10:43 AM, Ben Walton wrote: > ... > In some ways it's like automake and friends. ?My box here has 1.11, > but if I want to fiddle with coreutils to compare something between > solaris and linux, it yells and says I need 1.11.1. ?It's a bleeding > edge kind of dev tool. This sounds like a fundamental problem to me. We are in the "business" of making reliable packages. Does it make sense to base that on top of a foundation of a "bleeding edge kind of dev tool"? Perhaps someone with the time,and software development experience, could put together a more formal spec for this beast, and then we can nail it down into a more "productional" form? From william at wbonnet.net Sat Jan 23 12:32:41 2010 From: william at wbonnet.net (William Bonnet) Date: Sat, 23 Jan 2010 12:32:41 +0100 Subject: [csw-maintainers] OpenCSW Winter camp is opened Message-ID: <4B5ADE59.8000206@wbonnet.net> Hi, The OpenCSW Winter Camp in Munich is now opened. All of us are now in the hotel, located in Langries. The first morning of meeting is under progress :) You can follow us on the opencsw twitter http://twitter.com/opencsw cheers W. From skayser at opencsw.org Sat Jan 23 16:38:25 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Sat, 23 Jan 2010 16:38:25 +0100 Subject: [csw-maintainers] OpenCSW Winter camp is opened In-Reply-To: <4B5ADE59.8000206@wbonnet.net> References: <4B5ADE59.8000206@wbonnet.net> Message-ID: <4B5B17F1.30705@opencsw.org> Greetings from Winter Camp! William Bonnet wrote on 23.01.2010 12:32: > The OpenCSW Winter Camp in Munich is now opened. All of us are now in > the hotel, located in Langries. The first morning of meeting is under > progress :) > > You can follow us on the opencsw twitter http://twitter.com/opencsw I just pushed a couple of photos to flickr [1]. More photos plus some words on the proceedings later on today. As always, lots of ideas and things to talk about. We could use one week instead of one weekend, even more with the nice winter weather around us :) Off to more discussions, looking forward to some hacking later on. Sebastian [1] http://www.flickr.com/photos/opencsw/sets/72157623142885671/ From rupert at opencsw.org Sat Jan 23 20:11:30 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 23 Jan 2010 20:11:30 +0100 Subject: [csw-maintainers] OpenCSW Winter camp is opened In-Reply-To: <4B5B17F1.30705@opencsw.org> References: <4B5ADE59.8000206@wbonnet.net> <4B5B17F1.30705@opencsw.org> Message-ID: <6af4271001231111j70f1a415nf9a67128373a6b48@mail.gmail.com> On Sat, Jan 23, 2010 at 16:38, Sebastian Kayser wrote: > Greetings from Winter Camp! > > William Bonnet wrote on 23.01.2010 12:32: >> The OpenCSW Winter Camp in Munich is now opened. All of us are now in >> the hotel, located in Langries. The first morning of meeting is under >> progress :) >> >> You can follow us on the opencsw twitter http://twitter.com/opencsw > > I just pushed a couple of photos to flickr [1]. More photos plus some > words on the proceedings later on today. As always, lots of ideas and > things to talk about. We could use one week instead of one weekend, even > more with the nice winter weather around us :) Off to more discussions, > looking forward to some hacking later on. > > Sebastian > > [1] http://www.flickr.com/photos/opencsw/sets/72157623142885671/ ha many thanks - that makes envie to go there :) your python-vs-perl foto remindet me on an interesting article i saw recently about build tools in general: http://code.google.com/p/waf/wiki/WafAndOtherBuildSystems. i guess gar, mgar would fall into this category as well, isn't it? rupert. From phil at bolthole.com Sat Jan 23 22:22:18 2010 From: phil at bolthole.com (Philip Brown) Date: Sat, 23 Jan 2010 13:22:18 -0800 Subject: [csw-maintainers] OpenCSW Winter camp is opened In-Reply-To: <6af4271001231111j70f1a415nf9a67128373a6b48@mail.gmail.com> References: <4B5ADE59.8000206@wbonnet.net> <4B5B17F1.30705@opencsw.org> <6af4271001231111j70f1a415nf9a67128373a6b48@mail.gmail.com> Message-ID: sounds fun I just hope there will be good notes from this one ;-) From bwalton at opencsw.org Sat Jan 23 22:50:22 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 23 Jan 2010 16:50:22 -0500 Subject: [csw-maintainers] OpenCSW Winter camp is opened In-Reply-To: References: <4B5ADE59.8000206@wbonnet.net> <4B5B17F1.30705@opencsw.org> <6af4271001231111j70f1a415nf9a67128373a6b48@mail.gmail.com> Message-ID: <1264283356-sup-2482@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Sat Jan 23 16:22:18 -0500 2010: > sounds fun > I just hope there will be good notes from this one ;-) For the few minutes I've been able to browse, the google wave that has been active is pretty decent. Of course, someone will need to export (publish to blog or dump to alternate format) since you need a wave account to view it presently. -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 Sun Jan 24 01:21:12 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 24 Jan 2010 01:21:12 +0100 Subject: [csw-maintainers] OpenCSW Winter camp is opened In-Reply-To: <4B5B17F1.30705@opencsw.org> References: <4B5ADE59.8000206@wbonnet.net> <4B5B17F1.30705@opencsw.org> Message-ID: <4B5B9278.90308@opencsw.org> Sebastian Kayser wrote on 23.01.2010 16:38: > William Bonnet wrote on 23.01.2010 12:32: >> The OpenCSW Winter Camp in Munich is now opened. All of us are now in >> the hotel, located in Langries. The first morning of meeting is under >> progress :) >> >> You can follow us on the opencsw twitter http://twitter.com/opencsw > > I just pushed a couple of photos to flickr [1]. More photos plus some > words on the proceedings later on today. As always, lots of ideas and > things to talk about. We could use one week instead of one weekend, even > more with the nice winter weather around us :) Off to more discussions, > looking forward to some hacking later on. Won't get any written proceedings out of the door today (my brain feels like after a core meltdown), but if someone with a webcam wants to join in and say "hello" on short notice, we still have a camcorder sitting on the table and are likely to sit around for another hour hacking on things. Either iChat, Google Talk, or Skype should be fine. Just drop by on #opencsw on freenode and ping me (skayser). Sebastian From maciej at opencsw.org Sun Jan 24 15:17:43 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 24 Jan 2010 14:17:43 +0000 Subject: [csw-maintainers] Wintercamp minutes in Google Wave Message-ID: I've shared the Wintercamp waves with a newly created Google Group, called opencsw-maintainers. People who would like to read the wave, can join this group, using Google accounts. When people have joined the group, they can go to http://wave.google.com - the wave should be in your wave inboxes. The access to the waves will be read/write, so all members will be able to continue the discussions started on the Wintercamp, and there's a bunch of pretty interesting ones there. There are 2 waves from 2 days, containing a transcript of the discussions during the meetings. We'll also provide a read-only export, but we don't know yet what will be the exact way, perhaps a HTML or a PDF file. Maciej [1] https://groups.google.com/group/opencsw-maintainers From ihsan at opencsw.org Sun Jan 24 20:11:17 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 24 Jan 2010 20:11:17 +0100 Subject: [csw-maintainers] Ganglia for sparcv9 In-Reply-To: <4B53BBA5.6010607@opencsw.org> References: <4AE87999.6020401@opencsw.org> <777D637C-111E-4F5B-8562-501B9F42351E@opencsw.org> <4B48FA2F.2020806@opencsw.org> <4B538451.7030002@opencsw.org> <4B53BBA5.6010607@opencsw.org> Message-ID: <4B5C9B55.2090409@opencsw.org> Hello Roger, Am 18.01.10 02:38, schrieb Roger H?kansson: >> I'm running into a problem with Pango. We discussed this issue here >> before, but I don't remember how it ended. >> >> http://pastebin.ca/1755178 >> > > The lib does contain what you need, but I'm pretty sure that if you > check config.log you will find that every test have failed due to: > > Undefined first referenced > symbol in file > XSolarisIASetProcessInfo /usr/openwin/lib/libX11.so.4 > > The problem is related to what I wrote last week regarding libcairo. > > Until the libcairo-problem is fixed, you might be able to get around it > by adding this to your Makefile > > EXTRA_SOS_LD_FLAGS = -L$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) > CONFIGURE_ARGS += --x-includes=$(prefix)/X11/include > CONFIGURE_ARGS += --x-libraries=$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) > > Using those changes I'm able to build rrdtool using what's in GAR. Thanks for your help. Unfortunately, I was not able to build rrdtool on Solaris 9 with Studio 12 http://www.pastebin.ca/1764263 . Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Sun Jan 24 20:48:39 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 24 Jan 2010 20:48:39 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B54D11F.3000608@opencsw.org> <1263850046-sup-8178@ntdws12.chass.utoronto.ca> Message-ID: <4B5CA417.5060708@opencsw.org> Am 18.01.10 23:36, schrieb Maciej (Matchek) Blizinski: >>> newpkgs exists already: https://lists.opencsw.org/mailman/listinfo/newpkgs >> >> pkgreleases ? > > The existing newpkgs list sounds like it really means pkgreleases, > perhaps it could be renamed. (can you move list archives too?) > > The new list would be something along the lines of pkgsubmissions > (which is long, but descriptive). newpkgs will be renamed to pkgsubmissions. newpkgs will be the new lists name? Is that fine for everybody? Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From skayser at opencsw.org Sun Jan 24 21:48:45 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 24 Jan 2010 21:48:45 +0100 Subject: [csw-maintainers] Ganglia for sparcv9 In-Reply-To: <4B5C9B55.2090409@opencsw.org> References: <4AE87999.6020401@opencsw.org> <777D637C-111E-4F5B-8562-501B9F42351E@opencsw.org> <4B48FA2F.2020806@opencsw.org> <4B538451.7030002@opencsw.org> <4B53BBA5.6010607@opencsw.org> <4B5C9B55.2090409@opencsw.org> Message-ID: <4B5CB22D.4050207@opencsw.org> Ihsan Dogan wrote on 24.01.2010 20:11: > Am 18.01.10 02:38, schrieb Roger H?kansson: > >>> I'm running into a problem with Pango. We discussed this issue here >>> before, but I don't remember how it ended. >>> >>> http://pastebin.ca/1755178 >>> >> The lib does contain what you need, but I'm pretty sure that if you >> check config.log you will find that every test have failed due to: >> >> Undefined first referenced >> symbol in file >> XSolarisIASetProcessInfo /usr/openwin/lib/libX11.so.4 >> >> The problem is related to what I wrote last week regarding libcairo. >> >> Until the libcairo-problem is fixed, you might be able to get around it >> by adding this to your Makefile >> >> EXTRA_SOS_LD_FLAGS = -L$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) >> CONFIGURE_ARGS += --x-includes=$(prefix)/X11/include >> CONFIGURE_ARGS += --x-libraries=$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) >> >> Using those changes I'm able to build rrdtool using what's in GAR. > > Thanks for your help. Unfortunately, I was not able to build rrdtool on > Solaris 9 with Studio 12 http://www.pastebin.ca/1764263 . The crucial part from the pastebin is this one ... "rrd_restore.c", line 19: cannot find include file: ... Let's see where this file lives (/q ceeswi on freenode). 21:40 fsearch xmlreader.h 21:41 [libxml2_devel] /opt/csw/include/libxml2/libxml/xmlreader.h Change your EXTRA_INC in the GAR Makefile from EXTRA_INC += $(prefix)/include/libxml2/libxml to EXTRA_INC += $(prefix)/include/libxml2 and you should be fine. Sebastian From jeff at cjsa.com Mon Jan 25 05:54:55 2010 From: jeff at cjsa.com (Jeffery Small) Date: Mon, 25 Jan 2010 04:54:55 GMT Subject: [csw-maintainers] curlrt Message-ID: When I just updated my catalog, I find the following: curl_rt 7.19.7,REV=2010.01.15 curlrt 7.19.7,REV=2010.01.15 7.19.7,REV=2009.11.05 Notice that the curl package in the catalog is older than the installed package? Hmmmm, how did this happen. I previously uninstalled curlrt and then installed the new curl_rt package. So let's try again. I first uninstalled curlrt and then I look and curl_rt is also gone??? So I reinstall curl_rt and I see that both curlrt and curl_rt are once again listed as noted above. So what's up? Why does curlrt get listed and why is it still showing up in the catalog as an older version? Is this expected behavior or is something wrong with the install files which is mixing these two names improperly? Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From dam at opencsw.org Mon Jan 25 08:55:00 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 25 Jan 2010 08:55:00 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <4B5CA417.5060708@opencsw.org> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B54D11F.3000608@opencsw.org> <1263850046-sup-8178@ntdws12.chass.utoronto.ca> <4B5CA417.5060708@opencsw.org> Message-ID: <0444857F-28B4-437A-BF36-939AAB277B77@opencsw.org> Hi Ihsan, Am 24.01.2010 um 20:48 schrieb Ihsan Dogan: > Am 18.01.10 23:36, schrieb Maciej (Matchek) Blizinski: >>>> newpkgs exists already: https://lists.opencsw.org/mailman/listinfo/newpkgs >>> >>> pkgreleases ? >> >> The existing newpkgs list sounds like it really means pkgreleases, >> perhaps it could be renamed. (can you move list archives too?) >> >> The new list would be something along the lines of pkgsubmissions >> (which is long, but descriptive). > > newpkgs will be renamed to pkgsubmissions. > newpkgs will be the new lists name? > > Is that fine for everybody? I would prefer pkgreleases over pkgsubmissions as they more tend to go out than go in after that email. The new name is perfect. Best regards -- Dago From dam at opencsw.org Mon Jan 25 09:01:12 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 25 Jan 2010 09:01:12 +0100 Subject: [csw-maintainers] Problem: curlrt and curldevel still in the catalog In-Reply-To: References: Message-ID: Hi Jeffery, Am 25.01.2010 um 05:54 schrieb Jeffery Small: > When I just updated my catalog, I find the following: > > curl_rt 7.19.7,REV=2010.01.15 > curlrt 7.19.7,REV=2010.01.15 > 7.19.7,REV=2009.11.05 > > Notice that the curl package in the catalog is older than the > installed > package? > > Hmmmm, how did this happen. I previously uninstalled curlrt and then > installed the new curl_rt package. In theory this should not have been necessary as only the catalog name changed, not the package name. > So let's try again. I first > uninstalled curlrt and then I look and curl_rt is also gone??? > > So I reinstall curl_rt and I see that both curlrt and curl_rt are once > again listed as noted above. So what's up? Why does curlrt get > listed and > why is it still showing up in the catalog as an older version? > > Is this expected behavior or is something wrong with the install > files which > is mixing these two names improperly? dam at login [login]:/export/mirror/opencsw/current/sparc/5.8 > grep ^curl catalog curl 7.19.7,REV=2010.01.15 CSWcurl curl-7.19.7,REV=2010.01.15-SunOS5.8- sparc-CSW.pkg.gz 97acef51f585128c058e975270b489d9 107178 CSWcommon| CSWiconv|CSWlibidn|CSWlibnet|CSWoldaprt|CSWosslrt|CSWsasl|CSWzlib| CSWcurlrt none curl_devel 7.19.7,REV=2010.01.15 CSWcurldevel curl_devel-7.19.7,REV=2010.01.15-SunOS5.8-sparc-CSW.pkg.gz fde89710be8854e1bdd6d0ee4df2aa7a 130094 CSWcommon|CSWcurlrt none curl_rt 7.19.7,REV=2010.01.15 CSWcurlrt curl_rt-7.19.7,REV=2010.01.15- SunOS5.8-sparc-CSW.pkg.gz 7f4f391a1dafea8f5449ffb86f78b631 622538 CSWcommon|CSWlibidn|CSWlibnet|CSWoldaprt|CSWosslrt|CSWzlib|CSWsasl none curldevel 7.19.7,REV=2009.11.05 CSWcurldevel curldevel-7.19.7,REV=2009.11.05-SunOS5.8-sparc-CSW.pkg.gz dfc58af319883ddd9e66158eb2ae6f21 131730 CSWcurlrt|CSWcommon none curlrt 7.19.7,REV=2009.11.05 CSWcurlrt curlrt-7.19.7,REV=2009.11.05- SunOS5.8-sparc-CSW.pkg.gz f07ae1725636672cf126a9f6a248f53f 622453 CSWlibidn|CSWlibnet|CSWoldaprt|CSWosslrt|CSWzlib|CSWsasl|CSWcommon none There is still curlrt and curldevel in the catalog which should have been gone after the rename. Phil: Would you mind having a look and remove the previous packages from the catalog? Thanks for the report! Best regards -- Dago From bonivart at opencsw.org Mon Jan 25 09:39:13 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 25 Jan 2010 09:39:13 +0100 Subject: [csw-maintainers] Problem: curlrt and curldevel still in the catalog In-Reply-To: References: Message-ID: <625385e31001250039t3cc6b640j30913936d99832d9@mail.gmail.com> On Mon, Jan 25, 2010 at 9:01 AM, Dagobert Michelsen wrote: > There is still curlrt and curldevel in the catalog which should have been > gone > after the rename. This was easily picked up by chkcat: ERROR! CSWcurldevel exists more than once. ERROR! CSWcurlrt exists more than once. -- /peter From skayser at opencsw.org Mon Jan 25 11:27:04 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 25 Jan 2010 11:27:04 +0100 Subject: [csw-maintainers] Problem: curlrt and curldevel still in the catalog In-Reply-To: <625385e31001250039t3cc6b640j30913936d99832d9@mail.gmail.com> References: <625385e31001250039t3cc6b640j30913936d99832d9@mail.gmail.com> Message-ID: <4B5D71F8.3040708@opencsw.org> Peter Bonivart wrote on 25.01.2010 09:39: > On Mon, Jan 25, 2010 at 9:01 AM, Dagobert Michelsen wrote: >> There is still curlrt and curldevel in the catalog which should have been >> gone >> after the rename. > > This was easily picked up by chkcat: > > ERROR! CSWcurldevel exists more than once. > ERROR! CSWcurlrt exists more than once. Could it be hooked into the release process then to avoid such errors in the future? Sebastian From bwalton at opencsw.org Fri Jan 1 02:46:20 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 31 Dec 2009 20:46:20 -0500 Subject: [csw-maintainers] how to use the gnu linker? or is there anything else what can be done? In-Reply-To: <6af4270912310934p2a8f9bb9r104b102b49558d4a@mail.gmail.com> References: <6af4270912310856jdca43b9s5361db04adf5d72d@mail.gmail.com> <1262280366-sup-6237@ntdws12.chass.utoronto.ca> <6af4270912310934p2a8f9bb9r104b102b49558d4a@mail.gmail.com> Message-ID: <1262310175-sup-6266@ntdws12.chass.utoronto.ca> Excerpts from rupert THURNER's message of Thu Dec 31 12:34:01 -0500 2009: > i am using GARCOMPILER = GCC, is this different? No, that'll work fine, defaulting to gcc4. > i think the options are hardcoded, yes. therefor i thought gld might > fix this - and it would be easy :) Ok, if you're already using gcc, then the problem you're fighting is likely an assumption in configure that when gcc is used, the linker is gnu-ld. I'd first look to see if configure has a 'magic' option that can help. Next, I'd look at fixing the assumption in the configure script (submitting upstream if you craft something general). I've had trouble trying to override which ld gets used. If you do resort to this and make it work, I'd be interested in hearing/seeing. 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 Jan 1 14:54:03 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 1 Jan 2010 14:54:03 +0100 Subject: [csw-maintainers] clean without cleaning the downloaded file, unpackaged file ? In-Reply-To: <6af4270912311004k73ae3a67m677af8f684c931fc@mail.gmail.com> References: <6af4270912311004k73ae3a67m677af8f684c931fc@mail.gmail.com> Message-ID: <1490E460-2521-4D98-88B7-3A147A33337C@opencsw.org> Hi Rupert, Am 31.12.2009 um 19:04 schrieb rupert THURNER: > how can the build result can be cleaned without deleting the > downloaded file, This is not a problem as you should do a gmake garchive which archives the downladed sources to /home/src and grabs it from there at download time. > or maybe even avoiding unzipping it again? i try to > build qt4 as base for kde4, and the download is more than 100 mb. For this kind there is no special target. I would recommend to just gmake clean && gmake again after you tweak args. > as i got an error on build8s, i also tried to build on build10s, and i > am wondering if it is correct that it says "sparvc8": > > rupert at build10s:~/mgar/pkg/qt4/trunk > $ gmake package > gar/gar.pkg.mk:682: *** You are building this package on a > non-requested platform host 'build10s'. The follow platforms were > requested: > gar/gar.pkg.mk:682: *** - solaris8-sparc to be build on host 'build8s' Yes. Because the default build hosts for Sparc are on Solaris 8 only: If you want to build on another Solaris release you have to adjust PACKAGING_PLATFORMS. Just grep for this in the Makefiles for examples. Best regards -- Dago From rupert at opencsw.org Fri Jan 1 16:07:19 2010 From: rupert at opencsw.org (rupert THURNER) Date: Fri, 1 Jan 2010 16:07:19 +0100 Subject: [csw-maintainers] parallel build not working any more? Message-ID: <6af4271001010707k445229a7v3f83048503da36a9@mail.gmail.com> for some time setting PARALLELMFLAGS="-l -j $(psrinfo | wc -l)" enabled parallel builds. since a couple of weeks this seems not to work any more. i am trying to build qt4, and apr on build8s with either "gmake package" or "gmake platforms" and 90% of the system is idle, one thread is used. how could one enable this again ? rupert. From rupert at opencsw.org Fri Jan 1 18:58:46 2010 From: rupert at opencsw.org (rupert THURNER) Date: Fri, 1 Jan 2010 18:58:46 +0100 Subject: [csw-maintainers] pkgmk: ERROR: unable to obtain temporary file resources, errno=28 Message-ID: <6af4271001010958x2ca2c707u62a1d25b29f12604@mail.gmail.com> where does this error come from? pkgmk: ERROR: unable to obtain temporary file resources, errno=28 rupert at build8s:~/mgar/pkg/apr/trunk $ gmake repackage ==> Reset packaging state for CSWapr (rupert-build8s) [===== NOW BUILDING: apr-1.3.9 =====] [prerequisite] complete for apr. [fetch] complete for apr. [checksum] complete for apr. [checksum-global] complete for apr. [checksum-modulated] complete for apr. [===== NOW BUILDING: apr-1.3.9 MODULATION global: ISA= =====] [extract-modulated] complete for apr. [===== Building modulation 'isa-sparcv8' on host 'build8s' =====] gmake PLATFORM=solaris8-sparc MODULATION=isa-sparcv8 ISA=sparcv8 merge-modulated gmake[1]: Entering directory `/home/rupert/mgar/pkg/apr/trunk' [===== NOW BUILDING: apr-1.3.9 MODULATION isa-sparcv8: ISA=sparcv8 =====] [extract-modulated] complete for apr. [patch-modulated] complete for apr. [configure-modulated] complete for apr. [test-modulated] complete for apr. ==> fixconfig: /home/rupert/mgar/pkg/apr/trunk/work/solaris8-sparc/install-isa-sparcv8/opt/csw/lib ==> fixconfig: /home/rupert/mgar/pkg/apr/trunk/work/solaris8-sparc/install-isa-sparcv8/opt/csw/bin gmake[1]: Leaving directory `/home/rupert/mgar/pkg/apr/trunk' [===== Building modulation 'isa-sparcv9' on host 'build8s' =====] gmake PLATFORM=solaris8-sparc MODULATION=isa-sparcv9 ISA=sparcv9 merge-modulated gmake[1]: Entering directory `/home/rupert/mgar/pkg/apr/trunk' [===== NOW BUILDING: apr-1.3.9 MODULATION isa-sparcv9: ISA=sparcv9 =====] [extract-modulated] complete for apr. [patch-modulated] complete for apr. [configure-modulated] complete for apr. [test-modulated] complete for apr. ==> fixconfig: /home/rupert/mgar/pkg/apr/trunk/work/solaris8-sparc/install-isa-sparcv9/opt/csw/lib/64 ==> fixconfig: /home/rupert/mgar/pkg/apr/trunk/work/solaris8-sparc/install-isa-sparcv9/opt/csw/bin/sparcv9 gmake[1]: Leaving directory `/home/rupert/mgar/pkg/apr/trunk' [merge-license] complete for apr. [merge] complete for apr. ==> Processing CSWapr.gspec mkp: processing file://work/solaris8-sparc/build-global/CSWapr.gspec mkp: set ENV{bitname} = 'apr' mkp: set ENV{pkgname} = 'CSWapr' mkp: include file://%{PKGLIB}/csw_dyngspec.gspec mkp: replacing %{PKGLIB} with '/home/rupert/mgar/pkg/apr/trunk/gar/pkglib' mkp: include file://%{PKGLIB}/csw_vars.gspec mkp: replacing %{PKGLIB} with '/home/rupert/mgar/pkg/apr/trunk/gar/pkglib' mkp: replacing %{GARCH} with 'sparc' mkp: set ENV{arch} = 'sparc' mkp: replacing %{SPKG_DESC} with 'Apache Portable Runtime' mkp: set ENV{desc} = 'Apache Portable Runtime' mkp: replacing %{SPKG_PKGFILE} with '%{bitname}-%{SPKG_VERSION},%{SPKG_REVSTAMP}-%{SPKG_OSNAME}-%{arch}-UNCOMMITTED.pkg' mkp: replacing %{bitname} with 'apr' mkp: replacing %{SPKG_VERSION} with '1.3.9' mkp: replacing %{SPKG_REVSTAMP} with 'REV=2010.01.01' mkp: replacing %{SPKG_OSNAME} with 'SunOS5.8' mkp: replacing %{arch} with 'sparc' mkp: set ENV{pkgfile} = 'apr-1.3.9,REV=2010.01.01-SunOS5.8-sparc-UNCOMMITTED.pkg' mkp: replacing %{bitname} with 'apr' mkp: set ENV{RC_INIT_SCRIPT} = 'cswapr' mkp: replacing %{bitname} with 'apr' mkp: set ENV{SMF_SCRIPT} = 'svc-cswapr' mkp: replacing %{bitname} with 'apr' mkp: set ENV{SMF_MANIFEST} = 'cswapr.xml' mkp: include file://%{PKGLIB}/csw_prototype.gspec mkp: replacing %{PKGLIB} with '/home/rupert/mgar/pkg/apr/trunk/gar/pkglib' mkp: include file://%{PKGLIB}/std_depend.gspec mkp: replacing %{PKGLIB} with '/home/rupert/mgar/pkg/apr/trunk/gar/pkglib' mkp: Processing prototype mkp: WARNING: Using existing CSWapr.prototype-sparc mkp: Processing depend mkp: WARNING: Using existing CSWapr.depend mkp: Processing pkginfo mkp: WARNING: Using existing CSWapr.pkginfo mkp: Writing admin entries to CSWapr.prototype-sparc mkp: exec( pkgmk -d /home/rupert/spool/5.8-sparc -r /home/rupert/mgar/pkg/apr/trunk/work/solaris8-sparc/pkgroot -b /home/rupert/mgar/pkg/apr/trunk/work/solaris8-sparc/pkgroot -f /home/rupert/mgar/pkg/apr/trunk/work/solaris8-sparc/build-global/CSWapr.prototype-sparc WORKDIR_FIRSTMOD=../build-isa-sparcv8 ) ## Building pkgmap from package prototype file. pkgmk: ERROR: unable to obtain temporary file resources, errno=28 ## Packaging was not successful. mkp: ERROR: Failed to create CSWapr using /home/rupert/mgar/pkg/apr/trunk/work/solaris8-sparc/build-global/CSWapr.prototype-sparc gmake: *** [package-CSWapr] Error 2 From maciej at opencsw.org Fri Jan 1 21:33:27 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 1 Jan 2010 20:33:27 +0000 Subject: [csw-maintainers] pkgmk: ERROR: unable to obtain temporary file resources, errno=28 In-Reply-To: <6af4271001010958x2ca2c707u62a1d25b29f12604@mail.gmail.com> References: <6af4271001010958x2ca2c707u62a1d25b29f12604@mail.gmail.com> Message-ID: On Fri, Jan 1, 2010 at 5:58 PM, rupert THURNER wrote: > where does this error come from? > pkgmk: ERROR: unable to obtain temporary file resources, errno=28 Can you try trussing it? truss -o /var/tmp/mkp.truss From maciej at opencsw.org Fri Jan 1 21:33:56 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 1 Jan 2010 20:33:56 +0000 Subject: [csw-maintainers] pkgmk: ERROR: unable to obtain temporary file resources, errno=28 In-Reply-To: References: <6af4271001010958x2ca2c707u62a1d25b29f12604@mail.gmail.com> Message-ID: On Fri, Jan 1, 2010 at 8:33 PM, Maciej (Matchek) Blizinski wrote: > On Fri, Jan 1, 2010 at 5:58 PM, rupert THURNER wrote: >> where does this error come from? >> pkgmk: ERROR: unable to obtain temporary file resources, errno=28 > > Can you try trussing it? > > truss -o /var/tmp/mkp.truss I think I found the problem (that's build8s): maciej at build8s [build8s]:~ > df -k /var/tmp Filesystem kbytes used avail capacity Mounted on / 11188159 11188159 0 100% / From maciej at opencsw.org Fri Jan 1 21:38:14 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 1 Jan 2010 20:38:14 +0000 Subject: [csw-maintainers] pkgmk: ERROR: unable to obtain temporary file resources, errno=28 In-Reply-To: References: <6af4271001010958x2ca2c707u62a1d25b29f12604@mail.gmail.com> Message-ID: [+buildfarm] On Fri, Jan 1, 2010 at 8:33 PM, Maciej (Matchek) Blizinski wrote: > On Fri, Jan 1, 2010 at 8:33 PM, Maciej (Matchek) Blizinski > wrote: >> On Fri, Jan 1, 2010 at 5:58 PM, rupert THURNER wrote: >>> where does this error come from? >>> pkgmk: ERROR: unable to obtain temporary file resources, errno=28 >> >> Can you try trussing it? >> >> truss -o /var/tmp/mkp.truss > > I think I found the problem (that's build8s): > > maciej at build8s [build8s]:~ > df -k /var/tmp > Filesystem ? ? ? ? ? ?kbytes ? ?used ? avail capacity ?Mounted on > / ? ? ? ? ? ? ? ? ? ?11188159 11188159 ? ? ? 0 ? 100% ? ?/ > From dam at opencsw.org Fri Jan 1 22:34:55 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 1 Jan 2010 22:34:55 +0100 Subject: [csw-maintainers] pkgmk: ERROR: unable to obtain temporary file resources, errno=28 In-Reply-To: References: <6af4271001010958x2ca2c707u62a1d25b29f12604@mail.gmail.com> Message-ID: Hi, Am 01.01.2010 um 21:38 schrieb Maciej (Matchek) Blizinski: > [+buildfarm] > > On Fri, Jan 1, 2010 at 8:33 PM, Maciej (Matchek) Blizinski > wrote: >> On Fri, Jan 1, 2010 at 8:33 PM, Maciej (Matchek) Blizinski >> wrote: >>> On Fri, Jan 1, 2010 at 5:58 PM, rupert THURNER >>> wrote: >>>> where does this error come from? >>>> pkgmk: ERROR: unable to obtain temporary file resources, errno=28 >>> >>> Can you try trussing it? >>> >>> truss -o /var/tmp/mkp.truss >> >> I think I found the problem (that's build8s): >> >> maciej at build8s [build8s]:~ > df -k /var/tmp >> Filesystem kbytes used avail capacity Mounted on >> / 11188159 11188159 0 100% / Fixed. I guess I will set quota on Hudson now :-( Best regards -- Dago From dam at opencsw.org Fri Jan 1 22:38:59 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 1 Jan 2010 22:38:59 +0100 Subject: [csw-maintainers] parallel build not working any more? In-Reply-To: <6af4271001010707k445229a7v3f83048503da36a9@mail.gmail.com> References: <6af4271001010707k445229a7v3f83048503da36a9@mail.gmail.com> Message-ID: Hi Rupert, Am 01.01.2010 um 16:07 schrieb rupert THURNER: > for some time setting > PARALLELMFLAGS="-l -j $(psrinfo | wc -l)" > enabled parallel builds. > > since a couple of weeks this seems not to work any more. i am trying > to build qt4, and apr on build8s with either "gmake package" or "gmake > platforms" and 90% of the system is idle, one thread is used. how > could one enable this again ? This currently does not work as PARALLELMFLAGS is not propagated with platforms. Meanwhile you can set this in your .garrc which should then work an on all your recipes or temporarily in the Makefile you are working on. I opened a bug for this: Best regards -- Dago From maciej at opencsw.org Sat Jan 2 12:10:00 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 2 Jan 2010 11:10:00 +0000 Subject: [csw-maintainers] Our mailing list footer Message-ID: Our mailing list footer has been recently changed and now looks like this: _______________________________________________ maintainers mailing list maintainers at lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers This mailing lists archive is PUBLIC. Two issues: 1. There's an apostrophe missing in one of the words. 2. Somebody's capslock must've been jammed. Please fix. From rupert at opencsw.org Sat Jan 2 12:18:24 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 2 Jan 2010 12:18:24 +0100 Subject: [csw-maintainers] what is different on buildfarm? mercurial tests take long - or fail Message-ID: <6af4271001020318k5f9fe830gd5378c9bf96e267b@mail.gmail.com> while testing mercurial-1.4.2 i noticed that the tests take long - or forever on build8s. and they fail with network errors on build10s. as i did not have time to wait if they end at 8s, i breaked them and i tried 1.4.1 as well, which also did not complete in a reasonable time. so i wonder what might cause this. the new python? the new ipv6? something else? here the output of a "ps" while waiting for something to happen: rupert at build8s:~/tmp $ /usr/ucb/ps aguxwwwww | grep test rupert 7748 0.0 0.016920 2096 ? S 02:50:25 0:00 /opt/csw/bin/python /tmp/hgtests.8Qqkub/install/bin/hg serve -p 20137 -d --pid-file=hg.pid -E errors.log --daemon-pipefds=3,4 rupert 9810 0.0 0.0 2168 1536 pts/35 S 04:23:46 0:00 grep test rupert 12261 0.0 0.0 2232 1704 pts/60 S 04:11:39 0:00 /bin/sh /home/rupert/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build-isa-sparcv8/mercurial-1.4.1/tests/test-push-http rupert 12341 0.0 0.116920 6064 ? S 04:11:48 0:00 /opt/csw/bin/python /tmp/hgtests.ZTfh5M/install/bin/hg serve -p 20092 -d --pid-file=hg.pid -E errors.log --daemon-pipefds=3,4 rupert 12356 0.0 0.111784 8416 pts/60 S 04:11:49 0:00 /opt/csw/bin/python /tmp/hgtests.ZTfh5M/install/bin/hg --cwd ../test2 push http://localhost:20092/ rupert 15345 0.0 0.116920 2464 ? S 03:37:32 0:00 /opt/csw/bin/python /tmp/hgtests.vKPSKj/install/bin/hg serve -p 20095 -d --pid-file=hg.pid -E errors.log --daemon-pipefds=3,4 rupert 17196 0.0 0.1 9208 5376 pts/60 S 04:04:44 0:01 python run-tests.py -j30 rupert 18094 0.0 0.110232 6008 pts/60 S 04:04:56 0:01 /opt/csw/bin/python run-tests.py --jobs=1 --port=20059 --with-hg=/tmp/hgtests.ZTfh5M/install/bin/hg --timeout=180 --child=15 --port=20092 --tmpdir /tmp/hgtests.ZTfh5M/child11 test-audit-path test-command-template test-convert-hg-startrev test-diff-newlines test-git-export test-http-clone-r test-issue619 test-merge5 test-mv-cp-st-diff test-push-http test-resolve test-trusted.py rupert 18123 0.0 0.110232 5312 pts/60 S 04:04:57 0:01 /opt/csw/bin/python run-tests.py --jobs=1 --port=20059 --with-hg=/tmp/hgtests.ZTfh5M/install/bin/hg --timeout=180 --child=30 --port=20137 --tmpdir /tmp/hgtests.ZTfh5M/child26 test-branchmap test-convert-bzr-ghosts test-copy test-empty-file test-hgweb-auth.py test-inotify-issue1371 test-merge-force test-mq-qclone-http test-patch test-rebase-parameters test-static-http rupert 23378 0.0 0.0 2232 1128 pts/60 S 04:06:03 0:00 /bin/sh /home/rupert/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build-isa-sparcv8/mercurial-1.4.1/tests/test-mq-qclone-http rupert 24084 0.0 0.1 9360 4992 pts/60 S 04:06:13 0:00 python /home/rupert/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build-isa-sparcv8/mercurial-1.4.1/tests/get-with-headers.py localhost:20137 /?style=raw on build10s, using the tip of the crew repository, i get "network is not reachable" errors: rupert at build10s:~/hg-crew-10s $ python setup.py build ... rupert at build10s:~/hg-crew-10s/tests $ python run-tests.py -j 30 .. ERROR: /home/rupert/hg-crew-10s/tests/test-bad-pull output changed and returned error code 1 --- /home/rupert/hg-crew-10s/tests/test-bad-pull.out +++ /home/rupert/hg-crew-10s/tests/test-bad-pull.err @@ -1,5 +1,6 @@ -abort: error: Connection refused +abort: error: Network is unreachable 255 copy: No such file or directory -abort: HTTP Error 404 +abort: error: Network is unreachable 0 +/home/rupert/hg-crew-10s/tests/test-bad-pull: kill: no such process !... ERROR: /home/rupert/hg-crew-10s/tests/test-branchmap output changed and returned error code 1 ERROR: /home/rupert/hg-crew-10s/tests/test-webraw output changed --- /home/rupert/hg-crew-10s/tests/test-webraw.out +++ /home/rupert/hg-crew-10s/tests/test-webraw.err @@ -1,10 +1,18 @@ -200 Script output follows -content-type: text/plain -content-length: 157 -content-disposition: inline; filename="some \"text\".txt" - -This is just some random text -that will go inside the file and take a few lines. -It is very boring to read, but computers don't -care about things like that. -host - - [date] "GET /?f=a23bf1310f6e;file=sub/some%20%22text%22.txt;style=raw HTTP/1.1" 200 - +Traceback (most recent call last): + File "/home/rupert/hg-crew-10s/tests/get-with-headers.py", line 17, in + conn.request("GET", sys.argv[2]) + File "/opt/csw/lib/python/httplib.py", line 898, in request + self._send_request(method, url, body, headers) + File "/opt/csw/lib/python/httplib.py", line 935, in _send_request + self.endheaders() + File "/opt/csw/lib/python/httplib.py", line 892, in endheaders + self._send_output() + File "/opt/csw/lib/python/httplib.py", line 764, in _send_output + self.send(msg) + File "/opt/csw/lib/python/httplib.py", line 723, in send + self.connect() + File "/opt/csw/lib/python/httplib.py", line 704, in connect + self.timeout) + File "/opt/csw/lib/python/socket.py", line 514, in create_connection + raise error, msg +socket.error: [Errno 128] Network is unreachable rupert. From maciej at opencsw.org Sat Jan 2 12:28:31 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 2 Jan 2010 11:28:31 +0000 Subject: [csw-maintainers] Readline in sqlite3, changes to other people's packages Message-ID: I noticed that the readline frontend (the "sqlite3" command) doesn't have readline, so I recompiled it with readline support. http://sourceforge.net/apps/trac/gar/changeset/7799 I want readline because it's useful when working with the "sqlite3" utility to examine database contents. I've put it into testing. Ruper later bumped up the version to .21, so I've rebuilt sqlite3 again. I was thinking about a more general case. Let's say there's a package that I'm willing to put some work into, such as this one. It's much quicker to just fix the issue myself than ti file a bug and wait for the maintainer to respond. However, when I submit the package for release, I become the maintainer instead. Can we have a process in which: - I can introduce a change to a package and rebuild it - the package maintainer (here: Dago) approves the change - I submit it for release - I don't become the maintainer. Maciej From maciej at opencsw.org Sat Jan 2 12:40:41 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 2 Jan 2010 11:40:41 +0000 Subject: [csw-maintainers] Better shared object dependency checking in checkpkg out for testing In-Reply-To: References: Message-ID: On Tue, Dec 29, 2009 at 11:58 PM, Maciej (Matchek) Blizinski wrote: > I have one more bit to implement: checking the data modification > timestamp of /var/sadm/install/contents and updating the cache. This is done. I've implemented all the features I wanted, I would like to focus on merging my change to the main v2 branch. Here's the list of changes: http://sourceforge.net/apps/trac/gar/log/csw/mgar/gar/v2-checkpkg I haven't received any comments about the new code, which makes me think that people haven't tried it yet. My question to Dago: What would you like to be done with relation to merging back to v2? From ihsan at opencsw.org Sun Jan 3 21:34:14 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 03 Jan 2010 21:34:14 +0100 Subject: [csw-maintainers] Our mailing list footer In-Reply-To: References: Message-ID: <4B40FF46.5070400@opencsw.org> Am 02.01.10 12:10, schrieb Maciej (Matchek) Blizinski: > Our mailing list footer has been recently changed and now looks like this: [...] > Two issues: > 1. There's an apostrophe missing in one of the words. > 2. Somebody's capslock must've been jammed. Please fix. This is fixed now. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Mon Jan 4 10:33:53 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 4 Jan 2010 10:33:53 +0100 Subject: [csw-maintainers] [csw-buildfarm] what is different on buildfarm? mercurial tests take long - or fail In-Reply-To: <6af4271001020318k5f9fe830gd5378c9bf96e267b@mail.gmail.com> References: <6af4271001020318k5f9fe830gd5378c9bf96e267b@mail.gmail.com> Message-ID: <841FE230-13C7-4CEC-9202-B01167FE8730@opencsw.org> Hi Rupert, Am 02.01.2010 um 12:18 schrieb rupert THURNER: > while testing mercurial-1.4.2 i noticed that the tests take long - or > forever on build8s. and they fail with network errors on build10s. > > as i did not have time to wait if they end at 8s, i breaked them and i > tried 1.4.1 as well, which also did not complete in a reasonable time. > > so i wonder what might cause this. the new python? the new ipv6? > something else? You may want to try test8s which doesn't have the novelties above. If you want to have net access from the build machines you have to use a proxy. Best regards -- Dago From dam at opencsw.org Mon Jan 4 10:36:09 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 4 Jan 2010 10:36:09 +0100 Subject: [csw-maintainers] Readline in sqlite3, changes to other people's packages In-Reply-To: References: Message-ID: <2C53ED9C-D99A-4B88-9C7F-4849E55EB024@opencsw.org> Hi Maciej, Am 02.01.2010 um 12:28 schrieb Maciej (Matchek) Blizinski: > I noticed that the readline frontend (the "sqlite3" command) doesn't > have readline, so I recompiled it with readline support. > > http://sourceforge.net/apps/trac/gar/changeset/7799 > > I want readline because it's useful when working with the "sqlite3" > utility to examine database contents. > > I've put it into testing. Ruper later bumped up the version to .21, > so I've rebuilt sqlite3 again. Excellent example as sqlite3 is already team-maintained: > I was thinking about a more general case. Let's say there's a package > that I'm willing to put some work into, such as this one. It's much > quicker to just fix the issue myself than ti file a bug and wait for > the maintainer to respond. However, when I submit the package for > release, I become the maintainer instead. Can we have a process in > which: > > - I can introduce a change to a package and rebuild it > - the package maintainer (here: Dago) approves the change > - I submit it for release > - I don't become the maintainer. Phil? Even a change of the maintainer would be ok for me. We could just add you to the team. Best regards -- Dago From dam at opencsw.org Mon Jan 4 10:50:45 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 4 Jan 2010 10:50:45 +0100 Subject: [csw-maintainers] Better shared object dependency checking in checkpkg out for testing In-Reply-To: References: Message-ID: Hi Maciej, Am 02.01.2010 um 12:40 schrieb Maciej (Matchek) Blizinski: > On Tue, Dec 29, 2009 at 11:58 PM, Maciej (Matchek) Blizinski > wrote: >> I have one more bit to implement: checking the data modification >> timestamp of /var/sadm/install/contents and updating the cache. > > This is done. If you fiddle with the contents make sure you check for pkgserv and issue "pkgadm sync" if necessary. > I've implemented all the features I wanted, I would like > to focus on merging my change to the main v2 branch. Here's the list > of changes: > > http://sourceforge.net/apps/trac/gar/log/csw/mgar/gar/v2-checkpkg > > I haven't received any comments about the new code, which makes me > think that people haven't tried it yet. > > My question to Dago: What would you like to be done with relation to > merging back to v2? Please merge it back. It looks good enough to be tried and we can fix problems on-the-fly as the result doesn't affect package contents. Best regards -- Dago From maciej at opencsw.org Mon Jan 4 14:14:07 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 4 Jan 2010 13:14:07 +0000 Subject: [csw-maintainers] Better shared object dependency checking in checkpkg out for testing In-Reply-To: References: Message-ID: On Mon, Jan 4, 2010 at 9:50 AM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 02.01.2010 um 12:40 schrieb Maciej (Matchek) Blizinski: >> >> On Tue, Dec 29, 2009 at 11:58 PM, Maciej (Matchek) Blizinski >> wrote: >>> >>> I have one more bit to implement: checking the data modification >>> timestamp of /var/sadm/install/contents and updating the cache. >> >> This is done. > > If you fiddle with the contents make sure you check for pkgserv and > issue "pkgadm sync" if necessary. There's no fiddling in the sense of modifying the file. There's a cache of this file being built, and every time the file changes, there's a need to update the cache. >> I've implemented all the features I wanted, I would like >> to focus on merging my change to the main v2 branch. ?Here's the list >> of changes: >> >> http://sourceforge.net/apps/trac/gar/log/csw/mgar/gar/v2-checkpkg >> >> I haven't received any comments about the new code, which makes me >> think that people haven't tried it yet. >> >> My question to Dago: What would you like to be done with relation to >> merging back to v2? > > Please merge it back. It looks good enough to be tried and we can > fix problems on-the-fly as the result doesn't affect package contents. Cool. I've merged the branch into v2. I'll keep the v2-checkpkg branch around in case I want to make additional changes. I'm thinking of doing the following things: - porting individual checks from the monolithic part to plugins, probably taking code from Ben's git repository - implementing overrides - adding logs which can be inspected after checkpkg has finished Maciej From maciej at opencsw.org Mon Jan 4 16:43:35 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 4 Jan 2010 15:43:35 +0000 Subject: [csw-maintainers] GAR: Changes to checkpkg: shared libraries and modularity Message-ID: If you don't use GAR, you can stop reading now. The v2-checkpkg branch has been merged to v2 today. It means that the new shared library checking code is now live. The next time you update your GAR sources, the new code will be pulled in. The new code doesn't affect the way the packages are made, it only affects the way the new packages are being checked. There are two main differences: 1. There is new library checking code. It's emulating the way the shared libraries are searched on the filesystem. The first time you run it on each machine, it builds a cache of /var/sadm/install/contents, so please be patient and give it up to two minutes to complete. Subsequent runs will be fast, and in fact, faster than the previous code, because it doesn't read the contents file each time. One of the main differences in output is that the new check displays dependencies it thinks are unnecessary. I found it a useful feature. For instance, I found out that syslog-ng was reported to have an unnecessary dependency on CSWtcpwrap. Upon close examination, it turned out that syslog-ng was supposed to have tcp wrapper support, but it was just not compiled in. If checkpkg hasn't tipped me off, I wouldn't have known or fixed this issue. I'm sure other people will be able to catch some problems by looking at this part of checkpkg's output. The new code outputs also information about dependencies between binary files: which files uses which shared library, and which package provides the library in question. I suspect that the new code might be slightly more picky and may produce more false positives than the previous one. If you run into a false-positive, or any kind of problem with library-related checks, please drop me a line. I've got small debugging infrastructure integrated into the new checkpkg files. 2. Modular checks have been introduced. The gar/bin/checkpkg.d directory contains now separate checks. The checks are executable files, which can be written in any language. Communication is over command line flags and system exit codes. Output from each check is collected and displayed at the end of the run of checkpkg. It won't stop on the first failure; all errors will be collected and displayed at the end. The intention of the modular checks is that people can introduce their own checks without having the problem of unexpected interactions with other checks or global variables. This should make it easier to collaborate: each person can program in their own favorite language, and it's easy to develop new tests. Each test evaluates a set of packages, not just an individual package. It makes checks slightly more complex, because they have to loop over the list of packages to check. However, the set tests are necessary anyway, and I think it's a better approach to have only one type of test rather than two. If people think that individual tests are also useful, let's discuss it. I haven't integrated any of Ben's code yet, but I've looked at it and borrowed some ideas. I would like to start incorporating his cswpkgtest code. I think that some tweaks to lib/pkg_testfuncs.sh should make his existing tests compatible with checkpkg.d. If you have any questions, I'll be happy to answer them. Maciej From bonivart at opencsw.org Mon Jan 4 16:55:23 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 4 Jan 2010 16:55:23 +0100 Subject: [csw-maintainers] GAR: Changes to checkpkg: shared libraries and modularity In-Reply-To: References: Message-ID: <625385e31001040755y4d0e602ayfe4ea510aa315ef@mail.gmail.com> On Mon, Jan 4, 2010 at 4:43 PM, Maciej (Matchek) Blizinski wrote: > The v2-checkpkg branch has been merged to v2 today. Great work! -- /peter From phil at bolthole.com Mon Jan 4 18:45:52 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 4 Jan 2010 09:45:52 -0800 Subject: [csw-maintainers] Better shared object dependency checking in checkpkg out for testing In-Reply-To: References: Message-ID: On Tue, Dec 29, 2009 at 3:58 PM, Maciej (Matchek) Blizinski wrote: >... ?I've created a v2-checkpkg branch in gar and >>> re-implemented the part of checkpkg which analyzes shared library >>> dependencies. ?My implementation takes into account the RPATH set in >>> the analyzed shared libraries, which allows it to correctly identify >>> GCC runtime dependencies. >>>...(n more!) >> > > The main worry I have about the code is that has grew in line count > beyond what I initially anticipated, heheheh.. I am not surprised.. I knew it would be long and ugly, which is why I put off attempting to write a better one for so long ;-) > and I doubt that it's easy to > understand at the first glance. ?There is a number of unit tests, > which should make code refactoring easier. Given the complexity, yet utility of this code... you might consider making it a completely standalone util. I know you mentioned "modules" down the road, but this particular bit is possibly more useful to a wider audience, so it could be beneficial that way. call it "checkpkgdeps", perhaps ? From phil at bolthole.com Mon Jan 4 18:56:24 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 4 Jan 2010 09:56:24 -0800 Subject: [csw-maintainers] Readline in sqlite3, changes to other people's packages In-Reply-To: References: Message-ID: On Sat, Jan 2, 2010 at 3:28 AM, Maciej (Matchek) Blizinski wrote: > I was thinking about a more general case. ?Let's say there's a package > that I'm willing to put some work into, such as this one. ?It's much > quicker to just fix the issue myself than ti file a bug and wait for > the maintainer to respond. ?However, when I submit the package for > release, I become the maintainer instead. ?Can we have a process in > which: > > - I can introduce a change to a package and rebuild it > - the package maintainer (here: Dago) approves the change > - I submit it for release > - I don't become the maintainer. > In my opinion, the right thing to do, would be for "the maintainer" to rebuild the package with your changes. Contrariwise, even if you dont wish to be the maintainer... If you are willing to do the work to repackage the thin to fix a bug, and [the current maintainer] is not.. you are de facto a better "maintainer" than the current one, and the best thing to do is for you to become the maintainer. Or learn patience, if the maintainer says they can get to it in a few days ;-) From maciej at opencsw.org Mon Jan 4 19:59:07 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 4 Jan 2010 18:59:07 +0000 Subject: [csw-maintainers] Better shared object dependency checking in checkpkg out for testing In-Reply-To: References: Message-ID: On Mon, Jan 4, 2010 at 5:45 PM, Philip Brown wrote: > I know you mentioned "modules" down the road, but this particular bit > is possibly more useful to a wider audience, so it could be beneficial > that way. > > call it "checkpkgdeps", perhaps ? It certainly could be used standalone. However, its primary use is to be part of a larger test suite - a modular checkpkg. It doesn't do certain things, for example it doesn't extract the package the way checkpkg does. To be standalone and useful, it would need be armored with the unpacking code. The unpacking code is already there in checkpkg, perhaps we can reuse it? From phil at bolthole.com Mon Jan 4 20:25:42 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 4 Jan 2010 11:25:42 -0800 Subject: [csw-maintainers] Better shared object dependency checking in checkpkg out for testing In-Reply-To: References: Message-ID: On Mon, Jan 4, 2010 at 10:59 AM, Maciej (Matchek) Blizinski wrote: > On Mon, Jan 4, 2010 at 5:45 PM, Philip Brown wrote: >> I know you mentioned "modules" down the road, but this particular bit >> is possibly more useful to a wider audience, so it could be beneficial >> that way. >> >> call it "checkpkgdeps", perhaps ? > > It certainly could be used standalone. ?However, its primary use is to > be part of a larger test suite - ?a modular checkpkg. ?It doesn't do > certain things, for example it doesn't extract the package the way > checkpkg does. ?To be standalone and useful, it would need be armored > with the unpacking code. ?The unpacking code is already there in > checkpkg, perhaps we can reuse it? If you like. Or you could use the system pkgtrans on a pkg file, but fail if gzipped. Or you could make it a little plainer and just expect a directory, and let the caller deal with providing the package in directory format. From rupert at opencsw.org Mon Jan 4 20:48:07 2010 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 4 Jan 2010 20:48:07 +0100 Subject: [csw-maintainers] [csw-buildfarm] what is different on buildfarm? mercurial tests take long - or fail In-Reply-To: <841FE230-13C7-4CEC-9202-B01167FE8730@opencsw.org> References: <6af4271001020318k5f9fe830gd5378c9bf96e267b@mail.gmail.com> <841FE230-13C7-4CEC-9202-B01167FE8730@opencsw.org> Message-ID: <6af4271001041148x907e364ha7d09da31400df6b@mail.gmail.com> On Mon, Jan 4, 2010 at 10:33, Dagobert Michelsen wrote: > Hi Rupert, > > Am 02.01.2010 um 12:18 schrieb rupert THURNER: >> >> while testing mercurial-1.4.2 i noticed that the tests take long - or >> forever on build8s. and they fail with network errors on build10s. >> >> as i did not have time to wait if they end at 8s, i breaked them and i >> tried 1.4.1 as well, which also did not complete in a reasonable time. >> >> so i wonder what might cause this. the new python? the new ipv6? something >> else? > > You may want to try test8s which doesn't have the novelties above. > If you want to have net access from the build machines you have to > use a proxy. huhm .... the results are differing with the version built on build8s: 1. test8s, see below and http://mercurial.pastebin.com/m41cc23ac 2. build8s, see http://mercurial.pastebin.com/m6ed3c83a, just times ot / stops should we try to change one parameter by one, and rerun the tests? rupert at login:~ $ ssh test8s ... rupert at build8st:~/hg-crew-8s/tests $ python run-tests.py -j 30 ... Skipped test-convert-p4: missing feature: Perforce server and client Skipped test-convert-bzr-ghosts: missing feature: Canonical's Bazaar client Skipped test-inotify-issue1208: missing feature: inotify extension support Skipped test-highlight: missing feature: Pygments source highlighting library Skipped test-casefolding: missing feature: case insensitive file system Skipped test-convert-bzr-merges: missing feature: Canonical's Bazaar client Skipped test-inotify-issue1371: missing feature: inotify extension support Skipped test-convert-bzr-directories: missing feature: Canonical's Bazaar client Skipped test-convert-tla: missing feature: GNU Arch tla client Skipped test-inotify-dirty-dirstate: missing feature: inotify extension support Skipped test-convert-bzr-114: missing feature: Canonical's Bazaar client >= 1.14 Skipped test-inotify-debuginotify: missing feature: inotify extension support Skipped test-convert-svn-branches: missing feature: subversion python bindings Skipped test-convert-svn-move: missing feature: subversion python bindings Skipped test-convert-bzr: missing feature: Canonical's Bazaar client Skipped test-convert-svn-tags: missing feature: subversion python bindings Skipped test-inotify: missing feature: inotify extension support Skipped test-convert-baz: missing feature: GNU Arch baz client Skipped test-convert-svn-startrev: missing feature: subversion python bindings Skipped test-convert-svn-source: missing feature: subversion python bindings Skipped test-convert-bzr-treeroot: missing feature: Canonical's Bazaar client Skipped test-inotify-issue1542: missing feature: inotify extension support Skipped test-convert-svn-sink: missing feature: subversion python bindings Skipped test-inotify-lookup: missing feature: inotify extension support Skipped test-convert-darcs: missing feature: darcs client Skipped test-convert-p4-filetypes: missing feature: Perforce server and client Skipped test-convert-hg-svn: missing feature: subversion python bindings Skipped test-convert-mtn: missing feature: monotone client (> 0.31) Skipped test-inotify-issue1556: missing feature: inotify extension support Skipped test-gendoc: missing feature: Docutils rst2html tool Skipped test-convert-svn-encoding: missing feature: subversion python bindings Skipped test-no-symlinks: system supports symbolic links Failed test-convert-cvs: output changed Failed test-subrepo-svn: output changed and returned error code 2 Failed test-patch-offset: output changed and returned error code 2 # Ran 361 tests, 32 skipped, 3 failed. From hson at opencsw.org Mon Jan 4 22:25:55 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Mon, 04 Jan 2010 22:25:55 +0100 Subject: [csw-maintainers] Upstream check for sourceforge not working? Message-ID: <4B425CE3.8050201@opencsw.org> Anyone else noticed that there is something wrong with the upstream check for sourceforge packages? I haven't gotten any mail regarding updated sourceforge packages in a while now and when I runt "gmake check-upstream" manually I don't get any output at all. From william at wbonnet.net Mon Jan 4 22:36:05 2010 From: william at wbonnet.net (William Bonnet) Date: Mon, 04 Jan 2010 22:36:05 +0100 Subject: [csw-maintainers] Upstream check for sourceforge not working? In-Reply-To: <4B425CE3.8050201@opencsw.org> References: <4B425CE3.8050201@opencsw.org> Message-ID: <4B425F45.7050400@wbonnet.net> Hi Roger Could you please tell me which packages have problems ? > Anyone else noticed that there is something wrong with the upstream > check for sourceforge packages? There are a some packages which have a problem with the upstream check. There are at least two known bugs. . If catalog name is different from garname, then the maintainer will not always be reported accurately. . Some url are just not working... I'm still working on a new version. Maybe for early february. > I haven't gotten any mail regarding updated sourceforge packages in a > while now and when I runt "gmake check-upstream" manually I don't get > any output at all. This can be normal... once you have run check-upstream, a timestamp is created. If you run gmake check-upstream again, it will not report anything if the version has not changed. You should do a gmake clean before running it again. 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 hson at opencsw.org Mon Jan 4 23:22:48 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Mon, 04 Jan 2010 23:22:48 +0100 Subject: [csw-maintainers] Upstream check for sourceforge not working? In-Reply-To: <4B425F45.7050400@wbonnet.net> References: <4B425CE3.8050201@opencsw.org> <4B425F45.7050400@wbonnet.net> Message-ID: <4B426A38.3030504@opencsw.org> William Bonnet wrote: > Hi Roger > > Could you please tell me which packages have problems ? > >> Anyone else noticed that there is something wrong with the upstream >> check for sourceforge packages? > There are a some packages which have a problem with the upstream check. > There are at least two known bugs. > > . If catalog name is different from garname, then the maintainer will > not always be reported accurately. > > . Some url are just not working... > > I'm still working on a new version. Maybe for early february. >> I haven't gotten any mail regarding updated sourceforge packages in a >> while now and when I runt "gmake check-upstream" manually I don't get >> any output at all. > This can be normal... once you have run check-upstream, a timestamp is > created. If you run gmake check-upstream again, it will not report > anything if the version has not changed. You should do a gmake clean > before running it again. Well, lets take an example, lcms. In the Makefile, i have: GARNAME = lcms GARVERSION = 1.18 UPSTREAM_MASTER_SITES = $(SF_PROJECT_SHOWFILE)=26279 UPSTREAM_USE_SF = 1 UFILES_REGEX = (\d+(?:\.\d+)*) Taking a look at http://sourceforge.net/projects/lcms/files/ (where http://sourceforge.net/project/showfiles.php?group_id=26289 is redirected) the latest release is 1.19 I've checked upstream_watch and from what I can tell, it's supposed to get some output from "$wget_command -qO- $url 2>/dev/null | grep class | grep selected | grep li | grep Download | " However the output from sourceforge must have changed because running that command gives no output at all and running the wget manually and checking the output tells me that upstream_watch cannot work with their current design. From rupert at opencsw.org Mon Jan 4 23:53:47 2010 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 4 Jan 2010 23:53:47 +0100 Subject: [csw-maintainers] [csw-buildfarm] what is different on buildfarm? mercurial tests take long - or fail In-Reply-To: <0DEA3BF3-1EC8-42F7-A160-1CC681304F3F@opencsw.org> References: <6af4271001020318k5f9fe830gd5378c9bf96e267b@mail.gmail.com> <841FE230-13C7-4CEC-9202-B01167FE8730@opencsw.org> <6af4271001041148x907e364ha7d09da31400df6b@mail.gmail.com> <0DEA3BF3-1EC8-42F7-A160-1CC681304F3F@opencsw.org> Message-ID: <6af4271001041453o5324cc98t19981f6f67762853@mail.gmail.com> On Mon, Jan 4, 2010 at 21:38, Dagobert Michelsen wrote: > Hi Rupert, > > Am 04.01.2010 um 20:48 schrieb rupert THURNER: >> >> huhm .... the results are differing with the version built on build8s: >> 1. test8s, see below and http://mercurial.pastebin.com/m41cc23ac >> 2. build8s, see http://mercurial.pastebin.com/m6ed3c83a, just times ot / >> stops >> >> should we try to change one parameter by one, and rerun the tests? > > You can do > ?ssh root at test8s > now. You should be using the machine alone at the moment. Please don't FUBR > it. did: pkgrm CSWpython pkgutil -U -i python did not upgrade the dependent upgrades pkgutil suggested: CSWreadline-6.1,REV=2010.01.01 CSWsqlite3rt-3.6.21,REV=2010.01.04 CSWosslrt-0.9.8l,REV=2009.12.08 and you were right, the hg tests just stops. but i am completely lost why this would happen. it seems to be (at least) the push-http test: rupert at build8st:~/hg-crew-8s/tests $ python run-tests.py test-push-http rupert at build8st:~ $ /usr/ucb/ps aguxwwwww | grep rupert rupert 22253 0.1 0.111784 8496 pts/76 S 15:39:36 0:00 /opt/csw/bin/python /tmp/hgtests.iyfh65/install/bin/hg --cwd ../test2 push http://localhost:20059/ rupert 22165 0.0 0.110232 6952 pts/76 S 15:39:11 0:00 python run-tests.py test-push-http rupert 22210 0.0 0.0 2232 1656 pts/76 S 15:39:26 0:00 /bin/sh /home/rupert/hg-crew-8s/tests/test-push-http rupert 22254 0.0 0.0 5432 1624 pts/73 O 15:39:43 0:00 /usr/ucb/ps -aguxwwwww rupert 3135 0.0 0.116920 2904 ? S 15:02:26 0:00 /opt/csw/bin/python /tmp/hgtests.DAKOec/install/bin/hg serve -p 20101 -d --pid-file=hg.pid -E errors.log --daemon-pipefds=3,4 rupert 21190 0.0 0.112624 3176 ? S 15:33:05 0:00 /opt/csw/sbin/sshd -R rupert 21192 0.0 0.1 3768 2840 pts/73 S 15:33:05 0:00 -bash rupert 22209 0.0 0.0 2232 1656 pts/76 S 15:39:26 0:00 /bin/sh -c "/home/rupert/hg-crew-8s/tests/test-push-http" rupert 22244 0.0 0.116920 6272 ? S 15:39:35 0:00 /opt/csw/bin/python /tmp/hgtests.iyfh65/install/bin/hg serve -p 20059 -d --pid-file=hg.pid -E errors.log --daemon-pipefds=3,4 rupert 22252 0.0 0.0 2240 1608 pts/76 S 15:39:36 0:00 sed -e s,:[0-9][0-9]*/,/, rupert 22255 0.0 0.0 2168 1456 pts/73 S 15:39:43 0:00 grep rupert rupert 23303 0.0 0.012624 1632 ? S 14:59:42 0:00 /opt/csw/sbin/sshd -R rupert 23305 0.0 0.0 3832 1952 pts/76 S 14:59:43 0:00 -bash then i upgraded the dependencies too. but no change in the output. rupert. From rupert at opencsw.org Mon Jan 4 23:57:47 2010 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 4 Jan 2010 23:57:47 +0100 Subject: [csw-maintainers] [csw-buildfarm] what is different on buildfarm? mercurial tests take long - or fail In-Reply-To: <0DEA3BF3-1EC8-42F7-A160-1CC681304F3F@opencsw.org> References: <6af4271001020318k5f9fe830gd5378c9bf96e267b@mail.gmail.com> <841FE230-13C7-4CEC-9202-B01167FE8730@opencsw.org> <6af4271001041148x907e364ha7d09da31400df6b@mail.gmail.com> <0DEA3BF3-1EC8-42F7-A160-1CC681304F3F@opencsw.org> Message-ID: <6af4271001041457h4535abdar558fdb87b70cf151@mail.gmail.com> On Mon, Jan 4, 2010 at 21:38, Dagobert Michelsen wrote: > Hi Rupert, > > Am 04.01.2010 um 20:48 schrieb rupert THURNER: >> >> huhm .... the results are differing with the version built on build8s: >> 1. test8s, see below and http://mercurial.pastebin.com/m41cc23ac >> 2. build8s, see http://mercurial.pastebin.com/m6ed3c83a, just times ot / >> stops >> >> should we try to change one parameter by one, and rerun the tests? > > You can do > ?ssh root at test8s > now. You should be using the machine alone at the moment. Please don't FUBR > it. > did: pkgrm CSWpython pkgutil -U -i python did not upgrade the related upgrades pkgutil suggested: CSWreadline-6.1,REV=2010.01.01 CSWsqlite3rt-3.6.21,REV=2010.01.04 CSWosslrt-0.9.8l,REV=2009.12.08 and you were right, the hg tests just stops. but i am completely lost why this would happen. it seems to be (at least) the push-http test: rupert at build8st:~/hg-crew-8s/tests $ python run-tests.py test-push-http rupert at build8st:~ $ /usr/ucb/ps aguxwwwww | grep rupert rupert 22253 0.1 0.111784 8496 pts/76 S 15:39:36 0:00 /opt/csw/bin/python /tmp/hgtests.iyfh65/install/bin/hg --cwd ../test2 push http://localhost:20059/ rupert 22165 0.0 0.110232 6952 pts/76 S 15:39:11 0:00 python run-tests.py test-push-http rupert 22210 0.0 0.0 2232 1656 pts/76 S 15:39:26 0:00 /bin/sh /home/rupert/hg-crew-8s/tests/test-push-http rupert 22254 0.0 0.0 5432 1624 pts/73 O 15:39:43 0:00 /usr/ucb/ps -aguxwwwww rupert 3135 0.0 0.116920 2904 ? S 15:02:26 0:00 /opt/csw/bin/python /tmp/hgtests.DAKOec/install/bin/hg serve -p 20101 -d --pid-file=hg.pid -E errors.log --daemon-pipefds=3,4 rupert 21190 0.0 0.112624 3176 ? S 15:33:05 0:00 /opt/csw/sbin/sshd -R rupert 21192 0.0 0.1 3768 2840 pts/73 S 15:33:05 0:00 -bash rupert 22209 0.0 0.0 2232 1656 pts/76 S 15:39:26 0:00 /bin/sh -c "/home/rupert/hg-crew-8s/tests/test-push-http" rupert 22244 0.0 0.116920 6272 ? S 15:39:35 0:00 /opt/csw/bin/python /tmp/hgtests.iyfh65/install/bin/hg serve -p 20059 -d --pid-file=hg.pid -E errors.log --daemon-pipefds=3,4 rupert 22252 0.0 0.0 2240 1608 pts/76 S 15:39:36 0:00 sed -e s,:[0-9][0-9]*/,/, rupert 22255 0.0 0.0 2168 1456 pts/73 S 15:39:43 0:00 grep rupert rupert 23303 0.0 0.012624 1632 ? S 14:59:42 0:00 /opt/csw/sbin/sshd -R rupert 23305 0.0 0.0 3832 1952 pts/76 S 14:59:43 0:00 -bash then i upgraded the dependencies as well. but the result did not change, the test just hang. rupert. From maciej at opencsw.org Tue Jan 5 09:53:00 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 5 Jan 2010 08:53:00 +0000 Subject: [csw-maintainers] [csw-buildfarm] what is different on buildfarm? mercurial tests take long - or fail In-Reply-To: <6af4271001041457h4535abdar558fdb87b70cf151@mail.gmail.com> References: <6af4271001020318k5f9fe830gd5378c9bf96e267b@mail.gmail.com> <841FE230-13C7-4CEC-9202-B01167FE8730@opencsw.org> <6af4271001041148x907e364ha7d09da31400df6b@mail.gmail.com> <0DEA3BF3-1EC8-42F7-A160-1CC681304F3F@opencsw.org> <6af4271001041457h4535abdar558fdb87b70cf151@mail.gmail.com> Message-ID: On Mon, Jan 4, 2010 at 10:57 PM, rupert THURNER wrote: > then i upgraded the dependencies as well. but the result did not > change, the test just hang. My mantra is: what does truss say? From dam at opencsw.org Tue Jan 5 15:46:41 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 5 Jan 2010 15:46:41 +0100 Subject: [csw-maintainers] FYI: Automatic deletion of released packages from testing/ References: <201001051430.o05EUIPC008639@mirror.opencsw.org> Message-ID: Hi, automatic deletion of released packages is now active. So just leave packages in testing/ after copying them over to newpkgs/ and don't bother deleting them. Only *identical* packages are deleted. Files like these keep laying around, please remove them manually: Anfang der weitergeleiteten E-Mail: > Newer PKG released. Testing: mercurial-1.4.1,REV=2009.12.16-SunOS5.8-i386-CSW.pkg.gz > Released: mercurial-1.4.2,REV=2010.01.02-SunOS5.8-sparc-CSW.pkg.gz > Newer PKG released. Testing: mercurial-1.4.1,REV=2009.12.16-SunOS5.8-sparc-CSW.pkg.gz > Released: mercurial-1.4.2,REV=2010.01.02-SunOS5.8-sparc-CSW.pkg.gz Best regards -- Dago From phil at bolthole.com Tue Jan 5 17:27:08 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 5 Jan 2010 08:27:08 -0800 Subject: [csw-maintainers] FYI: Automatic deletion of released packages from testing/ In-Reply-To: References: <201001051430.o05EUIPC008639@mirror.opencsw.org> Message-ID: On Tue, Jan 5, 2010 at 6:46 AM, Dagobert Michelsen wrote: > Hi, > > automatic deletion of released packages is now active. So just > leave packages in testing/ after copying them over to newpkgs/ > and don't bother deleting them. Only *identical* packages are > deleted. Might be nice to either keep an exceptions file, or provide a separate "experimental" location, then? I'd like to keep the samba old packages around. From ihsan at opencsw.org Tue Jan 5 20:43:02 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Tue, 05 Jan 2010 20:43:02 +0100 Subject: [csw-maintainers] maintenance on the mail/web server Message-ID: <4B439646.9030804@opencsw.org> Hello, Between 18:00 and 21:00 GMT there will be an outage of the mail server for approximately 1 hour. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Tue Jan 5 21:14:37 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 5 Jan 2010 21:14:37 +0100 Subject: [csw-maintainers] FYI: Automatic deletion of released packages from testing/ In-Reply-To: References: <201001051430.o05EUIPC008639@mirror.opencsw.org> Message-ID: <670E7EA4-6062-4D9D-B68B-3D64B9B3AA93@opencsw.org> Hi Phil, Am 05.01.2010 um 17:27 schrieb Philip Brown: > On Tue, Jan 5, 2010 at 6:46 AM, Dagobert Michelsen wrote: >> automatic deletion of released packages is now active. So just >> leave packages in testing/ after copying them over to newpkgs/ >> and don't bother deleting them. Only *identical* packages are >> deleted. > > Might be nice to either keep an exceptions file, or provide a separate > "experimental" location, then? > I'd like to keep the samba old packages around. You are missing the point: Only packages officially released and resynced back to the farm are deleted from testing/, everything else is not touched, but needs to be removed manually if necessary. Best regards -- Dago From dam at opencsw.org Tue Jan 5 21:56:02 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 5 Jan 2010 21:56:02 +0100 Subject: [csw-maintainers] libproxy in testing Message-ID: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> Hi, I just build libproxy which can be used by many other packages for automatic proxy configuration location. Unfortunately it is written according to C99, which is only compilable on Solaris 10+. For Solaris 8/9 major code changes and GNULibs substitutes would be needed. Thoughts? libproxy-0.3.0,REV=2010.01.05-SunOS5.10-sparc-CSW.pkg.gz libproxy-0.3.0,REV=2010.01.05-SunOS5.10-i386-CSW.pkg.gz Best regards -- Dago From bwalton at opencsw.org Tue Jan 5 22:01:51 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 05 Jan 2010 16:01:51 -0500 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> Message-ID: <1262725258-sup-3515@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Tue Jan 05 15:56:02 -0500 2010: > be needed. Thoughts? 10 only. If the devs aren't interested in older platforms and you have no personal need, why go through the headache? -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 Jan 5 22:03:16 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 5 Jan 2010 22:03:16 +0100 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <1262725258-sup-3515@ntdws12.chass.utoronto.ca> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> <1262725258-sup-3515@ntdws12.chass.utoronto.ca> Message-ID: <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> Hi Ben, Am 05.01.2010 um 22:01 schrieb Ben Walton: > Excerpts from Dagobert Michelsen's message of Tue Jan 05 15:56:02 -0500 2010: > >> be needed. Thoughts? > > 10 only. If the devs aren't interested in older platforms and you > have no personal need, why go through the headache? The question is: Do we want to release it and make separate releases of packages for Solaris 8/9 vs. 10 which require it? Best regards -- Dago From bwalton at opencsw.org Tue Jan 5 22:13:18 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 05 Jan 2010 16:13:18 -0500 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> <1262725258-sup-3515@ntdws12.chass.utoronto.ca> <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> Message-ID: <1262725840-sup-6428@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Tue Jan 05 16:03:16 -0500 2010: > The question is: Do we want to release it and make separate releases > of packages for Solaris 8/9 vs. 10 which require it? I guess that depends on how popular it gets? Are there many packages that leverage it? -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dam at opencsw.org Tue Jan 5 22:21:01 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 5 Jan 2010 22:21:01 +0100 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <1262725840-sup-6428@ntdws12.chass.utoronto.ca> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> <1262725258-sup-3515@ntdws12.chass.utoronto.ca> <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> <1262725840-sup-6428@ntdws12.chass.utoronto.ca> Message-ID: <770D1EA9-1422-4196-B97E-E301D9087FA2@opencsw.org> Hi Ben, Am 05.01.2010 um 22:13 schrieb Ben Walton: > Excerpts from Dagobert Michelsen's message of Tue Jan 05 16:03:16 -0500 2010: > >> The question is: Do we want to release it and make separate releases >> of packages for Solaris 8/9 vs. 10 which require it? > > I guess that depends on how popular it gets? Are there many packages > that leverage it? It looks like it gets quite popular: http://code.google.com/p/libproxy/wiki/Applications I asked on-list wheter they would accept patches for pre-C99 compat. Best regards -- Dago From bwalton at opencsw.org Tue Jan 5 22:27:20 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 05 Jan 2010 16:27:20 -0500 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <770D1EA9-1422-4196-B97E-E301D9087FA2@opencsw.org> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> <1262725258-sup-3515@ntdws12.chass.utoronto.ca> <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> <1262725840-sup-6428@ntdws12.chass.utoronto.ca> <770D1EA9-1422-4196-B97E-E301D9087FA2@opencsw.org> Message-ID: <1262726786-sup-7146@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Tue Jan 05 16:21:01 -0500 2010: Hi Dago, > It looks like it gets quite popular: > http://code.google.com/p/libproxy/wiki/Applications Yes that is popular and importantly, some of the apps leveraging it are also quite popular. > I asked on-list wheter they would accept patches for pre-C99 > compat. Good luck! :) 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 skayser at opencsw.org Wed Jan 6 01:47:38 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 06 Jan 2010 01:47:38 +0100 Subject: [csw-maintainers] GAR: Changes to checkpkg: shared libraries and modularity In-Reply-To: References: Message-ID: <4B43DDAA.6040208@opencsw.org> Maciej (Matchek) Blizinski wrote on 04.01.2010 16:43: > The v2-checkpkg branch has been merged to v2 today. It means that the > new shared library checking code is now live. The next time you > update your GAR sources, the new code will be pulled in. > > [...] > > One of the main differences in output is that the new check displays > dependencies it thinks are unnecessary. I found it a useful feature. > For instance, I found out that syslog-ng was reported to have an > unnecessary dependency on CSWtcpwrap. Upon close examination, it > turned out that syslog-ng was supposed to have tcp wrapper support, > but it was just not compiled in. If checkpkg hasn't tipped me off, I > wouldn't have known or fixed this issue. I'm sure other people will > be able to catch some problems by looking at this part of checkpkg's > output. Yes!! Thanks for the time you put into this! checkpkg just did the same for me with mbuffer. Dependency to openssl_rt had become obsolete with version bumps and this would have gone unnoticed if it was only for me. > The new code outputs also information about dependencies between > binary files: which files uses which shared library, and which package > provides the library in question. > > I suspect that the new code might be slightly more picky and may > produce more false positives than the previous one. If you run into a > false-positive, or any kind of problem with library-related checks, > please drop me a line. I've got small debugging infrastructure > integrated into the new checkpkg files. Two minor things. First, the mbuffer package doesn't contain any library, still checkpkg tries to check something (the binary?) for a SONAME. ... INFO:root:The mbuffer shared library doesn't provide a SONAME. INFO:root:The mbuffer shared library doesn't provide a SONAME. ... Second, and this is really minor (but I guess trivial to attack with your python foo), could you get rid of the Unicode u prefix in front of the provided-by-package names? ... Analysis of sonames needed by the package set: libresolv.so.2 is provided by u'SUNWcsl' and required by: mbuffer libmhash.so.2 is provided by u'CSWlibmhash' and required by: mbuffer libnsl.so.1 is provided by u'SUNWcsl' and required by: mbuffer librt.so.1 is provided by u'SUNWcsl' and required by: mbuffer libsocket.so.1 is provided by u'SUNWcsl' and required by: mbuffer libm.so.1 is provided by u'SUNWlibms' and required by: mbuffer libpthread.so.1 is provided by u'SUNWcsl' and required by: mbuffer libc.so.1 is provided by u'SUNWcsl' and required by: mbuffer ... Sebastian From skayser at opencsw.org Wed Jan 6 12:12:30 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 06 Jan 2010 12:12:30 +0100 Subject: [csw-maintainers] GAR and isaexec: merging to $ISA subdirs doesn't work Message-ID: <4B44701E.1070100@opencsw.org> Hi, I just removed NO_ISAEXEC=1 from the mbuffer package to make it a regular 32-/64-bit package with isaexec as a wrapper. The resulting package looks just like before though. No isaexec symlink and the default $ISA in bin/. What's wrong? Running "gmake spotless package" leads to the same result. Current build description is checked in [1]. $ tree work/solaris8-sparc/pkgroot/ work/solaris8-sparc/pkgroot/ `-- opt `-- csw |-- bin | |-- mbuffer | `-- sparcv9 | `-- mbuffer $ file work/solaris8-sparc/pkgroot/opt/csw/bin/mbuffer work/solaris8-sparc/pkgroot/opt/csw/bin/mbuffer: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped $ file work/solaris8-sparc/pkgroot/opt/csw/bin/sparcv9/mbuffer work/solaris8-sparc/pkgroot/opt/csw/bin/sparcv9/mbuffer: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, stripped $ zgrep bin/ ~/pkgs/mbuffer-20091227\,REV\=2010.01.06-SunOS5.8-sparc-CSW.pkg.gz ... 1 f none /opt/csw/bin/mbuffer 0755 root bin 72608 13869 1262774610 1 f none /opt/csw/bin/sparcv9/mbuffer 0755 root bin 86176 27717 1262774652 ... Sebastian [1]https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/mbuffer/trunk/Makefile From dam at opencsw.org Wed Jan 6 22:36:03 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 6 Jan 2010 22:36:03 +0100 Subject: [csw-maintainers] GAR and isaexec: merging to $ISA subdirs doesn't work In-Reply-To: <4B44701E.1070100@opencsw.org> References: <4B44701E.1070100@opencsw.org> Message-ID: <080DF858-63AB-4867-9B3F-3ABA7A43E645@opencsw.org> Hi Sebastian, Am 06.01.2010 um 12:12 schrieb Sebastian Kayser: > I just removed NO_ISAEXEC=1 from the mbuffer package to make it a > regular 32-/64-bit package with isaexec as a wrapper. The resulting > package looks just like before though. No isaexec symlink and the > default $ISA in bin/. What's wrong? Running "gmake spotless package" > leads to the same result. Current build description is checked > in [1]. I guess you hit this bug: Please try "gmake repackage" unless it has been fixed. Best regards -- Dago From ihsan at opencsw.org Wed Jan 6 22:38:09 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 06 Jan 2010 22:38:09 +0100 Subject: [csw-maintainers] maintenance on the mail/web server In-Reply-To: <4B439646.9030804@opencsw.org> References: <4B439646.9030804@opencsw.org> Message-ID: <4B4502C1.5020104@opencsw.org> Am 05.01.10 20:43, schrieb Ihsan Dogan: > Between 18:00 and 21:00 GMT there will be an outage of the mail server > for approximately 1 hour. Everything is up and running again. I'm very sorry for the long delay. The PHP package is by the broken: ihsan at bender:~$ ldd /opt/csw/php5/lib/php/extensions/no-debug-non-zts-20060613/mysql.so libmysqlclient.so.15 => (file not found) libc.so.1 => /lib/libc.so.1 libm.so.2 => /lib/libm.so.2 /platform/SUNW,Sun-Fire-T200/lib/libc_psr.so.1 Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Wed Jan 6 22:46:23 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 6 Jan 2010 22:46:23 +0100 Subject: [csw-maintainers] maintenance on the mail/web server In-Reply-To: <4B4502C1.5020104@opencsw.org> References: <4B439646.9030804@opencsw.org> <4B4502C1.5020104@opencsw.org> Message-ID: Hi Ihsan, Am 06.01.2010 um 22:38 schrieb Ihsan Dogan: > Am 05.01.10 20:43, schrieb Ihsan Dogan: > >> Between 18:00 and 21:00 GMT there will be an outage of the mail server >> for approximately 1 hour. > > Everything is up and running again. I'm very sorry for the long delay. > > The PHP package is by the broken: > ihsan at bender:~$ ldd > /opt/csw/php5/lib/php/extensions/no-debug-non-zts-20060613/mysql.so > libmysqlclient.so.15 => (file not found) > libc.so.1 => /lib/libc.so.1 > libm.so.2 => /lib/libm.so.2 > /platform/SUNW,Sun-Fire-T200/lib/libc_psr.so.1 There seems to be a legacy link missing. This is in your mysql.so: [4] RUNPATH /opt/csw/lib:/opt/csw/bdb44/lib:/opt/csw/lib/mysql [5] RPATH /opt/csw/lib:/opt/csw/bdb44/lib:/opt/csw/lib/mysql Please make ln -s /opt/csw/mysql5/lib/mysql /opt/csw/lib/mysql in the meantime unless there is an official fix. Maciej: Shouldn't there be a "legacy compat link" somewhere in the mysql package? Best regards -- Dago From skayser at opencsw.org Wed Jan 6 23:03:05 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 06 Jan 2010 23:03:05 +0100 Subject: [csw-maintainers] GAR and isaexec: merging to $ISA subdirs doesn't work In-Reply-To: <080DF858-63AB-4867-9B3F-3ABA7A43E645@opencsw.org> References: <4B44701E.1070100@opencsw.org> <080DF858-63AB-4867-9B3F-3ABA7A43E645@opencsw.org> Message-ID: <4B450899.5030501@opencsw.org> Hi Dago, Dagobert Michelsen wrote on 06.01.2010 22:36: > Am 06.01.2010 um 12:12 schrieb Sebastian Kayser: >> I just removed NO_ISAEXEC=1 from the mbuffer package to make it a >> regular 32-/64-bit package with isaexec as a wrapper. The resulting >> package looks just like before though. No isaexec symlink and the >> default $ISA in bin/. What's wrong? Running "gmake spotless package" >> leads to the same result. Current build description is checked >> in [1]. > > I guess you hit this bug: > > > Please try "gmake repackage" unless it has been fixed. indeed, "gmake repackage" did the trick. Thank you. The bug seems to be triggered not only by "gmake platforms" btw., I had also tried a plain "gmake package" to no avail. I have added this as a comment to the bug. Sebastian From maciej at opencsw.org Thu Jan 7 13:48:49 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 7 Jan 2010 12:48:49 +0000 Subject: [csw-maintainers] maintenance on the mail/web server In-Reply-To: References: <4B439646.9030804@opencsw.org> <4B4502C1.5020104@opencsw.org> Message-ID: On Wed, Jan 6, 2010 at 9:46 PM, Dagobert Michelsen wrote: > There seems to be a legacy link missing. This is in your mysql.so: > > [4] ? ? RUNPATH ? ? ? ? /opt/csw/lib:/opt/csw/bdb44/lib:/opt/csw/lib/mysql > [5] ? ? RPATH ? ? ? ? ? /opt/csw/lib:/opt/csw/bdb44/lib:/opt/csw/lib/mysql > > Please make > > ?ln -s /opt/csw/mysql5/lib/mysql /opt/csw/lib/mysql > > in the meantime unless there is an official fix. > > Maciej: Shouldn't there be a "legacy compat link" somewhere in the mysql > package? I can add one. But -- what should the CSWmysql51 package contain? You can have a link from /opt/csw/lib/mysql to both /opt/csw/mysql5/lib/mysql and /opt/csw/mysql51/lib/mysql at the same time. From maciej at opencsw.org Thu Jan 7 13:49:33 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 7 Jan 2010 12:49:33 +0000 Subject: [csw-maintainers] maintenance on the mail/web server In-Reply-To: References: <4B439646.9030804@opencsw.org> <4B4502C1.5020104@opencsw.org> Message-ID: On Thu, Jan 7, 2010 at 12:48 PM, Maciej (Matchek) Blizinski wrote: > On Wed, Jan 6, 2010 at 9:46 PM, Dagobert Michelsen wrote: >> There seems to be a legacy link missing. This is in your mysql.so: >> >> [4] ? ? RUNPATH ? ? ? ? /opt/csw/lib:/opt/csw/bdb44/lib:/opt/csw/lib/mysql >> [5] ? ? RPATH ? ? ? ? ? /opt/csw/lib:/opt/csw/bdb44/lib:/opt/csw/lib/mysql >> >> Please make >> >> ?ln -s /opt/csw/mysql5/lib/mysql /opt/csw/lib/mysql >> >> in the meantime unless there is an official fix. >> >> Maciej: Shouldn't there be a "legacy compat link" somewhere in the mysql >> package? > > I can add one. ?But -- what should the CSWmysql51 package contain? You > can have a link from /opt/csw/lib/mysql to both > /opt/csw/mysql5/lib/mysql and /opt/csw/mysql51/lib/mysql at the same > time. Um, I meant, you cannot have a link from one place to two places at the same time. From dam at opencsw.org Thu Jan 7 14:47:16 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 7 Jan 2010 14:47:16 +0100 Subject: [csw-maintainers] BO Buildfarm will be down tomorrow for LDom update Message-ID: <4610F26C-0F72-4B02-AB82-72C14942A20D@opencsw.org> Hi, I am finally going to update the T5220 for LDoms and OpenSolaris. As "login" is affected the BO buildfarm will be down tomorrow 2010/01/08 between 9 AM MET and 6 PM MET. Please use login.go.opencsw.org in the meantime for something important. Best regards -- Dago From maciej at opencsw.org Thu Jan 7 16:33:13 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 7 Jan 2010 15:33:13 +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. Turns out, you can customize xterm and tell it which characters belong to words and which don't. man xterm, look for "charClass". The quick fix is: echo >> ~/.Xresources "xterm*charClass: 45:48" xrdb -merge ~/.Xresources If you use xterm, it should be useful for you. By the way, it turned out some time ago that the dot is also a legal character as far as pkgnames are concerned. I learned that when creating a catalog with SUNW packages. From dam at opencsw.org Thu Jan 7 21:51:00 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 7 Jan 2010 21:51:00 +0100 Subject: [csw-maintainers] Ganglia for sparcv9 In-Reply-To: <4AE87999.6020401@opencsw.org> References: <4AE87999.6020401@opencsw.org> Message-ID: <777D637C-111E-4F5B-8562-501B9F42351E@opencsw.org> Hi Daniel, Am 28.10.2009 um 18:04 schrieb Daniel Pocock: > I've added > > BUILD64 = 1 > > to my Ganglia package Makefile, so that I can build 64 bit support. > > This is important because Ganglia makes calls to kstat and that needs to be done from 64 bit code when running on a 64 bit kernel. > > However, I'm finding that some dependencies are not 64 bit. The key ones that I am currently stuck on: > > /opt/csw/apache2/lib/libapr-1.so.0 Ok, this is done now. > /opt/csw/lib/sparcv8/libsasl2.so.2 I have prepared the package, but as I don't use I need testers. Do you have experience with SASL? > /opt/csw/lib/sparcv8/libnet.so This is a hard one as I wrote before: Roger did some work towards it, but didn't finish updating the library. You can read about the troubles he ran into by following this thread: > Can anyone assist with this or make any comments on these issues? Ihsan: For rrdtool I just opened a case for 64 bit libs: Looks like we are getting closer... Best regards -- Dago From maciej at opencsw.org Fri Jan 8 00:54:07 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 7 Jan 2010 23:54:07 +0000 Subject: [csw-maintainers] GAR: Changes to checkpkg: shared libraries and modularity In-Reply-To: <4B43DDAA.6040208@opencsw.org> References: <4B43DDAA.6040208@opencsw.org> Message-ID: On Wed, Jan 6, 2010 at 12:47 AM, Sebastian Kayser wrote: > Two minor things. First, the mbuffer package doesn't contain any > library, still checkpkg tries to check something (the binary?) for a SONAME. > > ... > INFO:root:The mbuffer shared library doesn't provide a SONAME. > INFO:root:The mbuffer shared library doesn't provide a SONAME. > ... Right, the code currently doesn't distinguish shared libraries and executables; at some point it was assumed that if it is a shared library, it will provide a SONAME, but there are cases where it's not true, Oracle shared libraries for instance. I moved this message to the debug level, it's not needed for normal operation. > Second, and this is really minor (but I guess trivial to attack with > your python foo), could you get rid of the Unicode u prefix in front of > the provided-by-package names? > > ... > Analysis of sonames needed by the package set: > libresolv.so.2 is provided by u'SUNWcsl' and required by: > ?mbuffer > libmhash.so.2 is provided by u'CSWlibmhash' and required by: > ?mbuffer > libnsl.so.1 is provided by u'SUNWcsl' and required by: > ?mbuffer > librt.so.1 is provided by u'SUNWcsl' and required by: > ?mbuffer > libsocket.so.1 is provided by u'SUNWcsl' and required by: > ?mbuffer > libm.so.1 is provided by u'SUNWlibms' and required by: > ?mbuffer > libpthread.so.1 is provided by u'SUNWcsl' and required by: > ?mbuffer > libc.so.1 is provided by u'SUNWcsl' and required by: > ?mbuffer > ... Done. It was also a debug-ish thing, where I wanted to make sure that I can see a difference between "SUNWcsl" and "SUNWcsl ", etc. I'm glad you like it! Any further thoughts or comments? From dam at opencsw.org Fri Jan 8 18:44:57 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 8 Jan 2010 18:44:57 +0100 Subject: [csw-maintainers] BO Buildfarm available again In-Reply-To: <4610F26C-0F72-4B02-AB82-72C14942A20D@opencsw.org> References: <4610F26C-0F72-4B02-AB82-72C14942A20D@opencsw.org> Message-ID: Hi, Am 07.01.2010 um 14:47 schrieb Dagobert Michelsen: > I am finally going to update the T5220 for LDoms and OpenSolaris. > As "login" is affected the BO buildfarm will be down tomorrow > 2010/01/08 > between 9 AM MET and 6 PM MET. The T5220 is now split into two LDoms: One LDom with the existing Solaris 10 instance carrying all of the Sparc stuff which was already there (now restricted to 12 GB Ram and 20 Strands) and one LDom with OpenSolaris 06/09 Sparc still installing with 3 GB Ram and 8 Strands. Additionally, all zones have been patched with the current patchset. Please let me know if you encounter anything strange. Best regards -- Dago From ihsan at opencsw.org Sat Jan 9 22:40:26 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sat, 09 Jan 2010 22:40:26 +0100 Subject: [csw-maintainers] maintenance on the mail/web server In-Reply-To: References: <4B439646.9030804@opencsw.org> <4B4502C1.5020104@opencsw.org> Message-ID: <4B48F7CA.5010801@opencsw.org> Am 06.01.10 22:46, schrieb Dagobert Michelsen: >> The PHP package is by the broken: >> ihsan at bender:~$ ldd >> /opt/csw/php5/lib/php/extensions/no-debug-non-zts-20060613/mysql.so >> libmysqlclient.so.15 => (file not found) >> libc.so.1 => /lib/libc.so.1 >> libm.so.2 => /lib/libm.so.2 >> /platform/SUNW,Sun-Fire-T200/lib/libc_psr.so.1 > > There seems to be a legacy link missing. This is in your mysql.so: > > [4] RUNPATH /opt/csw/lib:/opt/csw/bdb44/lib:/opt/csw/lib/mysql > [5] RPATH /opt/csw/lib:/opt/csw/bdb44/lib:/opt/csw/lib/mysql > > Please make > > ln -s /opt/csw/mysql5/lib/mysql /opt/csw/lib/mysql > > in the meantime unless there is an official fix. I've fixed with setting LD_LIBRARY_PATH variable in the FastCGI start script. > Maciej: Shouldn't there be a "legacy compat link" somewhere in the mysql > package? Well, we would need an updated PHP package. :-) Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Sat Jan 9 22:50:39 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sat, 09 Jan 2010 22:50:39 +0100 Subject: [csw-maintainers] Ganglia for sparcv9 In-Reply-To: <777D637C-111E-4F5B-8562-501B9F42351E@opencsw.org> References: <4AE87999.6020401@opencsw.org> <777D637C-111E-4F5B-8562-501B9F42351E@opencsw.org> Message-ID: <4B48FA2F.2020806@opencsw.org> Am 07.01.10 21:51, schrieb Dagobert Michelsen: > Ihsan: For rrdtool I just opened a case for 64 bit libs: > I'll have a look in that tomorrow. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From hson at opencsw.org Sat Jan 9 23:41:46 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Sat, 09 Jan 2010 23:41:46 +0100 Subject: [csw-maintainers] libcairo dependency on /usr/openwin/lib/libX11.so... Message-ID: <4B49062A.9020805@opencsw.org> Since the packages in /opt/csw/X11/lib got updated and more and more packages started to get linked to those, I've started updating my packages but often gotten into trouble with the following error. Undefined first referenced symbol in file XSolarisIASetProcessInfo /usr/openwin/lib/libX11.so.4 At first I just made some changes so that /usr/openwin/lib/libXext.so got added to the link-phase, but then I started to wonder why some of the newly updated packages still required those old libraries. It seems that the problem is libcairo and libxrender. When libcairo is built, it needs libXrender and finds one in /opt/csw/lib (which according to dago's comments in the Makefile is kept there for compatibility issues). But that lib is linked to libX11.so.4 (openwin version) and not libX11.so.6 (csw version) which the libXrender under /opt/csw/X11/lib is not. The reason for this is simple, gar adds $(prefix)/X11/lib after $(prefix)/lib and thus libcairo gets linked to the old libXrender library. I've committed some changes to the Makefile which fixes this problem. Dago, could you repackage and update buildfarm (maybe start on build8st and build8xt so we can work our way through all dependencies before releasing?) From skayser at opencsw.org Sun Jan 10 00:00:02 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 10 Jan 2010 00:00:02 +0100 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last Message-ID: <4B490A72.6000602@opencsw.org> Hi, our mailing list archive boosts at least a dozen of threads on libtool. Here comes another one from someone to whom the exact inner libtool workings are a mystery. When I try to build dante with kerberos support (enabled per default), libtool IMHO messes up the call to ld which then fails to find the CSW kerberos libraries. /bin/bash ../libtool --tag=CC --mode=link /opt/studio/SOS11/SUNWspro/bin/cc -DSOCKS_CLIENT=1 -DSOCKS_SERVER=0 -DSOCKSLIBRARY_DYNAMIC=0 -xO3 -xarch=v8 -Xt -xarch=v8 -L/opt/csw/lib -L/opt/csw/lib -R/opt/csw/lib -R/opt/csw/lib/ -R/opt/csw/lib -L/opt/csw/lib -z combreloc -z text -z ignore -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lkrb5support -lresolv -lsocket -lnsl -o libsocks.la -rpath /opt/csw/lib -version-info 1:1:1 config_parse.lo config_scan.lo Raccept.lo Rbind.lo Rgetpeername.lo Rgetsockname.lo Rrresvport.lo io.lo address.lo authneg.lo client.lo clientconfig.lo clientprotocol.lo udp.lo userio.lo connectchild.lo config.lo log.lo protocol.lo socket.lo udp_util.lo util.lo Rbindresvport.lo Rconnect.lo Rgethostbyname.lo debug.lo Rcompat.lo msproxy_clientprotocol.lo hostcache.lo broken.lo serr.lo httpproxy.lo tostring.lo addressmatch.lo Rlisten.lo upnp.lo gssapi.lo iobuf.lo ../libscompat/libscompat.la -L/opt/csw/lib -R/opt/csw/lib -R/opt/csw/lib/ -R/opt/csw/lib -L/opt/csw/li b -z combreloc -z text -z ignore -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lkrb5support -lresolv -lsocket -lnsl -lpam -lnsl -lsocket -lresolv -ldl /usr/ccs/bin/ld -G -h libsocks.so.0 -o .libs/libsocks.so.0.1.1 .libs/config_parse.o .libs/config_scan.o .libs/Raccept.o .libs/Rbind.o .libs/Rgetpeername.o .libs/Rgetsockname.o .libs/Rrresvport.o .libs/io.o .libs/address.o .libs/authneg.o .libs/client.o .libs/clientconfig.o .libs/clientprotocol.o .libs/udp.o .libs/userio.o .libs/connectchild.o .libs/config.o .libs/log.o .libs/protocol.o .libs/socket.o .libs/udp_util.o .libs/util.o .libs/Rbindresvport.o .libs/Rconnect.o .libs/Rgethostbyname.o .libs/debug.o .libs/Rcompat.o .libs/msproxy_clientprotocol.o .libs/hostcache.o .libs/broken.o .libs/serr.o .libs/httpproxy.o .libs/tostring.o .libs/addressmatch.o .libs/Rlisten.o .libs/upnp.o .libs/gssapi.o .libs/iobuf.o -z allextract ../libscompat/.libs/libscompat.a -z defaultextract -R/opt/csw/lib -R/opt/csw/lib/ -ldl -lresolv -lsocket -lnsl -lpam -lkrb5support -lcom_err -lk5crypto -lkrb5 -lgssapi_krb5 -L/opt/csw/lib -lc ld: fatal: library -lkrb5support: not found ld: fatal: library -lcom_err: not found ld: fatal: library -lk5crypto: not found ld: fatal: library -lkrb5: not found ld: fatal: library -lgssapi_krb5: not found ld: fatal: File processing errors. No output written to .libs/libsocks.so.0.1.1 gmake[3]: *** [libsocks.la] Error 1 gmake[3]: Leaving directory `/home/skayser/mgar/pkg/dante/trunk/work/solaris8-sparc/build-isa-sparcv8/dante-1.2.0/lib' To me it looks like libtool is rearranging linker flags. When it calls /usr/ccs/bin/ld it puts -L/opt/csw/lib after all the -l options which obviously breaks any references to CSW libs. The invocation of libtool itself still contains the correct -L/-l order. Any idea how to fix or circumvent this? $ work/solaris8-sparc/build-isa-sparcv8/dante-1.2.0/libtool --version ltmain.sh (GNU libtool) 1.5.26 (1.1220.2.493 2008/02/01 16:58:18) Sebastian From william at wbonnet.net Sun Jan 10 00:58:02 2010 From: william at wbonnet.net (William Bonnet) Date: Sun, 10 Jan 2010 00:58:02 +0100 Subject: [csw-maintainers] Upstream check for sourceforge not working? In-Reply-To: <4B426A38.3030504@opencsw.org> References: <4B425CE3.8050201@opencsw.org> <4B425F45.7050400@wbonnet.net> <4B426A38.3030504@opencsw.org> Message-ID: <4B49180A.7030905@wbonnet.net> Hi Roger > However the output from sourceforge must have changed because running > that command gives no output at all and running the wget manually and > checking the output tells me that upstream_watch cannot work with > their current design. That's right, something changed in the design of the web page and it no longer works. I have to modify my checks. Thanks for reporting this. 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 skayser at opencsw.org Sun Jan 10 11:54:24 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 10 Jan 2010 11:54:24 +0100 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: <4B490A72.6000602@opencsw.org> References: <4B490A72.6000602@opencsw.org> Message-ID: <4B49B1E0.20907@opencsw.org> Sebastian Kayser wrote on 10.01.2010 00:00: > When I try to build dante with kerberos support (enabled per default), > libtool IMHO messes up the call to ld which then fails to find the CSW > kerberos libraries. > > > /bin/bash ../libtool --tag=CC --mode=link /opt/studio/SOS11/SUNWspro/bin/cc -DSOCKS_CLIENT=1 -DSOCKS_SERVER=0 -DSOCKSLIBRARY_DYNAMIC=0 -xO3 -xarch=v8 -Xt -xarch=v8 -L/opt/csw/lib -L/opt/csw/lib -R/opt/csw/lib -R/opt/csw/lib/ -R/opt/csw/lib -L/opt/csw/lib -z combreloc -z text -z ignore -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lkrb5support -lresolv -lsocket -lnsl -o libsocks.la -rpath /opt/csw/lib -version-info 1:1:1 config_parse.lo config_scan.lo Raccept.lo Rbind.lo Rgetpeername.lo Rgetsockname.lo Rrresvport.lo io.lo address.lo authneg.lo client.lo clientconfig.lo clientprotocol.lo udp.lo userio.lo connectchild.lo config.lo log.lo protocol.lo socket.lo udp_util.lo util.lo Rbindresvport.lo Rconnect.lo Rgethostbyname.lo debug.lo Rcompat.lo msproxy_clientprotocol.lo hostcache.lo broken.lo serr.lo httpproxy.lo tostring.lo addressmatch.lo Rlisten.lo upnp.lo gssapi.lo iobuf.lo ../libscompat/libscompat.la -L/opt/csw/lib -R/opt/csw/lib -R/opt/csw/lib/ -R/opt/csw/lib -L/opt/csw/ li > b -z combreloc -z text -z ignore -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lkrb5support -lresolv -lsocket -lnsl -lpam -lnsl -lsocket -lresolv -ldl > /usr/ccs/bin/ld -G -h libsocks.so.0 -o .libs/libsocks.so.0.1.1 .libs/config_parse.o .libs/config_scan.o .libs/Raccept.o .libs/Rbind.o .libs/Rgetpeername.o .libs/Rgetsockname.o .libs/Rrresvport.o .libs/io.o .libs/address.o .libs/authneg.o .libs/client.o .libs/clientconfig.o .libs/clientprotocol.o .libs/udp.o .libs/userio.o .libs/connectchild.o .libs/config.o .libs/log.o .libs/protocol.o .libs/socket.o .libs/udp_util.o .libs/util.o .libs/Rbindresvport.o .libs/Rconnect.o .libs/Rgethostbyname.o .libs/debug.o .libs/Rcompat.o .libs/msproxy_clientprotocol.o .libs/hostcache.o .libs/broken.o .libs/serr.o .libs/httpproxy.o .libs/tostring.o .libs/addressmatch.o .libs/Rlisten.o .libs/upnp.o .libs/gssapi.o .libs/iobuf.o -z allextract ../libscompat/.libs/libscompat.a -z defaultextract -R/opt/csw/lib -R/opt/csw/lib/ -ldl -lresolv -lsocket -lnsl -lpam -lkrb5support -lcom_err -lk5crypto -lkrb5 -lgssapi_krb5 -L/opt/csw/lib -lc > ld: fatal: library -lkrb5support: not found > ld: fatal: library -lcom_err: not found > ld: fatal: library -lk5crypto: not found > ld: fatal: library -lkrb5: not found > ld: fatal: library -lgssapi_krb5: not found > ld: fatal: File processing errors. No output written to .libs/libsocks.so.0.1.1 > gmake[3]: *** [libsocks.la] Error 1 > gmake[3]: Leaving directory `/home/skayser/mgar/pkg/dante/trunk/work/solaris8-sparc/build-isa-sparcv8/dante-1.2.0/lib' > > > To me it looks like libtool is rearranging linker flags. When it calls > /usr/ccs/bin/ld it puts -L/opt/csw/lib after all the -l options which > obviously breaks any references to CSW libs. The invocation of libtool > itself still contains the correct -L/-l order. Any idea how to fix or > circumvent this? > > $ work/solaris8-sparc/build-isa-sparcv8/dante-1.2.0/libtool --version > ltmain.sh (GNU libtool) 1.5.26 (1.1220.2.493 2008/02/01 16:58:18) The Debian patch section for Dante showed that they patch ./configure to use the platform libtool instead of the one shipped with Dante. That's what I ended up doing also. $ gsed -ie 's,^LIBTOOL=.*,LIBTOOL=/opt/csw/bin/libtool,' \ work/solaris8-sparc/build-isa-sparcv8/dante-1.2.0/configure $ grep ^LIBTOOL= \ work/solaris8-sparc/build-isa-sparcv8/dante-1.2.0/configure LIBTOOL=/opt/csw/bin/libtool The problem went away. There still is a downrev libtool in $(WORKSRC) which seems to get re-generated by ./configure, but looking at the build logs its the /opt/csw/bin/libtool which now takes care of the linking. Sebastian From bwalton at opencsw.org Sun Jan 10 15:42:35 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 10 Jan 2010 09:42:35 -0500 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: <4B49B1E0.20907@opencsw.org> References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> Message-ID: <1263134474-sup-4605@ntdws12.chass.utoronto.ca> Excerpts from Sebastian Kayser's message of Sun Jan 10 05:54:24 -0500 2010: > The problem went away. There still is a downrev libtool in $(WORKSRC) > which seems to get re-generated by ./configure, but looking at the build > logs its the /opt/csw/bin/libtool which now takes care of the linking. Given the issues we constantly hit with libtool, I always find myself wondering if it was ever a benefit instead of a burden. Any grey-beards care to offer some historical perspective on this? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Joerg.Schilling at fokus.fraunhofer.de Sun Jan 10 15:45:28 2010 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Sun, 10 Jan 2010 15:45:28 +0100 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: <1263134474-sup-4605@ntdws12.chass.utoronto.ca> References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> <1263134474-sup-4605@ntdws12.chass.utoronto.ca> Message-ID: <4b49e808.V0Z29z8bBAlJHmV1%Joerg.Schilling@fokus.fraunhofer.de> Ben Walton wrote: > Given the issues we constantly hit with libtool, I always find myself > wondering if it was ever a benefit instead of a burden. Any > grey-beards care to offer some historical perspective on this? One of the main reasons for stying with the Schily makefile system concept from 1993 is that it allows to put the knowledge about the various linkers inside the make rules and to sty independend from libtool. From my experiences, libtool is only without pain if you are on Linux. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From bwalton at opencsw.org Sun Jan 10 15:50:06 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 10 Jan 2010 09:50:06 -0500 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: <4b49e808.V0Z29z8bBAlJHmV1%Joerg.Schilling@fokus.fraunhofer.de> References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> <1263134474-sup-4605@ntdws12.chass.utoronto.ca> <4b49e808.V0Z29z8bBAlJHmV1%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <1263134971-sup-3553@ntdws12.chass.utoronto.ca> Excerpts from Joerg.Schilling's message of Sun Jan 10 09:45:28 -0500 2010: > libtool. From my experiences, libtool is only without pain if you > are on Linux. And yet even the Debian folks seem to eschew libtool...? -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 hson at opencsw.org Mon Jan 11 01:29:56 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Mon, 11 Jan 2010 01:29:56 +0100 Subject: [csw-maintainers] libcairo dependency on /usr/openwin/lib/libX11.so... In-Reply-To: <4B49062A.9020805@opencsw.org> References: <4B49062A.9020805@opencsw.org> Message-ID: <4B4A7104.7090604@opencsw.org> On 2010-01-09 23:41, Roger H?kansson wrote: > I've committed some changes to the Makefile which fixes this problem. > Seems I was a little bit hasty in my assessment... My first fix will make libcairo use /opt/csw/X11/lib/libXrender.so at link time, but not runtime. I've tested with a second one where made sure that -R/opt/csw/X11/lib would be first in runtimepath but still, when linking librsvg for instance, the wrong libXrender.so will be picked. So as far as I can see it, in order to "fix" the problem, all packages which link to libXrender.so or to a another lib which link to libXrender.so, must make sure that /opt/csw/X11/lib before /opt/csw/lib in RUNPATH and not the opposite. Or we just remove /opt/csw/lib/libXrender.so* which probably would break a ton of packages. For now (and until someone tells me it's a bad idea) I'll make sure my packages have X11/lib first in runpath From james at opencsw.org Mon Jan 11 16:42:31 2010 From: james at opencsw.org (James Lee) Date: Mon, 11 Jan 2010 15:42:31 GMT Subject: [csw-maintainers] [csw-buildfarm] BO Buildfarm available again In-Reply-To: References: <4610F26C-0F72-4B02-AB82-72C14942A20D@opencsw.org> Message-ID: <20100111.15423100.2872566158@gyor.oxdrove.co.uk> On 08/01/10, 17:44:57, Dagobert Michelsen wrote regarding Re: [csw-buildfarm] [csw-maintainers] BO Buildfarm available again: > The T5220 is now split into two LDoms: One LDom with the existing > Solaris 10 > instance carrying all of the Sparc stuff which was already there (now > restricted to 12 GB Ram and 20 Strands) and one LDom with OpenSolaris > 06/09 Sparc still installing with 3 GB Ram and 8 Strands. Any reason for the restriction? James. From maciej at opencsw.org Mon Jan 11 16:56:33 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 11 Jan 2010 15:56:33 +0000 Subject: [csw-maintainers] Building glib2 Message-ID: I would like to get the newest gnome-terminal working, so I started looking at the endless chain of dependencies. gnome-terminal --> vte --> glib2. I started working on glib2-2.23.1, and after stamping out a couple issues, I got it to build. Sadly, one of the unit tests is failing: https://bugzilla.gnome.org/show_bug.cgi?id=606488 There's also a bug in mantis for future reference: http://www.opencsw.org/mantis/view.php?id=3771 I think the issue could use some more eyeballs. The code under tests is gio, the input-output library. TEST: utf8-input-stream... (pid=196) /utf8-input-stream/read-ascii: OK /utf8-input-stream/read-utf8: OK /utf8-input-stream/read-utf8-partial: OK /utf8-input-stream/read-invalid-start: OK /utf8-input-stream/read-invalid-middle: OK /utf8-input-stream/read-invalid-end: OK /utf8-input-stream/read-invalid-partial: OK /utf8-input-stream/read-small-valid: ** ERROR:utf8-input-stream.c:171:test_read_small_valid: assertion failed ("\xc3\xa8\xc3\xa8" == buf): ("\303\250\303\250" == "\303\250\303\250ar") FAIL GTester: last random seed: R02S5b7291138f726ccdccce512cd75e3f31 gmake[7]: *** [test] Error 143 gmake[7]: Leaving directory `/home/maciej/src/opencsw/pkg/glib2/trunk/work/solaris8-sparc/build-isa-sparcv8/glib-2.23.1/gio/tests' The problem is repeatable, happens every time. Do you have any suggestions or ideas? Maciej From maciej at opencsw.org Mon Jan 11 17:48:13 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 11 Jan 2010 16:48:13 +0000 Subject: [csw-maintainers] GAR: Preprocessing a postinstall file In-Reply-To: <1260585404-sup-1926@ntdws12.chass.utoronto.ca> References: <1260585404-sup-1926@ntdws12.chass.utoronto.ca> Message-ID: On Sat, Dec 12, 2009 at 2:53 AM, Ben Walton wrote: > Excerpts from Maciej (Matchek) Blizinski's message of Fri Dec 11 20:27:14 -0500 2009: >> Suppose I have a file CSWfoo.postinstall, which has some variables >> which need to be substituted before the file can be shipped. >> Something along the lines of: >> >> mycommand=@bindir@/foo > > Use the dynamic adm script capability in GAR. I've found a side effect of this capability: The preprocessed scripts are copied to /home/src on "gmake garchive". It holds for postgresql and gitosis. I'm guessing that you've never done gmake garchive for docbook. From bwalton at opencsw.org Mon Jan 11 17:55:20 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 11 Jan 2010 11:55:20 -0500 Subject: [csw-maintainers] GAR: Preprocessing a postinstall file In-Reply-To: References: <1260585404-sup-1926@ntdws12.chass.utoronto.ca> Message-ID: <1263228843-sup-2059@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Mon Jan 11 11:48:13 -0500 2010: > I've found a side effect of this capability: The preprocessed scripts > are copied to /home/src on "gmake garchive". It holds for postgresql > and gitosis. I'm guessing that you've never done gmake garchive for > docbook. Interesting. Certainly unintentional. I'll see if I can spot why this happens tonight and correct it. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Mon Jan 11 17:56:10 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 11 Jan 2010 16:56:10 +0000 Subject: [csw-maintainers] GAR: Basic custom tests for packages In-Reply-To: <242BF313-F6AA-492A-BCAE-2F4FF1498BC9@opencsw.org> References: <1256179371-sup-7948@ntdws12.chass.utoronto.ca> <242BF313-F6AA-492A-BCAE-2F4FF1498BC9@opencsw.org> Message-ID: On Thu, Oct 22, 2009 at 8:12 AM, Dagobert Michelsen wrote: > Hi Maciej, hi Ben, > > Am 22.10.2009 um 04:44 schrieb Ben Walton: > >> Am 22.10.2009 um 01:04 schrieb Maciej (Matchek) Blizinski: >>> >>> Let's suppose I wanted to write some basic checks for a package. For >>> instance, that I expect there to be a certain file in the prototype, >>> with such and such name and such and such attributes (ownership, >>> permissions, etc). I guess I would do something like: >>> >>> TEST_SCRIPTS = custom >>> >>> test-custom: >>> ? ? ? test code here >>> >>> How do I access things like the prototype, or files at the location >>> from where they're already merged? >> >> I think you'd want to work with the state of things after the merge. >> I don't think the stuff in build-global is guaranteed to be there >> until after that step. ?I don't know if there are pre/post merge >> targets though. > > Yes. Because the normal cycle for a software is > ?configure > ?compile > ?test > ?install > the procedure is the same in GAR. Now to your questions: > >>> For instance, that I expect there to be a certain file in the prototype, >>> with such and such name and such and such attributes (ownership, >>> permissions, etc) > > The prototype (if dynamic) is built during 'package' and there is currently > no hook in-between after dynamic creation of the packaging source files > and the package creation. You could check after package-creation in > post-package. Can a hook be created between the prototype creation and the package creation? Say, just after the creation of the per-package prototype files, so that I can also check that certain files have landed in the specific packages. >>> How do I access things like the prototype, or files at the location >>> from where they're already merged? > > From the global modulation the prototype can be accessed as > ?$(WORKDIR)/prototype > and the package specific prototypes as > ?$(WORKDIR)/CSWmypkg.prototype How do I know I'm in the global modulation? > The merge location is available during global or specific modulations as > $(PKGROOT). > > I suggest you write your test as post-package to ensure it has been built > correctly. However, if it proves useful we could also insert another > step before package creation like > ?pkgverify-CSWmypkg: I've been recently bitten by something that would've been prevented easily using this kind of a test, so I'll get back to it soon. Maciej From hson at opencsw.org Mon Jan 11 23:22:07 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Mon, 11 Jan 2010 23:22:07 +0100 Subject: [csw-maintainers] libcairo dependency on /usr/openwin/lib/libX11.so... In-Reply-To: <4B4A7104.7090604@opencsw.org> References: <4B49062A.9020805@opencsw.org> <4B4A7104.7090604@opencsw.org> Message-ID: <4B4BA48F.5090703@opencsw.org> Roger H?kansson wrote: > On 2010-01-09 23:41, Roger H?kansson wrote: >> I've committed some changes to the Makefile which fixes this problem. >> > > Seems I was a little bit hasty in my assessment... > My first fix will make libcairo use /opt/csw/X11/lib/libXrender.so at > link time, but not runtime. > I've tested with a second one where made sure that -R/opt/csw/X11/lib > would be first in runtimepath but still, when linking librsvg for > instance, the wrong libXrender.so will be picked. > > So as far as I can see it, in order to "fix" the problem, all packages > which link to libXrender.so or to a another lib which link to > libXrender.so, must make sure that /opt/csw/X11/lib before /opt/csw/lib > in RUNPATH and not the opposite. > Or we just remove /opt/csw/lib/libXrender.so* which probably would break > a ton of packages. > > For now (and until someone tells me it's a bad idea) I'll make sure my > packages have X11/lib first in runpath Just to clarify, I've added (and committed) this to the Makefile for libcairo: EXTRA_SOS_LD_FLAGS = -L$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) EXTRA_SOS_LD_OPTIONS = -R$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) This will give us a libcairo.so with /opt/csw/X11/lib first in RUNPATH. Then the packages using libcairo only need to have -L/opt/csw/X11/lib first during build (i.e same setting as libcairo for EXTRA_SOS_LD_FLAGS, but not EXTRA_SOS_LD_OPTIONS) Runtime everything seems to be ok (on my build machines where I've built and reinstalled packages as I built them) using these options. But that's only my quick observations. From maciej at opencsw.org Tue Jan 12 15:37:05 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 12 Jan 2010 14:37:05 +0000 Subject: [csw-maintainers] GAR: Category-level post-merge target Message-ID: Is it possible to add a category-level post-merge target? I would like there to be a post-merge target that is executed with my custom category, but I would like the individual packages to have separate post-merge targets. Is there such target already, or if not, can I create it in GAR? Say, category-post-merge? Maciej From phil at bolthole.com Tue Jan 12 18:31:28 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 12 Jan 2010 09:31:28 -0800 Subject: [csw-maintainers] libcairo dependency on /usr/openwin/lib/libX11.so... In-Reply-To: <4B4A7104.7090604@opencsw.org> References: <4B49062A.9020805@opencsw.org> <4B4A7104.7090604@opencsw.org> Message-ID: On Sun, Jan 10, 2010 at 4:29 PM, Roger H?kansson wrote: >>... > Seems I was a little bit hasty in my assessment... > My first fix will make libcairo use /opt/csw/X11/lib/libXrender.so at link > time, but not runtime. Side comment/tip: make sure that ALL DEPENDANCIES of libcairo, are using "our" version of libX, etc, rather than the /usr/openwin ones. Otherwise that can mess you up. Sadly, it's not enough to have the deps' version "up to date". you also have to have them using the compatible libs for themselves. so you might need to take over some. From phil at bolthole.com Tue Jan 12 18:32:52 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 12 Jan 2010 09:32:52 -0800 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: <1263134474-sup-4605@ntdws12.chass.utoronto.ca> References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> <1263134474-sup-4605@ntdws12.chass.utoronto.ca> Message-ID: On Sun, Jan 10, 2010 at 6:42 AM, Ben Walton wrote: > > Given the issues we constantly hit with libtool, I always find myself > wondering if it was ever a benefit instead of a burden. ?Any > grey-beards care to offer some historical perspective on this? > "libtool evil". this is why our official documented guidelines are, "REMOVE .la files from your packages" !!! From hson at opencsw.org Tue Jan 12 23:13:57 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Tue, 12 Jan 2010 23:13:57 +0100 Subject: [csw-maintainers] libcairo dependency on /usr/openwin/lib/libX11.so... In-Reply-To: References: <4B49062A.9020805@opencsw.org> <4B4A7104.7090604@opencsw.org> Message-ID: <4B4CF425.5080304@opencsw.org> Philip Brown wrote: > On Sun, Jan 10, 2010 at 4:29 PM, Roger H?kansson wrote: >>> ... >> Seems I was a little bit hasty in my assessment... >> My first fix will make libcairo use /opt/csw/X11/lib/libXrender.so at link >> time, but not runtime. > > Side comment/tip: > > make sure that ALL DEPENDANCIES of libcairo, are using "our" version > of libX, etc, rather than the /usr/openwin ones. Otherwise that can > mess you up. > > Sadly, it's not enough to have the deps' version "up to date". you > also have to have them using the compatible libs for themselves. so > you might need to take over some. Correct, that's why I sent the mail regarding how to fix the problem, so other maintainers know how to solve the problem in their package. The bigger issue is that there are probably packages already out there which are linked to "our" libX while many old packages depending on the newly updated packages, don't. Since the list of packages linked to libX11.so.4 are huge, there is a ton of work to update them all. I've been thinking of this a bit and see three options. First, let the recommendation be, "EXTRA_INC, EXTRA_LIB and EXTRA_PKG_CONFIG_DIRS shouldn't be set to our X11 unless you package a package which don't have any packages depending on it". This means that it will more or less take forever before we can break the dependency on libX11.so.4. Second option is to say "ok, let whatever package breaks, break and let the maintainers for those packages repackage ASAP plus make an collective effort repackaging packages without a current mantainer". The third option is to get two new farm machines (or use build8st/build8xt) where we can start rebuilding and installing packages "from the root", i.e packages which many packages depends on. This also means we need to branch off packages in GAR to create a "X11-repackage" branch for each package. So the question is what road we should take... From jeff at cjsa.com Wed Jan 13 07:42:41 2010 From: jeff at cjsa.com (Jeffery Small) Date: Wed, 13 Jan 2010 06:42:41 GMT Subject: [csw-maintainers] dbus Message-ID: There was a problem with the dbus package that kept the service from shutting down. This would keep Solaris from haulting because it waited for the service shutdown command to return and it never did. This is with version 1.2.12,REV=2009.03.25. This has apparently been fixed. So I upgraded libdbus to 1.2.12,REV=2009.08.10 and then tried to upgrade the dbus package. However, the first thing that the upgrade processes attempts is to shutdown the current dbus service - and this operation never returns so the upgrade never executes! If, as root, I manually run the command: svcadm disable svc:/system/cswdbus this returns. But the command which is used in the dbus package: svcadm disable -t svc:/system/cswdbus hangs. Even when I have issued the first disable command, when I check: svcs svc:/system/cswdbus STATE STIME FMRI online* 22:09:08 svc:/system/cswdbus:default although when I take a look at the complete listing of services with a simple svcs command, the cswdbus service is not reported? Apparently the service is actually stopped but some bookkeeping does not get completed so svcadm and svcs are confused about the actual state of things. I tried editing the command from the uncompressed package datastream file: dbus-1.2.12,REV=2009.08.10-SunOS5.8-sparc-CSW.pkg.gz.tmp but when I rerun the upgrade command, it unpack another version from dbus-1.2.12,REV=2009.08.10-SunOS5.8-sparc-CSW.pkg.gz I tried uncompressing the master package, editing the command in the datastream and then recompressed the file, but when I run the upgrade, it must check the package checksum, see that it is off and it downloads a fresh copy of the package, overwriting all of my attempts to edit the install script. So how is someone supposed to upgrade this package? I can't be the first person attempting to upgrade this package since last August. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From maciej at opencsw.org Wed Jan 13 11:27:24 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 13 Jan 2010 10:27:24 +0000 Subject: [csw-maintainers] A new check: package file name must match the architecture in pkginfo Message-ID: I've been bitten again by the package architecture mislabeling problem: the i386 package was given a *-sparc-CSW.pkg.gz file name. To prevent the problem from happening in the future, I've added a new test to checkpkg. https://sourceforge.net/apps/trac/gar/changeset/7984 If you want your packages to be checked with it, you need to update the gar subdirectory in your subversion clients. Maciej From maciej at opencsw.org Wed Jan 13 11:37:53 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 13 Jan 2010 10:37:53 +0000 Subject: [csw-maintainers] Determining the architecture of a binary Message-ID: I'd like to write a new check, to make sure that the actual binaries inside a package match the architecture declared in the pkginfo file. Unfortunately, the file command's output is not as reliable as I'd like it to. For instance, on build8s, it can tell when a binary is i386, but it doesn't say the same about an amd64 binary. maciej at build8s [build8s]:~ > file ~maciej/src/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/solaris8-i386/install-isa-i386/opt/csw/mysql5/bin/mysql | cut -d: -f2 ELF 32-bit LSB executable 80386 Version 1, dynamically linked, stripped maciej at build8s [build8s]:~ > file ~maciej/src/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/solaris8-i386/install-isa-amd64/opt/csw/mysql5/bin/amd64/mysql | cut -d: -f2 ELF 64-bit LSB executable Version 1, dynamically linked, stripped We don't have our own, up-to-date file (or gfile), do we? Is there a better way of determining binary's architecture? (/usr/ccs/bin/dump?) Maciej From skayser at opencsw.org Wed Jan 13 12:07:54 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 13 Jan 2010 12:07:54 +0100 Subject: [csw-maintainers] Determining the architecture of a binary In-Reply-To: References: Message-ID: <20100113110754.GD18224@sebastiankayser.de> Hi Maciej, * Maciej (Matchek) Blizinski wrote: > I'd like to write a new check, to make sure that the actual binaries > inside a package match the architecture declared in the pkginfo file. > Unfortunately, the file command's output is not as reliable as I'd > like it to. For instance, on build8s, it can tell when a binary is > i386, but it doesn't say the same about an amd64 binary. > > maciej at build8s [build8s]:~ > file > ~maciej/src/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/solaris8-i386/install-isa-i386/opt/csw/mysql5/bin/mysql > | cut -d: -f2 > ELF 32-bit LSB executable 80386 Version 1, dynamically linked, stripped > maciej at build8s [build8s]:~ > file > ~maciej/src/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/solaris8-i386/install-isa-amd64/opt/csw/mysql5/bin/amd64/mysql > | cut -d: -f2 > ELF 64-bit LSB executable Version 1, dynamically linked, stripped > > We don't have our own, up-to-date file (or gfile), do we? > > Is there a better way of determining binary's architecture? (/usr/ccs/bin/dump?) great to see that you are enhancing the checks. The more we do catch upfront the better it is for all involved people (maintainer and release manager). You could have a look at the ELF header via elfdump. All outputs are from build8s. $ /usr/ccs/bin/elfdump -e ~maciej/src/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/solaris8-i386/install-isa-i386/opt/csw/mysql5/bin/mysql | grep e_machine e_machine: EM_386 e_version: EV_CURRENT $ /usr/ccs/bin/elfdump -e ~maciej/src/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/solaris8-i386/install-isa-amd64/opt/csw/mysql5/bin/amd64/mysql | grep e_machine e_machine: EM_AMD64 e_version: EV_CURRENT $ /usr/ccs/bin/elfdump -e ~maciej/src/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/solaris8-sparc/install-isa-sparcv8/opt/csw/mysql5/bin/mysql | grep e_machine e_machine: EM_SPARC e_version: EV_CURRENT $ /usr/ccs/bin/elfdump -e ~maciej/src/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/solaris8-sparc/install-isa-sparcv9/opt/csw/mysql5/bin/sparcv9/mysql | grep e_machine e_machine: EM_SPARCV9 e_version: EV_CURRENT Sebastian From james at opencsw.org Wed Jan 13 13:49:31 2010 From: james at opencsw.org (James Lee) Date: Wed, 13 Jan 2010 12:49:31 GMT Subject: [csw-maintainers] Determining the architecture of a binary In-Reply-To: References: Message-ID: <20100113.12493100.2174588176@gyor.oxdrove.co.uk> On 13/01/10, 10:37:53, Maciej "(Matchek)" Blizinski wrote regarding [csw-maintainers] Determining the architecture of a binary: > I'd like to write a new check, to make sure that the actual binaries > inside a package match the architecture declared in the pkginfo file. > Unfortunately, the file command's output is not as reliable as I'd > like it to. For instance, on build8s, it can tell when a binary is > i386, but it doesn't say the same about an amd64 binary. > maciej at build8s [build8s]:~ > file > ~maciej/src/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/solaris8-i386/i ns tall-isa-i386/opt/csw/mysql5/bin/mysql > | cut -d: -f2 > ELF 32-bit LSB executable 80386 Version 1, dynamically linked, stripped > maciej at build8s [build8s]:~ > file > ~maciej/src/opencsw/pkg/mysql5/branches/mysql-5.0.x/work/solaris8-i386/i ns tall-isa-amd64/opt/csw/mysql5/bin/amd64/mysql > | cut -d: -f2 > ELF 64-bit LSB executable Version 1, dynamically linked, stripped "LSB" goes with i386 and "MSB" goes with sparc. I guess it stands for least and most significant bit for the endian. If it's 64 bit and not sparc then what else is it? James. From hson at opencsw.org Wed Jan 13 13:50:22 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Wed, 13 Jan 2010 13:50:22 +0100 Subject: [csw-maintainers] Determining the architecture of a binary In-Reply-To: References: Message-ID: <4B4DC18E.4040408@opencsw.org> Maciej (Matchek) Blizinski wrote: > I'd like to write a new check, to make sure that the actual binaries > inside a package match the architecture declared in the pkginfo file. > Unfortunately, the file command's output is not as reliable as I'd > like it to. For instance, on build8s, it can tell when a binary is > i386, but it doesn't say the same about an amd64 binary. As far as I know "ELF 64-bit LSB" can only be an amd64 binary, sparc binaries are all MSB. From hson at opencsw.org Wed Jan 13 13:51:20 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Wed, 13 Jan 2010 13:51:20 +0100 Subject: [csw-maintainers] Determining the architecture of a binary In-Reply-To: <20100113.12493100.2174588176@gyor.oxdrove.co.uk> References: <20100113.12493100.2174588176@gyor.oxdrove.co.uk> Message-ID: <4B4DC1C8.1050207@opencsw.org> James Lee wrote: > > "LSB" goes with i386 and "MSB" goes with sparc. I guess it stands for > least and most significant bit for the endian. Correct. From dam at opencsw.org Wed Jan 13 16:33:19 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 13 Jan 2010 16:33:19 +0100 Subject: [csw-maintainers] [csw-buildfarm] BO Buildfarm available again In-Reply-To: <20100111.15423100.2872566158@gyor.oxdrove.co.uk> References: <4610F26C-0F72-4B02-AB82-72C14942A20D@opencsw.org> <20100111.15423100.2872566158@gyor.oxdrove.co.uk> Message-ID: <3863F96D-2DD6-441B-A1FE-3BB0575193A2@opencsw.org> Hi James, Am 11.01.2010 um 16:42 schrieb James Lee: > On 08/01/10, 17:44:57, Dagobert Michelsen wrote > regarding > Re: [csw-buildfarm] [csw-maintainers] BO Buildfarm available again: > >> The T5220 is now split into two LDoms: One LDom with the existing >> Solaris 10 >> instance carrying all of the Sparc stuff which was already there (now >> restricted to 12 GB Ram and 20 Strands) and one LDom with OpenSolaris >> 06/09 Sparc still installing with 3 GB Ram and 8 Strands. > > Any reason for the restriction? Because the machine doesn't have more resources ;-) There is also a control domain with 1 GB Ram and 4 Strands which sums up to 16 GB and 32 strands total. Best regards -- Dago From dam at opencsw.org Wed Jan 13 16:42:47 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 13 Jan 2010 16:42:47 +0100 Subject: [csw-maintainers] GAR: Basic custom tests for packages In-Reply-To: References: <1256179371-sup-7948@ntdws12.chass.utoronto.ca> <242BF313-F6AA-492A-BCAE-2F4FF1498BC9@opencsw.org> Message-ID: Hi Maciej, Am 11.01.2010 um 17:56 schrieb Maciej (Matchek) Blizinski: >>>> For instance, that I expect there to be a certain file in the >>>> prototype, >>>> with such and such name and such and such attributes (ownership, >>>> permissions, etc) >> >> The prototype (if dynamic) is built during 'package' and there is >> currently >> no hook in-between after dynamic creation of the packaging source >> files >> and the package creation. You could check after package-creation in >> post-package. > > Can a hook be created between the prototype creation and the package > creation? Say, just after the creation of the per-package prototype > files, so that I can also check that certain files have landed in the > specific packages. Yes, but currently only on a per-package base as the prototype creation and packaging is done in one step, one package after another. It would be possible to installed a hook here, of course: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/gar.pkg.mk#L711 >>>> How do I access things like the prototype, or files at the location >>>> from where they're already merged? >> >> From the global modulation the prototype can be accessed as >> $(WORKDIR)/prototype >> and the package specific prototypes as >> $(WORKDIR)/CSWmypkg.prototype > > How do I know I'm in the global modulation? Just see if $(MODULATION) == "global" >> The merge location is available during global or specific >> modulations as >> $(PKGROOT). >> >> I suggest you write your test as post-package to ensure it has been >> built >> correctly. However, if it proves useful we could also insert another >> step before package creation like >> pkgverify-CSWmypkg: > > I've been recently bitten by something that would've been prevented > easily using this kind of a test, so I'll get back to it soon. Ok. Best regards -- Dago From dam at opencsw.org Wed Jan 13 16:48:35 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 13 Jan 2010 16:48:35 +0100 Subject: [csw-maintainers] libcairo dependency on /usr/openwin/lib/libX11.so... In-Reply-To: <4B4BA48F.5090703@opencsw.org> References: <4B49062A.9020805@opencsw.org> <4B4A7104.7090604@opencsw.org> <4B4BA48F.5090703@opencsw.org> Message-ID: <380ED26A-1249-4794-BDBC-B17770BDD823@opencsw.org> Hi Roger, Am 11.01.2010 um 23:22 schrieb Roger H?kansson: > Roger H?kansson wrote: >> On 2010-01-09 23:41, Roger H?kansson wrote: >>> I've committed some changes to the Makefile which fixes this >>> problem. >>> >> Seems I was a little bit hasty in my assessment... >> My first fix will make libcairo use /opt/csw/X11/lib/libXrender.so >> at link time, but not runtime. >> I've tested with a second one where made sure that -R/opt/csw/X11/ >> lib would be first in runtimepath but still, when linking librsvg >> for instance, the wrong libXrender.so will be picked. >> So as far as I can see it, in order to "fix" the problem, all >> packages which link to libXrender.so or to a another lib which link >> to libXrender.so, must make sure that /opt/csw/X11/lib before /opt/ >> csw/lib in RUNPATH and not the opposite. >> Or we just remove /opt/csw/lib/libXrender.so* which probably would >> break a ton of packages. >> For now (and until someone tells me it's a bad idea) I'll make sure >> my packages have X11/lib first in runpath > > Just to clarify, I've added (and committed) this to the Makefile for > libcairo: > EXTRA_SOS_LD_FLAGS = -L$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) > EXTRA_SOS_LD_OPTIONS = -R$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) > > This will give us a libcairo.so with /opt/csw/X11/lib first in > RUNPATH. > > Then the packages using libcairo only need to have -L/opt/csw/X11/lib > first during build (i.e same setting as libcairo for > EXTRA_SOS_LD_FLAGS, but not EXTRA_SOS_LD_OPTIONS) > Runtime everything seems to be ok (on my build machines where I've > built > and reinstalled packages as I built them) using these options. But > that's only my quick observations. I guess it would be generally helpful to put EXTRA libraries in front of the standard path at /opt/csw/lib as opposed to appending it. Best regards -- Dago From dam at opencsw.org Wed Jan 13 17:37:59 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 13 Jan 2010 17:37:59 +0100 Subject: [csw-maintainers] GAR: Category-level post-merge target In-Reply-To: References: Message-ID: <46DC478A-8525-4400-8382-850A9F498F74@opencsw.org> Hi Maciej, Am 12.01.2010 um 15:37 schrieb Maciej (Matchek) Blizinski: > Is it possible to add a category-level post-merge target? I would > like there to be a post-merge target that is executed with my custom > category, but I would like the individual packages to have separate > post-merge targets. Is there such target already, or if not, can I > create it in GAR? Say, category-post-merge? I guess I don't understand what you mean "by category". From my understanding the category is defined in CATEGORY and controls some file to include for category-specific behaviour. That means there is no such thing as a "category phase" like there is a phase for extract, patch, configure, etc. Or do you mean a harcoded _post-merge-category target which is always called can can be overwritten inside a category? This is easily doable if you need it. Best regards -- Dago From dam at opencsw.org Wed Jan 13 17:39:33 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 13 Jan 2010 17:39:33 +0100 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> <1263134474-sup-4605@ntdws12.chass.utoronto.ca> Message-ID: Hi Phil, Am 12.01.2010 um 18:32 schrieb Philip Brown: > On Sun, Jan 10, 2010 at 6:42 AM, Ben Walton > wrote: >> >> Given the issues we constantly hit with libtool, I always find myself >> wondering if it was ever a benefit instead of a burden. Any >> grey-beards care to offer some historical perspective on this? > > "libtool evil". > > this is why our official documented guidelines are, > "REMOVE .la files from your packages" !!! He he, and just now I get a bug report for a package that doesn't work without the .la-files: Best regards -- Dago From dam at opencsw.org Wed Jan 13 17:45:31 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 13 Jan 2010 17:45:31 +0100 Subject: [csw-maintainers] dbus In-Reply-To: References: Message-ID: Hi Jeff, Am 13.01.2010 um 07:42 schrieb Jeffery Small: > There was a problem with the dbus package that kept the service from > shutting > down. ... > So how is someone supposed to upgrade this package? I can't be the > first > person attempting to upgrade this package since last August. This was announced together with the updated package on users@ in September: Am 03.09.2009 um 23:01 schrieb William Bonnet: > Hi, > > A new version of the dbus packages will be pushed to current catalog > in the next hours. This version fixes the fllowing bug > > 0003626: dbus daemon will not stop on reboot/init 6 blocking the > shutdown ( http://opencsw.org/bugtrack/view.php?id=3626 ). > > > This bugs prevents dbus from stop correctly. If dbus is running, it > will be stop during update, thus update may freeze. In order to > avoid this situation, you have to be sure that you don't have dbus > running, or if it is running, you will have to kill it by hand > before the upgrade. You can retrieve the pid to kill with the > following command : > > bash-3.00# cat /opt/csw/var/run/dbus/pid > 1592 > > or > > bash-3.00# ps -elf | grep dbus-daemon > 0 S messageb 1592 1 0 40 20 ? 634 ? > 22:55:25 ? 0:00 /opt/csw/bin/dbus-daemon --system > > Please "kill -9" the dbus process before running package upgrade. > > Kind regards > W. > > -- > William http://www.wbonnet.net > > http://www.sunwizard.net Le site fran?ais des amateurs de stations > Unix > http://www.opencsw.org Community SoftWare for Solaris > http://www.guses.org French speaking Solaris User Group > > > _______________________________________________ > users mailing list > users at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/users Hope this helps. Best regards -- Dago From hson at opencsw.org Wed Jan 13 17:46:05 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Wed, 13 Jan 2010 17:46:05 +0100 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> <1263134474-sup-4605@ntdws12.chass.utoronto.ca> Message-ID: <4B4DF8CD.5040500@opencsw.org> Dagobert Michelsen wrote: > Hi Phil, > > Am 12.01.2010 um 18:32 schrieb Philip Brown: >> On Sun, Jan 10, 2010 at 6:42 AM, Ben Walton wrote: >>> >>> Given the issues we constantly hit with libtool, I always find myself >>> wondering if it was ever a benefit instead of a burden. Any >>> grey-beards care to offer some historical perspective on this? >> >> "libtool evil". >> >> this is why our official documented guidelines are, >> "REMOVE .la files from your packages" !!! > > He he, and just now I get a bug report for a package that doesn't work > without the .la-files: > Same as ImageMagick, they use libtool runtime to load internal modules. So MERGE_EXCLUDE_LIBTOOL need to be set to MERGE_EXCLUDE_LIBTOOL ?= $(libdir)/lib.*\.la instead of MERGE_EXCLUDE_LIBTOOL ?= $(libdir)/.*\.la From hson at opencsw.org Wed Jan 13 17:51:48 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Wed, 13 Jan 2010 17:51:48 +0100 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: <4B4DF8CD.5040500@opencsw.org> References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> <1263134474-sup-4605@ntdws12.chass.utoronto.ca> <4B4DF8CD.5040500@opencsw.org> Message-ID: <4B4DFA24.5040601@opencsw.org> Roger H?kansson wrote: > Dagobert Michelsen wrote: >> Hi Phil, >> >> Am 12.01.2010 um 18:32 schrieb Philip Brown: >>> On Sun, Jan 10, 2010 at 6:42 AM, Ben Walton wrote: >>>> >>>> Given the issues we constantly hit with libtool, I always find myself >>>> wondering if it was ever a benefit instead of a burden. Any >>>> grey-beards care to offer some historical perspective on this? >>> >>> "libtool evil". >>> >>> this is why our official documented guidelines are, >>> "REMOVE .la files from your packages" !!! >> >> He he, and just now I get a bug report for a package that doesn't work >> without the .la-files: >> > > Same as ImageMagick, they use libtool runtime to load internal modules. > So MERGE_EXCLUDE_LIBTOOL need to be set to > MERGE_EXCLUDE_LIBTOOL ?= $(libdir)/lib.*\.la instead of > MERGE_EXCLUDE_LIBTOOL ?= $(libdir)/.*\.la Note: Thats not a general solution, packages with 64-bit libs or packages which have libraries in other places need to have MERGE_EXCLUDE_LIBTOOL properly set. "MERGE_EXCLUDE_LIBTOOL ?= $(libdir).*/lib.*\.la" might be a more general solution From maciej at opencsw.org Wed Jan 13 17:53:00 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 13 Jan 2010 16:53:00 +0000 Subject: [csw-maintainers] GAR: Category-level post-merge target In-Reply-To: <46DC478A-8525-4400-8382-850A9F498F74@opencsw.org> References: <46DC478A-8525-4400-8382-850A9F498F74@opencsw.org> Message-ID: On Wed, Jan 13, 2010 at 4:37 PM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 12.01.2010 um 15:37 schrieb Maciej (Matchek) Blizinski: >> >> Is it possible to add a category-level post-merge target? I would >> like there to be a post-merge target that is executed with my custom >> category, but I would like the individual packages to have separate >> post-merge targets. ?Is there such target already, or if not, can I >> create it in GAR? ?Say, category-post-merge? > > I guess I don't understand what you mean "by category". From my > understanding the category is defined in CATEGORY and controls > some file to include for category-specific behaviour. That means > there is no such thing as a "category phase" like there is a > phase for extract, patch, configure, etc. > > Or do you mean a harcoded _post-merge-category target which is > always called can can be overwritten inside a category? This > is easily doable if you need it. Yes, that's what I meant. Something like the currently existing category-level depends, used by the python class. From dam at opencsw.org Wed Jan 13 18:00:12 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 13 Jan 2010 18:00:12 +0100 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: <4B4DFA24.5040601@opencsw.org> References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> <1263134474-sup-4605@ntdws12.chass.utoronto.ca> <4B4DF8CD.5040500@opencsw.org> <4B4DFA24.5040601@opencsw.org> Message-ID: Hi Roger, Am 13.01.2010 um 17:51 schrieb Roger H?kansson: > Roger H?kansson wrote: >> Dagobert Michelsen wrote: >>> Hi Phil, >>> >>> Am 12.01.2010 um 18:32 schrieb Philip Brown: >>>> On Sun, Jan 10, 2010 at 6:42 AM, Ben Walton >>>> wrote: >>>>> >>>>> Given the issues we constantly hit with libtool, I always find >>>>> myself >>>>> wondering if it was ever a benefit instead of a burden. Any >>>>> grey-beards care to offer some historical perspective on this? >>>> >>>> "libtool evil". >>>> >>>> this is why our official documented guidelines are, >>>> "REMOVE .la files from your packages" !!! >>> >>> He he, and just now I get a bug report for a package that doesn't >>> work >>> without the .la-files: >>> >> Same as ImageMagick, they use libtool runtime to load internal >> modules. >> So MERGE_EXCLUDE_LIBTOOL need to be set to >> MERGE_EXCLUDE_LIBTOOL ?= $(libdir)/lib.*\.la instead of >> MERGE_EXCLUDE_LIBTOOL ?= $(libdir)/.*\.la > > Note: Thats not a general solution, packages with 64-bit libs or > packages which have libraries in other places need to have > MERGE_EXCLUDE_LIBTOOL properly set. > > "MERGE_EXCLUDE_LIBTOOL ?= $(libdir).*/lib.*\.la" might be a more > general solution I would like to keep the general solution of excluding all libtool-files and let the maintainer decide this on a case-by-case basis. Including .la-files should be the exception. Best regards -- Dago From hson at opencsw.org Wed Jan 13 18:03:13 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Wed, 13 Jan 2010 18:03:13 +0100 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> <1263134474-sup-4605@ntdws12.chass.utoronto.ca> <4B4DF8CD.5040500@opencsw.org> <4B4DFA24.5040601@opencsw.org> Message-ID: <4B4DFCD1.40303@opencsw.org> Dagobert Michelsen wrote: > Hi Roger, > > Am 13.01.2010 um 17:51 schrieb Roger H?kansson: > >> Roger H?kansson wrote: >>> Dagobert Michelsen wrote: >>>> Hi Phil, >>>> >>>> Am 12.01.2010 um 18:32 schrieb Philip Brown: >>>>> On Sun, Jan 10, 2010 at 6:42 AM, Ben Walton >>>>> wrote: >>>>>> >>>>>> Given the issues we constantly hit with libtool, I always find myself >>>>>> wondering if it was ever a benefit instead of a burden. Any >>>>>> grey-beards care to offer some historical perspective on this? >>>>> >>>>> "libtool evil". >>>>> >>>>> this is why our official documented guidelines are, >>>>> "REMOVE .la files from your packages" !!! >>>> >>>> He he, and just now I get a bug report for a package that doesn't work >>>> without the .la-files: >>>> >>> Same as ImageMagick, they use libtool runtime to load internal modules. >>> So MERGE_EXCLUDE_LIBTOOL need to be set to >>> MERGE_EXCLUDE_LIBTOOL ?= $(libdir)/lib.*\.la instead of >>> MERGE_EXCLUDE_LIBTOOL ?= $(libdir)/.*\.la >> >> Note: Thats not a general solution, packages with 64-bit libs or >> packages which have libraries in other places need to have >> MERGE_EXCLUDE_LIBTOOL properly set. >> >> "MERGE_EXCLUDE_LIBTOOL ?= $(libdir).*/lib.*\.la" might be a more >> general solution > > I would like to keep the general solution of excluding all libtool-files > and let the maintainer decide this on a case-by-case basis. Including > .la-files should be the exception. > Correct, with "general solution", I meant "starting point solution for those cases that need to keep some .la-files" There are only a few cases where .la-files need to be kept in the package. From hson at opencsw.org Wed Jan 13 18:10:39 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Wed, 13 Jan 2010 18:10:39 +0100 Subject: [csw-maintainers] BUILD64 Message-ID: <4B4DFE8F.80201@opencsw.org> Some info someone else might find usable... According to "GAR Variable Reference", BUILD64 should be set to 1 to build 64-bit targets, but actually the current GAR code doesn't care what you set it to, just that its set. If you check out something that has BUILD64=1 set and want to build a 32-bit-only package, I couldn't find any way except edit the Makefile before building. So I patched my local gar.conf.mk to fix this. "$if( $(BUILD64)...." is changed to "$if( eq($(BUILD64),1)...." With that change, setting "BUILD64=0" in ~/.garrc or prepending before gmake, will let you build a 32-bit-only package. (my personal x86-build server isn't 64-bit ready so I can only run Solaris8 and Solaris10 in 32-bit-mode) From jeff at cjsa.com Wed Jan 13 20:57:36 2010 From: jeff at cjsa.com (Jeffery Small) Date: Wed, 13 Jan 2010 19:57:36 GMT Subject: [csw-maintainers] dbus References: Message-ID: Dagobert Michelsen writes: >This was announced together with the updated package on users@ >in September: >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 [...] Thanks Dagobert. I'm sorry that I missed the announcement back in September. I followed the procedures and did get the updated package installed. I really appreciate the quick response. Two comments: 1) It would be good to get the news section for packages up and running so that information like this could be used to list important information like this. 2) Is there some reason that the test for the bad installed version of dbus was not performed by the package's install script and then have the script automatically check for a running process and kill it as part of the upgrade procedure, rather than force the user to perform a manual intervention? I ask this as a general question regarding all packages that might require a non-standard form of intervention during installation. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From skayser at opencsw.org Wed Jan 13 21:13:33 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 13 Jan 2010 21:13:33 +0100 Subject: [csw-maintainers] dbus In-Reply-To: References: Message-ID: <4B4E296D.9030708@opencsw.org> Jeffery Small wrote on 13.01.2010 20:57: > Dagobert Michelsen writes: > >> This was announced together with the updated package on users@ >> in September: > >> 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 [...] > > Thanks Dagobert. > > I'm sorry that I missed the announcement back in September. I followed the > procedures and did get the updated package installed. I really appreciate > the quick response. Two comments: > > 1) It would be good to get the news section for packages up and running so > that information like this could be used to list important information like > this. +1 The NEWS link on www.opencsw.org/packages/ points to the Mantis news page for a package. Each maintainer should be able to populate this section for his packages already. That's where important news about that package could go. Nothing fancy, but better than it is right now. What I also really would like to see is a changelog.CSW shipped with each package which is somehow hooked into the release process. The NEWS section could then be automatically updated. I just had a troubleshooting session with someone who updated amavisd-new and from the package side it took me some time of distilling the important items in the GAR logs to see what had changed. That's where the NEWS would have been helpful also. > 2) Is there some reason that the test for the bad installed version of > dbus was not performed by the package's install script and then have the > script automatically check for a running process and kill it as part of > the upgrade procedure, rather than force the user to perform a manual > intervention? I ask this as a general question regarding all packages that > might require a non-standard form of intervention during installation. The bad dbus package was already installed and in my case it was the uninstallation that hung. Nothing that the new package could have dealt with, or? Sebastian From skayser at opencsw.org Wed Jan 13 22:59:02 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 13 Jan 2010 22:59:02 +0100 Subject: [csw-maintainers] CSW packaged MTAs and /usr (continued from "CSWcswclassutils: it wants to write in /usr") Message-ID: <4B4E4226.40600@opencsw.org> Greetings, as our postfix packages needs some makeover, there is something I took away from the discussion about cswclassutils and /usr [1] which relates to our MTAs in general: #1 Automatically messing with system binaries is considered evil. (e.g. /usr/lib/sendmail, /usr/bin/mailq, and /usr/sbin/newaliases) #2 A CSW MTA that doesn't replace /usr/lib/sendmail isn't really integrated with the system (i.e. not guaranteed to catch all mail originating from the system) Currently the postfix package automatically tries to move away the system binaries and to link its own binaries into place. While this tries to fully integrate with the system, it violates rule #1. There are also a couple of bugs open against the package where this procedure fails in sparse zone enviroments [2]. With an updated postfix package I would like to make the package as simple as possible and leave control to the user. Therefor I would like to emit a notification message on package installation, either pointing the user to a README.CSW, a script, an additional integration package, or simply to echo commands that one can issue to integrate postfix with the system. Now I am wondering what these commands should do. Should they mimic the current behavior of mv .OFF && ln or would it rather be preferable to say pkgrm && ln I am specifically thinking about the latter option because of Solaris patches. What would happen if we left the system sendmail packages in place and simply moved away the binaries? Wouldn't a sendmail patch notice the installed sendmail package and overwrite our link with possibly patched binaries? Granted, pkgrm wouldn't make it easy for a user to revert back to system sendmail .. just trying to get a feeling for the different approaches. Feedback very welcome! Sebastian [1] http://thread.gmane.org/gmane.os.solaris.opencsw.maintainers/4955 [2] http://www.opencsw.org/mantis/set_project.php?project_id=147 From skayser at opencsw.org Thu Jan 14 00:02:27 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 14 Jan 2010 00:02:27 +0100 Subject: [csw-maintainers] dbus In-Reply-To: <4B4E296D.9030708@opencsw.org> References: <4B4E296D.9030708@opencsw.org> Message-ID: <4B4E5103.1010704@opencsw.org> Sebastian Kayser wrote on 13.01.2010 21:13: > Jeffery Small wrote on 13.01.2010 20:57: >> Dagobert Michelsen writes: >> >>> This was announced together with the updated package on users@ >>> in September: >>> 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 [...] >> Thanks Dagobert. >> >> I'm sorry that I missed the announcement back in September. I followed the >> procedures and did get the updated package installed. I really appreciate >> the quick response. Two comments: >> >> 1) It would be good to get the news section for packages up and running so >> that information like this could be used to list important information like >> this. > > +1 > > The NEWS link on www.opencsw.org/packages/ points to the Mantis > news page for a package. Each maintainer should be able to populate this > section for his packages already. That's where important news about that > package could go. Nothing fancy, but better than it is right now. Sorry, seems as if I was a bit hasty. While you should be able to populate the NEWS for each of your packages in the bug tracker (and view these news via "Main" after selecting one package in the drop down list to the upper right), the links from the individual package pages on opencsw.org/packages/ don't seem to be working yet (as the notes next to the links obviously point out). Will need to give it some thought and will post an update once I have done so (probably in about a week - during winter camp). Sebastian From bwalton at opencsw.org Thu Jan 14 00:41:46 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 13 Jan 2010 18:41:46 -0500 Subject: [csw-maintainers] CSW packaged MTAs and /usr (continued from "CSWcswclassutils: it wants to write in /usr") In-Reply-To: <4B4E4226.40600@opencsw.org> References: <4B4E4226.40600@opencsw.org> Message-ID: <1263425934-sup-3926@ntdws12.chass.utoronto.ca> Excerpts from Sebastian Kayser's message of Wed Jan 13 16:59:02 -0500 2010: > or would it rather be preferable to say > > pkgrm && ln This should be: ... && ln -s since the binaries won't be delivered to /usr. I personally still think this stinks (I use exim, but it's the same pita)...anyway, like many other things on solaris, I'll continue to hit them with my cfengine hammer. > I am specifically thinking about the latter option because of Solaris > patches. What would happen if we left the system sendmail packages in > place and simply moved away the binaries? Wouldn't a sendmail patch > notice the installed sendmail package and overwrite our link with > possibly patched binaries? Granted, pkgrm wouldn't make it easy for a Yes, the package tools would overwrite the link and restore the system sendmail. There is a setting that can be toggled to prevent this...I'd have to look it up as I'm not sure what it is off the top of my head. Since we need to live with these unfortunate rules, I think your approach of simplifying the package and providing 'guidelines' via README.CSW is the best option. 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. From bwalton at opencsw.org Thu Jan 14 01:36:44 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 13 Jan 2010 19:36:44 -0500 Subject: [csw-maintainers] new mailing list? Message-ID: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> Hi All, I'd like to propose a new, internal-only mailing list. The purpose of the list would be to record all package release requests. This would replace the current practice of private mails to Phil. This list would be open to posting from any @opencsw.org address, but would be subscribed on request by maintainers as desired, not automatically. There are a few reasons I'd like to see this happen: 1. Packages that are rejected are typically rejected for common reasons. The more people the see these, the better we'll get over time as we stop making the same mistakes. 2. History preservation. 3. Team maintainership memory. Presently, if mails are private between $release_manager and $maintainer, a $maintainer2 may not know why a package is not being released. A list archive could resolve this. This follows from #2. 4. More visible maintainer activity. This is an easy way to keep an eye on who's releasing what. This info can be gotten other ways of course, but this is a more passive approach to seeing the same info. 5. Openness. It pulls back the curtains a bit more on some of the backend happenings. Thoughts from others? 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 skayser at opencsw.org Thu Jan 14 02:45:42 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 14 Jan 2010 02:45:42 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> Message-ID: <4B4E7746.4030605@opencsw.org> Ben Walton wrote on 14.01.2010 01:36: > I'd like to propose a new, internal-only mailing list. The purpose of > the list would be to record all package release requests. This would > replace the current practice of private mails to Phil. This list > would be open to posting from any @opencsw.org address, but would be > subscribed on request by maintainers as desired, not automatically. > > There are a few reasons I'd like to see this happen: Sounds good. > 1. Packages that are rejected are typically rejected for common > reasons. The more people the see these, the better we'll get over > time as we stop making the same mistakes. And Maciej can keep updating checkpkg to implement checks for those common reasons (at least those that can be determined via a script). ;) Sweet! > 2. History preservation. > 3. Team maintainership memory. Presently, if mails are private > between $release_manager and $maintainer, a $maintainer2 may not > know why a package is not being released. A list archive could > resolve this. This follows from #2. That's a good one. I remember Benny and Mike tag teaming sendmail (lot of impetus behind it). Benny started the build recipe, Mike wanted to do the final touchings and then release the package. In fact, Mike committed quite some changes to the build recipe, but when he vanished into sabbatical shortly after, the package wasn't released and Benny didn't know a thing about the current state (had it been submitted for release? were there any remaining problems with it?). The impetus was pretty much lost from what I could tell from his face. If it was for a release mailing list, he could have at least quickly seen whether the package was already considered for release (and learn about potential release critical issues that he would have needed to take care of). Even if he would have seen that the package hadn't even been submitted he would have known right away that he could just pick up from the existing build recipe. IMHO makes things easier compared to pinging phil (or any release manager for that matter) via email and waiting for the timezones to shift in the right place for a reply. Easier for both parties. > 5. Openness. It pulls back the curtains a bit more on some of the > backend happenings. Openness/transparency is always good (unless you are in the secret service business of course ;) ). That's btw. one reason why I will be trying hard to publish on-time news during winter camp this time (plus some sort of "video conferencing" test-setup), so that all those who can't make it, can get a better feeling of what is happening behind those "winter camp curtains" :) Sebastian From skayser at opencsw.org Thu Jan 14 03:03:11 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 14 Jan 2010 03:03:11 +0100 Subject: [csw-maintainers] CSW packaged MTAs and /usr (continued from "CSWcswclassutils: it wants to write in /usr") In-Reply-To: <1263425934-sup-3926@ntdws12.chass.utoronto.ca> References: <4B4E4226.40600@opencsw.org> <1263425934-sup-3926@ntdws12.chass.utoronto.ca> Message-ID: <4B4E7B5F.4020105@opencsw.org> Ben Walton wrote on 14.01.2010 00:41: > Excerpts from Sebastian Kayser's message of Wed Jan 13 16:59:02 -0500 2010: >> or would it rather be preferable to say >> >> pkgrm && ln > > This should be: > > ... && ln -s > > since the binaries won't be delivered to /usr. I personally still > think this stinks (I use exim, but it's the same pita)...anyway, like > many other things on solaris, I'll continue to hit them with my > cfengine hammer. As with the similar discussion about cups, system integration could also be handled by an optional "integration package". For starters, my main focus is to produce a simplified and updated postfix package. >> I am specifically thinking about the latter option because of Solaris >> patches. What would happen if we left the system sendmail packages in >> place and simply moved away the binaries? Wouldn't a sendmail patch >> notice the installed sendmail package and overwrite our link with >> possibly patched binaries? Granted, pkgrm wouldn't make it easy for a > > Yes, the package tools would overwrite the link and restore the system > sendmail. There is a setting that can be toggled to prevent > this...I'd have to look it up as I'm not sure what it is off the top > of my head. If such an option exists, that would help alot. Than we could simply say "move old binaries away, symlink our binaries, and set this option". Provides an easy rollback option to system sendmail, though users would need to make sure to re-apply patches which they might have missed in the meantime. > Since we need to live with these unfortunate rules, I think your > approach of simplifying the package and providing 'guidelines' via > README.CSW is the best option. Thanks for the feedback, Ben. Sebastian From skayser at opencsw.org Thu Jan 14 04:16:45 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 14 Jan 2010 04:16:45 +0100 Subject: [csw-maintainers] GAR: Changes to checkpkg: shared libraries and modularity In-Reply-To: References: Message-ID: <4B4E8C9D.2030904@opencsw.org> Hi Maciej, Maciej (Matchek) Blizinski wrote on 04.01.2010 16:43: > The v2-checkpkg branch has been merged to v2 today. It means that the > new shared library checking code is now live. The next time you > update your GAR sources, the new code will be pulled in. > > [...] > > If you have any questions, I'll be happy to answer them. checkpkg-libs.py seems to have troubles picking up some libs. libdb-4.2.so is in /opt/csw/bdb42/lib and libpq.so.5 is in /opt/csw/postgresql/lib. Excerpt of the results from running checkpkg on a postfix package: ~skayser/pkgs/postfix-2.6.2\,REV\=2010.01.14-SunOS5.8-sparc-UNCOMMITTED.pkg.gz Analysis of sonames needed by the package set: ... libdb-4.2.so is required by set(['spawn', 'postmulti', 'postkick', 'postlog', 'postconf', 'bounce', 'qmqpd', 'nqmgr', 'flush', 'proxymap', 'scache', 'anvil', 'verify', 'postalias', 'postcat', 'virtual', 'pickup', 'oqmgr', 'master', 'postqueue', 'postmap', 'local', 'showq', 'sendmail', 'smtpd', 'lmtp', 'postdrop', 'trivial-rewrite', 'postfix', 'postlock', 'pipe', 'tlsmgr', 'error', 'discard', 'postsuper', 'cleanup']), but we don't know what provides it. ... libpq.so.5 is required by set(['spawn', 'postmulti', 'postkick', 'postlog', 'postconf', 'bounce', 'qmqpd', 'nqmgr', 'flush', 'proxymap', 'scache', 'anvil', 'verify', 'postalias', 'postcat', 'virtual', 'pickup', 'oqmgr', 'master', 'postqueue', 'postmap', 'local', 'showq', 'sendmail', 'smtpd', 'lmtp', 'postdrop', 'trivial-rewrite', 'postfix', 'postlock', 'pipe', 'tlsmgr', 'error', 'discard', 'postsuper', 'cleanup']), but we don't know what provides it. ... CSWpostfix: SUGGESTION: you may want to add some or all of the following as depends: (Feel free to ignore SUNW or SPRO packages) > SUNWcslx The following packages might be unnecessary dependencies: ? CSWbdb4 ? CSWlibpq The following sonames don't belong to any package: ! libdb-4.2.so ! libpq.so.5 Traceback (most recent call last): File "gar/bin/checkpkg.d/checkpkg-libs.py", line 206, in main() File "gar/bin/checkpkg.d/checkpkg-libs.py", line 195, in main "any package: %s" % checker.soname)) AttributeError: 'CheckpkgBase' object has no attribute 'soname' LOG END: /var/tmp/dissect.22044/checkpkg-libs.py.log ERROR: One or more tests have failed. gmake: *** [pkgcheck] Error 2 Observed on build8s. Besides tweaking the lib detection, could you fix/catch the error? And maybe get rid of the surrounding set() in the error messages (re-format the output to match its appearance to the regular "libfoo is required by" output?)? Sebastian From bonivart at opencsw.org Thu Jan 14 10:04:30 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 14 Jan 2010 10:04:30 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> Message-ID: <625385e31001140104u61ac1128g3bac618b544a960e@mail.gmail.com> On Thu, Jan 14, 2010 at 1:36 AM, Ben Walton wrote: > > Hi All, > > I'd like to propose a new, internal-only mailing list. ?The purpose of > the list would be to record all package release requests. ?This would > replace the current practice of private mails to Phil. ?This list > would be open to posting from any @opencsw.org address, but would be > subscribed on request by maintainers as desired, not automatically. +1 -- /peter From maciej at opencsw.org Thu Jan 14 12:11:11 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 14 Jan 2010 11:11:11 +0000 Subject: [csw-maintainers] GAR: Changes to checkpkg: shared libraries and modularity In-Reply-To: <4B4E8C9D.2030904@opencsw.org> References: <4B4E8C9D.2030904@opencsw.org> Message-ID: On Thu, Jan 14, 2010 at 3:16 AM, Sebastian Kayser wrote: > Hi Maciej, > > Maciej (Matchek) Blizinski wrote on 04.01.2010 16:43: >> The v2-checkpkg branch has been merged to v2 today. ?It means that the >> new shared library checking code is now live. ?The next time you >> update your GAR sources, the new code will be pulled in. >> >> [...] >> >> If you have any questions, I'll be happy to answer them. > > checkpkg-libs.py seems to have troubles picking up some libs. > libdb-4.2.so is in /opt/csw/bdb42/lib and libpq.so.5 is in > /opt/csw/postgresql/lib. > > Excerpt of the results from running checkpkg on a postfix package: > ~skayser/pkgs/postfix-2.6.2\,REV\=2010.01.14-SunOS5.8-sparc-UNCOMMITTED.pkg.gz Thanks for the path, I could reproduce the issue. > CSWpostfix: > SUGGESTION: you may want to add some or all of the following as depends: > ? (Feel free to ignore SUNW or SPRO packages) >> SUNWcslx > The following packages might be unnecessary dependencies: > ? CSWbdb4 > ? CSWlibpq > The following sonames don't belong to any package: > ! libdb-4.2.so > ! libpq.so.5 There were two problems. One was that '/opt/csw/postgresql/lib/' != '/opt/csw/postgresql/lib'. I added code to handle trailing slashes (and double slashes too). The RPATH of postgresql binaries was: 'runpath': ['/opt/csw/lib/$ISALIST', '/opt/csw/lib', '/opt/csw/bdb4/lib', '/opt/csw/mysql5/lib/mysql', '/opt/csw/postgresql/lib/', /* <-- the problem! */ '/usr/lib/$ISALIST', '/usr/lib', '/lib/$ISALIST', '/lib'] The second problem was that my code did not know about the symlink from /opt/csw/bdb4 to /opt/csw/bdb42. For now, there's a relatively dumb code which substitutes paths like this one. I didn't go for reimplementing the complete symlink handling. Here's the change: https://sourceforge.net/apps/trac/gar/changeset/7999 The new output is as expected: CSWpostfix: SUGGESTION: you may want to add some or all of the following as depends: (Feel free to ignore SUNW or SPRO packages) > CSWbdb42 > SUNWcslx The following packages might be unnecessary dependencies: ? CSWbdb4 > Traceback (most recent call last): > ?File "gar/bin/checkpkg.d/checkpkg-libs.py", line 206, in > ? ?main() > ?File "gar/bin/checkpkg.d/checkpkg-libs.py", line 195, in main > ? ?"any package: %s" % checker.soname)) > AttributeError: 'CheckpkgBase' object has no attribute 'soname' > > LOG END: /var/tmp/dissect.22044/checkpkg-libs.py.log > > ERROR: One or more tests have failed. > gmake: *** [pkgcheck] Error 2 > > > > Observed on build8s. Besides tweaking the lib detection, could you > fix/catch the error? Fixed. > And maybe get rid of the surrounding set() in > the error messages (re-format the output to match its appearance > to the regular "libfoo is required by" output?)? Yup, good idea, but I'm putting in on the todo stack for now. From hson at opencsw.org Thu Jan 14 13:55:00 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Thu, 14 Jan 2010 13:55:00 +0100 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> <1262725258-sup-3515@ntdws12.chass.utoronto.ca> <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> Message-ID: <4B4F1424.2080109@opencsw.org> Dagobert Michelsen wrote: > Hi Ben, > > Am 05.01.2010 um 22:01 schrieb Ben Walton: >> Excerpts from Dagobert Michelsen's message of Tue Jan 05 15:56:02 -0500 2010: >> >>> be needed. Thoughts? >> 10 only. If the devs aren't interested in older platforms and you >> have no personal need, why go through the headache? > > The question is: Do we want to release it and make separate releases > of packages for Solaris 8/9 vs. 10 which require it? > libproxy is a requirement for some gnome-packages which would mean that we can't upgrade upgrade them without libproxy, and since some of those packages have dependencies on other packages which might get upgraded we would soon end up with a lot of Solaris8-packages which doesn't work. From james at opencsw.org Thu Jan 14 15:05:21 2010 From: james at opencsw.org (James Lee) Date: Thu, 14 Jan 2010 14:05:21 GMT Subject: [csw-maintainers] [csw-buildfarm] BO Buildfarm available again In-Reply-To: <3863F96D-2DD6-441B-A1FE-3BB0575193A2@opencsw.org> References: <4610F26C-0F72-4B02-AB82-72C14942A20D@opencsw.org> <20100111.15423100.2872566158@gyor.oxdrove.co.uk> <3863F96D-2DD6-441B-A1FE-3BB0575193A2@opencsw.org> Message-ID: <20100114.14052100.2348471893@gyor.oxdrove.co.uk> On 13/01/10, 15:33:19, Dagobert Michelsen wrote regarding Re: [csw-maintainers] [csw-buildfarm] BO Buildfarm available again: > >> The T5220 is now split into two LDoms: One LDom with the existing > >> Solaris 10 > >> instance carrying all of the Sparc stuff which was already there (now > >> restricted to 12 GB Ram and 20 Strands) and one LDom with OpenSolaris > >> 06/09 Sparc still installing with 3 GB Ram and 8 Strands. > > > > Any reason for the restriction? > Because the machine doesn't have more resources ;-) Excuse me the machine does, prior to enhancement each virtual machine had 60% more available CPUs. > There is also > a control domain with 1 GB Ram and 4 Strands which sums up to > 16 GB and 32 strands total. Ah yes so LDOMs are restrictive. Sorry I've only read the marketing bumph which suggests resources are shared. That is on the misleading side of truthful as there is no dynamic sharing of CPU and memory. Where load is sporadic as for build hard partitioning is a waste of a good machine. James. From pfelecan at opencsw.org Thu Jan 14 15:47:42 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 14 Jan 2010 15:47:42 +0100 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: (Philip Brown's message of "Tue, 12 Jan 2010 09:32:52 -0800") References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> <1263134474-sup-4605@ntdws12.chass.utoronto.ca> Message-ID: Philip Brown writes: > On Sun, Jan 10, 2010 at 6:42 AM, Ben Walton wrote: >> >> Given the issues we constantly hit with libtool, I always find myself >> wondering if it was ever a benefit instead of a burden. ?Any >> grey-beards care to offer some historical perspective on this? >> > > "libtool evil". saying that, is evil. -- Peter From pfelecan at opencsw.org Thu Jan 14 15:49:27 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 14 Jan 2010 15:49:27 +0100 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: <4B4DFCD1.40303@opencsw.org> ("Roger =?iso-8859-1?Q?H=E5kanss?= =?iso-8859-1?Q?on=22's?= message of "Wed, 13 Jan 2010 18:03:13 +0100") References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> <1263134474-sup-4605@ntdws12.chass.utoronto.ca> <4B4DF8CD.5040500@opencsw.org> <4B4DFA24.5040601@opencsw.org> <4B4DFCD1.40303@opencsw.org> Message-ID: Roger H?kansson writes: >> Dagobert Michelsen wrote: >> I would like to keep the general solution of excluding all libtool-files >> and let the maintainer decide this on a case-by-case basis. Including >> .la-files should be the exception. >> > > Correct, with "general solution", I meant "starting point solution for > those cases that need to keep some .la-files" > There are only a few cases where .la-files need to be kept in the package. and for those cases it's a real PITA to convince the gate keeper of the day. -- Peter From pfelecan at opencsw.org Thu Jan 14 16:10:53 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 14 Jan 2010 16:10:53 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> (Ben Walton's message of "Wed, 13 Jan 2010 19:36:44 -0500") References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> Message-ID: Ben Walton writes: > Hi All, > > I'd like to propose a new, internal-only mailing list. The purpose of > the list would be to record all package release requests. [...] > Thoughts from others? completely supporting this proposal. therefore: +INF -- Peter From maciej at opencsw.org Thu Jan 14 19:15:32 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 14 Jan 2010 18:15:32 +0000 Subject: [csw-maintainers] GAR and isaexec: merging to $ISA subdirs doesn't work In-Reply-To: <4B450899.5030501@opencsw.org> References: <4B44701E.1070100@opencsw.org> <080DF858-63AB-4867-9B3F-3ABA7A43E645@opencsw.org> <4B450899.5030501@opencsw.org> Message-ID: On Wed, Jan 6, 2010 at 10:03 PM, Sebastian Kayser wrote: > Hi Dago, > > Dagobert Michelsen wrote on 06.01.2010 22:36: >> Am 06.01.2010 um 12:12 schrieb Sebastian Kayser: >>> I just removed NO_ISAEXEC=1 from the mbuffer package to make it a >>> regular 32-/64-bit package with isaexec as a wrapper. The resulting >>> package looks just like before though. No isaexec symlink and the >>> default $ISA in bin/. What's wrong? Running "gmake spotless package" >>> leads to the same result. Current build description is checked >>> in [1]. >> >> I guess you hit this bug: >> ? >> >> Please try "gmake repackage" unless it has been fixed. > > indeed, "gmake repackage" did the trick. Thank you. With this kind of a volatile problem, having a check would be good. This is more or less what I was getting at with the post-prototype pre-package check in GAR. If the problem happens regularly, we need to at least detect the problem every time it happens. Dago, do you have an implementation idea from the top of your head? From phil at bolthole.com Thu Jan 14 19:37:20 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 14 Jan 2010 10:37:20 -0800 Subject: [csw-maintainers] new mailing list? In-Reply-To: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> Message-ID: On Wednesday, January 13, 2010, Ben wrote ... > There are a few reasons I'd like to see this happen: > > 1. Packages that are rejected are typically rejected for common > ? reasons. ?The more people the see these, the better we'll get over > ? time as we stop making the same mistakes. I don't thnk this will help. for one thing it's usually the new maintainers that make the mist mistakes . they're not going to go back and read the archives. secondly the is enough maintainer email flying around as is. I would guess most mantainers would choose NOT to be subscribed to such a boring list From bwalton at opencsw.org Thu Jan 14 19:45:10 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 14 Jan 2010 13:45:10 -0500 Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> Message-ID: <1263494521-sup-2239@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Jan 14 13:37:20 -0500 2010: > I don't thnk this will help. > for one thing it's usually the new maintainers that make the mist > mistakes . they're not going to go back and read the archives. But, other maintainers could cull a rejection-FAQ from it that new maintainers would like/use. The number of people that know the common issues right now is ~1. With the list, that number can grow. > secondly the is enough maintainer email flying around as is. I would > guess most mantainers would choose NOT to be subscribed to such a > boring list But they don't have to be. As long as any @opencsw.org address can post, those interested could subscribe. The benefit of archiving the info is still obtained. A small change in operation for a fair amount of benefit, imo. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rupert at opencsw.org Thu Jan 14 20:15:55 2010 From: rupert at opencsw.org (rupert THURNER) Date: Thu, 14 Jan 2010 20:15:55 +0100 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> <1263134474-sup-4605@ntdws12.chass.utoronto.ca> <4B4DF8CD.5040500@opencsw.org> <4B4DFA24.5040601@opencsw.org> Message-ID: <6af4271001141115s5bdcacdbu4fcaae6ec696b336@mail.gmail.com> On Wed, Jan 13, 2010 at 18:00, Dagobert Michelsen wrote: > Hi Roger, > > Am 13.01.2010 um 17:51 schrieb Roger H?kansson: > > > Roger H?kansson wrote: >> >>> Dagobert Michelsen wrote: >>> >>>> Hi Phil, >>>> >>>> Am 12.01.2010 um 18:32 schrieb Philip Brown: >>>> >>>>> On Sun, Jan 10, 2010 at 6:42 AM, Ben Walton >>>>> wrote: >>>>> >>>>>> >>>>>> Given the issues we constantly hit with libtool, I always find myself >>>>>> wondering if it was ever a benefit instead of a burden. Any >>>>>> grey-beards care to offer some historical perspective on this? >>>>>> >>>>> >>>>> "libtool evil". >>>>> >>>>> this is why our official documented guidelines are, >>>>> "REMOVE .la files from your packages" !!! >>>>> >>>> >>>> He he, and just now I get a bug report for a package that doesn't work >>>> without the .la-files: >>>> >>>> >>> Same as ImageMagick, they use libtool runtime to load internal modules. >>> So MERGE_EXCLUDE_LIBTOOL need to be set to >>> MERGE_EXCLUDE_LIBTOOL ?= $(libdir)/lib.*\.la instead of >>> MERGE_EXCLUDE_LIBTOOL ?= $(libdir)/.*\.la >>> >> >> Note: Thats not a general solution, packages with 64-bit libs or packages >> which have libraries in other places need to have MERGE_EXCLUDE_LIBTOOL >> properly set. >> >> "MERGE_EXCLUDE_LIBTOOL ?= $(libdir).*/lib.*\.la" might be a more general >> solution >> > > I would like to keep the general solution of excluding all libtool-files > and let the maintainer decide this on a case-by-case basis. Including > .la-files should be the exception. > > svn-1.6.7 also was complaining about a missing .la file, while svn-1.6.6 did not. i had no time to track down if this was caused by a libtool upgrade in between the build, or the subversion build changed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Thu Jan 14 22:09:41 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 14 Jan 2010 22:09:41 +0100 Subject: [csw-maintainers] BUILD64 In-Reply-To: <4B4DFE8F.80201@opencsw.org> References: <4B4DFE8F.80201@opencsw.org> Message-ID: <91C693DD-4514-4467-AF89-C5FA16190383@opencsw.org> Hi Roger, Am 13.01.2010 um 18:10 schrieb Roger H?kansson: > Some info someone else might find usable... > > According to "GAR Variable Reference", BUILD64 should be set to 1 to > build 64-bit targets, but actually the current GAR code doesn't care > what you set it to, just that its set. > If you check out something that has BUILD64=1 set and want to build > a 32-bit-only package, I couldn't find any way except edit the > Makefile before building. > So I patched my local gar.conf.mk to fix this. > "$if( $(BUILD64)...." is changed to "$if( eq($(BUILD64),1)...." > > With that change, setting "BUILD64=0" in ~/.garrc or prepending > before gmake, will let you build a 32-bit-only package. > (my personal x86-build server isn't 64-bit ready so I can only run > Solaris8 and Solaris10 in 32-bit-mode) Feel free to commit that change to the main tree. Best regards -- Dago From dam at opencsw.org Thu Jan 14 22:23:24 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 14 Jan 2010 22:23:24 +0100 Subject: [csw-maintainers] dbus In-Reply-To: <4B4E296D.9030708@opencsw.org> References: <4B4E296D.9030708@opencsw.org> Message-ID: <3BCBB553-3744-467A-8874-E9B99D961E43@opencsw.org> Hi, Am 13.01.2010 um 21:13 schrieb Sebastian Kayser: > Jeffery Small wrote on 13.01.2010 20:57: >> Dagobert Michelsen writes: >> >>> This was announced together with the updated package on users@ >>> in September: >> >>> 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 [...] >> >> Thanks Dagobert. >> >> I'm sorry that I missed the announcement back in September. I >> followed the >> procedures and did get the updated package installed. I really >> appreciate >> the quick response. Two comments: >> >> 1) It would be good to get the news section for packages up and >> running so >> that information like this could be used to list important >> information like >> this. > > +1 > > The NEWS link on www.opencsw.org/packages/ points to the > Mantis > news page for a package. Each maintainer should be able to populate > this > section for his packages already. That's where important news about > that > package could go. Nothing fancy, but better than it is right now. This is definitely a good idea. We also have http://wiki.opencsw.org/packages Too many places for so simple things... > What I also really would like to see is a changelog.CSW shipped with > each package which is somehow hooked into the release process. The > NEWS > section could then be automatically updated. I just had a > troubleshooting session with someone who updated amavisd-new and from > the package side it took me some time of distilling the important > items > in the GAR logs to see what had changed. That's where the NEWS would > have been helpful also. The package news section should IMHO have one entry per release. The ChangeLog is usually updated on every edit session which may or may not result in a released package, so I'd propose a modified approach here. >> 2) Is there some reason that the test for the bad installed version >> of >> dbus was not performed by the package's install script and then >> have the >> script automatically check for a running process and kill it as >> part of >> the upgrade procedure, rather than force the user to perform a manual >> intervention? I ask this as a general question regarding all >> packages that >> might require a non-standard form of intervention during >> installation. > > The bad dbus package was already installed and in my case it was the > uninstallation that hung. Nothing that the new package could have > dealt > with, or? I think so, yes. Upgrade-triggers would help circumvent these kinds of problems. Best regards -- Dago From dam at opencsw.org Thu Jan 14 22:27:27 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 14 Jan 2010 22:27:27 +0100 Subject: [csw-maintainers] CSW packaged MTAs and /usr (continued from "CSWcswclassutils: it wants to write in /usr") In-Reply-To: <4B4E4226.40600@opencsw.org> References: <4B4E4226.40600@opencsw.org> Message-ID: <25605C8E-E185-455C-9B62-0407D2918CE0@opencsw.org> Hi Sebastian, Am 13.01.2010 um 22:59 schrieb Sebastian Kayser: > as our postfix packages needs some makeover, there is something I took > away from the discussion about cswclassutils and /usr [1] which > relates > to our MTAs in general: > > #1 Automatically messing with system binaries is considered evil. > (e.g. /usr/lib/sendmail, /usr/bin/mailq, and /usr/sbin/newaliases) > > #2 A CSW MTA that doesn't replace /usr/lib/sendmail isn't really > integrated with the system (i.e. not guaranteed to catch all mail > originating from the system) > > Currently the postfix package automatically tries to move away the > system binaries and to link its own binaries into place. While this > tries to fully integrate with the system, it violates rule #1. There > are > also a couple of bugs open against the package where this procedure > fails in sparse zone enviroments [2]. > > With an updated postfix package I would like to make the package as > simple as possible and leave control to the user. Therefor I would > like > to emit a notification message on package installation, either > pointing > the user to a README.CSW, a script, an additional integration package, > or simply to echo commands that one can issue to integrate postfix > with > the system. > > Now I am wondering what these commands should do. Should they mimic > the > current behavior of > > mv .OFF && ln > > or would it rather be preferable to say > > pkgrm && ln I would go as far as pkgrm && pkgutil -i > I am specifically thinking about the latter option because of Solaris > patches. What would happen if we left the system sendmail packages in > place and simply moved away the binaries? Wouldn't a sendmail patch > notice the installed sendmail package and overwrite our link with > possibly patched binaries? Yes. > Granted, pkgrm wouldn't make it easy for a > user to revert back to system sendmail .. just trying to get a feeling > for the different approaches. It is easy. Just pkgadd the previous sendmail from Solaris. As we discussed there should be a catalog ("extra"? "solreplace"?) with the stub packages being incompatible with the Solaris provided ones and doing the integration. Best regards -- Dago From dam at opencsw.org Thu Jan 14 22:28:44 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 14 Jan 2010 22:28:44 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> Message-ID: <8B61B45D-AC95-4267-9868-8F3C24C263BF@opencsw.org> Hi Ben, Am 14.01.2010 um 01:36 schrieb Ben Walton: > I'd like to propose a new, internal-only mailing list. The purpose of > the list would be to record all package release requests. This would > replace the current practice of private mails to Phil. This list > would be open to posting from any @opencsw.org address, but would be > subscribed on request by maintainers as desired, not automatically. > > There are a few reasons I'd like to see this happen: > > 1. Packages that are rejected are typically rejected for common > reasons. The more people the see these, the better we'll get over > time as we stop making the same mistakes. > 2. History preservation. > 3. Team maintainership memory. Presently, if mails are private > between $release_manager and $maintainer, a $maintainer2 may not > know why a package is not being released. A list archive could > resolve this. This follows from #2. > 4. More visible maintainer activity. This is an easy way to keep an > eye on who's releasing what. This info can be gotten other ways of > course, but this is a more passive approach to seeing the same > info. > 5. Openness. It pulls back the curtains a bit more on some of the > backend happenings. > > Thoughts from others? I fully support this. Best regards -- Dago From dam at opencsw.org Thu Jan 14 22:39:22 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 14 Jan 2010 22:39:22 +0100 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <4B4F1424.2080109@opencsw.org> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> <1262725258-sup-3515@ntdws12.chass.utoronto.ca> <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> <4B4F1424.2080109@opencsw.org> Message-ID: <6383CAAE-CCA4-42A2-B9E6-538AE742A8CB@opencsw.org> Hi Roger, Am 14.01.2010 um 13:55 schrieb Roger H?kansson: > Dagobert Michelsen wrote: >> Hi Ben, >> Am 05.01.2010 um 22:01 schrieb Ben Walton: >>> Excerpts from Dagobert Michelsen's message of Tue Jan 05 15:56:02 >>> -0500 2010: >>> >>>> be needed. Thoughts? >>> 10 only. If the devs aren't interested in older platforms and you >>> have no personal need, why go through the headache? >> The question is: Do we want to release it and make separate releases >> of packages for Solaris 8/9 vs. 10 which require it? > > libproxy is a requirement for some gnome-packages which would mean > that we can't upgrade upgrade them without libproxy, and since some > of those packages have dependencies on other packages which might > get upgraded we would soon end up with a lot of Solaris8-packages > which doesn't work. The alternatives would be: (1) wait until the project switches to C++ (should be done pretty soon) where the standard is supported by SOS11. (2) Use GCC to compile libproxy. This would pull in gcc*rt, but would work fine. (3) Start with Solaris 10. By definition we start at Solaris 9, although the download stats say almost all people use Solaris 10 by now (see http://wiki.opencsw.org/suggestions mirror stats if you are curious). I'd go in that order. Let me know if you need libproxy now, then I'd start with (2). Best regards -- Dago From dam at opencsw.org Thu Jan 14 22:43:09 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 14 Jan 2010 22:43:09 +0100 Subject: [csw-maintainers] [csw-buildfarm] BO Buildfarm available again In-Reply-To: <20100114.14052100.2348471893@gyor.oxdrove.co.uk> References: <4610F26C-0F72-4B02-AB82-72C14942A20D@opencsw.org> <20100111.15423100.2872566158@gyor.oxdrove.co.uk> <3863F96D-2DD6-441B-A1FE-3BB0575193A2@opencsw.org> <20100114.14052100.2348471893@gyor.oxdrove.co.uk> Message-ID: Hi James, Am 14.01.2010 um 15:05 schrieb James Lee: > On 13/01/10, 15:33:19, Dagobert Michelsen wrote > regarding > Re: [csw-maintainers] [csw-buildfarm] BO Buildfarm available again: > >>>> The T5220 is now split into two LDoms: One LDom with the existing >>>> Solaris 10 >>>> instance carrying all of the Sparc stuff which was already there >>>> (now >>>> restricted to 12 GB Ram and 20 Strands) and one LDom with >>>> OpenSolaris >>>> 06/09 Sparc still installing with 3 GB Ram and 8 Strands. >>> >>> Any reason for the restriction? > >> Because the machine doesn't have more resources ;-) > > Excuse me the machine does, prior to enhancement each virtual machine > had 60% more available CPUs. Is this a problem for you? Are you really using that many parallel threads? If it proves useful I could lower the assignments from OSOL to the Solaris 10 LDom. >> There is also >> a control domain with 1 GB Ram and 4 Strands which sums up to >> 16 GB and 32 strands total. > > Ah yes so LDOMs are restrictive. Sorry I've only read the marketing > bumph which suggests resources are shared. Yes, the machine is shared like "there are two OS instances on shared hardware". The hardware is not shared, but partitioned. > That is on the misleading > side of truthful as there is no dynamic sharing of CPU and memory. > Where load is sporadic as for build hard partitioning is a waste of a > good machine. I had the impression that the T5220 wasn't used that much at all. Most of the time the load is beneath 3 or 4 (from 32 in the previous configuration). If you have suggestions on how to better utilize the resources I am all ears. Best regards -- Dago From dam at opencsw.org Thu Jan 14 22:43:48 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 14 Jan 2010 22:43:48 +0100 Subject: [csw-maintainers] libtool rearranges linker arguments and puts -L/opt/csw/lib last In-Reply-To: References: <4B490A72.6000602@opencsw.org> <4B49B1E0.20907@opencsw.org> <1263134474-sup-4605@ntdws12.chass.utoronto.ca> <4B4DF8CD.5040500@opencsw.org> <4B4DFA24.5040601@opencsw.org> <4B4DFCD1.40303@opencsw.org> Message-ID: Hi Peter, Am 14.01.2010 um 15:49 schrieb Peter FELECAN: > Roger H?kansson writes: >>> Dagobert Michelsen wrote: >>> I would like to keep the general solution of excluding all libtool- >>> files >>> and let the maintainer decide this on a case-by-case basis. >>> Including >>> .la-files should be the exception. >>> >> >> Correct, with "general solution", I meant "starting point solution >> for >> those cases that need to keep some .la-files" >> There are only a few cases where .la-files need to be kept in the >> package. > > and for those cases it's a real PITA to convince the gate keeper of > the > day. If the presence of .la-files is a necessity for the package there is not much to discuss, I suppose... Best regards -- Dago From dam at opencsw.org Thu Jan 14 22:45:30 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 14 Jan 2010 22:45:30 +0100 Subject: [csw-maintainers] GAR and isaexec: merging to $ISA subdirs doesn't work In-Reply-To: References: <4B44701E.1070100@opencsw.org> <080DF858-63AB-4867-9B3F-3ABA7A43E645@opencsw.org> <4B450899.5030501@opencsw.org> Message-ID: Hi Maciej, Am 14.01.2010 um 19:15 schrieb Maciej (Matchek) Blizinski: > On Wed, Jan 6, 2010 at 10:03 PM, Sebastian Kayser > wrote: >> Dagobert Michelsen wrote on 06.01.2010 22:36: >>> Am 06.01.2010 um 12:12 schrieb Sebastian Kayser: >>>> I just removed NO_ISAEXEC=1 from the mbuffer package to make it a >>>> regular 32-/64-bit package with isaexec as a wrapper. The resulting >>>> package looks just like before though. No isaexec symlink and the >>>> default $ISA in bin/. What's wrong? Running "gmake spotless >>>> package" >>>> leads to the same result. Current build description is checked >>>> in [1]. >>> >>> I guess you hit this bug: >>> >> > >>> >>> Please try "gmake repackage" unless it has been fixed. >> >> indeed, "gmake repackage" did the trick. Thank you. > > With this kind of a volatile problem, having a check would be good. > This is more or less what I was getting at with the post-prototype > pre-package check in GAR. If the problem happens regularly, we need > to at least detect the problem every time it happens. > > Dago, do you have an implementation idea from the top of your head? Yes, we take your manifest and make a unit test out of it doing a "gmake package" and see if the prototype contains the isaexec-stuff. Best regards -- Dago From dam at opencsw.org Thu Jan 14 22:47:13 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 14 Jan 2010 22:47:13 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> Message-ID: <4AFEFC3A-5330-47F4-9BDB-989959DC02AD@opencsw.org> Hi Phil, Am 14.01.2010 um 19:37 schrieb Philip Brown: > On Wednesday, January 13, 2010, Ben wrote > ... >> There are a few reasons I'd like to see this happen: >> >> 1. Packages that are rejected are typically rejected for common >> reasons. The more people the see these, the better we'll get over >> time as we stop making the same mistakes. > > I don't thnk this will help. > for one thing it's usually the new maintainers that make the mist > mistakes . they're not going to go back and read the archives. > > secondly the is enough maintainer email flying around as is. I would > guess most mantainers would choose NOT to be subscribed to such a > boring list But some would want to (like me). Best regards -- Dago From william at wbonnet.net Thu Jan 14 23:24:07 2010 From: william at wbonnet.net (William Bonnet) Date: Thu, 14 Jan 2010 23:24:07 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <4AFEFC3A-5330-47F4-9BDB-989959DC02AD@opencsw.org> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <4AFEFC3A-5330-47F4-9BDB-989959DC02AD@opencsw.org> Message-ID: <4B4F9987.3040908@wbonnet.net> Hi I do like this proposal, thus thumb up and +1. It would be a nice information source for maintainers especially if some of us produces a FAQ, and it would also be useful for people working on internal tools. > But some would want to (like me). Some would want to, even if most would not. This is a typical situation in which we should consider that the needs of the few should be taken in account regarding to the needs of the many. Because it could help the few to improve quality of what the provide to the many ;) Cheers, -- 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 maciej at opencsw.org Thu Jan 14 23:59:59 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 14 Jan 2010 22:59:59 +0000 Subject: [csw-maintainers] new mailing list? In-Reply-To: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Jan 14, 2010 at 12:36 AM, Ben Walton wrote: > 1. Packages that are rejected are typically rejected for common > ? reasons. ?The more people the see these, the better we'll get over > ? time as we stop making the same mistakes. and > 4. More visible maintainer activity. This is an easy way to keep an > eye on who's releasing what. This info can be gotten other ways of > course, but this is a more passive approach to seeing the same > info. Sharing the package submission e-mail with other maintainers was my first instinct, but I got rebuked for "spamming the maintainers mailing list". A separate list would be good, because it makes the spamming argument go away. > 2. History preservation. > 3. Team maintainership memory. Presently, if mails are private > between $release_manager and $maintainer, a $maintainer2 may not > know why a package is not being released. A list archive could > resolve this. This follows from #2. This might be quite important at some point. For example, who was the previous maintainer of package X? When were specific versions submitted and released? > 5. Openness. ?It pulls back the curtains a bit more on some of the > ? backend happenings. I predict this argument will be attacked by Phil, as he generally pushes everything towards closedness. But I'm for transparency, and I'm generally interested in all the works and updates of other packages. Most of the time the mailing list will be along the lines of "here's a new package", "ok", but I'm sure that every now and then there are in-depth technical discussions which might be interesting and educating for the rest of maintainers, especially the new ones. In short, +1. Maciej From skayser at opencsw.org Fri Jan 15 01:13:48 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 15 Jan 2010 01:13:48 +0100 Subject: [csw-maintainers] dbus In-Reply-To: <3BCBB553-3744-467A-8874-E9B99D961E43@opencsw.org> References: <4B4E296D.9030708@opencsw.org> <3BCBB553-3744-467A-8874-E9B99D961E43@opencsw.org> Message-ID: <4B4FB33C.70400@opencsw.org> Dagobert Michelsen wrote on 14.01.2010 22:23: > Am 13.01.2010 um 21:13 schrieb Sebastian Kayser: >> The NEWS link on www.opencsw.org/packages/ points to the >> Mantis >> news page for a package. Each maintainer should be able to populate >> this >> section for his packages already. That's where important news about >> that >> package could go. Nothing fancy, but better than it is right now. > > This is definitely a good idea. We also have > http://wiki.opencsw.org/packages > Too many places for so simple things... True. Even if there are multiple places, one central place which ties them all together would be helpful. packages.debian.org is IMHO a brilliant example. >> What I also really would like to see is a changelog.CSW shipped with >> each package which is somehow hooked into the release process. The >> NEWS >> section could then be automatically updated. I just had a >> troubleshooting session with someone who updated amavisd-new and from >> the package side it took me some time of distilling the important >> items >> in the GAR logs to see what had changed. That's where the NEWS would >> have been helpful also. > > The package news section should IMHO have one entry per release. > The ChangeLog is usually updated on every edit session which may > or may not result in a released package, so I'd propose a modified > approach here. The changelog.CSW I am referring to also contains one block of information per package release - with all the relevant changes that happened since the last package release (examples see [1,2,3]). I took the idea from Yann's recipes ([4,5]) which in turn were likely inspired by Debian's changelog.Debian file. This block of information could simply be turned into a Mantis package news entry upon release. The file itself is a bit of fiddling at first, but when you have a template/script that assists you, it's more easy to do. It would of course be easier without, but for the benefit of the users (and ourselves) it is IMHO worth it. My very, very primitive script approach which helps me to construct the changelog can be found at http://dpaste.com/145339/. Sebastian [1]http://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/xterm/trunk/files/changelog.CSW [2]http://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/watch/trunk/files/changelog.CSW [3]http://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/sudosh2/trunk/files/changelog.CSW [4]http://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/screen/trunk/files/changelog.CSW [5]http://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/openssl/trunk/files/changelog.CSW From hson at opencsw.org Fri Jan 15 03:35:32 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 15 Jan 2010 03:35:32 +0100 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <6383CAAE-CCA4-42A2-B9E6-538AE742A8CB@opencsw.org> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> <1262725258-sup-3515@ntdws12.chass.utoronto.ca> <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> <4B4F1424.2080109@opencsw.org> <6383CAAE-CCA4-42A2-B9E6-538AE742A8CB@opencsw.org> Message-ID: <4B4FD474.20507@opencsw.org> Dagobert Michelsen wrote: > Hi Roger, > > Am 14.01.2010 um 13:55 schrieb Roger H?kansson: >> Dagobert Michelsen wrote: >>> Hi Ben, >>> Am 05.01.2010 um 22:01 schrieb Ben Walton: >>>> Excerpts from Dagobert Michelsen's message of Tue Jan 05 15:56:02 >>>> -0500 2010: >>>> >>>>> be needed. Thoughts? >>>> 10 only. If the devs aren't interested in older platforms and you >>>> have no personal need, why go through the headache? >>> The question is: Do we want to release it and make separate releases >>> of packages for Solaris 8/9 vs. 10 which require it? >> >> libproxy is a requirement for some gnome-packages which would mean >> that we can't upgrade upgrade them without libproxy, and since some of >> those packages have dependencies on other packages which might get >> upgraded we would soon end up with a lot of Solaris8-packages which >> doesn't work. > > The alternatives would be: > (1) wait until the project switches to C++ (should be done pretty soon) > where the standard is supported by SOS11. > (2) Use GCC to compile libproxy. This would pull in gcc*rt, but would > work fine. > (3) Start with Solaris 10. By definition we start at Solaris 9, although > the download stats say almost all people use Solaris 10 by now > (see http://wiki.opencsw.org/suggestions mirror stats if you are > curious). And (4) Use my patches to build Solaris8-packages. There are only minor changes needed to get it working. The ones I've got are not that generic that they could be submitted upstream, but for our purposes they work. However, I can't get the Makefile working so packaging on both Solaris 8 and 10 works with the same Makefile (maybee not needed if only Solaris8-packages are to be released). But I can commit my changes so you can finish the work. From bwalton at opencsw.org Fri Jan 15 04:37:31 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 14 Jan 2010 22:37:31 -0500 Subject: [csw-maintainers] GAR: Preprocessing a postinstall file In-Reply-To: References: <1260585404-sup-1926@ntdws12.chass.utoronto.ca> Message-ID: <1263526608-sup-2225@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Mon Jan 11 11:48:13 -0500 2010: > I've found a side effect of this capability: The preprocessed scripts > are copied to /home/src on "gmake garchive". It holds for postgresql > and gitosis. I'm guessing that you've never done gmake garchive for > docbook. This should be corrected with r8008. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Fri Jan 15 10:22:22 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 15 Jan 2010 09:22:22 +0000 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: References: <1257540745-sup-2047@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Nov 6, 2009 at 11:43 PM, Maciej (Matchek) Blizinski wrote: > 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 Dago has recently asked me about restoring this symlink. It's certainly technically possible, but let me ask this question: This symlink, if I understand correctly, makes it impossible to have multiple MySQL databases installed at the same time, because /opt/csw/lib/mysql is "the MySQL database", which is something people were arguing against (notably, Phil). If the presence of MySQL libraries in /opt/csw/lib/mysql is necessary, why not install MySQL with to the common /opt/csw prefix instead? Either we have one default version of MySQL or we don't. If we don't, the symlink shall not exist. If we do, let's install one MySQL version into /opt/csw, and alternative versions (e.g. 4) to private prefixes. Thoughts? Maciej From maciej at opencsw.org Fri Jan 15 11:09:23 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 15 Jan 2010 10:09:23 +0000 Subject: [csw-maintainers] new mailing list? In-Reply-To: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Jan 14, 2010 at 12:36 AM, Ben Walton wrote: > Thoughts from others? To summarize, people who have expressed support for the idea are: 1. Ben 2. Dagobert 3. Maciej 4. Peter Bonivart 5. Peter Felecan 6. William 7. Sebastian People not supporting the idea: 1. Phil It's a classic example when somebody makes a proposal, the vast majority of maintainers support the idea, Phil says no, and the topic dies a quiet death. I would like this not to happen any more. If the 7:1 support is not enough to accept the proposal and go ahead, I would suggest that we exercise the board vote on the subject. Maciej From dam at opencsw.org Fri Jan 15 11:12:10 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 15 Jan 2010 11:12:10 +0100 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: References: <1257540745-sup-2047@ntdws12.chass.utoronto.ca> Message-ID: Hi Maciej, Am 15.01.2010 um 10:22 schrieb Maciej (Matchek) Blizinski: > On Fri, Nov 6, 2009 at 11:43 PM, Maciej (Matchek) Blizinski > wrote: >> 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 > > Dago has recently asked me about restoring this symlink. It's > certainly technically possible, but let me ask this question: > > This symlink, if I understand correctly, makes it impossible to have > multiple MySQL databases installed at the same time, because > /opt/csw/lib/mysql is "the MySQL database", which is something people > were arguing against (notably, Phil). No, this is just transitional for packages that have /opt/csw/lib/mysql as runpath. It will be discarded when all these packages have been redone. Otherwise all these packages will remain broken. Best regards -- Dago From maciej at opencsw.org Fri Jan 15 11:16:09 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 15 Jan 2010 10:16:09 +0000 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: References: <1257540745-sup-2047@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Jan 15, 2010 at 10:12 AM, Dagobert Michelsen wrote: >> This symlink, if I understand correctly, makes it impossible to have >> multiple MySQL databases installed at the same time, because >> /opt/csw/lib/mysql is "the MySQL database", which is something people >> were arguing against (notably, Phil). > > No, this is just transitional for packages that have > /opt/csw/lib/mysql as runpath. It will be discarded when > all these packages have been redone. Otherwise all these > packages will remain broken. Would it be hard to get a list of these packages? If it's something like 2 or 3 packages, it might better to update them instead of dancing with symlinks. From maciej at opencsw.org Fri Jan 15 12:00:20 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 15 Jan 2010 11:00:20 +0000 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: References: <1257540745-sup-2047@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Jan 15, 2010 at 10:16 AM, Maciej (Matchek) Blizinski wrote: > On Fri, Jan 15, 2010 at 10:12 AM, Dagobert Michelsen wrote: >>> This symlink, if I understand correctly, makes it impossible to have >>> multiple MySQL databases installed at the same time, because >>> /opt/csw/lib/mysql is "the MySQL database", which is something people >>> were arguing against (notably, Phil). >> >> No, this is just transitional for packages that have >> /opt/csw/lib/mysql as runpath. It will be discarded when >> all these packages have been redone. Otherwise all these >> packages will remain broken. > > Would it be hard to get a list of these packages? ?If it's something > like 2 or 3 packages, it might better to update them instead of > dancing with symlinks. Wasn't that hard. Find the dependencies of CSWmysql5rt, find the .so files inside them, run ldd. The result is that there are 2 packages which can't find the mysql library: CSWphp5mysql CSWpmdbdmysql Both are lacking active maintainers, but both are in GAR. How about rebuilding them instead? Is anyone up for it? From pfelecan at opencsw.org Fri Jan 15 12:02:44 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 15 Jan 2010 12:02:44 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <4B4F9987.3040908@wbonnet.net> (William Bonnet's message of "Thu, 14 Jan 2010 23:24:07 +0100") References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <4AFEFC3A-5330-47F4-9BDB-989959DC02AD@opencsw.org> <4B4F9987.3040908@wbonnet.net> Message-ID: William Bonnet writes: > This is a typical situation in which we should consider that the needs > of the few should be taken in account regarding to the needs of the > many. Because it could help the few to improve quality of what the > provide to the many ;) This situation is, as you have learned in elementary classes, similar to that which created the favorable conditions for the French Revolution or the English one, but that was something that James studied ages ago. -- Peter From james at opencsw.org Fri Jan 15 13:03:17 2010 From: james at opencsw.org (James Lee) Date: Fri, 15 Jan 2010 12:03:17 GMT Subject: [csw-maintainers] [csw-buildfarm] BO Buildfarm available again In-Reply-To: References: <4610F26C-0F72-4B02-AB82-72C14942A20D@opencsw.org> <20100111.15423100.2872566158@gyor.oxdrove.co.uk> <3863F96D-2DD6-441B-A1FE-3BB0575193A2@opencsw.org> <20100114.14052100.2348471893@gyor.oxdrove.co.uk> Message-ID: <20100115.12031700.1966285364@gyor.oxdrove.co.uk> On 14/01/10, 21:43:09, Dagobert Michelsen wrote regarding Re: [csw-maintainers] [csw-buildfarm] BO Buildfarm available again: > >>>> The T5220 is now split into two LDoms: One LDom with the existing > >>>> Solaris 10 > >>>> instance carrying all of the Sparc stuff which was already there > >>>> (now > >>>> restricted to 12 GB Ram and 20 Strands) and one LDom with > >>>> OpenSolaris > >>>> 06/09 Sparc still installing with 3 GB Ram and 8 Strands. > >>> > >>> Any reason for the restriction? > > > >> Because the machine doesn't have more resources ;-) > > > > Excuse me the machine does, prior to enhancement each virtual machine > > had 60% more available CPUs. > Is this a problem for you? Are you really using that many parallel > threads? Yes, but only at times. OpenOffice.org is the worst and uses all threads for long periods (when the disc isn't dying). Looking at my current terminal output tiff says "build8s --> 20 jobs" several times but not for long as the whole build only takes 6 mins for everything. Problem is the wrong word. Only recently has the build farm had enough disc space and I've built OOo on my own Pentium 2 333MHz, it took 4 days not 6 hours but did get there. So it's not a problem but more is better, 5 minutes is better than 6 minutes and it won't be too fast until it's quicker than pressing a key. > > Ah yes so LDOMs are restrictive. Sorry I've only read the marketing > > bumph which suggests resources are shared. > Yes, the machine is shared like "there are two OS instances on shared > hardware". The hardware is not shared, but partitioned. > > That is on the misleading > > side of truthful as there is no dynamic sharing of CPU and memory. > > Where load is sporadic as for build hard partitioning is a waste of a > > good machine. > I had the impression that the T5220 wasn't used that much at all. Most > of the time the load is beneath 3 or 4 Exactly the problem I mean by sporadic load. Something like a busy email server will have a continual somewhat random stream of messages and will have a meaningful average load. A build the machine is idle until it's used, then it's busy. The load average means little, being low means no one is working. You should only take the load average of when it's busy which sounds silly but is right because the load when no one is using the machine doesn't matter. This is where average isn't important, as with the average number of legs on people, or rating the fire brigade by the percentage of time they are actually putting out fires. If it's a natural consequence of using LDoms then so be it. It's a shame they can't dynamically share threads, as with unrestricted zones, because for very uneven loads it's what is needed. James. From dam at opencsw.org Fri Jan 15 13:33:19 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 15 Jan 2010 13:33:19 +0100 Subject: [csw-maintainers] [csw-buildfarm] BO Buildfarm available again In-Reply-To: <20100115.12031700.1966285364@gyor.oxdrove.co.uk> References: <4610F26C-0F72-4B02-AB82-72C14942A20D@opencsw.org> <20100111.15423100.2872566158@gyor.oxdrove.co.uk> <3863F96D-2DD6-441B-A1FE-3BB0575193A2@opencsw.org> <20100114.14052100.2348471893@gyor.oxdrove.co.uk> <20100115.12031700.1966285364@gyor.oxdrove.co.uk> Message-ID: <1184D760-8C65-494D-8DAA-7BB4F95C0EDE@opencsw.org> Hi James, Am 15.01.2010 um 13:03 schrieb James Lee: > On 14/01/10, 21:43:09, Dagobert Michelsen wrote > regarding >> Is this a problem for you? Are you really using that many parallel >> threads? > > Yes, but only at times. OpenOffice.org is the worst and uses all > threads for long periods (when the disc isn't dying). Looking at my > current terminal output tiff says "build8s --> 20 jobs" several times > but not for long as the whole build only takes 6 mins for everything. > > Problem is the wrong word. Only recently has the build farm had > enough > disc space I can now easily add more space as I didn't assign everything that has been installed. Just let me know if you plan big projects ;-) > and I've built OOo on my own Pentium 2 333MHz, it took 4 > days not 6 hours but did get there. So it's not a problem but more > is better, 5 minutes is better than 6 minutes and it won't be too fast > until it's quicker than pressing a key. I see. For now I can move the CPUs from the OSOL LDom to the Solaris LDom until it is more heavily used. >>> That is on the misleading >>> side of truthful as there is no dynamic sharing of CPU and memory. >>> Where load is sporadic as for build hard partitioning is a waste >>> of a >>> good machine. > >> I had the impression that the T5220 wasn't used that much at all. >> Most >> of the time the load is beneath 3 or 4 > > Exactly the problem I mean by sporadic load. Something like a busy > email > server will have a continual somewhat random stream of messages and > will > have a meaningful average load. A build the machine is idle until > it's > used, then it's busy. The load average means little, being low > means no > one is working. You should only take the load average of when it's > busy > which sounds silly but is right because the load when no one is > using the > machine doesn't matter. This is where average isn't important, as > with > the average number of legs on people, or rating the fire brigade by > the > percentage of time they are actually putting out fires. > > If it's a natural consequence of using LDoms then so be it. It's a > shame they can't dynamically share threads, as with unrestricted > zones, > because for very uneven loads it's what is needed. I can move CPUs around on request if that helps. If it really shows to be a problem I will add another machine, but first I'd like to try it with this configuration. Best regards -- Dago From dam at opencsw.org Fri Jan 15 13:36:58 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 15 Jan 2010 13:36:58 +0100 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <4B4FD474.20507@opencsw.org> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> <1262725258-sup-3515@ntdws12.chass.utoronto.ca> <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> <4B4F1424.2080109@opencsw.org> <6383CAAE-CCA4-42A2-B9E6-538AE742A8CB@opencsw.org> <4B4FD474.20507@opencsw.org> Message-ID: <9B5249C5-C71A-4324-BC63-4D279E28461C@opencsw.org> Hi Roger, Am 15.01.2010 um 03:35 schrieb Roger H?kansson: > Dagobert Michelsen wrote: >> Hi Roger, >> Am 14.01.2010 um 13:55 schrieb Roger H?kansson: >>> Dagobert Michelsen wrote: >>>> Hi Ben, >>>> Am 05.01.2010 um 22:01 schrieb Ben Walton: >>>>> Excerpts from Dagobert Michelsen's message of Tue Jan 05 >>>>> 15:56:02 -0500 2010: >>>>> >>>>>> be needed. Thoughts? >>>>> 10 only. If the devs aren't interested in older platforms and you >>>>> have no personal need, why go through the headache? >>>> The question is: Do we want to release it and make separate >>>> releases >>>> of packages for Solaris 8/9 vs. 10 which require it? >>> >>> libproxy is a requirement for some gnome-packages which would mean >>> that we can't upgrade upgrade them without libproxy, and since >>> some of those packages have dependencies on other packages which >>> might get upgraded we would soon end up with a lot of Solaris8- >>> packages which doesn't work. >> The alternatives would be: >> (1) wait until the project switches to C++ (should be done pretty >> soon) >> where the standard is supported by SOS11. >> (2) Use GCC to compile libproxy. This would pull in gcc*rt, but would >> work fine. >> (3) Start with Solaris 10. By definition we start at Solaris 9, >> although >> the download stats say almost all people use Solaris 10 by now >> (see http://wiki.opencsw.org/suggestions mirror stats if you are >> curious). > > And (4) Use my patches to build Solaris8-packages. > There are only minor changes needed to get it working. The ones I've > got are not that generic that they could be submitted upstream, but > for our purposes they work. > However, I can't get the Makefile working so packaging on both > Solaris 8 and 10 works with the same Makefile (maybee not needed if > only Solaris8-packages are to be released). > But I can commit my changes so you can finish the work. Great, please do! I had the impression this was harder. Just take it over and release at will. Best regards -- Dago From bwalton at opencsw.org Fri Jan 15 14:42:35 2010 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 15 Jan 2010 08:42:35 -0500 Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> Message-ID: <1263562770-sup-2674@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Fri Jan 15 05:09:23 -0500 2010: > dies a quiet death. I would like this not to happen any more. If the > 7:1 support is not enough to accept the proposal and go ahead, I would > suggest that we exercise the board vote on the subject. While we should exercise this mechanism if required, I don't see that it is. The support has been almost unanimous. Given that there is only a single registered 'nay' vote and that procedural changes consist of _only_ sending the mail to a list instead of an individual, I'd like to ask Ihsan to create the list, with myself, Dago and Phil as members to start. I suspect some of the others that voiced support are ok with being on the list too, but I won't speak for them. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pfelecan at opencsw.org Fri Jan 15 14:45:10 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 15 Jan 2010 14:45:10 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <1263562770-sup-2674@ntdws12.chass.utoronto.ca> (Ben Walton's message of "Fri, 15 Jan 2010 08:42:35 -0500") References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> Message-ID: Ben Walton writes: > I suspect some of the others that voiced support are ok with being on > the list too, but I won't speak for them. I would like to be subscribed to this list. TIA -- Peter From maciej at opencsw.org Fri Jan 15 14:51:16 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 15 Jan 2010 13:51:16 +0000 Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Jan 15, 2010 at 1:45 PM, Peter FELECAN wrote: > Ben Walton writes: > >> I suspect some of the others that voiced support are ok with being on >> the list too, but I won't speak for them. > > I would like to be subscribed to this list. TIA Me too, please. From bonivart at opencsw.org Fri Jan 15 14:52:50 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 15 Jan 2010 14:52:50 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> Message-ID: <625385e31001150552x6d6b926bk949703867818e0e7@mail.gmail.com> On Fri, Jan 15, 2010 at 2:51 PM, Maciej (Matchek) Blizinski wrote: > On Fri, Jan 15, 2010 at 1:45 PM, Peter FELECAN wrote: >> Ben Walton writes: >> >>> I suspect some of the others that voiced support are ok with being on >>> the list too, but I won't speak for them. >> >> I would like to be subscribed to this list. TIA > > Me too, please. And me. -- /peter From dam at opencsw.org Fri Jan 15 16:03:52 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 15 Jan 2010 16:03:52 +0100 Subject: [csw-maintainers] Missing dependencies in X11 packages Message-ID: Hi William, I got some bug reports about missing dependencies in X11 packages: http://www.opencsw.org/mantis/view.php?id=4155 http://www.opencsw.org/mantis/view.php?id=4136 http://www.opencsw.org/mantis/view.php?id=4135 Could you please make sure that you don't have these issues when releasing the brand-new X11? Best regards -- Dago From hson at opencsw.org Fri Jan 15 18:08:30 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 15 Jan 2010 18:08:30 +0100 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <9B5249C5-C71A-4324-BC63-4D279E28461C@opencsw.org> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> <1262725258-sup-3515@ntdws12.chass.utoronto.ca> <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> <4B4F1424.2080109@opencsw.org> <6383CAAE-CCA4-42A2-B9E6-538AE742A8CB@opencsw.org> <4B4FD474.20507@opencsw.org> <9B5249C5-C71A-4324-BC63-4D279E28461C@opencsw.org> Message-ID: <4B50A10E.7030208@opencsw.org> Dagobert Michelsen wrote: > Hi Roger, > > Am 15.01.2010 um 03:35 schrieb Roger H?kansson: > >> Dagobert Michelsen wrote: >>> Hi Roger, >>> Am 14.01.2010 um 13:55 schrieb Roger H?kansson: >>>> Dagobert Michelsen wrote: >>>>> Hi Ben, >>>>> Am 05.01.2010 um 22:01 schrieb Ben Walton: >>>>>> Excerpts from Dagobert Michelsen's message of Tue Jan 05 15:56:02 >>>>>> -0500 2010: >>>>>> >>>>>>> be needed. Thoughts? >>>>>> 10 only. If the devs aren't interested in older platforms and you >>>>>> have no personal need, why go through the headache? >>>>> The question is: Do we want to release it and make separate releases >>>>> of packages for Solaris 8/9 vs. 10 which require it? >>>> >>>> libproxy is a requirement for some gnome-packages which would mean >>>> that we can't upgrade upgrade them without libproxy, and since some >>>> of those packages have dependencies on other packages which might >>>> get upgraded we would soon end up with a lot of Solaris8-packages >>>> which doesn't work. >>> The alternatives would be: >>> (1) wait until the project switches to C++ (should be done pretty soon) >>> where the standard is supported by SOS11. >>> (2) Use GCC to compile libproxy. This would pull in gcc*rt, but would >>> work fine. >>> (3) Start with Solaris 10. By definition we start at Solaris 9, although >>> the download stats say almost all people use Solaris 10 by now >>> (see http://wiki.opencsw.org/suggestions mirror stats if you are >>> curious). >> >> And (4) Use my patches to build Solaris8-packages. >> There are only minor changes needed to get it working. The ones I've >> got are not that generic that they could be submitted upstream, but >> for our purposes they work. >> However, I can't get the Makefile working so packaging on both Solaris >> 8 and 10 works with the same Makefile (maybee not needed if only >> Solaris8-packages are to be released). >> But I can commit my changes so you can finish the work. > > Great, please do! I had the impression this was harder. Just take > it over and release at will. I committed it last night. Do you have any example on how to modulate PATCHFILES depending not only on arch but also on OS? It's not required to build Solaris 8 packages, but for completeness if someone checks out the code and tries to build on Solaris 10 it will fail right now. I've pushed the packages to newpkgs From dam at opencsw.org Fri Jan 15 18:24:10 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 15 Jan 2010 18:24:10 +0100 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <4B50A10E.7030208@opencsw.org> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> <1262725258-sup-3515@ntdws12.chass.utoronto.ca> <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> <4B4F1424.2080109@opencsw.org> <6383CAAE-CCA4-42A2-B9E6-538AE742A8CB@opencsw.org> <4B4FD474.20507@opencsw.org> <9B5249C5-C71A-4324-BC63-4D279E28461C@opencsw.org> <4B50A10E.7030208@opencsw.org> Message-ID: <5BFDE348-4B8F-45EE-A643-9CB3427CE08E@opencsw.org> Hi Roger, Am 15.01.2010 um 18:08 schrieb Roger H?kansson: > Do you have any example on how to modulate PATCHFILES depending not > only on arch but also on OS? > It's not required to build Solaris 8 packages, but for completeness > if someone checks out the code and tries to build on Solaris 10 it > will fail right now. This is not straightforward as the whole selection is per-modulation and the Solaris release is something you usually don't modulate over. You could have platform-specific build recipes like in libmpeg2/trunk/Makefile. The trick is to set PATCHFILES to the patches to be applied to the current platform and ALLFILES_PATCHFILES to all patches to be add to "checksums". Could you please have a look first? Let me know if you have any troubles. Best regards -- Dago From hson at opencsw.org Fri Jan 15 21:21:45 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 15 Jan 2010 21:21:45 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <625385e31001150552x6d6b926bk949703867818e0e7@mail.gmail.com> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <625385e31001150552x6d6b926bk949703867818e0e7@mail.gmail.com> Message-ID: <4B50CE59.9030608@opencsw.org> Peter Bonivart wrote: > On Fri, Jan 15, 2010 at 2:51 PM, Maciej (Matchek) Blizinski > wrote: >> On Fri, Jan 15, 2010 at 1:45 PM, Peter FELECAN wrote: >>> Ben Walton writes: >>> >>>> I suspect some of the others that voiced support are ok with being on >>>> the list too, but I won't speak for them. >>> I would like to be subscribed to this list. TIA >> Me too, please. > > And me. > And me From william at wbonnet.net Sat Jan 16 19:43:11 2010 From: william at wbonnet.net (William Bonnet) Date: Sat, 16 Jan 2010 19:43:11 +0100 Subject: [csw-maintainers] Missing dependencies in X11 packages In-Reply-To: References: Message-ID: <4B5208BF.7050702@wbonnet.net> Hi Dago > Hi William, > > I got some bug reports about missing dependencies in X11 packages: > > http://www.opencsw.org/mantis/view.php?id=4155 > http://www.opencsw.org/mantis/view.php?id=4136 > http://www.opencsw.org/mantis/view.php?id=4135 > > Could you please make sure that you don't have these issues when > releasing the brand-new X11? Sure, i'll process these bugs. 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 trygvis at opencsw.org Sun Jan 17 16:09:19 2010 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Sun, 17 Jan 2010 16:09:19 +0100 Subject: [csw-maintainers] pcb-20081128 in testing/ Message-ID: <4B53281F.8060000@opencsw.org> Hi I've finally managed to get a working package of pcb with some pre/post install hacks. I also had to include a couple of patches that was needed when building larger boards with large netlists: http://git.gpleda.org/?p=pcb.git;a=commit;h=d053b4e41da10fd033429cb4b88c6e3b52769eb7 http://git.gpleda.org/?p=pcb.git;a=commit;h=40347a55413e152c7b5fc2bac074c75c7687b766 -- Trygve From dam at opencsw.org Sun Jan 17 17:36:23 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 17 Jan 2010 17:36:23 +0100 Subject: [csw-maintainers] Docbook test failing Message-ID: Hi, I am currently rebuilding mutt and the autoconf-test for docbook doesn't detect the docbook stylesheet, although it is installed. > build8s% pkginfo | grep -i docbook > application CSWdocbookdsssl docbookdsssl - Norman Walsh's > modular stylesheets for DocBook > application CSWdocbookdtds docbookdtds - SGML and XML document > type definitions for DocBook. > application CSWdocbookxsl docbookxsl - Norman Walsh's XSL > stylesheets for DocBook XML > application CSWdocbookxsldoc docbookxsldoc - Documentation for > the Docbook XSL stylesheets The test looks like this: > AC_MSG_CHECKING([for openjade docbook stylesheets]) > dslosfile=`ospcat --public-id="-//Norman Walsh//DOCUMENT DocBook > Print Stylesheet//EN"` > DSLROOT=`echo $dslosfile | sed -n -e "s/.*SOIBASE='\(@<:@^'@:>@*\) > \/catalog'.*/\1/p"` > # ospcat may spit out an absolute path without an SOIBASE > if test -z "$DSLROOT" > then > DSLROOT=`echo $dslosfile | sed -e 's|\(.*\)/print/ > docbook.dsl|\1|'` > fi > if test -f $DSLROOT/print/docbook.dsl > then > AC_MSG_RESULT([in $DSLROOT]) > have_openjade="yes" > else > AC_MSG_RESULT([not found: PDF documentation will not be built.]) > fi But the result of the first line is empty: > build8s% ospcat --public-id="-//Norman Walsh//DOCUMENT DocBook Print > Stylesheet//EN" Any idea why this is failing? Best regards -- Dago From skayser at opencsw.org Sun Jan 17 18:09:46 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 17 Jan 2010 18:09:46 +0100 Subject: [csw-maintainers] GAR: Least invasive way to pre-pend extra lib directories to LDFLAGS/LD_OPTIONS? Message-ID: <4B53445A.2010307@opencsw.org> Hi, a general GAR question. I know about EXTRA_LIBS which _appends_ the given directories to the default LDFLAGS and LD_OPTIONS while also considering a possible $ISALIST for each of these directories. Is there any variable which does the same, but pre-pends the given directories? For test purposes, I would like to have a binary with /opt/csw/bdb47/lib as the first component in the runpath (but i would like to avoid fiddling with LDFLAGS and LD_OPTIONS manually so to preserve as much of the defaults as possible). Sebastian From bwalton at opencsw.org Sun Jan 17 18:44:04 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 17 Jan 2010 12:44:04 -0500 Subject: [csw-maintainers] Docbook test failing In-Reply-To: References: Message-ID: <1263749957-sup-7540@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Sun Jan 17 11:36:23 -0500 2010: > > AC_MSG_CHECKING([for openjade docbook stylesheets]) > > dslosfile=`ospcat --public-id="-//Norman Walsh//DOCUMENT DocBook > > Print Stylesheet//EN"` I truss'd this call and it's failing because it doesn't look for the catalog files corectly. /1: open("catalog", O_RDONLY) Err#2 ENOENT /1: open("./catalog", O_RDONLY) Err#2 ENOENT /1: open("/opt/csw/share/sgml/catalog", O_RDONLY) Err#2 ENOENT /1: open("/opt/csw/share/xml/catalog", O_RDONLY) Err#2 ENOENT /1: open("/opt/csw/etc/sgml/catalog", O_RDONLY) Err#2 ENOENT It should be looking in /etc/opt/csw/sgml/catalog. Looks like a bug in CSWopensp. I thought this mess was in the past, but I must have overlooked something. I can work with Peter F to remedy this. Additionally, I could symlink /opt/csw/etc/{xml,sgml} -> /etc/opt/csw/{xml,sgml}, which would hide things like this. I'm not sure if hiding them is good though. 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 maciej at opencsw.org Sun Jan 17 19:57:00 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 17 Jan 2010 18:57:00 +0000 Subject: [csw-maintainers] GAR: Least invasive way to pre-pend extra lib directories to LDFLAGS/LD_OPTIONS? In-Reply-To: <4B53445A.2010307@opencsw.org> References: <4B53445A.2010307@opencsw.org> Message-ID: On Sun, Jan 17, 2010 at 5:09 PM, Sebastian Kayser wrote: > Hi, > > a general GAR question. I know about EXTRA_LIBS which _appends_ the > given directories to the default LDFLAGS and LD_OPTIONS while also > considering a possible $ISALIST for each of these directories. Is there > any variable which does the same, but pre-pends the given directories? > > For test purposes, I would like to have a binary with /opt/csw/bdb47/lib > as the first component in the runpath (but i would like to avoid > fiddling with LDFLAGS and LD_OPTIONS manually so to preserve as much of > the defaults as possible). There's a more high-level way to add paths to the runtime linker, it's documented here: http://sourceforge.net/apps/trac/gar/wiki/RuntimeLinkerPathes ...but it doesn't say anything about the resulting path order. From dam at opencsw.org Sun Jan 17 21:14:39 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 17 Jan 2010 21:14:39 +0100 Subject: [csw-maintainers] GAR: Least invasive way to pre-pend extra lib directories to LDFLAGS/LD_OPTIONS? In-Reply-To: <4B53445A.2010307@opencsw.org> References: <4B53445A.2010307@opencsw.org> Message-ID: <61493F41-495D-440F-A431-76F824C2704A@opencsw.org> Hi Sebastian, Am 17.01.2010 um 18:09 schrieb Sebastian Kayser: > a general GAR question. I know about EXTRA_LIBS which _appends_ the > given directories to the default LDFLAGS and LD_OPTIONS while also > considering a possible $ISALIST for each of these directories. Is > there > any variable which does the same, but pre-pends the given directories? Not yet. > For test purposes, I would like to have a binary with /opt/csw/bdb47/ > lib > as the first component in the runpath (but i would like to avoid > fiddling with LDFLAGS and LD_OPTIONS manually so to preserve as much > of > the defaults as possible). I have the feeling that it is generally a good idea to prepend manually set directories to the linker list as the contained libraries may be only there (which would cause no damage) or the would be more specialized like the general one (what is failing right now). That's why I think it would be good to change the order of directory pathes as linker parameters. As this change is somewhat invasive I would like some feedback of some senior packages (read: all of you :-) Best regards -- Dago From dam at opencsw.org Sun Jan 17 21:30:56 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 17 Jan 2010 21:30:56 +0100 Subject: [csw-maintainers] Determining the architecture of a binary In-Reply-To: References: Message-ID: Hi Maciej, Am 13.01.2010 um 11:37 schrieb Maciej (Matchek) Blizinski: > We don't have our own, up-to-date file (or gfile), do we? There doesn't seem to be a "GNU File" command, but I have packaged the latest one from http://www.darwinsys.com/file/ which seems pretty good in testing: file-5.03,REV=2010.01.17-SunOS5.8-sparc-CSW.pkg.gz file-5.03,REV=2010.01.17-SunOS5.8-i386-CSW.pkg.gz Best regards -- Dago From william at wbonnet.net Sun Jan 17 22:28:45 2010 From: william at wbonnet.net (William Bonnet) Date: Sun, 17 Jan 2010 22:28:45 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <1263562770-sup-2674@ntdws12.chass.utoronto.ca> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> Message-ID: <4B53810D.2010706@wbonnet.net> Hi > Given that there is only a single registered 'nay' vote and that > procedural changes consist of _only_ sending the mail to a list > instead of an individual, I'd like to ask Ihsan to create the list, > with myself, Dago and Phil as members to start. > More generally, i would like to suggest that each of our process that needs email communication, should be using "functional" email addresses rather than "personal" (or "named") addresses. Whether the functional address is a mailing list or not. Taking apart some difference of approach :) this would in any cases help us to improve process, and will handle easily cases like holidays, illness or whatever 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 Sun Jan 17 22:32:41 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 17 Jan 2010 16:32:41 -0500 Subject: [csw-maintainers] new mailing list? In-Reply-To: <4B53810D.2010706@wbonnet.net> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B53810D.2010706@wbonnet.net> Message-ID: <1263763930-sup-5284@ntdws12.chass.utoronto.ca> Excerpts from William Bonnet's message of Sun Jan 17 16:28:45 -0500 2010: Hi William, > More generally, i would like to suggest that each of our process > that needs email communication, should be using "functional" email > addresses rather than "personal" (or "named") addresses. Whether the > functional address is a mailing list or not. This makes a great deal of sense. 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 Sun Jan 17 22:42:41 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 17 Jan 2010 22:42:41 +0100 Subject: [csw-maintainers] Ganglia for sparcv9 In-Reply-To: <4B48FA2F.2020806@opencsw.org> References: <4AE87999.6020401@opencsw.org> <777D637C-111E-4F5B-8562-501B9F42351E@opencsw.org> <4B48FA2F.2020806@opencsw.org> Message-ID: <4B538451.7030002@opencsw.org> Am 09.01.10 22:50, schrieb Ihsan Dogan: >> Ihsan: For rrdtool I just opened a case for 64 bit libs: >> > > I'll have a look in that tomorrow. I'm running into a problem with Pango. We discussed this issue here before, but I don't remember how it ended. http://pastebin.ca/1755178 Any ideas? Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Sun Jan 17 22:57:27 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 17 Jan 2010 22:57:27 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <1263562770-sup-2674@ntdws12.chass.utoronto.ca> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> Message-ID: <4B5387C7.4010801@opencsw.org> Am 15.01.10 14:42, schrieb Ben Walton: >> dies a quiet death. I would like this not to happen any more. If the >> 7:1 support is not enough to accept the proposal and go ahead, I would >> suggest that we exercise the board vote on the subject. > > While we should exercise this mechanism if required, I don't see that > it is. The support has been almost unanimous. > > Given that there is only a single registered 'nay' vote and that > procedural changes consist of _only_ sending the mail to a list > instead of an individual, I'd like to ask Ihsan to create the list, > with myself, Dago and Phil as members to start. Ok, then I'm going to create a new list. Is internal at lists.opencsw.org fine? Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From trygvis at opencsw.org Sun Jan 17 23:01:08 2010 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Sun, 17 Jan 2010 23:01:08 +0100 Subject: [csw-maintainers] gtkwave-3.2.3 in testing/ Message-ID: <4B5388A4.9070402@opencsw.org> Hi Please test, in particular on SPARC. -- Trygve From trygvis at opencsw.org Sun Jan 17 23:03:01 2010 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Sun, 17 Jan 2010 23:03:01 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <4B5387C7.4010801@opencsw.org> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B5387C7.4010801@opencsw.org> Message-ID: <4B538915.6060209@opencsw.org> Ihsan Dogan wrote: > Am 15.01.10 14:42, schrieb Ben Walton: > >>> dies a quiet death. I would like this not to happen any more. If the >>> 7:1 support is not enough to accept the proposal and go ahead, I would >>> suggest that we exercise the board vote on the subject. >> While we should exercise this mechanism if required, I don't see that >> it is. The support has been almost unanimous. >> >> Given that there is only a single registered 'nay' vote and that >> procedural changes consist of _only_ sending the mail to a list >> instead of an individual, I'd like to ask Ihsan to create the list, >> with myself, Dago and Phil as members to start. > > Ok, then I'm going to create a new list. > Is internal at lists.opencsw.org fine? As the list is for new packages and we have a concept called "newpkgs" I think the list should be named "newpkgs" as it specifically is for new packages. -- Trygve From bwalton at opencsw.org Sun Jan 17 23:18:58 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 17 Jan 2010 17:18:58 -0500 Subject: [csw-maintainers] new mailing list? In-Reply-To: <4B538915.6060209@opencsw.org> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B5387C7.4010801@opencsw.org> <4B538915.6060209@opencsw.org> Message-ID: <1263766699-sup-2733@ntdws12.chass.utoronto.ca> Excerpts from Trygve Laugst?l's message of Sun Jan 17 17:03:01 -0500 2010: > As the list is for new packages and we have a concept called > "newpkgs" I think the list should be named "newpkgs" as it > specifically is for new packages. I had been things releases, but I prefer newpkgs too. +1 from me. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bwalton at opencsw.org Sun Jan 17 23:49:28 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 17 Jan 2010 17:49:28 -0500 Subject: [csw-maintainers] Docbook test failing In-Reply-To: <1263749957-sup-7540@ntdws12.chass.utoronto.ca> References: <1263749957-sup-7540@ntdws12.chass.utoronto.ca> Message-ID: <1263768279-sup-4850@ntdws12.chass.utoronto.ca> Excerpts from Ben Walton's message of Sun Jan 17 12:44:04 -0500 2010: > It should be looking in /etc/opt/csw/sgml/catalog. Looks like a bug > in CSWopensp. I thought this mess was in the past, but I must have Doh! It's not in GAR... I've opened a bug on this (the breakage, not the lack of GAR recipe). -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 hson at opencsw.org Mon Jan 18 02:38:45 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Mon, 18 Jan 2010 02:38:45 +0100 Subject: [csw-maintainers] Ganglia for sparcv9 In-Reply-To: <4B538451.7030002@opencsw.org> References: <4AE87999.6020401@opencsw.org> <777D637C-111E-4F5B-8562-501B9F42351E@opencsw.org> <4B48FA2F.2020806@opencsw.org> <4B538451.7030002@opencsw.org> Message-ID: <4B53BBA5.6010607@opencsw.org> Ihsan Dogan wrote: > Am 09.01.10 22:50, schrieb Ihsan Dogan: > >>> Ihsan: For rrdtool I just opened a case for 64 bit libs: >>> >> I'll have a look in that tomorrow. > > I'm running into a problem with Pango. We discussed this issue here > before, but I don't remember how it ended. > > http://pastebin.ca/1755178 > The lib does contain what you need, but I'm pretty sure that if you check config.log you will find that every test have failed due to: Undefined first referenced symbol in file XSolarisIASetProcessInfo /usr/openwin/lib/libX11.so.4 The problem is related to what I wrote last week regarding libcairo. Until the libcairo-problem is fixed, you might be able to get around it by adding this to your Makefile EXTRA_SOS_LD_FLAGS = -L$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) CONFIGURE_ARGS += --x-includes=$(prefix)/X11/include CONFIGURE_ARGS += --x-libraries=$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) Using those changes I'm able to build rrdtool using what's in GAR. However, until libcairo is fixed, you probably also need to add EXTRA_SOS_LD_OPTIONS = -R$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) From dam at opencsw.org Mon Jan 18 08:13:37 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 18 Jan 2010 08:13:37 +0100 Subject: [csw-maintainers] Ganglia for sparcv9 In-Reply-To: <4B53BBA5.6010607@opencsw.org> References: <4AE87999.6020401@opencsw.org> <777D637C-111E-4F5B-8562-501B9F42351E@opencsw.org> <4B48FA2F.2020806@opencsw.org> <4B538451.7030002@opencsw.org> <4B53BBA5.6010607@opencsw.org> Message-ID: <0F5D65D6-DCCC-4AC0-A836-7EFFA2AD25F2@opencsw.org> Hi Roger, Am 18.01.2010 um 02:38 schrieb Roger H?kansson: > Ihsan Dogan wrote: >> Am 09.01.10 22:50, schrieb Ihsan Dogan: >>>> Ihsan: For rrdtool I just opened a case for 64 bit libs: >>>> >>> I'll have a look in that tomorrow. >> I'm running into a problem with Pango. We discussed this issue here >> before, but I don't remember how it ended. >> http://pastebin.ca/1755178 > > The lib does contain what you need, but I'm pretty sure that if you > check config.log you will find that every test have failed due to: > > Undefined first referenced > symbol in file > XSolarisIASetProcessInfo /usr/openwin/lib/libX11.so.4 > > The problem is related to what I wrote last week regarding libcairo. > > Until the libcairo-problem is fixed, you might be able to get around > it > by adding this to your Makefile > > EXTRA_SOS_LD_FLAGS = -L$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) > CONFIGURE_ARGS += --x-includes=$(prefix)/X11/include > CONFIGURE_ARGS += --x-libraries=$(abspath $(prefix)/X11/lib/$ > (MM_LIBDIR)) > > Using those changes I'm able to build rrdtool using what's in GAR. > > However, until libcairo is fixed, you probably also need to add > EXTRA_SOS_LD_OPTIONS = -R$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) I see you have already done some work on it. Does it work? Please take it over at will. Best regards -- Dago From dam at opencsw.org Mon Jan 18 08:38:10 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 18 Jan 2010 08:38:10 +0100 Subject: [csw-maintainers] Anybody there with too much spare time? Message-ID: <9A5C2A02-9E13-41DC-ADF5-C8BF37E0205F@opencsw.org> Hi folks, grok this: 3D-Visualization of GIT activity, the result is... impressive... Examples videos are on the page. Best regards -- Dago From maciej at opencsw.org Mon Jan 18 08:58:30 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 18 Jan 2010 07:58:30 +0000 Subject: [csw-maintainers] new mailing list? In-Reply-To: <1263766699-sup-2733@ntdws12.chass.utoronto.ca> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B5387C7.4010801@opencsw.org> <4B538915.6060209@opencsw.org> <1263766699-sup-2733@ntdws12.chass.utoronto.ca> Message-ID: On Sun, Jan 17, 2010 at 10:18 PM, Ben Walton wrote: > Excerpts from Trygve Laugst?l's message of Sun Jan 17 17:03:01 -0500 2010: > >> As the list is for new packages and we have a concept called >> "newpkgs" I think the list should be named "newpkgs" as it >> specifically is for new packages. > > I had been things releases, but I prefer newpkgs too. ?+1 from me. Yes, makes sense. We've been using the keyword newpkgs in the past, let's stick to it. From dam at opencsw.org Mon Jan 18 09:01:05 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 18 Jan 2010 09:01:05 +0100 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <5BFDE348-4B8F-45EE-A643-9CB3427CE08E@opencsw.org> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> <1262725258-sup-3515@ntdws12.chass.utoronto.ca> <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> <4B4F1424.2080109@opencsw.org> <6383CAAE-CCA4-42A2-B9E6-538AE742A8CB@opencsw.org> <4B4FD474.20507@opencsw.org> <9B5249C5-C71A-4324-BC63-4D279E28461C@opencsw.org> <4B50A10E.7030208@opencsw.org> <5BFDE348-4B8F-45EE-A643-9CB3427CE08E@opencsw.org> Message-ID: <53446B3F-A718-4372-9DBF-8EB9D70BA020@opencsw.org> Hi Roger, could you please release libproxy to current/ at will so I can rebuild neon against it? Best regards -- Dago From maciej at opencsw.org Mon Jan 18 10:10:45 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 18 Jan 2010 09:10:45 +0000 Subject: [csw-maintainers] Determining the architecture of a binary In-Reply-To: References: Message-ID: On Sun, Jan 17, 2010 at 8:30 PM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 13.01.2010 um 11:37 schrieb Maciej (Matchek) Blizinski: >> >> We don't have our own, up-to-date file (or gfile), do we? > > There doesn't seem to be a "GNU File" command, but I have packaged > the latest one from > ?http://www.darwinsys.com/file/ > which seems pretty good in testing: > > file-5.03,REV=2010.01.17-SunOS5.8-sparc-CSW.pkg.gz > file-5.03,REV=2010.01.17-SunOS5.8-i386-CSW.pkg.gz Cool, that's the one. Thanks! I won't be relying on it for the architecture detection, though. I've found hachoir, a Python library which parses files and returns a data structure with all the data, similar to elfdump, but I won't have to parse the text output. From glaw at opencsw.org Mon Jan 18 10:23:24 2010 From: glaw at opencsw.org (Gary Law) Date: Mon, 18 Jan 2010 09:23:24 +0000 Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> Message-ID: add me and +1 for calling it newpkgs -- glaw at opencsw.org From hson at opencsw.org Mon Jan 18 10:38:26 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Mon, 18 Jan 2010 10:38:26 +0100 Subject: [csw-maintainers] libproxy in testing In-Reply-To: <53446B3F-A718-4372-9DBF-8EB9D70BA020@opencsw.org> References: <6ED3B2B2-1AD8-43E7-AE54-D661F46A6E5A@opencsw.org> <1262725258-sup-3515@ntdws12.chass.utoronto.ca> <2235DCA6-BD67-45B6-895D-30E56E47C5F2@opencsw.org> <4B4F1424.2080109@opencsw.org> <6383CAAE-CCA4-42A2-B9E6-538AE742A8CB@opencsw.org> <4B4FD474.20507@opencsw.org> <9B5249C5-C71A-4324-BC63-4D279E28461C@opencsw.org> <4B50A10E.7030208@opencsw.org> <5BFDE348-4B8F-45EE-A643-9CB3427CE08E@opencsw.org> <53446B3F-A718-4372-9DBF-8EB9D70BA020@opencsw.org> Message-ID: <4B542C12.3050705@opencsw.org> Dagobert Michelsen wrote: > Hi Roger, > > could you please release libproxy to current/ at will so I can > rebuild neon against it? It's already in newpkgs pending release, but I've pushed the latest build today. From maciej at opencsw.org Mon Jan 18 14:26:31 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 18 Jan 2010 13:26:31 +0000 Subject: [csw-maintainers] file-5.03 Message-ID: On Sun, Jan 17, 2010 at 8:30 PM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 13.01.2010 um 11:37 schrieb Maciej (Matchek) Blizinski: >> >> We don't have our own, up-to-date file (or gfile), do we? > > There doesn't seem to be a "GNU File" command, but I have packaged > the latest one from > ?http://www.darwinsys.com/file/ > which seems pretty good in testing: > > file-5.03,REV=2010.01.17-SunOS5.8-sparc-CSW.pkg.gz > file-5.03,REV=2010.01.17-SunOS5.8-i386-CSW.pkg.gz checkpkg doesn't work with it. It exports two colons instead of one in the output, and checkpkg doesn't detect a gzip file any more. The fix: Index: bin/checkpkg =================================================================== --- bin/checkpkg (revision 8048) +++ bin/checkpkg (working copy) @@ -90,7 +90,9 @@ set_variables_for_individual_package_check() { f=$1 - file $f |sed 's/^.*://' |grep gzip >/dev/null + file $f \ + | sed 's/^[^:]*://' \ + | grep gzip >/dev/null if [ $? -eq 0 ] ; then TMPARCHIVE=$CHECKPKG_TMPDIR/`basename $f` if [[ -f $TMPARCHIVE ]] ; then Committed in r8075. From hson at opencsw.org Mon Jan 18 14:41:46 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Mon, 18 Jan 2010 14:41:46 +0100 Subject: [csw-maintainers] libcairo in /testing (was Re: Ganglia for sparcv9) In-Reply-To: <0F5D65D6-DCCC-4AC0-A836-7EFFA2AD25F2@opencsw.org> References: <4AE87999.6020401@opencsw.org> <777D637C-111E-4F5B-8562-501B9F42351E@opencsw.org> <4B48FA2F.2020806@opencsw.org> <4B538451.7030002@opencsw.org> <4B53BBA5.6010607@opencsw.org> <0F5D65D6-DCCC-4AC0-A836-7EFFA2AD25F2@opencsw.org> Message-ID: <4B54651A.6060707@opencsw.org> Dagobert Michelsen wrote: > Hi Roger, > > Am 18.01.2010 um 02:38 schrieb Roger H?kansson: >> Ihsan Dogan wrote: >>> Am 09.01.10 22:50, schrieb Ihsan Dogan: >>>>> Ihsan: For rrdtool I just opened a case for 64 bit libs: >>>>> >>>> I'll have a look in that tomorrow. >>> I'm running into a problem with Pango. We discussed this issue here >>> before, but I don't remember how it ended. >>> http://pastebin.ca/1755178 >> >> The lib does contain what you need, but I'm pretty sure that if you >> check config.log you will find that every test have failed due to: >> >> Undefined first referenced >> symbol in file >> XSolarisIASetProcessInfo /usr/openwin/lib/libX11.so.4 >> >> The problem is related to what I wrote last week regarding libcairo. >> >> Until the libcairo-problem is fixed, you might be able to get around it >> by adding this to your Makefile >> >> EXTRA_SOS_LD_FLAGS = -L$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) >> CONFIGURE_ARGS += --x-includes=$(prefix)/X11/include >> CONFIGURE_ARGS += --x-libraries=$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) >> >> Using those changes I'm able to build rrdtool using what's in GAR. >> >> However, until libcairo is fixed, you probably also need to add >> EXTRA_SOS_LD_OPTIONS = -R$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) > > I see you have already done some work on it. Does it work? > Please take it over at will. Well, it works as far as I can tell, but a potential problem is how old dependencies are affected (see my previous mails regarding libX11.so.4/libXrender.so.1) I'll push the packages as is to /testing so someone else can do some more testing. The difference between this package and the current one is just that /opt/csw/X11/lib(/opt/csw/X11/lib/64) is first in RUNPATH in order to work around the fact that there is a libXrender.so.1 in /opt/csw/lib which is linked to libX11.so.4 in /usr/openwin instead of "our" own in /opt/csw/X11. But this still isn't a complete solution in order to link with libcairo without linking with libX11 from openwin. This version of libcairo only takes care of the runtime problem, when building apps/lib using libcairo you still need to prepend -L/opt/csw/X11/lib (-R/opt/csw/X11/lib if your app/lib uses X11 stuff in other places and not just as a result of linking with libcairo) to your link command. One way to do it when using GAR is to set: EXTRA_SOS_LD_FLAGS = -L$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) (and if needed: EXTRA_SOS_LD_OPTIONS = -R$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) ) From schwindt at dfki.uni-kl.de Mon Jan 18 18:33:28 2010 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Mon, 18 Jan 2010 18:33:28 +0100 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: Your message of "Mon, 21 Dec 2009 14:03:14 GMT." Message-ID: <201001181733.o0IHXS5r003576@dfki.uni-kl.de> [...] > * pysvn: minor version upgrade > * replaces the old subversion bindings with the pysvn project files. Which does break trac - btw. removing pysvn and install pythonsvn fixed the trac installation. I was lucky - the production system do not run this python .) Nicolai From maciej at opencsw.org Mon Jan 18 18:40:18 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 18 Jan 2010 17:40:18 +0000 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: <201001181733.o0IHXS5r003576@dfki.uni-kl.de> References: <201001181733.o0IHXS5r003576@dfki.uni-kl.de> Message-ID: On Mon, Jan 18, 2010 at 5:33 PM, Nicolai Schwindt wrote: > [...] >> * pysvn: minor version upgrade >> ?* replaces the old subversion bindings with the pysvn project files. > > Which does break trac - btw. > removing pysvn and install pythonsvn fixed the trac installation. > > I was lucky - the production system do not run this python .) The plan was to upgrade Trac and make it depend on pythonsvn. pysvn and pythonsvn can be installed alongside, removing or installing pysvn doesn't do anything with relation to Trac. But it's still depending on pysvn from what I can see on the packages page: http://www.opencsw.org/packages/trac The updated Trac is in testing. Rupert, ping? From schwindt at dfki.uni-kl.de Mon Jan 18 18:46:27 2010 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Mon, 18 Jan 2010 18:46:27 +0100 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: Your message of "Mon, 18 Jan 2010 17:40:18 GMT." Message-ID: <201001181746.o0IHkRpD003749@dfki.uni-kl.de> > The plan was to upgrade Trac and make it depend on pythonsvn. pysvn > and pythonsvn can be installed alongside, removing or installing pysvn > doesn't do anything with relation to Trac. > > But it's still depending on pysvn from what I can see on the packages page: > http://www.opencsw.org/packages/trac Exactly - and 'pkg-get -u' pulls in the pysvn 1.7.1,REV=2009.12.24. which breaks trac. Nicolai From maciej at opencsw.org Mon Jan 18 18:52:51 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 18 Jan 2010 17:52:51 +0000 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: <201001181746.o0IHkRpD003749@dfki.uni-kl.de> References: <201001181746.o0IHkRpD003749@dfki.uni-kl.de> Message-ID: On Mon, Jan 18, 2010 at 5:46 PM, Nicolai Schwindt wrote: > >> The plan was to upgrade Trac and make it depend on pythonsvn. pysvn >> and pythonsvn can be installed alongside, removing or installing pysvn >> doesn't do anything with relation to Trac. >> >> But it's still depending on pysvn from what I can see on the packages page: >> http://www.opencsw.org/packages/trac > > Exactly - and 'pkg-get -u' ?pulls in the ?pysvn 1.7.1,REV=2009.12.24. which > breaks trac. Does it really break it? I thought it would be neutral. From schwindt at dfki.uni-kl.de Mon Jan 18 20:52:36 2010 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Mon, 18 Jan 2010 20:52:36 +0100 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: Your message of "Mon, 18 Jan 2010 17:52:51 GMT." Message-ID: <201001181952.o0IJqa9b005155@dfki.uni-kl.de> [...] > > Does it really break it? I thought it would be neutral. "No module named svn" will be displayed on each page. The wiki itself stays readable. Nicolai From maciej at opencsw.org Mon Jan 18 20:59:48 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 18 Jan 2010 19:59:48 +0000 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: <201001181952.o0IJqa9b005155@dfki.uni-kl.de> References: <201001181952.o0IJqa9b005155@dfki.uni-kl.de> Message-ID: On Mon, Jan 18, 2010 at 7:52 PM, Nicolai Schwindt wrote: > [...] >> >> Does it really break it? ?I thought it would be neutral. > > "No module named svn" will be displayed on each page. > The wiki itself stays readable. I see. I think it's the lack of pythonsvn, not the presence of pysvn. From ihsan at opencsw.org Mon Jan 18 22:22:39 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Mon, 18 Jan 2010 22:22:39 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> Message-ID: <4B54D11F.3000608@opencsw.org> Am 18.01.10 10:23, schrieb Gary Law: > and +1 for calling it newpkgs newpkgs exists already: https://lists.opencsw.org/mailman/listinfo/newpkgs Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From bwalton at opencsw.org Mon Jan 18 22:27:45 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 18 Jan 2010 16:27:45 -0500 Subject: [csw-maintainers] new mailing list? In-Reply-To: <4B54D11F.3000608@opencsw.org> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B54D11F.3000608@opencsw.org> Message-ID: <1263850046-sup-8178@ntdws12.chass.utoronto.ca> Excerpts from Ihsan Dogan's message of Mon Jan 18 16:22:39 -0500 2010: > newpkgs exists already: https://lists.opencsw.org/mailman/listinfo/newpkgs pkgreleases ? -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Mon Jan 18 23:36:56 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 18 Jan 2010 22:36:56 +0000 Subject: [csw-maintainers] new mailing list? In-Reply-To: <1263850046-sup-8178@ntdws12.chass.utoronto.ca> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B54D11F.3000608@opencsw.org> <1263850046-sup-8178@ntdws12.chass.utoronto.ca> Message-ID: On Mon, Jan 18, 2010 at 9:27 PM, Ben Walton wrote: > Excerpts from Ihsan Dogan's message of Mon Jan 18 16:22:39 -0500 2010: > >> newpkgs exists already: https://lists.opencsw.org/mailman/listinfo/newpkgs > > pkgreleases ? The existing newpkgs list sounds like it really means pkgreleases, perhaps it could be renamed. (can you move list archives too?) The new list would be something along the lines of pkgsubmissions (which is long, but descriptive). From skayser at opencsw.org Tue Jan 19 00:08:51 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 19 Jan 2010 00:08:51 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B54D11F.3000608@opencsw.org> <1263850046-sup-8178@ntdws12.chass.utoronto.ca> Message-ID: <4B54EA03.9090001@opencsw.org> Maciej (Matchek) Blizinski wrote on 18.01.2010 23:36: > On Mon, Jan 18, 2010 at 9:27 PM, Ben Walton wrote: >> Excerpts from Ihsan Dogan's message of Mon Jan 18 16:22:39 -0500 2010: >> >>> newpkgs exists already: https://lists.opencsw.org/mailman/listinfo/newpkgs >> pkgreleases ? > > The existing newpkgs list sounds like it really means pkgreleases, > perhaps it could be renamed. (can you move list archives too?) +1 > The new list would be something along the lines of pkgsubmissions > (which is long, but descriptive). In case of a recipient address I like the concept of "short", so while we are juggling with names, what about? submit at opencsw.org Could also be just an alias for pkgsubmissions (that way all the pkg* relevant mailing lists would have the same prefix). Once the thread is on the list, the reply-to is set properly so the alias used to address the list initially shouldn't matter. Sebastian From bwalton at opencsw.org Tue Jan 19 01:27:49 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 18 Jan 2010 19:27:49 -0500 Subject: [csw-maintainers] new mailing list? In-Reply-To: <4B54EA03.9090001@opencsw.org> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B54D11F.3000608@opencsw.org> <1263850046-sup-8178@ntdws12.chass.utoronto.ca> <4B54EA03.9090001@opencsw.org> Message-ID: <1263860820-sup-7722@ntdws12.chass.utoronto.ca> Excerpts from Sebastian Kayser's message of Mon Jan 18 18:08:51 -0500 2010: > > The new list would be something along the lines of pkgsubmissions > we are juggling with names, what about? > > submit at opencsw.org Comprising to submitpkg@ ? -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 Jan 19 09:04:26 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 19 Jan 2010 09:04:26 +0100 Subject: [csw-maintainers] X11 installed and farm has been updated Message-ID: <3B37F5DF-A1E6-4D53-8CDC-A7931A4B1228@opencsw.org> Hi, I just upgraded all buildservers to the most recent packages and installed some of the new ones like libproxy. Let me know if you need anything more. William: I just installed all the new X11 proto packages for you :-) Best regards -- Dago From schwindt at dfki.uni-kl.de Tue Jan 19 10:21:56 2010 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Tue, 19 Jan 2010 10:21:56 +0100 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: Your message of "Mon, 18 Jan 2010 19:59:48 GMT." Message-ID: <201001190921.o0J9LuLK012292@dfki.uni-kl.de> [...] > I see. I think it's the lack of pythonsvn, not the presence of pysvn. May be I implied too much : updating pysvn ( as package name ) installs a python new module which no longer has the name svn ( as module name ). A new trac package with updated dependencies to pythonsvn could solve this. Nicolai From hson at opencsw.org Tue Jan 19 16:26:17 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Tue, 19 Jan 2010 16:26:17 +0100 Subject: [csw-maintainers] [csw-devel] SF.net SVN: gar:[8091] csw/mgar/pkg/libsoup2/trunk In-Reply-To: <4B55C08C.9000907@baltic-online.de> References: <4B55B966.6060505@gmail.com> <4B55BBF2.40504@gmail.com> <4B55C08C.9000907@baltic-online.de> Message-ID: <4B55CF19.2060905@opencsw.org> Jan Holzhueter wrote: > Hi, > > Am 19.01.10 15:04, schrieb Roger H?kansson: > >>> Noticed that you committed some stuff for libsoup2, I've been working >>> on releasing a updated version, but I've not committed my stuff yet. > Sorry didn't know you where working on it. > I will leave my work as it is atm and you can scrap or enhance it :) No problem, its a work in progress, I'm updating some packages which have a huge list of requirements and libsoup >2.4 was one of them so I started looking into that. >>> However I was going to update libsoup to current and scrap libsoup2 as >>> a separate package since there is only a few packages needing >>> libsoup2. So keeping them as separate packages is in my world not >>> necessary. > I don't now how many packages need libsoup2. A few weeks ago someone > drop by in the irc chat and reported that rhythmbox seems to be broken. > So I looked at bulding a new one since the CSW Version is kind of old. > Thats why I started updating libsoup2. > > So I don't know what to do with libsoup2 > Maybe you should forward this to maintainers@ > as I can't post there I think. To see what others think. Regarding the dependencies to libsoup (1.99) and libsoup2 (2.2.96), there are one package which need libsoup, multisync. There are four packages which need libsoup2, all of them evolution plus related plugins. My plan was to release a new libsoup-package which include the old libraries plus a empty dummy libsoup2-package which only has a dependency to libsoup so the evolution-stuff won't be broken (although, I don't know if it still works, there are a bunch of bugs reported for those packages). Then when the evolution-packages are updated (also on my TODO) they will have libsoup as a dependency and not libsoup2. But this maybe isn't the "right" way to do it (that's why I also send this to the maintainer's list)... From phil at bolthole.com Tue Jan 19 17:06:58 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 19 Jan 2010 08:06:58 -0800 Subject: [csw-maintainers] file-5.03 In-Reply-To: References: Message-ID: Just make sure your tweak works on the "gzip" package itself. gzip-blahblah*.pkg which is NOT gzipped, so will trigger error on false positive! :-) On Mon, Jan 18, 2010 at 5:26 AM, Maciej (Matchek) Blizinski wrote: > On Sun, Jan 17, 2010 at 8:30 PM, Dagobert Michelsen wrote: >> Hi Maciej, >> >> Am 13.01.2010 um 11:37 schrieb Maciej (Matchek) Blizinski: >>> >>> We don't have our own, up-to-date file (or gfile), do we? >> >> There doesn't seem to be a "GNU File" command, but I have packaged >> the latest one from >> ?http://www.darwinsys.com/file/ >> which seems pretty good in testing: >> >> file-5.03,REV=2010.01.17-SunOS5.8-sparc-CSW.pkg.gz >> file-5.03,REV=2010.01.17-SunOS5.8-i386-CSW.pkg.gz > > checkpkg doesn't work with it. > > It exports two colons instead of one in the output, and checkpkg > doesn't detect a gzip file any more. > > The fix: > > Index: bin/checkpkg > =================================================================== > --- bin/checkpkg ? ? ? ?(revision 8048) > +++ bin/checkpkg ? ? ? ?(working copy) > @@ -90,7 +90,9 @@ > > ?set_variables_for_individual_package_check() { > ? ? ? ?f=$1 > - ? ? ? file $f |sed 's/^.*://' |grep gzip >/dev/null > + ? ? ? file $f \ > + ? ? ? ? ? | sed 's/^[^:]*://' \ > + ? ? ? ? ? | grep gzip >/dev/null > ? ? ? ?if [ $? -eq 0 ] ; then > ? ? ? ? ? ? ? ?TMPARCHIVE=$CHECKPKG_TMPDIR/`basename $f` > ? ? ? ? ? ? ? ?if [[ -f $TMPARCHIVE ]] ; then > > Committed in r8075. > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From phil at bolthole.com Tue Jan 19 18:07:25 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 19 Jan 2010 09:07:25 -0800 Subject: [csw-maintainers] GAR: Least invasive way to pre-pend extra lib directories to LDFLAGS/LD_OPTIONS? In-Reply-To: <61493F41-495D-440F-A431-76F824C2704A@opencsw.org> References: <4B53445A.2010307@opencsw.org> <61493F41-495D-440F-A431-76F824C2704A@opencsw.org> Message-ID: On Sun, Jan 17, 2010 at 12:14 PM, Dagobert Michelsen wrote: >>.... > That's why I think it would be good to change the order of directory > pathes as linker parameters. As this change is somewhat invasive I would > like some feedback of some senior packages (read: all of you :-) > Gee, this sounds a whoole lot like a coupla years ago, when my recommendations were, "force certain paths in /opt/csw to be first, via LD_OPTIONS in your build environment, because it's canonical and tends to work reguardless of whatever twisted sub-build-tool is used." but people complained. Yet here we are again. ahaha. :-) From phil at bolthole.com Tue Jan 19 18:24:28 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 19 Jan 2010 09:24:28 -0800 Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Jan 14, 2010 at 2:59 PM, Maciej (Matchek) Blizinski wrote: > >> 5. Openness. ?It pulls back the curtains a bit more on some of the >> ? backend happenings. > > I predict this argument will be attacked by Phil, as he generally > pushes everything towards closedness. You dont know me as well as you think you do :-P >It's a classic example when somebody makes a proposal, the vast >majority of maintainers support the idea, Phil says no, and the topic >dies a quiet death. I would like this not to happen any more. I will mention here that the most common reason for this sort of cycle, is that I point out potential problems in the proposal, and no-one can come up with decent fixes for the problems in the proposal that I bring up. So then the flawed proposal dies. And in a logically based system, that is a GOOD thing. Flawed proposals SHOULD "die a quiet death". Not every proposal should succeed; even initially popular ones. That being said... I didnt even say "no this list should not be created or used". I only pointed out that it wont fully achieve specific things that Ben stated he thought it would do. It was nice to see that on this proposal, people actually replied to my comments in a useful manner, calmly and rationally. This is GOOD! I LIKE this! :-) My goal is not "stop all proposals", but only "point out any flaws in them that I can see". If people actually address those flaws, then I will cheerfully support a proposal I may have been initially against. PS: "submitpkg" as the new list name seems fairly good to me. From dam at opencsw.org Tue Jan 19 20:30:23 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 19 Jan 2010 20:30:23 +0100 Subject: [csw-maintainers] GAR: Least invasive way to pre-pend extra lib directories to LDFLAGS/LD_OPTIONS? In-Reply-To: References: <4B53445A.2010307@opencsw.org> <61493F41-495D-440F-A431-76F824C2704A@opencsw.org> Message-ID: <2F10C918-0DBE-41A9-A81D-75D04B6D6CF1@opencsw.org> Hi Phil, Am 19.01.2010 um 18:07 schrieb Philip Brown: > On Sun, Jan 17, 2010 at 12:14 PM, Dagobert Michelsen > wrote: >>> .... >> That's why I think it would be good to change the order of directory >> pathes as linker parameters. As this change is somewhat invasive I >> would >> like some feedback of some senior packages (read: all of you :-) > > > Gee, this sounds a whoole lot like a coupla years ago, when my > recommendations were, > "force certain paths in /opt/csw to be first, via LD_OPTIONS in your > build environment, because it's canonical and tends to work > reguardless of whatever twisted sub-build-tool is used." > but people complained. > > Yet here we are again. > ahaha. :-) Not quite. We are talking here about the order of directories passed via LD_OPTIONS to put more specialized directories in front and /opt/csw/lib at the end. It is not about LD_OPTIONS or LDFLAGS. Best regards -- Dago From phil at bolthole.com Tue Jan 19 21:42:39 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 19 Jan 2010 12:42:39 -0800 Subject: [csw-maintainers] GAR: Least invasive way to pre-pend extra lib directories to LDFLAGS/LD_OPTIONS? In-Reply-To: <2F10C918-0DBE-41A9-A81D-75D04B6D6CF1@opencsw.org> References: <4B53445A.2010307@opencsw.org> <61493F41-495D-440F-A431-76F824C2704A@opencsw.org> <2F10C918-0DBE-41A9-A81D-75D04B6D6CF1@opencsw.org> Message-ID: On Tue, Jan 19, 2010 at 11:30 AM, Dagobert Michelsen wrote: > Hi Phil, > *wave* > Am 19.01.2010 um 18:07 schrieb Philip Brown: > >> Gee, this sounds a whoole lot like a coupla years ago, when my >> recommendations were, >> "force certain paths in /opt/csw to be first, via LD_OPTIONS in your >> build environment, because it's canonical and tends to work >> reguardless of whatever twisted sub-build-tool is used." >> but people complained. >> >> Yet here we are again. >> ahaha. :-) > > Not quite. We are talking here about the order of directories passed via > LD_OPTIONS to put more specialized directories in front and /opt/csw/lib > at the end. It is not about LD_OPTIONS or LDFLAGS. > seems to me, the "least invasive way", would be to let the builder set them directly, and not to have it in "the build system" at all. Or, if it is in the build system, have ONE SINGLE top level override, that only gets set in extreme cases, and gets set only on a per-project basis. (ie: no "default" use of it). From phil at bolthole.com Tue Jan 19 21:44:16 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 19 Jan 2010 12:44:16 -0800 Subject: [csw-maintainers] Packages with private /opt/csw/foo directory In-Reply-To: References: <1257540745-sup-2047@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Jan 15, 2010 at 1:22 AM, Maciej (Matchek) Blizinski wrote: > > This symlink, if I understand correctly, makes it impossible to have > multiple MySQL databases installed at the same time, because > /opt/csw/lib/mysql is "the MySQL database", which is something people > were arguing against (notably, Phil). I was? > Either we have one default version of MySQL or we don't. ?If we don't, > the symlink shall not exist. ?If we do, let's install one MySQL > version into /opt/csw, and alternative versions (e.g. 4) to private > prefixes. > > Thoughts? I think the default should be done only via symlinks, or other appropriate wrappers/pointeres to the "real" location. From phil at bolthole.com Tue Jan 19 21:47:15 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 19 Jan 2010 12:47:15 -0800 Subject: [csw-maintainers] CSW packaged MTAs and /usr (continued from "CSWcswclassutils: it wants to write in /usr") In-Reply-To: <4B4E4226.40600@opencsw.org> References: <4B4E4226.40600@opencsw.org> Message-ID: On Wed, Jan 13, 2010 at 1:59 PM, Sebastian Kayser wrote: > > With an updated postfix package I would like to make the package as > simple as possible and leave control to the user. Therefor I would like > to emit a notification message on package installation, either pointing > the user to a README.CSW, a script, an additional integration package, > or simply to echo commands that one can issue to integrate postfix with > the system. a script would be best, IMO. > patches. What would happen if we left the system sendmail packages in > place and simply moved away the binaries? Wouldn't a sendmail patch > notice the installed sendmail package and overwrite our link with > possibly patched binaries? actually it would probably complain that the target binaries it was replacing, dont match, and then refuse to patch. but depending on the particular patch, it might. > Granted, pkgrm wouldn't make it easy for a > user to revert back to system sendmail .. just trying to get a feeling > for the different approaches. offering pkgrm as an option, sounds like a good thing. Also though, particularly for the "no pkgrm" option.. make sure to provide an UNinstall script, to match up with the (/usr) install script please. From skayser at opencsw.org Tue Jan 19 22:34:26 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 19 Jan 2010 22:34:26 +0100 Subject: [csw-maintainers] OpenCSW Winter Camp - 23/24 Jan 2010, final infos and preparations Message-ID: <4B562562.8010900@opencsw.org> Hi guys, while the snow here in Munich is melting away, winter camp is coming closer. Some details: current plan is to meet on Friday evening at our office in Munich and go for dinner nearby (Dago and Maciej will join us once they have made their way from the airport). After that we will drive to the conference place/hotel together (about 1hr south of Munich, two cars). Departure from the hotel will be Sunday 4pm. Details and directions are online on the wiki page [1,2]. I have booked single rooms for the people who are currently listed on the winter camp page. If anyone else decided to join in the meantime, please let me know. For all those others, I will try to post some more frequent updates about what's going on (plus photos) during the camp. What we also might try is to _test drive_ a web stream / conferencing setup (just for the fun of it, might come in handy for one of the future camps or to record a talk). Anyone out there with a recommendation on neat tools to do so? If there are any questions, don't hesitate to ask. Looking forward to Friday! Sebastian [1] http://opencsw.wikidot.com/wintercamp-2009 [2] http://opencsw.wikidot.com/wintercamp-2009-directions From james at opencsw.org Wed Jan 20 13:25:16 2010 From: james at opencsw.org (James Lee) Date: Wed, 20 Jan 2010 12:25:16 GMT Subject: [csw-maintainers] new mailing list? In-Reply-To: <4B53810D.2010706@wbonnet.net> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B53810D.2010706@wbonnet.net> Message-ID: <20100120.12251600.3567085334@gyor.oxdrove.co.uk> On 17/01/10, 21:28:45, William Bonnet wrote regarding Re: [csw-maintainers] new mailing list?: > > Given that there is only a single registered 'nay' vote and that > > procedural changes consist of _only_ sending the mail to a list > > instead of an individual, I'd like to ask Ihsan to create the list, > > with myself, Dago and Phil as members to start. > > > More generally, i would like to suggest that each of our process that > needs email communication, should be using "functional" email addresses > rather than "personal" (or "named") addresses. Whether the functional > address is a mailing list or not. This is a good idea and was called role based last time it was suggested here. Business email should be sent to a role but received by a person. I also suggested that package maintenance represents a role and so package email should go to ${package}@opencsw.org and be forwarded to a person. The key here is the person can change without changing the email address. Roles based addressing is not the same as having a mailing list behind it. This request seems like a classic example of wanting to see something because you can't and not because once seen there is any net benefit to logging every action. There are some activities that do not need to be logged in detail and broadcast, for example I had a poo this morning, does anyone want to see my log? I guess the majority of new package emails are "here is a package" followed by "thank you" which anyone can infer happened by the pattern of releases. Actually we don't know if it happened and neither does it matter as the important event is release which is already broadcast and public. Any useful transmission will be masked in a stream of boring traffic. Subscribe? No thank you. There may be some messages associated with refusal. If broadcast and recorded by a mailing list there is the potential for public humiliation. Brilliant idea, this might cause people to think before submitting a package! Can we have a naughty step on the web site? Any useful information should be condensed from the flow and put on the maintainers' list or a "How (not) to make a package" web page. I'll start here with common problems and top tips: 1. put the right arch binary in the right package 2. use the package for several days before release, install with pkg-get 3. remove your package (important as can't fix after install) 4. check that the new package does not disrupt any dependants, eg by changing a library's SONAME. 5. think. Eg in the package dir, run: find . -type f | xargs file find . -ls (look at locations and sizes) find . -type f | xargs file | nawk -F: '/ELF/{print $1}' and on each result: dump -Lv ... ldd -r ... and think. James. From william at wbonnet.net Wed Jan 20 14:18:07 2010 From: william at wbonnet.net (William Bonnet) Date: Wed, 20 Jan 2010 14:18:07 +0100 Subject: [csw-maintainers] X11 installed and farm has been updated In-Reply-To: <3B37F5DF-A1E6-4D53-8CDC-A7931A4B1228@opencsw.org> References: <3B37F5DF-A1E6-4D53-8CDC-A7931A4B1228@opencsw.org> Message-ID: <4B57028F.7040308@wbonnet.net> Hi > William: I just installed all the new X11 proto packages for you :-) > Thanks a lot Next batch of compilation is running cheers W. > > Best regards > > -- Dago > > From dam at opencsw.org Wed Jan 20 15:21:38 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 20 Jan 2010 15:21:38 +0100 Subject: [csw-maintainers] Problem compiling remake In-Reply-To: <6cd6de211001191857j35ff7838va94dab9a7b7a9adb@mail.gmail.com> References: <6cd6de211001070921i456ddc16s62ea6fbf4a2b71b2@mail.gmail.com> <829A8165-DBAA-4535-9312-038FEB31A5C8@opencsw.org> <6cd6de211001191857j35ff7838va94dab9a7b7a9adb@mail.gmail.com> Message-ID: Hi folks, I mailed with the author of remake (the make debugger) and he has compilation problems I have never seen before: Am 20.01.2010 um 03:57 schrieb Rocky Bernstein: > When I try to compile that I get errors due to some sort of error in > strings.h pulled in from > the readline config file config/readline.h: > > In file included from /opt/csw/include/readline/chardefs.h:35, > from /opt/csw/include/readline/keymaps.h:35, > from /opt/csw/include/readline/readline.h:37, > from ./config/readline.h:10, > from debugger/cmd.c:51: > /usr/include/strings.h:24: error: expected declaration specifiers or > '...' before '(' token > > If you immediately see what's wrong let me know. A log from "./ > configure" and from "make" > can be found on login.opencsw.org:~rocky/src/build/ > remake-3.81+dbg-0.2/configure.log > and make.log Any advice is welcome here. (Please reply-all as Rocky is not on maintainers@) Best regards -- Dago From maciej at opencsw.org Wed Jan 20 15:46:49 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 20 Jan 2010 14:46:49 +0000 Subject: [csw-maintainers] new mailing list? In-Reply-To: <20100120.12251600.3567085334@gyor.oxdrove.co.uk> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B53810D.2010706@wbonnet.net> <20100120.12251600.3567085334@gyor.oxdrove.co.uk> Message-ID: On Wed, Jan 20, 2010 at 12:25 PM, James Lee wrote: > I guess the majority of new package emails are "here is a package" > followed by "thank you" which anyone can infer happened by the pattern > of releases. ?Actually we don't know if it happened and neither does > it matter as the important event is release which is already broadcast > and public. ?Any useful transmission will be masked in a stream of > boring traffic. ?Subscribe? ?No thank you. It's true that in most cases it will be boring, but I think it's important to have the submission information available, of anyone wants to access it. The problem with sendmail effort comes to mind. The release is one important broadcast, but a package submission is also an important event, if you think about the dynamics of the maintainer group. > There may be some messages associated with refusal. ?If broadcast and > recorded by a mailing list there is the potential for public humiliation. Humiliation of whom do you mean? There would be nothing the contents of the submitted packages. If there was anything horribly broken about the package, it would be seen by the public at the testing/ stage. This rules out the mailing list as a humiliation cause. > Brilliant idea, this might cause people to think before submitting a > package! ?Can we have a naughty step on the web site? > > Any useful information should be condensed from the flow and put on the > maintainers' list or a "How (not) to make a package" web page. ?I'll > start here with common problems and top tips: > > 1. put the right arch binary in the right package > 2. use the package for several days before release, install with pkg-get > 3. remove your package (important as can't fix after install) > 4. check that the new package does not disrupt any dependants, eg > ? by changing a library's SONAME. > 5. think. ?Eg in the package dir, run: > ? ? ?find . -type f | xargs file > ? ? ?find . -ls ? (look at locations and sizes) > ? ? ?find . -type f | xargs file | nawk -F: '/ELF/{print $1}' > ? ? ? ? and on each result: > ? ? ? ? ? ?dump -Lv ... > ? ? ? ? ? ?ldd -r ... > ? and think. Everything that can be automated, should be automated. Documenting isn't a bad idea, but the things you've described above, thinking aside, are mundane and boring. Doing them each time for each package is a waste of braincycles and keystrokes. Having a maintainer candidate reading through a long description of how a package is built, would result in the candidates never applying. Now when I look back on my beginnings as a maintainer, I remember that I looked around the website and quickly decided that the documentation there is describing manual steps, which is clearly not the way it's done, so I better avoid looking at it altogether. Instead, I looked specifically for the source code repository. It wasn't obvious, because the words "source code" or "repository" are nowhere to be found on the website. If you look for "site:www.opencsw.org repository -mantis", there only hits are from the package pages, the subversion package being the first. Once I found the repository, I found the directory with the package that interested me and tried to run it. When It failed, I started pulling apart the GAR code to understand what it does, and fixing any errors I came across. And I ended up with decent looking packages. If I were to base my package build attempts on the contents of www.opencsw.org, I would give up building for OpenCSW and instead hack a bunch of scripts to build the package only for myself. I don't mean that I don't support documenting things. It's good to have a detailed description of the policy: what the policy is, and what are the reasons behind it. However, I oppose putting such description forward as an operational document. The new maintainers, who are most likely to make the most of mistakes, should be presented with a relatively short description how to build a package, leaving the checking to checkpkg. It's hard enough to get people to install Sun Studio and gar_devel, keeping the entry bar low for people who want to try building a package for fun is an important aspect of making the community grow. To recap, the boring mailing list is for visibility, traceability, cross-pollination and coordination, while all the lessons learned should be transformed into code which makes sure that the spotted problems will never happen again. Maciej From james at opencsw.org Wed Jan 20 17:39:04 2010 From: james at opencsw.org (James Lee) Date: Wed, 20 Jan 2010 16:39:04 GMT Subject: [csw-maintainers] Problem compiling remake In-Reply-To: References: <6cd6de211001070921i456ddc16s62ea6fbf4a2b71b2@mail.gmail.com> <829A8165-DBAA-4535-9312-038FEB31A5C8@opencsw.org> <6cd6de211001191857j35ff7838va94dab9a7b7a9adb@mail.gmail.com> Message-ID: <20100120.16390400.3062200435@gyor.oxdrove.co.uk> On 20/01/10, 14:21:38, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Problem compiling remake: > Am 20.01.2010 um 03:57 schrieb Rocky Bernstein: > > When I try to compile that I get errors due to some sort of error in > > strings.h pulled in from > > the readline config file config/readline.h: > > > > In file included from /opt/csw/include/readline/chardefs.h:35, > > from /opt/csw/include/readline/keymaps.h:35, > > from /opt/csw/include/readline/readline.h:37, > > from ./config/readline.h:10, > > from debugger/cmd.c:51: > > /usr/include/strings.h:24: error: expected declaration specifiers or > > '...' before '(' token in make.h # define bcmp(s1, s2, n) memcmp ((s1), (s2), (n)) should be # define bcmp(s1, s2, n) memcmp (s1, s2, n) and in a few other places the same. make.h is included before the system header so corrupts the function prototypes, it's turning the prototypes into type casts. Solaris has bcmp anyway so you can drop the whole of that section, perhaps the bit that identifies the system is wrong. James. From james at opencsw.org Wed Jan 20 17:47:01 2010 From: james at opencsw.org (James Lee) Date: Wed, 20 Jan 2010 16:47:01 GMT Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B53810D.2010706@wbonnet.net> <20100120.12251600.3567085334@gyor.oxdrove.co.uk> Message-ID: <20100120.16470100.3668465799@gyor.oxdrove.co.uk> On 20/01/10, 14:46:49, Maciej "(Matchek)" Blizinski wrote regarding Re: [csw-maintainers] new mailing list?: > It's true that in most cases it will be boring, but I think it's > important to have the submission information available, of anyone > wants to access it. The problem with sendmail effort comes to mind. > The release is one important broadcast, but a package submission is > also an important event, if you think about the dynamics of the > maintainer group. No, it's not important. No one outside the group needs to know. > > There may be some messages associated with refusal.?If broadcast and > > recorded by a mailing list there is the potential for public humiliation. > Humiliation of whom do you mean? Presumably the idiot that submits a sparc package with intel binaries. If you are not embarrassed to submit packages with such fundamental mistakes your standards are low. > There would be nothing the contents > of the submitted packages. If there was anything horribly broken > about the package, it would be seen by the public at the testing/ > stage. Oh yes? If this were true no package would ever fail which isn't true, so the initial assertion is also untrue. > > Any useful information should be condensed from the flow and put on the > > maintainers' list or a "How (not) to make a package" web page. ?I'll > > start here with common problems and top tips: ... > Everything that can be automated, should be automated. Documenting > isn't a bad idea, but the things you've described above, thinking > aside, are mundane and boring. Doing them each time for each package > is a waste of braincycles and keystrokes. Yes it's boring and mundane. Please explain why someone else should do this for you? More importantly why I have been. You seem to not understand anything about the effort involved in QA. > To recap, the boring mailing list is for visibility, traceability, > cross-pollination and coordination, while all the lessons learned > should be transformed into code which makes sure that the spotted > problems will never happen again. Visibility of what? I'm confused as to what you think exists that is being kept from you - and I'm not saying you shouldn't see it, only that it obscures useful information. James. From phil at bolthole.com Wed Jan 20 18:25:21 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 20 Jan 2010 09:25:21 -0800 Subject: [csw-maintainers] new mailing list? In-Reply-To: <20100120.12251600.3567085334@gyor.oxdrove.co.uk> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B53810D.2010706@wbonnet.net> <20100120.12251600.3567085334@gyor.oxdrove.co.uk> Message-ID: On Wed, Jan 20, 2010 at 4:25 AM, James Lee wrote: > > This is a good idea and was called role based last time it was suggested > here. ?Business email should be sent to a role but received by a person. > I also suggested that package maintenance represents a role and so > package email should go to ${package}@opencsw.org and be forwarded to a > person. ?The key here is the person can change without changing the > email address. > potentially nice idea.. but in practical terms, it ends up being a HUGE spam burden, with little benefit to having a direct email interface. Are you saying you dont like the existing interface of, webbrowse to www.opencsw.org/packages/{package} click "email maintainer" ? From james at opencsw.org Wed Jan 20 20:09:23 2010 From: james at opencsw.org (James Lee) Date: Wed, 20 Jan 2010 19:09:23 GMT Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B53810D.2010706@wbonnet.net> <20100120.12251600.3567085334@gyor.oxdrove.co.uk> Message-ID: <20100120.19092300.3761741195@gyor.oxdrove.co.uk> On 20/01/10, 17:25:21, Philip Brown wrote regarding Re: [csw-maintainers] new mailing list?: > > This is a good idea and was called role based last time it was suggested > > here. Business email should be sent to a role but received by a person. > > I also suggested that package maintenance represents a role and so > > package email should go to ${package}@opencsw.org and be forwarded to a > > person. The key here is the person can change without changing the > > email address. > potentially nice idea.. but in practical terms, it ends up being a > HUGE spam burden Good point. > Are you saying you dont like the existing interface of, > webbrowse to www.opencsw.org/packages/{package} > click "email maintainer" Not that, although now the email goes to the last maintainer and it doesn't change until a new packages is built. Divorcing the address from the package could make it easier to change the route. The packages contain the personal emails and we can't change. When someone takes a sabbatical the destination should be swapped. We could also have several people receiving the emails in the case of a maintainer team - or a mailing list. I subscribe to upstream announce lists and the address goes with the package not me. I'm not sure if package addresses are better, generally I like to split roles from handlers in the email routing. Package addresses are not as important as webmaster@, newpks@, release@, mirrors@, buildfarm@, mantis@, publicity@, anyrole at . James. From rocky at gnu.org Wed Jan 20 21:41:22 2010 From: rocky at gnu.org (Rocky Bernstein) Date: Wed, 20 Jan 2010 15:41:22 -0500 Subject: [csw-maintainers] Problem compiling remake In-Reply-To: <20100120.16390400.3062200435@gyor.oxdrove.co.uk> References: <6cd6de211001070921i456ddc16s62ea6fbf4a2b71b2@mail.gmail.com> <829A8165-DBAA-4535-9312-038FEB31A5C8@opencsw.org> <6cd6de211001191857j35ff7838va94dab9a7b7a9adb@mail.gmail.com> <20100120.16390400.3062200435@gyor.oxdrove.co.uk> Message-ID: <6cd6de211001201241u16c368afj712845458dee2fba@mail.gmail.com> Thanks for the clue. I now see what's going on. It is proving tougher because all of those headers which come from GNU make rather than my patches on top of that. On Wed, Jan 20, 2010 at 11:39 AM, James Lee wrote: > On 20/01/10, 14:21:38, Dagobert Michelsen wrote > regarding > Re: [csw-maintainers] Problem compiling remake: > > > Am 20.01.2010 um 03:57 schrieb Rocky Bernstein: > > > > When I try to compile that I get errors due to some sort of error in > > > strings.h pulled in from > > > the readline config file config/readline.h: > > > > > > In file included from /opt/csw/include/readline/chardefs.h:35, > > > from /opt/csw/include/readline/keymaps.h:35, > > > from /opt/csw/include/readline/readline.h:37, > > > from ./config/readline.h:10, > > > from debugger/cmd.c:51: > > > /usr/include/strings.h:24: error: expected declaration specifiers or > > > '...' before '(' token > > > in make.h > # define bcmp(s1, s2, n) memcmp ((s1), (s2), (n)) > > should be > # define bcmp(s1, s2, n) memcmp (s1, s2, n) > > and in a few other places the same. make.h is included before the > system header so corrupts the function prototypes, it's turning the > prototypes into type casts. > > > Solaris has bcmp anyway so you can drop the whole of that section, > perhaps the bit that identifies the system is wrong. > > > > > James. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at bolthole.com Wed Jan 20 22:30:04 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 20 Jan 2010 13:30:04 -0800 Subject: [csw-maintainers] maintainers email addrs on packages Message-ID: On Wed, Jan 20, 2010 at 11:09 AM, James Lee wrote: > On 20/01/10, 17:25:21, Philip Brown wrote regarding Re: >... >> Are you saying you dont like the existing interface of, > >> webbrowse to www.opencsw.org/packages/{package} >> click "email maintainer" > > Not that, although now the email goes to the last maintainer and > it doesn't change until a new packages is built. ?Divorcing the > address from the package could make it easier to change the route. > > The packages contain the personal emails and we can't change. > But we shouldnt need to "fix" that, as an organization. When a package is updated by a new maintainer, the "correct" maintainer email gets into the package. If someone is asking for support on a package, the first thing they should do is upgrade to the latest "current" version of the package. So the only time this is an issue is when the maintainer has retired/disappeared ... in which case, we as an organization, can redirect their email, so it's still ok in theory. > When someone takes a sabbatical the destination should be swapped. "redirect their organizational email". Same as in any other organization, when a person goes on "sabbatical" or extended leave. > We could also have several people receiving the emails in the case > of a maintainer team - or a mailing list. Hrrrm.. I can ALMOST visualize supporting MULTIPLE email addrs in the EMAIL= field of pkginfo. mantis DOES support having multiple people as manager of a package. However to get it to work end-to-end, our www.opencsw.org/packages/xxx scripting would have to be rewritten, rather majorly. Im not feeling up to that. If someone wants to update/take it over, that would be relatively fine by me though. > I subscribe to upstream announce lists and the address goes with > the package not me. Umm.. yikes. roles being subscribed to mailing lists, doesnt sound like a good idea to me personally. From skayser at opencsw.org Thu Jan 21 00:51:00 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 21 Jan 2010 00:51:00 +0100 Subject: [csw-maintainers] maintainers email addrs on packages In-Reply-To: References: Message-ID: <4B5796E4.6010701@opencsw.org> Philip Brown wrote on 20.01.2010 22:30: > On Wed, Jan 20, 2010 at 11:09 AM, James Lee wrote: >> We could also have several people receiving the emails in the case >> of a maintainer team - or a mailing list. > > Hrrrm.. I can ALMOST visualize supporting MULTIPLE email addrs in the > EMAIL= field of pkginfo. mantis DOES support having multiple people as > manager of a package. No ... please. Let's eventually de-couple our meta information handling from the bug handling in Mantis - not work it even more deeper into it. I would have wanted to assign global maintainer privileges to all CSW maintainers for a while now, so that bug handling across packages/projects gets easier. Currently though, our "package-to-maintainer" mapping is based on those privileges in Mantis, so I can't easily manage permissions in Mantis without risking to mess up the mappings. > However to get it to work end-to-end, our > www.opencsw.org/packages/xxx scripting would have to be rewritten, > rather majorly. Im not feeling up to that. > > If someone wants to update/take it over, that would be relatively fine > by me though. Any specifics on what you would need from a package release perspective? Sebastian From skayser at opencsw.org Thu Jan 21 01:27:21 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 21 Jan 2010 01:27:21 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <20100120.16470100.3668465799@gyor.oxdrove.co.uk> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B53810D.2010706@wbonnet.net> <20100120.12251600.3567085334@gyor.oxdrove.co.uk> <20100120.16470100.3668465799@gyor.oxdrove.co.uk> Message-ID: <4B579F69.9020604@opencsw.org> James Lee wrote on 20.01.2010 17:47: > On 20/01/10, 14:46:49, Maciej "(Matchek)" Blizinski > wrote regarding Re: [csw-maintainers] new mailing list?: >>> There may be some messages associated with refusal. If broadcast and >>> recorded by a mailing list there is the potential for public humiliation. > >> Humiliation of whom do you mean? > > Presumably the idiot that submits a sparc package with intel binaries. > If you are not embarrassed to submit packages with such fundamental > mistakes your standards are low. Could we please just drop the harsh word "humiliation" (and the attitude that usually comes along with it wherever one ventures)? There is always something to learn, everyone makes mistakes from time to time and those who are learning should _not_ feel like they are at the eager eyes of those who know better and who are just waiting to humiliate them. >>> Any useful information should be condensed from the flow and put on the >>> maintainers' list or a "How (not) to make a package" web page. I'll >>> start here with common problems and top tips: > > ... > >> Everything that can be automated, should be automated. Documenting >> isn't a bad idea, but the things you've described above, thinking >> aside, are mundane and boring. Doing them each time for each package >> is a waste of braincycles and keystrokes. > > Yes it's boring and mundane. Please explain why someone else should > do this for you? More importantly why I have been. You seem to not > understand anything about the effort involved in QA. >From what I understand, Maciej tried to point out that if something is "boring and mundane" and can be automated, why not let's do it and save everyone's braincycles and keystrokes, especially yours and Phil's. He also offered a hand at extending checkpkg so that it can catch more of those commonly encountered issues. I doubt very much that he doesn't appreciate what the two of you are doing. Sebastian From james at opencsw.org Thu Jan 21 11:50:06 2010 From: james at opencsw.org (James Lee) Date: Thu, 21 Jan 2010 10:50:06 GMT Subject: [csw-maintainers] new mailing list? In-Reply-To: <4B579F69.9020604@opencsw.org> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B53810D.2010706@wbonnet.net> <20100120.12251600.3567085334@gyor.oxdrove.co.uk> <20100120.16470100.3668465799@gyor.oxdrove.co.uk> <4B579F69.9020604@opencsw.org> Message-ID: <20100121.10500600.265148322@gyor.oxdrove.co.uk> On 21/01/10, 00:27:21, Sebastian Kayser wrote regarding Re: [csw-maintainers] new mailing list?: > >>> recorded by a mailing list there is the potential for public humiliation. > > > >> Humiliation of whom do you mean? > > > > Presumably the idiot that submits a sparc package with intel binaries. > > If you are not embarrassed to submit packages with such fundamental > > mistakes your standards are low. > Could we please just drop the harsh word "humiliation" (and the attitude > that usually comes along with it wherever one ventures)? There is always > something to learn, everyone makes mistakes from time to time and those No, it is used on purpose to emphasise my point. People make mistakes, we know that, we accept that. What is not useful is to make a list of someone's short comings and put them on a advertising billboard. > who are learning should _not_ feel like they are at the eager eyes of > those who know better and who are just waiting to humiliate them. Exactly my point, glad you agree. > >>> Any useful information should be condensed from the flow and put on the > >>> maintainers' list or a "How (not) to make a package" web page. I'll > >>> start here with common problems and top tips: > > > > ... > > > >> Everything that can be automated, should be automated. Documenting > >> isn't a bad idea, but the things you've described above, thinking > >> aside, are mundane and boring. Doing them each time for each package > >> is a waste of braincycles and keystrokes. > > > > Yes it's boring and mundane. Please explain why someone else should > > do this for you? More importantly why I have been. You seem to not > > understand anything about the effort involved in QA. > >From what I understand, Maciej tried to point out that if something is > "boring and mundane" and can be automated, why not let's do it and save > everyone's braincycles and keystrokes, especially yours and Phil's. He > also offered a hand at extending checkpkg so that it can catch more of > those commonly encountered issues. I doubt very much that he doesn't > appreciate what the two of you are doing. Automating in only part of the story. People have repeatedly suggested automation is the answer to everything, well firstly much of my test *is* automated. This is not the hard (boring and mundane) part, what takes the time is understanding the output, moderating the marginal cases and effecting rectification. Secondly if you have a automated test procedure that installs a package, answers questions, reads the readmes and follows any instructions as a human would then uses the software and finds all errors please present it. James. From james at opencsw.org Thu Jan 21 11:51:49 2010 From: james at opencsw.org (James Lee) Date: Thu, 21 Jan 2010 10:51:49 GMT Subject: [csw-maintainers] maintainers email addrs on packages In-Reply-To: References: Message-ID: <20100121.10514900.3025170389@gyor.oxdrove.co.uk> On 20/01/10, 21:30:04, Philip Brown wrote regarding Re: [csw-maintainers] maintainers email addrs on packages: > > Not that, although now the email goes to the last maintainer and > > it doesn't change until a new packages is built. ?Divorcing the > > address from the package could make it easier to change the route. > > > > The packages contain the personal emails and we can't change. > But we shouldnt need to "fix" that, as an organization. > When a package is updated by a new maintainer, the "correct" > maintainer email gets into the package. > If someone is asking for support on a package, the first thing they > should do is upgrade to the latest "current" version of the package. What if it is the current? Then the old maintainer is still listed in the package. > > When someone takes a sabbatical the destination should be swapped. > "redirect their organizational email". > Same as in any other organization, when a person goes on "sabbatical" > or extended leave. That can only be done on a per user basis, it's not possible to route some one way and others another. It also means any personal messages are redirected. A break might mean a break from work but not all contact. > > I subscribe to upstream announce lists and the address goes with > > the package not me. > Umm.. yikes. roles being subscribed to mailing lists, doesnt sound > like a good idea to me personally. ${user}@opencsw.org is already a redirect. It's no different. James. From phil at bolthole.com Thu Jan 21 18:44:10 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 21 Jan 2010 09:44:10 -0800 Subject: [csw-maintainers] maintainers email addrs on packages In-Reply-To: <20100121.10514900.3025170389@gyor.oxdrove.co.uk> References: <20100121.10514900.3025170389@gyor.oxdrove.co.uk> Message-ID: On Thu, Jan 21, 2010 at 2:51 AM, James Lee wrote: > On 20/01/10, 21:30:04, Philip Brown wrote regarding Re: > [csw-maintainers] maintainers email addrs on packages: >> Umm.. yikes. roles being subscribed to mailing lists, doesnt sound >> like a good idea to me personally. > > ${user}@opencsw.org is already a redirect. ?It's no different. > > but $user at opencsw.org is not publically advertised as a support interface. Remember that we never directly expose maintainer addresses on our web site It makes a difference, spamwise. From phil at bolthole.com Thu Jan 21 18:46:49 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 21 Jan 2010 09:46:49 -0800 Subject: [csw-maintainers] maintainers email addrs on packages In-Reply-To: <4B5796E4.6010701@opencsw.org> References: <4B5796E4.6010701@opencsw.org> Message-ID: On Wed, Jan 20, 2010 at 3:51 PM, Sebastian Kayser wrote: > Philip Brown wrote on 20.01.2010 22:30: >> On Wed, Jan 20, 2010 at 11:09 AM, James Lee wrote: >>> We could also have several people receiving the emails in the case >>> of a maintainer team - or a mailing list. >> >> Hrrrm.. I can ALMOST visualize supporting MULTIPLE email addrs in the >> EMAIL= field of pkginfo. mantis DOES support having multiple people as >> manager of a package. > > No ... please. Let's eventually de-couple our meta information handling > from the bug handling in Mantis - not work it even more deeper into it. > One way or another, we need "one central, official place to record who 'owns' a package". It makes sense that it be a database. Since we ALREADY have a database that keeps track of that sort of thing.. the mantis database... and that information MUST be kept current there.... it doesn't make sense, from the standpoint of "good information management practices" to make another separate database. It would require even more synchronization between things. Simpler is better. From skayser at opencsw.org Thu Jan 21 21:06:36 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 21 Jan 2010 21:06:36 +0100 Subject: [csw-maintainers] maintainers email addrs on packages In-Reply-To: References: <4B5796E4.6010701@opencsw.org> Message-ID: <4B58B3CC.8020006@opencsw.org> Philip Brown wrote on 21.01.2010 18:46: > On Wed, Jan 20, 2010 at 3:51 PM, Sebastian Kayser wrote: >> Philip Brown wrote on 20.01.2010 22:30: >>> On Wed, Jan 20, 2010 at 11:09 AM, James Lee wrote: >>>> We could also have several people receiving the emails in the case >>>> of a maintainer team - or a mailing list. >>> Hrrrm.. I can ALMOST visualize supporting MULTIPLE email addrs in the >>> EMAIL= field of pkginfo. mantis DOES support having multiple people as >>> manager of a package. >> No ... please. Let's eventually de-couple our meta information handling >> from the bug handling in Mantis - not work it even more deeper into it. >> > > One way or another, we need "one central, official place to record who > 'owns' a package". It makes sense that it be a database. One central database, totally agreed. > Since we ALREADY have a database that keeps track of that sort of > thing.. the mantis database... and that information MUST be kept > current there.... it doesn't make sense, from the standpoint of "good > information management practices" to make another separate database. > It would require even more synchronization between things. > Simpler is better. Currently I can't just grant every maintainer global maintainer privileges for easier bug handling in Mantis as it will break the package assignments which are (as of today) also tracked by using the privilege levels in Mantis. In other words, we are at a latent risk of possible meta data breakage because of things gone wrong in a 3rd party bug handling tool. When thinking about a dedicated CSW meta database and Mantis, the only synchronization required that comes to my mind would be a sync of maintainers to the list of people with global maintainer privileges in Mantis (except for the couple of Mantis admin users). Doesn't sound hard to me. Sebastian From phil at bolthole.com Thu Jan 21 21:27:19 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 21 Jan 2010 12:27:19 -0800 Subject: [csw-maintainers] maintainers email addrs on packages In-Reply-To: <4B58B3CC.8020006@opencsw.org> References: <4B5796E4.6010701@opencsw.org> <4B58B3CC.8020006@opencsw.org> Message-ID: On Thu, Jan 21, 2010 at 12:06 PM, Sebastian Kayser wrote: > >> Since we ALREADY have a database that keeps track of that sort of >> thing.. the mantis database... and that information MUST be kept >> current there.... it doesn't make sense, from the standpoint of "good >> information management practices" to make another separate database. >> It would require even more synchronization between things. >> Simpler is better. > > Currently I can't just grant every maintainer global maintainer > privileges for easier bug handling in Mantis err, what? I dont understand why you even bring that up. Maybe you should look again at the mantis database level setup? mantis supports both "global manager" priviledges, and project-specific manager privileges. that's how we do things right now. "proj-specific mananger" == "owner". mantis supports having more than one "proj-specific manager". So there would be no fixes needed to mantis itself. It would need code changes to the package "registration" process,and changes to the "package web page display" code. But both of those things will need changes anyway, if we ever support multiple people "owning" a package. From skayser at opencsw.org Thu Jan 21 22:03:36 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 21 Jan 2010 22:03:36 +0100 Subject: [csw-maintainers] maintainers email addrs on packages In-Reply-To: References: <4B5796E4.6010701@opencsw.org> <4B58B3CC.8020006@opencsw.org> Message-ID: <4B58C128.4090709@opencsw.org> Philip Brown wrote on 21.01.2010 21:27: > On Thu, Jan 21, 2010 at 12:06 PM, Sebastian Kayser wrote: >>> Since we ALREADY have a database that keeps track of that sort of >>> thing.. the mantis database... and that information MUST be kept >>> current there.... it doesn't make sense, from the standpoint of "good >>> information management practices" to make another separate database. >>> It would require even more synchronization between things. >>> Simpler is better. >> Currently I can't just grant every maintainer global maintainer >> privileges for easier bug handling in Mantis > > err, what? I dont understand why you even bring that up. Maintainers can't for example move a bug from a package they own to another package (which they don't own) where the bug might belong to. They are restricted to "their" packages. > Maybe you should look again at the mantis database level setup? > mantis supports both "global manager" priviledges, and > project-specific manager privileges. > that's how we do things right now. "proj-specific mananger" == "owner". > > mantis supports having more than one "proj-specific manager". > > So there would be no fixes needed to mantis itself. > It would need code changes to the package "registration" process,and > changes to the "package web page display" code. Let me try to put it in words again: in Mantis I would like to grant global maintainer privileges to every OpenCSW maintainer so that they can work more freely and more flexible on all bugs and packages. If I do so, Mantis will _automatically_ remove all the project-level maintainer privileges. >From a Mantis privilege perspective the project-level privileges are simply not required any more. However, as we have semantically overloaded these project-level privileges, things fall apart elsewhere: the package to maintainer relationship will vanish. We have seen this happen with Dago when we gave him global privileges. > But both of those things will need changes anyway, if we ever support > multiple people "owning" a package. So while we are at it, the person you called out for (in assistance for refactoring the packages/ and maintainers/ pages) might as well consider to implement a dedicated CSW meta db (meta sounds more heavyweight than it actually is) in order to make things more robust. At least that's what I would hope for, but it's up to him then. Sebastian From phil at bolthole.com Thu Jan 21 22:47:28 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 21 Jan 2010 13:47:28 -0800 Subject: [csw-maintainers] maintainers email addrs on packages In-Reply-To: <4B58C128.4090709@opencsw.org> References: <4B5796E4.6010701@opencsw.org> <4B58B3CC.8020006@opencsw.org> <4B58C128.4090709@opencsw.org> Message-ID: On Thu, Jan 21, 2010 at 1:03 PM, Sebastian Kayser wrote: > > Let me try to put it in words again: in Mantis I would like to grant > global maintainer privileges to every OpenCSW maintainer so that they > can work more freely and more flexible on all bugs and packages. oh. well, that's an entirely different matter. >If I do > so, Mantis will _automatically_ remove all the project-level maintainer > privileges. However, if you were to plan this, you could easily make a database backup of existing maintainer privs, then do the change, then reapply the individual-project flags afterwards in one batch one. That being said.... IF we were to do this, it would be then more rational to retire the whole "individual project manager" paradigm. HOWEVER.... that has other side effects. Such as, how to separate "people who have global ability to do [stuff like move bugs around]". vs people who are REALLY supposed to be "global admins" ? Woudl be nicer if there were simply the ability to enable "transfer bugs to other proj" in mantis without having to give global admin. >> But both of those things will need changes anyway, if we ever support >> multiple people "owning" a package. > > So while we are at it, the person you called out for (in assistance for > refactoring the packages/ and maintainers/ pages) might as well consider > to implement a dedicated CSW meta db (meta sounds more heavyweight than > it actually is) in order to make things more robust. At least that's > what I would hope for, but it's up to him then. Eh.. technically, we already have a per-package database in existance for other reasons, so it would in reality most likely mean going back to using that as the canonical place for "who owns a package?" From maciej at opencsw.org Fri Jan 22 09:07:00 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 22 Jan 2010 08:07:00 +0000 Subject: [csw-maintainers] Distributing a Python library with GAR, pkgutil, and others Message-ID: When I started writing Python code for OpenCSW such as comparepkg, submitpkg and build_sun_catalog, I started extracting common classes and functions into a library, which is now named opencsw.py: https://opencsw.svn.sourceforge.net/svnroot/opencsw/utilities/ The idea behind a library is to reuse code. I'd like now to use opencsw.py for checkpkg, but I don't know what's the best way of distributing it. For it to be distributed the same way that GAR is, I'd have to make a copy and commit it to the gar repository. Otherwise, I could make a package and make GAR depend on it. But this would make it more difficult to develop the library, because I'd have to go through the long cycle of develop-test-release-install. When I'm developing something relying on opencsw.py, I'm usually also updating the library and adding new functions, so freezing it would be a problem for development. I could add a svn:externals to mgar/v2/... but this would mean that each time a code checkout/update is make, two slow and annoying svn:externals are downloaded. I'd like to avoid that. To recap: - make a copy of the file - easy to do now, but hard to maintain in the future - make a package - makes it hard to develop code - svn:externals - easy to do, easy to develop and easy to maintain, but slow/annoying for people to use Do you have any other/better ideas? Maciej From bwalton at opencsw.org Fri Jan 22 16:06:41 2010 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 22 Jan 2010 10:06:41 -0500 Subject: [csw-maintainers] Distributing a Python library with GAR, pkgutil, and others In-Reply-To: References: Message-ID: <1264172665-sup-6689@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Fri Jan 22 03:07:00 -0500 2010: > I could add a svn:externals to mgar/v2/... but this would mean that > each time a code checkout/update is make, two slow and annoying > svn:externals are downloaded. I'd like to avoid that. Please no! :) > To recap: > - make a copy of the file - easy to do now, but hard to maintain in > the future > - make a package - makes it hard to develop code > - svn:externals - easy to do, easy to develop and easy to maintain, > but slow/annoying for people to use This is the same problem that GAR as a whole faces. I don't have a good answer and as you know, we simply treat GAR as an in-flight object...until we nail down something for GAR, I'd suggest just sticking it with the rest of the mgar/ tree. When we solve the GAR problem (have a stabilized tool that can be packaged), we could re-evaluate then. Not likely much help, but that's my $0.02 CDN. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. From phil at bolthole.com Fri Jan 22 19:31:56 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 22 Jan 2010 10:31:56 -0800 Subject: [csw-maintainers] Distributing a Python library with GAR, pkgutil, and others In-Reply-To: <1264172665-sup-6689@ntdws12.chass.utoronto.ca> References: <1264172665-sup-6689@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Jan 22, 2010 at 7:06 AM, Ben Walton wrote: > > This is the same problem that GAR as a whole faces. ?I don't have a > good answer and as you know, we simply treat GAR as an in-flight > object...until we nail down something for GAR, I'd suggest just > sticking it with the rest of the mgar/ tree. ?When we solve the GAR > problem (have a stabilized tool that can be packaged), we could > re-evaluate then. > Aaaand.. who is working on that, and when is it estimated to happen? [as far as I know, "no-one", and "never" :-( ] Perhaps, Maciej, this might give you a little motivation to work on that problem as well? kill two birds with one stone? ;-) From bwalton at opencsw.org Fri Jan 22 19:43:58 2010 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 22 Jan 2010 13:43:58 -0500 Subject: [csw-maintainers] Distributing a Python library with GAR, pkgutil, and others In-Reply-To: References: <1264172665-sup-6689@ntdws12.chass.utoronto.ca> Message-ID: <1264185435-sup-3518@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Jan 22 13:31:56 -0500 2010: > [as far as I know, "no-one", and "never" :-( ] Dago did some preliminary work on this, but I don't know where it stands. It's a fast moving target at times though, so a package for it could be quite annoying. Having it tracked via svn makes it lighter on its feet...if we could track it as a package _and_ keep it easy to keep updated, that'd be ideal. The lag for mirrors, or the overhead of a manual install is what makes it less than ideal as a package. In some ways it's like automake and friends. My box here has 1.11, but if I want to fiddle with coreutils to compare something between solaris and linux, it yells and says I need 1.11.1. It's a bleeding edge kind of dev tool. > Perhaps, Maciej, this might give you a little motivation to work on > that problem as well? kill two birds with one stone? ;-) Great if so, but it's not a simple problem to solve nicely for all that use it. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Fri Jan 22 20:03:17 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 22 Jan 2010 11:03:17 -0800 Subject: [csw-maintainers] Distributing a Python library with GAR, pkgutil, and others In-Reply-To: <1264185435-sup-3518@ntdws12.chass.utoronto.ca> References: <1264172665-sup-6689@ntdws12.chass.utoronto.ca> <1264185435-sup-3518@ntdws12.chass.utoronto.ca> Message-ID: On Fri, Jan 22, 2010 at 10:43 AM, Ben Walton wrote: > ... > In some ways it's like automake and friends. ?My box here has 1.11, > but if I want to fiddle with coreutils to compare something between > solaris and linux, it yells and says I need 1.11.1. ?It's a bleeding > edge kind of dev tool. This sounds like a fundamental problem to me. We are in the "business" of making reliable packages. Does it make sense to base that on top of a foundation of a "bleeding edge kind of dev tool"? Perhaps someone with the time,and software development experience, could put together a more formal spec for this beast, and then we can nail it down into a more "productional" form? From william at wbonnet.net Sat Jan 23 12:32:41 2010 From: william at wbonnet.net (William Bonnet) Date: Sat, 23 Jan 2010 12:32:41 +0100 Subject: [csw-maintainers] OpenCSW Winter camp is opened Message-ID: <4B5ADE59.8000206@wbonnet.net> Hi, The OpenCSW Winter Camp in Munich is now opened. All of us are now in the hotel, located in Langries. The first morning of meeting is under progress :) You can follow us on the opencsw twitter http://twitter.com/opencsw cheers W. From skayser at opencsw.org Sat Jan 23 16:38:25 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Sat, 23 Jan 2010 16:38:25 +0100 Subject: [csw-maintainers] OpenCSW Winter camp is opened In-Reply-To: <4B5ADE59.8000206@wbonnet.net> References: <4B5ADE59.8000206@wbonnet.net> Message-ID: <4B5B17F1.30705@opencsw.org> Greetings from Winter Camp! William Bonnet wrote on 23.01.2010 12:32: > The OpenCSW Winter Camp in Munich is now opened. All of us are now in > the hotel, located in Langries. The first morning of meeting is under > progress :) > > You can follow us on the opencsw twitter http://twitter.com/opencsw I just pushed a couple of photos to flickr [1]. More photos plus some words on the proceedings later on today. As always, lots of ideas and things to talk about. We could use one week instead of one weekend, even more with the nice winter weather around us :) Off to more discussions, looking forward to some hacking later on. Sebastian [1] http://www.flickr.com/photos/opencsw/sets/72157623142885671/ From rupert at opencsw.org Sat Jan 23 20:11:30 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 23 Jan 2010 20:11:30 +0100 Subject: [csw-maintainers] OpenCSW Winter camp is opened In-Reply-To: <4B5B17F1.30705@opencsw.org> References: <4B5ADE59.8000206@wbonnet.net> <4B5B17F1.30705@opencsw.org> Message-ID: <6af4271001231111j70f1a415nf9a67128373a6b48@mail.gmail.com> On Sat, Jan 23, 2010 at 16:38, Sebastian Kayser wrote: > Greetings from Winter Camp! > > William Bonnet wrote on 23.01.2010 12:32: >> The OpenCSW Winter Camp in Munich is now opened. All of us are now in >> the hotel, located in Langries. The first morning of meeting is under >> progress :) >> >> You can follow us on the opencsw twitter http://twitter.com/opencsw > > I just pushed a couple of photos to flickr [1]. More photos plus some > words on the proceedings later on today. As always, lots of ideas and > things to talk about. We could use one week instead of one weekend, even > more with the nice winter weather around us :) Off to more discussions, > looking forward to some hacking later on. > > Sebastian > > [1] http://www.flickr.com/photos/opencsw/sets/72157623142885671/ ha many thanks - that makes envie to go there :) your python-vs-perl foto remindet me on an interesting article i saw recently about build tools in general: http://code.google.com/p/waf/wiki/WafAndOtherBuildSystems. i guess gar, mgar would fall into this category as well, isn't it? rupert. From phil at bolthole.com Sat Jan 23 22:22:18 2010 From: phil at bolthole.com (Philip Brown) Date: Sat, 23 Jan 2010 13:22:18 -0800 Subject: [csw-maintainers] OpenCSW Winter camp is opened In-Reply-To: <6af4271001231111j70f1a415nf9a67128373a6b48@mail.gmail.com> References: <4B5ADE59.8000206@wbonnet.net> <4B5B17F1.30705@opencsw.org> <6af4271001231111j70f1a415nf9a67128373a6b48@mail.gmail.com> Message-ID: sounds fun I just hope there will be good notes from this one ;-) From bwalton at opencsw.org Sat Jan 23 22:50:22 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 23 Jan 2010 16:50:22 -0500 Subject: [csw-maintainers] OpenCSW Winter camp is opened In-Reply-To: References: <4B5ADE59.8000206@wbonnet.net> <4B5B17F1.30705@opencsw.org> <6af4271001231111j70f1a415nf9a67128373a6b48@mail.gmail.com> Message-ID: <1264283356-sup-2482@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Sat Jan 23 16:22:18 -0500 2010: > sounds fun > I just hope there will be good notes from this one ;-) For the few minutes I've been able to browse, the google wave that has been active is pretty decent. Of course, someone will need to export (publish to blog or dump to alternate format) since you need a wave account to view it presently. -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 Sun Jan 24 01:21:12 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 24 Jan 2010 01:21:12 +0100 Subject: [csw-maintainers] OpenCSW Winter camp is opened In-Reply-To: <4B5B17F1.30705@opencsw.org> References: <4B5ADE59.8000206@wbonnet.net> <4B5B17F1.30705@opencsw.org> Message-ID: <4B5B9278.90308@opencsw.org> Sebastian Kayser wrote on 23.01.2010 16:38: > William Bonnet wrote on 23.01.2010 12:32: >> The OpenCSW Winter Camp in Munich is now opened. All of us are now in >> the hotel, located in Langries. The first morning of meeting is under >> progress :) >> >> You can follow us on the opencsw twitter http://twitter.com/opencsw > > I just pushed a couple of photos to flickr [1]. More photos plus some > words on the proceedings later on today. As always, lots of ideas and > things to talk about. We could use one week instead of one weekend, even > more with the nice winter weather around us :) Off to more discussions, > looking forward to some hacking later on. Won't get any written proceedings out of the door today (my brain feels like after a core meltdown), but if someone with a webcam wants to join in and say "hello" on short notice, we still have a camcorder sitting on the table and are likely to sit around for another hour hacking on things. Either iChat, Google Talk, or Skype should be fine. Just drop by on #opencsw on freenode and ping me (skayser). Sebastian From maciej at opencsw.org Sun Jan 24 15:17:43 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 24 Jan 2010 14:17:43 +0000 Subject: [csw-maintainers] Wintercamp minutes in Google Wave Message-ID: I've shared the Wintercamp waves with a newly created Google Group, called opencsw-maintainers. People who would like to read the wave, can join this group, using Google accounts. When people have joined the group, they can go to http://wave.google.com - the wave should be in your wave inboxes. The access to the waves will be read/write, so all members will be able to continue the discussions started on the Wintercamp, and there's a bunch of pretty interesting ones there. There are 2 waves from 2 days, containing a transcript of the discussions during the meetings. We'll also provide a read-only export, but we don't know yet what will be the exact way, perhaps a HTML or a PDF file. Maciej [1] https://groups.google.com/group/opencsw-maintainers From ihsan at opencsw.org Sun Jan 24 20:11:17 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 24 Jan 2010 20:11:17 +0100 Subject: [csw-maintainers] Ganglia for sparcv9 In-Reply-To: <4B53BBA5.6010607@opencsw.org> References: <4AE87999.6020401@opencsw.org> <777D637C-111E-4F5B-8562-501B9F42351E@opencsw.org> <4B48FA2F.2020806@opencsw.org> <4B538451.7030002@opencsw.org> <4B53BBA5.6010607@opencsw.org> Message-ID: <4B5C9B55.2090409@opencsw.org> Hello Roger, Am 18.01.10 02:38, schrieb Roger H?kansson: >> I'm running into a problem with Pango. We discussed this issue here >> before, but I don't remember how it ended. >> >> http://pastebin.ca/1755178 >> > > The lib does contain what you need, but I'm pretty sure that if you > check config.log you will find that every test have failed due to: > > Undefined first referenced > symbol in file > XSolarisIASetProcessInfo /usr/openwin/lib/libX11.so.4 > > The problem is related to what I wrote last week regarding libcairo. > > Until the libcairo-problem is fixed, you might be able to get around it > by adding this to your Makefile > > EXTRA_SOS_LD_FLAGS = -L$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) > CONFIGURE_ARGS += --x-includes=$(prefix)/X11/include > CONFIGURE_ARGS += --x-libraries=$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) > > Using those changes I'm able to build rrdtool using what's in GAR. Thanks for your help. Unfortunately, I was not able to build rrdtool on Solaris 9 with Studio 12 http://www.pastebin.ca/1764263 . Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Sun Jan 24 20:48:39 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 24 Jan 2010 20:48:39 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B54D11F.3000608@opencsw.org> <1263850046-sup-8178@ntdws12.chass.utoronto.ca> Message-ID: <4B5CA417.5060708@opencsw.org> Am 18.01.10 23:36, schrieb Maciej (Matchek) Blizinski: >>> newpkgs exists already: https://lists.opencsw.org/mailman/listinfo/newpkgs >> >> pkgreleases ? > > The existing newpkgs list sounds like it really means pkgreleases, > perhaps it could be renamed. (can you move list archives too?) > > The new list would be something along the lines of pkgsubmissions > (which is long, but descriptive). newpkgs will be renamed to pkgsubmissions. newpkgs will be the new lists name? Is that fine for everybody? Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From skayser at opencsw.org Sun Jan 24 21:48:45 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 24 Jan 2010 21:48:45 +0100 Subject: [csw-maintainers] Ganglia for sparcv9 In-Reply-To: <4B5C9B55.2090409@opencsw.org> References: <4AE87999.6020401@opencsw.org> <777D637C-111E-4F5B-8562-501B9F42351E@opencsw.org> <4B48FA2F.2020806@opencsw.org> <4B538451.7030002@opencsw.org> <4B53BBA5.6010607@opencsw.org> <4B5C9B55.2090409@opencsw.org> Message-ID: <4B5CB22D.4050207@opencsw.org> Ihsan Dogan wrote on 24.01.2010 20:11: > Am 18.01.10 02:38, schrieb Roger H?kansson: > >>> I'm running into a problem with Pango. We discussed this issue here >>> before, but I don't remember how it ended. >>> >>> http://pastebin.ca/1755178 >>> >> The lib does contain what you need, but I'm pretty sure that if you >> check config.log you will find that every test have failed due to: >> >> Undefined first referenced >> symbol in file >> XSolarisIASetProcessInfo /usr/openwin/lib/libX11.so.4 >> >> The problem is related to what I wrote last week regarding libcairo. >> >> Until the libcairo-problem is fixed, you might be able to get around it >> by adding this to your Makefile >> >> EXTRA_SOS_LD_FLAGS = -L$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) >> CONFIGURE_ARGS += --x-includes=$(prefix)/X11/include >> CONFIGURE_ARGS += --x-libraries=$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) >> >> Using those changes I'm able to build rrdtool using what's in GAR. > > Thanks for your help. Unfortunately, I was not able to build rrdtool on > Solaris 9 with Studio 12 http://www.pastebin.ca/1764263 . The crucial part from the pastebin is this one ... "rrd_restore.c", line 19: cannot find include file: ... Let's see where this file lives (/q ceeswi on freenode). 21:40 fsearch xmlreader.h 21:41 [libxml2_devel] /opt/csw/include/libxml2/libxml/xmlreader.h Change your EXTRA_INC in the GAR Makefile from EXTRA_INC += $(prefix)/include/libxml2/libxml to EXTRA_INC += $(prefix)/include/libxml2 and you should be fine. Sebastian From jeff at cjsa.com Mon Jan 25 05:54:55 2010 From: jeff at cjsa.com (Jeffery Small) Date: Mon, 25 Jan 2010 04:54:55 GMT Subject: [csw-maintainers] curlrt Message-ID: When I just updated my catalog, I find the following: curl_rt 7.19.7,REV=2010.01.15 curlrt 7.19.7,REV=2010.01.15 7.19.7,REV=2009.11.05 Notice that the curl package in the catalog is older than the installed package? Hmmmm, how did this happen. I previously uninstalled curlrt and then installed the new curl_rt package. So let's try again. I first uninstalled curlrt and then I look and curl_rt is also gone??? So I reinstall curl_rt and I see that both curlrt and curl_rt are once again listed as noted above. So what's up? Why does curlrt get listed and why is it still showing up in the catalog as an older version? Is this expected behavior or is something wrong with the install files which is mixing these two names improperly? Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From dam at opencsw.org Mon Jan 25 08:55:00 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 25 Jan 2010 08:55:00 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: <4B5CA417.5060708@opencsw.org> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B54D11F.3000608@opencsw.org> <1263850046-sup-8178@ntdws12.chass.utoronto.ca> <4B5CA417.5060708@opencsw.org> Message-ID: <0444857F-28B4-437A-BF36-939AAB277B77@opencsw.org> Hi Ihsan, Am 24.01.2010 um 20:48 schrieb Ihsan Dogan: > Am 18.01.10 23:36, schrieb Maciej (Matchek) Blizinski: >>>> newpkgs exists already: https://lists.opencsw.org/mailman/listinfo/newpkgs >>> >>> pkgreleases ? >> >> The existing newpkgs list sounds like it really means pkgreleases, >> perhaps it could be renamed. (can you move list archives too?) >> >> The new list would be something along the lines of pkgsubmissions >> (which is long, but descriptive). > > newpkgs will be renamed to pkgsubmissions. > newpkgs will be the new lists name? > > Is that fine for everybody? I would prefer pkgreleases over pkgsubmissions as they more tend to go out than go in after that email. The new name is perfect. Best regards -- Dago From dam at opencsw.org Mon Jan 25 09:01:12 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 25 Jan 2010 09:01:12 +0100 Subject: [csw-maintainers] Problem: curlrt and curldevel still in the catalog In-Reply-To: References: Message-ID: Hi Jeffery, Am 25.01.2010 um 05:54 schrieb Jeffery Small: > When I just updated my catalog, I find the following: > > curl_rt 7.19.7,REV=2010.01.15 > curlrt 7.19.7,REV=2010.01.15 > 7.19.7,REV=2009.11.05 > > Notice that the curl package in the catalog is older than the > installed > package? > > Hmmmm, how did this happen. I previously uninstalled curlrt and then > installed the new curl_rt package. In theory this should not have been necessary as only the catalog name changed, not the package name. > So let's try again. I first > uninstalled curlrt and then I look and curl_rt is also gone??? > > So I reinstall curl_rt and I see that both curlrt and curl_rt are once > again listed as noted above. So what's up? Why does curlrt get > listed and > why is it still showing up in the catalog as an older version? > > Is this expected behavior or is something wrong with the install > files which > is mixing these two names improperly? dam at login [login]:/export/mirror/opencsw/current/sparc/5.8 > grep ^curl catalog curl 7.19.7,REV=2010.01.15 CSWcurl curl-7.19.7,REV=2010.01.15-SunOS5.8- sparc-CSW.pkg.gz 97acef51f585128c058e975270b489d9 107178 CSWcommon| CSWiconv|CSWlibidn|CSWlibnet|CSWoldaprt|CSWosslrt|CSWsasl|CSWzlib| CSWcurlrt none curl_devel 7.19.7,REV=2010.01.15 CSWcurldevel curl_devel-7.19.7,REV=2010.01.15-SunOS5.8-sparc-CSW.pkg.gz fde89710be8854e1bdd6d0ee4df2aa7a 130094 CSWcommon|CSWcurlrt none curl_rt 7.19.7,REV=2010.01.15 CSWcurlrt curl_rt-7.19.7,REV=2010.01.15- SunOS5.8-sparc-CSW.pkg.gz 7f4f391a1dafea8f5449ffb86f78b631 622538 CSWcommon|CSWlibidn|CSWlibnet|CSWoldaprt|CSWosslrt|CSWzlib|CSWsasl none curldevel 7.19.7,REV=2009.11.05 CSWcurldevel curldevel-7.19.7,REV=2009.11.05-SunOS5.8-sparc-CSW.pkg.gz dfc58af319883ddd9e66158eb2ae6f21 131730 CSWcurlrt|CSWcommon none curlrt 7.19.7,REV=2009.11.05 CSWcurlrt curlrt-7.19.7,REV=2009.11.05- SunOS5.8-sparc-CSW.pkg.gz f07ae1725636672cf126a9f6a248f53f 622453 CSWlibidn|CSWlibnet|CSWoldaprt|CSWosslrt|CSWzlib|CSWsasl|CSWcommon none There is still curlrt and curldevel in the catalog which should have been gone after the rename. Phil: Would you mind having a look and remove the previous packages from the catalog? Thanks for the report! Best regards -- Dago From bonivart at opencsw.org Mon Jan 25 09:39:13 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 25 Jan 2010 09:39:13 +0100 Subject: [csw-maintainers] Problem: curlrt and curldevel still in the catalog In-Reply-To: References: Message-ID: <625385e31001250039t3cc6b640j30913936d99832d9@mail.gmail.com> On Mon, Jan 25, 2010 at 9:01 AM, Dagobert Michelsen wrote: > There is still curlrt and curldevel in the catalog which should have been > gone > after the rename. This was easily picked up by chkcat: ERROR! CSWcurldevel exists more than once. ERROR! CSWcurlrt exists more than once. -- /peter From skayser at opencsw.org Mon Jan 25 11:27:04 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 25 Jan 2010 11:27:04 +0100 Subject: [csw-maintainers] Problem: curlrt and curldevel still in the catalog In-Reply-To: <625385e31001250039t3cc6b640j30913936d99832d9@mail.gmail.com> References: <625385e31001250039t3cc6b640j30913936d99832d9@mail.gmail.com> Message-ID: <4B5D71F8.3040708@opencsw.org> Peter Bonivart wrote on 25.01.2010 09:39: > On Mon, Jan 25, 2010 at 9:01 AM, Dagobert Michelsen wrote: >> There is still curlrt and curldevel in the catalog which should have been >> gone >> after the rename. > > This was easily picked up by chkcat: > > ERROR! CSWcurldevel exists more than once. > ERROR! CSWcurlrt exists more than once. Could it be hooked into the release process then to avoid such errors in the future? Sebastian From hson at opencsw.org Mon Jan 25 16:14:46 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Mon, 25 Jan 2010 16:14:46 +0100 Subject: [csw-maintainers] Question regarding package naming, merging... Message-ID: <4B5DB566.6020302@opencsw.org> Any thoughts regarding the naming and possible merging of packages? Example: libsoup Today we have a libsoup package which is version 1.99 and a libsoup2 which is 2.2 I'm about to release a new libsoup package (2.4) which will include libraries from old libsoup and libsoup2 packages (for backwards compatibility until packages depending on the old ones are rereleased) plus a libsoup2 package which is really just a dummy with a dependency to libsoup so the dependency chain isn't broken. But then I started thinking that this might need some input from some others, specially since there are lot of other packages that face similar problems. What is the recommended package naming scheme? Should our packages follow the naming scheme from other distributions (either Linux or other) "to the letter" or is it more a "is possible") The reason why I ask is that if we were to follow other dists a libsoup24 would be the logical naming, but I find it rather silly to have that name when no other libsoup package exists. (When the packages depending on the older versions have been upgraded, there is no need to keep the old packages and we certainly don't want anyone building new packages using the old stuff) The same applies to other packages where there might be a package called vfshN(N=2,3..) but there is no longer any package called vfsh (or even if there is such a package, it is so old we really don't want anyone using it for releasing new packages) Comments? From dam at opencsw.org Mon Jan 25 16:21:28 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 25 Jan 2010 16:21:28 +0100 Subject: [csw-maintainers] Alternatives In-Reply-To: <1261181863-sup-5150@ntdws12.chass.utoronto.ca> References: <4B2C021B.50800@opencsw.org> <1261181863-sup-5150@ntdws12.chass.utoronto.ca> Message-ID: <273FAD65-E364-49BB-B29C-B21B45A3BCE1@opencsw.org> Hi, Am 19.12.2009 um 01:27 schrieb Ben Walton: > Excerpts from Philip Brown's message of Fri Dec 18 17:44:17 -0500 > 2009: > >> by that argument, you might say that me naming "pkg-get" as such, and >> not "apt-get", was just too confusing, because since the userland >> syntax is the same, and it IS a 90% clone of apt-get, I should have >> kept the name as apt-get. > > The difference being pkg-get is an apt-get workalike. The package > Maciej has put forward is the 'real deal[1].' > > While the name used in Debian is long and annoying to type, even with > auto-completion, it's really not something you interact with often, if > at all. > > So, my 'vote' is that if we don't do a ground up reimplementation, we > stick with the name from Debian. If somebody wants to invest the time > tailoring a solution to CSW, pick a new name. > > > Is anyone else out there not making use of auto-completion shell > features? Life feels too short for that! :) > > > -Ben > > [1] It's the identical code/functionality split out from a larger > Debian package. +1 from me and it is still not released. Could we please get on with this? I need this for at least two packages (mutt and especially automake), both pending release. Best regards -- Dago From maciej at opencsw.org Mon Jan 25 17:04:29 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 25 Jan 2010 16:04:29 +0000 Subject: [csw-maintainers] newpkgs alternatives (was Re: Alternatives) Message-ID: On Mon, Jan 25, 2010 at 3:21 PM, Dagobert Michelsen wrote: > Hi, > > Am 19.12.2009 um 01:27 schrieb Ben Walton: >> >> Excerpts from Philip Brown's message of Fri Dec 18 17:44:17 -0500 2009: >> >>> by that argument, you might say that me naming "pkg-get" as such, and >>> not "apt-get", was just too confusing, because since the userland >>> syntax is the same, and it IS a 90% clone of apt-get, I should have >>> kept the name as apt-get. >> >> The difference being pkg-get is an apt-get workalike. ?The package >> Maciej has put forward is the 'real deal[1].' >> >> While the name used in Debian is long and annoying to type, even with >> auto-completion, it's really not something you interact with often, if >> at all. >> >> So, my 'vote' is that if we don't do a ground up reimplementation, we >> stick with the name from Debian. ?If somebody wants to invest the time >> tailoring a solution to CSW, pick a new name. >> >> >> Is anyone else out there not making use of auto-completion shell >> features? ?Life feels too short for that! :) >> >> >> -Ben >> >> [1] It's the identical code/functionality split out from a larger >> ? Debian package. > > +1 from me and it is still not released. Could we please get on with this? > I need this for at least two packages (mutt and especially automake), > both pending release. Here's the submission message then. Since the new mailing list hasn't been created yet, I'm using the maintainers list instead. * new package: alternatives + alternatives-1.15.5.3,REV=2009.12.10-SunOS5.8-all-CSW.pkg.gz -- $Id: opencsw.py 113 2010-01-11 12:08:24Z wahwah $ From Joerg.Schilling at fokus.fraunhofer.de Mon Jan 25 17:18:24 2010 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Mon, 25 Jan 2010 17:18:24 +0100 Subject: [csw-maintainers] OpenCSW Winter camp is opened In-Reply-To: <6af4271001231111j70f1a415nf9a67128373a6b48@mail.gmail.com> References: <4B5ADE59.8000206@wbonnet.net> <4B5B17F1.30705@opencsw.org> <6af4271001231111j70f1a415nf9a67128373a6b48@mail.gmail.com> Message-ID: <4b5dc450.uv4QV5JgzToX/gWK%Joerg.Schilling@fokus.fraunhofer.de> rupert THURNER wrote: > your python-vs-perl foto remindet me on an interesting article i saw > recently about build tools in general: > http://code.google.com/p/waf/wiki/WafAndOtherBuildSystems. i guess > gar, mgar would fall into this category as well, isn't it? Mmmm they don't mention the "Schily makefile system"..... J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From phil at bolthole.com Mon Jan 25 17:40:03 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 25 Jan 2010 08:40:03 -0800 Subject: [csw-maintainers] Problem: curlrt and curldevel still in the catalog In-Reply-To: <4B5D71F8.3040708@opencsw.org> References: <625385e31001250039t3cc6b640j30913936d99832d9@mail.gmail.com> <4B5D71F8.3040708@opencsw.org> Message-ID: On Mon, Jan 25, 2010 at 2:27 AM, Sebastian Kayser wrote: > Peter Bonivart wrote on 25.01.2010 09:39: >> On Mon, Jan 25, 2010 at 9:01 AM, Dagobert Michelsen wrote: >>> There is still curlrt and curldevel in the catalog which should have been >>> gone >>> after the rename. >> >> This was easily picked up by chkcat: >> >> ERROR! CSWcurldevel exists more than once. >> ERROR! CSWcurlrt exists more than once. > > Could it be hooked into the release process then to avoid such errors in > the future? > yah i'll do that. From phil at bolthole.com Mon Jan 25 17:59:39 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 25 Jan 2010 08:59:39 -0800 Subject: [csw-maintainers] Question regarding package naming, merging... In-Reply-To: <4B5DB566.6020302@opencsw.org> References: <4B5DB566.6020302@opencsw.org> Message-ID: Hi Roger, First of all, thanks for giving this issue so much thought. To best answer your question, I think the simple core fact will be the answer to the question; - Once you release a NEW libsoup(24), will there be any desire to compile against the older version? If no, then your current plan, of "update, keep old shared libs in for compatibility until not needed any more", is just fine. it's our standard way of doing these things. I think you already have answered "no we dont want to compile against older versions", so go right ahead. From phil at bolthole.com Mon Jan 25 18:00:18 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 25 Jan 2010 09:00:18 -0800 Subject: [csw-maintainers] Question regarding package naming, merging... In-Reply-To: References: <4B5DB566.6020302@opencsw.org> Message-ID: oops. i think perhaps my last email was ambiguous. so to be perfectly clear: go ahead and release "libsoup 2.4" as "libsoup2". From bonivart at opencsw.org Mon Jan 25 18:15:42 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 25 Jan 2010 18:15:42 +0100 Subject: [csw-maintainers] Problem: curlrt and curldevel still in the catalog In-Reply-To: References: <625385e31001250039t3cc6b640j30913936d99832d9@mail.gmail.com> <4B5D71F8.3040708@opencsw.org> Message-ID: <625385e31001250915t66884482n54b2c09071205e2f@mail.gmail.com> On Mon, Jan 25, 2010 at 5:40 PM, Philip Brown wrote: > On Mon, Jan 25, 2010 at 2:27 AM, Sebastian Kayser wrote: >> Peter Bonivart wrote on 25.01.2010 09:39: >>> On Mon, Jan 25, 2010 at 9:01 AM, Dagobert Michelsen wrote: >>>> There is still curlrt and curldevel in the catalog which should have been >>>> gone >>>> after the rename. >>> >>> This was easily picked up by chkcat: >>> >>> ERROR! CSWcurldevel exists more than once. >>> ERROR! CSWcurlrt exists more than once. >> >> Could it be hooked into the release process then to avoid such errors in >> the future? >> > > yah i'll do that. I recommend using the -e option for errors only, otherwise it will warn about, e.g., packages without REV and so on. # chkcat -e /path/to/catalog If you want to use it in a script you can use -q for no output and only return codes. 0 for no problems, 1 for warnings and 2 for errors found. # chkcat -q /path/to/catalog # echo $? 2 There's also a simple man page for chkcat. -- /peter From phil at bolthole.com Mon Jan 25 19:25:48 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 25 Jan 2010 10:25:48 -0800 Subject: [csw-maintainers] new mailing list? In-Reply-To: <4B5CA417.5060708@opencsw.org> References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B54D11F.3000608@opencsw.org> <1263850046-sup-8178@ntdws12.chass.utoronto.ca> <4B5CA417.5060708@opencsw.org> Message-ID: On Sun, Jan 24, 2010 at 11:48 AM, Ihsan Dogan wrote: > > newpkgs will be renamed to pkgsubmissions. > newpkgs will be the new lists name? > > Is that fine for everybody? > > No it is not. "newpkgs", is at this point, a long established "customer facing api". It has been out there *for years*. Because of that, I think we should not change it. For those who care: there are 375 people currently subscribed to the existing "newpkgs" mailing list. It would not be good "customer service" to force all those people to change. We should especially not take the old name, and use it for something completely opposite. If we are busy renaming, and we want consistency, then lets rename the internal interfaces only. We can rename the "newpkgs" directory to something,and then create a new mailing list with the same name? From phil at opencsw.org Mon Jan 25 18:29:10 2010 From: phil at opencsw.org (Philip Brown) Date: Mon, 25 Jan 2010 09:29:10 -0800 Subject: [csw-maintainers] newpkgs alternatives (was Re: Alternatives) In-Reply-To: References: Message-ID: On Mon, Jan 25, 2010 at 8:04 AM, Maciej (Matchek) Blizinski wrote: > > > Here's the submission message then. ?Since the new mailing list hasn't > been created yet, I'm using the maintainers list instead. > > * new package: alternatives > ?+ alternatives-1.15.5.3,REV=2009.12.10-SunOS5.8-all-CSW.pkg.gz > > Dont do that please. Nor anyone else. I think it's safe to say that 9 out of 10 maintainers do NOT want that kind of spam on the maintainers list. Please just stick to the usual way, until the new list is set up. I'll look at the package today. From maciej at opencsw.org Mon Jan 25 21:50:44 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 25 Jan 2010 20:50:44 +0000 Subject: [csw-maintainers] On examining proposals (was: new mailing list?) Message-ID: On Tue, Jan 19, 2010 at 5:24 PM, Philip Brown wrote: >>It's a classic example when somebody makes a proposal, the vast >>majority of maintainers support the idea, Phil says no, and the topic >>dies a quiet death. ?I would like this not to happen any more. > > > I will mention here that the most common reason for this sort of > cycle, is that I point out potential problems in the proposal, and > no-one can come up with decent fixes for the problems in the proposal > that I bring up. > So then the flawed proposal dies. And in a logically based system, > that is a GOOD thing. > Flawed proposals SHOULD "die a quiet death". Not every proposal should > succeed; even > initially popular ones. > > > That being said... I didnt even say "no this list should not be > created or used". > I only pointed out that it wont fully achieve specific things that Ben > stated he thought it would do. > > It was nice to see that on this proposal, people actually replied to > my comments in a useful manner, calmly and rationally. This is GOOD! I > LIKE this! :-) My goal is not "stop all proposals", but only "point > out any flaws in them that I can see". If people actually address > those flaws, then I will cheerfully support a proposal I may have been > initially against. I'm glad that this thread touched on the proposal examination topic. It's also related to one of Sebastian's e-mails[1] and relevant to the last post in the alternatives topic (the one cc'd to board@). You mention that I haven't responded to the issues that you've raised about the alternatives package. This is true, I haven't responded to them, and I've submitted the package for release without any changes and without further technical discussions. This is mostly because I've lost my faith in technical discussions such as the one about alternatives. I'll try to explain why. I'll start with pointing out some assumptions, that, as I understand, linger behind any discussion over a proposal. The first one is that you, Phil Brown, are in the central decision making position. I haven't seen it written anywhere, but from how I see things are working around here, it's pretty clear that if you say "yes", it happens, and if you say "no", it doesn't. I'm not sure if the leadership position is something you consciously aimed for, or something that by itself emerged out of the chaos, but in either case, from all the people in OpenCSW, you seem to have the most power in stopping things from happening. You said that the proposals die when you point out potential problems in the proposal, and no one can come up with decent fixes. That's correct, you do point out potential problems, and in most cases the issues you raise are valid in the sense that they are sentences which indeed seem to be logically true. For instance, that "update-alternatives" is a long word to type. This is something that could be in some context described as a flaw, and could be potentially addressed by providing a shorter name. In the case of the mailing list, you indeed haven't said that "no, this list should not be created or used". But I don't think that it's possible, in your position, to avoid this context and this implicit meaning, when you point out potential problems. When you write "here is flaw A" and it's hard to solve, it pretty much means that the proposal won't pass. I know that it's frustrating when any message you write can have implicit meanings that you haven't intended. Language is ambiguous. Smileys can help, but if you input a smiley, it's still ambiguous: do you smile because you're friendly, or is it an ironic smirk? If someone reads the smiley the later way, you're unlikely to see them cooperating with you in the future. However, there's a bunch of specific implicit interpretations of your messages, that you can pretty safely assume to be there, especially considering that you're a release manager. One of the way to interpret them is the search for a potential answer to the question: "does Phil approve of the proposal or does he not?", and "what is there to be done before Phil accepts the proposal?" I'm sure that people read and carefully consider all the potential problems that you point out. In some cases they respond and this leads to the improvement of the proposal, but there are multiple ways in which this process can go wrong. If the back-and-forth discussion goes on for too long, and new issues are introduced when the old ones are resolved, the proponents of the proposal might get an impression that there are flaws in the flaw search procedure. Or, to put it bluntly, that flaws are being made up all along as necessary, just to keep at least one flaw on the stack, so that the proposal never passes. I'm not saying that this is what actually happens, but this hypothesis is sometimes startlingly consistent with the observation. Once someone gets this impression, it triggers a chain reaction: they don't trust the process any more, they start assuming malevolence of the other party. When it happens, it's hard to undo. Because all the communication is tainted, it loses value. In other words, it doesn't matter any more what any of the sides is saying; the only thing that still matters is what they do. Any pointed out flaws lose any actual technical meaning, they are only seen as just another way of saying "no". After all, flaws are relatively easy to find, no matter how good the proposal is. There will be often a tradeoff situation, and you can keep on always pointing out that negative side of the tradeoff. Given some power, one can make it a game which is impossible to win. This situation is somewhat similar to internet trolling. In trolling, one of the sides abuses the conversation by putting forward disagreeing or otherwise challenging statements only to make the other side uncomfortable and upset. The main difference is that trolling mostly bases itself on the asymmetrical emotional engagement, while in the case of technical proposals that we use to have, it's probably something else. Perhaps asymmetrical technical engagement (one side is dependent on the technology being examined, while the other is not). Or maybe it's about the decision making power. Or both. I understand that the job of a release manager is saying "no". The vital part is to say "no" at the right times, and it takes a lot of effort to be accurate in it. It's very, very important to foresee any potential problems, as fixing a problem that has made it outside can take 10-100 times more effort than it would have taken otherwise. This should not be underestimated. It's therefore very important that the people on the receiving end of the "no" understand and accept the reasoning behind it. How to mitigate this communication breakdown problem? I think that the first thing is to bring implicit to the explicit. When a flaw is pointed out, is it put forward as a show stopper or just a side note? It would also help if you, being in the leadership position, to present a summary of the gains and losses from each possible choice, what would be the size of the impact of each potential problem, and what would be the tipping point on the yes/no balance. How many people would be affected by the flaw? Can it be supported by any statistics or estimated numbers? What would be the positive impact of the proposal? What would be the overall outcome for the project? Can there be any other solution that solves the original problem? Of course, you can shrug and say that you don't care about that and if there's a communication problem, you just stop working with the individual in question. Sure, it's one of the things you can do. Maybe it's not worth your time to do research and make more extensive evaluations. Maybe it's not worth your time to work to regaining lost cooperation. But being in the leadership position, you bear a large share of the responsibility to keep the community in a good shape, whether you want it or not. When you consider this thought, don't find flaws on just one side of the argument. Try to see flaws and values on both sides. Or perhaps you'll find a third solution? Maciej [1] http://lists.opencsw.org/pipermail/maintainers/2009-December/005185.html From phil at bolthole.com Mon Jan 25 22:26:11 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 25 Jan 2010 13:26:11 -0800 Subject: [csw-maintainers] On examining proposals (was: new mailing list?) In-Reply-To: References: Message-ID: Hello Maciej, I have read through your whole email. I will attempt to condense a reply. First of all, thank you for recognizing the responsabilities of the release manager, as a person to "say no, at the right times". I'm also glad that you brought up the issue of *perceived* bias, discouraging people from discussing issues, even when there may be no bias at all. If you doubt whether I am being honest in my technical objections, and suspect that I am merely "stalling" somehow; the solution is very straightforward, although it does require you do some work: find solutions to my objections, and see how I react. You write: >It would also help if you, being in the leadership position, to >present a summary of the gains and losses from each possible choice, >what would be the size of the impact of each potential problem, and >what would be the tipping point on the yes/no balance. How many >people would be affected by the flaw? Can it be supported by any >statistics or estimated numbers? This does not scale well. It should be up to the person making the proposal, to come up with additional numbers, etc to support the proposal. This is completely standard behaviour. Go look at how any "review board" or QA management/release management process works in the "real world". Is it up to the board, or the submitter, to find solutions to any issues that are raised? It is up to the submitter! In the past, occasionally, people have spent the time to do research on numbers as you suggest. Most of the time, the results supported my position :) but sometimes, they have done the opposite,and I have changed my position. > Of course, you can shrug and say that you don't care about that and if > there's a communication problem, you just stop working with the > individual in question. Sure, it's one of the things you can do. > Maybe it's not worth your time to do research and make more extensive > evaluations. I dont just "stop working with the individual". I always wait for them to respond to any issues I have brought up. It is usually the other individual who cannot be bothered to do the extra research, yet puts the blame on me, for not finding the solution, to THEIR proposal. This is not right for them to blame me for not doing their work. In the case of the "alternatives" issue,though, I have actually gone above and beyond my responsabilities, and actually done the work for "the other side". I have looked around, and found another solution, that does EXACTLY what you wanted, yet solves all my objections to it. This is something you could have done yourself, but you chose not to do the work. Even so, I have handed you the solution on a platter. But you still choose not to do the work. Yet now you are blaming me for getting in the way of your proposal ??? It seems to me you are treating me very poorly here. From glaw at opencsw.org Mon Jan 25 23:04:50 2010 From: glaw at opencsw.org (Gary Law) Date: Mon, 25 Jan 2010 22:04:50 +0000 Subject: [csw-maintainers] On examining proposals (was: new mailing list?) In-Reply-To: References: Message-ID: 2010/1/25 Philip Brown : > yet solves all my objections to it And therein lies the problem. It's a one-man veto. It doesn't encourage participation and it doesn't scale (ok, we've two release managers now, but you know what I mean). I've worked on change boards, and no-one ever has veto that can't be overridden. Maintainers should be assumed to know what their doing. If the release manager feels something is seriously substandard, and they can't agree to release it, it should be put to a vote here. But unless it's a complete turkey, I say release early, release often. Think about this in agile terms -- it's software we're dealing with after all. No agile process has a ''now get the agreement to release from the person who may not give his requirements until after you've done all the work'' step in it, for very obvious reasons! Gary -- glaw at opencsw.org From phil at bolthole.com Mon Jan 25 23:17:00 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 25 Jan 2010 14:17:00 -0800 Subject: [csw-maintainers] On examining proposals (was: new mailing list?) In-Reply-To: References: Message-ID: On Mon, Jan 25, 2010 at 2:04 PM, Gary Law wrote: > > Maintainers should be assumed to know what their doing. If the release > manager feels something is seriously substandard, and they can't agree > to release it, it should be put to a vote here. I will point out that, on occasion where I reach a deadlock with a maintainer in my capacity as release manager, I have more than once said, "ok, lets bring this up for discussion on the general list". This doesnt happen very often, however, because by far the vast majority of maintainers recognize that I am bringing up logical points of interest about the package, and they work well with me in discussing potential workarounds, and then the package gets released. For this reason, I am very much in FAVOR of making the package release process public via a new mailing list, so that the more difficult-to-deal-with people can see how easily the process flows, when both people act in a reasonable fashion. From dam at opencsw.org Tue Jan 26 08:20:26 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 26 Jan 2010 08:20:26 +0100 Subject: [csw-maintainers] On examining proposals (was: new mailing list?) In-Reply-To: References: Message-ID: Hi Phil, Am 25.01.2010 um 23:17 schrieb Philip Brown: > On Mon, Jan 25, 2010 at 2:04 PM, Gary Law wrote: >> >> Maintainers should be assumed to know what their doing. If the >> release >> manager feels something is seriously substandard, and they can't >> agree >> to release it, it should be put to a vote here. > > I will point out that, on occasion where I reach a deadlock with a > maintainer in my capacity as release manager, I have more than once > said, "ok, lets bring this up for discussion on the general list". > > This doesnt happen very often, however, because by far the vast > majority of maintainers recognize that I am bringing up logical points > of interest about the package, and they work well with me in > discussing potential workarounds, and then the package gets released. > > For this reason, I am very much in FAVOR of making the package release > process public via a new mailing list, so that the more > difficult-to-deal-with people can see how easily the process flows, > when both people act in a reasonable fashion. There is one more point to it: See, that the overall project comes ahead and regularly ping people who delivered a sub-standard package, see that they get help if needed, see that maybe others take over the package, start work on stubs to get something going. Keep the discussion flowing and see that ideas don't die. We have a plurality of offices here as you are not only the release manager but also the president. You are perfectly well describing what your work as release manager is and how it should be, however, there is an additional task you have taken over. And that requires more than just QA board filtering. Best regards -- Dago From maciej at opencsw.org Tue Jan 26 11:59:47 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 26 Jan 2010 10:59:47 +0000 Subject: [csw-maintainers] GAR: garlinks and testing branches Message-ID: I remember that when Dago was working on alternatives, he asked people to test the new branch. At the time, I didn't test the branch much, I did maybe one build of MySQL with it. The reason was that I thought I had to update svn:externals for every package I wanted to test, or to manage directories by hand. There is a garlinks command which makes "gar" symlinks in all the packages, pointing to mgar/gar/v2. It's a very nice solution, as it makes all the packages use the same directory with GAR sources. However, if one wants to switch the packages to another branch, it's necessary to go through all the directories and change the gar links. How about the following: mgar |-- gar | |-- current -> v2 | `-- v2 `-- pkg `-- foo `-- trunk `-- gar -> ../../../gar/current In this way, it's enough to change one symlink to make all the builds use another branch. This would make testing GAR branches much easier. Thoughts? Maciej From maciej at opencsw.org Tue Jan 26 12:03:11 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 26 Jan 2010 11:03:11 +0000 Subject: [csw-maintainers] GAR: garlinks and testing branches In-Reply-To: References: Message-ID: On Tue, Jan 26, 2010 at 10:59 AM, Maciej (Matchek) Blizinski wrote: > I remember that when Dago was working on alternatives, Um, looks like I can't afford to keep eating out this giraffe[1]. I meant parallel build. [1] http://xkcd.com/604/ From bonivart at opencsw.org Tue Jan 26 22:27:49 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 26 Jan 2010 22:27:49 +0100 Subject: [csw-maintainers] /testing spamassassin, bind, dhcp, dnstop Message-ID: <625385e31001261327k31719e1bo2bd90963eb99a3d2@mail.gmail.com> I have a few packages in testing and I would like some help testing them. - SpamAssassin 3.3.0, big update, note that no rules are delivered from now on, only sa-update is supported. - BIND 9.6.1-P3, security update. - DHCP 4.1.1, update that should fix the problems some installations had. - dnstop 20090128, a top-like utility for DNS servers. http://mirror.opencsw.org/testing.html -- /peter From skayser at opencsw.org Wed Jan 27 01:39:15 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 27 Jan 2010 01:39:15 +0100 Subject: [csw-maintainers] Wintercamp minutes in Google Wave In-Reply-To: References: Message-ID: <4B5F8B33.6000902@opencsw.org> Maciej (Matchek) Blizinski wrote on 24.01.2010 15:17: > I've shared the Wintercamp waves with a newly created Google Group, > called opencsw-maintainers. People who would like to read the wave, > can join this group, using Google accounts. When people have joined > the group, they can go to http://wave.google.com - the wave should be > in your wave inboxes. The access to the waves will be read/write, so > all members will be able to continue the discussions started on the > Wintercamp, and there's a bunch of pretty interesting ones there. > > There are 2 waves from 2 days, containing a transcript of the > discussions during the meetings. > > We'll also provide a read-only export, but we don't know yet what will > be the exact way, perhaps a HTML or a PDF file. In addition to the Wave minutes, I have now also put down a few rough notes from the first day into the Wiki [1]. These notes are not complete and link to the almost completes ones from the Wave as the Wave pretty much caught the flow of discussions and actions from halfway-through the first day. Anyone who has ever been to one of our camps will know how hard it is to capture the flow of information while at the same time participating in the discussions (a dedicated minute taker might be helpful next time). Maciej did a very good at it though. The picture set on flickr has also seen some additions and now includes 12 pictures [2]. Will upload the full batch for separate download when I return from vacation in two weeks. William, could you also upload your pictures somewhere for us to download them? Sebastian [1] http://opencsw.wikidot.com/wintercamp-2009-minutes [2] http://www.flickr.com/photos/opencsw/sets/72157623142885671/ From dam at opencsw.org Wed Jan 27 10:40:39 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 27 Jan 2010 10:40:39 +0100 Subject: [csw-maintainers] GAR: garlinks and testing branches In-Reply-To: References: Message-ID: Hi Maciej, Am 26.01.2010 um 11:59 schrieb Maciej (Matchek) Blizinski: > I remember that when Dago was working on alternatives, he asked people > to test the new branch. At the time, I didn't test the branch much, I > did maybe one build of MySQL with it. The reason was that I thought I > had to update svn:externals for every package I wanted to test, or to > manage directories by hand. There is a garlinks command which makes > "gar" symlinks in all the packages, pointing to mgar/gar/v2. It's a > very nice solution, as it makes all the packages use the same > directory with GAR sources. However, if one wants to switch the > packages to another branch, it's necessary to go through all the > directories and change the gar links. > > How about the following: > > mgar > |-- gar > | |-- current -> v2 > | `-- v2 > `-- pkg > `-- foo > `-- trunk > `-- gar -> ../../../gar/current > > In this way, it's enough to change one symlink to make all the builds > use another branch. This would make testing GAR branches much easier. > Thoughts? This breaks the usecase of tagging trunk by just copying it. And it would be impossible to check out a single package with "svn co". The testing is a transient process and I would prefer to then introduce some script like setgar current/v2-testfeature pkg/*/trunk which would just reset links to the specified one without touching the svn:externals. Best regards -- Dago From maciej at opencsw.org Wed Jan 27 14:51:59 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 27 Jan 2010 13:51:59 +0000 Subject: [csw-maintainers] Changes in checkpkg might potentially cause issues Message-ID: Hello maintainers, I've shuffled Python module files around in the gar source code. There is no mechanism in subversion to clean up *.pyc files when clients get updated, so old *pyc files are likely to be still lying around. I've added code to checkpkg which deals with the *.pyc files automatically, so the best fix is to update your gar sources and you should be OK. If you still run into issues with checkpkg, remove all the *.pyc files from GAR sources and try again. gfind gar -name '*.pyc' -exec rm {} \; gmake Why the problems might happen: "import checkpkg" might read v2/bin/checkpkg.d/checkpkg.pyc instead of v2/lib/python/checkpkg.py, which would create a mismatch between the library and library client. I'm sorry for the inconvenience. Maciej From maciej at opencsw.org Wed Jan 27 15:55:15 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 27 Jan 2010 14:55:15 +0000 Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B54D11F.3000608@opencsw.org> <1263850046-sup-8178@ntdws12.chass.utoronto.ca> <4B5CA417.5060708@opencsw.org> Message-ID: On Mon, Jan 25, 2010 at 6:25 PM, Philip Brown wrote: > We can rename the "newpkgs" directory to something,and then create a > new mailing list with the same name? Looks good to me. The new name could be pkgsubmissions, which is somewhat long, but descriptive. Are people OK with this solution? From phil at bolthole.com Wed Jan 27 18:51:02 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 27 Jan 2010 09:51:02 -0800 Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B54D11F.3000608@opencsw.org> <1263850046-sup-8178@ntdws12.chass.utoronto.ca> <4B5CA417.5060708@opencsw.org> Message-ID: On Wed, Jan 27, 2010 at 6:55 AM, Maciej (Matchek) Blizinski wrote: > On Mon, Jan 25, 2010 at 6:25 PM, Philip Brown wrote: >> We can rename the "newpkgs" directory to something,and then create a >> new mailing list with the same name? > > Looks good to me. > > The new name could be pkgsubmissions, which is somewhat long, but > descriptive. Are people OK with this solution? > The only remaining issue about the name I can think of, is that when and if we get back to doing regular "stable freeze" type things, it might be nice to have separate lists for freeze/stable type updates. In which case, we might keep that in mind when choosing names for things. currentupdates vs stableupdates? Ehhh.. I dunno, not sure I even have a definate view on this either way, but I'll toss it out there for comments. From maciej at opencsw.org Wed Jan 27 20:00:14 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 27 Jan 2010 19:00:14 +0000 Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <4B54D11F.3000608@opencsw.org> <1263850046-sup-8178@ntdws12.chass.utoronto.ca> <4B5CA417.5060708@opencsw.org> Message-ID: On Wed, Jan 27, 2010 at 5:51 PM, Philip Brown wrote: > The only remaining issue about the name I can think of, is that when > and if we get back to doing regular "stable freeze" type things, it > might be nice to have separate lists for freeze/stable type updates. > In which case, we might keep that in mind when choosing names for things. > > currentupdates vs stableupdates? There was an extensive discussion in Munich about how to revive the stable catalog and do stable releases. I'm going to do an extensive writeup of it during the weekend. If the proposal passed, the name 'currentupdates' would not match what it referred to. I don't want to go into any details right now, there will be a separate thread for this discussion, let me just say that it needs only minimal changes to the current process and pkgsubmissions would be perfectly adequate as a mailing list name and a directory name. If, on the other hand, we decide that a different name is needed, we'll change it. This mailing list name does not have to be carved in stone. If it's no longer necessary or useful, we can archive and close it. Maciej From phil at bolthole.com Wed Jan 27 20:39:00 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 27 Jan 2010 11:39:00 -0800 Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <4B54D11F.3000608@opencsw.org> <1263850046-sup-8178@ntdws12.chass.utoronto.ca> <4B5CA417.5060708@opencsw.org> Message-ID: On Wed, Jan 27, 2010 at 11:00 AM, Maciej (Matchek) Blizinski wrote: >... let me just say that it needs only minimal changes to > the current process and pkgsubmissions would be perfectly adequate as > a mailing list name and a directory name. ?If, on the other hand, we > decide that a different name is needed, we'll change it. ?This mailing > list name does not have to be carved in stone. ?If it's no longer > necessary or useful, we can archive and close it. > good point, particularly since it is internal-only. ok, i'm fine with "pkgsubmissions" From william at wbonnet.net Wed Jan 27 23:44:40 2010 From: william at wbonnet.net (William Bonnet) Date: Wed, 27 Jan 2010 23:44:40 +0100 Subject: [csw-maintainers] [RFE] CSW outstanding bug notification email Message-ID: <4B60C1D8.8060805@wbonnet.net> Hi, I would like to ask for an evolution on this reminder email please. Would it be possible to add package name, and if possible nug summary to the email content please ? In example... Current email format is : These reports have severity "major" or above: http://www.opencsw.org/bugtrack/view.php?id=1893 http://www.opencsw.org/bugtrack/view.php?id=1924 http://www.opencsw.org/bugtrack/view.php?id=1975 Would it be possible to have this : These reports have severity "major" or above: firefox : http://www.opencsw.org/bugtrack/view.php?id=1893 xfce_engine : http://www.opencsw.org/bugtrack/view.php?id=1924 xfce_load : http://www.opencsw.org/bugtrack/view.php?id=1975 Or even better (IMHO) These reports have severity "major" or above: firefox : Firefox directories keep moving http://www.opencsw.org/bugtrack/view.php?id=1893 xfce_engine : bad location for engine modules http://www.opencsw.org/bugtrack/view.php?id=1924 xfce_load : la file contains local paths http://www.opencsw.org/bugtrack/view.php?id=1975 Thanks in advance 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 hson at opencsw.org Thu Jan 28 01:28:43 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Thu, 28 Jan 2010 01:28:43 +0100 Subject: [csw-maintainers] maintainers email addrs on packages In-Reply-To: <4B5796E4.6010701@opencsw.org> References: <4B5796E4.6010701@opencsw.org> Message-ID: <4B60DA3B.4000403@opencsw.org> Sebastian Kayser wrote: > Philip Brown wrote on 20.01.2010 22:30: >> On Wed, Jan 20, 2010 at 11:09 AM, James Lee wrote: >>> We could also have several people receiving the emails in the case >>> of a maintainer team - or a mailing list. >> Hrrrm.. I can ALMOST visualize supporting MULTIPLE email addrs in the >> EMAIL= field of pkginfo. mantis DOES support having multiple people as >> manager of a package. > > No ... please. Let's eventually de-couple our meta information handling > from the bug handling in Mantis - not work it even more deeper into it. > > I would have wanted to assign global maintainer privileges to all CSW > maintainers for a while now, so that bug handling across > packages/projects gets easier. Currently though, our > "package-to-maintainer" mapping is based on those privileges in Mantis, > so I can't easily manage permissions in Mantis without risking to mess > up the mappings. Is the mapping based on who's "manager" for a package? Then it wouldn't be a problem to give all maintainers "developer "privileges to all projects in Mantis, right? That way the only thing a "developer" can't(if I remember the default settings for Mantis) do is to close issues and assign them, which still would fall upon the maintainer for that package. From james at opencsw.org Thu Jan 28 11:01:29 2010 From: james at opencsw.org (James Lee) Date: Thu, 28 Jan 2010 10:01:29 GMT Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B54D11F.3000608@opencsw.org> <1263850046-sup-8178@ntdws12.chass.utoronto.ca> <4B5CA417.5060708@opencsw.org> Message-ID: <20100128.10012900.2387771233@gyor.oxdrove.co.uk> On 27/01/10, 17:51:02, Philip Brown wrote regarding Re: [csw-maintainers] new mailing list?: > The only remaining issue about the name I can think of, is that when > and if we get back to doing regular "stable freeze" type things, it > might be nice to have separate lists for freeze/stable type updates. > In which case, we might keep that in mind when choosing names for things. > currentupdates vs stableupdates? No, updates are still first sent to unstable for proving. James. From james at opencsw.org Thu Jan 28 12:17:36 2010 From: james at opencsw.org (James Lee) Date: Thu, 28 Jan 2010 11:17:36 GMT Subject: [csw-maintainers] [RFE] CSW outstanding bug notification email In-Reply-To: <4B60C1D8.8060805@wbonnet.net> References: <4B60C1D8.8060805@wbonnet.net> Message-ID: <20100128.11173600.2649314494@gyor.oxdrove.co.uk> On 27/01/10, 22:44:40, William Bonnet wrote regarding [csw-maintainers] [RFE] CSW outstanding bug notification email: > Would it be possible to add package name, and if possible nug summary to > the email content please ? > Current email format is : > These reports have severity "major" or above: > http://www.opencsw.org/bugtrack/view.php?id=1893 > http://www.opencsw.org/bugtrack/view.php?id=1924 > http://www.opencsw.org/bugtrack/view.php?id=1975 > Would it be possible to have this : > firefox : Firefox directories keep moving > http://www.opencsw.org/bugtrack/view.php?id=1893 > xfce_engine : bad location for engine modules > http://www.opencsw.org/bugtrack/view.php?id=1924 > xfce_load : la file contains local paths > http://www.opencsw.org/bugtrack/view.php?id=1975 It's possible but one click away. The process is incremental so you only need review the highest numbers. The other method for remembering the long list is to make it shorter by fixing something, in a way the bug list is supposed to be annoying. William, I've set you a test, how it that? James. From maciej at opencsw.org Thu Jan 28 15:28:47 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 28 Jan 2010 14:28:47 +0000 Subject: [csw-maintainers] GAR: New checkpkg module: pkgmap / pkginfo class action integrity Message-ID: I've recently bumped into a problem in which there's a class that's assigned to files in pkgmap, but not present in pkginfo CLASSES variable. The result is that the files marked with the orphaned class, even though they are in the root/ directory of the package, don't get installed. I wrote a checkpkg module to test for this issue, it has been submitted to the repository. An example output: ERROR: One or more errors have been found by class action scripts / prototype integrity. PackageError("Class 'bar' is only in pkginfo",) PackageError("Class 'foo' is only in pkginfo",) PackageError("Class 'baz' is only in pkginfo",) PackageError("Class 'none' is only in pkgmap",) PackageError("pkginfo_classes: set(['baz', 'foo', 'bar', 'cswtexinfo']), pkgmap classes: set(['none', 'cswtexinfo'])",) If you want to use the new module, you need to update your local copy of GAR code. Maciej From dam at opencsw.org Thu Jan 28 15:32:30 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 28 Jan 2010 15:32:30 +0100 Subject: [csw-maintainers] GAR: New checkpkg module: pkgmap / pkginfo class action integrity In-Reply-To: References: Message-ID: <8E1629AC-D455-4271-BA30-C1798F54351E@opencsw.org> Hi Maciej, Am 28.01.2010 um 15:28 schrieb Maciej (Matchek) Blizinski: > I've recently bumped into a problem in which there's a class that's > assigned to files in pkgmap, but not present in pkginfo CLASSES > variable. The result is that the files marked with the orphaned > class, even though they are in the root/ directory of the package, > don't get installed. > > I wrote a checkpkg module to test for this issue, it has been > submitted to the repository. An example output: > > ERROR: One or more errors have been found by class action scripts / > prototype integrity. > PackageError("Class 'bar' is only in pkginfo",) > PackageError("Class 'foo' is only in pkginfo",) > PackageError("Class 'baz' is only in pkginfo",) > PackageError("Class 'none' is only in pkgmap",) > PackageError("pkginfo_classes: set(['baz', 'foo', 'bar', > 'cswtexinfo']), pkgmap classes: set(['none', 'cswtexinfo'])",) > > If you want to use the new module, you need to update your local copy > of GAR code. Most of the times you are right. However, there is the case where only a subset of files gets installed by selecting only specific classes. The list of classes can be calculated during checkinstall depending on the system where the package is installed. I don't know if there are any package that make use of this, but everyone please keep an open eye on this! Best regards -- Dago From maciej at opencsw.org Thu Jan 28 16:24:57 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 28 Jan 2010 15:24:57 +0000 Subject: [csw-maintainers] GAR: New checkpkg module: pkgmap / pkginfo class action integrity In-Reply-To: <8E1629AC-D455-4271-BA30-C1798F54351E@opencsw.org> References: <8E1629AC-D455-4271-BA30-C1798F54351E@opencsw.org> Message-ID: On Thu, Jan 28, 2010 at 2:32 PM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 28.01.2010 um 15:28 schrieb Maciej (Matchek) Blizinski: >> >> I've recently bumped into a problem in which there's a class that's >> assigned to files in pkgmap, but not present in pkginfo CLASSES >> variable. ?The result is that the files marked with the orphaned >> class, even though they are in the root/ directory of the package, >> don't get installed. >> >> I wrote a checkpkg module to test for this issue, it has been >> submitted to the repository. An example output: >> >> ERROR: One or more errors have been found by class action scripts / >> prototype integrity. >> PackageError("Class 'bar' is only in pkginfo",) >> PackageError("Class 'foo' is only in pkginfo",) >> PackageError("Class 'baz' is only in pkginfo",) >> PackageError("Class 'none' is only in pkgmap",) >> PackageError("pkginfo_classes: set(['baz', 'foo', 'bar', >> 'cswtexinfo']), pkgmap classes: set(['none', 'cswtexinfo'])",) >> >> If you want to use the new module, you need to update your local copy >> of GAR code. > > Most of the times you are right. However, there is the case where only > a subset of files gets installed by selecting only specific classes. > The list of classes can be calculated during checkinstall Pardon my ignorance, at what stage is checkinstall being run? > depending > on the system where the package is installed. I don't know if there > are any package that make use of this, but everyone please keep an > open eye on this! I hope that if this issue ever crops up, I'll have the overrides mechanism in place. From dam at opencsw.org Thu Jan 28 16:33:16 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 28 Jan 2010 16:33:16 +0100 Subject: [csw-maintainers] GAR: New checkpkg module: pkgmap / pkginfo class action integrity In-Reply-To: References: <8E1629AC-D455-4271-BA30-C1798F54351E@opencsw.org> Message-ID: <21AA258E-0764-4FCF-AEF9-231159D39AAA@opencsw.org> Hi Maciej, Am 28.01.2010 um 16:24 schrieb Maciej (Matchek) Blizinski: > Pardon my ignorance, at what stage is checkinstall being run? Checkinstall is run early during package installation before classes are applied to the files. This way a package can compute which files need to be installed. For example the Veritas Volume Manager has kernel modules for all supported OS revisions in the package, each tagged with a different class. During checkinstall only the kernel modules for the current architecture are selected by dynamically modifying the installed classes. Or you could have a request script asking the user if he wants documentation installed and dynamically add the "docs" class. Together with pkgask(1) this is very elegant, but will go away soon with IPS anyway... >> depending >> on the system where the package is installed. I don't know if there >> are any package that make use of this, but everyone please keep an >> open eye on this! > > I hope that if this issue ever crops up, I'll have the overrides > mechanism in place. Ok, good. Best regards -- Dago From phil at bolthole.com Thu Jan 28 18:37:17 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 28 Jan 2010 09:37:17 -0800 Subject: [csw-maintainers] maintainers email addrs on packages In-Reply-To: <4B60DA3B.4000403@opencsw.org> References: <4B5796E4.6010701@opencsw.org> <4B60DA3B.4000403@opencsw.org> Message-ID: On Wed, Jan 27, 2010 at 4:28 PM, Roger H?kansson wrote: > > Is the mapping based on who's "manager" for a package? > Then it wouldn't be a problem to give all maintainers "developer "privileges > to all projects in Mantis, right? yes, and yes. Excellent idea, thank you. I leave it to our "mantis administrator" to handle the details. :) Although I would appreciate an offlist mention to me, of what the sql level change is, so that I can update our "new maintainer" proceedures to give them developer privs on signup. From dam at opencsw.org Thu Jan 28 21:00:32 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 28 Jan 2010 21:00:32 +0100 Subject: [csw-maintainers] (now about sudo) In-Reply-To: <4B28150D.4040506@opencsw.org> References: <4B28150D.4040506@opencsw.org> Message-ID: Hi folks, Am 16.12.2009 um 00:00 schrieb Sebastian Kayser: > Philip Brown wrote on 15.12.2009 22:12: >> On Tue, Dec 15, 2009 at 12:57 PM, Maciej (Matchek) Blizinski >> wrote: >>> On Tue, Dec 15, 2009 at 4:45 PM, Philip Brown >>> wrote: >>>> there is at least ONE "known bug", that you havent fixed: perms >>>> on sudo_ldap. >>>> please fix that. >>> I'll pass for now. I'm offering only the version bump. >> >> It's a trivial change. one line in the prototype file. I wont accept >> the packages until you fix it. > > It's not about "the one prototype line". I am a bit puzzled here: If it is just one changed line, Maciej, why don't you simply fix it? Or is there anything else going on here I don't understand? Best regards -- Dago From hson at opencsw.org Thu Jan 28 21:06:56 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Thu, 28 Jan 2010 21:06:56 +0100 Subject: [csw-maintainers] Package policy questions Message-ID: <4B61EE60.7010509@opencsw.org> I'm packaging a new version of an orphaned package which have a optional dependency package where upstream requires v8plus to build. (They write in the README file that their package requires v8plus and will not build on v8) The question is what to do in cases like this? Build the first package without this optional (but for some users wanted) dependency package or build a package which can only be run on machines with v8plus? This would mean that we limit our users to machines with UltraSparc CPU's (or newer) which I can't seem to be a big problem (anyone still using old SS10/SS5/SS20's must be pain lovers...) today. Next issue... I think I've read somewhere that we should strive to build all packages with as many options enabled as possible, which seems like a good idea. But what about delivering different functionality in the same package for 32/64-bit binaries? I've been looking into enabling 64-bit support for ImageMagick, but the dependency chain is starting to get huge and when that list include packages like libbonobo2 it becomes a bit tricky. The amount of packages affected by an upgrade of for example libbonobo2 are huge. On the other hand, it seems silly to start gar-ifying current versions of some of those packages, which are several years old, just to get 64bit support. So the question is, what is the preferred solution, skip 64bit until all dependencies have been fixed or build a package with different features enabled for 32 and 64-bit? From dam at opencsw.org Thu Jan 28 21:16:05 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 28 Jan 2010 21:16:05 +0100 Subject: [csw-maintainers] Package policy questions In-Reply-To: <4B61EE60.7010509@opencsw.org> References: <4B61EE60.7010509@opencsw.org> Message-ID: <14B89B51-A1D3-4EBD-93FB-9431B14FF139@opencsw.org> Hi Roger, Am 28.01.2010 um 21:06 schrieb Roger H?kansson: > I'm packaging a new version of an orphaned package which have a > optional dependency package where upstream requires v8plus to build. > (They write in the README file that their package requires v8plus > and will not build on v8) > > The question is what to do in cases like this? > Build the first package without this optional (but for some users > wanted) dependency package or build a package which can only be run > on machines with v8plus? > This would mean that we limit our users to machines with UltraSparc > CPU's (or newer) which I can't seem to be a big problem (anyone > still using old SS10/SS5/SS20's must be pain lovers...) today. You can build it for sparcv8plus for Solaris 9 and if you want without this optional dependency for sparcv8 for Solaris 8, but this is not mandatory. > Next issue... > I think I've read somewhere that we should strive to build all > packages with as many options enabled as possible, which seems like > a good idea. > But what about delivering different functionality in the same > package for 32/64-bit binaries? > I've been looking into enabling 64-bit support for ImageMagick, but > the dependency chain is starting to get huge and when that list > include packages like libbonobo2 it becomes a bit tricky. > The amount of packages affected by an upgrade of for example > libbonobo2 are huge. > On the other hand, it seems silly to start gar-ifying current > versions of some of those packages, which are several years old, > just to get 64bit support. > > So the question is, what is the preferred solution, skip 64bit until > all dependencies have been fixed or build a package with different > features enabled for 32 and 64-bit? The best solution would be to just upgrade to 64 bit now ;-) Kidding aside, it would be cleanest to restrict the features to the ones which are available in both 32 and 64 bit or to skip 64 bit completely and build 64 bit from ground up. Different features is asking for trouble. Maybe some others can chime in in a joint-effort to garify and 64 bit enable this stuff? I like packaging up libraries :-) Best regards -- Dago From dam at opencsw.org Thu Jan 28 21:44:07 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 28 Jan 2010 21:44:07 +0100 Subject: [csw-maintainers] Package policy questions In-Reply-To: <14B89B51-A1D3-4EBD-93FB-9431B14FF139@opencsw.org> References: <4B61EE60.7010509@opencsw.org> <14B89B51-A1D3-4EBD-93FB-9431B14FF139@opencsw.org> Message-ID: <57AD1F89-5906-431B-94C4-32BCBCAFF4DA@opencsw.org> Hi Roger, Am 28.01.2010 um 21:16 schrieb Dagobert Michelsen: > Am 28.01.2010 um 21:06 schrieb Roger H?kansson: >> I think I've read somewhere that we should strive to build all >> packages with as many options enabled as possible, which seems like >> a good idea. >> But what about delivering different functionality in the same >> package for 32/64-bit binaries? >> I've been looking into enabling 64-bit support for ImageMagick, but >> the dependency chain is starting to get huge and when that list >> include packages like libbonobo2 it becomes a bit tricky. >> The amount of packages affected by an upgrade of for example >> libbonobo2 are huge. I remember. I was working on libbonobo2 and stuck at an error during IDL compilation from ORBit2, then decided it was an orbit-thing and updated ORBit2 to the latest version including 64 bit but it didn't help. On compilation I get > /opt/csw/bin/orbit-idl-2 -I../idl -D__Bonobo_COMPILATION - > D__Bonobo_Unknown_COMPILATION -D__Bonobo_GenericFactory_COMPILATION - > D__Bonobo_Activation_types_COMPILATION --imodule ../idl/Bonobo.idl > orbit-idl-2 2.14.17 compiling > mode, hide preprocessor errors, passes: stubs skels common headers > imodule > > Processing file ../idl/Bonobo.idl > ../idl/Bonobo.idl:35: Error: syntax error, unexpected TOK_SRCFILE, > expecting TOK_ENUM or TOK_STRUCT or TOK_UNION > > ** (orbit-idl-2:19669): WARNING **: ../idl/Bonobo.idl compilation > failed > gmake: *** [Bonobo.h] Error 1 Any ideas of what is going on there? Everything is checked into GAR at pkg/libbonobo2 Best regards -- Dago From hson at opencsw.org Thu Jan 28 22:14:13 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Thu, 28 Jan 2010 22:14:13 +0100 Subject: [csw-maintainers] Package policy questions In-Reply-To: <57AD1F89-5906-431B-94C4-32BCBCAFF4DA@opencsw.org> References: <4B61EE60.7010509@opencsw.org> <14B89B51-A1D3-4EBD-93FB-9431B14FF139@opencsw.org> <57AD1F89-5906-431B-94C4-32BCBCAFF4DA@opencsw.org> Message-ID: <4B61FE25.60000@opencsw.org> Dagobert Michelsen wrote: > Hi Roger, > > Am 28.01.2010 um 21:16 schrieb Dagobert Michelsen: >> Am 28.01.2010 um 21:06 schrieb Roger H?kansson: >>> I think I've read somewhere that we should strive to build all >>> packages with as many options enabled as possible, which seems like a >>> good idea. >>> But what about delivering different functionality in the same package >>> for 32/64-bit binaries? >>> I've been looking into enabling 64-bit support for ImageMagick, but >>> the dependency chain is starting to get huge and when that list >>> include packages like libbonobo2 it becomes a bit tricky. >>> The amount of packages affected by an upgrade of for example >>> libbonobo2 are huge. > > I remember. I was working on libbonobo2 and stuck at an error during IDL > compilation > from ORBit2, then decided it was an orbit-thing and updated ORBit2 to > the latest > version including 64 bit but it didn't help. On compilation I get > >> /opt/csw/bin/orbit-idl-2 -I../idl -D__Bonobo_COMPILATION >> -D__Bonobo_Unknown_COMPILATION -D__Bonobo_GenericFactory_COMPILATION >> -D__Bonobo_Activation_types_COMPILATION --imodule ../idl/Bonobo.idl >> orbit-idl-2 2.14.17 compiling >> mode, hide preprocessor errors, passes: stubs skels common headers >> imodule >> >> Processing file ../idl/Bonobo.idl >> ../idl/Bonobo.idl:35: Error: syntax error, unexpected TOK_SRCFILE, >> expecting TOK_ENUM or TOK_STRUCT or TOK_UNION >> >> ** (orbit-idl-2:19669): WARNING **: ../idl/Bonobo.idl compilation failed >> gmake: *** [Bonobo.h] Error 1 > > Any ideas of what is going on there? Everything is checked into GAR at > pkg/libbonobo2 > One hit with google https://bugzilla.gnome.org/show_bug.cgi?id=142099 From dam at opencsw.org Thu Jan 28 22:19:32 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 28 Jan 2010 22:19:32 +0100 Subject: [csw-maintainers] Package policy questions In-Reply-To: <4B61FE25.60000@opencsw.org> References: <4B61EE60.7010509@opencsw.org> <14B89B51-A1D3-4EBD-93FB-9431B14FF139@opencsw.org> <57AD1F89-5906-431B-94C4-32BCBCAFF4DA@opencsw.org> <4B61FE25.60000@opencsw.org> Message-ID: <466B52CF-3375-4301-8231-CF243EAFB83B@opencsw.org> Hi Roger, Am 28.01.2010 um 22:14 schrieb Roger H?kansson: > Dagobert Michelsen wrote: >> Hi Roger, >> Am 28.01.2010 um 21:16 schrieb Dagobert Michelsen: >>> Am 28.01.2010 um 21:06 schrieb Roger H?kansson: >>>> I think I've read somewhere that we should strive to build all >>>> packages with as many options enabled as possible, which seems >>>> like a good idea. >>>> But what about delivering different functionality in the same >>>> package for 32/64-bit binaries? >>>> I've been looking into enabling 64-bit support for ImageMagick, >>>> but the dependency chain is starting to get huge and when that >>>> list include packages like libbonobo2 it becomes a bit tricky. >>>> The amount of packages affected by an upgrade of for example >>>> libbonobo2 are huge. >> I remember. I was working on libbonobo2 and stuck at an error >> during IDL compilation >> from ORBit2, then decided it was an orbit-thing and updated ORBit2 >> to the latest >> version including 64 bit but it didn't help. On compilation I get >>> /opt/csw/bin/orbit-idl-2 -I../idl -D__Bonobo_COMPILATION - >>> D__Bonobo_Unknown_COMPILATION - >>> D__Bonobo_GenericFactory_COMPILATION - >>> D__Bonobo_Activation_types_COMPILATION --imodule ../idl/Bonobo.idl >>> orbit-idl-2 2.14.17 compiling >>> mode, hide preprocessor errors, passes: stubs skels common >>> headers imodule >>> >>> Processing file ../idl/Bonobo.idl >>> ../idl/Bonobo.idl:35: Error: syntax error, unexpected TOK_SRCFILE, >>> expecting TOK_ENUM or TOK_STRUCT or TOK_UNION >>> >>> ** (orbit-idl-2:19669): WARNING **: ../idl/Bonobo.idl compilation >>> failed >>> gmake: *** [Bonobo.h] Error 1 >> Any ideas of what is going on there? Everything is checked into GAR >> at >> pkg/libbonobo2 > > One hit with google > https://bugzilla.gnome.org/show_bug.cgi?id=142099 This is for ORBit2, which I have compiled nicely. Do you think I should recompile it with CPP=/usr/lib/cpp set and then redo libbonobo2? Best regards -- Dago From hson at opencsw.org Thu Jan 28 22:21:55 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Thu, 28 Jan 2010 22:21:55 +0100 Subject: [csw-maintainers] Package policy questions In-Reply-To: <466B52CF-3375-4301-8231-CF243EAFB83B@opencsw.org> References: <4B61EE60.7010509@opencsw.org> <14B89B51-A1D3-4EBD-93FB-9431B14FF139@opencsw.org> <57AD1F89-5906-431B-94C4-32BCBCAFF4DA@opencsw.org> <4B61FE25.60000@opencsw.org> <466B52CF-3375-4301-8231-CF243EAFB83B@opencsw.org> Message-ID: <4B61FFF3.508@opencsw.org> >> One hit with google >> https://bugzilla.gnome.org/show_bug.cgi?id=142099 > > This is for ORBit2, which I have compiled nicely. Do you think I should > recompile it with CPP=/usr/lib/cpp set and then redo libbonobo2? > It seems like a probable cause, I'm compiling right now From william at wbonnet.net Thu Jan 28 22:33:06 2010 From: william at wbonnet.net (William Bonnet) Date: Thu, 28 Jan 2010 22:33:06 +0100 Subject: [csw-maintainers] [RFE] CSW outstanding bug notification email In-Reply-To: <20100128.11173600.2649314494@gyor.oxdrove.co.uk> References: <4B60C1D8.8060805@wbonnet.net> <20100128.11173600.2649314494@gyor.oxdrove.co.uk> Message-ID: <4B620292.3000809@wbonnet.net> Hi James > William, I've set you a test, how it that? > Looks perfect to me. Thanks 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 hson at opencsw.org Fri Jan 29 00:04:55 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 29 Jan 2010 00:04:55 +0100 Subject: [csw-maintainers] Package policy questions In-Reply-To: <14B89B51-A1D3-4EBD-93FB-9431B14FF139@opencsw.org> References: <4B61EE60.7010509@opencsw.org> <14B89B51-A1D3-4EBD-93FB-9431B14FF139@opencsw.org> Message-ID: <4B621817.60505@opencsw.org> Dagobert Michelsen wrote: > You can build it for sparcv8plus for Solaris 9 and if you want without > this optional dependency > for sparcv8 for Solaris 8, but this is not mandatory. Why Solaris9? Its not until Solaris 10 that all non-v8plus capable CPUs are totally unsupported. sun4c was dropped in Solaris 8, sun4d in Solaris 9 and sun4m in Solaris 10. >> So the question is, what is the preferred solution, skip 64bit until >> all dependencies have been fixed or build a package with different >> features enabled for 32 and 64-bit? > > The best solution would be to just upgrade to 64 bit now ;-) Kidding aside, > it would be cleanest to restrict the features to the ones which are > available > in both 32 and 64 bit The problem with that is that many of the features which have been available for many years now would be gone. For example EPS/PDF support since ghostscript isn't 64-bit and has dependencies to old orphaned packages like krb5_lib. And I think that EPS/PDF support might be considered basic. At least would my customers be a bit angry if I would to remove support for them in ImageMagick. > Different features is asking for trouble. I agree. > Maybe some others > can chime in in a joint-effort to garify and 64 bit enable this stuff? > I like packaging up libraries :-) Me too ;) From hson at opencsw.org Fri Jan 29 00:06:14 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 29 Jan 2010 00:06:14 +0100 Subject: [csw-maintainers] Package policy questions In-Reply-To: <4B61FFF3.508@opencsw.org> References: <4B61EE60.7010509@opencsw.org> <14B89B51-A1D3-4EBD-93FB-9431B14FF139@opencsw.org> <57AD1F89-5906-431B-94C4-32BCBCAFF4DA@opencsw.org> <4B61FE25.60000@opencsw.org> <466B52CF-3375-4301-8231-CF243EAFB83B@opencsw.org> <4B61FFF3.508@opencsw.org> Message-ID: <4B621866.1070402@opencsw.org> Roger H?kansson wrote: > >>> One hit with google >>> https://bugzilla.gnome.org/show_bug.cgi?id=142099 >> >> This is for ORBit2, which I have compiled nicely. Do you think I should >> recompile it with CPP=/usr/lib/cpp set and then redo libbonobo2? >> > > It seems like a probable cause, I'm compiling right now > Seems to do the trick, I've rebuilt libidl, orbit2 and reinstalled them on my "build8s" and bonobo2 builds just fine (or at least the v8, v9 is compiling right now) if libname-server-2.a is included in orbit2 From maciej at opencsw.org Fri Jan 29 15:19:45 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 29 Jan 2010 14:19:45 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: <4B28150D.4040506@opencsw.org> Message-ID: On Thu, Jan 28, 2010 at 8:00 PM, Dagobert Michelsen wrote: > Hi folks, > > Am 16.12.2009 um 00:00 schrieb Sebastian Kayser: >> >> Philip Brown wrote on 15.12.2009 22:12: >>> >>> On Tue, Dec 15, 2009 at 12:57 PM, Maciej (Matchek) Blizinski >>> wrote: >>>> >>>> On Tue, Dec 15, 2009 at 4:45 PM, Philip Brown wrote: >>>>> >>>>> there is at least ONE "known bug", that you havent fixed: perms on >>>>> sudo_ldap. >>>>> please fix that. >>>> >>>> I'll pass for now. ?I'm offering only the version bump. >>> >>> It's a trivial change. one line in the prototype file. ?I wont accept >>> the packages until you fix it. >> >> It's not about "the one prototype line". > > I am a bit puzzled here: If it is just one changed line, Maciej, > why don't you simply fix it? Or is there anything else going on > here I don't understand? There is. Here goes one more long e-mail from me. Remember one of the first scenes in The Matrix[1]? Agent Smith: Lieutenant? Lieutenant: Oh shit. Agent Smith: Lieutenant, you were given specific orders -- Lieutenant: I'm just doing my job. You gimme that Juris-my dick-tion and you can cram it up your ass. Agent Smith was right, the police couldn't handle this one little girl. But he wasn't doing a good job at establishing a good relationship with the lieutenant. Perhaps he didn't need to. But I'll get to that later. The initial problem with sudo was that a combination of an old enough version of CSWsudo and the way pkg-get upgrades packages (doesn't remove all the dependencies before installing new packages) resulted in a missing /opt/csw/bin/sudo. I wrote a fix and distributed it to my Solaris fleet at work. I believe that sharing my work with others is the right thing to do, so I spent some time explaining the failure mode in the butracking system[2] so that the maintainer could fix the problem. Soon enough it turned out that the sudo maintainer is on sabbatical. OK, this was more that I initially intended to do, but I decided to move forward and deliver a fix to the project. I submitted my code to the repository, and rebuilt the sudo and sudo_common packages. Phil didn't accept my fix. He started coming up with failure modes which involved sudo_ldap, an alternative version of sudo. The failure modes he presented didn't look very convincing to me, mainly because they involved modifications of paths controlled directly by packages / pkgmap files. The main premise was that sudo_ldap is a working alternative to sudo, and can be installed at the same time. Phil suggested writing a postinstall script which would try to guess what to do about symlinks - what to do if sudo_ldap is there, what to do if it's not, etc. I didn't agree that it was a good solution. All these arguments were under the premise that sudo_ldap is a working package. When I discovered that the sudo.ldap binary wasn't setuid root, Phil wanted me to fix it. It was out of the scope of what I intended to fix, so I opened a bug in mantis[3] in so that the problem isn't forgotten, and said that I don't want to extend the scope of my work. There was only one specific bug I intended to fix. I maintain that sudo_ldap is a work in progress, it's not a finished solution, and it's unlikely that anybody actually uses it. And if anybody does, there's a number things that they have to be aware of and fix after the installation and each upgrade, so they probably don't expect an upgraded package to work out of the box. But Phil insisted. OK, again I decided to go beyond what I initially intended, and solve the problem of alternative binaries in a proper way. Delivering hackish postinstall scripts sounds like a bad idea, so if sudo and sudo_ldap are to be used as alternatives, there needs to be an alternatives system in place. I packaged up Debian's solution. You can argue that this package is not perfect, but it's there and it can get the job done. I offered the alternatives package. It was rejected. In the meantime, a new version of sudo was released. Already bitter about the whole thing, I gritted my teeth and packaged the upgrade. Since sudo_ldap should get an upgrade as well, I packaged it up too. But I didn't want to fix the sudo_ldap package. Mind you, a short time before that, Phil has rejected my work on a solution to a problem that he imposed on me in the first place. There's only so much I can be pushed around like this. Working sudo_ldap is a premise for arguments that make my life difficult, I'm not going to have my hand in making it come true. The sudo_ldap non-fix was a test. Phil could have said: "fair enough, you fix one thing, the other thing at least doesn't get any worse, perhaps you can do it at later time". If he did, I'd be quite likely to go back to sudo_ldap after the alternatives issue gets resolved (because it's a dependency). But instead he said "Fix this now or else!" I agree that it's something that needs to be eventually fixed. But I'm not going to fix it because there's pressure inflicted on me. In circumstances like this, inflicting pressure on me is a guarantee that I'm not going to touch the damn thing. I'm sorry, I'm not going to work like this. What I'm doing might seem like an overreaction, but it's not the only issue I'm having with Phil. There has been a number of occasions at which Phil has collected bad karma. Here are some examples: * website html code update: I wanted to offer an update to the website. There already has been an argument about the website source code, in which Phil insisted on not submitting the HTML code to the repository. I gritted my teeth, copied the files, modified them and sent Phil a patch. Instead of just taking the patch and applying it, Phil pushed back, telling me to send the whole file and point him at a live instance of the modified page. I did that. When he looked into the directory and saw that the whole web directory has been copied, he started lecturing me that it was messy, and I should have copied only what was necessary. Not using source control, not accepting a patch... and lecturing me about messiness. * lecturing me about how open source works: I started working on a web app to display package / maintainer information. When I wrote about what I intended to do, Phil started giving me a lecture about how the development in open source works[4]. Until today, I don't know what was the intention behind this e-mail, was it to educate me, or rebuke me (by implying that I don't know certain things and have to be taught), or was it something else. * database update rejection: I offered a package database update, that I needed to use the db from Django. It was backwards compatible. I offered a complete SQL script, doing a backup of the affected tables. There was also code to roll the changes back if anything went wrong. It was rejected, and the comment I received in private is that Phil doesn't have time to read other people's code. Then he started lecturing me about how I should go and fix Django. * rxvt-unicode rejection: I've built it on Solaris 10; it wouldn't compile on Solaris 8 or 9. The package was rejected. I understand that certain packages, such as libraries need to be compiled on Solaris 8. But this is a terminal emulator which differs from xterm basically only in the capability of displaying unicode characters. How is it important to build it on Solaris 8, I don't understand. It still sits in testing/ and each time I do ls -l /home/testing | grep maciej, I see it and it makes me sad. There are also constant smaller issues such as yelling in e-mail and unreasonable arguments in discussions ("I don't use autocompletion"). Back to the Matrix analogy: Perhaps Phil, just like Agent Smith, understands more and has reasons to do what he does, but in either case I'm not going to submit to "You were given specific orders." I needed to draw a line somewhere, and sudo_ldap is my line. I don't know whether it's just one core issue that led to the current situation, or is it only an unfortunate combination of reckless use of language in e-mails, annoying technical issues, and our past experiences. I think that most probably Phil means well, and I know I do too. But I've experienced a lot of things I didn't like. They make me sad and bitter, and I don't want to be sad nor bitter. I want to work on solving technical problems with like-minded individuals and be happy. Maciej [1] http://www.imsdb.com/scripts/Matrix,-The.html [2] http://www.opencsw.org/bugtrack/view.php?id=4004 [3] http://www.opencsw.org/bugtrack/view.php?id=4074 [4] http://lists.opencsw.org/pipermail/maintainers/2009-March/001791.html From hson at opencsw.org Fri Jan 29 17:21:01 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 29 Jan 2010 17:21:01 +0100 Subject: [csw-maintainers] [csw-devel] SF.net SVN: gar:[8215] csw/mgar/gar/v2 In-Reply-To: References: Message-ID: <4B630AED.7040806@opencsw.org> wahwah at users.sourceforge.net wrote: > Revision: 8215 > http://gar.svn.sourceforge.net/gar/?rev=8215&view=rev > Author: wahwah ... > +readonly NAME_MAX_LENGTH=${NAME_MAX_LENGTH:-20} ... > -if [[ ${#software} -gt 20 ]] ; then errmsg $f: software name greater than 20 chars ; fi > -if [[ ${#pkgname} -gt 20 ]] ; then errmsg $f: pkg name greater than 20 chars; fi > +if [[ ${#software} -gt ${NAME_MAX_LENGTH} ]] ; then errmsg $f: software name greater than 20 chars ; fi > +if [[ ${#pkgname} -gt ${NAME_MAX_LENGTH} ]] ; then errmsg $f: pkg name greater than 20 chars; fi First, ${NAME_MAX_LENGTH} should probably be in the output as well... When I noticed this I started wondering about the length of the package name. pkginfo(4) on Solaris 8 states that the maxlength is 9 chars and on Solaris 9 it is 32. Since we have packages with longer names than 9 chars and they install just fine on Solaris 8 I suspect that Sun raised the limit in some patch but never fixed the man page. But the question is have they raised it to 32 or something else. Does anyone know? From phil at bolthole.com Fri Jan 29 17:29:26 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 29 Jan 2010 08:29:26 -0800 Subject: [csw-maintainers] [csw-devel] SF.net SVN: gar:[8215] csw/mgar/gar/v2 In-Reply-To: <4B630AED.7040806@opencsw.org> References: <4B630AED.7040806@opencsw.org> Message-ID: On Fri, Jan 29, 2010 at 8:21 AM, Roger H?kansson wrote: > > > > First, ${NAME_MAX_LENGTH} should probably be in the output as well... > > When I noticed this I started wondering about the length of the package > name. > pkginfo(4) on Solaris 8 states that the maxlength is 9 chars and on Solaris > 9 it is 32. > Since we have packages with longer names than 9 chars and they install just > fine on Solaris 8 I suspect that Sun raised the limit in some patch but > never fixed the man page. > But the question is have they raised it to 32 or something else. Does anyone > know? > It's something like 32, yah. However, that being said, having super-long package names looks very ugly in system level outputs (eg: pkginfo), so we discourage it :) the "software name" is supposed to be the informative one anyway. From hson at opencsw.org Fri Jan 29 17:53:27 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 29 Jan 2010 17:53:27 +0100 Subject: [csw-maintainers] [csw-devel] SF.net SVN: gar:[8215] csw/mgar/gar/v2 In-Reply-To: References: <4B630AED.7040806@opencsw.org> Message-ID: <4B631287.1030203@opencsw.org> Philip Brown wrote: > > It's something like 32, yah. Ok > However, that being said, having > super-long package names looks very ugly in system level outputs (eg: > pkginfo), so we discourage it :) the "software name" is supposed to be > the informative one anyway. Sometimes its hard to cut down the name in some good way. gnome-object-introspection for example. goject-introspection is a common name in Linux dists, but its still too long an we also need a development package. CSWgobjectintrospectdev is still 24 chars... From phil at bolthole.com Fri Jan 29 18:11:49 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 29 Jan 2010 09:11:49 -0800 Subject: [csw-maintainers] [csw-devel] SF.net SVN: gar:[8215] csw/mgar/gar/v2 In-Reply-To: <4B631287.1030203@opencsw.org> References: <4B630AED.7040806@opencsw.org> <4B631287.1030203@opencsw.org> Message-ID: On Fri, Jan 29, 2010 at 8:53 AM, Roger H?kansson wrote: > > Sometimes its hard to cut down the name in some good way. > > gnome-object-introspection for example. > goject-introspection is a common name in Linux dists, but its still too long > an we also need a development package. > CSWgobjectintrospectdev is still 24 chars... > __________________________________ CSWgobjintrodev From dam at opencsw.org Fri Jan 29 23:24:28 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 29 Jan 2010 23:24:28 +0100 Subject: [csw-maintainers] [csw-buildfarm] Perl 5.10.1 on build test servers In-Reply-To: <625385e31001290557m2fe80722k66545d37249533f6@mail.gmail.com> References: <625385e31001290557m2fe80722k66545d37249533f6@mail.gmail.com> Message-ID: <63A43D71-BC2E-41D0-8B4F-1A84FF482F3E@opencsw.org> Hi Peter, Am 29.01.2010 um 14:57 schrieb Peter Bonivart: > Please install Perl 5.10.1 (from testing) on the build test servers, > build8st and build8xt, so we can start rebuilding modules for it. Doing this now. I get collisions of build8xt with /opt/csw/bin/config_data /opt/csw/bin/ptar /opt/csw/bin/ptardiff /opt/csw/bin/shasum /opt/csw/bin/config_data f none 0555 root bin 7244 11245 1200758331 CSWpmmodulebuild /opt/csw/bin/ptar f none 0555 root bin 2976 34189 1205448705 CSWpmarchivetar /opt/csw/bin/ptardiff f none 0555 root bin 2514 63805 1205448705 CSWpmarchivetar /opt/csw/bin/shasum f none 0555 root bin 7666 22683 1204981192 CSWpmdigestsha They have lots of dependencies which should then depend on Perl. Should CSWperl have additional conflicts with these? Or should they be stubs on CSWperl? > Anyone who want to help can look at the wiki page. Please update your > own modules first, next the ones from retired maintainers. Everything > must be in GAR. > > http://wiki.opencsw.org/perl Fwd'ing to maintainers@ Best regards -- Dago From bonivart at opencsw.org Sat Jan 30 14:36:11 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Sat, 30 Jan 2010 14:36:11 +0100 Subject: [csw-maintainers] [csw-buildfarm] Perl 5.10.1 on build test servers In-Reply-To: <63A43D71-BC2E-41D0-8B4F-1A84FF482F3E@opencsw.org> References: <625385e31001290557m2fe80722k66545d37249533f6@mail.gmail.com> <63A43D71-BC2E-41D0-8B4F-1A84FF482F3E@opencsw.org> Message-ID: <625385e31001300536v7f2932b9la0dc633143a0fa55@mail.gmail.com> On Fri, Jan 29, 2010 at 11:24 PM, Dagobert Michelsen wrote: > Doing this now. I get collisions of build8xt with > > ?/opt/csw/bin/config_data > ?/opt/csw/bin/ptar > ?/opt/csw/bin/ptardiff > ?/opt/csw/bin/shasum > > /opt/csw/bin/config_data f none 0555 root bin 7244 11245 1200758331 > CSWpmmodulebuild > /opt/csw/bin/ptar f none 0555 root bin 2976 34189 1205448705 CSWpmarchivetar > /opt/csw/bin/ptardiff f none 0555 root bin 2514 63805 1205448705 > CSWpmarchivetar > /opt/csw/bin/shasum f none 0555 root bin 7666 22683 1204981192 > CSWpmdigestsha > > They have lots of dependencies which should then depend on Perl. > Should CSWperl have additional conflicts with these? Or should they be stubs > on CSWperl? Yes, I've noticed those too but I'm not sure how we're going to find all possible collisions? Regarding what to do, I guess we need to make them empty packages until all packages depending on them have been rebuilt. We will have to file bugs on those packages. I'm repeating the link to our project page for those who want to help out: http://wiki.opencsw.org/perl -- /peter From maciej at opencsw.org Sun Jan 31 14:18:32 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 31 Jan 2010 13:18:32 +0000 Subject: [csw-maintainers] Wintercamp minutes in Google Wave In-Reply-To: References: Message-ID: On Sun, Jan 24, 2010 at 2:17 PM, Maciej (Matchek) Blizinski wrote: > We'll also provide a read-only export I looked for a way to present the minutes outside Wave, and ended up doing a copy/paste operation of the wave. I saved the resulting text file and attached it to the wiki page. The link is at the bottom. http://wiki.opencsw.org/wintercamp-2009-minutes My minutes are aimed at completeness rather than structure; in the original view you can clearly see things like bullet lists; in the text format they are gone. But it's still laid out in a way that makes it possible to read top to bottom, retaining the logical (but not necessarily chronological) structure of the discussion. Maciej From hson at opencsw.org Sun Jan 31 14:36:29 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Sun, 31 Jan 2010 14:36:29 +0100 Subject: [csw-maintainers] Wintercamp minutes in Google Wave In-Reply-To: References: Message-ID: <4B65875D.8010704@opencsw.org> Maciej (Matchek) Blizinski wrote: > I've shared the Wintercamp waves with a newly created Google Group, > called opencsw-maintainers. People who would like to read the wave, > can join this group, using Google accounts. When people have joined > the group, they can go to http://wave.google.com - the wave should be > in your wave inboxes. Well, it's not in my wave inbox after I joined... Anything special I have to do to see it? From maciej at opencsw.org Sun Jan 31 16:15:49 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 31 Jan 2010 15:15:49 +0000 Subject: [csw-maintainers] Wintercamp minutes in Google Wave In-Reply-To: <4B65875D.8010704@opencsw.org> References: <4B65875D.8010704@opencsw.org> Message-ID: On Sun, Jan 31, 2010 at 1:36 PM, Roger H?kansson wrote: > Maciej (Matchek) Blizinski wrote: >> >> I've shared the Wintercamp waves with a newly created Google Group, >> called opencsw-maintainers. People who would like to read the wave, >> can join this group, using Google accounts. When people have joined >> the group, they can go to http://wave.google.com - the wave should be >> in your wave inboxes. > > Well, it's not in my wave inbox after I joined... > Anything special I have to do to see it? Looks like the group doesn't work the way I hoped it would. Try this search: with:public tag:solaris From dam at opencsw.org Sun Jan 31 17:37:33 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 31 Jan 2010 17:37:33 +0100 Subject: [csw-maintainers] On updating Perl modules Message-ID: <25C6F9C5-34F2-4370-B95A-C362A946A10F@opencsw.org> Hi, when we now update all Perl modules we should take care they are linked against Perl. THis means "ldd -r" must not contain any errors of the form > symbol not found: Perl_safesysmalloc (work/ > solaris8-i386/pkgroot/opt/csw/lib/perl/csw/auto/BerkeleyDB/ > BerkeleyDB.so) > symbol not found: Perl_safesysfree (work/ > solaris8-i386/pkgroot/opt/csw/lib/perl/csw/auto/BerkeleyDB/ > BerkeleyDB.so) > symbol not found: Perl_safesysrealloc (work/ > solaris8-i386/pkgroot/opt/csw/lib/perl/csw/auto/BerkeleyDB/ > BerkeleyDB.so) > symbol not found: PL_memory_wrap (work/ > solaris8-i386/pkgroot/opt/csw/lib/perl/csw/auto/BerkeleyDB/ > BerkeleyDB.so) Maciej: Is the ldd -r check already activated? This is very important when libperl.so is used in embedding the Perl interpreter in other applications or subtle errors will occur like the one described here: http://www.opencsw.org/mantis/view.php?id=3766 Please read the enclosed debian report for details. Best regards -- Dago From maciej at opencsw.org Sun Jan 31 18:13:19 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 31 Jan 2010 17:13:19 +0000 Subject: [csw-maintainers] On updating Perl modules In-Reply-To: <25C6F9C5-34F2-4370-B95A-C362A946A10F@opencsw.org> References: <25C6F9C5-34F2-4370-B95A-C362A946A10F@opencsw.org> Message-ID: On Sun, Jan 31, 2010 at 4:37 PM, Dagobert Michelsen wrote: > Maciej: Is the ldd -r check already activated? No, I haven't gotten around to doing it yet. I'll see what I can do today. From maciej at opencsw.org Sun Jan 31 19:17:58 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 31 Jan 2010 18:17:58 +0000 Subject: [csw-maintainers] On updating Perl modules In-Reply-To: References: <25C6F9C5-34F2-4370-B95A-C362A946A10F@opencsw.org> Message-ID: On Sun, Jan 31, 2010 at 5:13 PM, Maciej (Matchek) Blizinski wrote: > On Sun, Jan 31, 2010 at 4:37 PM, Dagobert Michelsen wrote: >> Maciej: Is the ldd -r check already activated? > > No, I haven't gotten around to doing it yet. ?I'll see what I can do today. Done. It greps lines of ldd -r output for "symbol not found:". All the ldd -r output lines containing the phrase are printed at the end of checkpkg run. I also modified the output to be slightly nicer. Maciej From james at opencsw.org Sun Jan 31 19:40:18 2010 From: james at opencsw.org (James Lee) Date: Sun, 31 Jan 2010 18:40:18 GMT Subject: [csw-maintainers] /testing spamassassin In-Reply-To: <625385e31001261327k31719e1bo2bd90963eb99a3d2@mail.gmail.com> References: <625385e31001261327k31719e1bo2bd90963eb99a3d2@mail.gmail.com> Message-ID: <20100131.18401800.3054865960@gyor.oxdrove.co.uk> On 26/01/10, 21:27:49, Peter Bonivart wrote regarding [csw-maintainers] /testing spamassassin, bind, dhcp, dnstop: > - SpamAssassin 3.3.0, big update, note that no rules are delivered > from now on, only sa-update is supported. I've installed this and have it running. Two things that would help: 1. sa-update needs gpg and now that sa-update is needed CSWgpg should be added to the package depend list. # /opt/csw/bin/sa-update error: gpg required but not found! 2. The new package includes spamd start up code. This is good (saves me adding my own) but to change the spamd options requires editing /etc/opt/csw/init.d/cswspamd and the edits will be lost on package removal. Can we have a way of setting the spamd args from a conf file? ... find CONF ... ARGS=`cat $CONF` spamd -d $ARGS Other thoughts... The fist time it starts svc gets in a tiz because sa-update hasn't run. Perhaps needs some way of breaking the loop if not configured. Thanks for the package. James. From bonivart at opencsw.org Sun Jan 31 20:11:39 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 31 Jan 2010 20:11:39 +0100 Subject: [csw-maintainers] /testing spamassassin In-Reply-To: <20100131.18401800.3054865960@gyor.oxdrove.co.uk> References: <625385e31001261327k31719e1bo2bd90963eb99a3d2@mail.gmail.com> <20100131.18401800.3054865960@gyor.oxdrove.co.uk> Message-ID: <625385e31001311111h11e39f58x2b0df332e48f03b0@mail.gmail.com> On Sun, Jan 31, 2010 at 7:40 PM, James Lee wrote: > On 26/01/10, 21:27:49, Peter Bonivart wrote > regarding [csw-maintainers] /testing spamassassin, bind, dhcp, dnstop: > >> - SpamAssassin 3.3.0, big update, note that no rules are delivered >> from now on, only sa-update is supported. > > I've installed this and have it running. ?Two things that would help: > > > 1. sa-update needs gpg and now that sa-update is needed CSWgpg should be > added to the package depend list. > > # /opt/csw/bin/sa-update > error: gpg required but not found! > > > 2. The new package includes spamd start up code. ?This is good (saves > me adding my own) but to change the spamd options requires editing > /etc/opt/csw/init.d/cswspamd and the edits will be lost on package > removal. ?Can we have a way of setting the spamd args from a conf file? > > ... find CONF ... > ARGS=`cat $CONF` > spamd -d $ARGS > > > > > Other thoughts... > The fist time it starts svc gets in a tiz because sa-update hasn't > run. ?Perhaps needs some way of breaking the loop if not configured. > > > Thanks for the package. Thanks for testing, I haven't had time myself, very busy at work. I'll try to fix all of the above and spin a new package. For the options, would an extra file be good? I'm thinking about how we configure cswclassutils, like with this file for user/group creations: /etc/opt/csw/pkg//cswusergroup I also use this with my MailScanner package, delivering a MailScanner.CSW file that is treated like any config file, i.e. preserved. Here we could have: /etc/opt/csw/pkg/CSWspamassassin/spamd.CSW You could then edit spamd as needed and it would be preserved during upgrades and sourced by the init script. -- /peter From maciej at opencsw.org Sun Jan 31 22:26:20 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 31 Jan 2010 21:26:20 +0000 Subject: [csw-maintainers] [csw-devel] SF.net SVN: gar:[8215] csw/mgar/gar/v2 In-Reply-To: <4B630AED.7040806@opencsw.org> References: <4B630AED.7040806@opencsw.org> Message-ID: On Fri, Jan 29, 2010 at 4:21 PM, Roger H?kansson wrote: > wahwah at users.sourceforge.net wrote: > First, ${NAME_MAX_LENGTH} should probably be in the output as well... Done. From rupert.thurner at gmail.com Sat Jan 30 18:41:47 2010 From: rupert.thurner at gmail.com (rupert THURNER) Date: Sat, 30 Jan 2010 18:41:47 +0100 Subject: [csw-maintainers] build8s and ip-v6 for apr-1.4.2 Message-ID: <6af4271001300941h58c5a512ke935ab34d3c422ef@mail.gmail.com> hi, i tried to upgrade the apr package to 1.4.2, and it seems that ip-v6 is off / gone again on build8s, as the test case again produces an error. was there a special reason to disable it? rupert. From dam at opencsw.org Sun Jan 31 22:49:21 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 31 Jan 2010 22:49:21 +0100 Subject: [csw-maintainers] On updating Perl modules In-Reply-To: References: <25C6F9C5-34F2-4370-B95A-C362A946A10F@opencsw.org> Message-ID: Hi Maciej, Am 31.01.2010 um 19:17 schrieb Maciej (Matchek) Blizinski: > On Sun, Jan 31, 2010 at 5:13 PM, Maciej (Matchek) Blizinski > wrote: >> On Sun, Jan 31, 2010 at 4:37 PM, Dagobert Michelsen >> wrote: >>> Maciej: Is the ldd -r check already activated? >> >> No, I haven't gotten around to doing it yet. I'll see what I can >> do today. > > Done. It greps lines of ldd -r output for "symbol not found:". All > the ldd -r output lines containing the phrase are printed at the end > of checkpkg run. > > I also modified the output to be slightly nicer. Great! The test works, Bennys stuff already got rejected ;-) I have updated the "cpan" category to automatically bind against libperl.so if the use Makefile.PL starting with r8283. If you do *not* want to use this binding you can set BIND_LIBPERL = (nothing) in your GAR Makefile. If this works for a couple of modules I'm afraid we need to redo the packages. Sorry folks! Best regards -- Dago From dam at opencsw.org Sun Jan 31 22:59:36 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 31 Jan 2010 22:59:36 +0100 Subject: [csw-maintainers] build8s and ip-v6 for apr-1.4.2 In-Reply-To: <6af4271001300941h58c5a512ke935ab34d3c422ef@mail.gmail.com> References: <6af4271001300941h58c5a512ke935ab34d3c422ef@mail.gmail.com> Message-ID: Hi Rupert, Am 30.01.2010 um 18:41 schrieb rupert THURNER: > i tried to upgrade the apr package to 1.4.2, and it seems that ip-v6 > is off / gone again on build8s, as the test case again produces an > error. was there a special reason to disable it? No, I just rebooted the machine and due to a bug in Solaris IPv6 localhost interfaces don't get propagated into the zone automatically and I simply forgot to turn it on in this zone. It should work again. Sorry for the inconvenience! Please note that the best address for these issues is buildfarm@ Best regards -- Dago