From bwalton at opencsw.org Thu Apr 1 04:47:30 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 31 Mar 2010 22:47:30 -0400 Subject: [csw-maintainers] tcl/tk 8.5.8 and expect 5.43 In-Reply-To: <4BAFC95A.7000405@opencsw.org> References: <4BAFC95A.7000405@opencsw.org> Message-ID: <1270089868-sup-4604@pinkfloyd.chass.utoronto.ca> Excerpts from Roger H?kansson's message of Sun Mar 28 17:25:46 -0400 2010: > Please report any problem you encounter. How about successes? gitk and the ruby tk module both function with the updated packages. I'll try to build one or both of these packages on testing9* in the next day or so to exercise the 8.5 versions too. HTH. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Thu Apr 1 10:09:27 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 01 Apr 2010 10:09:27 +0200 Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 - Intel In-Reply-To: <4BB394FE.7070003@opencsw.org> ("Roger =?iso-8859-1?Q?H=E5kan?= =?iso-8859-1?Q?sson=22's?= message of "Wed, 31 Mar 2010 20:31:26 +0200") References: <4BB3247C.8040104@clamav.net> <4BB3423C.3050401@clamav.net> <4BB35DEC.4020805@opencsw.org> <4BB37B25.2050306@opencsw.org> <4BB3922D.3010407@opencsw.org> <4BB394FE.7070003@opencsw.org> Message-ID: Roger H?kansson writes: > On 2010-03-31 20:26, Peter FELECAN wrote: > >>> Not in it self, no, but when others start using that as basis for >>> optimizing/configuring their software things can go seriously >>> wrong. I've seen several packages where they use the output from gcc >>> to figure out which OS they are running and what features they can >>> use. >> >> Can you give one or more examples? > > Nah, I tend to forget the names of software faster than you can say... > >> What will solve that? Why? Arguments of the arguing, please. > > You have already gotten some, seems enough for me. Consequently, at this stage, I consider that there are no solid arguments in favor of your proposition. -- Peter From phil at bolthole.com Thu Apr 1 20:30:24 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 1 Apr 2010 11:30:24 -0700 Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 - Intel In-Reply-To: References: <4BB3247C.8040104@clamav.net> <4BB3423C.3050401@clamav.net> <4BB35DEC.4020805@opencsw.org> Message-ID: On Wed, Mar 31, 2010 at 7:46 AM, Dagobert Michelsen wrote: > > > +1 from me. But it breaks the long-hated NFS-for-all. Okay, we know - you dont like this method. That being said, I would request that we, as a group, and you particularly as a member of our board, refrain from making further remarks of this type? Okay, you dont like it. But there are still quite a few places that share out software via NFS. Or other methods that functional for packaging purposes, effectively similar to it. (eg: rsync) To talk like this, is to insult our customers' choices. Not a good thing at the best of times, but when the choice in this particular case is a perfectly valid one, especially makes us look bad. From bonivart at opencsw.org Thu Apr 1 22:30:04 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 1 Apr 2010 22:30:04 +0200 Subject: [csw-maintainers] /testing clamav 0.96, bind 9.7.0-P1 Message-ID: Please help testing the new Clam Antivirus and BIND DNS packages. You can find the packages here: http://mirror.opencsw.org/experimental.html#bonivart. Install with: pkgutil -t http://mirror.opencsw.org/opencsw/experimental/bonivart -i Direct links: http://mirror.opencsw.org/experimental/bonivart/clamav-0.96,REV=2010.04.01-SunOS5.9-sparc-CSW.pkg.gz http://mirror.opencsw.org/experimental/bonivart/clamav-0.96,REV=2010.04.01-SunOS5.9-i386-CSW.pkg.gz http://mirror.opencsw.org/experimental/bonivart/libclamav-0.96,REV=2010.04.01-SunOS5.9-i386-CSW.pkg.gz http://mirror.opencsw.org/experimental/bonivart/libclamav-0.96,REV=2010.04.01-SunOS5.9-sparc-CSW.pkg.gz http://mirror.opencsw.org/experimental/bonivart/bind-9.7.0P1,REV=2010.03.30-SunOS5.9-i386-CSW.pkg.gz http://mirror.opencsw.org/experimental/bonivart/bind-9.7.0P1,REV=2010.03.30-SunOS5.9-sparc-CSW.pkg.gz http://mirror.opencsw.org/experimental/bonivart/bind_utils-9.7.0P1,REV=2010.03.30-SunOS5.9-i386-CSW.pkg.gz http://mirror.opencsw.org/experimental/bonivart/bind_utils-9.7.0P1,REV=2010.03.30-SunOS5.9-sparc-CSW.pkg.gz http://mirror.opencsw.org/experimental/bonivart/libbind-9.7.0P1,REV=2010.03.30-SunOS5.9-i386-CSW.pkg.gz http://mirror.opencsw.org/experimental/bonivart/libbind-9.7.0P1,REV=2010.03.30-SunOS5.9-sparc-CSW.pkg.gz http://mirror.opencsw.org/experimental/bonivart/bind_chroot-9.7.0P1,REV=2010.03.30-SunOS5.9-all-CSW.pkg.gz http://mirror.opencsw.org/experimental/bonivart/bind_devel-9.7.0P1,REV=2010.03.30-SunOS5.9-all-CSW.pkg.gz -- /peter From hson at opencsw.org Fri Apr 2 00:21:44 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 02 Apr 2010 00:21:44 +0200 Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 - Intel In-Reply-To: References: <4BB3247C.8040104@clamav.net> <4BB3423C.3050401@clamav.net> <4BB35DEC.4020805@opencsw.org> Message-ID: <4BB51C78.4050409@opencsw.org> On 2010-04-01 20:30, Philip Brown wrote: > To talk like this, is to insult our customers' choices. Not a good > thing at the best of times, but when the choice in this particular > case is a perfectly valid one, especially makes us look bad. Sharing /opt between OS releases can never be considered a valid configuration and we should not try to support such a configuration either. Any "customer" choosing to try such setup, do it at their own risk. Having said that, we should try to support a "one NFS share per OS release" configuration which is common. (during my 20 years of working with SunOS 4/5, I've seen many configurations, netboot with filesystems on local disk, netboot with everything NFS-mounted, NFS-shared /usr... But I have never seen anyone try a NFS-for-all setup, there have always been different shares for different OS releases) From rupert at opencsw.org Fri Apr 2 10:33:59 2010 From: rupert at opencsw.org (rupert THURNER) Date: Fri, 2 Apr 2010 10:33:59 +0200 Subject: [csw-maintainers] python - illegal compiler flag ? Message-ID: while building mercurial-1.5.1 i got the error, on both build9s, and build9x: /opt/studio/SOS11/SUNWspro/bin/cc -G -m32 -xarch=386 -L/opt/csw/lib -xO3 -m32 -xarch=386 -xnorunpath -I/opt/csw/include build/temp.solaris-2.9-i86pc-2.6/mercurial/parsers.o -L/opt/csw/lib -lpython2.6 -o build/lib.solaris-2.9-i86pc-2.6/mercurial/parsers.so cc: Warning: illegal option -m32 cc: Warning: illegal option -m32 it compiles, so the package is on testing now. rupert From hson at opencsw.org Fri Apr 2 10:48:36 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 02 Apr 2010 10:48:36 +0200 Subject: [csw-maintainers] python - illegal compiler flag ? In-Reply-To: References: Message-ID: <4BB5AF64.90903@opencsw.org> On 2010-04-02 10:33, rupert THURNER wrote: > while building mercurial-1.5.1 i got the error, on both build9s, and build9x: > > /opt/studio/SOS11/SUNWspro/bin/cc -G -m32 -xarch=386 -L/opt/csw/lib > -xO3 -m32 -xarch=386 -xnorunpath -I/opt/csw/include > build/temp.solaris-2.9-i86pc-2.6/mercurial/parsers.o -L/opt/csw/lib > -lpython2.6 -o build/lib.solaris-2.9-i86pc-2.6/mercurial/parsers.so > cc: Warning: illegal option -m32 > cc: Warning: illegal option -m32 The SOS11 compiler doesn't like -m32, but you should be using SOS12 anyway... From hson at opencsw.org Fri Apr 2 11:30:07 2010 From: hson at opencsw.org (=?UTF-8?B?Um9nZXIgSMOla2Fuc3Nvbg==?=) Date: Fri, 02 Apr 2010 11:30:07 +0200 Subject: [csw-maintainers] 64-bit python (was evince-2.24.2 in experimental) In-Reply-To: References: <4B9614B0.7030503@cmi.univ-mrs.fr> <4B989CCA.2060409@opencsw.org> <4B98B139.8020001@opencsw.org> Message-ID: <4BB5B91F.1010107@opencsw.org> On 2010-03-11 10:07, Maciej (Matchek) Blizinski wrote: > On Thu, Mar 11, 2010 at 9:00 AM, Roger H?kansson wrote: >> On 2010-03-11 09:46, Maciej (Matchek) Blizinski wrote: >>> but lcms depends on Python, which is not, and >>> will not, in the nearest future, be available in 64-bit. >> >> Why not? > > I've looked at it once. Python headers do checks on certain 64-bit > related constants, which AFAIK are set by the compiler; the assertions > in the Python code are failing. > > "/opt/csw/include/python2.6/pyport.h", line 680: Error: #error > "LONG_BIT definition appears wrong for platform (bad gcc/glibc > config?).". > The problem is that you need to "merge" pyconfig.h from both 32-bit and 64-bit and add some ifdefs to switch between them. How/if this can be done using GAR I have no idea. From skayser at opencsw.org Fri Apr 2 22:26:34 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 02 Apr 2010 22:26:34 +0200 Subject: [csw-maintainers] Mantis privileges elevated to allow for easier cross-package collaboration Message-ID: <4BB652FA.2080006@opencsw.org> Greetings, as discussed in [1] I have finally elevated the global privileges for all maintainers in Mantis to DEVELOPER. This means, everyone should now be able to do everyday work on bugs (like moving or assigning) for _all_ packages, not just the ones which one specifically owns. Questions or anything not working as expected? Please let me know. Sebastian [1]http://lists.opencsw.org/pipermail/maintainers/2010-January/011158.html From rupert at opencsw.org Sat Apr 3 16:03:02 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 3 Apr 2010 16:03:02 +0200 Subject: [csw-maintainers] opensolaris command more compliant - what is opencsw solution ? Message-ID: hi, the mercurial testsuite relies on which returning something non 0 in case nothing is found. the standard solaris csh script returns 0. the opensolaris which fixed this, see http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/which/which.csh 53 if ( ! $?found ) then 54 echo no $arg in $path 55 set exit_status = 1 56 endif 57 end 58 59 exit ${exit_status} 60 what is the strategy we follow in opencsw in such cases? rupert. From bwalton at opencsw.org Sat Apr 3 18:54:53 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 03 Apr 2010 12:54:53 -0400 Subject: [csw-maintainers] opensolaris command more compliant - what is opencsw solution ? In-Reply-To: References: Message-ID: <1270313646-sup-8139@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Sat Apr 03 10:03:02 -0400 2010: Hi Rupert, > the mercurial testsuite relies on which returning something non 0 in > case nothing is found. the standard solaris csh script returns 0. The following ruby script, if placed with precedence somewhere in your PATH during the mercurial build[1] would likely work. It's not full featured, but should do the trick, I think. You'd want to then add CSWruby as a build prerequisite too (or rewrite in perl or python, etc). --snip-- #!/opt/csw/bin/ruby -w ENV['PATH'].split(':').each do |p| begin prog = File.join(p, ARGV[0]) f = File.stat(prog) rescue Errno::ENOENT => e # file doesn't exist in this path # this also catches dangling symlinks... next else # file does exist. is it usable? if f.file? and f.executable? puts prog exit 0 end end end $stderr.puts "#{ARGV[0]} not found in #{ENV['PATH'].gsub(':', ' ')}" exit 1 --snip-- I wasn't aware of this breakage in `which.` There is a proper which available here: http://www.xs4all.nl/~carlo17/which/. Looks like Maciej was working on it already...Maciej, are there build issues with it? Thanks -Ben [1] Add the script as 'which' in your files/ directory, make it +x and do: PATH := $(FILEDIR):$(PATH) in your GAR recipe...this is rough, but should be close to what you need to make it work. -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From jeff at cjsa.com Sun Apr 4 08:27:08 2010 From: jeff at cjsa.com (Jeffery Small) Date: Sun, 4 Apr 2010 06:27:08 GMT Subject: [csw-maintainers] Upgrade problems?? Message-ID: I have encountered this problem twice now and strongly believe that it is related to doing a pkg-get upgrade operation. The problem is that I don't discover the actual problem until long after the upgrade procedure which I didn't pay close attention to at the time. The problem is that I have had some programs - notably xpdf, uninstalled and then not reinstalled after the upgrade. I don't notice this until I try to use xpdf. When I do discover this, I manually install xpdf again, and I get the following messages: Analysing special files... Please see /opt/csw/share/doc/xpdf/license for license information. WARNING: /opt/csw/bin/pdffonts WARNING: /opt/csw/bin/pdfimages WARNING: /opt/csw/bin/pdfinfo WARNING: /opt/csw/bin/pdftoppm WARNING: /opt/csw/bin/pdftops WARNING: /opt/csw/bin/pdftotext Installation of was successful. I remember seeing this message the last time I had to manually reinstalled xpdf. Are these messages normal and expected, or do they indicate a conflict with some other package? When I do a pkgchk -l CSWxpdf, it reports that files like pdffonts, pdfimages, pdfinfo, pdftoppm, pdftops, and pdftotext are referenced by packages CSWpoppler and CSWxpdf. I'm gonna' take a guess here and say that there may be a conflict between these two packages and that may somehow be responsible for CSWxpdf getting trashed - possibly when CSWpoppler is upgraded? Any thoughts or comments? Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From hson at opencsw.org Sun Apr 4 09:18:33 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Sun, 04 Apr 2010 09:18:33 +0200 Subject: [csw-maintainers] Upgrade problems?? In-Reply-To: References: Message-ID: <4BB83D49.20806@opencsw.org> On 2010-04-04 08:27, Jeffery Small wrote: >When I do a pkgchk -l CSWxpdf, it > reports that files like pdffonts, pdfimages, pdfinfo, pdftoppm, pdftops, > and pdftotext are referenced by packages CSWpoppler and CSWxpdf. I'm gonna' > take a guess here and say that there may be a conflict between these two > packages and that may somehow be responsible for CSWxpdf getting trashed - > possibly when CSWpoppler is upgraded? Yes there is a conflict between CSWpoppler and CSWxpdf due to the fact that poppler is a fork of the xpdf source and they have kept the binary names. CSWpoppler have CSWxpdf marked as incompatible so you should not be able to install it by mistake, however CSWxpdf does not have CSWpoppler as incompatible (yet). From bwalton at opencsw.org Mon Apr 5 03:45:41 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 04 Apr 2010 21:45:41 -0400 Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 - Intel In-Reply-To: References: <4BB3247C.8040104@clamav.net> <4BB3423C.3050401@clamav.net> <4BB35DEC.4020805@opencsw.org> Message-ID: <1270431512-sup-8336@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Apr 01 14:30:24 -0400 2010: > That being said, I would request that we, as a group, and you > particularly as a member of our board, refrain from making further > remarks of this type? And what is a valid forum for discussing our past decisions in order to (possibly) re-examine them? It's perfectly legitimate, imo, to discuss things like this on the maintainers list...if not here then where? Private email among a cabal of select individuals?[1][2] > To talk like this, is to insult our customers' choices. Not a good > thing at the best of times, but when the choice in this particular > case is a perfectly valid one, especially makes us look bad. It was _clearly_ not Dago's intent to insult anyone with his remarks. Anyone that would take offense at the comment is someone that's easily offended in general... Thanks -Ben [1] No, I'm not being serious here, just pointing out that this list really is our only valid place for the discussion to happen. [2] I'm also in no way proposing a private mailing list here. Being open is a good thing. -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Apr 5 03:48:21 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 04 Apr 2010 21:48:21 -0400 Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 - Intel In-Reply-To: References: <4BB3247C.8040104@clamav.net> <4BB3423C.3050401@clamav.net> Message-ID: <1270431962-sup-7422@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Mar 31 10:19:31 -0400 2010: > I already bumped gcc4 to the latest versions and it compiles > (although it takes a day or so), merging is tbd. Ok, so if we ignore the isaexec issue (which exists in the current package anyway), could we simply re-roll for sol9, add a postinstall script that does the fixincludes ala Peter's gcc3 packages and get something out? A more long term solution could follow later... Thoughts? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From jeff at cjsa.com Mon Apr 5 04:05:17 2010 From: jeff at cjsa.com (Jeffery Small) Date: Mon, 5 Apr 2010 02:05:17 GMT Subject: [csw-maintainers] Upgrade problems?? References: <4BB83D49.20806@opencsw.org> Message-ID: "=?ISO-8859-1?Q?Roger_H=E5kansson?=" writes: >On 2010-04-04 08:27, Jeffery Small wrote: >>When I do a pkgchk -l CSWxpdf, it >> reports that files like pdffonts, pdfimages, pdfinfo, pdftoppm, pdftops, >> and pdftotext are referenced by packages CSWpoppler and CSWxpdf. I'm gonna' >> take a guess here and say that there may be a conflict between these two >> packages and that may somehow be responsible for CSWxpdf getting trashed - >> possibly when CSWpoppler is upgraded? >Yes there is a conflict between CSWpoppler and CSWxpdf due to the fact >that poppler is a fork of the xpdf source and they have kept the binary >names. CSWpoppler have CSWxpdf marked as incompatible so you should not >be able to install it by mistake, however CSWxpdf does not have >CSWpoppler as incompatible (yet). CSWpoppler is a rendering library while CSWxpdf is a PDF viewer. CSWpoppler is required for evince, gimp and claws_pdfviewer, so it is crucial. So how can you allow this type of incompatibility which should make it impossible to install xpdf? Why hasn't xpdf been fixed to rely on CSWpoppler? Making these packages incompatible is no solution. I do not understand why CSWpoppler ever got released with this incompatibility intact? Stuff like this makes the entire CSW tree unpredictable. You can't have one package simply removing another! And I consider xpdf to be a very valuable program. It's 5 times faster than Adobe Reader. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From hson at opencsw.org Mon Apr 5 07:13:32 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Mon, 05 Apr 2010 07:13:32 +0200 Subject: [csw-maintainers] Mantis privileges elevated to allow for easier cross-package collaboration In-Reply-To: <4BB652FA.2080006@opencsw.org> References: <4BB652FA.2080006@opencsw.org> Message-ID: <4BB9717C.4020006@opencsw.org> On 2010-04-02 22:26, Sebastian Kayser wrote: > Greetings, > > as discussed in [1] I have finally elevated the global privileges for > all maintainers in Mantis to DEVELOPER. This means, everyone should now > be able to do everyday work on bugs (like moving or assigning) for _all_ > packages, not just the ones which one specifically owns. Weee! Great work! From william at wbonnet.net Mon Apr 5 11:54:37 2010 From: william at wbonnet.net (William Bonnet) Date: Mon, 05 Apr 2010 11:54:37 +0200 Subject: [csw-maintainers] Mantis privileges elevated to allow for easier cross-package collaboration In-Reply-To: <4BB652FA.2080006@opencsw.org> References: <4BB652FA.2080006@opencsw.org> Message-ID: <4BB9B35D.5060109@wbonnet.net> Hi Sebastian > as discussed in [1] I have finally elevated the global privileges for > all maintainers in Mantis to DEVELOPER. This means, everyone should now > be able to do everyday work on bugs (like moving or assigning) for _all_ > packages, not just the ones which one specifically owns. > > Questions or anything not working as expected? Please let me know. > > Sebastian > > [1]http://lists.opencsw.org/pipermail/maintainers/2010-January/011158.html > 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 pfelecan at opencsw.org Mon Apr 5 14:58:06 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 05 Apr 2010 14:58:06 +0200 Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 - Intel In-Reply-To: <1270431962-sup-7422@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Sun, 04 Apr 2010 21:48:21 -0400") References: <4BB3247C.8040104@clamav.net> <4BB3423C.3050401@clamav.net> <1270431962-sup-7422@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > Excerpts from Dagobert Michelsen's message of Wed Mar 31 10:19:31 -0400 2010: > >> I already bumped gcc4 to the latest versions and it compiles >> (although it takes a day or so), merging is tbd. > > Ok, so if we ignore the isaexec issue (which exists in the current > package anyway), could we simply re-roll for sol9, add a postinstall > script that does the fixincludes ala Peter's gcc3 packages and get > something out? > A more long term solution could follow later... In what what you propose above is not a long term solution (at least until a new upstream release comes out which is anyway, already the case) ? -- Peter From pfelecan at opencsw.org Mon Apr 5 15:02:45 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 05 Apr 2010 15:02:45 +0200 Subject: [csw-maintainers] Mantis privileges elevated to allow for easier cross-package collaboration In-Reply-To: <4BB652FA.2080006@opencsw.org> (Sebastian Kayser's message of "Fri, 02 Apr 2010 22:26:34 +0200") References: <4BB652FA.2080006@opencsw.org> Message-ID: Sebastian Kayser writes: > as discussed in [1] I have finally elevated the global privileges for > all maintainers in Mantis to DEVELOPER. This means, everyone should now > be able to do everyday work on bugs (like moving or assigning) for _all_ > packages, not just the ones which one specifically owns. > > Questions or anything not working as expected? Please let me know. > > Sebastian > > [1]http://lists.opencsw.org/pipermail/maintainers/2010-January/011158.html And this answers to what requirement(s)? Strangely, the assignment was not a feature available for a "developer" in the messages that you refer but now it changes? -- Peter From bwalton at opencsw.org Mon Apr 5 16:12:01 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 05 Apr 2010 10:12:01 -0400 Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 - Intel In-Reply-To: References: <4BB3247C.8040104@clamav.net> <4BB3423C.3050401@clamav.net> <1270431962-sup-7422@pinkfloyd.chass.utoronto.ca> Message-ID: <1270476641-sup-3510@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Mon Apr 05 08:58:06 -0400 2010: > In what what you propose above is not a long term solution (at least > until a new upstream release comes out which is anyway, already the > case) ? Well, it _could_ be a long term solution, I guess, but given that Dago has identified other issues with the package, presumably someone will care enough to address those too at some point... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From skayser at opencsw.org Mon Apr 5 19:06:44 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 05 Apr 2010 19:06:44 +0200 Subject: [csw-maintainers] Mantis privileges elevated to allow for easier cross-package collaboration In-Reply-To: References: <4BB652FA.2080006@opencsw.org> Message-ID: <4BBA18A4.8010809@opencsw.org> Peter FELECAN wrote on 05.04.2010 15:02: > Sebastian Kayser writes: > >> as discussed in [1] I have finally elevated the global privileges for >> all maintainers in Mantis to DEVELOPER. This means, everyone should now >> be able to do everyday work on bugs (like moving or assigning) for _all_ >> packages, not just the ones which one specifically owns. >> >> Questions or anything not working as expected? Please let me know. >> >> Sebastian >> >> [1]http://lists.opencsw.org/pipermail/maintainers/2010-January/011158.html > > And this answers to what requirement(s)? Is this a sincere question (not quite sure, your mails seemed to have a touch of irony/sarcasm lately)? It just makes working on/with bugs easier for maintainers. Bugs against orphaned packages can now be worked on before you officially release/adopt the package. If you mis-file a bug against the wrong package (like it happened with multiple tabs and the Mantis cookie mechanism of tracking the currently active project) you can move it yourself, without calling upon an administrator. In the end it gives everyone a bit more flexibility. > Strangely, the assignment was not a feature available for a "developer" > in the messages that you refer but now it changes? The key in Roger's message was "if I remember". As it stands, developers can assign bugs out of the box, no change required. Sebastian From hson at opencsw.org Mon Apr 5 19:11:41 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Mon, 05 Apr 2010 19:11:41 +0200 Subject: [csw-maintainers] Mantis privileges elevated to allow for easier cross-package collaboration In-Reply-To: References: <4BB652FA.2080006@opencsw.org> Message-ID: <4BBA19CD.40003@opencsw.org> On 2010-04-05 15:02, Peter FELECAN wrote: > Sebastian Kayser writes: > >> as discussed in [1] I have finally elevated the global privileges for >> all maintainers in Mantis to DEVELOPER. This means, everyone should now >> be able to do everyday work on bugs (like moving or assigning) for _all_ >> packages, not just the ones which one specifically owns. >> >> Questions or anything not working as expected? Please let me know. >> >> Sebastian >> >> [1]http://lists.opencsw.org/pipermail/maintainers/2010-January/011158.html > > And this answers to what requirement(s)? First of all, we have a ton of packages either orphaned or "owned" by absent/retired/... maintainers and if someone else starts to work on fixing a bug, he can't communicate with the bug reporter as its intended (set the status to feedback) until he has released a new package and becomes maintainer for the package. Also, another problem which also relates to orphaned packages is this: Say that you want to fix a problem in package A (which you are maintainer for) which depends on B which depends on C which depends on D. And you know that the problem is solved by upgrading/turning on a config-option in D so that C can autoconfig itself differently so B behaves diffrently which fixes the problem in A. Mantis have a good feature where you can daisy-chain bugs so you can see which bug needs to be fixed first and when its fixed the next maintainer can move on and so on. Without developer access the only way for the maintainer of A to achieve this is to report a bug on each package, mail the maintainers and ask them to manually chain them, and in case of orphaned packages, ask the admins to do it, even though the maintainer of A could do this all by him self if he had the correct permissions. (Which you can do now) > Strangely, the assignment was not a feature available for a "developer" > in the messages that you refer but now it changes? Well, thats my fault, I remembered wrong what privileges a "developer" and a "manager" has, its been a while since I ran Mantis... From pfelecan at opencsw.org Mon Apr 5 20:27:35 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 05 Apr 2010 20:27:35 +0200 Subject: [csw-maintainers] Mantis privileges elevated to allow for easier cross-package collaboration In-Reply-To: <4BBA18A4.8010809@opencsw.org> (Sebastian Kayser's message of "Mon, 05 Apr 2010 19:06:44 +0200") References: <4BB652FA.2080006@opencsw.org> <4BBA18A4.8010809@opencsw.org> Message-ID: Sebastian Kayser writes: > Peter FELECAN wrote on 05.04.2010 15:02: >> Sebastian Kayser writes: >> >>> as discussed in [1] I have finally elevated the global privileges for >>> all maintainers in Mantis to DEVELOPER. This means, everyone should now >>> be able to do everyday work on bugs (like moving or assigning) for _all_ >>> packages, not just the ones which one specifically owns. >>> >>> Questions or anything not working as expected? Please let me know. >>> >>> Sebastian >>> >>> [1]http://lists.opencsw.org/pipermail/maintainers/2010-January/011158.html >> >> And this answers to what requirement(s)? > > Is this a sincere question (not quite sure, your mails seemed to have a > touch of irony/sarcasm lately)? What make you doubt my sincerity? Of course, there were irony about the oldish releases of our beloved operating system but other than that... > It just makes working on/with bugs easier for maintainers. Bugs against > orphaned packages can now be worked on before you officially > release/adopt the package. If you mis-file a bug against the wrong > package (like it happened with multiple tabs and the Mantis cookie > mechanism of tracking the currently active project) you can move it > yourself, without calling upon an administrator. In the end it gives > everyone a bit more flexibility. That I understand. >> Strangely, the assignment was not a feature available for a "developer" >> in the messages that you refer but now it changes? > > The key in Roger's message was "if I remember". As it stands, developers > can assign bugs out of the box, no change required. I didn't knew that. Thank you for the answers. -- Peter From pfelecan at opencsw.org Mon Apr 5 20:31:00 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 05 Apr 2010 20:31:00 +0200 Subject: [csw-maintainers] Mantis privileges elevated to allow for easier cross-package collaboration In-Reply-To: <4BBA19CD.40003@opencsw.org> ("Roger =?iso-8859-1?Q?H=E5kanss?= =?iso-8859-1?Q?on=22's?= message of "Mon, 05 Apr 2010 19:11:41 +0200") References: <4BB652FA.2080006@opencsw.org> <4BBA19CD.40003@opencsw.org> Message-ID: Roger H?kansson writes: > On 2010-04-05 15:02, Peter FELECAN wrote: >> Sebastian Kayser writes: >> >>> as discussed in [1] I have finally elevated the global privileges for >>> all maintainers in Mantis to DEVELOPER. This means, everyone should now >>> be able to do everyday work on bugs (like moving or assigning) for _all_ >>> packages, not just the ones which one specifically owns. >>> >>> Questions or anything not working as expected? Please let me know. >>> >>> Sebastian >>> >>> [1]http://lists.opencsw.org/pipermail/maintainers/2010-January/011158.html >> >> And this answers to what requirement(s)? > > First of all, we have a ton of packages either orphaned or "owned" by > absent/retired/... maintainers and if someone else starts to work on > fixing a bug, he can't communicate with the bug reporter as its > intended (set the status to feedback) until he has released a new > package and becomes maintainer for the package. > > Also, another problem which also relates to orphaned packages is this: > Say that you want to fix a problem in package A (which you are > maintainer for) which depends on B which depends on C which depends on > D. And you know that the problem is solved by upgrading/turning on a > config-option in D so that C can autoconfig itself differently so B > behaves diffrently which fixes the problem in A. > Mantis have a good feature where you can daisy-chain bugs so you can > see which bug needs to be fixed first and when its fixed the next > maintainer can move on and so on. > Without developer access the only way for the maintainer of A to > achieve this is to report a bug on each package, mail the maintainers > and ask them to manually chain them, and in case of orphaned packages, > ask the admins to do it, even though the maintainer of A could do this > all by him self if he had the correct permissions. > (Which you can do now) Thank you for this very satisfactory explanation. >> Strangely, the assignment was not a feature available for a "developer" >> in the messages that you refer but now it changes? > > Well, thats my fault, I remembered wrong what privileges a "developer" > and a "manager" has, its been a while since I ran Mantis... Alright, I wasn't aware about the ability to assign in that way. I'm not very comfortable but can live with. Thank you again. -- Peter From dam at opencsw.org Mon Apr 5 20:52:00 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Apr 2010 20:52:00 +0200 Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 - Intel In-Reply-To: References: <4BB3247C.8040104@clamav.net> <4BB3423C.3050401@clamav.net> <4BB35DEC.4020805@opencsw.org> Message-ID: <129795FD-8094-419A-A48F-D64F0FE9383B@opencsw.org> Hi Phil, Am 01.04.2010 um 20:30 schrieb Philip Brown: > On Wed, Mar 31, 2010 at 7:46 AM, Dagobert Michelsen wrote: >> +1 from me. But it breaks the long-hated NFS-for-all. > > Okay, we know - you dont like this method. > That being said, I would request that we, as a group, and you > particularly as a member of our board, refrain from making further > remarks of this type? > > Okay, you dont like it. But there are still quite a few places that > share out software via NFS. > Or other methods that functional for packaging purposes, effectively > similar to it. > (eg: rsync) > > To talk like this, is to insult our customers' choices. Not a good > thing at the best of times, but when the choice in this particular > case is a perfectly valid one, especially makes us look bad. Then I would like to request two things: 1. Make clear what we actually support and how we do that. NFS from Solaris 9 to Solaris 10? Only from Solaris 10 to Solaris 10? How are configuration files are handled? RC-Scripts? SMF? etc. 2. At least one maintainer who actually drives things in terms of NFS-sharing-compliance. I am willing to do some courtesy work, but this goes beyond my line. If the big shops want this feature they can provide someone who works on it. Best regards -- Dago From dam at opencsw.org Mon Apr 5 21:06:40 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Apr 2010 21:06:40 +0200 Subject: [csw-maintainers] python - illegal compiler flag ? In-Reply-To: References: Message-ID: <8CCF2CE7-E5C8-4546-83C4-80A640EEA67E@opencsw.org> Hi Rupert, Am 02.04.2010 um 10:33 schrieb rupert THURNER: > while building mercurial-1.5.1 i got the error, on both build9s, and build9x: > > /opt/studio/SOS11/SUNWspro/bin/cc -G -m32 -xarch=386 -L/opt/csw/lib > -xO3 -m32 -xarch=386 -xnorunpath -I/opt/csw/include > build/temp.solaris-2.9-i86pc-2.6/mercurial/parsers.o -L/opt/csw/lib > -lpython2.6 -o build/lib.solaris-2.9-i86pc-2.6/mercurial/parsers.so > cc: Warning: illegal option -m32 > cc: Warning: illegal option -m32 > > it compiles, so the package is on testing now. This is strange. GAR doesn't use -m32 on SOS11, I just checked ([1]). Is this added by mercurial itself? Best regards -- Dago [1] http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/gar.conf.mk#L322 From dam at opencsw.org Mon Apr 5 21:11:11 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Apr 2010 21:11:11 +0200 Subject: [csw-maintainers] 64-bit python (was evince-2.24.2 in experimental) In-Reply-To: <4BB5B91F.1010107@opencsw.org> References: <4B9614B0.7030503@cmi.univ-mrs.fr> <4B989CCA.2060409@opencsw.org> <4B98B139.8020001@opencsw.org> <4BB5B91F.1010107@opencsw.org> Message-ID: <715E80A5-F3EE-4EE0-8D5E-393DBFF9AC48@opencsw.org> Hi Roger, Am 02.04.2010 um 11:30 schrieb Roger H?kansson: > On 2010-03-11 10:07, Maciej (Matchek) Blizinski wrote: >> On Thu, Mar 11, 2010 at 9:00 AM, Roger H?kansson wrote: >>> On 2010-03-11 09:46, Maciej (Matchek) Blizinski wrote: >>>> but lcms depends on Python, which is not, and >>>> will not, in the nearest future, be available in 64-bit. >>> >>> Why not? >> >> I've looked at it once. Python headers do checks on certain 64-bit >> related constants, which AFAIK are set by the compiler; the assertions >> in the Python code are failing. >> >> "/opt/csw/include/python2.6/pyport.h", line 680: Error: #error >> "LONG_BIT definition appears wrong for platform (bad gcc/glibc >> config?).". > > The problem is that you need to "merge" pyconfig.h from both 32-bit and 64-bit and add some ifdefs to switch between them. > How/if this can be done using GAR I have no idea. There is currently no built-in in GAR to do this as I have only encountered this (headers different between 32/64 bit) once: for curl. The solution is to make a wrapper for the header which branches for 32/64 bit and then pull in the renamed "real" includes like this: > /* Allow 32 and 64 bit headers to coexist */ > #if defined __amd64 || defined __x86_64 || defined __sparcv9 > #include "curlbuild-64.h" > #else > #include "curlbuild-32.h" > #endif The renaming in GAR is done during merge like this: > EXTRA_PAX_ARGS_32 = -s ",^\.$(includedir)/curl/curlbuild.h$$,.$(includedir)/curl/curlbuild-32.h,p" > EXTRA_PAX_ARGS_64 = -s ",^\.$(includedir)/curl/curlbuild.h$$,.$(includedir)/curl/curlbuild-64.h,p" > EXTRA_PAX_ARGS = $(EXTRA_PAX_ARGS_$(MEMORYMODEL)) Best regards -- Dago From dam at opencsw.org Mon Apr 5 21:23:01 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Apr 2010 21:23:01 +0200 Subject: [csw-maintainers] Upgrade problems?? In-Reply-To: <4BB83D49.20806@opencsw.org> References: <4BB83D49.20806@opencsw.org> Message-ID: <205A0887-D833-4F66-BE24-3384479BF838@opencsw.org> Hi, Am 04.04.2010 um 09:18 schrieb Roger H?kansson: > On 2010-04-04 08:27, Jeffery Small wrote: >> When I do a pkgchk -l CSWxpdf, it >> reports that files like pdffonts, pdfimages, pdfinfo, pdftoppm, pdftops, >> and pdftotext are referenced by packages CSWpoppler and CSWxpdf. I'm gonna' >> take a guess here and say that there may be a conflict between these two >> packages and that may somehow be responsible for CSWxpdf getting trashed - >> possibly when CSWpoppler is upgraded? > > Yes there is a conflict between CSWpoppler and CSWxpdf due to the fact that poppler is a fork of the xpdf source and they have kept the binary names. CSWpoppler have CSWxpdf marked as incompatible so you should not be able to install it by mistake, however CSWxpdf does not have CSWpoppler as incompatible (yet). Maybe the binaries should be suffixed with the package like xpdf.xpdf xpdf.poppler with alternatives for selection? Would circument the ugly "Incompatible". Best regards -- Dago From dam at opencsw.org Mon Apr 5 21:25:27 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Apr 2010 21:25:27 +0200 Subject: [csw-maintainers] Upgrade problems?? In-Reply-To: References: <4BB83D49.20806@opencsw.org> Message-ID: Hi Jeff, Am 05.04.2010 um 04:05 schrieb Jeffery Small: > Stuff like this makes the entire CSW tree unpredictable. You can't have > one package simply removing another! And I consider xpdf to be a very > valuable program. It's 5 times faster than Adobe Reader. Thank you for reporting this. I am sure we find a viable solution for your problem soon. A more elaborated testing staga has been suggested on the list but unfortunately hasn't been implemented yet. Best regards -- Dago [1] http://wiki.opencsw.org/releases-and-staging From phil at opencsw.org Mon Apr 5 21:39:51 2010 From: phil at opencsw.org (Philip Brown) Date: Mon, 5 Apr 2010 12:39:51 -0700 Subject: [csw-maintainers] cswpkgloghooks, shell choices Message-ID: (redirected from the pkgsubmissions list: prior subject [csw-pkgsubmissions] newpkgs cswpkgloghooks ) On Thu, Apr 1, 2010 at 12:02 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Thu Apr 01 14:55:57 -0400 2010: > >> Although really, better still would be to just program in standard sh > > Standard sh sucks. ?I won't use it for anything other than forking > something useful. > ksh is standard (been there since almost forever), and is even on boot cdroms. But you wont use that either, I presume.... The true reason, I'm guessing, being that "it's not bash" :-) From bwalton at opencsw.org Mon Apr 5 21:46:49 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 05 Apr 2010 15:46:49 -0400 Subject: [csw-maintainers] cswpkgloghooks, shell choices In-Reply-To: References: Message-ID: <1270496520-sup-4923@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Apr 05 15:39:51 -0400 2010: > ksh is standard (been there since almost forever), and is even on > boot cdroms. But you wont use that either, I presume.... The true > reason, I'm guessing, being that "it's not bash" :-) You presume wrong. If I was familiar with ksh, I'd turn to that first. I'm not...and I see _zero_ value in learning it in 2010. Bash is 'standard enough' as it's on sol8+, which for CSW purposes is all that's required. It lets me do things without calling out to external tools for something simple like this, which is why I didn't turn to xpg4/bin/sh. If, hypothetically, bash isn't an acceptable, my next tool (when looking for something widely available) would be perl... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Apr 5 21:47:46 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 05 Apr 2010 15:47:46 -0400 Subject: [csw-maintainers] cswpkgloghooks, shell choices In-Reply-To: References: Message-ID: <1270496821-sup-4261@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Apr 05 15:39:51 -0400 2010: > > Standard sh sucks. ?I won't use it for anything other than forking > > something useful. To clarify this, I'm referring to /bin/sh. It should be actively avoided in my opinion. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert at opencsw.org Mon Apr 5 22:00:21 2010 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 5 Apr 2010 22:00:21 +0200 Subject: [csw-maintainers] python - illegal compiler flag ? In-Reply-To: <8CCF2CE7-E5C8-4546-83C4-80A640EEA67E@opencsw.org> References: <8CCF2CE7-E5C8-4546-83C4-80A640EEA67E@opencsw.org> Message-ID: On Mon, Apr 5, 2010 at 21:06, Dagobert Michelsen wrote: > Hi Rupert, > > Am 02.04.2010 um 10:33 schrieb rupert THURNER: >> while building mercurial-1.5.1 i got the error, on both build9s, and build9x: >> >> /opt/studio/SOS11/SUNWspro/bin/cc -G -m32 -xarch=386 -L/opt/csw/lib >> -xO3 -m32 -xarch=386 -xnorunpath -I/opt/csw/include >> build/temp.solaris-2.9-i86pc-2.6/mercurial/parsers.o -L/opt/csw/lib >> -lpython2.6 -o build/lib.solaris-2.9-i86pc-2.6/mercurial/parsers.so >> cc: Warning: illegal option -m32 >> cc: Warning: illegal option -m32 >> >> it compiles, so the package is on testing now. > > This is strange. GAR doesn't use -m32 on SOS11, I just checked ([1]). Is this > added by mercurial itself? to my knowledge setuptools compilation use the flags used to compile python. rupert. From dam at opencsw.org Mon Apr 5 22:02:27 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Apr 2010 22:02:27 +0200 Subject: [csw-maintainers] python - illegal compiler flag ? In-Reply-To: References: <8CCF2CE7-E5C8-4546-83C4-80A640EEA67E@opencsw.org> Message-ID: Hi Rupert, Am 05.04.2010 um 22:00 schrieb rupert THURNER: > On Mon, Apr 5, 2010 at 21:06, Dagobert Michelsen wrote: >> Hi Rupert, >> >> Am 02.04.2010 um 10:33 schrieb rupert THURNER: >>> while building mercurial-1.5.1 i got the error, on both build9s, and build9x: >>> >>> /opt/studio/SOS11/SUNWspro/bin/cc -G -m32 -xarch=386 -L/opt/csw/lib >>> -xO3 -m32 -xarch=386 -xnorunpath -I/opt/csw/include >>> build/temp.solaris-2.9-i86pc-2.6/mercurial/parsers.o -L/opt/csw/lib >>> -lpython2.6 -o build/lib.solaris-2.9-i86pc-2.6/mercurial/parsers.so >>> cc: Warning: illegal option -m32 >>> cc: Warning: illegal option -m32 >>> >>> it compiles, so the package is on testing now. >> >> This is strange. GAR doesn't use -m32 on SOS11, I just checked ([1]). Is this >> added by mercurial itself? > > to my knowledge setuptools compilation use the flags used to compile python. Than most certainly Python was compiled with Sun Studio 12 and you hardwired CC to Sun Studio 11 :-) Best regards -- Dago From phil at bolthole.com Mon Apr 5 22:03:33 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 5 Apr 2010 13:03:33 -0700 Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 - Intel In-Reply-To: <1270431512-sup-8336@pinkfloyd.chass.utoronto.ca> References: <4BB3247C.8040104@clamav.net> <4BB3423C.3050401@clamav.net> <4BB35DEC.4020805@opencsw.org> <1270431512-sup-8336@pinkfloyd.chass.utoronto.ca> Message-ID: On Sun, Apr 4, 2010 at 6:45 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Thu Apr 01 14:30:24 -0400 2010: > >> To talk like this, is to insult our customers' choices. Not a good >> thing at the best of times, but when the choice in this particular >> case is a perfectly valid one, especially makes us look bad. > > It was _clearly_ not Dago's intent to insult anyone with his remarks. > Anyone that would take offense at the comment is someone that's easily > offended in general... > That is a very debian approach. I would like to say that is one aspect of debian, i would like to NOT replicate at opencsw. From phil at bolthole.com Mon Apr 5 22:11:22 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 5 Apr 2010 13:11:22 -0700 Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 - Intel In-Reply-To: <129795FD-8094-419A-A48F-D64F0FE9383B@opencsw.org> References: <4BB3247C.8040104@clamav.net> <4BB3423C.3050401@clamav.net> <4BB35DEC.4020805@opencsw.org> <129795FD-8094-419A-A48F-D64F0FE9383B@opencsw.org> Message-ID: On Mon, Apr 5, 2010 at 11:52 AM, Dagobert Michelsen wrote: > Hi Phil, > *wave* > Then I would like to request two things: > > 1. Make clear what we actually support and how we do that. > NFS from Solaris 9 to Solaris 10? Only from Solaris 10 to > Solaris 10? How are configuration files are handled? > RC-Scripts? SMF? etc. A very sensible request. Thank you for taking things forward constructively :) I agree that we should probably document this sort of thing more. And I am willing to take this "action item" and implement it myself. Hopefully, I will have some time tonight to do it, or wednesday worst case. > 2. At least one maintainer who actually drives things in terms > of NFS-sharing-compliance. I am willing to do some courtesy > work, but this goes beyond my line. If the big shops want this > feature they can provide someone who works on it. It would appear that I am probably the point person on this sort of thing. But I welcome help from other maintainers as well. Or, even other folks. As Secretary, perhaps you might solicit a request for interested parties on the users' list, Dago? For people who currently deploy in "shared read-only /opt" in some capacity, and are interested in making csw packages better in that area? You could mention that this might not actually require maintaining a package, but be more of a tech resource, and "focus group", if you will. From bwalton at opencsw.org Mon Apr 5 22:20:01 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 05 Apr 2010 16:20:01 -0400 Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 - Intel In-Reply-To: References: <4BB3247C.8040104@clamav.net> <4BB3423C.3050401@clamav.net> <4BB35DEC.4020805@opencsw.org> <1270431512-sup-8336@pinkfloyd.chass.utoronto.ca> Message-ID: <1270498757-sup-9582@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Apr 05 16:03:33 -0400 2010: > On Sun, Apr 4, 2010 at 6:45 PM, Ben Walton wrote: > > Excerpts from Philip Brown's message of Thu Apr 01 14:30:24 -0400 2010: > > > >> To talk like this, is to insult our customers' choices. Not a good > >> thing at the best of times, but when the choice in this particular > >> case is a perfectly valid one, especially makes us look bad. > > > > It was _clearly_ not Dago's intent to insult anyone with his remarks. > > Anyone that would take offense at the comment is someone that's easily > > offended in general... > > > > That is a very debian approach. Ok, now I'm completely lost...Debian approach? Confused. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Mon Apr 5 22:23:54 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 5 Apr 2010 13:23:54 -0700 Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 - Intel In-Reply-To: <1270498757-sup-9582@pinkfloyd.chass.utoronto.ca> References: <4BB3247C.8040104@clamav.net> <4BB3423C.3050401@clamav.net> <4BB35DEC.4020805@opencsw.org> <1270431512-sup-8336@pinkfloyd.chass.utoronto.ca> <1270498757-sup-9582@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Apr 5, 2010 at 1:20 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Mon Apr 05 16:03:33 -0400 2010: >> That is a very debian approach. > > Ok, now I'm completely lost...Debian approach? I was referring to, >> > Anyone that would take offense at the comment is someone that's easily >> > offended in general... ie: "if someone gets offended, it's THEIR fault, not the speaker". but anyways, I'm happy that we now have a positive direction to move towards, so I dont have anything further to say about it. From phil at bolthole.com Mon Apr 5 22:31:43 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 5 Apr 2010 13:31:43 -0700 Subject: [csw-maintainers] cswpkgloghooks, shell choices In-Reply-To: <1270496520-sup-4923@pinkfloyd.chass.utoronto.ca> References: <1270496520-sup-4923@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Apr 5, 2010 at 12:46 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Mon Apr 05 15:39:51 -0400 2010: > >> ksh is standard (been there since almost forever), and is even on >> boot cdroms. ?But you wont use that either, I presume.... The true >> reason, I'm guessing, being that "it's not bash" :-) > > You presume wrong. ?If I was familiar with ksh, I'd turn to that > first. oh, wonderful! >?I'm not...and I see _zero_ value in learning it in 2010. ?Bash > is 'standard enough' except that this reinforces my original assumption :-} but hang on a minute.... > as it's on sol8+, which for CSW purposes is all > that's required. ?It lets me do things without calling out to external > tools for something simple like this, which is why I didn't turn to > xpg4/bin/sh. > Some points for your consideration,though: 1. /bin/ksh actually has most of the useful features of xpg4/bin/sh 2. Similarly, most built-in things in bash, are also built-in for ksh. PS; technically, i think bash is still *optional* for sol8. It's not in SUNWCreq It's also "optional" in sol9. again, not in SUNWCreq. Checking... Nope, it's not in sol10 SUNWCreq either. So it's still in "optional" status for sol10! But ksh is *always* there. (It's part of SUNWcsu, even) From phil at bolthole.com Mon Apr 5 22:33:19 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 5 Apr 2010 13:33:19 -0700 Subject: [csw-maintainers] cswpkgloghooks, shell choices In-Reply-To: References: <1270496520-sup-4923@pinkfloyd.chass.utoronto.ca> Message-ID: PPS: On Mon, Apr 5, 2010 at 1:31 PM, Philip Brown wrote: > > 1. /bin/ksh actually has most of the useful features of xpg4/bin/sh > actually, ksh virtually IS xpg4/bin/sh... but with extras too :) From phil at bolthole.com Mon Apr 5 22:37:55 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 5 Apr 2010 13:37:55 -0700 Subject: [csw-maintainers] Upgrade problems?? In-Reply-To: <4BB83D49.20806@opencsw.org> References: <4BB83D49.20806@opencsw.org> Message-ID: On Sun, Apr 4, 2010 at 12:18 AM, Roger H?kansson wrote: > On 2010-04-04 08:27, Jeffery Small wrote: >> >> When I do a pkgchk -l CSWxpdf, it >> reports that files like pdffonts, pdfimages, pdfinfo, pdftoppm, pdftops, >> and pdftotext are referenced by packages CSWpoppler and CSWxpdf. ?I'm >> gonna' >> take a guess here and say that there may be a conflict between these two >> packages and that may somehow be responsible for CSWxpdf getting trashed - >> possibly when CSWpoppler is upgraded? > > Yes there is a conflict between CSWpoppler and CSWxpdf due to the fact that > poppler is a fork of the xpdf source and they have kept the binary names. > CSWpoppler have CSWxpdf marked as incompatible so you should not be able to > install it by mistake, however CSWxpdf does not have CSWpoppler as > incompatible (yet). > ________________ aaak. you should have kept the older poppler package ideosyncracies! Roger, please repackage poppler along the old package standards. that is to say: nothing in /opt/csw/bin Then you can remove the xpdf conflict also. From bwalton at opencsw.org Tue Apr 6 01:06:32 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 05 Apr 2010 19:06:32 -0400 Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 - Intel In-Reply-To: References: <4BB3247C.8040104@clamav.net> <4BB3423C.3050401@clamav.net> <4BB35DEC.4020805@opencsw.org> <1270431512-sup-8336@pinkfloyd.chass.utoronto.ca> <1270498757-sup-9582@pinkfloyd.chass.utoronto.ca> Message-ID: <1270508554-sup-357@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Apr 05 16:23:54 -0400 2010: > >> > Anyone that would take offense at the comment is someone that's easily > >> > offended in general... > > ie: "if someone gets offended, it's THEIR fault, not the speaker". I've seen this theme pop up a few times lately (in completely unrelated contexts) and I'll say it again: Taking offense at something is stupid. It implies that the speaker should put their own thoughts at a lesser standing than the 'hearer.' The notion of offense is that of taking a non-personal statement and being insulted by it. So, if you take offense at something, it's inherently your 'fault' for doing so. It restricts the ability of someone to properly speak their mind which leads us to the insane levels of political correctness we have today. Had Dago specified someone/something personal then yes, someone could rightly take _insult_ at such a statement. That is clearly not the case here. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Tue Apr 6 01:47:57 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 5 Apr 2010 16:47:57 -0700 Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 - Intel In-Reply-To: <1270508554-sup-357@pinkfloyd.chass.utoronto.ca> References: <4BB3247C.8040104@clamav.net> <4BB35DEC.4020805@opencsw.org> <1270431512-sup-8336@pinkfloyd.chass.utoronto.ca> <1270498757-sup-9582@pinkfloyd.chass.utoronto.ca> <1270508554-sup-357@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Apr 5, 2010 at 4:06 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Mon Apr 05 16:23:54 -0400 2010: > >> >> > Anyone that would take offense at the comment is someone that's easily >> >> > offended in general... >> >> ie: "if someone gets offended, it's THEIR fault, not the speaker". >.... > > Had Dago specified someone/something personal then yes, someone could > rightly take _insult_ at such a statement. ?That is clearly not the > case here. > perhaps I wasnt being clear in my choice of words earlier. I dont think that Dago's remark was directed at any one person in general. I dont believe it was a "personal attack" on anyone. That being said, there's more than one way to cause insult. Some 3rd party examples, that may or may not resonate with you: When Sun decided, many years ago, to drop solaris x86, I felt insulted, as a customer. When Oracle decided recently, to limit licensing of solaris to no longer be 100%, all the time, and require a support contract for ALL deployments, I felt insulted, as a customer. A remark, or action, does not have to be directed at a specific person, to cause "insult" to a customer. To state it in a more directly relevant fashion: When a business, or organization, says, "the way that you choose to run your IT department, is stupid/dumb/obsolete/'hated' "... That Is Insulting. And that was what happened here. From bwalton at opencsw.org Tue Apr 6 01:50:07 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 05 Apr 2010 19:50:07 -0400 Subject: [csw-maintainers] cswpkgloghooks, shell choices In-Reply-To: References: <1270496520-sup-4923@pinkfloyd.chass.utoronto.ca> Message-ID: <1270511253-sup-8840@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Apr 05 16:33:19 -0400 2010: > actually, ksh virtually IS xpg4/bin/sh... but with extras too :) Yes, but as stated earlier, I already know the extras in bash and am not interested in learning the idiosyncrasies of yet another shell. (Read: I'm not interested in doing everything in your view of 'the solaris way.') The only change I'd make from bash is to perl, for the originally stated reason. Learning ksh in 2010 is of _zero_ value to _me_. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From james at opencsw.org Tue Apr 6 10:58:12 2010 From: james at opencsw.org (James Lee) Date: Tue, 06 Apr 2010 08:58:12 GMT Subject: [csw-maintainers] Upgrade problems?? In-Reply-To: References: <4BB83D49.20806@opencsw.org> Message-ID: <20100406.8581200.3876240886@gyor.oxdrove.co.uk> On 05/04/10, 20:25:27, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Upgrade problems??: > Am 05.04.2010 um 04:05 schrieb Jeffery Small: > > Stuff like this makes the entire CSW tree unpredictable. You can't have > > one package simply removing another! And I consider xpdf to be a very > > valuable program. It's 5 times faster than Adobe Reader. > Thank you for reporting this. I am sure we find a viable solution for > your problem soon. A more elaborated testing staga has been suggested > on the list but unfortunately hasn't been implemented yet. http://www.opencsw.org/bugtrack/view.php?id=4339 and I'll add I feel insulted. James. From dam at opencsw.org Tue Apr 6 11:39:43 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 6 Apr 2010 11:39:43 +0200 Subject: [csw-maintainers] Upgrade problems?? In-Reply-To: <20100406.8581200.3876240886@gyor.oxdrove.co.uk> References: <4BB83D49.20806@opencsw.org> <20100406.8581200.3876240886@gyor.oxdrove.co.uk> Message-ID: <2D34D1F7-A07E-4A18-97A5-8E25801956A2@opencsw.org> Hi James, Am 06.04.2010 um 10:58 schrieb James Lee: > On 05/04/10, 20:25:27, Dagobert Michelsen wrote > regarding > Re: [csw-maintainers] Upgrade problems??: > >> Am 05.04.2010 um 04:05 schrieb Jeffery Small: >>> Stuff like this makes the entire CSW tree unpredictable. You >>> can't have >>> one package simply removing another! And I consider xpdf to be a >>> very >>> valuable program. It's 5 times faster than Adobe Reader. > >> Thank you for reporting this. I am sure we find a viable solution for >> your problem soon. A more elaborated testing staga has been suggested >> on the list but unfortunately hasn't been implemented yet. > > http://www.opencsw.org/bugtrack/view.php?id=4339 > > and I'll add I feel insulted. Why is that? You found the problem, but as it looks the "fix" from Roger was not appropriate. As we don't have release stages between current and stable the updated poppler hit users from current/ instead of something before that. IMHO it would be good to have a release stage before current which gets promoted to current if there are no more known issues. Best regards -- Dago From dam at opencsw.org Tue Apr 6 16:22:58 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 6 Apr 2010 16:22:58 +0200 Subject: [csw-maintainers] About SUNW X11, CSW X11 and OpenGL Message-ID: <61E55267-65C7-426B-A7DA-709110EF1E4A@opencsw.org> Hi, I am experimenting in doing specific compiles for SUNW X11 and CSW X11 to provide accelerated 3D with SUNW X11 while allowing up-to-date packages with OpenCSW X11. Some notes: (1) Package names and contents I suggest making different sets of packages, CSW bound against SUNW X11 CSWx11 bound against OpenCSW X11 where conforms to regular naming standards, like *rt, etc. The files in CSWx11 are in /opt/csw/X11/* while the files for CSW are in regular /opt/csw/(lib|...) locations. This way existing binaries without OpenCSW X11 can continue to work. Only CSWx11 depends on CSWx11smi, CSWx11libx11, etc. (2) OpenGL Solaris 9 doesn't have an OpenGL binding by default. There is one at for Solaris 9 Sparc, but not x86. Solaris 10 has a bundled gl.h, but in GL/gl.h where e.h. giflib checks for gl/gl.h. Are these different libs or is there a link or something missing? And when I compile on Solaris 9 SUNWglrt is an optional package which I can not rely on. How should I proceed here? Compile without OpenGL on Solaris 9 and only depend on Solaris 10 builtin OpenGL? The first set of packages (giflib) compiled without OpenGL on Solaris 9 only, separate CSW X11 and SUNW X11 version is available at for inspection. Best regards -- Dago From phil at bolthole.com Tue Apr 6 21:08:17 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 6 Apr 2010 12:08:17 -0700 Subject: [csw-maintainers] About SUNW X11, CSW X11 and OpenGL In-Reply-To: <61E55267-65C7-426B-A7DA-709110EF1E4A@opencsw.org> References: <61E55267-65C7-426B-A7DA-709110EF1E4A@opencsw.org> Message-ID: On Tue, Apr 6, 2010 at 7:22 AM, Dagobert Michelsen wrote: > > (2) OpenGL > Solaris 9 doesn't have an OpenGL binding by default. I dont even understand that statement. What do you mean, "binding" ? > And when I compile > on Solaris 9 SUNWglrt is an optional package which I can not rely > on. How should I proceed here? Compile without OpenGL on Solaris 9 > and only depend on Solaris 10 builtin OpenGL? compile against OUR OpenGL providing package, which Makes Things Work, automagically. (mesalibs, if I recall correct) it provides libGL. it also provides the headers. Then if sun opengl is present, the program will use that at runtime. Its that aux filter thing again. From phil at bolthole.com Tue Apr 6 21:44:31 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 6 Apr 2010 12:44:31 -0700 Subject: [csw-maintainers] reminder about "incompatible packages" Message-ID: Hi folks, a reminder about marking packages as "incompatible": It is NOT okay to ship the same executables (in the exact same path) as another package, and just mark your package as "incompatible" with the other one. All packages sitting in "current", must peacably co-exist with each other. The "incompatible" flag, is only to be used when a NEW package, is designed to override an OLD package, that *no longer exists*, in our current repository. From phil at bolthole.com Wed Apr 7 04:54:34 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 6 Apr 2010 19:54:34 -0700 Subject: [csw-maintainers] use of /opt/csw/etc Message-ID: btw, I hope to find time to write up some stuff on NFS tomorrow. but while I think of it, here is an example of appropriate "global configuration" in /opt/csw/etc that I just found in our packages: /opt/csw/etc/fontconfig/fonts.conf Without a "fonts.conf" file, fontconfig basically Does Not Work. So you must supply one, across all machines you deploy /opt/csw to. And, it is very unlikely (to say the least), that you would ever need to have machine-local tweaks to this file. It is basically configured at pkgadd time, and never messed with. Although ideally, a package would allow for sysadmin customization, and create the global one from a presumed template. which our fontconfig package unfortunately does not :-} From skayser at opencsw.org Wed Apr 7 20:11:13 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 7 Apr 2010 20:11:13 +0200 Subject: [csw-maintainers] Mantis privileges elevated to allow for easier cross-package collaboration In-Reply-To: References: <4BB652FA.2080006@opencsw.org> <4BBA18A4.8010809@opencsw.org> Message-ID: <20100407181113.GS27943@sebastiankayser.de> * Peter FELECAN wrote: > Sebastian Kayser writes: > > > Peter FELECAN wrote on 05.04.2010 15:02: > >> Sebastian Kayser writes: > >> > >>> as discussed in [1] I have finally elevated the global privileges for > >>> all maintainers in Mantis to DEVELOPER. This means, everyone should now > >>> be able to do everyday work on bugs (like moving or assigning) for _all_ > >>> packages, not just the ones which one specifically owns. > >>> > >>> Questions or anything not working as expected? Please let me know. > >>> > >>> Sebastian > >>> > >>> [1]http://lists.opencsw.org/pipermail/maintainers/2010-January/011158.html > >> > >> And this answers to what requirement(s)? > > > > Is this a sincere question (not quite sure, your mails seemed to have a > > touch of irony/sarcasm lately)? > > What make you doubt my sincerity? Of course, there were irony about the > oldish releases of our beloved operating system but other than that... Nothing in particular. The requirement seemed obvious to me after a couple of groans from those dealing quite frequently with bugs, thus I wanted to avoid any ambiguity. Sorry in case it came across harsher than it should have. Thanks Roger for the comprehensive explanation. Sebastian From maciej at opencsw.org Thu Apr 8 18:05:02 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 8 Apr 2010 16:05:02 +0000 Subject: [csw-maintainers] checkpkg: Detecting file conflicts (wrt the recent ev.h conflict) Message-ID: File conflicts appear to be a frequent problem. There has recently been a collision between two packages providing ev.h header. It also seems like Python 3.1 tries to provide /opt/csw/lib/python/os.py -- a file which is already provided by Python 2.6. I'm thinking of implementing a check catching file collisions. Directories would be excluded from the check. What do you think about such check? Maciej From bwalton at opencsw.org Thu Apr 8 18:20:20 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 08 Apr 2010 12:20:20 -0400 Subject: [csw-maintainers] checkpkg: Detecting file conflicts (wrt the recent ev.h conflict) In-Reply-To: References: Message-ID: <1270743588-sup-5079@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Thu Apr 08 12:05:02 -0400 2010: > file which is already provided by Python 2.6. I'm thinking of > implementing a check catching file collisions. Directories would be > excluded from the check. What do you think about such check? I think it's a great idea. As long as it's not too heavy, and I don't see why it would be, it should be a nice addition. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Thu Apr 8 19:22:12 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 8 Apr 2010 10:22:12 -0700 Subject: [csw-maintainers] checkpkg: Detecting file conflicts (wrt the recent ev.h conflict) In-Reply-To: References: Message-ID: On Thu, Apr 8, 2010 at 9:05 AM, Maciej (Matchek) Blizinski wrote: > File conflicts appear to be a frequent problem. ?There has recently > been a collision between two packages providing ev.h header. ?It also > seems like Python 3.1 tries to provide /opt/csw/lib/python/os.py -- a > file which is already provided by Python 2.6. ?I'm thinking of > implementing a check catching file collisions. ?Directories would be > excluded from the check. ?What do you think about such check? > it's a good point that we "need something". I dont see how you could possibly implement something on the GAR side though. The good news is... I'm now doing it where it belongs. in our package database. (or at least trying to now. there's a certain amount of cleanup I have to do first. Like eliminating all the "directory" entries, leaving just the "file" entries :-/ ) From phil at bolthole.com Thu Apr 8 22:07:05 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 8 Apr 2010 13:07:05 -0700 Subject: [csw-maintainers] sparc assembly, gcc vs cc Message-ID: Sooo.. I found a problem with "libffi". It contains the following evil, buried in the middle of a function call: /* Flush the Icache. FIXME: alignment isn't certain, assume 8 bytes */ asm volatile ("iflush %0" : : "r" (closure) : "memory"); asm volatile ("iflush %0" : : "r" (((char *) closure) + 8) : "memory"); Does anyone have any idea how to convert this mess into something that will be Sun CC compatible? From phil at bolthole.com Thu Apr 8 23:44:01 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 8 Apr 2010 14:44:01 -0700 Subject: [csw-maintainers] sparc assembly, gcc vs cc In-Reply-To: References: Message-ID: On Thu, Apr 8, 2010 at 1:07 PM, Philip Brown wrote: > Sooo.. I found a problem with "libffi". > ?It contains the following evil, buried in the middle of a function call: > > ?/* Flush the Icache. ?FIXME: alignment isn't certain, assume 8 bytes */ > > ?asm volatile ("iflush %0" : : "r" (closure) : "memory"); > ?asm volatile ("iflush %0" : : "r" (((char *) closure) + 8) : "memory"); > > > Does anyone have any idea how to convert this mess into something that > will be Sun CC compatible? > found the answer mesself. turns out, sun cc (12 or better) actually does support this sort of thing.. but ONLY if you turn optimization on. Even -xO1 will do. From phil at bolthole.com Fri Apr 9 01:50:46 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 8 Apr 2010 16:50:46 -0700 Subject: [csw-maintainers] poppler back-revved to stable version Message-ID: FYI: I have backrevved poppler to stable version, because of inconsistencies. I now hope to continue to move forward with pending submitted pakages. From phil at bolthole.com Fri Apr 9 21:38:52 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 9 Apr 2010 12:38:52 -0700 Subject: [csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw In-Reply-To: <1269452532-sup-9950@pinkfloyd.chass.utoronto.ca> References: <740D4C44-60A7-4734-9180-C4F3FBECAD3B@opencsw.org> <1269360409-sup-6150@pinkfloyd.chass.utoronto.ca> <1269367768-sup-3364@pinkfloyd.chass.utoronto.ca> <1269438807-sup-5650@pinkfloyd.chass.utoronto.ca> <1269452532-sup-9950@pinkfloyd.chass.utoronto.ca> Message-ID: Going back a waaaaayyys... On Wed, Mar 24, 2010 at 10:44 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Wed Mar 24 13:38:04 -0400 2010: > >> i'm not surprised. which is why I reiterate my suggestion that we >> should merely duplicate the user-level interface (and only the bits >> we actually care about), and thus avoid extra baggage. > > But why reinvent the wheel? ?The wheel is already round and mostly > works. Because "fully works" is better than "mostly works" >?With some tweaks, that as you say, should be acceptable > upstream since they wouldn't harm the original environment, it'd be > perfectly round for us too. Thanks to Dago's writeups on the wiki spaces, I now have a better understanding of how "alternatives" works. And I now also understand Dagobert's reticence on this issue... sadly, I dont think that this would be fixable in the redhat implementation without majorly reengineering the way it currently works. > Anyway. ?Since I'm not going to do the work in either scenario, I'll > be quiet now. Well, I am happy to say that this week, I found both my old spirit of development, and time to indulge it, for a while! I have now written a mostly complete, from scratch implementation of "alternatives" (in ksh of course:) It currently stands at 230 lines. 52 of those are comments. "Simpler is Better". I anticipate "version 1.0" to be somewhere below 300 lines. Readable, functional, and fully compatible with ALL our needs, rather than only "mostly". If I dont produce a test version for public consumption by tuesday, someone please give me a nudge :) From hson at opencsw.org Fri Apr 9 21:59:13 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 09 Apr 2010 21:59:13 +0200 Subject: [csw-maintainers] Upgrade problems?? In-Reply-To: References: <4BB83D49.20806@opencsw.org> Message-ID: <4BBF8711.3080901@opencsw.org> On 2010-04-05 04:05, Jeffery Small wrote: > > CSWpoppler is a rendering library while CSWxpdf is a PDF viewer. > > CSWpoppler is required for evince, gimp and claws_pdfviewer, And evince and claws_pdfviewer is also PDF viewers, whats your point? Since poppler is a fork of the xpdf code without building the actual viewer its not surprising that there are conflicts. Which is why I made CSWpoppler have CSWxpdf as a incompatible package, then you'll get to choose which you want. From hson at opencsw.org Fri Apr 9 22:03:03 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 09 Apr 2010 22:03:03 +0200 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs xpdf, xpdf_utils In-Reply-To: References: <201004051421.o35ELHXH020806@login.bo.opencsw.org> Message-ID: <4BBF87F7.7080809@opencsw.org> On 2010-04-06 00:11, Philip Brown wrote: > On Mon, Apr 5, 2010 at 7:21 AM, Benjamin von Mossner wrote: >> Hi Phil, >> >> due to the conflict between CSWpoppler and CSWxpdf (#0004390) >> xpdf is now split into two separate packages. >> > > well hold off there... > this doesnt properly resolve it. > poppler is the one abusing the namespace. poppler is the one that > needs to split. > particularly since it was previously split anyways. This most surely is the proper way to solve it. As I've stated before, poppler is a fork of the xpdf code, so why should we decide which is the proper "pdftotext". If you take a look at other dists, some have both xpdf, xpdf_utils and poppler(_utils) where poppler(_utils) and xpdf_utils are providing the same things, i.e are incompatible and the users get to choose which to install. From hson at opencsw.org Fri Apr 9 22:13:00 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 09 Apr 2010 22:13:00 +0200 Subject: [csw-maintainers] Upgrade problems?? In-Reply-To: <20100406.8581200.3876240886@gyor.oxdrove.co.uk> References: <4BB83D49.20806@opencsw.org> <20100406.8581200.3876240886@gyor.oxdrove.co.uk> Message-ID: <4BBF8A4C.1000903@opencsw.org> On 2010-04-06 10:58, James Lee wrote: > > http://www.opencsw.org/bugtrack/view.php?id=4339 > > > and I'll add I feel insulted. > Insulted by what? From phil at bolthole.com Fri Apr 9 22:23:26 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 9 Apr 2010 13:23:26 -0700 Subject: [csw-maintainers] Upgrade problems?? In-Reply-To: <4BBF8711.3080901@opencsw.org> References: <4BB83D49.20806@opencsw.org> <4BBF8711.3080901@opencsw.org> Message-ID: On Fri, Apr 9, 2010 at 12:59 PM, Roger H?kansson wrote: > On 2010-04-05 04:05, Jeffery Small wrote: >> >> CSWpoppler is a rendering library while CSWxpdf is a PDF viewer. >> >> CSWpoppler is required for evince, gimp and claws_pdfviewer, > > And evince and claws_pdfviewer is also PDF viewers, whats your point? > The missing piece of the puzzle here, is that this pulls up a bit of legacy naming problem. evince, etc. have depended on "CSWpoppler" for a long time now. The problem is that the actual contents of the package, would more accurately be described as "libpoppler". One way of getting us closer to sanity, would be to take the following steps. 1. Create new "libpoppler" packages, and submit them as official packages. (I unfortunately had to wipe the old ones), for conflicts of some sort. 2. Create an empty CSWpoppler and submit that for now also. This would have the benefit of getting newer versions of the poppler libs into our existing evince packages, and potentialy allowing newer ones to be built, too 3. recompile evince, and the handful of other things currently depending on "CSWpoppler", to properly depend on CSWlibpoppler From phil at bolthole.com Fri Apr 9 22:25:33 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 9 Apr 2010 13:25:33 -0700 Subject: [csw-maintainers] Upgrade problems?? In-Reply-To: <4BBF8711.3080901@opencsw.org> References: <4BB83D49.20806@opencsw.org> <4BBF8711.3080901@opencsw.org> Message-ID: PS: On Fri, Apr 9, 2010 at 12:59 PM, Roger H?kansson wrote: > .... Which is why I made CSWpoppler > have CSWxpdf as a incompatible package, then you'll get to choose which you > want. the proper way to do this, is to rework both the xpdf package, and poppler, to use CSWalternatives. NOT, to mark packages as "incompatible" with other current packages. Please note: maintainers of xpdf and poppler will have to work together, to agree which should be the "default" xpdf, if both packages are installed. From hson at opencsw.org Fri Apr 9 22:44:37 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 09 Apr 2010 22:44:37 +0200 Subject: [csw-maintainers] Upgrade problems?? In-Reply-To: References: <4BB83D49.20806@opencsw.org> <4BBF8711.3080901@opencsw.org> Message-ID: <4BBF91B5.40906@opencsw.org> On 2010-04-09 22:25, Philip Brown wrote: > the proper way to do this, is to rework both the xpdf package, and > poppler, to use CSWalternatives. > NOT, to mark packages as "incompatible" with other current packages. > > Please note: maintainers of xpdf and poppler will have to work > together, to agree which should be the "default" xpdf, if both > packages are installed. Regarding xpdf, there is no collision, its the utilities (pdftotext...) that collide, which was why I suggested to Benny that he also split them out to a separate package and we make them (poppler and xpdf_utils incompatible). From phil at bolthole.com Fri Apr 9 22:48:32 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 9 Apr 2010 13:48:32 -0700 Subject: [csw-maintainers] Upgrade problems?? In-Reply-To: <4BBF91B5.40906@opencsw.org> References: <4BB83D49.20806@opencsw.org> <4BBF8711.3080901@opencsw.org> <4BBF91B5.40906@opencsw.org> Message-ID: On Fri, Apr 9, 2010 at 1:44 PM, Roger H?kansson wrote: > > Regarding xpdf, there is no collision, its the utilities (pdftotext...) that > collide, which was why I suggested to Benny that he also split them out to a > separate package and we make them (poppler and xpdf_utils incompatible). > split to separate package: okay make incompatible: not okay. From hson at opencsw.org Fri Apr 9 22:55:51 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 09 Apr 2010 22:55:51 +0200 Subject: [csw-maintainers] About SUNW X11, CSW X11 and OpenGL In-Reply-To: <61E55267-65C7-426B-A7DA-709110EF1E4A@opencsw.org> References: <61E55267-65C7-426B-A7DA-709110EF1E4A@opencsw.org> Message-ID: <4BBF9457.4080508@opencsw.org> On 2010-04-06 16:22, Dagobert Michelsen wrote: > Hi, > > I am experimenting in doing specific compiles for SUNW X11 and > CSW X11 to provide accelerated 3D with SUNW X11 while allowing > up-to-date packages with OpenCSW X11. Some notes: > > (1) Package names and contents > I suggest making different sets of packages, > CSW bound against SUNW X11 > CSWx11 bound against OpenCSW X11 > where conforms to regular naming standards, like *rt, etc. > The files in CSWx11 are in /opt/csw/X11/* while the files for > CSW are in regular /opt/csw/(lib|...) locations. This way > existing binaries without OpenCSW X11 can continue to work. > Only CSWx11 depends on CSWx11smi, CSWx11libx11, etc. > Wait a minute, you're proposing that we start releasing two versions of the same package for a ton of packages? And the number will also increase a lot in the near future. I've been working on updating some gnome-apps and I think I have more than 20 new packages which the gnome-guys have added as build dependencies for gnome packages which we need to update (in order to release updated versions of applications). Don't you think this will become a nightmare where in the end many packages with libraries need to be built in two versions just because some end-application need OpenCSW X11? Lets say gimp were to need OpenCSW X11, the imagemagick would need to be built in two versions, graphviz, ghostscript... all the way through the dependency chain. If you take a look at the list of packages on the "project X11" page, its not a small list and then you need to combine it with the list of packages that already have been rebuilt using OpenCSW X11. I'm not familiar with the initial problem (which called for the OpenCSW X11), but I think this could get us digging ourselves deeper into a hole instead of getting us out of it. I'm not saying that we should do it in either way, just that maybe we should think about it some more before hasting into a solution that might bite back at us later on. From phil at bolthole.com Fri Apr 9 23:13:00 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 9 Apr 2010 14:13:00 -0700 Subject: [csw-maintainers] About SUNW X11, CSW X11 and OpenGL In-Reply-To: <4BBF9457.4080508@opencsw.org> References: <61E55267-65C7-426B-A7DA-709110EF1E4A@opencsw.org> <4BBF9457.4080508@opencsw.org> Message-ID: On Fri, Apr 9, 2010 at 1:55 PM, Roger H?kansson wrote: > > I'm not familiar with the initial problem (which called for the OpenCSW > X11), but I think this could get us digging ourselves deeper into a hole > instead of getting us out of it. > I'm not saying that we should do it in either way, just that maybe we should > think about it some more before hasting into a solution that might bite back > at us later on. > agreed. Roger, please save yourself some potentially wasted effort, and hold off on doing any compiles of gtk-related things until we resolve this issue. From hson at opencsw.org Fri Apr 9 23:22:29 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 09 Apr 2010 23:22:29 +0200 Subject: [csw-maintainers] About SUNW X11, CSW X11 and OpenGL In-Reply-To: References: <61E55267-65C7-426B-A7DA-709110EF1E4A@opencsw.org> <4BBF9457.4080508@opencsw.org> Message-ID: <4BBF9A95.3030208@opencsw.org> On 2010-04-09 23:13, Philip Brown wrote: > On Fri, Apr 9, 2010 at 1:55 PM, Roger H?kansson wrote: >> >> I'm not familiar with the initial problem (which called for the OpenCSW >> X11), but I think this could get us digging ourselves deeper into a hole >> instead of getting us out of it. >> I'm not saying that we should do it in either way, just that maybe we should >> think about it some more before hasting into a solution that might bite back >> at us later on. >> > > agreed. Roger, please save yourself some potentially wasted effort, > and hold off on doing any compiles of gtk-related things until we > resolve this issue. Well, I'm not near releasing anything of it soon so I'll work on as usual on getting the dependency chains uptodate/garified which isn't wasted work. From dam at opencsw.org Sat Apr 10 09:18:01 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 10 Apr 2010 09:18:01 +0200 Subject: [csw-maintainers] Upgrade problems?? In-Reply-To: <4BBF91B5.40906@opencsw.org> References: <4BB83D49.20806@opencsw.org> <4BBF8711.3080901@opencsw.org> <4BBF91B5.40906@opencsw.org> Message-ID: Hi Roger, Am 09.04.2010 um 22:44 schrieb Roger H?kansson: > On 2010-04-09 22:25, Philip Brown wrote: >> the proper way to do this, is to rework both the xpdf package, and >> poppler, to use CSWalternatives. >> NOT, to mark packages as "incompatible" with other current packages. >> >> Please note: maintainers of xpdf and poppler will have to work >> together, to agree which should be the "default" xpdf, if both >> packages are installed. > > Regarding xpdf, there is no collision, its the utilities > (pdftotext...) that collide, which was why I suggested to Benny that > he also split them out to a separate package and we make them > (poppler and xpdf_utils incompatible). It would really be the best to use alternatives to select which set of tools would be selected. That way both packages can be installed, no breakage, and if one or the other has some minor advantage in one or the other environment the user can easily select the tools of choice. It is pretty simple in GAR: http://sourceforge.net/apps/trac/gar/wiki/Alternatives Benny, Roger: Just let me know if I can be of any assistance in this issue. Best regards -- Dago From dam at opencsw.org Sat Apr 10 09:29:21 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 10 Apr 2010 09:29:21 +0200 Subject: [csw-maintainers] About SUNW X11, CSW X11 and OpenGL In-Reply-To: <4BBF9457.4080508@opencsw.org> References: <61E55267-65C7-426B-A7DA-709110EF1E4A@opencsw.org> <4BBF9457.4080508@opencsw.org> Message-ID: <6EDEC51E-7163-4AD1-B03D-AAB40BE0504E@opencsw.org> Hi Roger, Am 09.04.2010 um 22:55 schrieb Roger H?kansson: > Wait a minute, you're proposing that we start releasing two versions > of the same package for a ton of packages? The main issue that we can either have a current X11 or OpenGL acceleration. Every X11 thing we build must decide which way it goes (or both when packaged up twice). As I don't use much 3D anyway I honestly don't know which libs would be needed for apps that benefit from it. There is the additional problem that James encountered apps breaking after we changed libs in /opt/csw/lib to bind against the CSW X11. Unfortunately the problem could not be reproduced on the buildfarm and the exact cause is yet unknown (James: correct me here if I'm wrong). Keeping libs in /opt/csw/lib bound against SUNW X11 would keep existing apps functioning and adding OpenCSW X11 libs in /opt/csw/X11/lib would cleanly separate out libs. I don't necessarily propagate this, but besides a lot of work it seems clean and would minimize dependencies as apps that don't need OpenCSW X11 could bind to libs bound to SUNW X11. > I'm not familiar with the initial problem (which called for the > OpenCSW X11), but I think this could get us digging ourselves deeper > into a hole instead of getting us out of it. > I'm not saying that we should do it in either way, just that maybe > we should think about it some more before hasting into a solution > that might bite back at us later on. Absolutely true. I made this first effort to get a better feeling how much work it is and experiment with the layout. As I said I don't have much expertise in that field and would prefer to follow someone who has a good understanding of all issues. Best regards -- Dago From maciej at opencsw.org Sat Apr 10 11:09:14 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 10 Apr 2010 10:09:14 +0100 Subject: [csw-maintainers] checkpkg: Detecting file conflicts (wrt the recent ev.h conflict) In-Reply-To: <1270743588-sup-5079@pinkfloyd.chass.utoronto.ca> References: <1270743588-sup-5079@pinkfloyd.chass.utoronto.ca> Message-ID: 2010/4/8 Ben Walton : > Excerpts from Maciej (Matchek) Blizinski's message of Thu Apr 08 12:05:02 -0400 2010: > >> file which is already provided by Python 2.6. ?I'm thinking of >> implementing a check catching file collisions. ?Directories would be >> excluded from the check. ?What do you think about such check? > > I think it's a great idea. ?As long as it's not too heavy, and I don't > see why it would be, it should be a nice addition. There might be a reason. Currently, the data available to checkpkg are: - the package set under examination - /var/sadm/install/contents I could easily implement a check that finds collisions against packages installed on the buildfarm. However, it would miss collisions with packages that are not installed on the buildfarm. In this sense, Phil is right pointing at the package database; the problem with that is that the package database is not available for checkpkg, unless we want to tie checkpkg with the buildfarm, and I think that we don't. I think that we might add a new flag to checkpkg, that would point at a specific catalog to include in the checks. For example: bin/checkpkg -c /export/mirror/opencsw/unstable/sparc/5.9 pkg1 pkg2 ... This would make checkpkg verify whether it has the recent information about all the packages from the catalog, and if there was anything missing, it would get imported from the catalog, by unpacking each package and collecting data from it. The initial run might take hours. A central cache would certainly speed things up, but it has to be something that can be also deployed outside of the buildfarm, so the package database doesn't qualify. Perhaps we could have a tool that generates a file with the same format as /var/sadm/install/contents, and checkpkg would take "additional /var/sadm/install/contents files" as parameters: bin/checkpkg/ \ -c /var/sadm/install/contents \ -c /opt/csw/share/install/contents \ -c /home/maciej/mycontents \ pkg1 pkg2 ... The csw shared install/contents file could be generated from the package database, if the database contains enough information. This solution would require a party to take the responsibility of updating the shared install/contents file, or else the check would not be helpful. Thoughts? From benny at opencsw.org Sat Apr 10 14:06:16 2010 From: benny at opencsw.org (Benjamin von Mossner) Date: Sat, 10 Apr 2010 14:06:16 +0200 Subject: [csw-maintainers] Upgrade problems?? In-Reply-To: <4BBF91B5.40906@opencsw.org> References: <4BB83D49.20806@opencsw.org> <4BBF8711.3080901@opencsw.org> <4BBF91B5.40906@opencsw.org> Message-ID: <20100410120616.GA31919@vonmossner.de> >> Please note: maintainers of xpdf and poppler will have to work >> together, to agree which should be the "default" xpdf, if both >> packages are installed. > Regarding xpdf, there is no collision, its the utilities (pdftotext...) > that collide, which was why I suggested to Benny that he also split them > out to a separate package and we make them (poppler and xpdf_utils > incompatible). I agree with Roger and as xpdf is already rebuilt and split, i would suggest to go ahead and release it. Packages can be found in /home/testing and on bender. Or just have a look into the GAR recipe [1] cheers, benny [1] http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/xpdf/trunk/Makefile -- /"\ ASCII RIBBON CAMPAIGN | Benjamin von Mossner \ / AGAINST HTML MAIL | benny at vonmossner.de X / \ multiple exclamation marks are a sure sign of a diseased mind From bwalton at opencsw.org Sat Apr 10 14:57:51 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 10 Apr 2010 08:57:51 -0400 Subject: [csw-maintainers] checkpkg: Detecting file conflicts (wrt the recent ev.h conflict) In-Reply-To: References: <1270743588-sup-5079@pinkfloyd.chass.utoronto.ca> Message-ID: <1270903860-sup-1406@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Sat Apr 10 05:09:14 -0400 2010: > A central cache would certainly speed things up, but it has to be > something that can be also deployed outside of the buildfarm, so the > package database doesn't qualify. Perhaps we could have a tool that > generates a file with the same format as /var/sadm/install/contents, > and checkpkg would take "additional /var/sadm/install/contents > files" as parameters: Is the full /var/sadm/install/contents format required? I'd expect you only need the first and last fields to implement the check. Eg: File /x/y/z in your package CSWfoort conflicts with CSWoldfoo, or something. We have this info in the central database, as it's consumed by the /search/ URL on the website. If we made periodic (weekly?) dumps of this data available for download/caching[1] by checkpkg, you could achieve what's required, no? It would be a public[1] URL, so it wouldn't be tied to the buildfarm... If this is deemed infeasible, then you're correct in the rest of what you say. Thanks -Ben [1] Maybe with a registered user/pass combo to prevent abuse. Consumers of the data could register to use it. -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bonivart at opencsw.org Sun Apr 11 20:00:25 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 11 Apr 2010 20:00:25 +0200 Subject: [csw-maintainers] checkpkg: Detecting file conflicts (wrt the recent ev.h conflict) In-Reply-To: <1270903860-sup-1406@pinkfloyd.chass.utoronto.ca> References: <1270743588-sup-5079@pinkfloyd.chass.utoronto.ca> <1270903860-sup-1406@pinkfloyd.chass.utoronto.ca> Message-ID: On Sat, Apr 10, 2010 at 2:57 PM, Ben Walton wrote: > We have this info in the central database, as it's consumed by the > /search/ URL on the website. ?If we made periodic (weekly?) dumps of > this data available for download/caching[1] by checkpkg, you could > achieve what's required, no? ?It would be a public[1] URL, so it > wouldn't be tied to the buildfarm... I also think this is the most reasonable approach. Add an option to checkpkg to point it to the "contents" file. No complex fetching/db-access code in checkpkg. Dump the file from the db with simple scripts run from cron instead. -- /peter From ja at opencsw.org Sun Apr 11 21:54:28 2010 From: ja at opencsw.org (Juergen Arndt) Date: Sun, 11 Apr 2010 21:54:28 +0200 Subject: [csw-maintainers] Packages for nagios, nrpe and nsca in experimental Message-ID: Hello, there are new packages for Nagios, NRPE and NSCA available from http://mirror.opencsw.org/experimental.html#ja Be aware that config files were moved to /etc/opt/csw - for Nagios this is not automatically done. You have to change the path names in your config files too. Look at [1] for more instructions. Feedback is very welcome. Juergen [1] http://wiki.opencsw.org/nagios -- Juergen Arndt From maciej at opencsw.org Mon Apr 12 01:19:22 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 12 Apr 2010 00:19:22 +0100 Subject: [csw-maintainers] checkpkg: Detecting file conflicts (wrt the recent ev.h conflict) In-Reply-To: <1270903860-sup-1406@pinkfloyd.chass.utoronto.ca> References: <1270743588-sup-5079@pinkfloyd.chass.utoronto.ca> <1270903860-sup-1406@pinkfloyd.chass.utoronto.ca> Message-ID: 2010/4/10 Ben Walton : > Is the full /var/sadm/install/contents format required? If the file had the same format, I could use the same parser. > I'd expect > you only need the first and last fields to implement the check. ?Eg: > File /x/y/z in your package CSWfoort conflicts with CSWoldfoo, or > something. I think that's OK if the file had dummy strings for uninteresting fields. The important fields are: - full path - file type - pkgname > We have this info in the central database, as it's consumed by the > /search/ URL on the website. ?If we made periodic (weekly?) dumps of > this data available for download/caching[1] by checkpkg, you could > achieve what's required, no? ?It would be a public[1] URL, so it > wouldn't be tied to the buildfarm... I like the idea. I'll try to sketch something along those lines in the following week. From bwalton at opencsw.org Mon Apr 12 01:26:32 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 11 Apr 2010 19:26:32 -0400 Subject: [csw-maintainers] checkpkg: Detecting file conflicts (wrt the recent ev.h conflict) In-Reply-To: References: <1270743588-sup-5079@pinkfloyd.chass.utoronto.ca> <1270903860-sup-1406@pinkfloyd.chass.utoronto.ca> Message-ID: <1271028334-sup-2527@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Sun Apr 11 19:19:22 -0400 2010: > If the file had the same format, I could use the same parser. Good point. > I think that's OK if the file had dummy strings for uninteresting > fields. The important fields are: > > - full path > - file type > - pkgname I'm not sure if the db is carrying file type currently as I haven't looked at it. Can someone with familiarity comment on this? > I like the idea. I'll try to sketch something along those lines in > the following week. Cool! Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Mon Apr 12 06:42:25 2010 From: phil at bolthole.com (Philip Brown) Date: Sun, 11 Apr 2010 21:42:25 -0700 Subject: [csw-maintainers] checkpkg: Detecting file conflicts (wrt the recent ev.h conflict) In-Reply-To: <1271028334-sup-2527@pinkfloyd.chass.utoronto.ca> References: <1270743588-sup-5079@pinkfloyd.chass.utoronto.ca> <1270903860-sup-1406@pinkfloyd.chass.utoronto.ca> <1271028334-sup-2527@pinkfloyd.chass.utoronto.ca> Message-ID: pleae note: this weekend is my weekend to look after my children, so I've been rather busy. however, after doing a little research , I have noticed two things: 1. there are existing, non-conflicting overlaps in sone packages that make checks mote complicated 2. I need to reformat the database table that holds this stuff because it needs to be case sensitive. Sigh. this stuff will happen but it's going to take a few days From phil at bolthole.com Mon Apr 12 07:01:48 2010 From: phil at bolthole.com (Philip Brown) Date: Sun, 11 Apr 2010 22:01:48 -0700 Subject: [csw-maintainers] checkpkg: Detecting file conflicts (wrt the recent ev.h conflict) In-Reply-To: References: <1270743588-sup-5079@pinkfloyd.chass.utoronto.ca> <1270903860-sup-1406@pinkfloyd.chass.utoronto.ca> <1271028334-sup-2527@pinkfloyd.chass.utoronto.ca> Message-ID: problem. I can't seem to get our db to put the thing in case sensitive mode. complains about every "_cs" or "_bin" character set I've tried so far From bwalton at opencsw.org Mon Apr 12 15:22:02 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 12 Apr 2010 09:22:02 -0400 Subject: [csw-maintainers] checkpkg: Detecting file conflicts (wrt the recent ev.h conflict) In-Reply-To: References: <1270743588-sup-5079@pinkfloyd.chass.utoronto.ca> <1270903860-sup-1406@pinkfloyd.chass.utoronto.ca> <1271028334-sup-2527@pinkfloyd.chass.utoronto.ca> Message-ID: <1271078466-sup-8825@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Apr 12 01:01:48 -0400 2010: > problem. > I can't seem to get our db to put the thing in case sensitive mode. > complains about every "_cs" or "_bin" character set I've tried so far I've never been very fond of the mysql handling of collations etc. It's caused me pain when I've had to play with it. Can anyone that has had success with this help out? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Mon Apr 12 18:03:59 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 12 Apr 2010 09:03:59 -0700 Subject: [csw-maintainers] checkpkg: Detecting file conflicts (wrt the recent ev.h conflict) In-Reply-To: References: <1270743588-sup-5079@pinkfloyd.chass.utoronto.ca> <1270903860-sup-1406@pinkfloyd.chass.utoronto.ca> <1271028334-sup-2527@pinkfloyd.chass.utoronto.ca> Message-ID: On Sun, Apr 11, 2010 at 10:01 PM, Philip Brown wrote: > problem. > I can't seem to get our db to put the thing in case sensitive mode. > complains about every "_cs" or "_bin" character set I've tried so far > oh, PS: just to be explicit, the complaint is ERROR 1115 (42000): Unknown character set: 'utf8_bin' From phil at bolthole.com Mon Apr 12 18:50:43 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 12 Apr 2010 09:50:43 -0700 Subject: [csw-maintainers] GAR, alternatives, and general integration of GAR Message-ID: So, I saw a recent mail, I think from Dagobert, about how to enable "alternatives" use in GAR. Unfortunately, I cant find the specific email, or I would quote it :( But it brings up a side issue. I have noticed in times past, a flaw in debian. There has long been the framework of "debian helper", to help people build debian packages. It gets more and more complicated over time. And it has even gone through a few major re-workings, which were semi-incompatible with older versions. Like GAR, it was basically a layer on top of the "real" debian package interface. The problem is that people had to learn "debian helper", to use it, and learning it ended up being almost as complicated as learning direct debian packages... which means that people often ended up not actually learning fully about the real debian package formats. I see this happening with GAR. It is getting more and more complex.... and there is more of a movement for people to "learn gar", instead of learning what is happening in our Actual Packages. I see this as a bad thing. I think that GAR should be an "assistant" to making packages, but not a REPLACEMENT for understanding packages. An excellent example, is the recent alternatives GAR module. To my mind, using the gar module, is almost the same complexity as just using alternatives directly! To do it "directly"; provide ONE FILE, with ONE LINE in it. basically: /opt/csw/etc/alternatives/YOURPKGNAME: /opt/csw/bin/userprog userprog /opt/csw/libexec/yourprog {Priority rating} then we do basically the same steps as if you were using a 'cswclassutil' function. Set that file to be class "cswalternatives" in your prototype file, add in cswalternatives to the CLASSES def in pkginfo, and depend on the appropriate package (CSWalternatives). It could be nice if GAR somehow auto-detected presense of /opt/csw/etc/alternatives/[anything-here], and then automatically did the class stuff. However, it is not so nice, in my opinion, that it attempts to mask the underlaying package mechanisms from the maintainer. Maintainers need to understand how "alternatives" really functions, if they are going to use it. From dam at opencsw.org Mon Apr 12 22:07:39 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 12 Apr 2010 22:07:39 +0200 Subject: [csw-maintainers] GAR, alternatives, and general integration of GAR In-Reply-To: References: Message-ID: <42D0B7EB-00BA-4889-9B7B-50913F8B2EC0@opencsw.org> Hi Phil, Am 12.04.2010 um 18:50 schrieb Philip Brown: > So, I saw a recent mail, I think from Dagobert, about how to enable > "alternatives" use in GAR. This wiki-page? > But it brings up a side issue. > > I have noticed in times past, a flaw in debian. > There has long been the framework of "debian helper", to help people > build debian packages. It gets more and more complicated over time. > And it has even gone through a few major re-workings, which were > semi-incompatible with older versions. > > Like GAR, it was basically a layer on top of the "real" debian package > interface. > > The problem is that people had to learn "debian helper", to use it, > and learning it ended up being almost as complicated as learning > direct debian packages... which means that people often ended up not > actually learning fully about the real debian package formats. > > I see this happening with GAR. It is getting more and more complex.... > and there is more of a movement for people to "learn gar", instead of > learning what is happening in our Actual Packages. In fact our package structure gets more and more complex, and GAR helps *hiding* this complexity from the maintainer. > I see this as a bad thing. And this is a *good thing* as the maintainers is not forced to understand every bit of it. If you are interested in something it is of course better to understand it, but there is rarely the need. The task of GAR is exactly hiding the ugly details like "how do I assemble a package with 32/64 bit with isaexec" by condensing it down to BUILD64=1. Take Texinfo-files: To properly put them at the right location, set the class for the texinfo-files, add the class in the correct order, all this is done *without any intervention* from the maintainer. > I think that GAR should be an "assistant" to making packages, but not > a REPLACEMENT for understanding packages. > > An excellent example, is the recent alternatives GAR module. > > To my mind, using the gar module, is almost the same complexity as > just using alternatives directly! Funnily the only person complaining that this is too complex is one of the few not using GAR. > To do it "directly"; provide ONE FILE, with ONE LINE in it. > basically: > > /opt/csw/etc/alternatives/YOURPKGNAME: > /opt/csw/bin/userprog userprog /opt/csw/libexec/yourprog {Priority > rating} I don't see how this is different from the GAR implementation. This is *exactly* of what you write in ALTERNATIVES_* in GAR. > then we do basically the same steps as if you were using a > 'cswclassutil' function. > Set that file to be class "cswalternatives" in your prototype file, > add in cswalternatives to the CLASSES def in pkginfo, and depend on > the appropriate package (CSWalternatives). All this is done automatically without maintainer intervention. > It could be nice if GAR somehow auto-detected presense of > /opt/csw/etc/alternatives/[anything-here], and then automatically did > the class stuff. GAR works exactly like that. If you feel like shooting yourself in the left foot you can just put the file in the right location manually and GAR will pick it up and take care of the rest. > However, it is not so nice, in my opinion, that it attempts to mask > the underlaying package mechanisms from the maintainer. > Maintainers need to understand how "alternatives" really functions, if > they are going to use it. The understanding on how alternatives work has nothing to do on how you specify it in the package. The current GAR implementation is not even abstract enough: the final goal is to just specify the alternative modulations and how they are build (like "slang" and "ncurses") and what binaries should be switches (like /opt/csw/bin/mutt) and GAR should take care of the rest like renaming the real binaries, setting up the modulation etc. so the current variables ALTERNATIVES_ would only be an (then invisible) intermediate step. Best regards -- Dago From phil at bolthole.com Mon Apr 12 22:38:00 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 12 Apr 2010 13:38:00 -0700 Subject: [csw-maintainers] GAR, alternatives, and general integration of GAR In-Reply-To: <42D0B7EB-00BA-4889-9B7B-50913F8B2EC0@opencsw.org> References: <42D0B7EB-00BA-4889-9B7B-50913F8B2EC0@opencsw.org> Message-ID: On Mon, Apr 12, 2010 at 1:07 PM, Dagobert Michelsen wrote: > Hi Phil, *wave* > Am 12.04.2010 um 18:50 schrieb Philip Brown: >> >> So, I saw a recent mail, I think from Dagobert, about how to enable >> "alternatives" use in GAR. > > This wiki-page? > ? oops.. yes I think that was it. >.... > And this is a *good thing* as the maintainers is not forced to > understand every bit of it. If you are interested in something it > is of course better to understand it, but there is rarely the need. > The task of GAR is exactly hiding the ugly details like "how do > I assemble a package with 32/64 bit with isaexec" by condensing it > down to BUILD64=1. Except of course, that we've had recent troubles of packages inappropriately doing too much 64bit, and people not realizing how to par that down :) But in general, yes I think that's a good thing. It's a nice, simple one line GAR thing. > Take Texinfo-files: To properly put them at the right location, set > the class for the texinfo-files, add the class in the correct order, > all this is done *without any intervention* from the maintainer. and this also I think is good. It doesnt require the maintainer to particularly "learn gar". Automatic, is good. Unfortunately, it does not seem possible to make providing an "alternatives" implementation in a package, "automatic". or even "simple". That is what I am resisting here. However,.... having thought about it some more, I think i've picked up some missing pieces that you didnt explicitly say in your wiki page, but may be true non the less. You seem to be viewing it from a perspective of, "I want to split up/recompile ONE software tarball, into multiple, different-back-end packages". Which IS actually somewhat complex, and I can see how that would benefit from GAR assistance. On the other hand, I am for some reason more focused on a view of multiple maintainers, with their own package, and each compiles something individually. This may be unrealistic. So, me going along with the idea of "Gar really does make this easier".... would you please simplify your wiki page about it? Right now, there are two, completely separate, examples. mostly "code"(makefile), and not enough explaination. MIght you move out the complicated automake stuff (or relegate it to a "page 2" kind of thing, and then explain more what is going on with the mutt exaple please? From benny at opencsw.org Mon Apr 12 22:41:26 2010 From: benny at opencsw.org (Benjamin von Mossner) Date: Mon, 12 Apr 2010 22:41:26 +0200 Subject: [csw-maintainers] Upgrade problems?? In-Reply-To: <20100410120616.GA31919@vonmossner.de> References: <4BB83D49.20806@opencsw.org> <4BBF8711.3080901@opencsw.org> <4BBF91B5.40906@opencsw.org> <20100410120616.GA31919@vonmossner.de> Message-ID: <20100412204125.GB31919@vonmossner.de> Hi, > > Regarding xpdf, there is no collision, its the utilities (pdftotext...) > > that collide, which was why I suggested to Benny that he also split them > > out to a separate package and we make them (poppler and xpdf_utils > > incompatible). > I agree with Roger and as xpdf is already rebuilt and split, i would > suggest to go ahead and release it. Packages can be found in > /home/testing and on bender. Or just have a look into the GAR > recipe [1] Phil, any answer on this? I know tha package is downgrade but thats not a final solution, is it? Cheers, benny -- /"\ ASCII RIBBON CAMPAIGN | Benjamin von Mossner \ / AGAINST HTML MAIL | benny at vonmossner.de X / \ multiple exclamation marks are a sure sign of a diseased mind From phil at bolthole.com Mon Apr 12 23:17:54 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 12 Apr 2010 14:17:54 -0700 Subject: [csw-maintainers] Upgrade problems?? In-Reply-To: <20100412204125.GB31919@vonmossner.de> References: <4BB83D49.20806@opencsw.org> <4BBF8711.3080901@opencsw.org> <4BBF91B5.40906@opencsw.org> <20100410120616.GA31919@vonmossner.de> <20100412204125.GB31919@vonmossner.de> Message-ID: On Mon, Apr 12, 2010 at 1:41 PM, Benjamin von Mossner wrote: > Hi, > >> > Regarding xpdf, there is no collision, its the utilities (pdftotext...) >> > that collide, which was why I suggested to Benny that he also split them >> > out to a separate package and we make them (poppler and xpdf_utils >> > incompatible). >> I agree with Roger and as xpdf is already rebuilt and split, i would >> suggest to go ahead and release it. Packages can be found in >> /home/testing and on bender. Or just have a look into the GAR >> recipe [1] > Phil, any answer on this? I know tha package is downgrade > but thats not a final solution, is it? > ah, sorry. lemme start a new thread on this thing, its getting a bit long and ugly now :0 From phil at bolthole.com Mon Apr 12 23:25:06 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 12 Apr 2010 14:25:06 -0700 Subject: [csw-maintainers] xpdf, poppler, going forward. Message-ID: On Mon, Apr 12, 2010 at 1:41 PM, Benjamin von Mossner wrote: > Phil, any answer on this? I know tha package is downgrade > but thats not a final solution, is it? > well, actually, Roger was nice enough to repackage soon after the downgrade. So that part is handled. However, now there is a question of, "how do we handle the rest of it?" The issue at the core of this, is that it has been suggested that (lib)poppler, if installed, makes for a "better" renderer than xpdf. The thought, which both Dagobert and I have suggested, is that, if it makes sense, you might repackage both xpdf, and the utils, to make use of "alternatives", and then xpdf would point to the "regular", xpdf implementation by default, but then get auto-redirected to the poppler implementation, if that was installed. A few things have to happen, for that to be possible. 1. You would both have to AGREE "poppler is better" :) 2. you would move the xpdf binaries (both xpdf, and utils), to something like /opt/csw/libexec/xpdf/xxxxxx, and register all of then through "alternatives" 3. Roger would do the same with the matching "poppler" binaries, setting the "alternatives" priority as higher than the xpdf entries 4. you resubmit your stuff, he resubmits "CSWpoppler" (leaving CSWlibpoppler unchanged) and there we go. However... if you disagree that poppler is always better... Then we need to discuss further on here. From maciej at opencsw.org Tue Apr 13 19:21:17 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 13 Apr 2010 18:21:17 +0100 Subject: [csw-maintainers] cswcrontab action script vs the percent sign Message-ID: The cswcrontab CAS uses percent as if it was a comment. However, the percent is not a comment; the way cron works is it pipes everything after the percent into the command being run. More information: http://www.hcidata.info/crontab.htm I think we need to mark the cswcrontab entries by a magic comment above the crontab line. Thoughts? From phil at bolthole.com Tue Apr 13 21:26:59 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 13 Apr 2010 12:26:59 -0700 Subject: [csw-maintainers] cswcrontab action script vs the percent sign In-Reply-To: References: Message-ID: On Tue, Apr 13, 2010 at 10:21 AM, Maciej (Matchek) Blizinski wrote: > The cswcrontab CAS uses percent as if it was a comment. ?However, the > percent is not a comment; the way cron works is it pipes everything > after the percent into the command being run. > > More information: http://www.hcidata.info/crontab.htm > > I think we need to mark the cswcrontab entries by a magic comment > above the crontab line. > > Thoughts? > maybe the action needs to be reengineered entirely, to not depend on comments like this at all. Sun does have a few packages that tweak cron. I dont know how it handles it, off-hand, but maybe we should emulate that more. From dam at opencsw.org Wed Apr 14 11:38:39 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 14 Apr 2010 11:38:39 +0200 Subject: [csw-maintainers] GAR, alternatives, and general integration of GAR In-Reply-To: References: <42D0B7EB-00BA-4889-9B7B-50913F8B2EC0@opencsw.org> Message-ID: Hi Phil, Am 12.04.2010 um 22:38 schrieb Philip Brown: >> .... >> And this is a *good thing* as the maintainers is not forced to >> understand every bit of it. If you are interested in something it >> is of course better to understand it, but there is rarely the need. >> The task of GAR is exactly hiding the ugly details like "how do >> I assemble a package with 32/64 bit with isaexec" by condensing it >> down to BUILD64=1. > > Except of course, that we've had recent troubles of packages > inappropriately doing too much 64bit, and people not realizing how to > par that down :) This is about defaults, not hiding implementation details. That only including libraries per default would be more intuitive may be true and I already wanted to do it, but I fear breaking old recipes. We may start another thread on how to best do this. > Unfortunately, it does not seem possible to make providing an > "alternatives" implementation in a package, "automatic". I haven't done it "automatic" because I simply don't have enough usecases. There is barey one package for each usecase and this is just not enough for me to generalize out "the best default". > or even "simple". I have added an example for the most simple case: one alternative in one package: However, this also was not in there because there was no use for it. The existing packages all use the other documented mechanisms. > You seem to be viewing it from a perspective of, > "I want to split up/recompile ONE software tarball, into multiple, > different-back-end packages". > Which IS actually somewhat complex, and I can see how that would > benefit from GAR assistance. > > On the other hand, I am for some reason more focused on a view of > multiple maintainers, with their own package, and each compiles > something individually. > This may be unrealistic. Again, we didn't have that case up until now and I just added the necessary line in GAR: > So, me going along with the idea of "Gar really does make this > easier".... would you please simplify your wiki page about it? Done. > Right now, there are two, completely separate, examples. mostly > "code"(makefile), and not enough explaination. > > MIght you move out the complicated automake stuff (or relegate it to a > "page 2" kind of thing, and then explain more what is going on with > the mutt exaple please? We already have this documented in the general "How alternatives work" wiki. As it is said on top of the trac wiki page you are supposed to read that first. Every argument to GAR is exactly of what is passed to alternatives with the --install added automatically. Best regards -- Dago From dam at opencsw.org Wed Apr 14 11:46:13 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 14 Apr 2010 11:46:13 +0200 Subject: [csw-maintainers] cswcrontab action script vs the percent sign In-Reply-To: References: Message-ID: Hi, Am 13.04.2010 um 21:26 schrieb Philip Brown: > On Tue, Apr 13, 2010 at 10:21 AM, Maciej (Matchek) Blizinski > wrote: >> The cswcrontab CAS uses percent as if it was a comment. However, the >> percent is not a comment; the way cron works is it pipes everything >> after the percent into the command being run. >> >> More information: http://www.hcidata.info/crontab.htm >> >> I think we need to mark the cswcrontab entries by a magic comment >> above the crontab line. >> >> Thoughts? Looks like though... > maybe the action needs to be reengineered entirely, to not depend on > comments like this at all. > > Sun does have a few packages that tweak cron. I dont know how it > handles it, off-hand, but maybe we should emulate that more. Do you have an example for me or do I need to take SUNW* apart? Best regards -- Dago From maciej at opencsw.org Wed Apr 14 14:20:58 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 14 Apr 2010 13:20:58 +0100 Subject: [csw-maintainers] Runpath menagerie for review In-Reply-To: <4BAFB4EC.9000800@opencsw.org> References: <4BAFB4EC.9000800@opencsw.org> Message-ID: No dia 28 de Mar?o de 2010 20:58, Roger H?kansson escreveu: > Ok, that override works, but it seems like you could skip checking the > override files... True. I've added it to the todo list, but there are other tasks which have priority: - the whole catalog run (need to reduce the number of false positives before release, need to replace the prototype with something that can be used with the unmaintainable package database on the buildfarm) - a bug in the stats collection of binary files (manifests itself with the ivtools package and a number of others) - file collision check (to prevent the kind of problems we had with ev.h) From phil at bolthole.com Wed Apr 14 18:16:10 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 14 Apr 2010 09:16:10 -0700 Subject: [csw-maintainers] cswcrontab action script vs the percent sign In-Reply-To: References: Message-ID: On Wed, Apr 14, 2010 at 2:46 AM, Dagobert Michelsen wrote: >> Sun does have a few packages that tweak cron. I dont know how it >> handles it, off-hand, but maybe we should emulate that more. > > Do you have an example for me or do I need to take SUNW* apart? > afraid that grep cron SUNW*/install/postinstall is your best option right now From phil at bolthole.com Wed Apr 14 18:23:40 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 14 Apr 2010 09:23:40 -0700 Subject: [csw-maintainers] GAR, alternatives, and general integration of GAR In-Reply-To: References: <42D0B7EB-00BA-4889-9B7B-50913F8B2EC0@opencsw.org> Message-ID: On Wed, Apr 14, 2010 at 2:38 AM, Dagobert Michelsen wrote: > > I have added an example for the most simple case: one alternative > in one package: > ? Thanks. the page could still be a little clearer though. The layout is currently an implicit flow of - (pick one of the following) - then, reguardless of which you pick, you should probably also do this postinstall notice The problem is that it doesnt explicitly call out "You only need to pick ONE of the following three strategies." Would be nice if you could make that a lot clearer somehow. (in regular HTML pages, I tend to indent the whole set together. Not sure whats the best way to handle it in wiki syntax) From james at opencsw.org Wed Apr 14 20:16:35 2010 From: james at opencsw.org (James Lee) Date: Wed, 14 Apr 2010 18:16:35 GMT Subject: [csw-maintainers] cswcrontab action script vs the percent sign In-Reply-To: References: Message-ID: <20100414.18163500.3907703497@gyor.oxdrove.co.uk> On 14/04/10, 10:46:13, Dagobert Michelsen wrote regarding Re: [csw-maintainers] cswcrontab action script vs the percent sign: > > Sun does have a few packages that tweak cron. I dont know how it > > handles it, off-hand, but maybe we should emulate that more. > Do you have an example for me or do I need to take SUNW* apart? http://docs.sun.com/app/docs/doc/805-6338/6j5vn5q5k From dam at opencsw.org Wed Apr 14 20:27:53 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 14 Apr 2010 20:27:53 +0200 Subject: [csw-maintainers] GAR, alternatives, and general integration of GAR In-Reply-To: References: <42D0B7EB-00BA-4889-9B7B-50913F8B2EC0@opencsw.org> Message-ID: Hi Phil, Am 14.04.2010 um 18:23 schrieb Philip Brown: > On Wed, Apr 14, 2010 at 2:38 AM, Dagobert Michelsen > wrote: >> >> I have added an example for the most simple case: one alternative >> in one package: >> > > the page could still be a little clearer though. > The layout is currently an implicit flow of > > - (pick one of the following) > - then, reguardless of which you pick, you should probably also do > this postinstall notice > > The problem is that it doesnt explicitly call out "You only need to > pick ONE of the following three strategies." > > Would be nice if you could make that a lot clearer somehow. > > (in regular HTML pages, I tend to indent the whole set together. Not > sure whats the best way to handle it in wiki syntax) Umh, it looks pretty clear to me. As it is a wiki I suggest you just make the change. Best regards -- Dago From phil at bolthole.com Wed Apr 14 21:06:26 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 14 Apr 2010 12:06:26 -0700 Subject: [csw-maintainers] GAR, alternatives, and general integration of GAR In-Reply-To: References: <42D0B7EB-00BA-4889-9B7B-50913F8B2EC0@opencsw.org> Message-ID: On Wed, Apr 14, 2010 at 11:27 AM, Dagobert Michelsen wrote: > Hi Phil, > >> The problem is that it doesnt explicitly call out "You only need to >> pick ONE of the following three strategies." >> >> Would be nice if you could make that a lot clearer somehow. >> >> (in regular HTML pages, I tend to indent the whole set together. Not >> sure whats the best way to handle it in wiki syntax) > > Umh, it looks pretty clear to me. As it is a wiki I suggest you just > make the change. > "Not sure whats the best way to handle it in wiki syntax". or for that matter, any way to handle it. From dam at opencsw.org Fri Apr 16 17:40:25 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 16 Apr 2010 17:40:25 +0200 Subject: [csw-maintainers] Updating all buildfarm servers now Message-ID: <54E78005-9D49-4B46-AC75-C5930CACB901@opencsw.org> Hi, I am currently updating all buildfarm servers to current/. Please stand by. Best regards -- Dago From dam at opencsw.org Fri Apr 16 17:59:03 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 16 Apr 2010 17:59:03 +0200 Subject: [csw-maintainers] [csw-buildfarm] group request In-Reply-To: <4BC887E3.6000601@cognigencorp.com> References: <4BC78768.9070307@cognigencorp.com> <4BC87B62.7070405@cognigencorp.com> <83598AD0-0AC8-4C21-AD40-5194C40E85BF@opencsw.org> <4BC887E3.6000601@cognigencorp.com> Message-ID: Hi Darin, (moving from buildfarm@ to maintainers@ is the topic is of general interest). Am 16.04.2010 um 17:53 schrieb Darin Perusich: > Dago, > >>> >>> I'm rebuilding with this option but I don't believe it's going to be >>> adequate. The problem when setting --disable-installperms is the >>> permission are then not properly set during 'make install' and the >>> user >>> and group pairs in the prototype will not be properly setup, there >>> are >>> some 90+ files/dirs which need to be amanda:sys. >>> >>> This is definitely a fakeroot problem on Solaris 9. I've tested the >>> chown operation on Solaris 8 and 10 (w/ fakeroot built for sol10) >>> and >>> it's functioning properly. I guess simply building on 8 will be the >>> easiest way to get around this for now. >> >> Ok then, the Solaris 8 machines are still (and will be) remain in >> place, so for now it should be ok. If you want to do a GAR build >> later: GAR does not support fakeroot and fully relies on DESTDIR. >> The prototype can then be adjusted programmatically with regular >> expressions per field. > > If a package needs to set a large number of specific permission for > users, groups, files, etc, having to adjust them individually w/ > regex's > sounds overly complicated and error prone to me. What happens when a > new > release is available and these change? Then you must check the permissions. Usually, the changes are specific to certain directories or specific binaries, so the level of change should be manageable. > In this instance amanda does fully support DESTDIR but you need to set > some files to root:sys which are setgid, others amanda:sys, and others > root:root. What would be the easiest way to accomplish this for a > maintainer...using fakeroot, compiling as root to ensure user:groups > are > properly set, or some ever changing regex's? I'm not looking for an > answer, simply point out that these are complicated issues. How does fakeroot work? Make a library interposer and grab the chown calls? As the packaging processo can obviously not run as root I don't see an easy alternative to manually setting permissions here - ideas of course welcome! Best regards -- Dago From phil at bolthole.com Fri Apr 16 19:37:00 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 16 Apr 2010 10:37:00 -0700 Subject: [csw-maintainers] [csw-buildfarm] group request In-Reply-To: References: <4BC78768.9070307@cognigencorp.com> <4BC87B62.7070405@cognigencorp.com> <83598AD0-0AC8-4C21-AD40-5194C40E85BF@opencsw.org> <4BC887E3.6000601@cognigencorp.com> Message-ID: On Fri, Apr 16, 2010 at 8:59 AM, Dagobert Michelsen wrote: > How does fakeroot work? Make a library interposer and grab the chown > calls? yuyp. but it also intercepts the stat() calls somehow as well. From ihsan at opencsw.org Fri Apr 16 22:43:35 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Fri, 16 Apr 2010 22:43:35 +0200 Subject: [csw-maintainers] checkpkg behavior Message-ID: <4BC8CBF7.9020001@opencsw.org> Hello, I'm facing the problem that checkpkg behaves on x86 different than on sparc. INFO:root:Collecting 'CSWirssi' package statistics. Analyzing collected statistics... CSWirssi: # Missing dependencies of CSWirssi: # If you don't know of any reasons to include these dependencies, you might # remove them: # ? CSWiconv All modular tests were successful. The following packages have been built: CSWirssi /home/ihsan/staging/build-16.Apr.2010/irssi-0.8.15,REV=2010.04.16-SunOS5.9-sparc-CSW.pkg.gz [package] complete for irssi. Everything is fine on sparc. If I build the same package on x86, this will happen: INFO:root:Collecting 'CSWirssi' package statistics. Analyzing collected statistics... CSWirssi: # Missing dependencies of CSWirssi: # If you don't know of any reasons to include these dependencies, you might # remove them: # ? CSWiconv If any of the reported errors were false positives, you can override them pasting the lines below to the GAR recipe. CHECKPKG_OVERRIDES_CSWirssi += deprecated-library|opt/csw/bin/botti|Deprecated|Berkeley|DB|location|/opt/csw/lib/libdb-4.7.so CHECKPKG_OVERRIDES_CSWirssi += deprecated-library|opt/csw/bin/irssi|Deprecated|Berkeley|DB|location|/opt/csw/lib/libdb-4.7.so ERROR: Modular checks are reporting errors. To run checkpkg in the debug mode, add the '-d' flag, for example: After you modify any overrides, you need to do gmake remerge repackage or gmake platforms-remerge platforms-repackage. gmake: *** [pkgcheck] Error 2 What is going wrong here? Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From phil at bolthole.com Fri Apr 16 23:05:12 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 16 Apr 2010 14:05:12 -0700 Subject: [csw-maintainers] checkpkg behavior In-Reply-To: <4BC8CBF7.9020001@opencsw.org> References: <4BC8CBF7.9020001@opencsw.org> Message-ID: On Fri, Apr 16, 2010 at 1:43 PM, Ihsan Dogan wrote: > Hello, > > I'm facing the problem that checkpkg behaves on x86 different than on sparc. > > What is going wrong here? I'm guessing that what is wrong, is that you compiled it differently, on x86 vs sparc . in one you linked in libiconv from csw, and in one, you didnt? go check your make logs or Makefiles or something? From maciej at opencsw.org Fri Apr 16 23:17:46 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 16 Apr 2010 22:17:46 +0100 Subject: [csw-maintainers] checkpkg behavior In-Reply-To: <4BC8CBF7.9020001@opencsw.org> References: <4BC8CBF7.9020001@opencsw.org> Message-ID: No dia 16 de Abril de 2010 21:43, Ihsan Dogan escreveu: > I'm facing the problem that checkpkg behaves on x86 different than on sparc. I don't know why the difference between x86 and sparc, but I can explain what is the error about. > CHECKPKG_OVERRIDES_CSWirssi += > deprecated-library|opt/csw/bin/botti|Deprecated|Berkeley|DB|location|/opt/csw/lib/libdb-4.7.so > CHECKPKG_OVERRIDES_CSWirssi += > deprecated-library|opt/csw/bin/irssi|Deprecated|Berkeley|DB|location|/opt/csw/lib/libdb-4.7.so > ERROR: Modular checks are reporting errors. You're not supposed to link against Berkeley DB in /opt/csw/lib, it's a legacy location. Even though there is a symlink... > ls -l /opt/csw/lib/libdb-4.7.so lrwxrwxrwx 1 root root 25 Nov 11 10:52 /opt/csw/lib/libdb-4.7.so -> ../bdb47/lib/libdb-4.7.so ...you're not supposed to link against it. You need to give a specific berkeley DB version in the runpath. The symlink belongs to the deprecated CSWbdb. The actual library belongs to CSWbdb47. In short, you need to prepend the RPATH list with /opt/csw/bdb47/lib. From bwalton at opencsw.org Sun Apr 18 02:06:16 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 17 Apr 2010 20:06:16 -0400 Subject: [csw-maintainers] coreutils Message-ID: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca> Hi All, I've finally gotten coreutils to a point where I think it's fit for release. This means that it's time to begin updating the packages that depend on one or more of CSWgfile, CSWshutils and CSWtextutils. Fortunately, this isn't a big list and the bulk of the packages have active maintainers. I've created a project page in the wiki to track this: http://wiki.opencsw.org/project-coreutils Briefly, the following people will need to be involved in updating packages: Maciej Dago Peter Felecan Murray Jensen (listed active, but is this correct?) If you see something in the wiki or package data that I've missed, please let me know. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From ihsan at opencsw.org Sun Apr 18 11:11:58 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 18 Apr 2010 11:11:58 +0200 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: <4ADB45B0.1000207@opencsw.org> References: <4ADB45B0.1000207@opencsw.org> Message-ID: <4BCACCDE.7060807@opencsw.org> Am 18.10.09 18:43, schrieb Ihsan Dogan: > The Apache 2 package needs to be reworked and I can't find any > additional ressources at this time. Would be great if someone could take > over this package. Still nobody interested in taking over Apache? Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Sun Apr 18 13:17:51 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 18 Apr 2010 13:17:51 +0200 Subject: [csw-maintainers] checkpkg behavior In-Reply-To: References: <4BC8CBF7.9020001@opencsw.org> Message-ID: <4BCAEA5F.5010602@opencsw.org> Am 16.04.10 23:17, schrieb Maciej (Matchek) Blizinski: >> CHECKPKG_OVERRIDES_CSWirssi += >> deprecated-library|opt/csw/bin/botti|Deprecated|Berkeley|DB|location|/opt/csw/lib/libdb-4.7.so >> CHECKPKG_OVERRIDES_CSWirssi += >> deprecated-library|opt/csw/bin/irssi|Deprecated|Berkeley|DB|location|/opt/csw/lib/libdb-4.7.so >> ERROR: Modular checks are reporting errors. > > You're not supposed to link against Berkeley DB in /opt/csw/lib, it's > a legacy location. Even though there is a symlink... Thanks, I've fixed that now. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From bonivart at opencsw.org Sun Apr 18 14:34:06 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 18 Apr 2010 14:34:06 +0200 Subject: [csw-maintainers] coreutils In-Reply-To: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca> References: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca> Message-ID: On Sun, Apr 18, 2010 at 2:06 AM, Ben Walton wrote: > Murray Jensen (listed active, but is this correct?) He quickly responded to my maintainer ping a few weeks back and said he wants to remain listed as active but as he sometimes have little time it's ok to take his packages if needed. I recommend you first ask him directly though if he's interested in doing the update or not. -- /peter From bwalton at opencsw.org Sun Apr 18 15:10:57 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 18 Apr 2010 09:10:57 -0400 Subject: [csw-maintainers] coreutils In-Reply-To: References: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca> Message-ID: <1271596236-sup-2073@pinkfloyd.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Sun Apr 18 08:34:06 -0400 2010: > He quickly responded to my maintainer ping a few weeks back and said > he wants to remain listed as active but as he sometimes have little > time it's ok to take his packages if needed. I recommend you first ask > him directly though if he's interested in doing the update or not. Ok. I just mailed him directly. Thanks for the info Peter. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bonivart at opencsw.org Sun Apr 18 21:05:26 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 18 Apr 2010 21:05:26 +0200 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: <4BCACCDE.7060807@opencsw.org> References: <4ADB45B0.1000207@opencsw.org> <4BCACCDE.7060807@opencsw.org> Message-ID: On Sun, Apr 18, 2010 at 11:11 AM, Ihsan Dogan wrote: > Am 18.10.09 18:43, schrieb Ihsan Dogan: > >> The Apache 2 package needs to be reworked and I can't find any >> additional ressources at this time. Would be great if someone could take >> over this package. > > Still nobody interested in taking over Apache? Didn't Rupert do some work on it? -- /peter From maciej at opencsw.org Mon Apr 19 09:58:28 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 19 Apr 2010 08:58:28 +0100 Subject: [csw-maintainers] coreutils In-Reply-To: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca> References: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 18 de Abril de 2010 01:06, Ben Walton escreveu: > I've finally gotten coreutils to a point where I think it's fit for > release. ?This means that it's time to begin updating the packages > that depend on one or more of CSWgfile, CSWshutils and CSWtextutils. Do you mean that the packages formerly depending on CSWgfile and friends should be now rebuild declaring a dependency on CSWcoreutils, without CSWcoreutils being released? This could be done with the following override: CHECKPKG_OVERRIDES_CSWwgetpaste += unidentified-dependency|CSWcoreutils Here's an update to wgetpaste done in this way: http://sourceforge.net/apps/trac/gar/changeset/9703 Maciej From ihsan at opencsw.org Mon Apr 19 11:39:10 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Mon, 19 Apr 2010 11:39:10 +0200 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: References: <4ADB45B0.1000207@opencsw.org> <4BCACCDE.7060807@opencsw.org> Message-ID: <4BCC24BE.1080900@opencsw.org> On 04/18/10 21:05, Peter Bonivart wrote: >>> The Apache 2 package needs to be reworked and I can't find any >>> additional ressources at this time. Would be great if someone could take >>> over this package. >> Still nobody interested in taking over Apache? > > Didn't Rupert do some work on it? Not that I'm aware of. Rupert? Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From bwalton at opencsw.org Mon Apr 19 15:08:11 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 19 Apr 2010 09:08:11 -0400 Subject: [csw-maintainers] coreutils In-Reply-To: References: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca> Message-ID: <1271682347-sup-1053@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Mon Apr 19 03:58:28 -0400 2010: > Do you mean that the packages formerly depending on CSWgfile and > friends should be now rebuild declaring a dependency on CSWcoreutils, > without CSWcoreutils being released? This could be done with the > following override: > > CHECKPKG_OVERRIDES_CSWwgetpaste += > unidentified-dependency|CSWcoreutils Yup. That's what I've been adding to the ones I've done already. The biggest holdup with by ruby_dev as I can't rebuild that package until the gcc stuff is sorted out[1]. If it drags on too long, I may unroll the package and hand-edit the dependency just to get coreutils out. > Here's an update to wgetpaste done in this way: > http://sourceforge.net/apps/trac/gar/changeset/9703 That looks good. Thanks -Ben [1] I've nominally started looking at gcc (4.5.0 was just released) but that will need some updates to other packages.... :) -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert at opencsw.org Mon Apr 19 18:22:13 2010 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 19 Apr 2010 18:22:13 +0200 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: <4BCC24BE.1080900@opencsw.org> References: <4ADB45B0.1000207@opencsw.org> <4BCACCDE.7060807@opencsw.org> <4BCC24BE.1080900@opencsw.org> Message-ID: On Mon, Apr 19, 2010 at 11:39, Ihsan Dogan wrote: > On 04/18/10 21:05, Peter Bonivart wrote: > >>>> The Apache 2 package needs to be reworked and I can't find any >>>> additional ressources at this time. Would be great if someone could take >>>> over this package. >>> >>> Still nobody interested in taking over Apache? >> >> Didn't Rupert do some work on it? > > Not that I'm aware of. > Rupert? maciej, and me did some yes .. but this was far from good. now there is only one single package contrary to the sophisticated setup before. a package of version 2.2.14 is on http://mirror.opencsw.org/testing.html. rupert From phil at bolthole.com Mon Apr 19 19:06:17 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 19 Apr 2010 10:06:17 -0700 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: References: <4ADB45B0.1000207@opencsw.org> <4BCACCDE.7060807@opencsw.org> <4BCC24BE.1080900@opencsw.org> Message-ID: On Mon, Apr 19, 2010 at 9:22 AM, rupert THURNER wrote: > > > maciej, and me did some yes .. but this was far from good. now there > is only one single package contrary to the sophisticated setup before. > a package of version 2.2.14 is on > http://mirror.opencsw.org/testing.html. > might be better if you at least split out the manual, judging by size: bender$ ls -Ll apache2* -rw-rw-r-- 2 phil release 9146 Aug 25 2009 apache2-2.2.13,REV=2009.08.22-SunOS5.8-all-CSW.pkg.gz -rw-rw-r-- 1 phil release 532528 Aug 25 2009 apache2_devel-2.2.13,REV=2009.08.22-SunOS5.8-sparc-CSW.pkg.gz -rw-rw-r-- 2 phil release 2351496 Aug 25 2009 apache2_manual-2.2.13,REV=2009.08.22-SunOS5.8-all-CSW.pkg.gz -rw-rw-r-- 1 phil release 804890 Aug 25 2009 apache2c-2.2.13,REV=2009.08.22-SunOS5.8-sparc-CSW.pkg.gz -rw-rw-r-- 1 phil release 206820 Aug 25 2009 apache2rt-2.2.13,REV=2009.08.22-SunOS5.8-sparc-CSW.pkg.gz From phil at bolthole.com Mon Apr 19 19:08:03 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 19 Apr 2010 10:08:03 -0700 Subject: [csw-maintainers] coreutils In-Reply-To: References: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Apr 19, 2010 at 12:58 AM, Maciej (Matchek) Blizinski wrote: > > Do you mean that the packages formerly depending on CSWgfile and > friends should be now rebuild declaring a dependency on CSWcoreutils, > without CSWcoreutils being released? well, it doesnt have to be an "all at once" operation, if coredutils is just released with some dummy CSWgfile packages that depend on CSWcoreutils. From bwalton at opencsw.org Mon Apr 19 19:25:36 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 19 Apr 2010 13:25:36 -0400 Subject: [csw-maintainers] coreutils In-Reply-To: References: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca> Message-ID: <1271697460-sup-321@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Apr 19 13:08:03 -0400 2010: > well, it doesnt have to be an "all at once" operation, if coredutils > is just released with some dummy CSWgfile packages that depend on > CSWcoreutils. No, I think it does, unfortunately...if we want to keep circular dependencies out of the catalog, anyway. We could do: CSWgfile(dummy) -> {CSWcoreutils,CSWshutils,CSWtextutils} CSWshutils(dummy) -> {CSWcoreutils,CSWgfile,CSWtextutils} CSWtextutils(dummy) -> {CSWcoreutils,CSWgfile,CSWshutils} Each of the old packages would need to depend on coreutils _and_ the other two dummy packages to force an update of one to update the others too. This would also imply that CSWcoreutils couldn't declare itself Incompatible with the old packages which opens us up to: Someone updates CSWwgetpaste (depends on CSWshutils) when Maciej cranks out a new version, but doesn't update any packages that depend on CSWgfile or CSWtextutils. Those would be left in their current (file bearing) states and would then have file conflicts with CSWcoreutils. A full 'upgrade' operation would handle this, but there are situations where even adding one of the affected packages could trigger the above behaviour. Thoughts? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert at opencsw.org Mon Apr 19 21:06:48 2010 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 19 Apr 2010 21:06:48 +0200 Subject: [csw-maintainers] apr compile failed on i386 In-Reply-To: References: Message-ID: a "gmake platforms-reinstall platforms-remerge platforms-repackage" led to the following error: /home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/share /home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/share/build-1 /home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/share/build-1/mkdir.sh /home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/share/build-1/libtool /home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/share/build-1/apr_rules.mk /home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/share/build-1/make_exports.awk /home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/share/build-1/make_var_export.awk gmake[1]: Leaving directory `/home/rupert/mgar/pkg/apr/trunk' gmake[1]: Entering directory `/home/rupert/mgar/pkg/apr/trunk' [ Reset install state for modulation isa-amd64: ISA=amd64 ] gmake[1]: Leaving directory `/home/rupert/mgar/pkg/apr/trunk' gmake[1]: Entering directory `/home/rupert/mgar/pkg/apr/trunk' gar/gar.conf.mk:418: *** The ISA 'amd64' can not be build on this kernel with the arch 'i386'. ?Stop. gmake[1]: Leaving directory `/home/rupert/mgar/pkg/apr/trunk' gmake: *** [reset-install-isa-amd64] Error 2 gmake: Leaving directory `/home/rupert/mgar/pkg/apr/trunk' Connection to current9x closed. gmake: *** [platforms-reinstall] Error 2 is this in apr, or in gar? rupert. From phil at bolthole.com Mon Apr 19 21:18:26 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 19 Apr 2010 12:18:26 -0700 Subject: [csw-maintainers] coreutils In-Reply-To: <1271697460-sup-321@pinkfloyd.chass.utoronto.ca> References: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca> <1271697460-sup-321@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Apr 19, 2010 at 10:25 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Mon Apr 19 13:08:03 -0400 2010: > >> well, it doesnt have to be an "all at once" operation, if coredutils >> is just released with some dummy CSWgfile packages that depend on >> CSWcoreutils. > > No, I think it does, unfortunately...if we want to keep circular > dependencies out of the catalog, anyway. >.... >... > Thoughts? > drat. I think you're right. From dam at opencsw.org Mon Apr 19 21:56:27 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 19 Apr 2010 21:56:27 +0200 Subject: [csw-maintainers] apr compile failed on i386 In-Reply-To: References: Message-ID: Hi Rupert, Am 19.04.2010 um 21:06 schrieb rupert THURNER: > a "gmake platforms-reinstall platforms-remerge platforms-repackage" > > led to the following error: > > /home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/ > share > /home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/ > share/build-1 > /home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/ > share/build-1/mkdir.sh > /home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/ > share/build-1/libtool > /home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/ > share/build-1/apr_rules.mk > /home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/ > share/build-1/make_exports.awk > /home/rupert/mgar/pkg/apr/trunk/work/solaris9-i386/pkgroot/./opt/csw/ > share/build-1/make_var_export.awk > gmake[1]: Leaving directory `/home/rupert/mgar/pkg/apr/trunk' > gmake[1]: Entering directory `/home/rupert/mgar/pkg/apr/trunk' > [ Reset install state for modulation isa-amd64: ISA=amd64 ] > gmake[1]: Leaving directory `/home/rupert/mgar/pkg/apr/trunk' > gmake[1]: Entering directory `/home/rupert/mgar/pkg/apr/trunk' > gar/gar.conf.mk:418: *** The ISA 'amd64' can not be build on this > kernel with the arch 'i386'. Stop. > gmake[1]: Leaving directory `/home/rupert/mgar/pkg/apr/trunk' > gmake: *** [reset-install-isa-amd64] Error 2 > gmake: Leaving directory `/home/rupert/mgar/pkg/apr/trunk' > Connection to current9x closed. > gmake: *** [platforms-reinstall] Error 2 > > is this in apr, or in gar? This is a GAR issue. I can't see the cause right now and rebuild apr to reproduce your problem and look into it. Best regards -- Dago From rupert at opencsw.org Wed Apr 21 00:10:18 2010 From: rupert at opencsw.org (rupert THURNER) Date: Wed, 21 Apr 2010 00:10:18 +0200 Subject: [csw-maintainers] java error, core dumped, when building bdb50, subversion-1.6.11 In-Reply-To: References: Message-ID: when compiling subversion-1.6.11 a similar error occurred than with bdb50: /src/org/tigris/subversion/javahl/Version.java /home/rupert/mgar/pkg/subversion/trunk/work/solaris9-sparc/build-isa-sparcv8/subversion-1.6.11/subversion/bindings/javahl/src/org/tigris/subversion/javahl/ChangelistCallback.java /home/rupert/mgar/pkg/subversion/trunk/work/solaris9-sparc/build-isa-sparcv8/subversion-1.6.11/subversion/bindings/javahl/src/org/tigris/subversion/javahl/SVNClient.java /home/rupert/mgar/pkg/subversion/trunk/work/solaris9-sparc/build-isa-sparcv8/subversion-1.6.11/subversion/bindings/javahl/src/org/tigris/subversion/javahl/NativeException.java # # An unexpected error has been detected by HotSpot Virtual Machine: # # ?Internal Error (4F533F534F4C415249533F53504152430E4350500054 FF), pid=12617, tid=1 # # Java VM: Java HotSpot(TM) Server VM (1.5.0_15-b04 mixed mode) # An error report file with more information is saved as hs_err_pid12617.log gmake[3]: *** [subversion/bindings/javahl/classes/org/tigris/subversion/javahl/PropertyData.class] Illegal Instruction (core dumped) gmake[3]: Leaving directory `/home/rupert/mgar/pkg/subversion/trunk/work/solaris9-sparc/build-isa-sparcv8/subversion-1.6.11' gmake[2]: *** [svn-java] Error 2 gmake[2]: Leaving directory `/home/rupert/mgar/pkg/subversion/trunk' gmake[1]: *** [merge-isa-sparcv8] Error 2 gmake[1]: Leaving directory `/home/rupert/mgar/pkg/subversion/trunk' gmake: *** [platforms] Error 2 rupert at current9s ~/mgar/pkg/subversion/trunk can it be that the build system now mixes up the various java versions installed? kr, rupert On Mon, Apr 5, 2010 at 21:20, Dagobert Michelsen wrote: > Hi Rupert, > > Am 03.04.2010 um 15:33 schrieb rupert THURNER: > >> hi, >> >> while the little one was sleeping i tried to give bdb-50 a try .... >> and i could not even compile it: >> >> ./work/solaris9-sparc/build-isa-sparcv8/db-5.0.21/build_unix/config.log ?says: >> >> configure:16889: checking for javac >> configure:16905: found /usr/jdk1.6.0_07/bin/javac >> configure:16916: result: javac >> configure:16974: checking if javac works >> configure:16988: javac ?Test.java >> configure:16991: $? = 0 >> configure:17002: result: yes >> configure:17012: checking for jar >> configure:17028: found /usr/jdk1.6.0_07/bin/jar >> configure:17039: result: jar >> configure:17103: checking for java >> configure:17119: found /usr/jdk1.6.0_07/bin/java >> configure:17130: result: java >> configure:17190: checking for uudecode >> configure:17206: found /usr/bin/uudecode >> configure:17217: result: yes >> configure:17226: checking if uudecode can decode base 64 file >> configure: 17249: uudecode had trouble decoding base 64 file 'Test.uue' >> configure: failed file was: >> begin-base64 644 Test.class >> yv66vgADAC0AFQcAAgEABFRlc3QHAAQBABBqYXZhL2xhbmcvT2JqZWN0AQAE >> bWFpbgEAFihbTGphdmEvbGFuZy9TdHJpbmc7KVYBAARDb2RlAQAPTGluZU51 >> bWJlclRhYmxlDAAKAAsBAARleGl0AQAEKEkpVgoADQAJBwAOAQAQamF2YS9s >> YW5nL1N5c3RlbQEABjxpbml0PgEAAygpVgwADwAQCgADABEBAApTb3VyY2VG >> aWxlAQAJVGVzdC5qYXZhACEAAQADAAAAAAACAAkABQAGAAEABwAAACEAAQAB >> AAAABQO4AAyxAAAAAQAIAAAACgACAAAACgAEAAsAAQAPABAAAQAHAAAAIQAB >> AAEAAAAFKrcAErEAAAABAAgAAAAKAAIAAAAEAAQABAABABMAAAACABQ= >> ==== >> configure:17253: result: no >> configure:17258: WARNING: I have to compile Test.class from scratch >> configure:17389: checking if java works >> configure:17407: javac ?Test.java >> configure:17410: $? = 0 >> configure:17420: java ?Test >> ../dist/configure: line 1: 28337 Illegal Instruction ? ? (core dumped) >> $JAVA $JAVAFLAGS $TEST >> configure:17423: $? = 132 >> configure: failed program was: >> /* [#]line 17402 "configure" */ >> public class Test { >> public static void main (String args[]) { >> ? ? ? ?System.exit (0); >> } } >> configure:17429: error: The Java VM java failed (see config.log, check >> the CLASSPATH?) >> >> >> did you see something similar already? > > No, maybe you try some other JVM? > > > Best regards > > ?-- Dago > > From dam at opencsw.org Wed Apr 21 10:07:58 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 21 Apr 2010 10:07:58 +0200 Subject: [csw-maintainers] apr compile failed on i386 In-Reply-To: References: Message-ID: <651DF211-DD52-4AA0-8F2E-67A3AF9987B5@opencsw.org> Hi Rupert, Am 19.04.2010 um 21:56 schrieb Dagobert Michelsen: > This is a GAR issue. I can't see the cause right now and rebuild apr > to > reproduce your problem and look into it. Sorry, I can not reproduce it. Does it still occur for you? Best regards -- Dago From maciej at opencsw.org Wed Apr 21 14:26:45 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 21 Apr 2010 13:26:45 +0100 Subject: [csw-maintainers] Calling statvfs() on my home directory Message-ID: While debugging a failed OpenCSW package build on my workstation I came across a problem with statvfs() returning EOVERFLOW. I did some experiments, and ended up writing the following example code, which makes a dummy statvfs() call and reports whether it has succeeded or not. I've compiled it in two versions, the sole difference being -m32 vs -m64. Here's the complete code: $ cat statvfs-example.sh cat > statvfs-example.c < #include #include #include int main(void) { struct statvfs buf; extern int errno; if (statvfs(getenv("HOME"), &buf) < 0) { printf("statvfs() has failed, errno = %d\n", errno); switch (errno) { case EOVERFLOW: printf("EOVERFLOW\n"); break; } } else { printf("statvfs() completed successfully.\n"); } exit(EXIT_SUCCESS); } EOF for word_length in 32 64; do cc \ -m${word_length} \ statvfs-example.c \ -o statvfs-example-${word_length} file statvfs-example-${word_length} ./statvfs-example-${word_length} done Running it yields the following: $ bash statvfs-example.sh statvfs-example-32: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped statvfs() has failed, errno = 79 EOVERFLOW statvfs-example-64: ELF 64-bit LSB executable AMD64 Version 1 [SSE FXSR FPU], dynamically linked, not stripped statvfs() completed successfully. It looks like any 32-bit binary making the statvfs() call on my home directory will fail with EOVERFLOW, while a 64-bit binary will succeed. Does that count as an advantage of building 64-bit binaries? From maciej at opencsw.org Wed Apr 21 15:06:54 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 21 Apr 2010 14:06:54 +0100 Subject: [csw-maintainers] Calling statvfs() on my home directory In-Reply-To: References: Message-ID: As Dago suggested, adding the output of getconf LFS_CFLAGS to CFLAGS fixes the statvfs() issue. It expands to: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 Outcome: Running: cc -m32 statvfs-example.c -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -o statvfs-example-32 statvfs-example-32: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped statvfs() completed successfully. Running: cc -m64 statvfs-example.c -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -o statvfs-example-64 statvfs-example-64: ELF 64-bit LSB executable AMD64 Version 1 [SSE FXSR FPU], dynamically linked, not stripped statvfs() completed successfully. I don't yet have a proof, but I think that our perl might not handle statvfs() well. Does anyone know what perl functionality causes the statvfs() call to be made? From Darin.Perusich at cognigencorp.com Fri Apr 23 17:42:05 2010 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Fri, 23 Apr 2010 11:42:05 -0400 Subject: [csw-maintainers] installing packages on the "testing" hosts Message-ID: <4BD1BFCD.50802@cognigencorp.com> Is it possible to install packages on testing hosts? I use to be able to ssh as root over to them but am unable to now. I'm trying to figure out a problem with the new amanda package I'm building and being able to install in on something other solaris 10 would be helpful. -- Darin Perusich Unix Systems Administrator Cognigen Corporation 395 Youngs Rd. Williamsville, NY 14221 Phone: 716-633-3463 Email: darinper at cognigencorp.com From rupert at opencsw.org Fri Apr 23 19:55:45 2010 From: rupert at opencsw.org (rupert THURNER) Date: Fri, 23 Apr 2010 19:55:45 +0200 Subject: [csw-maintainers] apr compile failed on i386 In-Reply-To: <651DF211-DD52-4AA0-8F2E-67A3AF9987B5@opencsw.org> References: <651DF211-DD52-4AA0-8F2E-67A3AF9987B5@opencsw.org> Message-ID: On Wed, Apr 21, 2010 at 10:07, Dagobert Michelsen wrote: > Hi Rupert, > > Am 19.04.2010 um 21:56 schrieb Dagobert Michelsen: >> >> This is a GAR issue. I can't see the cause right now and rebuild apr to >> reproduce your problem and look into it. > > Sorry, I can not reproduce it. Does it still occur for you? > no - cannot reproduce with a clean build. rupert. From Darin.Perusich at cognigencorp.com Fri Apr 23 21:50:32 2010 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Fri, 23 Apr 2010 15:50:32 -0400 Subject: [csw-maintainers] opening both 32bit and 64bit shared libs Message-ID: <4BD1FA08.2090106@cognigencorp.com> Hello, I'm testing a new Amanda package and all the apps are core dumping and for some reason they are opening both the 32 and 64bit libgthread-2.0.so.0 libraries. Has anyone ever seen this or have any idea why it might be happening? When I truss execution you can see that both libs are being opened. root at testing9s : grep open /tmp/truss.out | grep -v NOENT | grep gthread open("/opt/csw/lib/libgthread-2.0.so.0", O_RDONLY) = 5 open("/opt/csw/lib/sparcv9/libgthread-2.0.so.0", O_RDONLY) = 5 The error I get just before it dumps core is: ERROR:glib-util.c:48:glib_init: assertion failed: (!g_thread_supported()) Line 48 of glib-util.c is wrapped in a libcurl definition so I'm wondering if this could be related to libcurl. #ifdef HAVE_LIBCURL # ifdef G_THREADS_ENABLED g_assert(!g_thread_supported()); # endif g_assert(curl_global_init(CURL_GLOBAL_ALL) == 0); #endif -- Darin Perusich Unix Systems Administrator Cognigen Corporation 395 Youngs Rd. Williamsville, NY 14221 Phone: 716-633-3463 Email: darinper at cognigencorp.com From phil at bolthole.com Fri Apr 23 23:25:29 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 23 Apr 2010 14:25:29 -0700 Subject: [csw-maintainers] opening both 32bit and 64bit shared libs In-Reply-To: <4BD1FA08.2090106@cognigencorp.com> References: <4BD1FA08.2090106@cognigencorp.com> Message-ID: On Fri, Apr 23, 2010 at 12:50 PM, Darin Perusich wrote: > Hello, > > I'm testing a new Amanda package and all the apps are core dumping and > for some reason they are opening both the 32 and 64bit > libgthread-2.0.so.0 libraries. Has anyone ever seen this or have any > idea why it might be happening? I believe that LD_DEBUG=files /run/your/app lets you know exactly why a particular shared lib is loaded. it might be that two different components of your dependancy tree, are pulling in two different versions of the "same" library? From Darin.Perusich at cognigencorp.com Sat Apr 24 01:32:26 2010 From: Darin.Perusich at cognigencorp.com (Darin.Perusich at cognigencorp.com) Date: Fri, 23 Apr 2010 19:32:26 -0400 (EDT) Subject: [csw-maintainers] opening both 32bit and 64bit shared libs In-Reply-To: References: <4BD1FA08.2090106@cognigencorp.com> Message-ID: <40919.69.207.26.168.1272065546.squirrel@onestop.cognigencorp.com> Thanks Phil, this should be very helpful. > On Fri, Apr 23, 2010 at 12:50 PM, Darin Perusich > wrote: >> Hello, >> >> I'm testing a new Amanda package and all the apps are core dumping and >> for some reason they are opening both the 32 and 64bit >> libgthread-2.0.so.0 libraries. Has anyone ever seen this or have any >> idea why it might be happening? > > I believe that > > LD_DEBUG=files /run/your/app > > > lets you know exactly why a particular shared lib is loaded. > > it might be that two different components of your dependancy tree, are > pulling in two different versions of the "same" library? > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From Darin.Perusich at cognigencorp.com Sat Apr 24 01:42:28 2010 From: Darin.Perusich at cognigencorp.com (Darin.Perusich at cognigencorp.com) Date: Fri, 23 Apr 2010 19:42:28 -0400 (EDT) Subject: [csw-maintainers] opening both 32bit and 64bit shared libs In-Reply-To: References: <4BD1FA08.2090106@cognigencorp.com> Message-ID: <43733.69.207.26.168.1272066148.squirrel@onestop.cognigencorp.com> So when I run "LD_DEBUG=all /opt/csw/sbin/amstatus test" this reference to /opt/csw/lib/sparcv9/libgthread-2.0.so.0 is only mentioned once in the output, see below. I'm not sure out to interrupt this output, does it mean the libgthread-2.0.so.0 is trying to use the 64bit library? 22836: 1: find object=libgthread-2.0.so.0; searching 22836: 1: search path=/opt/csw/lib/$ISALIST:/opt/csw/lib:/opt/csw/lib (RPATH from file /opt/csw/lib/libgobject-2.0.so.0) 22836: 1: trying path=/opt/csw/lib/sparcv9+vis2/libgthread-2.0.so.0 22836: 1: trying path=/opt/csw/lib/sparcv9+vis/libgthread-2.0.so.0 22836: 1: trying path=/opt/csw/lib/sparcv9/libgthread-2.0.so.0 22836: 1: 22836: 1: file=/opt/csw/lib/sparcv9/libgthread-2.0.so.0; rejected: wrong ELF class: ELFCLASS64 22836: 1: 22836: 1: trying path=/opt/csw/lib/sparcv8plus+vis2/libgthread-2.0.so.0 22836: 1: trying path=/opt/csw/lib/sparcv8plus+vis/libgthread-2.0.so.0 22836: 1: trying path=/opt/csw/lib/sparcv8plus/libgthread-2.0.so.0 22836: 1: trying path=/opt/csw/lib/sparcv8/libgthread-2.0.so.0 22836: 1: file=/opt/csw/lib/sparcv8/libgthread-2.0.so.0 skipped: already processed as /opt/csw/lib/libgthread-2.0.so.0 22836: 1: 22836: 1: file=/opt/csw/lib/libgobject-2.0.so.0; add binding to: 22836: 1: file=/opt/csw/lib/libgthread-2.0.so.0 [ NEEDED ] > On Fri, Apr 23, 2010 at 12:50 PM, Darin Perusich > wrote: >> Hello, >> >> I'm testing a new Amanda package and all the apps are core dumping and >> for some reason they are opening both the 32 and 64bit >> libgthread-2.0.so.0 libraries. Has anyone ever seen this or have any >> idea why it might be happening? > > I believe that > > LD_DEBUG=files /run/your/app > > From phil at bolthole.com Sat Apr 24 07:01:53 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 23 Apr 2010 22:01:53 -0700 Subject: [csw-maintainers] opening both 32bit and 64bit shared libs In-Reply-To: <43733.69.207.26.168.1272066148.squirrel@onestop.cognigencorp.com> References: <4BD1FA08.2090106@cognigencorp.com> <43733.69.207.26.168.1272066148.squirrel@onestop.cognigencorp.com> Message-ID: On Friday, April 23, 2010, wrote: > So when I run "LD_DEBUG=all /opt/csw/sbin/amstatus test" this reference to > /opt/csw/lib/sparcv9/libgthread-2.0.so.0 is only mentioned once in the > output, see below. I'm not sure out to interrupt this output, does it mean > the libgthread-2.0.so.0 is trying to use the 64bit library? > it would appear that it CONSIDERS using it... for which it has to open() the file... but then appropriately rejects it. the odd thing is why ISALIST is expanding to include sparc v9 for a 32 bit executable. something very wrong there. perhaps a prior library incorrectly loaded ? From maciej at opencsw.org Sat Apr 24 09:49:14 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 24 Apr 2010 08:49:14 +0100 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs idle, python, python_devel, python_tk In-Reply-To: References: <201004200557.o3K5vQGr024663@login.bo.opencsw.org> Message-ID: No dia 23 de Abril de 2010 21:49, Philip Brown escreveu: > erm... there's some really really old legacy garbage in the python package. > > ERROR: build-machine paths found in file > python-2.6.5,REV=2010.04.19-SunOS5.9-sparc-CSW.pkg.gz Yes, this is known and expected. It deserves a bit of explanation. I'm cc'ing maintainers@, as the same issue might affect other people too. The CSWpython package contains legacy shared library, namely /opt/csw/lib/libpython2.5.so.1.0. This file is stored in the repository in the binary form and added to the pkgroot in a separate step during building. It's not recompiled any more. There's no description to compile it, so it's bound to stay the way it is until it's removed. The legacy library contains build-machine paths, and it always did. Here's a session dump from build9s: maciej at current9s :~/src/opencsw/pkg/python/trunk > ggrep medusa /opt/csw/lib/libpython2.5.so.1.0 Binary file /opt/csw/lib/libpython2.5.so.1.0 matches The reason we didn't know about it is because the pre-maciej version of checkpkg failed to detect that. Current version of checkpkg does detect and report it. There is a need to tell checkpkg that we know about this problem and that it's okay. If you look into python-2.6.5,REV=2010.04.19-SunOS5.9-sparc-CSW.pkg.gz, you'll notice: /opt/csw/share/checkpkg/overrides/python containing: CSWpython: file-with-bad-content /export/medusa root/opt/csw/lib/libpython2.5.so.1.0 CSWpython: file-with-bad-content /opt/build root/opt/csw/lib/libpython2.5.so.1.0 CSWpython: file-with-bad-content /export/medusa root/opt/csw/share/checkpkg/overrides/python CSWpython: file-with-bad-content /opt/build root/opt/csw/share/checkpkg/overrides/python The override file is a plaintext file, and it contains the "/export/medusa" string. I believe that this is the file that the old checkpkg complained about. If it was able to detect build-machine paths reliably, it would have always complained about CSWpython. Looking at the whole catalog, there are currently 189 packages affected by this issue (build-machine paths). Here's the list of packages with details: http://www.opencsw.org/~maciej/bad-content.txt Maciej From rupert at opencsw.org Sun Apr 25 17:05:49 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 25 Apr 2010 17:05:49 +0200 Subject: [csw-maintainers] getting apache2 ldaps authentication to work: test openldap, apache2 In-Reply-To: References: Message-ID: hi, last week we did not get the ldaps authentication of apache2 working with the current package versions in http://opencsw.org/packages. up to now we have no idea if openssl might be responsible or openldap, or even apache2. so i tried to upgrade to recent and recompile the concerned packages apche2 (done), openssl (failed in at configure), and openldap (half-done). as there are so many dependencies i'd be glad about some help and testing. we will test only the following scenario: apache2 authentication via ldaps, on sparc. as openssl recently was successfully built, we will ?try two scenarios, (1) with the old openssl and (2) with a newly built openldap. when compiling i had 3 issues see below for the longer error messages: 1. openldap did not link on i386 2. gar complained when doing a remerge 3. openssl - configure did not work ad 1. /usr/ccs/bin/ld -G -h libldap-2.3.so.0 -o .libs/libldap-2.3.so.0.2.31 .libs/bind.o .libs/open.o .libs/result.o .libs/error.o .libs/compare.o .libs/search.o .libs/controls.o .libs/messages.o .libs/references.o .libs/extended.o .libs/cyrus.o .libs/modify.o .libs/add.o .libs/modrdn.o .libs/delete.o .libs/abandon.o .libs/sasl.o .libs/sbind.o .libs/kbind.o .libs/unbind.o .libs/cancel.o .libs/filter.o .libs/free.o .libs/sort.o .libs/passwd.o .libs/whoami.o .libs/getdn.o .libs/getentry.o .libs/getattr.o .libs/getvalues.o .libs/addentry.o .libs/request.o .libs/os-ip.o .libs/url.o .libs/sortctrl.o .libs/vlvctrl.o .libs/init.o .libs/options.o .libs/print.o .libs/string.o .libs/util-int.o .libs/schema.o .libs/charray.o .libs/tls.o .libs/os-local.o .libs/dnssrv.o .libs/utf-8.o .libs/utf-8-conv.o .libs/turn.o .libs/groupings.o .libs/txn.o .libs/ppolicy.o .libs/version.o ?-R/opt/csw/lib/64 -L/opt/csw/bdb44/lib/64 -L/opt/csw/lib/64 -L/home/rupert/mgar/pkg/openldap/trunk/work/solaris9-i386/install-isa-amd64-garversion-2.3.43/opt/csw/lib/64 -llber -lresolv -lgen -lnsl -lsocket -lssl -lcrypto -lc ld: fatal: file libld.so.3: dlopen failed: ld.so.1: ld: fatal: libld.so.3: open failed: No such file or directory libtool: install: error: relink `libldap.la' with the above command before installing it gmake[4]: *** [install-local] Error 1 gmake[4]: Leaving directory `/home/rupert/mgar/pkg/openldap/trunk/work/solaris9-i386/build-isa-amd64-garversion-2.3.43/openldap-2.3.43/libraries/libldap' gmake[3]: *** [install-common] Error 1 gmake[3]: Leaving directory `/home/rupert/mgar/pkg/openldap/trunk/work/solaris9-i386/build-isa-amd64-garversion-2.3.43/openldap-2.3.43/libraries' gmake[2]: *** [install-common] Error 1 gmake[2]: Leaving directory `/home/rupert/mgar/pkg/openldap/trunk/work/solaris9-i386/build-isa-amd64-garversion-2.3.43/openldap-2.3.43' gmake[1]: *** [install-work/solaris9-i386/build-isa-amd64-garversion-2.3.43/openldap-2.3.43/Makefile] Error 2 gmake[1]: Leaving directory `/home/rupert/mgar/pkg/openldap/trunk' gmake: *** [reset-install-isa-amd64-garversion-2.3.43] Error 2 gmake: Leaving directory `/home/rupert/mgar/pkg/openldap/trunk' Connection to current9x closed. ad 2. just as a sidenote, is it possible that there is still a glitch in gar? in the beginning, the openldap compile ended with a compiled sparc 2.4.21 version, with checkpkg failing. correcting the makefile and doing a repackage ended with The ISA 'amd64' can not be build on this kernel with the arch 'i386' : rupert at current9s ~/mgar/pkg/openldap/trunk $ gmake platforms-reinstall platforms-remerge platforms-repackage .... /home/rupert/mgar/pkg/openldap/trunk/work/solaris9-i386/pkgroot/./etc/opt/csw/openldap/DB_CONFIG.example /home/rupert/mgar/pkg/openldap/trunk/work/solaris9-i386/pkgroot/./etc/opt/csw/openldap/ldap.conf /home/rupert/mgar/pkg/openldap/trunk/work/solaris9-i386/pkgroot/./etc/opt/csw/openldap/slapd.conf.default gmake[1]: Leaving directory `/home/rupert/mgar/pkg/openldap/trunk' gmake[1]: Entering directory `/home/rupert/mgar/pkg/openldap/trunk' [ Reset install state for modulation isa-amd64-garversion-2.3.43: ISA=amd64 GARVERSION=2.3.43 ] gmake[1]: Leaving directory `/home/rupert/mgar/pkg/openldap/trunk' gmake[1]: Entering directory `/home/rupert/mgar/pkg/openldap/trunk' gar/gar.conf.mk:418: *** The ISA 'amd64' can not be build on this kernel with the arch 'i386'. ?Stop. gmake[1]: Leaving directory `/home/rupert/mgar/pkg/openldap/trunk' gmake: *** [reset-install-isa-amd64-garversion-2.3.43] Error 2 gmake: Leaving directory `/home/rupert/mgar/pkg/openldap/trunk' Connection to current9x closed. gmake: *** [platforms-reinstall] Error 2 rupert at current9s ~/mgar/pkg/openldap/trunk rupert. From dam at opencsw.org Sun Apr 25 21:41:11 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 25 Apr 2010 21:41:11 +0200 Subject: [csw-maintainers] opening both 32bit and 64bit shared libs In-Reply-To: References: <4BD1FA08.2090106@cognigencorp.com> <43733.69.207.26.168.1272066148.squirrel@onestop.cognigencorp.com> Message-ID: <81890504-F4A0-4646-B2B0-C91CA0E38958@opencsw.org> Hi, Am 24.04.2010 um 07:01 schrieb Philip Brown: > On Friday, April 23, 2010, wrote: >> So when I run "LD_DEBUG=all /opt/csw/sbin/amstatus test" this reference to >> /opt/csw/lib/sparcv9/libgthread-2.0.so.0 is only mentioned once in the >> output, see below. I'm not sure out to interrupt this output, does it mean >> the libgthread-2.0.so.0 is trying to use the 64bit library? > > it would appear that it CONSIDERS using it... for which it has to > open() the file... but then appropriately rejects it. > > the odd thing is why ISALIST is expanding to include sparc v9 for a 32 > bit executable. something very wrong there. > perhaps a prior library incorrectly loaded ? This is perfectly normal. The reason is because sysinfo(2)(SI_ISALIST,...) doesn't look for 32/64 bits for the result - it is always the same. The reason for this is because /usr/lib/isaexec uses this same syscall to find the best ISA, which may very well be 64 bit binary even if isaesec itself is 32 bit. It may be wise of there would be another syscall for the linker, but there isn't. Hence this is normal behaviour and does not lead to your problem. There must be another cause. Best regards -- Dago From dam at opencsw.org Sun Apr 25 21:56:52 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 25 Apr 2010 21:56:52 +0200 Subject: [csw-maintainers] getting apache2 ldaps authentication to work: test openldap, apache2 In-Reply-To: References: Message-ID: Hi Rupert. Am 25.04.2010 um 17:05 schrieb rupert THURNER: > last week we did not get the ldaps authentication of apache2 working > with the current package versions in http://opencsw.org/packages. up > to now we have no idea if openssl might be responsible or openldap, or > even apache2. > > so i tried to upgrade to recent and recompile the concerned packages > apche2 (done), openssl (failed in at configure), Yann: Does it build cleanly for you? > and openldap > (half-done). The package is AFAIK not ready for release and needs some more work. David Mantock was working on it. David, what is your current status about it? I'll also have a look, but the more eyes the better. > as there are so many dependencies i'd be glad about some help and > testing. we will test only the following scenario: apache2 > authentication via ldaps, on sparc. as openssl recently was > successfully built, we will try two scenarios, (1) with the old > openssl and (2) with a newly built openldap. > > when compiling i had 3 issues see below for the longer error messages: > 1. openldap did not link on i386 > 2. gar complained when doing a remerge I'll see if I can reproduce it. > 3. openssl - configure did not work It looks like the patches can not be applied to 1.0.0 Yann? Best regards -- Dago From ihsan at opencsw.org Sun Apr 25 22:04:46 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 25 Apr 2010 22:04:46 +0200 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: References: <4ADB45B0.1000207@opencsw.org> <4BCACCDE.7060807@opencsw.org> <4BCC24BE.1080900@opencsw.org> Message-ID: <4BD4A05E.4080409@opencsw.org> On 4/19/10 6:22 PM, rupert THURNER wrote: >>>>> The Apache 2 package needs to be reworked and I can't find any >>>>> additional ressources at this time. Would be great if someone could take >>>>> over this package. >>>> Still nobody interested in taking over Apache? >>> Didn't Rupert do some work on it? >> Not that I'm aware of. >> Rupert? > > maciej, and me did some yes .. but this was far from good. now there > is only one single package contrary to the sophisticated setup before. > a package of version 2.2.14 is on > http://mirror.opencsw.org/testing.html. Would be great if you guys could go on with with the work. As I already mentioned before, I really don't have the resources to rework the package. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From yann at pleiades.fr.eu.org Mon Apr 26 13:18:25 2010 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Mon, 26 Apr 2010 13:18:25 +0200 Subject: [csw-maintainers] getting apache2 ldaps authentication to work: test openldap, apache2 In-Reply-To: References: Message-ID: <4BD57681.1020007@pleiades.fr.eu.org> Le 25/04/2010 21:56, Dagobert Michelsen a ?crit : >> so i tried to upgrade to recent and recompile the concerned packages >> apche2 (done), openssl (failed in at configure), > > Yann: Does it build cleanly for you? Are we talking about 0.9.8 or 1.0.0 ? >> 3. openssl - configure did not work > > It looks like the patches can not be applied to 1.0.0 Yann? Yes it can't. I already locally updated the patches in the openssl1 package but didn't commit until now. You can find the updated patch here: http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/openssl1/trunk/files/more_configure_targets.patch?revision=9769&view=raw But I didn't finish working on this package, so I am not sure it will build and work cleanly. Yann From Darin.Perusich at cognigencorp.com Mon Apr 26 15:09:49 2010 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Mon, 26 Apr 2010 09:09:49 -0400 Subject: [csw-maintainers] opening both 32bit and 64bit shared libs In-Reply-To: <81890504-F4A0-4646-B2B0-C91CA0E38958@opencsw.org> References: <4BD1FA08.2090106@cognigencorp.com> <43733.69.207.26.168.1272066148.squirrel@onestop.cognigencorp.com> <81890504-F4A0-4646-B2B0-C91CA0E38958@opencsw.org> Message-ID: <4BD5909D.6080207@cognigencorp.com> Dago, On 04/25/2010 03:41 PM, Dagobert Michelsen wrote: > Hi, > > Am 24.04.2010 um 07:01 schrieb Philip Brown: >> On Friday, April 23, 2010, wrote: >>> So when I run "LD_DEBUG=all /opt/csw/sbin/amstatus test" this reference to >>> /opt/csw/lib/sparcv9/libgthread-2.0.so.0 is only mentioned once in the >>> output, see below. I'm not sure out to interrupt this output, does it mean >>> the libgthread-2.0.so.0 is trying to use the 64bit library? >> >> it would appear that it CONSIDERS using it... for which it has to >> open() the file... but then appropriately rejects it. >> >> the odd thing is why ISALIST is expanding to include sparc v9 for a 32 >> bit executable. something very wrong there. >> perhaps a prior library incorrectly loaded ? > > This is perfectly normal. The reason is because sysinfo(2)(SI_ISALIST,...) > doesn't look for 32/64 bits for the result - it is always the same. The > reason for this is because /usr/lib/isaexec uses this same syscall to > find the best ISA, which may very well be 64 bit binary even if isaesec > itself is 32 bit. It may be wise of there would be another syscall for > the linker, but there isn't. Hence this is normal behaviour and does > not lead to your problem. There must be another cause. > You say this is normal behavior, i.e listing all the applicable libraries, but there is no other instance where an open() to a 64bit library is occurring. Whenever a 64bit lib is evaluated I get "rejected: wrong ELF class: ELFCLASS64" for those libs. -- Darin Perusich Unix Systems Administrator Cognigen Corporation 395 Youngs Rd. Williamsville, NY 14221 Phone: 716-633-3463 Email: darinper at cognigencorp.com From dam at opencsw.org Mon Apr 26 17:10:48 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 26 Apr 2010 17:10:48 +0200 Subject: [csw-maintainers] opening both 32bit and 64bit shared libs In-Reply-To: <4BD5909D.6080207@cognigencorp.com> References: <4BD1FA08.2090106@cognigencorp.com> <43733.69.207.26.168.1272066148.squirrel@onestop.cognigencorp.com> <81890504-F4A0-4646-B2B0-C91CA0E38958@opencsw.org> <4BD5909D.6080207@cognigencorp.com> Message-ID: Hi Darin, Am 26.04.2010 um 15:09 schrieb Darin Perusich: > You say this is normal behavior, i.e listing all the applicable > libraries, but there is no other instance where an open() to a 64bit > library is occurring. Whenever a 64bit lib is evaluated I get > "rejected: > wrong ELF class: ELFCLASS64" for those libs. Just take an arbitrary binary from /opt/csw/bin which has $ISALIST in the RPATH, like 411toppm. It is always the same behaviour: dam at testing9s :/opt/csw/bin > dump -Lv 411toppm 411toppm: **** DYNAMIC SECTION INFORMATION **** .dynamic: [INDEX] Tag Value [1] NEEDED libnetpbm.so.10 [2] NEEDED libpng12.so.0 [3] NEEDED libz.so [4] NEEDED libjpeg.so.62 [5] NEEDED libtiff.so.3 [6] NEEDED libm.so.1 [7] NEEDED libsocket.so.1 [8] NEEDED libnsl.so.1 [9] NEEDED libc.so.1 [10] INIT 0x1fe258 [11] FINI 0x1fe268 [12] RUNPATH /opt/csw/lib/$ISALIST:/opt/csw/lib [13] RPATH /opt/csw/lib/$ISALIST:/opt/csw/lib [14] HASH 0x100e8 ... dam at testing9s :/opt/csw/bin > truss -f ./411toppm 2932: execve("netpbm", 0xFFBFFAD4, 0xFFBFFADC) argc = 1 ... 2932: mprotect(0xFF1C0000, 159436, PROT_READ|PROT_EXEC) = 0 2932: stat("/opt/csw/lib/sparcv9+vis2/libjpeg.so.7", 0xFFBFF148) Err#2 ENOENT 2932: stat("/opt/csw/lib/sparcv9+vis/libjpeg.so.7", 0xFFBFF148) Err#2 ENOENT 2932: stat("/opt/csw/lib/sparcv9/libjpeg.so.7", 0xFFBFF148) = 0 2932: resolvepath("/opt/csw/lib/sparcv9/libjpeg.so.7", "/opt/csw/lib/ sparcv9/libjpeg.so.7.0.0", 1023) = 37 2932: open("/opt/csw/lib/sparcv9/libjpeg.so.7", O_RDONLY) = 3 2932: mmap(0x00010000, 32768, PROT_READ|PROT_EXEC, MAP_PRIVATE| MAP_ALIGN, 3, 0) = 0xFF0F0000 2932: close(3) = 0 2932: stat("/opt/csw/lib/sparcv8plus+vis2/libjpeg.so.7", 0xFFBFF148) Err#2 ENOENT 2932: stat("/opt/csw/lib/sparcv8plus+vis/libjpeg.so.7", 0xFFBFF148) Err#2 ENOENT 2932: stat("/opt/csw/lib/sparcv8plus/libjpeg.so.7", 0xFFBFF148) Err#2 ENOENT 2932: stat("/opt/csw/lib/sparcv8/libjpeg.so.7", 0xFFBFF148) = 0 2932: resolvepath("/opt/csw/lib/sparcv8/libjpeg.so.7", "/opt/csw/lib/ libjpeg.so.7.0.0", 1023) = 29 2932: open("/opt/csw/lib/sparcv8/libjpeg.so.7", O_RDONLY) = 3 2932: mmap(0xFF0F0000, 32768, PROT_READ|PROT_EXEC, MAP_PRIVATE| MAP_FIXED, 3, 0) = 0xFF0F0000 2932: mmap(0x00010000, 368640, PROT_NONE, MAP_PRIVATE|MAP_NORESERVE| MAP_ANON|MAP_ALIGN, -1, 0) = 0xFEDA0000 ... Best regards -- Dago From Darin.Perusich at cognigencorp.com Mon Apr 26 18:26:14 2010 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Mon, 26 Apr 2010 12:26:14 -0400 Subject: [csw-maintainers] opening both 32bit and 64bit shared libs In-Reply-To: References: <4BD1FA08.2090106@cognigencorp.com> <43733.69.207.26.168.1272066148.squirrel@onestop.cognigencorp.com> <81890504-F4A0-4646-B2B0-C91CA0E38958@opencsw.org> <4BD5909D.6080207@cognigencorp.com> Message-ID: <4BD5BEA6.9070800@cognigencorp.com> Hi Dago, I see what you're saying but the behavior I'm seeing is that it's only attempting to open the 64bit lib and never the 32bit one, see below. I've been in contact with the Amanda developers and they're not sure what's going on or how to proceed. From how things appear the problem is outside of the amanda libs and is glib2 related. I've definitely reached a point where I don't know how to proceed so any guidance will be greatly appreciated. Thanks grep open /tmp/amtruss.out |grep -v NOENT | grep gthread open("/opt/csw/lib/sparcv9/libgthread-2.0.so.0", O_RDONLY) = 5 open("/opt/csw/lib/sparcv8/libgthread-2.0.so.0", O_RDONLY) = 5 open("/opt/csw/lib/sparcv9/libgthread-2.0.so.0", O_RDONLY) = 5 open("/opt/csw/lib/sparcv9/libgthread-2.0.so.0", O_RDONLY) = 5 open("/opt/csw/lib/sparcv9/libgthread-2.0.so.0", O_RDONLY) = 5 open("/opt/csw/lib/sparcv9/libgthread-2.0.so.0", O_RDONLY) = 5 open("/opt/csw/lib/sparcv9/libgthread-2.0.so.0", O_RDONLY) = 4 open("/opt/csw/lib/sparcv9/libgthread-2.0.so.0", O_RDONLY) = 5 open("/opt/csw/lib/sparcv9/libgthread-2.0.so.0", O_RDONLY) = 5 open("/opt/csw/lib/sparcv9/libgthread-2.0.so.0", O_RDONLY) = 5 open("/opt/csw/lib/sparcv9/libgthread-2.0.so.0", O_RDONLY) = 5 On 04/26/2010 11:10 AM, Dagobert Michelsen wrote: > Hi Darin, > > Am 26.04.2010 um 15:09 schrieb Darin Perusich: >> You say this is normal behavior, i.e listing all the applicable >> libraries, but there is no other instance where an open() to a 64bit >> library is occurring. Whenever a 64bit lib is evaluated I get "rejected: >> wrong ELF class: ELFCLASS64" for those libs. > > Just take an arbitrary binary from /opt/csw/bin which has $ISALIST > in the RPATH, like 411toppm. It is always the same behaviour: > > dam at testing9s :/opt/csw/bin > dump -Lv 411toppm > > 411toppm: > > **** DYNAMIC SECTION INFORMATION **** > .dynamic: > [INDEX] Tag Value > [1] NEEDED libnetpbm.so.10 > [2] NEEDED libpng12.so.0 > [3] NEEDED libz.so > [4] NEEDED libjpeg.so.62 > [5] NEEDED libtiff.so.3 > [6] NEEDED libm.so.1 > [7] NEEDED libsocket.so.1 > [8] NEEDED libnsl.so.1 > [9] NEEDED libc.so.1 > [10] INIT 0x1fe258 > [11] FINI 0x1fe268 > [12] RUNPATH /opt/csw/lib/$ISALIST:/opt/csw/lib > [13] RPATH /opt/csw/lib/$ISALIST:/opt/csw/lib > [14] HASH 0x100e8 > ... > > dam at testing9s :/opt/csw/bin > truss -f ./411toppm > 2932: execve("netpbm", 0xFFBFFAD4, 0xFFBFFADC) argc = 1 > ... > 2932: mprotect(0xFF1C0000, 159436, PROT_READ|PROT_EXEC) = 0 > 2932: stat("/opt/csw/lib/sparcv9+vis2/libjpeg.so.7", 0xFFBFF148) Err#2 > ENOENT > 2932: stat("/opt/csw/lib/sparcv9+vis/libjpeg.so.7", 0xFFBFF148) Err#2 > ENOENT > 2932: stat("/opt/csw/lib/sparcv9/libjpeg.so.7", 0xFFBFF148) = 0 > 2932: resolvepath("/opt/csw/lib/sparcv9/libjpeg.so.7", > "/opt/csw/lib/sparcv9/libjpeg.so.7.0.0", 1023) = 37 > 2932: open("/opt/csw/lib/sparcv9/libjpeg.so.7", O_RDONLY) = 3 > 2932: mmap(0x00010000, 32768, PROT_READ|PROT_EXEC, > MAP_PRIVATE|MAP_ALIGN, 3, 0) = 0xFF0F0000 > 2932: close(3) = 0 > 2932: stat("/opt/csw/lib/sparcv8plus+vis2/libjpeg.so.7", 0xFFBFF148) > Err#2 ENOENT > 2932: stat("/opt/csw/lib/sparcv8plus+vis/libjpeg.so.7", 0xFFBFF148) > Err#2 ENOENT > 2932: stat("/opt/csw/lib/sparcv8plus/libjpeg.so.7", 0xFFBFF148) Err#2 > ENOENT > 2932: stat("/opt/csw/lib/sparcv8/libjpeg.so.7", 0xFFBFF148) = 0 > 2932: resolvepath("/opt/csw/lib/sparcv8/libjpeg.so.7", > "/opt/csw/lib/libjpeg.so.7.0.0", 1023) = 29 > 2932: open("/opt/csw/lib/sparcv8/libjpeg.so.7", O_RDONLY) = 3 > 2932: mmap(0xFF0F0000, 32768, PROT_READ|PROT_EXEC, > MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFF0F0000 > 2932: mmap(0x00010000, 368640, PROT_NONE, > MAP_PRIVATE|MAP_NORESERVE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFEDA0000 > ... > > > Best regards > > -- Dago > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -- Darin Perusich Unix Systems Administrator Cognigen Corporation 395 Youngs Rd. Williamsville, NY 14221 Phone: 716-633-3463 Email: darinper at cognigencorp.com From phil at bolthole.com Mon Apr 26 18:31:09 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 26 Apr 2010 09:31:09 -0700 Subject: [csw-maintainers] opening both 32bit and 64bit shared libs In-Reply-To: <4BD5BEA6.9070800@cognigencorp.com> References: <4BD1FA08.2090106@cognigencorp.com> <43733.69.207.26.168.1272066148.squirrel@onestop.cognigencorp.com> <81890504-F4A0-4646-B2B0-C91CA0E38958@opencsw.org> <4BD5909D.6080207@cognigencorp.com> <4BD5BEA6.9070800@cognigencorp.com> Message-ID: On Mon, Apr 26, 2010 at 9:26 AM, Darin Perusich wrote: > Hi Dago, > > I see what you're saying but the behavior I'm seeing is that it's only > attempting to open the 64bit lib and never the 32bit one, see below. Odd.I thought I saw the attempt to open the other one, in the LD_DEBUG output, rather than the truss one. From phil at bolthole.com Mon Apr 26 20:02:15 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 26 Apr 2010 11:02:15 -0700 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs idle, python, python_devel, python_tk In-Reply-To: References: <201004200557.o3K5vQGr024663@login.bo.opencsw.org> Message-ID: thanks for the explaination. batched From david.mantock at gmx.ch Mon Apr 26 17:32:28 2010 From: david.mantock at gmx.ch (David Mantock) Date: Mon, 26 Apr 2010 17:32:28 +0200 Subject: [csw-maintainers] getting apache2 ldaps authentication to work: test openldap, apache2 In-Reply-To: References: Message-ID: <059EA4012F9540BA9CCD68FFD5CD6556@DavidPC> I am sorry, but I do not have any time to be a CSW maintainer. I had hoped it would be OK, but my personal circumstances do not allow for it. Best regards, David Mantock -------------------------------------------------- From: "Dagobert Michelsen" Sent: Sunday, April 25, 2010 9:56 PM To: "List for OpenCSW maintainers" Cc: "Yann Rouillard" ; "David Mantock" Subject: Re: [csw-maintainers] getting apache2 ldaps authentication to work: test openldap, apache2 > Hi Rupert. > > Am 25.04.2010 um 17:05 schrieb rupert THURNER: >> last week we did not get the ldaps authentication of apache2 working >> with the current package versions in http://opencsw.org/packages. up >> to now we have no idea if openssl might be responsible or openldap, or >> even apache2. >> >> so i tried to upgrade to recent and recompile the concerned packages >> apche2 (done), openssl (failed in at configure), > > Yann: Does it build cleanly for you? > >> and openldap >> (half-done). > > The package is AFAIK not ready for release and needs some more work. > David Mantock was working on it. David, what is your current status > about it? > I'll also have a look, but the more eyes the better. > >> as there are so many dependencies i'd be glad about some help and >> testing. we will test only the following scenario: apache2 >> authentication via ldaps, on sparc. as openssl recently was >> successfully built, we will try two scenarios, (1) with the old >> openssl and (2) with a newly built openldap. >> >> when compiling i had 3 issues see below for the longer error messages: >> 1. openldap did not link on i386 >> 2. gar complained when doing a remerge > > I'll see if I can reproduce it. > >> 3. openssl - configure did not work > > It looks like the patches can not be applied to 1.0.0 Yann? > > > Best regards > > -- Dago From maciej at opencsw.org Tue Apr 27 19:55:26 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 27 Apr 2010 18:55:26 +0100 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs py_hachoir_core, py_hachoir_parser In-Reply-To: References: <201004270624.o3R6OnMw010611@login.bo.opencsw.org> Message-ID: No dia 27 de Abril de 2010 17:31, Philip Brown escreveu: > huh. > it would appear that the "core" was already named normally, but the > parser was not. > even though the "software name" already had the py prefix. Yes, it has fallen through the cracks. I had the right thing in mind, but missed the pkgname. I'm planning on adding a check for it. Dear maintainers, what do you think about the following: If a package installs stuff into /opt/csw/lib/python/site-packages, checkpkg will require the pkgname to begin with CSWpy-" and catalogname with "py_". If there are larger packages with just a couple Python files, a Python subpackage might be separated out (which usually is a good practice anyway) and prefixed. If there are exceptions (such as pythonsvn), overrides can be used. Thoughts? Maciej From skayser at opencsw.org Wed Apr 28 00:32:31 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 28 Apr 2010 00:32:31 +0200 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs py_hachoir_core, py_hachoir_parser In-Reply-To: References: <201004270624.o3R6OnMw010611@login.bo.opencsw.org> Message-ID: <4BD765FF.3080704@opencsw.org> Maciej (Matchek) Blizinski wrote on 27.04.2010 19:55: > No dia 27 de Abril de 2010 17:31, Philip Brown escreveu: >> huh. >> it would appear that the "core" was already named normally, but the >> parser was not. >> even though the "software name" already had the py prefix. > > Yes, it has fallen through the cracks. I had the right thing in mind, > but missed the pkgname. > > I'm planning on adding a check for it. > > Dear maintainers, what do you think about the following: > > If a package installs stuff into /opt/csw/lib/python/site-packages, > checkpkg will require the pkgname to begin with CSWpy-" and > catalogname with "py_". If there are larger packages with just a > couple Python files, a Python subpackage might be separated out (which > usually is a good practice anyway) and prefixed. If there are > exceptions (such as pythonsvn), overrides can be used. > > Thoughts? Sounds good. Helps to embed standards into the packaging workflow itself rather than to rely on people being aware of every tiny detail (yeah I know, they should be aware about the py_ prefix, but well). Does checkpkg already support explanations for thrown errors so that people can get a descriptive error message? Sebastian From james at opencsw.org Wed Apr 28 10:12:17 2010 From: james at opencsw.org (James Lee) Date: Wed, 28 Apr 2010 08:12:17 GMT Subject: [csw-maintainers] newpkgs py_hachoir_core, py_hachoir_parser In-Reply-To: References: Message-ID: <20100428.8121700.97698744@gyor.oxdrove.co.uk> On 27/04/10, 18:55:26, Maciej "(Matchek)" Blizinski wrote regarding Re: [csw-maintainers] [csw-pkgsubmissions] newpkgs py_hachoir_core, py_hachoir_parser: > If a package installs stuff into /opt/csw/lib/python/site-packages, > checkpkg will require the pkgname to begin with CSWpy-" and > catalogname with "py_". No. The fetchmailconf package contains a program called fetchmailconf that just happens to use python, a fact between uninteresting and irrelevant to the user. You could mean if a package exclusively installs stuff into. Avoidance tactic: I put fetchmailconf's python files in another directory. James. From maciej at opencsw.org Wed Apr 28 14:54:29 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 28 Apr 2010 13:54:29 +0100 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs py_hachoir_core, py_hachoir_parser In-Reply-To: <4BD765FF.3080704@opencsw.org> References: <201004270624.o3R6OnMw010611@login.bo.opencsw.org> <4BD765FF.3080704@opencsw.org> Message-ID: No dia 27 de Abril de 2010 23:32, Sebastian Kayser escreveu: > Sounds good. Helps to embed standards into the packaging workflow itself Yes, this is the idea. I've committed the new check, plus unit tests. > Does checkpkg already support explanations for thrown errors so that > people can get a descriptive error message? Yes, there is a Messenger class, which is passed to every checking function. It has a Message(str) function, to which you can pass a message string. You don't have to worry about the line breaks, the text will be automatically reformatted later on. You can pass it one long string with no line breaks and it will look nice in the output. Here's an example: -----------------8<-------------------- CSWhachoir-parser: # The package installs files into /opt/csw/lib/python. For example, # '/opt/csw/lib/python/site-packages'. However, the pkgname doesn't start with # 'CSWpy-'. # The package installs files into /opt/csw/lib/python. For example, # '/opt/csw/lib/python/site-packages'. However, the catalogname doesn't start # with 'py_'. # Missing dependencies of CSWhachoir-parser: # If you don't know of any reasons to include these dependencies, you might # remove them: # ? CSWpy-hachoir-core If any of the reported errors were false positives, you can override them pasting the lines below to the GAR recipe. CHECKPKG_OVERRIDES_CSWhachoir-parser += pkgname-does-not-start-with-CSWpy- CHECKPKG_OVERRIDES_CSWhachoir-parser += catalogname-does-not-start-with-py_ CHECKPKG_OVERRIDES_CSWhachoir-parser += surplus-dependency|CSWpy-hachoir-core Please note that checkpkg isn't suggesting you should use these overrides. It only informs what the overrides could look like. You need to understand what are the reported issues about and use your best judgement to decide whether to fix the underlying problems or override them. -----------------8<-------------------- The messages are displayed above the override lines, so if you have a lot of errors, they might get scrolled up a lot. I thought about saving them to disk somewhere, but it would make the UNCOMMITTED trigger go off. I'm still looking for a better way to format these messages. I don't want to spam the screen with too much of "READ THIS" kind of text, because with time, people will go numb. Perhaps some form of a bullet-point list? Ideas? From Darin.Perusich at cognigencorp.com Wed Apr 28 23:17:42 2010 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Wed, 28 Apr 2010 17:17:42 -0400 Subject: [csw-maintainers] gar question Message-ID: <4BD8A5F6.1070508@cognigencorp.com> Hello, I'm trying to build perl 8 from gar and it's failing to find the PathTools-3.30 dependency. The same thing happens when I attempt to build perl 10 as well. I thought all that need to be done was checkout the package, change to the trunk/tag directory, and run gmake. What am I doing wrong? -- Darin Perusich Unix Systems Administrator Cognigen Corporation 395 Youngs Rd. Williamsville, NY 14221 Phone: 716-633-3463 Email: darinper at cognigencorp.com From skayser at opencsw.org Wed Apr 28 23:53:24 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 28 Apr 2010 23:53:24 +0200 Subject: [csw-maintainers] gar question In-Reply-To: <4BD8A5F6.1070508@cognigencorp.com> References: <4BD8A5F6.1070508@cognigencorp.com> Message-ID: <4BD8AE54.2000801@opencsw.org> Darin Perusich wrote on 28.04.2010 23:17: > I'm trying to build perl 8 from gar and it's failing to find the > PathTools-3.30 dependency. The same thing happens when I attempt to > build perl 10 as well. I thought all that need to be done was checkout > the package, change to the trunk/tag directory, and run gmake. What am I > doing wrong? I can't speak for the perl recipe, only for the GAR workings in general. Most build recipes in GAR specify the runtime dependencies for a package (RUNTIME_DEP_PKGS), but not yet the build dependencies (BUILD_DEP_PKGS). If a recipe defines the build dependencies, GAR warns you in case any of the build depencies is missing. I guess the perl recipe doesn't define them, thus you can run into missing build dependencies. Either way you have to install such build dependencies manually, GAR doesn't pull them in automatically. @Dago: How about a GAR target a la "install-build-deps"? Sebastian P.S.: In an ideal world every recipe would define its build dependencies, so if you feel like adding some or letting the package maintainer know, please do so. From Darin.Perusich at cognigencorp.com Thu Apr 29 00:05:20 2010 From: Darin.Perusich at cognigencorp.com (Darin.Perusich at cognigencorp.com) Date: Wed, 28 Apr 2010 18:05:20 -0400 (EDT) Subject: [csw-maintainers] gar question In-Reply-To: <4BD8AE54.2000801@opencsw.org> References: <4BD8A5F6.1070508@cognigencorp.com> <4BD8AE54.2000801@opencsw.org> Message-ID: <39273.69.207.26.168.1272492320.squirrel@onestop.cognigencorp.com> > Darin Perusich wrote on 28.04.2010 23:17: >> I'm trying to build perl 8 from gar and it's failing to find the >> PathTools-3.30 dependency. The same thing happens when I attempt to >> build perl 10 as well. I thought all that need to be done was checkout >> the package, change to the trunk/tag directory, and run gmake. What am I >> doing wrong? > > I can't speak for the perl recipe, only for the GAR workings in general. > > Most build recipes in GAR specify the runtime dependencies for a package > (RUNTIME_DEP_PKGS), but not yet the build dependencies (BUILD_DEP_PKGS). > If a recipe defines the build dependencies, GAR warns you in case any > of the build depencies is missing. I guess the perl recipe doesn't > define them, thus you can run into missing build dependencies. > > Either way you have to install such build dependencies manually, GAR > doesn't pull them in automatically. @Dago: How about a GAR target a la > "install-build-deps"? I should have clarified that it's trying to download PathTools-3.30 and it's not available on any of the mirrors. From bwalton at opencsw.org Thu Apr 29 01:59:11 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 28 Apr 2010 19:59:11 -0400 Subject: [csw-maintainers] coreutils In-Reply-To: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca> References: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca> Message-ID: <1272499094-sup-8467@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Sat Apr 17 20:06:16 -0400 2010: Hi All, > I've created a project page in the wiki to track this: > http://wiki.opencsw.org/project-coreutils A quick status update: We're down to two packages requiring a re-roll before update testing can begin. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bonivart at opencsw.org Thu Apr 29 07:30:57 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 29 Apr 2010 07:30:57 +0200 Subject: [csw-maintainers] gar question In-Reply-To: <39273.69.207.26.168.1272492320.squirrel@onestop.cognigencorp.com> References: <4BD8A5F6.1070508@cognigencorp.com> <4BD8AE54.2000801@opencsw.org> <39273.69.207.26.168.1272492320.squirrel@onestop.cognigencorp.com> Message-ID: On Thu, Apr 29, 2010 at 12:05 AM, wrote: > I should have clarified that it's trying to download PathTools-3.30 and > it's not available on any of the mirrors. Path::Tools 3.30 seems to have vanished, it's now 3.31 that is current. Try that. -- /peter From dam at opencsw.org Thu Apr 29 09:42:56 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 29 Apr 2010 09:42:56 +0200 Subject: [csw-maintainers] gar question In-Reply-To: <39273.69.207.26.168.1272492320.squirrel@onestop.cognigencorp.com> References: <4BD8A5F6.1070508@cognigencorp.com> <4BD8AE54.2000801@opencsw.org> <39273.69.207.26.168.1272492320.squirrel@onestop.cognigencorp.com> Message-ID: <384F8273-5FEB-4CA8-9AFF-AD41A7BD5334@opencsw.org> Hi Darin, Am 29.04.2010 um 00:05 schrieb Darin.Perusich at cognigencorp.com: > I should have clarified that it's trying to download PathTools-3.30 and > it's not available on any of the mirrors. There seems to have been some spring cleaning on CPAN removing old versions. Often we have archived copies at /home/src, but obviously not in this case. As Peter suggested I would just bump the version and then do gmake makesum to start over. Best regards -- Dago From dam at opencsw.org Thu Apr 29 09:50:02 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 29 Apr 2010 09:50:02 +0200 Subject: [csw-maintainers] [csw-buildfarm] svn servers config file location changed? In-Reply-To: <4BD8B840.4020907@opencsw.org> References: <4BD8B840.4020907@opencsw.org> Message-ID: <1A794E9A-E846-4B08-B381-0FFD857A5F25@opencsw.org> Hi, Am 29.04.2010 um 00:35 schrieb Sebastian Kayser: > just noticed that svn on the build hosts seems to have forgotten about > our proxy. truss shows that it tries to open /etc/opt/csw/subversion/servers > whereas the build hosts only have /etc/subversion/servers. Did the > location used by svn change? There seems to be MIGRATECONF missing as in http://wiki.opencsw.org/cswclassutils-package#toc12 I guess it should be something like MIGRATE_FILES = servers config MIGRATE_SOURCE_DIR = /etc/subversion MIGRATE_DEST_DIR= /etc/opt/csw/subversion > @Rupert: Also noticed that the changelog.CSW file in the package is still > the one from the 1.6.6 version (my comment in the Makefile might have > been misleading), would you mind updating it for newer versions? :) Rupert, could you please respin subversion 1.6.9 with the migrateconf-directive? Best regards -- Dago From Darin.Perusich at cognigencorp.com Thu Apr 29 17:12:00 2010 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Thu, 29 Apr 2010 11:12:00 -0400 Subject: [csw-maintainers] gar question In-Reply-To: <384F8273-5FEB-4CA8-9AFF-AD41A7BD5334@opencsw.org> References: <4BD8A5F6.1070508@cognigencorp.com> <4BD8AE54.2000801@opencsw.org> <39273.69.207.26.168.1272492320.squirrel@onestop.cognigencorp.com> <384F8273-5FEB-4CA8-9AFF-AD41A7BD5334@opencsw.org> Message-ID: <4BD9A1C0.2030807@cognigencorp.com> Hi Dago, On 04/29/2010 03:42 AM, Dagobert Michelsen wrote: > There seems to have been some spring cleaning on CPAN removing old versions. > Often we have archived copies at /home/src, but obviously not in this case. > As Peter suggested I would just bump the version and then do > gmake makesum > to start over. I've done this and everything appears to build successfully, or at least I think it has. What do i need to do to create the package, use createpkg or is gar suppose to do this for me? -- Darin Perusich Unix Systems Administrator Cognigen Corporation 395 Youngs Rd. Williamsville, NY 14221 Phone: 716-633-3463 Email: darinper at cognigencorp.com From maciej at opencsw.org Thu Apr 29 17:35:49 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 29 Apr 2010 16:35:49 +0100 Subject: [csw-maintainers] gar question In-Reply-To: <4BD9A1C0.2030807@cognigencorp.com> References: <4BD8A5F6.1070508@cognigencorp.com> <4BD8AE54.2000801@opencsw.org> <39273.69.207.26.168.1272492320.squirrel@onestop.cognigencorp.com> <384F8273-5FEB-4CA8-9AFF-AD41A7BD5334@opencsw.org> <4BD9A1C0.2030807@cognigencorp.com> Message-ID: No dia 29 de Abril de 2010 16:12, Darin Perusich escreveu: > I've done this and everything appears to build successfully, or at least > I think it has. What do i need to do to create the package, use > createpkg or is gar suppose to do this for me? Try: gmake package From Darin.Perusich at cognigencorp.com Thu Apr 29 18:04:45 2010 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Thu, 29 Apr 2010 12:04:45 -0400 Subject: [csw-maintainers] gar question In-Reply-To: References: <4BD8A5F6.1070508@cognigencorp.com> <4BD8AE54.2000801@opencsw.org> <39273.69.207.26.168.1272492320.squirrel@onestop.cognigencorp.com> <384F8273-5FEB-4CA8-9AFF-AD41A7BD5334@opencsw.org> <4BD9A1C0.2030807@cognigencorp.com> Message-ID: <4BD9AE1D.8020107@cognigencorp.com> On 04/29/2010 11:35 AM, Maciej (Matchek) Blizinski wrote: > No dia 29 de Abril de 2010 16:12, Darin Perusich > escreveu: >> I've done this and everything appears to build successfully, or at least >> I think it has. What do i need to do to create the package, use >> createpkg or is gar suppose to do this for me? > > Try: > > gmake package That is what I'm doing and I'm getting these "ld.so.1: perl: fatal: libperl.so.5.8.8:" errors. everest:perl-5.8.8,REV=2009.11.12$ gmake package [===== NOW BUILDING: perl-5.8.8 =====] [prerequisite] complete for perl. [fetch] complete for perl. [checksum] complete for perl. [checksum-global] complete for perl. [checksum-modulated] complete for perl. [===== NOW BUILDING: perl-5.8.8 MODULATION global: ISA= =====] [extract-modulated] complete for perl. [===== Building modulation 'isa-sparcv8' on host '' =====] gmake MODULATION=isa-sparcv8 ISA=sparcv8 merge-modulated gmake[1]: Entering directory `/opt/perl-mgar/tags/perl-5.8.8,REV=2009.11.12' [===== NOW BUILDING: perl-5.8.8 MODULATION isa-sparcv8: ISA=sparcv8 =====] [extract-modulated] complete for perl. [patch-modulated] complete for perl. [configure-modulated] complete for perl. [test-modulated] complete for perl. ==> Applying core update: PathTools-3.31 ld.so.1: perl: fatal: libperl.so.5.8.8: open failed: No such file or directory Killed make: Fatal error: No arguments to build Current working directory /opt/perl-mgar/tags/perl-5.8.8,REV=2009.11.12/work/build-isa-sparcv8/PathTools-3.31 make: Fatal error: Don't know how to make target `test' Current working directory /opt/perl-mgar/tags/perl-5.8.8,REV=2009.11.12/work/build-isa-sparcv8/PathTools-3.31 make: Fatal error: Don't know how to make target `install' Current working directory /opt/perl-mgar/tags/perl-5.8.8,REV=2009.11.12/work/build-isa-sparcv8/PathTools-3.31 ==> Applying core update: CGI.pm-3.44 ld.so.1: perl: fatal: libperl.so.5.8.8: open failed: No such file or directory .. .. .. .. gmake[1]: *** [install-core-updates] Error 1 gmake[1]: Leaving directory `/opt/perl-mgar/tags/perl-5.8.8,REV=2009.11.12' gmake: *** [merge-isa-sparcv8] Error 2 -- Darin Perusich Unix Systems Administrator Cognigen Corporation 395 Youngs Rd. Williamsville, NY 14221 Phone: 716-633-3463 Email: darinper at cognigencorp.com From dam at opencsw.org Thu Apr 29 22:21:22 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 29 Apr 2010 22:21:22 +0200 Subject: [csw-maintainers] gar question In-Reply-To: <4BD9AE1D.8020107@cognigencorp.com> References: <4BD8A5F6.1070508@cognigencorp.com> <4BD8AE54.2000801@opencsw.org> <39273.69.207.26.168.1272492320.squirrel@onestop.cognigencorp.com> <384F8273-5FEB-4CA8-9AFF-AD41A7BD5334@opencsw.org> <4BD9A1C0.2030807@cognigencorp.com> <4BD9AE1D.8020107@cognigencorp.com> Message-ID: Hi Darin, Am 29.04.2010 um 18:04 schrieb Darin Perusich: > That is what I'm doing and I'm getting these "ld.so.1: perl: fatal: > libperl.so.5.8.8:" errors. This is a bit difficult. The problem is that the newly binaries are prepended to PATH and a tool needed by GAR itself has just been build but is not able to run because the libraries are not really installed and the binary doesn't have a wrapper to find libraries in relative locations. Please try IGNORE_DESTDIR = 1 and then do a gmake repackage Best regards -- Dago From hson at opencsw.org Fri Apr 30 01:37:08 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 30 Apr 2010 01:37:08 +0200 Subject: [csw-maintainers] opening both 32bit and 64bit shared libs In-Reply-To: <4BD5BEA6.9070800@cognigencorp.com> References: <4BD1FA08.2090106@cognigencorp.com> <43733.69.207.26.168.1272066148.squirrel@onestop.cognigencorp.com> <81890504-F4A0-4646-B2B0-C91CA0E38958@opencsw.org> <4BD5909D.6080207@cognigencorp.com> <4BD5BEA6.9070800@cognigencorp.com> Message-ID: <4BDA1824.7090604@opencsw.org> I'm just jumping right in the middle of this thread. Any reason why all amanda binaries are sparcv8+ and not just sparcv8? > > I see what you're saying but the behavior I'm seeing is that it's only > attempting to open the 64bit lib and never the 32bit one, see below. Incorrect, which you can see when you run LD_DEBUG and grep for NEEDED. Also you missed something in your grep... > grep open /tmp/amtruss.out |grep -v NOENT | grep gthread > open("/opt/csw/lib/sparcv9/libgthread-2.0.so.0", O_RDONLY) = 5 > open("/opt/csw/lib/sparcv8/libgthread-2.0.so.0", O_RDONLY) = 5 Note "sparcv8", not "sparcv9" The reason why it tries the v8 only once is that it becomes marked needed and is never considered again while the v9 is scrapped each time and have to be reconsidered. > I've been in contact with the Amanda developers and they're not sure > what's going on or how to proceed. From how things appear the problem is > outside of the amanda libs and is glib2 related. > > I've definitely reached a point where I don't know how to proceed so any > guidance will be greatly appreciated. > I think that you have been sidetracked by all this 32/64-stuff. You have a 32-bit binary and it is only using 32-bit libraries, period! The reason for the coredump have nothing to do with sparcv9, but as you mentioned in your initial mail, the assertion on lib 48 in glib_init. g_assert = print error and dump core This can also be seen if you use dbx on the core file that is produced. t at 1 (l at 1) program terminated by signal ABRT (Abort) 0xffffffffffffffff: Current function is glib_init 48 g_assert(!g_thread_supported()); (dbx) where current thread: t at 1 [1] 0xff3dc6f8(0xffbfe930, 0xa3, 0x1, 0x6, 0x2, 0x6), at 0xff3dc6f8 [2] 0xff3d8ea8(0x1, 0x6, 0x0, 0xfec3c000, 0x2, 0x0), at 0xff3d8ea8 [3] 0xff3dc658(0x1, 0x6, 0x0, 0xfec3c000, 0x2, 0x13), at 0xff3dc658 [4] raise(0x6, 0x0, 0xffbfeab8, 0xfec3c000, 0xd3ef4, 0xe400), at 0xfebd0b28 [5] abort(0x0, 0x1, 0xe45c, 0xfe825bc8, 0xd3ef4, 0xe400), at 0xfebb6e70 [6] g_assertion_message(0xe5c0, 0xe400, 0xfe83154c, 0xfffea530, 0x15800, 0xffbfebd4), at 0xfe77902c [7] g_assertion_message_expr(0x256fb0, 0xfe977d60, 0x30, 0xfe97e5ef, 0xacb70, 0x15800), at 0xfe7790a0 =>[8] glib_init(), line 48 in "glib-util.c" [9] device_api_init(), line 59 in "device.c" [10] boot_Amanda__Device(my_perl = 0x21370, cv = 0x25b2b8), line 4007 in "Device.c" For some reason which the amanda developers have to explain, they want to initialize libcurl before glib's threading is initialized, but I can't see how that code could really work. ---------------------------------------- /* set up libcurl (this must happen before threading * is initialized) */ #ifdef HAVE_LIBCURL # ifdef G_THREADS_ENABLED g_assert(!g_thread_supported()); # endif g_assert(curl_global_init(CURL_GLOBAL_ALL) == 0); #endif /* And set up glib's threads */ #if defined(G_THREADS_ENABLED) && !defined(G_THREADS_IMPL_NONE) if (g_thread_supported()) { return; } g_thread_init(NULL); #endif ---------------------------------------- Either you have to compile amanda without threading or without libcurl. But if they really mean what they write in the comment (that libcurl should be initialized before threading, and not that libcurl cannot work together with threading), the code maybe should be: ---------------------------------------- #ifdef HAVE_LIBCURL # ifdef G_THREADS_ENABLED if(g_thread_get_initialized ()) g_assert(!g_thread_supported()); # endif g_assert(curl_global_init(CURL_GLOBAL_ALL) == 0); #endif ---------------------------------------- From dam at opencsw.org Fri Apr 30 14:40:58 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 30 Apr 2010 14:40:58 +0200 Subject: [csw-maintainers] coreutils In-Reply-To: <1272499094-sup-8467@pinkfloyd.chass.utoronto.ca> References: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca> <1272499094-sup-8467@pinkfloyd.chass.utoronto.ca> Message-ID: <4B82DC81-95DA-4188-8978-A2F0CFF7BACA@opencsw.org> Hi Ben, Am 29.04.2010 um 01:59 schrieb Ben Walton: > Excerpts from Ben Walton's message of Sat Apr 17 20:06:16 -0400 2010: > > Hi All, > >> I've created a project page in the wiki to track this: >> http://wiki.opencsw.org/project-coreutils > > A quick status update: We're down to two packages requiring a re-roll > before update testing can begin. As you already updated the Makefile for cswutils feel free to reroll and take it over. Best reards -- Dago From dam at baltic-online.de Wed Apr 28 15:32:11 2010 From: dam at baltic-online.de (Dagobert Michelsen) Date: Wed, 28 Apr 2010 15:32:11 +0200 Subject: [csw-maintainers] Updating all server to current/ Message-ID: Hi, I am updating all servers to current/ now. Please stand by! Best regards -- Dago