From phil at bolthole.com Sun May 2 04:15:34 2010 From: phil at bolthole.com (Philip Brown) Date: Sat, 1 May 2010 19:15:34 -0700 Subject: [csw-maintainers] alternatives in testing Message-ID: FYI, I dropped initial go at csw specific implementation of "alternatives" in testing. should appear in a few mins. feedback is hereby requested From Darin.Perusich at cognigencorp.com Mon May 3 17:08:20 2010 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Mon, 03 May 2010 11:08:20 -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> <4BD9AE1D.8020107@cognigencorp.com> Message-ID: <4BDEE6E4.9070401@cognigencorp.com> Hi Dago, On 04/29/2010 04:21 PM, Dagobert Michelsen wrote: > locations. Please try > IGNORE_DESTDIR = 1 > and then do a > gmake repackage > This has gotten me a bit further...now I'm getting a pkgproto error which is causing the packaging to fail. gmake[1]: Leaving directory `/opt/perl-mgar/tags/perl-5.8.8,REV=2009.11.12' [merge-license] complete for perl. [merge] complete for perl. pkgproto: ERROR: unable to stat Failed to generate prototype at /opt/perl-mgar/tags/perl-5.8.8,REV=2009.11.12/gar/bin/cswproto line 131. gmake: *** [work/build-global/prototype] Error 1 -- Darin Perusich Unix Systems Administrator Cognigen Corporation 395 Youngs Rd. Williamsville, NY 14221 Phone: 716-633-3463 Email: darinper at cognigencorp.com From bwalton at opencsw.org Tue May 4 16:39:38 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 04 May 2010 10:39:38 -0400 Subject: [csw-maintainers] coreutils In-Reply-To: <4B82DC81-95DA-4188-8978-A2F0CFF7BACA@opencsw.org> References: <1271548989-sup-9916@pinkfloyd.chass.utoronto.ca> <1272499094-sup-8467@pinkfloyd.chass.utoronto.ca> <4B82DC81-95DA-4188-8978-A2F0CFF7BACA@opencsw.org> Message-ID: <1272983957-sup-982@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Fri Apr 30 08:40:58 -0400 2010: Hi Dago, > As you already updated the Makefile for cswutils feel free to reroll > and take it over. Will do. Thanks. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Wed May 5 16:34:38 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 5 May 2010 16:34:38 +0200 Subject: [csw-maintainers] gar question In-Reply-To: <4BDEE6E4.9070401@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> <4BDEE6E4.9070401@cognigencorp.com> Message-ID: Hi Darin, Am 03.05.2010 um 17:08 schrieb Darin Perusich: > This has gotten me a bit further...now I'm getting a pkgproto error > which is causing the packaging to fail. > > gmake[1]: Leaving directory `/opt/perl-mgar/tags/ > perl-5.8.8,REV=2009.11.12' > [merge-license] complete for perl. > [merge] complete for perl. > pkgproto: ERROR: unable to stat > Failed to generate prototype at > /opt/perl-mgar/tags/perl-5.8.8,REV=2009.11.12/gar/bin/cswproto line > 131. > gmake: *** [work/build-global/prototype] Error 1 There are a number of issues here: - The tag name is not suitable for pkgproto. The '=' is not allowed in pathnames as it is also used in prototypes. At the time I made this tag I was not aware of this issue. I have renamed the tag to work again. - The major difference between installed Perl 5.10.1 and build of Perl 5.8.8 leads to some effects in the core updates which needs fixing too. I am working on it. BTW, are you rebuilding 5.8.8 for a specific reason? Best regards -- Dago From Darin.Perusich at cognigencorp.com Wed May 5 17:04:56 2010 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Wed, 05 May 2010 11:04:56 -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> <4BD9AE1D.8020107@cognigencorp.com> <4BDEE6E4.9070401@cognigencorp.com> Message-ID: <4BE18918.1020208@cognigencorp.com> On 05/05/2010 10:34 AM, Dagobert Michelsen wrote: > There are a number of issues here: > - The tag name is not suitable for pkgproto. The '=' is not allowed in > pathnames > as it is also used in prototypes. At the time I made this tag I was > not aware > of this issue. I have renamed the tag to work again. > - The major difference between installed Perl 5.10.1 and build of Perl > 5.8.8 leads > to some effects in the core updates which needs fixing too. > > I am working on it. > > BTW, are you rebuilding 5.8.8 for a specific reason? > I was but I don't need it any longer so if you're working in it simply for this reason I wouldn't worry about it. Thanks Dago -- 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 Wed May 5 17:25:02 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 5 May 2010 17:25:02 +0200 Subject: [csw-maintainers] gar question In-Reply-To: <4BE18918.1020208@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> <4BDEE6E4.9070401@cognigencorp.com> <4BE18918.1020208@cognigencorp.com> Message-ID: Hi Darin, Am 05.05.2010 um 17:04 schrieb Darin Perusich: > On 05/05/2010 10:34 AM, Dagobert Michelsen wrote: >> There are a number of issues here: >> - The tag name is not suitable for pkgproto. The '=' is not allowed >> in >> pathnames >> as it is also used in prototypes. At the time I made this tag I was >> not aware >> of this issue. I have renamed the tag to work again. >> - The major difference between installed Perl 5.10.1 and build of >> Perl >> 5.8.8 leads >> to some effects in the core updates which needs fixing too. >> >> I am working on it. >> >> BTW, are you rebuilding 5.8.8 for a specific reason? > > I was but I don't need it any longer so if you're working in it simply > for this reason I wouldn't worry about it. Ah, ok. Then I would just leave it as it is now. Just let me know if there are other GAR issues you encounter :-) Best regards -- Dago From Darin.Perusich at cognigencorp.com Wed May 5 17:25:11 2010 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Wed, 05 May 2010 11:25:11 -0400 Subject: [csw-maintainers] cswinetd and cswetcservices? Message-ID: <4BE18DD7.5020004@cognigencorp.com> Hello all, Does the cswetcservices class check to see if a service is already listed in /etc/services before adding it? I've updated the Amanda package to use this class instead of a postinstall script and it's added the services again, i.e they are listed twice. Can someone explain or provide an example on how to have cswinetd *not* enable services by default? The docs say it honors the autoenable_* variables of cswinitsmf but after reviewing that documentation it's still not clear to me. Additional, how does this handle an inetd service that listens on both TCP and UDP? Thanks. -- Darin Perusich Unix Systems Administrator Cognigen Corporation 395 Youngs Rd. Williamsville, NY 14221 Phone: 716-633-3463 Email: darinper at cognigencorp.com From bwalton at opencsw.org Wed May 5 17:37:32 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 05 May 2010 11:37:32 -0400 Subject: [csw-maintainers] cswinetd and cswetcservices? In-Reply-To: <4BE18DD7.5020004@cognigencorp.com> References: <4BE18DD7.5020004@cognigencorp.com> Message-ID: <1273073623-sup-7955@pinkfloyd.chass.utoronto.ca> Excerpts from Darin Perusich's message of Wed May 05 11:25:11 -0400 2010: Hi Darin, > Does the cswetcservices class check to see if a service is already > listed in /etc/services before adding it? I've updated the Amanda > package to use this class instead of a postinstall script and it's > added the services again, i.e they are listed twice. It tries to. The heuristic used to determine whether or not to add the line is: /usr/xpg4/bin/grep -q "^$svcname[[:space:]].*$port_proto.*$PKGINST" /etc/services The lines added by the CAS include a '# CSWfoo' as a suffix to indicate they were added by the script. I guess the detection should likely just look for: "^$svcname[[:space:]].*$port_proto" This would better handle things not added/maintained by the script itself and thus situations like yours. Do you see anything wrong with this for your (or other) uses? (The r.cswetcservices script doesn't alter the /etc/services file at all...) I need to review some docs (and personal uses) of the cswinetd script to answer the other question... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Wed May 5 18:35:38 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 5 May 2010 17:35:38 +0100 Subject: [csw-maintainers] cswinetd and cswetcservices? In-Reply-To: <1273073623-sup-7955@pinkfloyd.chass.utoronto.ca> References: <4BE18DD7.5020004@cognigencorp.com> <1273073623-sup-7955@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 5 de Maio de 2010 16:37, Ben Walton escreveu: > /usr/xpg4/bin/grep -q "^$svcname[[:space:]].*$port_proto.*$PKGINST" /etc/services /usr/xpg4/bin/grep might not exist, depending on the initial package set when installing Solaris. From bwalton at opencsw.org Wed May 5 18:49:27 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 05 May 2010 12:49:27 -0400 Subject: [csw-maintainers] cswinetd and cswetcservices? In-Reply-To: References: <4BE18DD7.5020004@cognigencorp.com> <1273073623-sup-7955@pinkfloyd.chass.utoronto.ca> Message-ID: <1273078115-sup-9725@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Wed May 05 12:35:38 -0400 2010: > /usr/xpg4/bin/grep might not exist, depending on the initial package > set when installing Solaris. *mumble mumble* Is there a posix grep that is guaranteed to be available? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Wed May 5 19:42:31 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 5 May 2010 10:42:31 -0700 Subject: [csw-maintainers] cswinetd and cswetcservices? In-Reply-To: <1273078115-sup-9725@pinkfloyd.chass.utoronto.ca> References: <4BE18DD7.5020004@cognigencorp.com> <1273073623-sup-7955@pinkfloyd.chass.utoronto.ca> <1273078115-sup-9725@pinkfloyd.chass.utoronto.ca> Message-ID: On Wed, May 5, 2010 at 9:49 AM, Ben Walton wrote: > /usr/xpg4/bin/grep -q "^$svcname[[:space:]].*$port_proto.*$PKGINST" /etc/services > Excerpts from Maciej (Matchek) Blizinski's message of Wed May 05 12:35:38 -0400 2010: > >> /usr/xpg4/bin/grep might not exist, depending on the initial package >> set when installing Solaris. > > *mumble mumble* Is there a posix grep that is guaranteed to be > ?available? > dont think so. use awk or sed? Modifying the original, under the "skip the CSWxxx" principle you recently said: awk '$1=="'$svcname'" && $2=="'$port_proto'" {print "found"}' /etc/services should print out a value if found, or nothing, if not found. From bwalton at opencsw.org Wed May 5 19:49:33 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 05 May 2010 13:49:33 -0400 Subject: [csw-maintainers] cswinetd and cswetcservices? In-Reply-To: References: <4BE18DD7.5020004@cognigencorp.com> <1273073623-sup-7955@pinkfloyd.chass.utoronto.ca> <1273078115-sup-9725@pinkfloyd.chass.utoronto.ca> Message-ID: <1273081677-sup-3151@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Wed May 05 13:42:31 -0400 2010: > dont think so. use awk or sed? > Modifying the original, under the "skip the CSWxxx" principle you > recently said: > awk '$1=="'$svcname'" && $2=="'$port_proto'" {print "found"}' /etc/services > > should print out a value if found, or nothing, if not found. Ok, this works for me. I'll commit a fix tonight and ask Peter B to release an update. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From Darin.Perusich at cognigencorp.com Wed May 5 20:23:33 2010 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Wed, 05 May 2010 14:23:33 -0400 Subject: [csw-maintainers] cswinetd and cswetcservices? In-Reply-To: <1273073623-sup-7955@pinkfloyd.chass.utoronto.ca> References: <4BE18DD7.5020004@cognigencorp.com> <1273073623-sup-7955@pinkfloyd.chass.utoronto.ca> Message-ID: <4BE1B7A5.7060908@cognigencorp.com> Hi Ben, On 05/05/2010 11:37 AM, Ben Walton wrote: > > I need to review some docs (and personal uses) of the cswinetd script > to answer the other question... > Any luck locating/reviewing your docs to locate this? Thanks -- Darin Perusich Unix Systems Administrator Cognigen Corporation 395 Youngs Rd. Williamsville, NY 14221 Phone: 716-633-3463 Email: darinper at cognigencorp.com From bwalton at opencsw.org Wed May 5 20:47:13 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 05 May 2010 14:47:13 -0400 Subject: [csw-maintainers] cswinetd and cswetcservices? In-Reply-To: <4BE1B7A5.7060908@cognigencorp.com> References: <4BE18DD7.5020004@cognigencorp.com> <1273073623-sup-7955@pinkfloyd.chass.utoronto.ca> <4BE1B7A5.7060908@cognigencorp.com> Message-ID: <1273084843-sup-7395@pinkfloyd.chass.utoronto.ca> Excerpts from Darin Perusich's message of Wed May 05 14:23:33 -0400 2010: > Any luck locating/reviewing your docs to locate this? Sorry, got into other stuff. There is no facility for the maintainer to default this to off. It's administrator dependent. Both /etc/opt/csw/csw.conf and /opt/csw/etc/csw.conf are taken into account (sourced by the shell). The following is how initial state is determined: default is on state set to off if autoenable_daemons is set to no in csw.conf state is set to off if autoenable_$svcname is set to no state is set to on if autoenable_$svcname is set to yes So, the autoenable_daemons setting is trumped by autoenable_git (for example) when installing git. The only sensible solution I see to allow the maintainer to set the default is to honour the # as the first character in the inetd.conf definition. (I can try to look at this tonight.) Does this help? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Wed May 5 20:52:50 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 05 May 2010 14:52:50 -0400 Subject: [csw-maintainers] cswinetd and cswetcservices? In-Reply-To: References: <4BE18DD7.5020004@cognigencorp.com> <1273073623-sup-7955@pinkfloyd.chass.utoronto.ca> <1273078115-sup-9725@pinkfloyd.chass.utoronto.ca> Message-ID: <1273085523-sup-1218@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Wed May 05 13:42:31 -0400 2010: > dont think so. use awk or sed? > Modifying the original, under the "skip the CSWxxx" principle you > recently said: This will make its way into the cswinetd script too as I'm also using /usr/xpg4/bin/grep there too. :( Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Wed May 5 20:57:16 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 5 May 2010 11:57:16 -0700 Subject: [csw-maintainers] cswinetd and cswetcservices? In-Reply-To: <1273084843-sup-7395@pinkfloyd.chass.utoronto.ca> References: <4BE18DD7.5020004@cognigencorp.com> <1273073623-sup-7955@pinkfloyd.chass.utoronto.ca> <4BE1B7A5.7060908@cognigencorp.com> <1273084843-sup-7395@pinkfloyd.chass.utoronto.ca> Message-ID: On Wed, May 5, 2010 at 11:47 AM, Ben Walton wrote: > Excerpts from Darin Perusich's message of Wed May 05 14:23:33 -0400 2010: > >> Any luck locating/reviewing your docs to locate this? > > Sorry, got into other stuff. ?There is no facility for the maintainer > to default this to off. why would the *maintainer* want something to default to off ?? Normally I would think of this kind of behaviour from a complex demon. If its that complex of a demon, though, maybe it shouldnt be running out of inetd? :-} Or if its a smaller, "optional" part of some package, and the maintainer is presuming, "well, most people want the core stuff, but only a few will want the inetd demon"... in which case... I think best thing to do is to split off the "inetd demon" functionality into a separate package. Then, if the user installs the package, then sort of by definition, they WANT it running, in which case the maintainer has no business defaulting it to off ;-) From Darin.Perusich at cognigencorp.com Wed May 5 21:08:50 2010 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Wed, 05 May 2010 15:08:50 -0400 Subject: [csw-maintainers] cswinetd and cswetcservices? In-Reply-To: <1273084843-sup-7395@pinkfloyd.chass.utoronto.ca> References: <4BE18DD7.5020004@cognigencorp.com> <1273073623-sup-7955@pinkfloyd.chass.utoronto.ca> <4BE1B7A5.7060908@cognigencorp.com> <1273084843-sup-7395@pinkfloyd.chass.utoronto.ca> Message-ID: <4BE1C242.2060904@cognigencorp.com> On 05/05/2010 02:47 PM, Ben Walton wrote: > Excerpts from Darin Perusich's message of Wed May 05 14:23:33 -0400 2010: > >> Any luck locating/reviewing your docs to locate this? > > Sorry, got into other stuff. There is no facility for the maintainer > to default this to off. It's administrator dependent. Both > /etc/opt/csw/csw.conf and /opt/csw/etc/csw.conf are taken into account > (sourced by the shell). > > The following is how initial state is determined: > > default is on > state set to off if autoenable_daemons is set to no in csw.conf > state is set to off if autoenable_$svcname is set to no > state is set to on if autoenable_$svcname is set to yes > > So, the autoenable_daemons setting is trumped by autoenable_git (for > example) when installing git. So if I added the following to /etc/opt/csw/csw.conf and /opt/csw/etc/csw.conf, if they don't already exist of course, the services will be disabled by default. autoenable_amanda=no autoenable_amandaidx=no autoenable_amidxtape=no > The only sensible solution I see to allow the maintainer to set the > default is to honour the # as the first character in the inetd.conf > definition. (I can try to look at this tonight.) I initially set # as the first character in inetd.conf but the package install throws the following error. Installing class ... /opt/csw/etc/pkg/CSWamanda/inetd.conf Service '#amanda' not found in /etc/inet/services. Won't setup inetd for it. pkgadd: ERROR: class action script did not complete successfully [ verifying class ] > Does this help? > Thanks, this was helpful. -- Darin Perusich Unix Systems Administrator Cognigen Corporation 395 Youngs Rd. Williamsville, NY 14221 Phone: 716-633-3463 Email: darinper at cognigencorp.com From bwalton at opencsw.org Wed May 5 21:14:51 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 05 May 2010 15:14:51 -0400 Subject: [csw-maintainers] cswinetd and cswetcservices? In-Reply-To: <4BE1C242.2060904@cognigencorp.com> References: <4BE18DD7.5020004@cognigencorp.com> <1273073623-sup-7955@pinkfloyd.chass.utoronto.ca> <4BE1B7A5.7060908@cognigencorp.com> <1273084843-sup-7395@pinkfloyd.chass.utoronto.ca> <4BE1C242.2060904@cognigencorp.com> Message-ID: <1273086730-sup-9202@pinkfloyd.chass.utoronto.ca> Excerpts from Darin Perusich's message of Wed May 05 15:08:50 -0400 2010: > So if I added the following to /etc/opt/csw/csw.conf and > /opt/csw/etc/csw.conf, if they don't already exist of course, the > services will be disabled by default. > > autoenable_amanda=no > autoenable_amandaidx=no > autoenable_amidxtape=no Yes, this would keep them turned off. > I initially set # as the first character in inetd.conf but the package > install throws the following error. This wasn't something that was planned for. :) I'm inclined to agree with Phil's reasoning on this though. I'd recommend splitting out an amanda_daemon package that adds the daemon specific bits as required. There isn't much point in having amanada on a machine if you're not going to use it, right? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From Darin.Perusich at cognigencorp.com Wed May 5 21:35:52 2010 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Wed, 05 May 2010 15:35:52 -0400 Subject: [csw-maintainers] cswinetd and cswetcservices? In-Reply-To: <1273086730-sup-9202@pinkfloyd.chass.utoronto.ca> References: <4BE18DD7.5020004@cognigencorp.com> <1273073623-sup-7955@pinkfloyd.chass.utoronto.ca> <4BE1B7A5.7060908@cognigencorp.com> <1273084843-sup-7395@pinkfloyd.chass.utoronto.ca> <4BE1C242.2060904@cognigencorp.com> <1273086730-sup-9202@pinkfloyd.chass.utoronto.ca> Message-ID: <4BE1C898.6080306@cognigencorp.com> On 05/05/2010 03:14 PM, Ben Walton wrote: > Excerpts from Darin Perusich's message of Wed May 05 15:08:50 -0400 2010: > >> So if I added the following to /etc/opt/csw/csw.conf and >> /opt/csw/etc/csw.conf, if they don't already exist of course, the >> services will be disabled by default. >> >> autoenable_amanda=no >> autoenable_amandaidx=no >> autoenable_amidxtape=no > > Yes, this would keep them turned off. > >> I initially set # as the first character in inetd.conf but the package >> install throws the following error. > > This wasn't something that was planned for. :) I'm inclined to agree > with Phil's reasoning on this though. I'd recommend splitting out an > amanda_daemon package that adds the daemon specific bits as required. > There isn't much point in having amanada on a machine if you're not > going to use it, right? I'd rather not make the presumption that just because something been installed it should be started. My preference has alway been off by default and if the admin wants to use it they can enable it. -- 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 May 5 21:46:53 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 5 May 2010 21:46:53 +0200 Subject: [csw-maintainers] cswinetd and cswetcservices? In-Reply-To: <4BE1C898.6080306@cognigencorp.com> References: <4BE18DD7.5020004@cognigencorp.com> <1273073623-sup-7955@pinkfloyd.chass.utoronto.ca> <4BE1B7A5.7060908@cognigencorp.com> <1273084843-sup-7395@pinkfloyd.chass.utoronto.ca> <4BE1C242.2060904@cognigencorp.com> <1273086730-sup-9202@pinkfloyd.chass.utoronto.ca> <4BE1C898.6080306@cognigencorp.com> Message-ID: <20100505194652.GB27943@sebastiankayser.de> * Darin Perusich wrote: > On 05/05/2010 03:14 PM, Ben Walton wrote: > > Excerpts from Darin Perusich's message of Wed May 05 15:08:50 -0400 2010: > > > >> So if I added the following to /etc/opt/csw/csw.conf and > >> /opt/csw/etc/csw.conf, if they don't already exist of course, the > >> services will be disabled by default. > >> > >> autoenable_amanda=no > >> autoenable_amandaidx=no > >> autoenable_amidxtape=no > > > > Yes, this would keep them turned off. > > > >> I initially set # as the first character in inetd.conf but the package > >> install throws the following error. > > > > This wasn't something that was planned for. :) I'm inclined to agree > > with Phil's reasoning on this though. I'd recommend splitting out an > > amanda_daemon package that adds the daemon specific bits as required. > > There isn't much point in having amanada on a machine if you're not > > going to use it, right? > > I'd rather not make the presumption that just because something been > installed it should be started. My preference has alway been off by > default and if the admin wants to use it they can enable it. +1 Same here! Sebastian From phil at bolthole.com Wed May 5 22:32:48 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 5 May 2010 13:32:48 -0700 Subject: [csw-maintainers] cswinetd and cswetcservices? In-Reply-To: <4BE1C898.6080306@cognigencorp.com> References: <4BE18DD7.5020004@cognigencorp.com> <1273073623-sup-7955@pinkfloyd.chass.utoronto.ca> <4BE1B7A5.7060908@cognigencorp.com> <1273084843-sup-7395@pinkfloyd.chass.utoronto.ca> <4BE1C242.2060904@cognigencorp.com> <1273086730-sup-9202@pinkfloyd.chass.utoronto.ca> <4BE1C898.6080306@cognigencorp.com> Message-ID: On Wed, May 5, 2010 at 12:35 PM, Darin Perusich wrote: > > I'd rather not make the presumption that just because something been > installed it should be started. My preference has alway been off by > default and if the admin wants to use it they can enable it. > which is exactly why the autoenable_demons option in csw.conf was invented. If the admin doesnt want demons enabled, even after installing a package, then they will set it to "off". So, that concern is already handled. Shouldnt maintainers be in the business of allowing the admins to make decisions flexibly, rather than making decisions FOR them? To look at it another way; If you are not respecting the admin's choice of setting for autoenable_demons, then you are going AGAINST the admin's decision. That's not a good path to follow, is it? If they DO want the things enabled by default, you are unneccessarily making things more difficult for them. Just go with what's in the site-local csw.conf settings. Which you dont have to do anything yourself, to respect. Just let the class action script handle it, and interpret the site-admin's decision about it. That's what it's for. From bonivart at opencsw.org Thu May 6 18:01:08 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 6 May 2010 18:01:08 +0200 Subject: [csw-maintainers] Bug in i.cswusergroup (cswclassutils) Message-ID: I'm testing the new cswclassutils 1.35 package and it contains the updated usergroup creation script. I tried it and hit some bug in it: Installing class ... Group named already exists User named already exists /usr/sadm/install/scripts/i.cswusergroup: !: not found [ verifying class ] I haven't had time to look at it but it's myself, Ben and Sebastian who's made changes to it over time so one of us is guilty. :-) -- /peter From maciej at opencsw.org Thu May 6 18:08:56 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 6 May 2010 17:08:56 +0100 Subject: [csw-maintainers] Bug in i.cswusergroup (cswclassutils) In-Reply-To: References: Message-ID: No dia 6 de Maio de 2010 17:01, Peter Bonivart escreveu: > /usr/sadm/install/scripts/i.cswusergroup: !: not found I've seen it many times. $ /bin/sh -c "if ! false; then echo not false, means true; fi" /bin/sh: !: not found $ /bin/bash -c "if ! false; then echo not false, means true; fi" not false, means true Maciej From phil at bolthole.com Thu May 6 18:11:30 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 6 May 2010 09:11:30 -0700 Subject: [csw-maintainers] Bug in i.cswusergroup (cswclassutils) In-Reply-To: References: Message-ID: On 5/6/10, Peter Bonivart wrote: > I'm testing the new cswclassutils 1.35 package and it contains the > updated usergroup creation script. I tried it and hit some bug in it: > > Installing class ... > Group named already exists > User named already exists > /usr/sadm/install/scripts/i.cswusergroup: !: not found > side note: i havent look at this, but this sort of thing is usually because someone used "!" in a test case, where it works on BASH, but not /bin/sh. Guess which one class action scripts gets invoked by? (reason #427 to be more familiar with *shell* coding, than "bash" coding) From skayser at opencsw.org Thu May 6 19:03:02 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 06 May 2010 19:03:02 +0200 Subject: [csw-maintainers] Bug in i.cswusergroup (cswclassutils) In-Reply-To: References: Message-ID: <4BE2F646.1030400@opencsw.org> Peter Bonivart wrote on 06.05.2010 18:01: > I'm testing the new cswclassutils 1.35 package and it contains the > updated usergroup creation script. I tried it and hit some bug in it: > > Installing class ... > Group named already exists > User named already exists > /usr/sadm/install/scripts/i.cswusergroup: !: not found > > [ verifying class ] > > I haven't had time to look at it but it's myself, Ben and Sebastian > who's made changes to it over time so one of us is guilty. :-) I plead guilty. Fix commited in r9825. Could you please try again? Sebastian From Darin.Perusich at cognigencorp.com Thu May 6 22:46:56 2010 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Thu, 06 May 2010 16:46:56 -0400 Subject: [csw-maintainers] more gar? Message-ID: <4BE32AC0.30503@cognigencorp.com> I'm trying to put a few of my packages in GAR and I'm unsure two do the following.... How do you define dependencies in GAR? How do you specify pre/post install/remove scripts? How you renamed file.conf to file.conf.CSW? I'm sure more questions will follow. Thanks -- Darin Perusich Unix Systems Administrator Cognigen Corporation 395 Youngs Rd. Williamsville, NY 14221 Phone: 716-633-3463 Email: darinper at cognigencorp.com From bonivart at opencsw.org Fri May 7 00:04:40 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 7 May 2010 00:04:40 +0200 Subject: [csw-maintainers] more gar? In-Reply-To: <4BE32AC0.30503@cognigencorp.com> References: <4BE32AC0.30503@cognigencorp.com> Message-ID: On Thu, May 6, 2010 at 10:46 PM, Darin Perusich wrote: > How do you define dependencies in GAR? With RUNTIME_DEP_PKGS. See http://sourceforge.net/apps/trac/gar/wiki/GAR%20Variable%20Reference. > How do you specify pre/post install/remove scripts? With a line like this: DISTFILES += $(call admfiles,CSWpkgutil,prototype preremove postinstall) You provide the scripts in for example files/CSWpkgutil.preremove. See http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/pkgutil/trunk/. The above example defines a static prototype as well as preremove and postinstall, you should normally always use a dynamic prototype. > How you renamed file.conf to ?file.conf.CSW? You can write your own install scripts directly in the Makefile, easiest would be to look at other Makefiles, here's one: http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/bind/trunk/Makefile?revision=9472&view=markup -- /peter From dam at opencsw.org Fri May 7 09:58:53 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 7 May 2010 09:58:53 +0200 Subject: [csw-maintainers] more gar? In-Reply-To: References: <4BE32AC0.30503@cognigencorp.com> Message-ID: <9575805B-05CA-4292-8285-E684211E73CA@opencsw.org> Hi, Am 07.05.2010 um 00:04 schrieb Peter Bonivart: > On Thu, May 6, 2010 at 10:46 PM, Darin Perusich > wrote: >> How do you define dependencies in GAR? > > With RUNTIME_DEP_PKGS. See > http://sourceforge.net/apps/trac/gar/wiki/GAR%20Variable%20Reference. > >> How do you specify pre/post install/remove scripts? > > With a line like this: > > DISTFILES += $(call admfiles,CSWpkgutil,prototype preremove > postinstall) The admfiles-routine also adds CSWpkgutil.gspec, which sets package name etc. I would recommend just adding the files you need directly without the call, e.g. DISTFILES = CSWpkgutil.postinstall CSWpkgutil.preremove etc. (for Darin, Peter: you have probably a special case here) > You provide the scripts in for example files/CSWpkgutil.preremove. See > http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/pkgutil/trunk/. > The above example defines a static prototype as well as preremove and > postinstall, you should normally always use a dynamic prototype. > >> How you renamed file.conf to file.conf.CSW? > > You can write your own install scripts directly in the Makefile, > easiest would be to look at other Makefiles, here's one: > > http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/bind/trunk/Makefile?revision=9472&view=markup Or even easier you just say PRESERVECONF = /etc/opt/csw/myapp.conf GAR is smart enough to automatically append .CSW, set the class, add the cswclassutils dependency etc. This is documented here: Best regards -- Dago From Darin.Perusich at cognigencorp.com Fri May 7 17:24:11 2010 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Fri, 07 May 2010 11:24:11 -0400 Subject: [csw-maintainers] more gar? In-Reply-To: <9575805B-05CA-4292-8285-E684211E73CA@opencsw.org> References: <4BE32AC0.30503@cognigencorp.com> <9575805B-05CA-4292-8285-E684211E73CA@opencsw.org> Message-ID: <4BE4309B.9040306@cognigencorp.com> Thanks Peter and Dago! On 05/07/2010 03:58 AM, Dagobert Michelsen wrote: > Hi, > > Am 07.05.2010 um 00:04 schrieb Peter Bonivart: >> On Thu, May 6, 2010 at 10:46 PM, Darin Perusich >> wrote: >>> How do you define dependencies in GAR? >> >> With RUNTIME_DEP_PKGS. See >> http://sourceforge.net/apps/trac/gar/wiki/GAR%20Variable%20Reference. >> >>> How do you specify pre/post install/remove scripts? >> >> With a line like this: >> >> DISTFILES += $(call admfiles,CSWpkgutil,prototype preremove postinstall) > > The admfiles-routine also adds CSWpkgutil.gspec, which sets package name > etc. > I would recommend just adding the files you need directly without the > call, e.g. > DISTFILES = CSWpkgutil.postinstall CSWpkgutil.preremove etc. > (for Darin, Peter: you have probably a special case here) > >> You provide the scripts in for example files/CSWpkgutil.preremove. See >> http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/pkgutil/trunk/. >> The above example defines a static prototype as well as preremove and >> postinstall, you should normally always use a dynamic prototype. >> >>> How you renamed file.conf to file.conf.CSW? >> >> You can write your own install scripts directly in the Makefile, >> easiest would be to look at other Makefiles, here's one: >> >> http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/bind/trunk/Makefile?revision=9472&view=markup >> > > Or even easier you just say > PRESERVECONF = /etc/opt/csw/myapp.conf > GAR is smart enough to automatically append .CSW, set the class, add the > cswclassutils dependency etc. This is documented here: > > > > 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 Darin.Perusich at cognigencorp.com Fri May 7 18:34:23 2010 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Fri, 07 May 2010 12:34:23 -0400 Subject: [csw-maintainers] initial commit to gar Message-ID: <4BE4410F.2090204@cognigencorp.com> Ok, so I believe I'm ready to make my initial commit to gar but I'm not sure exactly which files need to be committed. Certainly the Makefile needs to but what about the checksums? From looking at other packages this seems to be the practice but anything other then those two? -- Darin Perusich Unix Systems Administrator Cognigen Corporation 395 Youngs Rd. Williamsville, NY 14221 Phone: 716-633-3463 Email: darinper at cognigencorp.com From Darin.Perusich at cognigencorp.com Fri May 7 19:14:23 2010 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Fri, 07 May 2010 13:14:23 -0400 Subject: [csw-maintainers] initial commit to gar In-Reply-To: <4BE4410F.2090204@cognigencorp.com> References: <4BE4410F.2090204@cognigencorp.com> Message-ID: <4BE44A6F.8060702@cognigencorp.com> Is there a special username/password that needs to be used to commit? It's doesn't like my sourceforge account. On 05/07/2010 12:34 PM, Darin Perusich wrote: > Ok, so I believe I'm ready to make my initial commit to gar but I'm not > sure exactly which files need to be committed. Certainly the Makefile > needs to but what about the checksums? From looking at other packages > this seems to be the practice but anything other then those two? > -- Darin Perusich Unix Systems Administrator Cognigen Corporation 395 Youngs Rd. Williamsville, NY 14221 Phone: 716-633-3463 Email: darinper at cognigencorp.com From bwalton at opencsw.org Fri May 7 19:17:27 2010 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 07 May 2010 13:17:27 -0400 Subject: [csw-maintainers] initial commit to gar In-Reply-To: <4BE4410F.2090204@cognigencorp.com> References: <4BE4410F.2090204@cognigencorp.com> Message-ID: <4BE44B27.6070302@opencsw.org> On 10-05-07 12:34 PM, Darin Perusich wrote: > Ok, so I believe I'm ready to make my initial commit to gar but I'm not > sure exactly which files need to be committed. Certainly the Makefile > needs to but what about the checksums? From looking at other packages > this seems to be the practice but anything other then those two? > > Makefile, checksums, anything in files/ (which would typically be patches, adm scripts, etc). HTH. -Ben From dam at opencsw.org Fri May 7 20:22:41 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 7 May 2010 20:22:41 +0200 Subject: [csw-maintainers] initial commit to gar In-Reply-To: <4BE44A6F.8060702@cognigencorp.com> References: <4BE4410F.2090204@cognigencorp.com> <4BE44A6F.8060702@cognigencorp.com> Message-ID: <49A64B94-0EDA-4D84-8103-1A466C24A10B@opencsw.org> Hi Darin, Am 07.05.2010 um 19:14 schrieb Darin Perusich: > Is there a special username/password that needs to be used to commit? > It's doesn't like my sourceforge account. You must tell me your SF username so I can add you to the list of committers. Best regards -- Dago From Darin.Perusich at cognigencorp.com Fri May 7 20:27:39 2010 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Fri, 07 May 2010 14:27:39 -0400 Subject: [csw-maintainers] initial commit to gar In-Reply-To: <49A64B94-0EDA-4D84-8103-1A466C24A10B@opencsw.org> References: <4BE4410F.2090204@cognigencorp.com> <4BE44A6F.8060702@cognigencorp.com> <49A64B94-0EDA-4D84-8103-1A466C24A10B@opencsw.org> Message-ID: <4BE45B9B.7010700@cognigencorp.com> On 05/07/2010 02:22 PM, Dagobert Michelsen wrote: > Hi Darin, > > Am 07.05.2010 um 19:14 schrieb Darin Perusich: >> Is there a special username/password that needs to be used to commit? >> It's doesn't like my sourceforge account. > > You must tell me your SF username so I can add you to the list of > committers. > darinper -- Darin Perusich Unix Systems Administrator Cognigen Corporation 395 Youngs Rd. Williamsville, NY 14221 Phone: 716-633-3463 Email: darinper at cognigencorp.com From dam at opencsw.org Fri May 7 20:35:17 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 7 May 2010 20:35:17 +0200 Subject: [csw-maintainers] initial commit to gar In-Reply-To: <4BE45B9B.7010700@cognigencorp.com> References: <4BE4410F.2090204@cognigencorp.com> <4BE44A6F.8060702@cognigencorp.com> <49A64B94-0EDA-4D84-8103-1A466C24A10B@opencsw.org> <4BE45B9B.7010700@cognigencorp.com> Message-ID: <45247A99-90F5-4F0D-8BAA-2C933D41739E@opencsw.org> Hi Darin, Am 07.05.2010 um 20:27 schrieb Darin Perusich: > On 05/07/2010 02:22 PM, Dagobert Michelsen wrote: >> Hi Darin, >> >> Am 07.05.2010 um 19:14 schrieb Darin Perusich: >>> Is there a special username/password that needs to be used to commit? >>> It's doesn't like my sourceforge account. >> >> You must tell me your SF username so I can add you to the list of >> committers. > > darinper Ok, you should be able to commit now. Best regards -- Dago From Darin.Perusich at cognigencorp.com Fri May 7 21:42:49 2010 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Fri, 07 May 2010 15:42:49 -0400 Subject: [csw-maintainers] initial commit to gar In-Reply-To: <45247A99-90F5-4F0D-8BAA-2C933D41739E@opencsw.org> References: <4BE4410F.2090204@cognigencorp.com> <4BE44A6F.8060702@cognigencorp.com> <49A64B94-0EDA-4D84-8103-1A466C24A10B@opencsw.org> <4BE45B9B.7010700@cognigencorp.com> <45247A99-90F5-4F0D-8BAA-2C933D41739E@opencsw.org> Message-ID: <4BE46D39.306@cognigencorp.com> On 05/07/2010 02:35 PM, Dagobert Michelsen wrote: > > Ok, you should be able to commit now. > Thanks Dago, I'm all set. -- 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 Sun May 9 10:05:48 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 9 May 2010 10:05:48 +0200 Subject: [csw-maintainers] Fwd: java error, core dumped, when building subversion-1.6.11 In-Reply-To: <20100508103943.GB30529@noel.stsp.name> References: <5270541f-195e-42ba-8d98-cac4f5791a26@d19g2000yqf.googlegroups.com> <20100508103943.GB30529@noel.stsp.name> Message-ID: fyi. ---------- Forwarded message ---------- From: Stefan Sperling Date: Sat, May 8, 2010 at 12:39 Subject: Re: java error, core dumped, when building subversion-1.6.11 To: "rupert.thurner" Cc: dev at subversion.apache.org On Fri, May 07, 2010 at 10:57:05PM -0700, rupert.thurner wrote: > hi, > > when i try to build subversion-1.6.11 on solaris 9 the below error > occurs. how could one track that down? > /usr/jdk1.6.0_07/bin/javah -force -d subversion/bindings/javahl/ > include -classpath subversion/bindings/javahl/classes: > gmake[3]: *** [subversion/bindings/javahl/include/ > org_tigris_subversion_javahl_PropertyData.h] Illegal Instruction (core > dumped) My guess is that your java or GNU make binary is not 100% compatible with your processor architecture. I've seen such errors with a self-compiled FreeBSD system, optimized for Athlon XP at compile time, after moving the hard drive into an old dual-Celeron box (this was before dual-core CPUs were available) because the Athlon's mainboard had decided to die. The result was that most programs worked fine, but anything trying to use stuff like advanced floating point instructions was failing with illegal instruction errors. Back then I was lucky enough to be able to re-compile the system in place, this time without optimisations (and I have given up on playing with CFLAGS ever since). So I'd double check with the source of your java / gnu make binaries to make sure they are compatible with your OS and processor. Stefan From dam at opencsw.org Thu May 6 18:14:36 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 6 May 2010 18:14:36 +0200 Subject: [csw-maintainers] [buildfarm-announce] Network outage on the OpenCSW buildfarm Message-ID: <91097094-43A8-444D-BDA9-C04677352380@opencsw.org> Hi, FYI: we had a small network outage on the OpenCSW buildfarm due to network restructuring. Please expect some small outages to continue during the next week as we clean up some cabling. Sorry for the inconvenience -- Dago _______________________________________________ buildfarm-announce mailing list buildfarm-announce at opencsw.org https://lists.opencsw.org/mailman/listinfo/buildfarm-announce From bwalton at artsci.utoronto.ca Fri May 7 04:11:56 2010 From: bwalton at artsci.utoronto.ca (Ben Walton) Date: Thu, 06 May 2010 22:11:56 -0400 Subject: [csw-maintainers] cswinetd and cswetcservices? In-Reply-To: <4BE1B7A5.7060908@cognigencorp.com> References: <4BE18DD7.5020004@cognigencorp.com> <1273073623-sup-7955@pinkfloyd.chass.utoronto.ca> <4BE1B7A5.7060908@cognigencorp.com> Message-ID: <4BE376EC.2010208@artsci.utoronto.ca> On 10-05-05 02:23 PM, Darin Perusich wrote: Hi Darin, > Any luck locating/reviewing your docs to locate this? I've placed an updated cswclassutils in my experimental catalog. Would you mind testing it with your amanda packages? It addresses the issue you encountered with previously existing entries in /etc/services that didn't have a # CSWfoo suffix on the line. I also converted both cswinetd and cswetcservices to use awk for detection of existing lines instead of xpg4/bin/grep. If you find this satisfactory (defaulting services off being a separate issue), let me know. I'll then ask Peter B to release it officially. Thanks -Ben From dam at opencsw.org Mon May 10 15:56:43 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 10 May 2010 15:56:43 +0200 Subject: [csw-maintainers] Fwd: java error, core dumped, when building subversion-1.6.11 In-Reply-To: References: <5270541f-195e-42ba-8d98-cac4f5791a26@d19g2000yqf.googlegroups.com> <20100508103943.GB30529@noel.stsp.name> Message-ID: <94A5AE3C-B20E-41D8-A444-BD5B49D6CCAD@opencsw.org> Hi Rupert, Am 09.05.2010 um 10:05 schrieb rupert THURNER: > fyi. > > > ---------- Forwarded message ---------- > From: Stefan Sperling > Date: Sat, May 8, 2010 at 12:39 > Subject: Re: java error, core dumped, when building subversion-1.6.11 > To: "rupert.thurner" > Cc: dev at subversion.apache.org > > On Fri, May 07, 2010 at 10:57:05PM -0700, rupert.thurner wrote: >> hi, >> >> when i try to build subversion-1.6.11 on solaris 9 the below error >> occurs. how could one track that down? > >> /usr/jdk1.6.0_07/bin/javah -force -d subversion/bindings/javahl/ >> include -classpath subversion/bindings/javahl/classes: > >> gmake[3]: *** [subversion/bindings/javahl/include/ >> org_tigris_subversion_javahl_PropertyData.h] Illegal Instruction >> (core >> dumped) > > My guess is that your java or GNU make binary is not 100% compatible > with > your processor architecture. I am pretty sure that this is not the case - the jdk is the official binary from Sun, and the T2 CPU is fully supported. > I've seen such errors with a self-compiled FreeBSD system, optimized > for > Athlon XP at compile time, after moving the hard drive into an old > dual-Celeron box (this was before dual-core CPUs were available) > because > the Athlon's mainboard had decided to die. > > The result was that most programs worked fine, but anything trying to > use stuff like advanced floating point instructions was failing with > illegal instruction errors. Back then I was lucky enough to be able to > re-compile the system in place, this time without optimisations (and I > have given up on playing with CFLAGS ever since). > > So I'd double check with the source of your java / gnu make binaries > to make sure they are compatible with your OS and processor. Is the corefile really from gnumake? Best regards -- Dago From Darin.Perusich at cognigencorp.com Mon May 10 16:58:35 2010 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Mon, 10 May 2010 10:58:35 -0400 Subject: [csw-maintainers] gar and autoconf Message-ID: <4BE81F1B.8050400@cognigencorp.com> Hello, Before running configure I need to make a quick edit to configure.ac and run autoconf, how do I call autoconf from gar? The edit is a simple removal of a header, gsed -i -e 's%sys/acl.h%%' configure.ac. How would I execute this? Thanks! -- Darin Perusich Unix Systems Administrator Cognigen Corporation 395 Youngs Rd. Williamsville, NY 14221 Phone: 716-633-3463 Email: darinper at cognigencorp.com From bwalton at opencsw.org Mon May 10 17:17:12 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 10 May 2010 11:17:12 -0400 Subject: [csw-maintainers] gar and autoconf In-Reply-To: <4BE81F1B.8050400@cognigencorp.com> References: <4BE81F1B.8050400@cognigencorp.com> Message-ID: <4BE82378.3010006@opencsw.org> On 10-05-10 10:58 AM, Darin Perusich wrote: > Hello, > > Before running configure I need to make a quick edit to configure.ac and > run autoconf, how do I call autoconf from gar? The edit is a simple > removal of a header, gsed -i -e 's%sys/acl.h%%' configure.ac. How would > I execute this? Use something like: pre-configure-modulated: @( cd $(WORKSRC); gsed -i -e 's%sys/acl.h%%' configure.ac; \ autoreconf ...) @$(MAKECOOKIE) That will run for each modulation (likely only one in your case, but safe against multiple) and do the required edit. As the name suggests, this is pretty much immediately prior the configure call. You could also create a patch that gets applied instead. HTH -Ben From Darin.Perusich at cognigencorp.com Mon May 10 18:09:46 2010 From: Darin.Perusich at cognigencorp.com (Darin Perusich) Date: Mon, 10 May 2010 12:09:46 -0400 Subject: [csw-maintainers] gar and autoconf In-Reply-To: <4BE82378.3010006@opencsw.org> References: <4BE81F1B.8050400@cognigencorp.com> <4BE82378.3010006@opencsw.org> Message-ID: <4BE82FCA.8050104@cognigencorp.com> Thanks Ben, this is exactly what I was looking for. On 05/10/2010 11:17 AM, Ben Walton wrote: > On 10-05-10 10:58 AM, Darin Perusich wrote: >> Hello, >> >> Before running configure I need to make a quick edit to configure.ac and >> run autoconf, how do I call autoconf from gar? The edit is a simple >> removal of a header, gsed -i -e 's%sys/acl.h%%' configure.ac. How would >> I execute this? > > Use something like: > > pre-configure-modulated: > @( cd $(WORKSRC); gsed -i -e 's%sys/acl.h%%' configure.ac; \ > autoreconf ...) > @$(MAKECOOKIE) > > That will run for each modulation (likely only one in your case, but > safe against multiple) and do the required edit. As the name suggests, > this is pretty much immediately prior the configure call. You could > also create a patch that gets applied instead. > -- 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 Mon May 10 20:22:47 2010 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 10 May 2010 20:22:47 +0200 Subject: [csw-maintainers] Fwd: java error, core dumped, when building subversion-1.6.11 In-Reply-To: <94A5AE3C-B20E-41D8-A444-BD5B49D6CCAD@opencsw.org> References: <5270541f-195e-42ba-8d98-cac4f5791a26@d19g2000yqf.googlegroups.com> <20100508103943.GB30529@noel.stsp.name> <94A5AE3C-B20E-41D8-A444-BD5B49D6CCAD@opencsw.org> Message-ID: On Mon, May 10, 2010 at 15:56, Dagobert Michelsen wrote: > Hi Rupert, > > Am 09.05.2010 um 10:05 schrieb rupert THURNER: > > fyi. >> >> >> ---------- Forwarded message ---------- >> From: Stefan Sperling >> Date: Sat, May 8, 2010 at 12:39 >> Subject: Re: java error, core dumped, when building subversion-1.6.11 >> To: "rupert.thurner" >> Cc: dev at subversion.apache.org >> >> On Fri, May 07, 2010 at 10:57:05PM -0700, rupert.thurner wrote: >> >>> hi, >>> >>> when i try to build subversion-1.6.11 on solaris 9 the below error >>> occurs. how could one track that down? >>> >> >> /usr/jdk1.6.0_07/bin/javah -force -d subversion/bindings/javahl/ >>> include -classpath subversion/bindings/javahl/classes: >>> >> >> gmake[3]: *** [subversion/bindings/javahl/include/ >>> org_tigris_subversion_javahl_PropertyData.h] Illegal Instruction (core >>> dumped) >>> >> >> My guess is that your java or GNU make binary is not 100% compatible with >> your processor architecture. >> > > I am pretty sure that this is not the case - the jdk is the official > binary from Sun, and the T2 CPU is fully supported. > > > I've seen such errors with a self-compiled FreeBSD system, optimized for >> Athlon XP at compile time, after moving the hard drive into an old >> dual-Celeron box (this was before dual-core CPUs were available) because >> the Athlon's mainboard had decided to die. >> >> The result was that most programs worked fine, but anything trying to >> use stuff like advanced floating point instructions was failing with >> illegal instruction errors. Back then I was lucky enough to be able to >> re-compile the system in place, this time without optimisations (and I >> have given up on playing with CFLAGS ever since). >> >> So I'd double check with the source of your java / gnu make binaries >> to make sure they are compatible with your OS and processor. >> > > Is the corefile really from gnumake? > > > i do not know. a much simpler testcase producing the same result might be compiling berkely db 5.0. there only configure and a simple java test is involved until the core. out of ~/mgar/pkg/bdb50/trunk/work/solaris9-sparc/build-isa-sparcv8/db-5.0.21/build_unix/config.log ... configure:17407: javac Test.java configure:17410: $? = 0 ... configure:17420: java Test ../dist/configure: line 1: 27179 Illegal Instruction (core dumped) $JAVA $JAVAFLAGS $TEST rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at bolthole.com Mon May 10 20:42:33 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 10 May 2010 11:42:33 -0700 Subject: [csw-maintainers] Fwd: java error, core dumped, when building subversion-1.6.11 In-Reply-To: References: <5270541f-195e-42ba-8d98-cac4f5791a26@d19g2000yqf.googlegroups.com> <20100508103943.GB30529@noel.stsp.name> <94A5AE3C-B20E-41D8-A444-BD5B49D6CCAD@opencsw.org> Message-ID: On Mon, May 10, 2010 at 11:22 AM, rupert THURNER wrote: > On Mon, May 10, 2010 at 15:56, Dagobert Michelsen wrote: >> >> Is the corefile really from gnumake? >> >> > i do not know. what does "file core" say? From phil at bolthole.com Mon May 10 21:59:49 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 10 May 2010 12:59:49 -0700 Subject: [csw-maintainers] really need feedback on "alternatives" package Message-ID: Sooo... i havent received any feedback on the new implementation of "alternatives". (in testing, atm) I hesitate to put something as crucial as this out there, without anyone but myself looking at it. I doubt I've caught all the bugs in it. From dam at opencsw.org Mon May 10 22:28:31 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 10 May 2010 22:28:31 +0200 Subject: [csw-maintainers] Fwd: java error, core dumped, when building subversion-1.6.11 In-Reply-To: References: <5270541f-195e-42ba-8d98-cac4f5791a26@d19g2000yqf.googlegroups.com> <20100508103943.GB30529@noel.stsp.name> Message-ID: <23383113-F2BA-40B8-8492-B31129C950BB@opencsw.org> Hi Rupert, Am 09.05.2010 um 10:05 schrieb rupert THURNER: > On Fri, May 07, 2010 at 10:57:05PM -0700, rupert.thurner wrote: >> when i try to build subversion-1.6.11 on solaris 9 the below error >> occurs. how could one track that down? > >> /usr/jdk1.6.0_07/bin/javah -force -d subversion/bindings/javahl/ >> include -classpath subversion/bindings/javahl/classes: > >> gmake[3]: *** [subversion/bindings/javahl/include/ >> org_tigris_subversion_javahl_PropertyData.h] Illegal Instruction >> (core >> dumped) > > My guess is that your java or GNU make binary is not 100% compatible > with > your processor architecture. I just figured that even "java -version" bails out on some minor releases. After updating everything to 6u20 it looks pretty good now. Please verify. Best regards -- Dago From dam at baltic-online.de Tue May 11 14:32:24 2010 From: dam at baltic-online.de (Dagobert Michelsen) Date: Tue, 11 May 2010 12:32:24 -0000 Subject: [csw-maintainers] [buildfarm-announce] Changes on login.opencsw.org Message-ID: Hi, first welcome to the OpenCSW buildfarm list! You have been automatically subscribed as you are a user of the OpenCSW buildfarm. This will be a low-volume list to announce changes, updates and downtimes at the OpenCSW buildfarm. The access via Sun Secure Global Desktop (X11 over Web) has been changed to another hostname/ip and ssh access has been enhanced to run also on port 443 to allow direct access via proxy tunneling. There is now the following configuration: login.opencsw.org Port 22 SSH login.opencsw.org Port 443 SSH sgd.opencsw.org Port 80 HTTP for SGD sgd.opencsw.org Port 443 HTTPS for SGD Access to SGD is not enabled by default. If you want to use it please contact buildfarm at opencsw.org Best regards -- Dago _______________________________________________ buildfarm-announce mailing list buildfarm-announce at opencsw.org https://lists.opencsw.org/mailman/listinfo/buildfarm-announce From hson at opencsw.org Wed May 12 11:16:06 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Wed, 12 May 2010 11:16:06 +0200 Subject: [csw-maintainers] [svn] GD upstream update notification In-Reply-To: <201005010252.o412qUld010983@mirror.opencsw.org> References: <201005010252.o412qUld010983@mirror.opencsw.org> Message-ID: <4BEA71D6.8020500@opencsw.org> On 2010-05-01 04:52, Upstream Package Watch wrote: > Hello dear GD maintainer, > > The upstream notification job has detected the availability of new files for GD. > > The following upstream file(s): > GD-2.45.tar.gz > > is/are available at the following url(s): > http://search.cpan.org/CPAN/authors/id/L/LD/LDS/ ftp://ftp.nrc.ca/pub/CPAN/authors/id/L/LD/LDS/ ftp://ftp.nas.nasa.gov/pub/perl/CPAN/authors/id/L/LD/LDS/ http://mirrors.ibiblio.org/pub/mirrors/CPAN/authors/id/L/LD/LDS/ ftp://cpan.pair.com/pub/CPAN/authors/id/L/LD/LDS/ http://mirrors.kernel.org/cpan/authors/id/L/LD/LDS/ > Seems that the upstream watch isn't working properly. I am the maintainer for the package CSWgd/gd which is libgd, but this upstream notice is for the perl binding module for gd which I'm not the maintainer... From dam at opencsw.org Wed May 12 11:24:47 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 12 May 2010 11:24:47 +0200 Subject: [csw-maintainers] [svn] GD upstream update notification In-Reply-To: <4BEA71D6.8020500@opencsw.org> References: <201005010252.o412qUld010983@mirror.opencsw.org> <4BEA71D6.8020500@opencsw.org> Message-ID: Hi Roger, Am 12.05.2010 um 11:16 schrieb Roger H?kansson: > On 2010-05-01 04:52, Upstream Package Watch wrote: >> Hello dear GD maintainer, >> >> The upstream notification job has detected the availability of new >> files for GD. >> >> The following upstream file(s): >> GD-2.45.tar.gz >> >> is/are available at the following url(s): >> http://search.cpan.org/CPAN/authors/id/L/LD/LDS/ ftp://ftp.nrc.ca/pub/CPAN/authors/id/L/LD/LDS/ >> ftp://ftp.nas.nasa.gov/pub/perl/CPAN/authors/id/L/LD/LDS/ http://mirrors.ibiblio.org/pub/mirrors/CPAN/authors/id/L/LD/LDS/ >> ftp://cpan.pair.com/pub/CPAN/authors/id/L/LD/LDS/ http://mirrors.kernel.org/cpan/authors/id/L/LD/LDS/ > > Seems that the upstream watch isn't working properly. > I am the maintainer for the package CSWgd/gd which is libgd, but > this upstream notice is for the perl binding module for gd which I'm > not the maintainer... I think it looks for the GARNAME. William filed a bug for a package of mine some time ago to change the GARNAME, but I think it should better take out the catalog name and then look that up in the database. Best regards -- Dago From hson at opencsw.org Wed May 12 11:28:12 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Wed, 12 May 2010 11:28:12 +0200 Subject: [csw-maintainers] [svn] GD upstream update notification In-Reply-To: References: <201005010252.o412qUld010983@mirror.opencsw.org> <4BEA71D6.8020500@opencsw.org> Message-ID: <4BEA74AC.10104@opencsw.org> On 2010-05-12 11:24, Dagobert Michelsen wrote: >> Seems that the upstream watch isn't working properly. >> I am the maintainer for the package CSWgd/gd which is libgd, but this >> upstream notice is for the perl binding module for gd which I'm not >> the maintainer... > > I think it looks for the GARNAME. William filed a bug for a package of > mine some time ago to change the GARNAME, but I think it should better > take out the catalog name and then look that up in the database. > Ahh, and when it comes to CPAN-modules, there might be more than one that matches another GARNAME... From dam at baltic-online.de Wed May 12 11:55:49 2010 From: dam at baltic-online.de (Dagobert Michelsen) Date: Wed, 12 May 2010 11:55:49 +0200 Subject: [csw-maintainers] libev and libevent Message-ID: <54DDD943-FE7E-418F-8FB9-FDC5C91B88FC@baltic-online.de> Hi, because of the collision of event.h from libev and libevent I am deinstalling CSWlibev for now as tmux which I am building right now does not work with the event.h from libev. I have not looked into the proposed solution from http://www.opencsw.org/mantis/view.php?id=4376 but may do so soon :) Best regards -- Dago From dam at opencsw.org Wed May 12 13:39:03 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 12 May 2010 13:39:03 +0200 Subject: [csw-maintainers] libev and libevent References: <54DDD943-FE7E-418F-8FB9-FDC5C91B88FC@baltic-online.de> Message-ID: <7EE3CF2E-4D6C-41B6-AD4B-6F9228F0E358@opencsw.org> Hi, because of the collision of event.h from libev and libevent I am deinstalling CSWlibev for now as tmux which I am building right now does not work with the event.h from libev. I have not looked into the proposed solution from http://www.opencsw.org/mantis/view.php?id=4376 but may do so soon :) Best regards -- Dago From rupert at opencsw.org Thu May 13 12:31:42 2010 From: rupert at opencsw.org (rupert THURNER) Date: Thu, 13 May 2010 12:31:42 +0200 Subject: [csw-maintainers] subversion-1.6.11 - what does -xnorunpath ? Message-ID: hi, the subversion-1.6.11 compile does at some point a "-xnorunpath " and then fails with gcc: language norunpath not recognized and then: gcc: subversion/bindings/swig/ruby/libsvn_swig_ruby/swigutil_rb.c: linker input file unused because linking not done see here for details: http://opencsw.pastebin.com/cX55Wzu9 any hints would be appreciated. rupert. From maciej at opencsw.org Thu May 13 12:37:23 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 13 May 2010 11:37:23 +0100 Subject: [csw-maintainers] subversion-1.6.11 - what does -xnorunpath ? In-Reply-To: References: Message-ID: No dia 13 de Maio de 2010 11:31, rupert THURNER escreveu: > hi, > > the subversion-1.6.11 compile does at some point a "-xnorunpath " and > then fails with > ? gcc: language norunpath not recognized It's a Sun Studio flag, which prevents it from embedding it's private RUNPATH entries in the binaries. GCC doesn't have this option. Did you search GAR code for it? Maciej From rupert at opencsw.org Thu May 13 12:51:14 2010 From: rupert at opencsw.org (rupert THURNER) Date: Thu, 13 May 2010 12:51:14 +0200 Subject: [csw-maintainers] Fwd: java error, core dumped, when building subversion-1.6.11 In-Reply-To: <23383113-F2BA-40B8-8492-B31129C950BB@opencsw.org> References: <5270541f-195e-42ba-8d98-cac4f5791a26@d19g2000yqf.googlegroups.com> <20100508103943.GB30529@noel.stsp.name> <23383113-F2BA-40B8-8492-B31129C950BB@opencsw.org> Message-ID: On Mon, May 10, 2010 at 22:28, Dagobert Michelsen wrote: > Hi Rupert, > > Am 09.05.2010 um 10:05 schrieb rupert THURNER: >> >> On Fri, May 07, 2010 at 10:57:05PM -0700, rupert.thurner wrote: >>> >>> when i try to build subversion-1.6.11 on solaris 9 the below error >>> occurs. how could one track that down? >> >>> /usr/jdk1.6.0_07/bin/javah -force -d subversion/bindings/javahl/ >>> include -classpath subversion/bindings/javahl/classes: >> >>> gmake[3]: *** [subversion/bindings/javahl/include/ >>> org_tigris_subversion_javahl_PropertyData.h] Illegal Instruction (core >>> dumped) >> >> My guess is that your java or GNU make binary is not 100% compatible with >> your processor architecture. > > I just figured that even "java -version" bails out on some minor releases. > After updating everything to 6u20 it looks pretty good now. Please verify. many thanks dago, seems to work with both bdb50 and subversion-1.6.11. rupert. From dam at opencsw.org Fri May 14 10:12:36 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 14 May 2010 10:12:36 +0200 Subject: [csw-maintainers] subversion-1.6.11 - what does -xnorunpath ? In-Reply-To: References: Message-ID: Hi, Am 13.05.2010 um 12:37 schrieb Maciej (Matchek) Blizinski: > No dia 13 de Maio de 2010 11:31, rupert THURNER > escreveu: >> the subversion-1.6.11 compile does at some point a "-xnorunpath " and >> then fails with >> gcc: language norunpath not recognized > > It's a Sun Studio flag, which prevents it from embedding it's private > RUNPATH entries in the binaries. GCC doesn't have this option. Did > you search GAR code for it? The problem arises when programs are compiled with cc and the flags are stored in a .pc or similar file which gets then applied to compile a package with gcc. I remember there were issues with the Ruby compile anyway which Ben wanted to convert to cc compilation when I last pinged him on Xapian compilation. Ben, did you get to changing the compile environment? Best regards -- Dago From bwalton at opencsw.org Fri May 14 14:56:55 2010 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 14 May 2010 08:56:55 -0400 Subject: [csw-maintainers] subversion-1.6.11 - what does -xnorunpath ? In-Reply-To: References: Message-ID: <1273841722-sup-8160@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Fri May 14 04:12:36 -0400 2010: > Ben, did you get to changing the compile environment? I did get ruby to build and pass the test suite with sos. I now build with both compilers (at each update) so that I can get rbconfig.rb with settings for both environments. My issue wasn't with .pc files though, but with other compiler flags being forced in based on bad assumptions. I'd have to look back at commits and comments for the exact issue. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Fri May 14 16:37:52 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 14 May 2010 15:37:52 +0100 Subject: [csw-maintainers] more gar? In-Reply-To: <9575805B-05CA-4292-8285-E684211E73CA@opencsw.org> References: <4BE32AC0.30503@cognigencorp.com> <9575805B-05CA-4292-8285-E684211E73CA@opencsw.org> Message-ID: No dia 7 de Maio de 2010 08:58, Dagobert Michelsen escreveu: > Or even easier you just say > ?PRESERVECONF = /etc/opt/csw/myapp.conf > GAR is smart enough to automatically append .CSW, set the class, add the > cswclassutils dependency etc. This is documented here: > ? I took a loot at it, the page suggests: PRESERVECONF = /etc/opt/csw/yourprog.cnf.CSW ...and doesn't say anything about the rename. From dam at opencsw.org Fri May 14 16:43:37 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 14 May 2010 16:43:37 +0200 Subject: [csw-maintainers] more gar? In-Reply-To: References: <4BE32AC0.30503@cognigencorp.com> <9575805B-05CA-4292-8285-E684211E73CA@opencsw.org> Message-ID: <1B654A0D-A33D-4D54-9763-559553A63504@opencsw.org> Hi Maciej, Am 14.05.2010 um 16:37 schrieb Maciej (Matchek) Blizinski: > No dia 7 de Maio de 2010 08:58, Dagobert Michelsen > escreveu: >> Or even easier you just say >> PRESERVECONF = /etc/opt/csw/myapp.conf >> GAR is smart enough to automatically append .CSW, set the class, >> add the >> cswclassutils dependency etc. This is documented here: >> > > I took a loot at it, the page suggests: > > PRESERVECONF = /etc/opt/csw/yourprog.cnf.CSW > > ...and doesn't say anything about the rename. Ok, then I should fix the docs. The code is in there to always rename templates to have the .CSW-suffix: Thanks for noticing! -- Dago PS: Stop editing the page or I can't update it ;-) From maciej at opencsw.org Fri May 14 17:22:07 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 14 May 2010 16:22:07 +0100 Subject: [csw-maintainers] more gar? In-Reply-To: <1B654A0D-A33D-4D54-9763-559553A63504@opencsw.org> References: <4BE32AC0.30503@cognigencorp.com> <9575805B-05CA-4292-8285-E684211E73CA@opencsw.org> <1B654A0D-A33D-4D54-9763-559553A63504@opencsw.org> Message-ID: No dia 14 de Maio de 2010 15:43, Dagobert Michelsen escreveu: > PS: Stop editing the page or I can't update it ;-) No problem, I've released the lock. I might have changed something one the page. ;-) From maciej at opencsw.org Fri May 14 17:30:56 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 14 May 2010 16:30:56 +0100 Subject: [csw-maintainers] more gar? In-Reply-To: <1B654A0D-A33D-4D54-9763-559553A63504@opencsw.org> References: <4BE32AC0.30503@cognigencorp.com> <9575805B-05CA-4292-8285-E684211E73CA@opencsw.org> <1B654A0D-A33D-4D54-9763-559553A63504@opencsw.org> Message-ID: No dia 14 de Maio de 2010 15:43, Dagobert Michelsen escreveu: > Ok, then I should fix the docs. The code is in there to always rename > templates to have the .CSW-suffix: > ? I've added information about a gotcha: If you use csw{sample,preserve}conf together with PKGFILES, the following won't work: PRESERVECONF = /etc/opt/csw/yourprog.cnf PKGFILES_CSWfoo = /etc/opt/csw/yourprog.cnf Instead, you need to do the following: PRESERVECONF = /etc/opt/csw/yourprog.cnf PKGFILES_CSWfoo = /etc/opt/csw/yourprog.cnf.CSW Maciej From dam at opencsw.org Fri May 14 17:46:30 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 14 May 2010 17:46:30 +0200 Subject: [csw-maintainers] more gar? In-Reply-To: References: <4BE32AC0.30503@cognigencorp.com> <9575805B-05CA-4292-8285-E684211E73CA@opencsw.org> <1B654A0D-A33D-4D54-9763-559553A63504@opencsw.org> Message-ID: <220DB706-E4F1-48B6-A68C-AD9FE8BF1D71@opencsw.org> Hi Maciej, Am 14.05.2010 um 17:30 schrieb Maciej (Matchek) Blizinski: > No dia 14 de Maio de 2010 15:43, Dagobert Michelsen > escreveu: >> Ok, then I should fix the docs. The code is in there to always rename >> templates to have the .CSW-suffix: >> > > > > I've added information about a gotcha: If you use > csw{sample,preserve}conf together with PKGFILES, the following won't > work: > > PRESERVECONF = /etc/opt/csw/yourprog.cnf > PKGFILES_CSWfoo = /etc/opt/csw/yourprog.cnf > > Instead, you need to do the following: > > PRESERVECONF = /etc/opt/csw/yourprog.cnf > PKGFILES_CSWfoo = /etc/opt/csw/yourprog.cnf.CSW Right. Would you consider this a bug? It shouldn't be too hard to fix it. Best regards -- Dago From maciej at opencsw.org Fri May 14 18:02:40 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 14 May 2010 17:02:40 +0100 Subject: [csw-maintainers] more gar? In-Reply-To: <220DB706-E4F1-48B6-A68C-AD9FE8BF1D71@opencsw.org> References: <4BE32AC0.30503@cognigencorp.com> <9575805B-05CA-4292-8285-E684211E73CA@opencsw.org> <1B654A0D-A33D-4D54-9763-559553A63504@opencsw.org> <220DB706-E4F1-48B6-A68C-AD9FE8BF1D71@opencsw.org> Message-ID: No dia 14 de Maio de 2010 16:46, Dagobert Michelsen escreveu: > Hi Maciej, > > Am 14.05.2010 um 17:30 schrieb Maciej (Matchek) Blizinski: >> >> No dia 14 de Maio de 2010 15:43, Dagobert Michelsen >> escreveu: >>> >>> Ok, then I should fix the docs. The code is in there to always rename >>> templates to have the .CSW-suffix: >>> >>> ? >> >> I've added information about a gotcha: If you use >> csw{sample,preserve}conf together with PKGFILES, the following won't >> work: >> >> PRESERVECONF = /etc/opt/csw/yourprog.cnf >> PKGFILES_CSWfoo = /etc/opt/csw/yourprog.cnf >> >> Instead, you need to do the following: >> >> PRESERVECONF = /etc/opt/csw/yourprog.cnf >> PKGFILES_CSWfoo = /etc/opt/csw/yourprog.cnf.CSW > > Right. Would you consider this a bug? It shouldn't be too > hard to fix it. By documenting it and relying on it, I just made it a feature! http://blog.jorgepereira.com.br/jorge/wp-content/uploads/2008/12/bug-feature.jpg I think it would be more intuitive if PKGFILES would use the original file names. If you fix it, let me know, I'll need to adjust some Makefiles. From phil at bolthole.com Sat May 15 05:16:17 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 14 May 2010 20:16:17 -0700 Subject: [csw-maintainers] more gar? In-Reply-To: References: <4BE32AC0.30503@cognigencorp.com> <9575805B-05CA-4292-8285-E684211E73CA@opencsw.org> <1B654A0D-A33D-4D54-9763-559553A63504@opencsw.org> <220DB706-E4F1-48B6-A68C-AD9FE8BF1D71@opencsw.org> Message-ID: side comment: we don't have, but could probably use, a class action varient where conf file .CSW versions are kept in /opt/csw/etc, (or even somewhere else under /opt/csw) but copied to /etc/opt/csw. I don't task switch well, and my mind is on subversion right now(and hopefully catalog stuff tomorrow). anyone else want to step in? From bwalton at opencsw.org Sat May 15 14:45:38 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 15 May 2010 08:45:38 -0400 Subject: [csw-maintainers] incompatible packages Message-ID: <1273927251-sup-443@pinkfloyd.chass.utoronto.ca> Hi All, Is there a way to make pkgadd automatically pkgrm (when given the ok by the user) packages marked as Incompatible? Until we get support for this in the catalog and package tools, it's nastier than need be. I don't see any options for the admin file to make this nicer... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat May 15 17:46:07 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 15 May 2010 11:46:07 -0400 Subject: [csw-maintainers] coreutils (and deps) in experimental Message-ID: <1273938178-sup-1386@pinkfloyd.chass.utoronto.ca> Hi All, It's taken _way_ longer than I anticipated to get this into shape[1] but I think the coreutils package is now ready for testing. In the experimental/coreutils catalog, you'll find coreutils and anything that had a dependency on one or more of gfile, shutils or textutils. Coreutils declares itself as incompatible with the old packages (which makes the update suck a bit due to manual handling of the old packages), but everything else should be in working order. Please test this if you can and provide any (positive or negative) feedback you've got. Thanks -Ben [1] Some solaris specific gotchas that were patched around took a bit of time to sort out. -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert at opencsw.org Sat May 15 18:27:40 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 15 May 2010 18:27:40 +0200 Subject: [csw-maintainers] GARCOMPILER = GNU, C compiler cannot create executables ? Message-ID: serf-0.6.1 (libserf) did not compile with the solaris compiler so i set GARCOMPILER = GNU but configure seems not to like this at all, the result was, in config.log: Using built-in specs. Target: sparc-sun-solaris2.8 Configured with: ../gcc-4.3.3/configure --prefix=/opt/csw/gcc4 --exec-prefix=/opt/csw/gcc4 --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-nls --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x --with-mpfr=/opt/csw --with-gmp=/opt/csw --enable-java-awt=xlib --enable-libada --enable-libssp --enable-objc-gc --enable-threads=posix --enable-stage1-languages=c --enable-languages=ada,c,c++,fortran,java,objc Thread model: posix gcc version 4.3.3 (GCC) configure:3331: $? = 0 configure:3338: /opt/csw/gcc4/bin/gcc -V >&5 gcc: '-V' option must have argument configure:3341: $? = 1 configure:3364: checking for C compiler default output file name configure:3391: /opt/csw/gcc4/bin/gcc -O2 -pipe -mcpu=v8 -mt -I/opt/csw/include -DSOLARIS2=8 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_LARGEFILE64_SOURCE -L/opt/csw/gcc4/lib/. -mcpu=v8 -L/opt/csw/lib conftest.c >&5 cc1: error: unrecognized command line option "-mt" configure:3394: $? = 1 configure:3432: result: configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:3439: error: C compiler cannot create executables See `config.log' for more details. From bwalton at opencsw.org Sat May 15 18:56:18 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 15 May 2010 12:56:18 -0400 Subject: [csw-maintainers] GARCOMPILER = GNU, C compiler cannot create executables ? In-Reply-To: References: Message-ID: <1273942453-sup-8547@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Sat May 15 12:27:40 -0400 2010: Hi Rupert, > serf-0.6.1 (libserf) did not compile with the solaris compiler so i set > > GARCOMPILER = GNU > > but configure seems not to like this at all, the result was, in > config.log: This looks to be a mismatch between what the apr was built with (SOS) and what you're building with now. The apr confiruation section is honouring the CC setting but using the CFLAGS, etc that it was built with... Likely best to sort out the SOS12 problem in this case. It doesn't look too bad, although I haven't spotted the problem yet. HTH. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert at opencsw.org Sat May 15 19:12:27 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 15 May 2010 19:12:27 +0200 Subject: [csw-maintainers] checkpkg - why emacscommon for subversion tools? In-Reply-To: References: Message-ID: hi, could it be an error in checkpkg that it insists requiring "emacscommon" for subversion tools or contrib? CHECKPKG_OVERRIDES_CSWsvn-tools += missing-dependency|CSWemacscommon CHECKPKG_OVERRIDES_CSWsvn-contrib += missing-dependency|CSWemacscommon rupert. From bwalton at opencsw.org Sat May 15 19:27:09 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 15 May 2010 13:27:09 -0400 Subject: [csw-maintainers] checkpkg - why emacscommon for subversion tools? In-Reply-To: References: Message-ID: <1273944364-sup-7067@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Sat May 15 13:12:27 -0400 2010: > could it be an error in checkpkg that it insists requiring > "emacscommon" for subversion tools or contrib? > > CHECKPKG_OVERRIDES_CSWsvn-tools += missing-dependency|CSWemacscommon > CHECKPKG_OVERRIDES_CSWsvn-contrib += > missing-dependency|CSWemacscommon This is added when .el files are detected in the package. If you don't want the dependency, either use the suggested override or split out the .el stuff into a separate _el package that does have the dependency. If the package doesn't have .el files, this would be a bug. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Sat May 15 19:42:57 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 15 May 2010 19:42:57 +0200 Subject: [csw-maintainers] checkpkg - why emacscommon for subversion tools? In-Reply-To: <1273944364-sup-7067@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Sat, 15 May 2010 13:27:09 -0400") References: <1273944364-sup-7067@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > Excerpts from rupert THURNER's message of Sat May 15 13:12:27 -0400 2010: > >> could it be an error in checkpkg that it insists requiring >> "emacscommon" for subversion tools or contrib? >> >> CHECKPKG_OVERRIDES_CSWsvn-tools += missing-dependency|CSWemacscommon >> CHECKPKG_OVERRIDES_CSWsvn-contrib += >> missing-dependency|CSWemacscommon > > This is added when .el files are detected in the package. If you > don't want the dependency, either use the suggested override or split > out the .el stuff into a separate _el package that does have the > dependency. > > If the package doesn't have .el files, this would be a bug. It has psvn.el -- Peter From phil at bolthole.com Sat May 15 21:26:07 2010 From: phil at bolthole.com (Philip Brown) Date: Sat, 15 May 2010 12:26:07 -0700 Subject: [csw-maintainers] incompatible packages In-Reply-To: <1273927251-sup-443@pinkfloyd.chass.utoronto.ca> References: <1273927251-sup-443@pinkfloyd.chass.utoronto.ca> Message-ID: pkg-get has always done this. pkgutil doesn't because it ignores the pkg files and just goes by what's in the catalog I'm going to update catalog format this weekend hopefully On Saturday, May 15, 2010, Ben Walton wrote: > > Hi All, > > Is there a way to make pkgadd automatically pkgrm (when given the ok > by the user) packages marked as Incompatible? ?Until we get support > for this in the catalog and package tools, it's nastier than need be. > I don't see any options for the admin file to make this nicer... > > Thanks > -Ben > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From bwalton at opencsw.org Sat May 15 21:58:29 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 15 May 2010 15:58:29 -0400 Subject: [csw-maintainers] incompatible packages In-Reply-To: References: <1273927251-sup-443@pinkfloyd.chass.utoronto.ca> Message-ID: <1273953463-sup-4291@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sat May 15 15:26:07 -0400 2010: > pkg-get has always done this. Interesting. I was unaware of this. You're handling the depend file explicitly then? > pkgutil doesn't because it ignores the pkg files and just goes by > what's in the catalog I'm going to update catalog format this > weekend hopefully Excellent! Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Sat May 15 23:42:18 2010 From: phil at bolthole.com (Philip Brown) Date: Sat, 15 May 2010 14:42:18 -0700 Subject: [csw-maintainers] incompatible packages In-Reply-To: <1273953463-sup-4291@pinkfloyd.chass.utoronto.ca> References: <1273927251-sup-443@pinkfloyd.chass.utoronto.ca> <1273953463-sup-4291@pinkfloyd.chass.utoronto.ca> Message-ID: >> pkg-get has always done this. > > Interesting. ?I was unaware of this. ?You're handling the depend file > explicitly then? yup. one of the reasons pkg-get is so long. From rupert at opencsw.org Sun May 16 07:37:11 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 16 May 2010 07:37:11 +0200 Subject: [csw-maintainers] openldap: internal compiler error: Failure while writing SunIR file ? Message-ID: while trying to rebuild openldap the compiler says: /opt/studio/SOS12/SUNWspro/bin/cc -xO3 -m64 -xarch=sse2 -xnorunpath -I../../../include -I../../../include -I.. -I./.. -I/opt/csw/bdb44/include -I/opt/csw/include -DSLAPD_IMPORT -c delete.c -KPIC -DPIC -o .libs/delete.o "/opt/csw/include/sqltypes.h", line 400: warning: no explicit type given "/opt/csw/include/sqltypes.h", line 403: warning: no explicit type given "delete.c", line 54: internal compiler error: Failure while writing SunIR file gmake[4]: Leaving directory `/home/rupert/mgar/pkg/openldap/trunk/work/solaris9-i386/build-isa-amd64-garversion-2.3.43/openldap-2.3.43/servers/slapd/back-sql' gmake[3]: Leaving directory `/home/rupert/mgar/pkg/openldap/trunk/work/solaris9-i386/build-isa-amd64-garversion-2.3.43/openldap-2.3.43/servers/slapd' From rupert at opencsw.org Sun May 16 07:38:44 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 16 May 2010 07:38:44 +0200 Subject: [csw-maintainers] subversion - ld: fatal: library -luuid: not found (only on i386) Message-ID: somebody of you saw this already and has an idea where it might come from? $ SKIPTEST=1 gmake clean platforms ... /bin/bash /home/rupert/mgar/pkg/subversion/trunk/work/solaris9-i386/build-isa-i386/subversion-1.6.11/libtool --tag=CC --silent --mode=compile /opt/studio/SOS12/SUNWspro/bin/cc -I/opt/csw/apache2/include -I/opt/csw/include -DSOLARIS2=8 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_LARGEFILE64_SOURCE -xO3 -m32 -xarch=386 -xnorunpath -mt -D_LARGEFILE64_SOURCE -DNE_LFS -I./subversion/include -I./subversion -I/opt/csw/apache2/include -I/opt/csw/apache2/include -I/opt/csw/include -I/opt/csw/bdb48/include -I/opt/csw/include/neon -I/opt/csw/include -I/opt/csw/include -o subversion/libsvn_subr/xml.lo -c subversion/libsvn_subr/xml.c cd subversion/libsvn_subr && /bin/bash /home/rupert/mgar/pkg/subversion/trunk/work/solaris9-i386/build-isa-i386/subversion-1.6.11/libtool --tag=CC --silent --mode=link /opt/studio/SOS12/SUNWspro/bin/cc -xO3 -m32 -xarch=386 -xnorunpath -mt -D_LARGEFILE64_SOURCE -DNE_LFS -m32 -xarch=386 -L/opt/csw/bdb48/lib -L/opt/csw/apache2/lib -L/opt/csw/lib/svn -L/opt/csw/lib -lintl -liconv -L/opt/csw/lib -L/opt/csw/bdb48/lib -L/opt/csw/lib -L/opt/csw/lib -rpath /opt/csw/lib/svn -o libsvn_subr-1.la atomic.lo auth.lo cache-inprocess.lo cache-memcache.lo cache.lo checksum.lo cmdline.lo compat.lo config.lo config_auth.lo config_file.lo config_win.lo constructors.lo ctype.lo date.lo deprecated.lo dirent_uri.lo dso.lo error.lo hash.lo io.lo iter.lo kitchensink.lo lock.lo log.lo macos_keychain.lo md5.lo mergeinfo.lo nls.lo opt.lo path.lo pool.lo prompt.lo properties.lo quoprint.lo sha1.lo simple_providers.lo skel.lo sorts.lo sqlite.lo ssl_client_cert_providers.lo ssl_client_cert_pw_providers.lo ssl_server_trust_providers.lo stream.lo subst.lo svn_base64.lo svn_string.lo target.lo time.lo user.lo username_providers.lo utf.lo utf_validate.lo validate.lo version.lo win32_crashrpt.lo win32_crypto.lo win32_xlate.lo xml.lo -laprutil-1 -lldap -llber -lexpat -liconv -lapr-1 -luuid -lsendfile -lrt -lsocket -lnsl -lpthread -ldl -lz -lsqlite3 -lsocket ld: fatal: library -luuid: not found ld: fatal: File processing errors. No output written to .libs/libsvn_subr-1.so.0.0.0 gmake[2]: *** [subversion/libsvn_subr/libsvn_subr-1.la] Error 1 gmake[2]: Leaving directory `/home/rupert/mgar/pkg/subversion/trunk/work/solaris9-i386/build-isa-i386/subversion-1.6.11' gmake[1]: *** [build-work/solaris9-i386/build-isa-i386/subversion-1.6.11/Makefile] Error 2 gmake[1]: Leaving directory `/home/rupert/mgar/pkg/subversion/trunk' gmake: *** [merge-isa-i386] Error 2 gmake: Leaving directory `/home/rupert/mgar/pkg/subversion/trunk' Connection to current9x closed. gmake: *** [platforms] Error 2 rupert at current9s ~/mgar/pkg/subversion/trunk From rupert at opencsw.org Sun May 16 09:49:43 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 16 May 2010 09:49:43 +0200 Subject: [csw-maintainers] gar: -I/opt/csw/include -I. should be -I. -I/opt/csw/include Message-ID: hi, what would be the best way to turn the inclusion directories. in this case, we have an old version of serf, and its .h files gets included instead of the new versions to be compiled. rupert. ---------- Forwarded message ---------- From: Greg Stein Date: May 15, 6:54?pm Subject: [serf] r1370 committed - Tag for 0.6.1 release. To: Serf Development List That is strange. The type is defined in serf_bucket_types.h, which is included by serf.h, so it should be present in the build. I believe what is happened is that you're getting the wrong includes. Your build line has -I/opt/csw/include *before* the -I. .. so if you have an old serf.h/serf_bucket_types.h in that opt area, then... boom. How did that directory get before the -I. ? And is there an old serf there already? Cheers, -g On Sat, May 15, 2010 at 12:17, rupert.thur... at gmail.com wrote: > hi, i tried to compile 0.6.1 forhttp://opencsw.orgsolaris packaging, > but the compilation fails with: > gmake[3]: Entering directory `/home/rupert/mgar/pkg/libserf/trunk/work/ > solaris9-sparc/build-isa-sparcv8/serf-0.6.1' > /home/rupert/mgar/pkg/libserf/trunk/work/solaris9-sparc/build-isa- > sparcv8/serf-0.6.1/libtool --silent --tag=CC --mode=compile /opt/ > studio/SOS12/SUNWspro/bin/cc -mt -xO3 -m32 -xarch=v8 -xnorunpath - > DSOLARIS2=8 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT - > D_LARGEFILE64_SOURCE -I/opt/csw/include -I. ?-I/opt/csw/apache2/ > include ? -I/opt/csw/apache2/include -I/opt/csw/include ?-c -o buckets/ > aggregate_buckets.lo buckets/aggregate_buckets.c && touch buckets/ > aggregate_buckets.lo > "buckets/aggregate_buckets.c", line 33: syntax error before or at: > serf_bucket_aggregate_eof_t > "buckets/aggregate_buckets.c", line 45: improper member use: snapshot > "buckets/aggregate_buckets.c", line 51: improper member use: done > "buckets/aggregate_buckets.c", line 52: improper member use: done > "buckets/aggregate_buckets.c", line 54: improper member use: done > "buckets/aggregate_buckets.c", line 54: improper member use: done > "buckets/aggregate_buckets.c", line 55: improper member use: done > "buckets/aggregate_buckets.c", line 57: improper member use: done > "buckets/aggregate_buckets.c", line 75: improper member use: list > "buckets/aggregate_buckets.c", line 76: improper member use: last > "buckets/aggregate_buckets.c", line 77: improper member use: done > "buckets/aggregate_buckets.c", line 78: improper member use: snapshot > "buckets/aggregate_buckets.c", line 79: undefined struct/union member: > hold_open > "buckets/aggregate_buckets.c", line 100: improper member use: list > "buckets/aggregate_buckets.c", line 101: improper member use: list > "buckets/aggregate_buckets.c", line 101: improper member use: list > "buckets/aggregate_buckets.c", line 102: improper member use: list > "buckets/aggregate_buckets.c", line 103: improper member use: list > "buckets/aggregate_buckets.c", line 104: improper member use: list > "buckets/aggregate_buckets.c", line 134: improper member use: list > "buckets/aggregate_buckets.c", line 136: improper member use: list > "buckets/aggregate_buckets.c", line 155: improper member use: list > "buckets/aggregate_buckets.c", line 156: improper member use: list > "buckets/aggregate_buckets.c", line 157: improper member use: last > "buckets/aggregate_buckets.c", line 160: improper member use: last > "buckets/aggregate_buckets.c", line 161: improper member use: last > "buckets/aggregate_buckets.c", line 161: improper member use: last > "buckets/aggregate_buckets.c", line 166: syntax error before or at: > serf_bucket_aggregate_eof_t > "buckets/aggregate_buckets.c", line 166: warning: undefined or missing > type for: serf_bucket_aggregate_eof_t > "buckets/aggregate_buckets.c", line 167: warning: undefined or missing > type for: void > "buckets/aggregate_buckets.c", line 170: undefined struct/union > member: hold_open > "buckets/aggregate_buckets.c", line 170: undefined symbol: fn > "buckets/aggregate_buckets.c", line 171: undefined symbol: baton > "buckets/aggregate_buckets.c", line 171: warning: improper pointer/ > integer combination: op "=" > "buckets/aggregate_buckets.c", line 225: improper member use: list > "buckets/aggregate_buckets.c", line 226: undefined struct/union > member: hold_open > "buckets/aggregate_buckets.c", line 227: improper member use: > hold_open > "buckets/aggregate_buckets.c", line 227: function designator is not of > function type > "buckets/aggregate_buckets.c", line 227: warning: improper pointer/ > integer combination: op "=" > "buckets/aggregate_buckets.c", line 235: improper member use: list > "buckets/aggregate_buckets.c", line 264: improper member use: list > "buckets/aggregate_buckets.c", line 265: improper member use: list > "buckets/aggregate_buckets.c", line 265: improper member use: done > "buckets/aggregate_buckets.c", line 266: improper member use: done > "buckets/aggregate_buckets.c", line 266: improper member use: list > "buckets/aggregate_buckets.c", line 267: improper member use: list > "buckets/aggregate_buckets.c", line 270: improper member use: list > "buckets/aggregate_buckets.c", line 271: undefined struct/union > member: hold_open > "buckets/aggregate_buckets.c", line 272: improper member use: > hold_open > "buckets/aggregate_buckets.c", line 272: function designator is not of > function type > "buckets/aggregate_buckets.c", line 272: warning: improper pointer/ > integer combination: op "=" > "buckets/aggregate_buckets.c", line 302: cannot recover from previous > errors > cc: acomp failed for buckets/aggregate_buckets.c > gmake[3]: *** [buckets/aggregate_buckets.lo] Error 1 > gmake[3]: Leaving directory `/home/rupert/mgar/pkg/libserf/trunk/work/ > solaris9-sparc/build-isa-sparcv8/serf-0.6.1' > gmake[2]: *** [build-work/solaris9-sparc/build-isa-sparcv8/serf-0.6.1/ > Makefile] Error 2 > gmake[2]: Leaving directory `/home/rupert/mgar/pkg/libserf/trunk' > gmake[1]: *** [merge-isa-sparcv8] Error 2 > gmake[1]: Leaving directory `/home/rupert/mgar/pkg/libserf/trunk' > gmake: *** [platforms] Error 2 > rupert. > On May 14, 3:35?pm, s... at googlecode.com wrote: >> Revision: 1370 >> Author: gstein >> Date: Fri May 14 06:24:32 2010 >> Log: Tag for 0.6.1 release. >>http://code.google.com/p/serf/source/detail?r=1370 >> Added: >> ? /tags/0.6.1 >> -- >> You received this message because you are subscribed to the Google Groups "Serf Development List" group. >> To post to this group, send email to serf-dev at googlegroups.com. >> To unsubscribe from this group, send email to serf-dev+unsubscribe at googlegroups.com. >> For more options, visit this group athttp://groups.google.com/group/serf-dev?hl=en. > -- > You received this message because you are subscribed to the Google Groups "Serf Development List" group. > To post to this group, send email to serf-dev at googlegroups.com. > To unsubscribe from this group, send email to serf-dev+unsubscribe at googlegroups.com. > For more options, visit this group athttp://groups.google.com/group/serf-dev?hl=en. -- You received this message because you are subscribed to the Google Groups "Serf Development List" group. To post to this group, send email to serf-dev at googlegroups.com. To unsubscribe from this group, send email to serf-dev +unsubscribe at googlegroups.com. For more options, visit this group athttp://groups.google.com/group/serf-dev?hl=en. From dam at opencsw.org Fri May 14 10:36:09 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 14 May 2010 10:36:09 +0200 Subject: [csw-maintainers] [buildfarm-announce] Unplanned outage In-Reply-To: <4BEC6326.6020909@baltic-online.de> References: <4BEC6326.6020909@baltic-online.de> Message-ID: Dear buildfarm users, we had an unplanned downtime on the buildfarm due to defect testsuite which consumed all memory. The issue has been resolved and we will set up memory constraints in the near future. Sorry for the inconvenience -- Dago _______________________________________________ buildfarm-announce mailing list buildfarm-announce at opencsw.org https://lists.opencsw.org/mailman/listinfo/buildfarm-announce From dam at opencsw.org Mon May 17 09:53:49 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 17 May 2010 09:53:49 +0200 Subject: [csw-maintainers] more gar? In-Reply-To: References: <4BE32AC0.30503@cognigencorp.com> <9575805B-05CA-4292-8285-E684211E73CA@opencsw.org> <1B654A0D-A33D-4D54-9763-559553A63504@opencsw.org> <220DB706-E4F1-48B6-A68C-AD9FE8BF1D71@opencsw.org> Message-ID: <1F0F96D2-712C-415C-B0EC-B3FFA76AE8DD@opencsw.org> Hi Phil, Am 15.05.2010 um 05:16 schrieb Philip Brown: > side comment: > we don't have, but could probably use, a class action varient where > conf file .CSW versions are kept in /opt/csw/etc, (or even somewhere > else under /opt/csw) but copied to /etc/opt/csw. > > I don't task switch well, and my mind is on subversion right now(and > hopefully catalog stuff tomorrow). anyone else want to step in? How about adding an RFE on the wiki-page or a bug on the package? Beste regards -- Dago From dam at opencsw.org Mon May 17 10:44:10 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 17 May 2010 10:44:10 +0200 Subject: [csw-maintainers] checkpkg - why emacscommon for subversion tools? In-Reply-To: References: <1273944364-sup-7067@pinkfloyd.chass.utoronto.ca> Message-ID: <9BFCCB76-E645-46F7-8A2E-75D153682423@opencsw.org> Hi, Am 15.05.2010 um 19:42 schrieb Peter FELECAN: > Ben Walton writes: >> Excerpts from rupert THURNER's message of Sat May 15 13:12:27 -0400 >> 2010: >>> could it be an error in checkpkg that it insists requiring >>> "emacscommon" for subversion tools or contrib? >>> >>> CHECKPKG_OVERRIDES_CSWsvn-tools += missing-dependency|CSWemacscommon >>> CHECKPKG_OVERRIDES_CSWsvn-contrib += >>> missing-dependency|CSWemacscommon >> >> This is added when .el files are detected in the package. If you >> don't want the dependency, either use the suggested override or split >> out the .el stuff into a separate _el package that does have the >> dependency. >> >> If the package doesn't have .el files, this would be a bug. > > It has psvn.el Ok, I would tend to override the checkpkg warning. The .el-file is pretty optional and only useful *if* you use emacs, but using emacs is not mandatory ;-) Best regards -- Dago From dam at opencsw.org Mon May 17 10:46:45 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 17 May 2010 10:46:45 +0200 Subject: [csw-maintainers] openldap: internal compiler error: Failure while writing SunIR file ? In-Reply-To: References: Message-ID: <8D001570-600A-4AB0-873C-C2873FA9D093@opencsw.org> Hi Rupert, Am 16.05.2010 um 07:37 schrieb rupert THURNER: > while trying to rebuild openldap the compiler says: > > /opt/studio/SOS12/SUNWspro/bin/cc -xO3 -m64 -xarch=sse2 -xnorunpath > -I../../../include -I../../../include -I.. -I./.. > -I/opt/csw/bdb44/include -I/opt/csw/include -DSLAPD_IMPORT -c delete.c > -KPIC -DPIC -o .libs/delete.o > "/opt/csw/include/sqltypes.h", line 400: warning: no explicit type > given > "/opt/csw/include/sqltypes.h", line 403: warning: no explicit type > given > "delete.c", line 54: internal compiler error: Failure while writing > SunIR file > gmake[4]: Leaving directory > `/home/rupert/mgar/pkg/openldap/trunk/work/solaris9-i386/build-isa- > amd64-garversion-2.3.43/openldap-2.3.43/servers/slapd/back-sql' > gmake[3]: Leaving directory > `/home/rupert/mgar/pkg/openldap/trunk/work/solaris9-i386/build-isa- > amd64-garversion-2.3.43/openldap-2.3.43/servers/slapd' Last time I saw this was because of excessive use of parallel making. It it occuring even with sequential make? Best regards -- Dago From dam at opencsw.org Mon May 17 11:00:08 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 17 May 2010 11:00:08 +0200 Subject: [csw-maintainers] subversion - ld: fatal: library -luuid: not found (only on i386) In-Reply-To: References: Message-ID: <31653F2D-6B07-4A12-A6F1-CA72AF56EDEB@opencsw.org> Hi Rupert, Am 16.05.2010 um 07:38 schrieb rupert THURNER: > somebody of you saw this already and has an idea where it might come > from? > > $ SKIPTEST=1 gmake clean platforms > ... > /bin/bash /home/rupert/mgar/pkg/subversion/trunk/work/solaris9-i386/ > build-isa-i386/subversion-1.6.11/libtool > --tag=CC --silent --mode=compile /opt/studio/SOS12/SUNWspro/bin/cc > -I/opt/csw/apache2/include -I/opt/csw/include -DSOLARIS2=8 > -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_LARGEFILE64_SOURCE -xO3 > -m32 -xarch=386 -xnorunpath -mt -D_LARGEFILE64_SOURCE -DNE_LFS > -I./subversion/include -I./subversion -I/opt/csw/apache2/include > -I/opt/csw/apache2/include -I/opt/csw/include -I/opt/csw/bdb48/include > -I/opt/csw/include/neon -I/opt/csw/include -I/opt/csw/include -o > subversion/libsvn_subr/xml.lo -c subversion/libsvn_subr/xml.c > cd subversion/libsvn_subr && /bin/bash > /home/rupert/mgar/pkg/subversion/trunk/work/solaris9-i386/build-isa- > i386/subversion-1.6.11/libtool > --tag=CC --silent --mode=link /opt/studio/SOS12/SUNWspro/bin/cc -xO3 > -m32 -xarch=386 -xnorunpath -mt -D_LARGEFILE64_SOURCE -DNE_LFS > -m32 -xarch=386 -L/opt/csw/bdb48/lib -L/opt/csw/apache2/lib > -L/opt/csw/lib/svn -L/opt/csw/lib -lintl -liconv -L/opt/csw/lib > -L/opt/csw/bdb48/lib -L/opt/csw/lib -L/opt/csw/lib -rpath > /opt/csw/lib/svn -o libsvn_subr-1.la atomic.lo auth.lo > cache-inprocess.lo cache-memcache.lo cache.lo checksum.lo cmdline.lo > compat.lo config.lo config_auth.lo config_file.lo config_win.lo > constructors.lo ctype.lo date.lo deprecated.lo dirent_uri.lo dso.lo > error.lo hash.lo io.lo iter.lo kitchensink.lo lock.lo log.lo > macos_keychain.lo md5.lo mergeinfo.lo nls.lo opt.lo path.lo pool.lo > prompt.lo properties.lo quoprint.lo sha1.lo simple_providers.lo > skel.lo sorts.lo sqlite.lo ssl_client_cert_providers.lo > ssl_client_cert_pw_providers.lo ssl_server_trust_providers.lo > stream.lo subst.lo svn_base64.lo svn_string.lo target.lo time.lo > user.lo username_providers.lo utf.lo utf_validate.lo validate.lo > version.lo win32_crashrpt.lo win32_crypto.lo win32_xlate.lo xml.lo > -laprutil-1 -lldap -llber -lexpat -liconv -lapr-1 -luuid -lsendfile > -lrt -lsocket -lnsl -lpthread -ldl -lz -lsqlite3 -lsocket > ld: fatal: library -luuid: not found > ld: fatal: File processing errors. No output written to > .libs/libsvn_subr-1.so.0.0.0 > gmake[2]: *** [subversion/libsvn_subr/libsvn_subr-1.la] Error 1 > gmake[2]: Leaving directory > `/home/rupert/mgar/pkg/subversion/trunk/work/solaris9-i386/build-isa- > i386/subversion-1.6.11' > gmake[1]: *** [build-work/solaris9-i386/build-isa-i386/ > subversion-1.6.11/Makefile] > Error 2 > gmake[1]: Leaving directory `/home/rupert/mgar/pkg/subversion/trunk' > gmake: *** [merge-isa-i386] Error 2 > gmake: Leaving directory `/home/rupert/mgar/pkg/subversion/trunk' > Connection to current9x closed. > gmake: *** [platforms] Error 2 > rupert at current9s ~/mgar/pkg/subversion/trunk There is no /usr/lib/libuuid.so on current9x. On current9s it is and SUNWcsl looks good to me. Maybe someone can crosscheck? For now I have added /usr/lib/libuuid.so -> libuuid.so.1 which should fix your problem. Best regards -- Dago From dam at opencsw.org Mon May 17 11:07:33 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 17 May 2010 11:07:33 +0200 Subject: [csw-maintainers] gar: -I/opt/csw/include -I. should be -I. -I/opt/csw/include In-Reply-To: References: Message-ID: <99D9E299-998D-423A-97F4-A990076623C7@opencsw.org> Hi Rupert, Am 16.05.2010 um 09:49 schrieb rupert THURNER: > hi, what would be the best way to turn the inclusion directories. in > this case, we have an old version of serf, and its .h files gets > included instead of the new versions to be compiled. Difficult. You have to look how -I/opt/csw/include gets there, by which variable in the Makefile. Then you either change the variables passed to "make" (preferred), patch the Makefile or, as a last resort, rewrite the arguments by a "cc" stub like in Best regards -- Dago From phil at bolthole.com Mon May 17 18:16:16 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 17 May 2010 09:16:16 -0700 Subject: [csw-maintainers] more gar? In-Reply-To: <1F0F96D2-712C-415C-B0EC-B3FFA76AE8DD@opencsw.org> References: <4BE32AC0.30503@cognigencorp.com> <9575805B-05CA-4292-8285-E684211E73CA@opencsw.org> <1B654A0D-A33D-4D54-9763-559553A63504@opencsw.org> <220DB706-E4F1-48B6-A68C-AD9FE8BF1D71@opencsw.org> <1F0F96D2-712C-415C-B0EC-B3FFA76AE8DD@opencsw.org> Message-ID: On Mon, May 17, 2010 at 12:53 AM, Dagobert Michelsen wrote: > Hi Phil, > > Am 15.05.2010 um 05:16 schrieb Philip Brown: >> >> side comment: >> we don't have, but could probably use, a class action varient where >> conf file .CSW versions are kept in /opt/csw/etc, (or even somewhere >> else under /opt/csw) but copied to /etc/opt/csw. >> >> I don't task switch well, and my mind is on subversion right now(and >> hopefully catalog stuff tomorrow). anyone else want to step in? > > How about adding an RFE on the wiki-page or a bug on the package? > good idea. i updated wiki page. although its so long it will get lost. as far as filing a bug, no-one really has full "ownership" of the package, so not sure that is exactly useful. From pfelecan at opencsw.org Mon May 17 19:27:29 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 17 May 2010 19:27:29 +0200 Subject: [csw-maintainers] checkpkg - why emacscommon for subversion tools? In-Reply-To: <9BFCCB76-E645-46F7-8A2E-75D153682423@opencsw.org> (Dagobert Michelsen's message of "Mon, 17 May 2010 10:44:10 +0200") References: <1273944364-sup-7067@pinkfloyd.chass.utoronto.ca> <9BFCCB76-E645-46F7-8A2E-75D153682423@opencsw.org> Message-ID: Dagobert Michelsen writes: > Hi, > > Am 15.05.2010 um 19:42 schrieb Peter FELECAN: >> Ben Walton writes: >>> Excerpts from rupert THURNER's message of Sat May 15 13:12:27 -0400 >>> 2010: >>>> could it be an error in checkpkg that it insists requiring >>>> "emacscommon" for subversion tools or contrib? >>>> >>>> CHECKPKG_OVERRIDES_CSWsvn-tools += missing-dependency|CSWemacscommon >>>> CHECKPKG_OVERRIDES_CSWsvn-contrib += >>>> missing-dependency|CSWemacscommon >>> >>> This is added when .el files are detected in the package. If you >>> don't want the dependency, either use the suggested override or split >>> out the .el stuff into a separate _el package that does have the >>> dependency. >>> >>> If the package doesn't have .el files, this would be a bug. >> >> It has psvn.el > > Ok, I would tend to override the checkpkg warning. The .el-file is > pretty optional and only useful *if* you use emacs, but using emacs > is not mandatory ;-) This and also because the psvn.el supplied with subversion is very often out of date I propose to have a separate package containing this file from the source, i.e., upstream. -- Peter From bwalton at opencsw.org Mon May 17 19:35:40 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 17 May 2010 13:35:40 -0400 Subject: [csw-maintainers] checkpkg - why emacscommon for subversion tools? In-Reply-To: References: <1273944364-sup-7067@pinkfloyd.chass.utoronto.ca> <9BFCCB76-E645-46F7-8A2E-75D153682423@opencsw.org> Message-ID: <1274117675-sup-7708@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Mon May 17 13:27:29 -0400 2010: > This and also because the psvn.el supplied with subversion is very > often out of date I propose to have a separate package containing > this file from the source, i.e., upstream. So don't use the override...simply remove it as a (GAR) post-install step. Then, deliver a better version as a separate package. That sounds like a good strategy. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert at opencsw.org Mon May 17 20:49:39 2010 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 17 May 2010 20:49:39 +0200 Subject: [csw-maintainers] gar: -I/opt/csw/include -I. should be -I. -I/opt/csw/include In-Reply-To: <99D9E299-998D-423A-97F4-A990076623C7@opencsw.org> References: <99D9E299-998D-423A-97F4-A990076623C7@opencsw.org> Message-ID: On Mon, May 17, 2010 at 11:07, Dagobert Michelsen wrote: > Hi Rupert, > > Am 16.05.2010 um 09:49 schrieb rupert THURNER: >> >> hi, what would be the best way to turn the inclusion directories. in >> this case, we have an old version of serf, and its .h files gets >> included instead of the new versions to be compiled. > > Difficult. You have to look how -I/opt/csw/include gets there, > by which variable in the Makefile. Then you either change the > variables passed to "make" (preferred), patch the Makefile or, > as a last resort, rewrite the arguments by a "cc" stub like in > ? this seems quite complex? the current makefile is here: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/libserf/trunk/Makefile, and i did not put anything to tinker with that order. at least not deliverately. should it not be the default that the files delivered with a package source should be the first in the path for everything, in any case, every package? rupert. From skayser at opencsw.org Mon May 17 21:39:35 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 17 May 2010 21:39:35 +0200 Subject: [csw-maintainers] gar: -I/opt/csw/include -I. should be -I. -I/opt/csw/include In-Reply-To: References: <99D9E299-998D-423A-97F4-A990076623C7@opencsw.org> Message-ID: <4BF19B77.7080407@opencsw.org> rupert THURNER wrote on 17.05.2010 20:49: > On Mon, May 17, 2010 at 11:07, Dagobert Michelsen wrote: >> Am 16.05.2010 um 09:49 schrieb rupert THURNER: >>> hi, what would be the best way to turn the inclusion directories. in >>> this case, we have an old version of serf, and its .h files gets >>> included instead of the new versions to be compiled. >> Difficult. You have to look how -I/opt/csw/include gets there, >> by which variable in the Makefile. Then you either change the >> variables passed to "make" (preferred), patch the Makefile or, >> as a last resort, rewrite the arguments by a "cc" stub like in >> > > this seems quite complex? the current makefile is here: > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/libserf/trunk/Makefile, > and i did not put anything to tinker with that order. at least not > deliverately. Have a look at the output of "gmake modenv". GAR pre-sets default preprocessor, compiler, and linker flags WRT to /opt/csw via the environment. For libserf CPPFLAGS is the interesting one. $ gmake modenv | grep CPPFLAGS CPPFLAGS = -I/opt/csw/include Combined with the serf Makefile ... $ grep CPPFLAGS work/solaris9-i386/build-isa-i386/serf-0.6.1/Makefile CPPFLAGS = -DSOLARIS2=8 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_LARGEFILE64_SOURCE -I/opt/csw/include $(LIBTOOL) $(LTFLAGS) --mode=compile $(CC) $(CFLAGS) $(CPPFLAGS) $(INCLUDES) -c -o $@ $< && touch $@ ... this translates to the failing build invocation. When you swap $(CPPFLAGS) and $(INCLUDES) the build continues. > should it not be the default that the files delivered with a package > source should be the first in the path for everything, in any case, > every package? I don't have a strong stance here, but I would think that if a software build absolutely needs to make sure -I. comes first, then it should also place it properly for the compiler invocation (i.e. even before any possibly given -I in $CPPFLAGS). Sebastian From bonivart at opencsw.org Tue May 18 14:46:40 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 18 May 2010 14:46:40 +0200 Subject: [csw-maintainers] Catalog broken Message-ID: # chkcat -e catalog.ftp.df.lth.se_pub_csw_current_sparc_5.10 ERROR! 7 fields instead of normal 8. [apr 1.4.2,REV=2010.04.19 CSWapr apr-1.4.2,REV=2010.04.19-SunOS5.9-sparc-CSW.pkg.gz 44cfa96279fed78d7c30a4832b462368 374061 none] ERROR! 7 fields instead of normal 8. [pca 20100514.01,REV=2010.05.17 CSWpca pca-20100514.01,REV=2010.05.17-SunOS5.9-all-CSW.pkg.gz b7fd6559c664c37e693e1e6e9dff4a97 71738 none] ERROR! 7 fields instead of normal 8. [phpldapadmin 1.2.0.5,REV=2010.05.17 CSWphpldapadmin phpldapadmin-1.2.0.5,REV=2010.05.17-SunOS5.9-all-CSW.pkg.gz fa2cb964a1684128cd6d8de769486985 1378475 none] ERROR! 7 fields instead of normal 8. [sunx11_devel 1.0,REV=2010.05.17 CSWsunx11devel sunx11_devel-1.0,REV=2010.05.17-SunOS5.9-all-CSW.pkg.gz 0c354320155896604a61a72d3435b7ae 7358 none] ERROR! 7 fields instead of normal 8. [tmux 1.2,REV=2010.05.17 CSWtmux tmux-1.2,REV=2010.05.17-SunOS5.9-sparc-CSW.pkg.gz 145351cf6186fdcadcd169b66387f72f 214091 none] # digest -a md5 catalog.ftp.df.lth.se_pub_csw_current_sparc_5.10 3291702371e4b3654d610aad9a72afd6 -- /peter From dam at opencsw.org Tue May 18 14:59:36 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 18 May 2010 14:59:36 +0200 Subject: [csw-maintainers] Catalog broken In-Reply-To: References: Message-ID: <7BCD4E9E-F951-4FAB-8DFE-881B4AB3337D@opencsw.org> Hi Peter, Am 18.05.2010 um 14:46 schrieb Peter Bonivart: > # chkcat -e catalog.ftp.df.lth.se_pub_csw_current_sparc_5.10 > > ERROR! 7 fields instead of normal 8. [apr 1.4.2,REV=2010.04.19 CSWapr > apr-1.4.2,REV=2010.04.19-SunOS5.9-sparc-CSW.pkg.gz > 44cfa96279fed78d7c30a4832b462368 374061 none] > > ERROR! 7 fields instead of normal 8. [pca 20100514.01,REV=2010.05.17 > CSWpca pca-20100514.01,REV=2010.05.17-SunOS5.9-all-CSW.pkg.gz > b7fd6559c664c37e693e1e6e9dff4a97 71738 none] > > ERROR! 7 fields instead of normal 8. [phpldapadmin > 1.2.0.5,REV=2010.05.17 CSWphpldapadmin > phpldapadmin-1.2.0.5,REV=2010.05.17-SunOS5.9-all-CSW.pkg.gz > fa2cb964a1684128cd6d8de769486985 1378475 none] > > ERROR! 7 fields instead of normal 8. [sunx11_devel 1.0,REV=2010.05.17 > CSWsunx11devel sunx11_devel-1.0,REV=2010.05.17-SunOS5.9-all-CSW.pkg.gz > 0c354320155896604a61a72d3435b7ae 7358 none] > > ERROR! 7 fields instead of normal 8. [tmux 1.2,REV=2010.05.17 CSWtmux > tmux-1.2,REV=2010.05.17-SunOS5.9-sparc-CSW.pkg.gz > 145351cf6186fdcadcd169b66387f72f 214091 none] > > # digest -a md5 catalog.ftp.df.lth.se_pub_csw_current_sparc_5.10 > 3291702371e4b3654d610aad9a72afd6 Hugh? I thought chkcat was now part of the release process?? Best regards -- Dago From phil at bolthole.com Tue May 18 15:35:20 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 18 May 2010 06:35:20 -0700 Subject: [csw-maintainers] Catalog broken In-Reply-To: <7BCD4E9E-F951-4FAB-8DFE-881B4AB3337D@opencsw.org> References: <7BCD4E9E-F951-4FAB-8DFE-881B4AB3337D@opencsw.org> Message-ID: > Hugh? I thought chkcat was now part of the release process?? > Peter must have this complaint automated. otherwise , surely, he would not be complaining about a catalog change he's been bugging me to make for the last few MONTHS :) From maciej at opencsw.org Tue May 18 18:56:55 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 18 May 2010 17:56:55 +0100 Subject: [csw-maintainers] Catalog broken In-Reply-To: <7BCD4E9E-F951-4FAB-8DFE-881B4AB3337D@opencsw.org> References: <7BCD4E9E-F951-4FAB-8DFE-881B4AB3337D@opencsw.org> Message-ID: No dia 18 de Maio de 2010 13:59, Dagobert Michelsen escreveu: > Hugh? I thought chkcat was now part of the release process?? I thought that too. Phil, will you take action to prevent this from happening on the future? What will it be? Maciej From phil at bolthole.com Tue May 18 19:04:00 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 18 May 2010 10:04:00 -0700 Subject: [csw-maintainers] Catalog broken In-Reply-To: References: <7BCD4E9E-F951-4FAB-8DFE-881B4AB3337D@opencsw.org> Message-ID: On Tue, May 18, 2010 at 9:56 AM, Maciej (Matchek) Blizinski wrote: > No dia 18 de Maio de 2010 13:59, Dagobert Michelsen escreveu: >> Hugh? I thought chkcat was now part of the release process?? > > I thought that too. ?Phil, will you take action to prevent this from > happening on the future? ?What will it be? > please read all replies on a thread, before replying to the middle of an email thread From skayser at opencsw.org Tue May 18 19:13:48 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 18 May 2010 19:13:48 +0200 Subject: [csw-maintainers] Catalog broken In-Reply-To: References: <7BCD4E9E-F951-4FAB-8DFE-881B4AB3337D@opencsw.org> Message-ID: <20100518171348.GD27943@sebastiankayser.de> * Philip Brown wrote: > On Tue, May 18, 2010 at 9:56 AM, Maciej (Matchek) Blizinski > wrote: > > No dia 18 de Maio de 2010 13:59, Dagobert Michelsen escreveu: > >> Hugh? I thought chkcat was now part of the release process?? > > > > I thought that too. ?Phil, will you take action to prevent this from > > happening on the future? ?What will it be? > > > > please read all replies on a thread, before replying to the middle of > an email thread IMHO the question is valid: Peter's chkcat would have thrown errors and you might have noticed that there is some coordination to be done with Peter, no? Sebastian From phil at bolthole.com Tue May 18 19:24:38 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 18 May 2010 10:24:38 -0700 Subject: [csw-maintainers] Catalog broken In-Reply-To: <20100518171348.GD27943@sebastiankayser.de> References: <7BCD4E9E-F951-4FAB-8DFE-881B4AB3337D@opencsw.org> <20100518171348.GD27943@sebastiankayser.de> Message-ID: On Tue, May 18, 2010 at 10:13 AM, Sebastian Kayser wrote: > * Philip Brown wrote: >> On Tue, May 18, 2010 at 9:56 AM, Maciej (Matchek) Blizinski >> wrote: >> > No dia 18 de Maio de 2010 13:59, Dagobert Michelsen escreveu: >> >> Hugh? I thought chkcat was now part of the release process?? >> > >> > I thought that too. ?Phil, will you take action to prevent this from >> > happening on the future? ?What will it be? >> > >> >> please read all replies on a thread, before replying to the middle of >> an email thread > > IMHO the question is valid: Peter's chkcat would have thrown errors and > you might have noticed that there is some coordination to be done with > Peter, no? > ookay, then I will presume you READ my prior email, but did not UNDERSTAND it :) Peter has been bugging me for a format change to the catalog. I just made the change. chkcat is now complaining "the format changed". This is not an error in the catalog, but an error in chkcat not recognizing the new format. From bwalton at opencsw.org Tue May 18 19:34:08 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 18 May 2010 13:34:08 -0400 Subject: [csw-maintainers] Catalog broken In-Reply-To: References: <7BCD4E9E-F951-4FAB-8DFE-881B4AB3337D@opencsw.org> <20100518171348.GD27943@sebastiankayser.de> Message-ID: <1274203974-sup-159@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue May 18 13:24:38 -0400 2010: > Peter has been bugging me for a format change to the catalog. I > just made the change. chkcat is now complaining "the format > changed". This is not an error in the catalog, but an error in > chkcat not recognizing the new format. I thought the error was to do with some packages either missing a field or others having extra. If the format changed, shouldn't all package entries in the catalog have the same amount of fields? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Tue May 18 19:42:03 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 18 May 2010 10:42:03 -0700 Subject: [csw-maintainers] Catalog broken In-Reply-To: <1274203974-sup-159@pinkfloyd.chass.utoronto.ca> References: <7BCD4E9E-F951-4FAB-8DFE-881B4AB3337D@opencsw.org> <20100518171348.GD27943@sebastiankayser.de> <1274203974-sup-159@pinkfloyd.chass.utoronto.ca> Message-ID: On Tue, May 18, 2010 at 10:34 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Tue May 18 13:24:38 -0400 2010: > >> Peter has been bugging me for a format change to the catalog. ?I >> just made the change. ?chkcat is now complaining "the format >> changed". ?This is not an error in the catalog, but an error in >> chkcat not recognizing the new format. > > I thought the error was to do with some packages either missing a > field or others having extra. ?If the format changed, shouldn't all > package entries in the catalog have the same amount of fields? > not neccessarily. From bwalton at opencsw.org Tue May 18 19:44:12 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 18 May 2010 13:44:12 -0400 Subject: [csw-maintainers] Catalog broken In-Reply-To: References: <7BCD4E9E-F951-4FAB-8DFE-881B4AB3337D@opencsw.org> <20100518171348.GD27943@sebastiankayser.de> <1274203974-sup-159@pinkfloyd.chass.utoronto.ca> Message-ID: <1274204584-sup-9543@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue May 18 13:42:03 -0400 2010: > > I thought the error was to do with some packages either missing a > > field or others having extra. ?If the format changed, shouldn't all > > package entries in the catalog have the same amount of fields? > > > > not neccessarily. So tools need to be aware that a line with X fields is the old format and (X + 1) is the new? This is doable, but wouldn't it be nicer if all the packages were updated to include the new info? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Tue May 18 19:48:03 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 18 May 2010 10:48:03 -0700 Subject: [csw-maintainers] Catalog broken In-Reply-To: <1274204584-sup-9543@pinkfloyd.chass.utoronto.ca> References: <7BCD4E9E-F951-4FAB-8DFE-881B4AB3337D@opencsw.org> <20100518171348.GD27943@sebastiankayser.de> <1274203974-sup-159@pinkfloyd.chass.utoronto.ca> <1274204584-sup-9543@pinkfloyd.chass.utoronto.ca> Message-ID: On Tue, May 18, 2010 at 10:44 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Tue May 18 13:42:03 -0400 2010: > >> > I thought the error was to do with some packages either missing a >> > field or others having extra. ?If the format changed, shouldn't all >> > package entries in the catalog have the same amount of fields? >> > >> >> not neccessarily. > > So tools need to be aware that a line with X fields is the old format > and (X + 1) is the new? ?This is doable, but wouldn't it be nicer if > all the packages were updated to include the new info? > nicer for tool writers? perhaps :) but backward compatibility is something that tool writers need to now deal with, since we have older formats for 'stable'. so, not really. consider it "forced incentive" :-D PS: Oi! How about that xrender package that everyone's waiting on, instead of faffing about with catalog formats? ;-) From bonivart at opencsw.org Tue May 18 20:47:25 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 18 May 2010 20:47:25 +0200 Subject: [csw-maintainers] Catalog broken In-Reply-To: References: <7BCD4E9E-F951-4FAB-8DFE-881B4AB3337D@opencsw.org> Message-ID: On Tue, May 18, 2010 at 3:35 PM, Philip Brown wrote: >> Hugh? I thought chkcat was now part of the release process?? >> > > Peter must have this complaint automated. otherwise , surely, he would > not be complaining about a catalog change he's been bugging me to make > for the last few MONTHS :) I have never asked you to make the catalog into 7 fields. I suggest you read the output of chkcat I posted first in this thread. How do explain that one field is missing when they were supposed to have one extra field? -- /peter From phil at bolthole.com Tue May 18 21:28:27 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 18 May 2010 12:28:27 -0700 Subject: [csw-maintainers] Catalog broken In-Reply-To: References: <7BCD4E9E-F951-4FAB-8DFE-881B4AB3337D@opencsw.org> Message-ID: On Tue, May 18, 2010 at 11:47 AM, Peter Bonivart wrote: > On Tue, May 18, 2010 at 3:35 PM, Philip Brown wrote: >>> Hugh? I thought chkcat was now part of the release process?? >>> >> >> Peter must have this complaint automated. otherwise , surely, he would >> not be complaining about a catalog change he's been bugging me to make >> for the last few MONTHS :) > > I have never asked you to make the catalog into 7 fields. I suggest > you read the output of chkcat I posted first in this t pposed to have one > extra field? > Wooops! sorry about that... i read it as complaining about an extra field. temporary dyslexia? :-} things updated, and on the way out. From rupert at opencsw.org Wed May 19 06:07:52 2010 From: rupert at opencsw.org (rupert THURNER) Date: Wed, 19 May 2010 06:07:52 +0200 Subject: [csw-maintainers] apr cannot be compiled any more if apr is installed on the buildfarm Message-ID: apr has a simple recipe to compile. now, as apr is installed on the buildfarm as well, an installed older version seems to disturb the build of the newer. i am wondering 1. how other projects, like debian, etc, handle this situation? do they always start with a clean environment to have no interferences? 2. if it is just the apache related things (apr, serf, ...) have this problem, or if its more general. rupert. From phil at bolthole.com Wed May 19 06:21:39 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 18 May 2010 21:21:39 -0700 Subject: [csw-maintainers] apr cannot be compiled any more if apr is installed on the buildfarm In-Reply-To: References: Message-ID: this sort of thing has been known to happen, and it is perfectly acceptible to ask that older versions of a package be removed for a fixed timeperiod for recompiling and to answer your side question: most decently written software does not have this problem On Tuesday, May 18, 2010, rupert THURNER wrote: > apr has a simple recipe to compile. now, as apr is installed on the > buildfarm as well, an installed older version seems to disturb the > build of the newer. i am wondering > > 1. how other projects, like debian, etc, handle this situation? > ? ?do they always start with a clean environment to have no interferences? > 2. if it is just the apache related things (apr, serf, ...) have this > ? ?problem, or if its more general. > From dam at opencsw.org Wed May 19 10:41:47 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 19 May 2010 10:41:47 +0200 Subject: [csw-maintainers] Catalog broken In-Reply-To: References: <7BCD4E9E-F951-4FAB-8DFE-881B4AB3337D@opencsw.org> Message-ID: Hi Phil, Am 18.05.2010 um 21:28 schrieb Philip Brown: > On Tue, May 18, 2010 at 11:47 AM, Peter Bonivart > wrote: >> On Tue, May 18, 2010 at 3:35 PM, Philip Brown >> wrote: >>>> Hugh? I thought chkcat was now part of the release process?? >>> >>> Peter must have this complaint automated. otherwise , surely, he >>> would >>> not be complaining about a catalog change he's been bugging me to >>> make >>> for the last few MONTHS :) >> >> I have never asked you to make the catalog into 7 fields. I suggest >> you read the output of chkcat I posted first in this t > pposed to have one >> extra field? > > Wooops! sorry about that... i read it as complaining about an extra > field. temporary dyslexia? :-} > > things updated, and on the way out. That means you do have mandatory chkcat in the catalog release process but misinterpreted its output? Best regards -- Dago From maciej at opencsw.org Wed May 19 12:00:38 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 19 May 2010 11:00:38 +0100 Subject: [csw-maintainers] Two versions of the alternatives package in the package directory Message-ID: This command: ls -l /export/mirror/opencsw/unstable/sparc/5.9/alter* ...shows 2 packages: alternatives-1.0,REV=2009.10.17-SunOS5.9-all-CSW.pkg.gz alternatives-1.3.30c,REV=2010.02.18-SunOS5.8-sparc-CSW.pkg.gz Is there a reason for both packages to be there? From phil at bolthole.com Wed May 19 18:48:09 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 19 May 2010 09:48:09 -0700 Subject: [csw-maintainers] Two versions of the alternatives package in the package directory In-Reply-To: References: Message-ID: On Wed, May 19, 2010 at 3:00 AM, Maciej (Matchek) Blizinski wrote: > This command: > > ls -l /export/mirror/opencsw/unstable/sparc/5.9/alter* > > ...shows 2 packages: > > alternatives-1.0,REV=2009.10.17-SunOS5.9-all-CSW.pkg.gz > alternatives-1.3.30c,REV=2010.02.18-SunOS5.8-sparc-CSW.pkg.gz > > Is there a reason for both packages to be there? not really. they're currently kinda like .. erm.. woodshavings :) the important thing is that the older one is not in the catalog. my normal mechanisms are gated by chkpkg. which dont like the new format. so I'm doing a bit uglier pushes for now. the more manual pushes, dont delete older files. From phil at bolthole.com Wed May 19 18:48:57 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 19 May 2010 09:48:57 -0700 Subject: [csw-maintainers] Catalog broken In-Reply-To: References: <7BCD4E9E-F951-4FAB-8DFE-881B4AB3337D@opencsw.org> Message-ID: On Wed, May 19, 2010 at 1:41 AM, Dagobert Michelsen wrote: > > > That means you do have mandatory chkcat in the catalog release process > but misinterpreted its output? > yup From bonivart at opencsw.org Thu May 20 10:37:34 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 20 May 2010 10:37:34 +0200 Subject: [csw-maintainers] Catalog broken In-Reply-To: References: <7BCD4E9E-F951-4FAB-8DFE-881B4AB3337D@opencsw.org> Message-ID: On Wed, May 19, 2010 at 6:48 PM, Philip Brown wrote: > On Wed, May 19, 2010 at 1:41 AM, Dagobert Michelsen wrote: >> >> That means you do have mandatory chkcat in the catalog release process >> but misinterpreted its output? > > yup There's a new version that considers anything less than 8 or more than 9 fields as an error. I have removed the format option since we now have a mix of 8 and 9 fields in the catalogs. http://pkgutil.svn.sourceforge.net/viewvc/pkgutil/trunk/chkcat?revision=254 -- /peter From maciej at opencsw.org Thu May 20 17:40:03 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 20 May 2010 16:40:03 +0100 Subject: [csw-maintainers] Problems compiling ctypes on Solaris x86 Message-ID: The ctypes Python module compiles on sparc, but not on x86. The error message is: "build/temp.solaris-2.9-i86pc-2.6/libffi/include/ffitarget.h", line 67: undefined symbol: FFI_DEFAULT_ABI pkg-config seems to be doing the right thing: > pkg-config --cflags-only-I libffi -I/opt/csw/lib/libffi-3.0.8/include I'm not sure how does ffitarget.h end up in the build/temp.solaris-2.9-i86pc-2.6/libffi/include, but these two are exactly the same: work/solaris9-i386/build-isa-i386/Python-2.6.5/build/temp.solaris-2.9-i86pc-2.6/libffi/include/ffitarget.h /opt/csw/lib/libffi-3.0.8/include/ffitarget.h ...so I conclude the Python build system makes a copy. So why does it error out? An unfortunate combination of flags perhaps? Is this a known problem with libffi? Maciej From skayser at opencsw.org Fri May 21 17:53:16 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 21 May 2010 17:53:16 +0200 Subject: [csw-maintainers] User reported build problems with gcc4.3, Sun ld, and libiconv In-Reply-To: <20100521124305.3B2BFD28@mail.opencsw.org> References: <20100521124305.3B2BFD28@mail.opencsw.org> Message-ID: <20100521155315.GJ27943@sebastiankayser.de> Greetings, I just received this build failure report from a user trying to build libiconv with gcc4.3. Has someone seen an error like this before? Further, are there any general known issues for our gcc4.3 (i vaguely remember someone mentioning something). * david.kirkby at onetel.net wrote: > libtool: install: /usr/bin/ginstall -c -m 644 .libs/libcharset.so.1.0.0 /tmp/iconv-1.13.1.p2/src/lib/libcharset.so.1.0.0 > libtool: install: (cd /tmp/iconv-1.13.1.p2/src/lib && { ln -s -f libcharset.so.1.0.0 libcharset.so.1 || { rm -f libcharset.so.1 && ln -s libcharset.so.1.0.0 libcharset.so.1; }; }) > libtool: install: (cd /tmp/iconv-1.13.1.p2/src/lib && { ln -s -f libcharset.so.1.0.0 libcharset.so || { rm -f libcharset.so && ln -s libcharset.so.1.0.0 libcharset.so; }; }) > libtool: install: chmod +x /tmp/iconv-1.13.1.p2/src/lib/libcharset.so.1.0.0 > libtool: install: /usr/bin/ginstall -c -m 644 .libs/libcharset.lai /tmp/iconv-1.13.1.p2/src/lib/libcharset.la > libtool: install: /usr/bin/ginstall -c -m 644 .libs/libcharset.a /tmp/iconv-1.13.1.p2/src/lib/libcharset.a > libtool: install: chmod 644 /tmp/iconv-1.13.1.p2/src/lib/libcharset.a > libtool: install: ranlib /tmp/iconv-1.13.1.p2/src/lib/libcharset.a > libtool: install: warning: remember to run `libtool --finish /usr/local/lib' > test -f /tmp/iconv-1.13.1.p2/src/lib/charset.alias && orig=/tmp/iconv-1.13.1.p2/src/lib/charset.alias \ > || orig=charset.alias; \ > sed -f ref-add.sed $orig > /tmp/iconv-1.13.1.p2/src/lib/t-charset.alias; \ > /usr/bin/ginstall -c -m 644 /tmp/iconv-1.13.1.p2/src/lib/t-charset.alias /tmp/iconv-1.13.1.p2/src/lib/charset.alias; \ > rm -f /tmp/iconv-1.13.1.p2/src/lib/t-charset.alias > make[2]: Leaving directory `/tmp/iconv-1.13.1.p2/src/libcharset/lib' > /bin/sh ./build-aux/mkinstalldirs /tmp/iconv-1.13.1.p2/src/lib > /usr/bin/ginstall -c -m 644 include/libcharset.h /tmp/iconv-1.13.1.p2/src/lib/libcharset.h > /usr/bin/ginstall -c -m 644 include/localcharset.h.inst /tmp/iconv-1.13.1.p2/src/lib/localcharset.h > make[1]: Leaving directory `/tmp/iconv-1.13.1.p2/src/libcharset' > cd lib && make all > make[1]: Entering directory `/tmp/iconv-1.13.1.p2/src/lib' > /bin/sh ../libtool --mode=compile gcc -I. -I. -I../include -I./../include -I.. -I./.. -g -O2 -fvisibility=hidden -fPIC -DLIBDIR=\"/usr/local/lib\" -DBUILDING_LIBICONV -DBUILDING_DLL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/usr/local/lib\" -DNO_XMALLOC -Dset_relocation_prefix=libiconv_set_relocation_prefix -Drelocate=libiconv_relocate -DHAVE_CONFIG_H -c ./iconv.c > libtool: compile: gcc -I. -I. -I../include -I./../include -I.. -I./.. -g -O2 -fvisibility=hidden -fPIC "-DLIBDIR=\"/usr/local/lib\"" -DBUILDING_LIBICONV -DBUILDING_DLL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY "-DINSTALLDIR=\"/usr/local/lib\"" -DNO_XMALLOC -Dset_relocation_prefix=libiconv_set_relocation_prefix -Drelocate=libiconv_relocate -DHAVE_CONFIG_H -c ./iconv.c -fPIC -DPIC -o .libs/iconv.o > lib/aliases_syssolaris.gperf: In function ?aliases_lookup?: > lib/aliases_syssolaris.gperf:389: warning: visibility attribute not supported in this configuration; ignored > /bin/sh ../libtool --mode=compile gcc -I. -I. -I../include -I./../include -I.. -I./.. -g -O2 -fvisibility=hidden -fPIC -DLIBDIR=\"/usr/local/lib\" -DBUILDING_LIBICONV -DBUILDING_DLL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/usr/local/lib\" -DNO_XMALLOC -Dset_relocation_prefix=libiconv_set_relocation_prefix -Drelocate=libiconv_relocate -DHAVE_CONFIG_H -c ./../libcharset/lib/localcharset.c > libtool: compile: gcc -I. -I. -I../include -I./../include -I.. -I./.. -g -O2 -fvisibility=hidden -fPIC "-DLIBDIR=\"/usr/local/lib\"" -DBUILDING_LIBICONV -DBUILDING_DLL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY "-DINSTALLDIR=\"/usr/local/lib\"" -DNO_XMALLOC -Dset_relocation_prefix=libiconv_set_relocation_prefix -Drelocate=libiconv_relocate -DHAVE_CONFIG_H -c ./../libcharset/lib/localcharset.c -fPIC -DPIC -o .libs/localcharset.o > ./../libcharset/lib/localcharset.c: In function ?locale_charset?: > ./../libcharset/lib/localcharset.c:500: warning: visibility attribute not supported in this configuration; ignored > /bin/sh ../libtool --mode=compile gcc -I. -I. -I../include -I./../include -I.. -I./.. -g -O2 -fvisibility=hidden -fPIC -DLIBDIR=\"/usr/local/lib\" -DBUILDING_LIBICONV -DBUILDING_DLL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/usr/local/lib\" -DNO_XMALLOC -Dset_relocation_prefix=libiconv_set_relocation_prefix -Drelocate=libiconv_relocate -DHAVE_CONFIG_H -c ./relocatable.c > libtool: compile: gcc -I. -I. -I../include -I./../include -I.. -I./.. -g -O2 -fvisibility=hidden -fPIC "-DLIBDIR=\"/usr/local/lib\"" -DBUILDING_LIBICONV -DBUILDING_DLL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY "-DINSTALLDIR=\"/usr/local/lib\"" -DNO_XMALLOC -Dset_relocation_prefix=libiconv_set_relocation_prefix -Drelocate=libiconv_relocate -DHAVE_CONFIG_H -c ./relocatable.c -fPIC -DPIC -o .libs/relocatable.o > ./relocatable.c: In function ?libiconv_relocate?: > ./relocatable.c:466: warning: visibility attribute not supported in this configuration; ignored > /bin/sh ../libtool --mode=link gcc -g -O2 -fvisibility=hidden -fPIC -o libiconv.la -rpath /usr/local/lib -version-info 7:0:5 -no-undefined iconv.lo localcharset.lo relocatable.lo > libtool: link: gcc -shared -Wl,-z -Wl,text -Wl,-h -Wl,libiconv.so.2 -o .libs/libiconv.so.2.5.0 .libs/iconv.o .libs/localcharset.o .libs/relocatable.o -lc > Text relocation remains referenced > against symbol offset in file > aliases_lookup 0x125c6 .libs/iconv.o > aliases_lookup 0x12b04 .libs/iconv.o > ld: fatal: relocations remain against allocatable but non-writable sections > collect2: ld returned 1 exit status > make[1]: *** [libiconv.la] Error 1 > make[1]: Leaving directory `/tmp/iconv-1.13.1.p2/src/lib' > make: *** [all] Error 2 Sun studio is not an option for him as he needs to build a full stack on top of it which contains a massively GNUisms infested software. If someone can help him out, David is on CC. Thanks Sebastian From Murray.Jensen at csiro.au Sat May 22 06:08:53 2010 From: Murray.Jensen at csiro.au (Murray.Jensen at csiro.au) Date: Sat, 22 May 2010 14:08:53 +1000 Subject: [csw-maintainers] User reported build problems with gcc4.3, Sun ld, and libiconv In-Reply-To: Your message of "Sat, 22 May 2010 01:53:16 +1000" <20100521155315.GJ27943@sebastiankayser.de> Message-ID: <30703.1274501333@midgard.cmse.csiro.au> On Sat, 22 May 2010 01:53:16 +1000, Sebastian Kayser writes: >> Text relocation remains referenced >> against symbol offset in file ... >Sun studio is not an option for him as he needs to build a full stack on >top of it which contains a massively GNUisms infested software. But it still uses Sun's linker ... when I see this sort of thing I usually try adding "-z defs" to LD_OPTIONS (well actually, I have this as the default now, and only remove it if it causes problems). Cheers! Murray... From rupert at opencsw.org Sat May 22 13:41:14 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 22 May 2010 13:41:14 +0200 Subject: [csw-maintainers] apr-util - searches for libiconv.la - how to use .so ? Message-ID: hi, how could one convince apr-util to not search for libiconv.la, but use what is existing and working? /bin/bash /opt/csw/share/build-1/libtool --silent --mode=link /opt/studio/SOS12/SUNWspro/bin/cc -mt -xO3 -m32 -xarch=v8 -xnorunpath -m32 -xarch=v8 -L/opt/csw/lib -release 1 -module -rpath /opt/csw/lib/apr-util-1 -o dbd/apr_dbd_freetds.la dbd/apr_dbd_freetds.lo -lsybdb /opt/csw/bin/ggrep: /opt/csw/lib/libiconv.la: No such file or directory /opt/csw/bin/gsed: can't read /opt/csw/lib/libiconv.la: No such file or directory libtool: link: `/opt/csw/lib/libiconv.la' is not a valid libtool archive gmake[4]: *** [dbd/apr_dbd_freetds.la] Error 1 gmake[4]: Leaving directory `/home/rupert/mgar/pkg/apr-util/trunk/work/solaris9-sparc/build-isa-sparcv8/apr-util-1.3.9' gmake[3]: *** [all-recursive] Error 1 rupert. From bwalton at opencsw.org Sat May 22 14:26:48 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 22 May 2010 08:26:48 -0400 Subject: [csw-maintainers] apr-util - searches for libiconv.la - how to use .so ? In-Reply-To: References: Message-ID: <1274531028-sup-9935@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Sat May 22 07:41:14 -0400 2010: Hi Rupert, > how could one convince apr-util to not search for libiconv.la, but > use what is existing and working? Have you turned on the 'STRIP_LIBTOOL = 1' option in your GAR recipe? If not, try that first. If it still doesn't work nicely, you'll need a bigger hammer...I've got one recipe where the trick about didn't work and I had to correct it through other means. See the Openjade build recipe here: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/openjade/trunk/Makefile Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From david.kirkby at onetel.net Sat May 22 10:50:59 2010 From: david.kirkby at onetel.net (Dr. David Kirkby) Date: Sat, 22 May 2010 09:50:59 +0100 Subject: [csw-maintainers] User reported build problems with gcc4.3, Sun ld, and libiconv In-Reply-To: <30703.1274501333@midgard.cmse.csiro.au> References: <30703.1274501333@midgard.cmse.csiro.au> Message-ID: <4BF79AF3.2090800@onetel.net> On 05/22/10 05:08 AM, Murray.Jensen at csiro.au wrote: > On Sat, 22 May 2010 01:53:16 +1000, Sebastian Kayser writes: >>> Text relocation remains referenced >>> against symbol offset in file > ... >> Sun studio is not an option for him as he needs to build a full stack on >> top of it which contains a massively GNUisms infested software. > > But it still uses Sun's linker ... when I see this sort of thing I usually > try adding "-z defs" to LD_OPTIONS (well actually, I have this as the default > now, and only remove it if it causes problems). Cheers! > Murray... > Does adding "-z defs" solve the problem, or hide the underlying problem? https://de.opensolaris.org/jive/thread.jspa?threadID=116065&tstart=143 says "The use of -ztext is not your problem --- it's simply allowing the linker to catch the problem, which is that the object iconv.o has relocations against the text segment." I found that changing to gcc 4.4.4 solved the problem. I'd completely overlooked that post above, where I'd commented about 3 months ago that a 4.5.0 snapshot solved the problem too. (The user 'drkirkby' is me). This would appear to be a bug in at least gcc 4.3.4 (what I used) and gcc 4.4.2 (what 'penyuan' used), but which is cleared in 4.4.4 and an earlier 4.5.0 snapshot - I've not tried with the official 4.5.0 Note however 'penyuan' has --with-gnu-ld and -with-ld=/usr/ccs/bin/ld which seems a bit odd. I've no idea how gcc handles that one. Dave From rupert at opencsw.org Sun May 23 13:16:49 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 23 May 2010 13:16:49 +0200 Subject: [csw-maintainers] apr-util - searches for libiconv.la - how to use .so ? In-Reply-To: <1274531028-sup-9935@pinkfloyd.chass.utoronto.ca> References: <1274531028-sup-9935@pinkfloyd.chass.utoronto.ca> Message-ID: On Sat, May 22, 2010 at 14:26, Ben Walton wrote: > Excerpts from rupert THURNER's message of Sat May 22 07:41:14 -0400 2010: > > Hi Rupert, > >> how could one convince apr-util to not search for ?libiconv.la, but >> use what is existing and working? > > Have you turned on the 'STRIP_LIBTOOL = 1' option in your GAR recipe? > If not, try that first. ?If it still doesn't work nicely, you'll need > a bigger hammer...I've got one recipe where the trick about didn't > work and I had to correct it through other means. ?See the Openjade > build recipe here: > https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/openjade/trunk/Makefile > uh ... that looks great! do you know the source of the problem as well, maybe we can notify upstream wo we do not need to work around such things? rupert. From rupert at opencsw.org Sun May 23 14:12:17 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 23 May 2010 14:12:17 +0200 Subject: [csw-maintainers] apr-util - searches for libiconv.la - how to use .so ? In-Reply-To: References: <1274531028-sup-9935@pinkfloyd.chass.utoronto.ca> Message-ID: On Sun, May 23, 2010 at 13:16, rupert THURNER wrote: > On Sat, May 22, 2010 at 14:26, Ben Walton wrote: >> Excerpts from rupert THURNER's message of Sat May 22 07:41:14 -0400 2010: >> >> Hi Rupert, >> >>> how could one convince apr-util to not search for ?libiconv.la, but >>> use what is existing and working? >> >> Have you turned on the 'STRIP_LIBTOOL = 1' option in your GAR recipe? >> If not, try that first. ?If it still doesn't work nicely, you'll need >> a bigger hammer...I've got one recipe where the trick about didn't >> work and I had to correct it through other means. ?See the Openjade >> build recipe here: >> https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/openjade/trunk/Makefile >> > > uh ... that looks great! do you know the source of the problem as > well, maybe we can notify upstream wo we do not need to work around > such things? > > rupert. i searched now for libiconv ... and i cannot find who introduces this :( From bwalton at opencsw.org Sun May 23 14:47:36 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 23 May 2010 08:47:36 -0400 Subject: [csw-maintainers] apr-util - searches for libiconv.la - how to use .so ? In-Reply-To: References: <1274531028-sup-9935@pinkfloyd.chass.utoronto.ca> Message-ID: <1274618791-sup-642@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Sun May 23 07:16:49 -0400 2010: > uh ... that looks great! do you know the source of the problem as > well, maybe we can notify upstream wo we do not need to work around > such things? No, I didn't dig much further than required in order to make it build. The openjade project is pretty much a legacy tool at this point so I didn't think more time was warranted. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert at opencsw.org Mon May 24 22:18:07 2010 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 24 May 2010 22:18:07 +0200 Subject: [csw-maintainers] Fwd: [ccache] solaris compile error In-Reply-To: <4BFADC8F.9080108@rosdahl.net> References: <4BFADC8F.9080108@rosdahl.net> Message-ID: fyi, somebody of you has an idea? ---------- Forwarded message ---------- From: Joel Rosdahl Date: Mon, May 24, 2010 at 22:07 Subject: Re: [ccache] solaris compile error To: "rupert.thurner" Cc: ccache at lists.samba.org On 2010-05-24 21:37, rupert.thurner wrote: > when trying to make a package for http://opencsw.org Thanks! > compiling ccache fails with: > > gmake[3]: Entering directory `/home/rupert/mgar/pkg/ccache/trunk/work/ > solaris9-sparc/build-isa-sparcv8/ccache-3.0pre1' > /opt/studio/SOS12/SUNWspro/bin/cc -xO3 -m32 -xarch=v8 -xnorunpath -O - > I/opt/csw/include -I. -c -o util.o util.c > "util.c", line 68: incomplete struct/union/enum timeval: tv > "util.c", line 71: warning: implicit function declaration: > gettimeofday > > "util.c", line 72: undefined struct/union member: tv_sec > "util.c", line 72: warning: argument #1 is incompatible with > prototype: > ? ? ? ? prototype: pointer to const long : "/usr/include/iso/ > time_iso.h", line 89 > ? ? ? ? argument : pointer to int > [...] I don't have access to a Solaris machine so I can't investigate this myself, but the Solaris man pages I find on the net say that sys/time.h should be included to get a declaration of gettimeofday() and struct timeval. Does your config.h define HAVE_SYS_TIME_H? If not, please check config.log for hints. If HAVE_SYS_TIME_H is defined in config.h, maybe it could be an ordering problem -- does it make any difference if you move the "#include " row further up in the file? > "util.c", line 206: warning: implicit function declaration: mkstemp > "util.c", line 274: warning: implicit function declaration: fchmod > "util.c", line 383: warning: implicit function declaration: > gethostname > "util.c", line 478: warning: implicit function declaration: strdup > [...] > "util.c", line 585: warning: implicit function declaration: lstat > "util.c", line 772: warning: implicit function declaration: realpath > [...] > "util.c", line 943: warning: implicit function declaration: utimes Header files for the above functions are included according to the Solaris man pages I find on the net, so don't see what to do. Anyone else got a clue? -- Joel From dam at opencsw.org Tue May 25 09:53:40 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 25 May 2010 09:53:40 +0200 Subject: [csw-maintainers] apr-util - searches for libiconv.la - how to use .so ? In-Reply-To: References: <1274531028-sup-9935@pinkfloyd.chass.utoronto.ca> Message-ID: Hi Rupert, Am 23.05.2010 um 14:12 schrieb rupert THURNER: > On Sun, May 23, 2010 at 13:16, rupert THURNER > wrote: >> On Sat, May 22, 2010 at 14:26, Ben Walton >> wrote: >>> Excerpts from rupert THURNER's message of Sat May 22 07:41:14 >>> -0400 2010: >>>> how could one convince apr-util to not search for libiconv.la, but >>>> use what is existing and working? >>> >>> Have you turned on the 'STRIP_LIBTOOL = 1' option in your GAR >>> recipe? >>> If not, try that first. If it still doesn't work nicely, you'll >>> need >>> a bigger hammer...I've got one recipe where the trick about didn't >>> work and I had to correct it through other means. See the Openjade >>> build recipe here: >>> https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/openjade/trunk/Makefile >>> >> >> uh ... that looks great! do you know the source of the problem as >> well, maybe we can notify upstream wo we do not need to work around >> such things? > > i searched now for libiconv ... and i cannot find who introduces > this :( Usually this is from some other .la depending on libiconv where the .la has already been stripped. So the upstream notification would be for us to remove the .la from the respective package. As we already have chosen to remove .la files from all new/updated packages and use STRIP_LIBTOOL on problems until everything is clean there is not much gain in finding the exact cause. Just pick a package with .la and start fixing it if you want to help :-) Best regards -- Dago From james at opencsw.org Tue May 25 12:22:14 2010 From: james at opencsw.org (James Lee) Date: Tue, 25 May 2010 10:22:14 GMT Subject: [csw-maintainers] Fwd: [ccache] solaris compile error In-Reply-To: References: <4BFADC8F.9080108@rosdahl.net> Message-ID: <20100525.10221400.3558006443@gyor.oxdrove.co.uk> On 24/05/10, 21:18:07, rupert THURNER wrote regarding [csw-maintainers] Fwd: [ccache] solaris compile error: > ---------- Forwarded message ---------- > From: Joel Rosdahl > Date: Mon, May 24, 2010 at 22:07 > Subject: Re: [ccache] solaris compile error > To: "rupert.thurner" > Cc: ccache at lists.samba.org > > gmake[3]: Entering directory `/home/rupert/mgar/pkg/ccache/trunk/work/ > > solaris9-sparc/build-isa-sparcv8/ccache-3.0pre1' > > /opt/studio/SOS12/SUNWspro/bin/cc -xO3 -m32 -xarch=v8 -xnorunpath -O - > > I/opt/csw/include -I. -c -o util.o util.c > > "util.c", line 68: incomplete struct/union/enum timeval: tv > > "util.c", line 71: warning: implicit function declaration: > > gettimeofday config.h.in defines _XOPEN_SOURCE which is preventing the use of struct timeval tv and gettimeofday(). Try adding "#define __EXTENSIONS__". James. From dam at opencsw.org Tue May 25 12:49:46 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 25 May 2010 12:49:46 +0200 Subject: [csw-maintainers] [csw-buildfarm] get only newest bdb onto buildserver In-Reply-To: References: <1274409984-sup-2309@pinkfloyd.chass.utoronto.ca> Message-ID: <4E118E06-1F10-4A18-BF82-0F32CCCC0504@opencsw.org> Hi Rupert, Am 23.05.2010 um 13:07 schrieb rupert THURNER: > On Sat, May 22, 2010 at 22:37, Dagobert Michelsen > wrote: >> Am 22.05.2010 um 12:09 schrieb rupert THURNER: >>> as there are multiple packages (subversion, openldap i know of) >>> doing >>> this there might be something basically wrong. >>> >>> it seems that /opt/csw/lib gets precedence vs extra libs. having >>> some >>> compatibility stuff in /opt/csw/lib then leads to picking it up. >> >> This looks like a bug in GAR. Please commit everything you have and >> let me >> verify the issue on a specific package known to be working in the >> past, >> like subversion? > > that would be great! i have everything committed. I cannot reproduce the problem. Is this your issue? > current9s% ldd -r svn > /usr/lib/secure/s9_preload.so.1 > libsvn_client-1.so.0 => /opt/csw/lib/svn/libsvn_client-1.so.0 > libsvn_wc-1.so.0 => /opt/csw/lib/svn/libsvn_wc-1.so.0 > libsvn_ra-1.so.0 => /opt/csw/lib/svn/libsvn_ra-1.so.0 > libsvn_diff-1.so.0 => /opt/csw/lib/svn/libsvn_diff-1.so.0 > libsvn_ra_local-1.so.0 => /opt/csw/lib/svn/ > libsvn_ra_local-1.so.0 > libsvn_repos-1.so.0 => /opt/csw/lib/svn/libsvn_repos-1.so.0 > libsvn_fs-1.so.0 => /opt/csw/lib/svn/libsvn_fs-1.so.0 > libsvn_fs_fs-1.so.0 => /opt/csw/lib/svn/libsvn_fs_fs-1.so.0 > libsvn_fs_base-1.so.0 => /opt/csw/lib/svn/ > libsvn_fs_base-1.so.0 > libdb-4.8.so => /opt/csw/bdb48/lib/libdb-4.8.so > libsvn_fs_util-1.so.0 => /opt/csw/lib/svn/ > libsvn_fs_util-1.so.0 > libsvn_ra_svn-1.so.0 => /opt/csw/lib/svn/libsvn_ra_svn-1.so.0 > libsasl2.so.2 => /opt/csw/lib/sparcv8/libsasl2.so.2 > libsvn_ra_neon-1.so.0 => /opt/csw/lib/svn/ > libsvn_ra_neon-1.so.0 > libsvn_ra_serf-1.so.0 => /opt/csw/lib/svn/ > libsvn_ra_serf-1.so.0 > libserf-0.so.0 => /opt/csw/lib/sparcv8/libserf-0.so.0 > libsvn_delta-1.so.0 => /opt/csw/lib/svn/libsvn_delta-1.so.0 > libsvn_subr-1.so.0 => /opt/csw/lib/svn/libsvn_subr-1.so.0 > libintl.so.8 => /opt/csw/lib/sparcv8/libintl.so.8 > libz.so.1 => /opt/csw/lib/sparcv8plus+vis/libz.so.1 > libsqlite3.so.0 => /opt/csw/lib/sparcv8/libsqlite3.so.0 > libaprutil-1.so.0 => /opt/csw/apache2/lib/ > libaprutil-1.so.0 > libldap-2.3.so.0 => /opt/csw/lib/sparcv8/libldap-2.3.so.0 > liblber-2.3.so.0 => /opt/csw/lib/sparcv8/liblber-2.3.so.0 > libexpat.so.1 => /opt/csw/lib/sparcv8/libexpat.so.1 > libiconv.so.2 => /opt/csw/lib/sparcv8/libiconv.so.2 > libapr-1.so.0 => /opt/csw/apache2/lib/libapr-1.so.0 > libuuid.so.1 => /usr/lib/libuuid.so.1 > libsendfile.so.1 => /usr/lib/libsendfile.so.1 > librt.so.1 => /usr/lib/librt.so.1 > libnsl.so.1 => /usr/lib/libnsl.so.1 > libpthread.so.1 => /usr/lib/libpthread.so.1 > libdl.so.1 => /usr/lib/libdl.so.1 > libneon.so.27 => /opt/csw/lib/sparcv8/libneon.so.27 > libsocket.so.1 => /usr/lib/libsocket.so.1 > libthread.so.1 => /usr/lib/libthread.so.1 > libc.so.1 => /usr/lib/libc.so.1 > libdb-4.7.so => /opt/csw/bdb47/lib/libdb-4.7.so ^^^^^^^^^^^^ > libresolv.so.2 => /usr/lib/libresolv.so.2 > libneon.so.26 => /opt/csw/lib/sparcv8/libneon.so.26 > libapr-1.so.0 => /opt/csw/lib/sparcv8/libapr-1.so.0 > libm.so.1 => /usr/lib/libm.so.1 > libssl.so.0.9.8 => /opt/csw/lib/sparcv8plus+vis/ > libssl.so.0.9.8 > libcrypto.so.0.9.8 => /opt/csw/lib/sparcv8plus+vis/ > libcrypto.so.0.9.8 > libsec.so.1 => /usr/lib/libsec.so.1 > libgen.so.1 => /usr/lib/libgen.so.1 > libnet.so => /opt/csw/lib/sparcv8/libnet.so > libaio.so.1 => /usr/lib/libaio.so.1 > libmd5.so.1 => /usr/lib/libmd5.so.1 > libmp.so.2 => /usr/lib/libmp.so.2 > /usr/platform/SUNW,SPARC-Enterprise-T5220/lib/libc_psr.so.1 Everything is alright here: svn is linked against bdb48, the "problem" is that RPATH is /opt/csw/lib and "ldd -r" checks against the library version installed in /opt/csw/lib, and not the newly built one. The fresh library is built correctly against libdb-4.8.so: > current9s% dump -Lv libsvn_fs_base-1.so > > libsvn_fs_base-1.so: > > **** DYNAMIC SECTION INFORMATION **** > .dynamic: > [INDEX] Tag Value > [1] NEEDED libintl.so.8 > [2] NEEDED libsvn_delta-1.so.0 > [3] NEEDED libsvn_subr-1.so.0 > [4] NEEDED libaprutil-1.so.0 > [5] NEEDED libldap-2.3.so.0 > [6] NEEDED liblber-2.3.so.0 > [7] NEEDED libexpat.so.1 > [8] NEEDED libiconv.so.2 > [9] NEEDED libapr-1.so.0 > [10] NEEDED libuuid.so.1 > [11] NEEDED libsendfile.so.1 > [12] NEEDED librt.so.1 > [13] NEEDED libnsl.so.1 > [14] NEEDED libpthread.so.1 > [15] NEEDED libdl.so.1 > [16] NEEDED libdb-4.8.so > [17] NEEDED libsvn_fs_util-1.so.0 > [18] NEEDED libsocket.so.1 > [19] NEEDED libc.so.1 > ... Are there any other issues I can assist? Best regards -- Dago From dam at opencsw.org Tue May 25 12:56:19 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 25 May 2010 12:56:19 +0200 Subject: [csw-maintainers] Fwd: [ccache] solaris compile error In-Reply-To: <20100525.10221400.3558006443@gyor.oxdrove.co.uk> References: <4BFADC8F.9080108@rosdahl.net> <20100525.10221400.3558006443@gyor.oxdrove.co.uk> Message-ID: <2BA3E1EF-8CA6-4F2C-B4FA-77BFD8B09073@opencsw.org> Hi James, Am 25.05.2010 um 12:22 schrieb James Lee: > On 24/05/10, 21:18:07, rupert THURNER wrote > regarding > [csw-maintainers] Fwd: [ccache] solaris compile error: > >> ---------- Forwarded message ---------- >> From: Joel Rosdahl >> Date: Mon, May 24, 2010 at 22:07 >> Subject: Re: [ccache] solaris compile error >> To: "rupert.thurner" >> Cc: ccache at lists.samba.org > > >>> gmake[3]: Entering directory `/home/rupert/mgar/pkg/ccache/trunk/ >>> work/ >>> solaris9-sparc/build-isa-sparcv8/ccache-3.0pre1' >>> /opt/studio/SOS12/SUNWspro/bin/cc -xO3 -m32 -xarch=v8 -xnorunpath - >>> O - >>> I/opt/csw/include -I. -c -o util.o util.c >>> "util.c", line 68: incomplete struct/union/enum timeval: tv >>> "util.c", line 71: warning: implicit function declaration: >>> gettimeofday > > config.h.in defines _XOPEN_SOURCE which is preventing the use of > struct > timeval tv and gettimeofday(). Try adding "#define __EXTENSIONS__". Ah, ok. There are several Makefiles in GAR already using this: > pinentry/trunk/Makefile:EXTRA_CFLAGS = -D__EXTENSIONS__ > pinentry/trunk/Makefile:EXTRA_CXXFLAGS = -D__EXTENSIONS__ There should be no need to patch the source, a define in the Makefile should suffice. Best regards -- Dago From phil at bolthole.com Tue May 25 18:17:12 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 25 May 2010 09:17:12 -0700 Subject: [csw-maintainers] apr-util - searches for libiconv.la - how to use .so ? In-Reply-To: References: <1274531028-sup-9935@pinkfloyd.chass.utoronto.ca> Message-ID: On Tue, May 25, 2010 at 12:53 AM, Dagobert Michelsen wrote: > Usually this is from some other .la depending on libiconv where the .la has > already been stripped. So the upstream notification would be for us to > remove > the .la from the respective package. As we already have chosen to remove > .la files from all new/updated packages and use STRIP_LIBTOOL on problems > until everything is clean there is not much gain in finding the exact > cause. Just pick a package with .la and start fixing it if you want > to help :-) > > Although if you feel particularly motivated to "scratch what itches YOU", Rupert, feel free to ask for pointers tracking the culprit down if you need them :) From rupert at opencsw.org Wed May 26 19:54:11 2010 From: rupert at opencsw.org (rupert THURNER) Date: Wed, 26 May 2010 19:54:11 +0200 Subject: [csw-maintainers] Fwd: [ccache] solaris compile error In-Reply-To: <20100525.10221400.3558006443@gyor.oxdrove.co.uk> References: <4BFADC8F.9080108@rosdahl.net> <20100525.10221400.3558006443@gyor.oxdrove.co.uk> Message-ID: great, that worked. do we have a trick to make the test script work as well? it contains "pwd" (which gives "trunk") to call the freshly compiled ccache (which is deep in th ework directory), so the result is: gmake[3]: Entering directory `/home/rupert/mgar/pkg/ccache/trunk/work/solaris9-sparc/build-isa-sparcv8/ccache-3.0pre1' CC='/opt/studio/SOS12/SUNWspro/bin/cc' ./test.sh starting testsuite base ./test.sh: /home/rupert/mgar/pkg/ccache/trunk/ccache: not found SUITE: "base", TEST: "" - Expected "cache hit (preprocessed)" to be 0, got ./test.sh: /home/rupert/mgar/pkg/ccache/trunk/ccache: not found TEST FAILED On Tue, May 25, 2010 at 12:22, James Lee wrote: > On 24/05/10, 21:18:07, rupert THURNER wrote regarding > [csw-maintainers] Fwd: [ccache] solaris compile error: > >> ---------- Forwarded message ---------- >> From: Joel Rosdahl >> Date: Mon, May 24, 2010 at 22:07 >> Subject: Re: [ccache] solaris compile error >> To: "rupert.thurner" >> Cc: ccache at lists.samba.org > > >> > gmake[3]: Entering directory `/home/rupert/mgar/pkg/ccache/trunk/work/ >> > solaris9-sparc/build-isa-sparcv8/ccache-3.0pre1' >> > /opt/studio/SOS12/SUNWspro/bin/cc -xO3 -m32 -xarch=v8 -xnorunpath -O - >> > I/opt/csw/include -I. -c -o util.o util.c >> > "util.c", line 68: incomplete struct/union/enum timeval: tv >> > "util.c", line 71: warning: implicit function declaration: >> > gettimeofday > > config.h.in defines _XOPEN_SOURCE which is preventing the use of struct > timeval tv and gettimeofday(). ?Try adding "#define __EXTENSIONS__". > > > > James. > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From skayser at opencsw.org Wed May 26 20:28:50 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 26 May 2010 20:28:50 +0200 Subject: [csw-maintainers] Fwd: [ccache] solaris compile error In-Reply-To: References: <4BFADC8F.9080108@rosdahl.net> <20100525.10221400.3558006443@gyor.oxdrove.co.uk> Message-ID: <20100526182850.GP27943@sebastiankayser.de> * rupert THURNER wrote: > great, that worked. do we have a trick to make the test script work as > well? it contains "pwd" (which gives "trunk") to call the freshly > compiled ccache (which is deep in th ework directory), so the result > is: > > gmake[3]: Entering directory > `/home/rupert/mgar/pkg/ccache/trunk/work/solaris9-sparc/build-isa-sparcv8/ccache-3.0pre1' > CC='/opt/studio/SOS12/SUNWspro/bin/cc' ./test.sh > starting testsuite base > ./test.sh: /home/rupert/mgar/pkg/ccache/trunk/ccache: not found > SUITE: "base", TEST: "" - Expected "cache hit (preprocessed)" to be 0, got > ./test.sh: /home/rupert/mgar/pkg/ccache/trunk/ccache: not found > TEST FAILED I get the slight feeling that all those answers here seduce you to give up troubleshooting yourself ... I bet you could have figured this out too. * test.sh is using $PWD (if set, otherwise falls back to `pwd`) * "gmake -C test" doesn't alter the $PWD which is set by bash and still points to trunk/, so test.sh is using $PWD and thereby trunk/ which is wrong * When you unset $PWD for the test phase, test.sh will fall back to `pwd` which determines the proper directory $ svn diff Index: Makefile =================================================================== --- Makefile (revision 10000) +++ Makefile (working copy) @@ -22,4 +22,8 @@ CONFIGURE_ARGS = $(DIRPATHS) EXTRA_CFLAGS = -D__EXTENSIONS__ +# Unset $PWD (which isn't changed on gmake -C) so that test.sh uses `pwd` +PWD= +TEST_EXPORTS=PWD + include gar/category.mk Sebastian From rupert at opencsw.org Wed May 26 20:30:24 2010 From: rupert at opencsw.org (rupert THURNER) Date: Wed, 26 May 2010 20:30:24 +0200 Subject: [csw-maintainers] [csw-buildfarm] get only newest bdb onto buildserver In-Reply-To: <4E118E06-1F10-4A18-BF82-0F32CCCC0504@opencsw.org> References: <1274409984-sup-2309@pinkfloyd.chass.utoronto.ca> <4E118E06-1F10-4A18-BF82-0F32CCCC0504@opencsw.org> Message-ID: On Tue, May 25, 2010 at 12:49, Dagobert Michelsen wrote: > Hi Rupert, > > Am 23.05.2010 um 13:07 schrieb rupert THURNER: >> >> On Sat, May 22, 2010 at 22:37, Dagobert Michelsen wrote: >>> >>> Am 22.05.2010 um 12:09 schrieb rupert THURNER: >>>> >>>> as there are multiple packages (subversion, openldap i know of) doing >>>> this there might be something basically wrong. >>>> >>>> it seems that /opt/csw/lib gets precedence vs extra libs. having some >>>> compatibility stuff in /opt/csw/lib then leads to picking it up. >>> >>> This looks like a bug in GAR. Please commit everything you have and let >>> me >>> verify the issue on a specific package known to be working in the past, >>> like subversion? >> >> that would be great! i have everything committed. > > I cannot reproduce the problem. Is this your issue? > >> current9s% ldd -r svn >> ? ? ? ?/usr/lib/secure/s9_preload.so.1 >> ? ? ? ?libsvn_client-1.so.0 => ?/opt/csw/lib/svn/libsvn_client-1.so.0 >> ? ? ? ?libsvn_wc-1.so.0 => ? ? ?/opt/csw/lib/svn/libsvn_wc-1.so.0 >> ? ? ? ?libsvn_ra-1.so.0 => ? ? ?/opt/csw/lib/svn/libsvn_ra-1.so.0 >> ? ? ? ?libsvn_diff-1.so.0 => ? ?/opt/csw/lib/svn/libsvn_diff-1.so.0 >> ? ? ? ?libsvn_ra_local-1.so.0 => >> ?/opt/csw/lib/svn/libsvn_ra_local-1.so.0 >> ? ? ? ?libsvn_repos-1.so.0 => ? /opt/csw/lib/svn/libsvn_repos-1.so.0 >> ? ? ? ?libsvn_fs-1.so.0 => ? ? ?/opt/csw/lib/svn/libsvn_fs-1.so.0 >> ? ? ? ?libsvn_fs_fs-1.so.0 => ? /opt/csw/lib/svn/libsvn_fs_fs-1.so.0 >> ? ? ? ?libsvn_fs_base-1.so.0 => >> /opt/csw/lib/svn/libsvn_fs_base-1.so.0 >> ? ? ? ?libdb-4.8.so => ?/opt/csw/bdb48/lib/libdb-4.8.so >> ? ? ? ?libsvn_fs_util-1.so.0 => >> /opt/csw/lib/svn/libsvn_fs_util-1.so.0 >> ? ? ? ?libsvn_ra_svn-1.so.0 => ?/opt/csw/lib/svn/libsvn_ra_svn-1.so.0 >> ? ? ? ?libsasl2.so.2 => ? ? ? ? /opt/csw/lib/sparcv8/libsasl2.so.2 >> ? ? ? ?libsvn_ra_neon-1.so.0 => >> /opt/csw/lib/svn/libsvn_ra_neon-1.so.0 >> ? ? ? ?libsvn_ra_serf-1.so.0 => >> /opt/csw/lib/svn/libsvn_ra_serf-1.so.0 >> ? ? ? ?libserf-0.so.0 => ? ? ? ?/opt/csw/lib/sparcv8/libserf-0.so.0 >> ? ? ? ?libsvn_delta-1.so.0 => ? /opt/csw/lib/svn/libsvn_delta-1.so.0 >> ? ? ? ?libsvn_subr-1.so.0 => ? ?/opt/csw/lib/svn/libsvn_subr-1.so.0 >> ? ? ? ?libintl.so.8 => ?/opt/csw/lib/sparcv8/libintl.so.8 >> ? ? ? ?libz.so.1 => ? ? /opt/csw/lib/sparcv8plus+vis/libz.so.1 >> ? ? ? ?libsqlite3.so.0 => ? ? ? /opt/csw/lib/sparcv8/libsqlite3.so.0 >> ? ? ? ?libaprutil-1.so.0 => ? ? /opt/csw/apache2/lib/libaprutil-1.so.0 >> ? ? ? ?libldap-2.3.so.0 => ? ? ?/opt/csw/lib/sparcv8/libldap-2.3.so.0 >> ? ? ? ?liblber-2.3.so.0 => ? ? ?/opt/csw/lib/sparcv8/liblber-2.3.so.0 >> ? ? ? ?libexpat.so.1 => ? ? ? ? /opt/csw/lib/sparcv8/libexpat.so.1 >> ? ? ? ?libiconv.so.2 => ? ? ? ? /opt/csw/lib/sparcv8/libiconv.so.2 >> ? ? ? ?libapr-1.so.0 => ? ? ? ? /opt/csw/apache2/lib/libapr-1.so.0 >> ? ? ? ?libuuid.so.1 => ?/usr/lib/libuuid.so.1 >> ? ? ? ?libsendfile.so.1 => ? ? ?/usr/lib/libsendfile.so.1 >> ? ? ? ?librt.so.1 => ? ?/usr/lib/librt.so.1 >> ? ? ? ?libnsl.so.1 => ? /usr/lib/libnsl.so.1 >> ? ? ? ?libpthread.so.1 => ? ? ? /usr/lib/libpthread.so.1 >> ? ? ? ?libdl.so.1 => ? ?/usr/lib/libdl.so.1 >> ? ? ? ?libneon.so.27 => ? ? ? ? /opt/csw/lib/sparcv8/libneon.so.27 >> ? ? ? ?libsocket.so.1 => ? ? ? ?/usr/lib/libsocket.so.1 >> ? ? ? ?libthread.so.1 => ? ? ? ?/usr/lib/libthread.so.1 >> ? ? ? ?libc.so.1 => ? ? /usr/lib/libc.so.1 >> ? ? ? ?libdb-4.7.so => ?/opt/csw/bdb47/lib/libdb-4.7.so > > ^^^^^^^^^^^^ > >> ? ? ? ?libresolv.so.2 => ? ? ? ?/usr/lib/libresolv.so.2 >> ? ? ? ?libneon.so.26 => ? ? ? ? /opt/csw/lib/sparcv8/libneon.so.26 >> ? ? ? ?libapr-1.so.0 => ? ? ? ? /opt/csw/lib/sparcv8/libapr-1.so.0 >> ? ? ? ?libm.so.1 => ? ? /usr/lib/libm.so.1 >> ? ? ? ?libssl.so.0.9.8 => >> /opt/csw/lib/sparcv8plus+vis/libssl.so.0.9.8 >> ? ? ? ?libcrypto.so.0.9.8 => >> ?/opt/csw/lib/sparcv8plus+vis/libcrypto.so.0.9.8 >> ? ? ? ?libsec.so.1 => ? /usr/lib/libsec.so.1 >> ? ? ? ?libgen.so.1 => ? /usr/lib/libgen.so.1 >> ? ? ? ?libnet.so => ? ? /opt/csw/lib/sparcv8/libnet.so >> ? ? ? ?libaio.so.1 => ? /usr/lib/libaio.so.1 >> ? ? ? ?libmd5.so.1 => ? /usr/lib/libmd5.so.1 >> ? ? ? ?libmp.so.2 => ? ?/usr/lib/libmp.so.2 >> ? ? ? ?/usr/platform/SUNW,SPARC-Enterprise-T5220/lib/libc_psr.so.1 > > Everything is alright here: svn is linked against bdb48, the "problem" is > that > RPATH is /opt/csw/lib and "ldd -r" checks against the library version > installed > in /opt/csw/lib, and not the newly built one. The fresh library is built > correctly > against libdb-4.8.so: > >> current9s% dump -Lv libsvn_fs_base-1.so >> >> libsvn_fs_base-1.so: >> >> ?**** DYNAMIC SECTION INFORMATION **** >> .dynamic: >> [INDEX] Tag ? ? ? ? Value >> [1] ? ? NEEDED ? ? ? ? ?libintl.so.8 >> [2] ? ? NEEDED ? ? ? ? ?libsvn_delta-1.so.0 >> [3] ? ? NEEDED ? ? ? ? ?libsvn_subr-1.so.0 >> [4] ? ? NEEDED ? ? ? ? ?libaprutil-1.so.0 >> [5] ? ? NEEDED ? ? ? ? ?libldap-2.3.so.0 >> [6] ? ? NEEDED ? ? ? ? ?liblber-2.3.so.0 >> [7] ? ? NEEDED ? ? ? ? ?libexpat.so.1 >> [8] ? ? NEEDED ? ? ? ? ?libiconv.so.2 >> [9] ? ? NEEDED ? ? ? ? ?libapr-1.so.0 >> [10] ? ?NEEDED ? ? ? ? ?libuuid.so.1 >> [11] ? ?NEEDED ? ? ? ? ?libsendfile.so.1 >> [12] ? ?NEEDED ? ? ? ? ?librt.so.1 >> [13] ? ?NEEDED ? ? ? ? ?libnsl.so.1 >> [14] ? ?NEEDED ? ? ? ? ?libpthread.so.1 >> [15] ? ?NEEDED ? ? ? ? ?libdl.so.1 >> [16] ? ?NEEDED ? ? ? ? ?libdb-4.8.so >> [17] ? ?NEEDED ? ? ? ? ?libsvn_fs_util-1.so.0 >> [18] ? ?NEEDED ? ? ? ? ?libsocket.so.1 >> [19] ? ?NEEDED ? ? ? ? ?libc.so.1 > >> ... > > Are there any other issues I can assist? if you could confirm that the test failing here is working for you: $ ~/mgar/pkg/subversion/trunk/work/solaris9-sparc/build-isa-sparcv8/subversion-1.6.11/subversion/tests/libsvn_fs_base/fs-base-test 1 svn_tests: Bad database version: compiled with 4.7.25, running against 4.8.26 FAIL: fs-base-test 1: svn_fs_create_berkeley From dam at opencsw.org Wed May 26 22:18:37 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 26 May 2010 22:18:37 +0200 Subject: [csw-maintainers] BerkeleyDB upgrade In-Reply-To: <4C32281F-89A3-4B57-B840-699CA6795EDB@opencsw.org> References: <4C32281F-89A3-4B57-B840-699CA6795EDB@opencsw.org> Message-ID: Hi, I have the strong impression the problem with the wrong bdb linkage from Subversion has something to do with the major bdb update: Am 19.10.2009 um 17:35 schrieb Dagobert Michelsen: > Dear maintainers, > > I have now finally assembled a new and complete rebuild of the > Berkeley DB libraries. In the new schema every version of BDB > is sitting in a separate subdirectory, that means > Berkeley DB X.Y.Z is located at /opt/csw/bdbXY/(bin|lib|...) > The repackaged versions contain 3.3, 4.2, 4.3, 4.4, 4.7 and 4.8. > If necessary the legacy packages needed as dependencies have > been replaced by stubs containing minimal links to the new > locations with a respective dependency in the package. > > The following packages have been updated: > > CATALOGNAME PACKAGENAME > berkeleydb CSWbdb > berkeleydb3 CSWbdb3 > berkeleydb3_devel CSWbdb3devel > berkeleydb3_doc CSWbdb3doc > berkeleydb4 CSWbdb4 > berkeleydb42 CSWbdb42 > berkeleydb42_devel CSWbdb42devel > berkeleydb42_doc CSWbdb42doc > berkeleydb43 CSWbdb43 > berkeleydb43_devel CSWbdb43-devel > berkeleydb43_doc CSWbdb43-doc > berkeleydb44 CSWbdb44 > berkeleydb44_devel CSWbdb44-devel > berkeleydb44_doc CSWbdb44-doc > berkeleydb47 CSWbdb47 > berkeleydb47_devel CSWbdb47devel > berkeleydb47_doc CSWbdb47doc > berkeleydb48 CSWbdb48 > berkeleydb48_devel CSWbdb48devel > berkeleydb48_doc CSWbdb48doc > > The following packages are deprecated: > > - CSWbdb was newly introduced during the unification. It contains now > only symlinks pointing inside CSWbdb47. The package will go away > when all dependant packages habe been recompiled against CSWbdb47. > /opt/csw/lib/amd64/libdb-4.7.so=../../bdb47/lib/amd64/libdb-4.7.so > /opt/csw/lib/libdb-4.7.so=../bdb47/lib/libdb-4.7.so > - CSWbdb4 contained the original Berkeley DB 4.2 in /opt/csw/bdb4. > The package now contains > /opt/csw/bdb4=bdb42 > > The following packages do not exist any more as the base packages are > deprecated: > > - berkeleydb_doc CSWbdbdoc > - berkeleydb_devel CSWbdbdevel In fact these two still exist, although they should have been gone. Especially berkeleydb_devel contains /opt/csw/include/db.h with hardcoded 4.7.25 in it. Phil: Could you please completely remove these two packages? > - berkeleydb4_doc CSWbdb4-doc > > The following package names have been kept to match the existing naming. > The package names will be adjusted at a later date with proper announcement: > > - berkeleydb43_devel CSWbdb43-devel > - berkeleydb43_doc CSWbdb43-doc > - berkeleydb44_devel CSWbdb44-devel > - berkeleydb44_doc CSWbdb44-doc > > Should you encounter any issues please post to users@ as usual. Best regards -- Dago From dam at opencsw.org Wed May 26 22:25:44 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 26 May 2010 22:25:44 +0200 Subject: [csw-maintainers] [csw-buildfarm] get only newest bdb onto buildserver In-Reply-To: References: <1274409984-sup-2309@pinkfloyd.chass.utoronto.ca> <4E118E06-1F10-4A18-BF82-0F32CCCC0504@opencsw.org> Message-ID: Hi Rupert, Am 26.05.2010 um 20:30 schrieb rupert THURNER: > if you could confirm that the test failing here is working for you: > > $ ~/mgar/pkg/subversion/trunk/work/solaris9-sparc/build-isa-sparcv8/subversion-1.6.11/subversion/tests/libsvn_fs_base/fs-base-test > 1 > svn_tests: Bad database version: compiled with 4.7.25, running against 4.8.26 > FAIL: fs-base-test 1: svn_fs_create_berkeley It is now :-) The problem was the inclusion of /opt/csw/include/db.h prior to /opt/csw/bdb48/include/db.h despite the setting of the configure directive. The solution was to use EXTRA_INC as in r10004: http://sourceforge.net/apps/trac/gar/changeset/10004 In the future this may no longer be necessary as mistakenly berkeleydb_devel is still in the catalog and also installed on the machines where it should not (see my previous posting). Best regards -- Dago From dam at opencsw.org Wed May 26 22:34:20 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 26 May 2010 22:34:20 +0200 Subject: [csw-maintainers] Commit #10000 today! In-Reply-To: References: Message-ID: <96314941-4A54-4D05-8445-FF4F43939B35@opencsw.org> Hi folks, we just had commit #10000 from Rupert on fixing a flag for CCache. I just grabbed my previous anniversary email and it is almost up to the day one year old. That means we needed 4 years for the first 5000 commits (first commit was on 24-Nov-2005) and just 1 year for the next 5000 :-) If you are curious SourceForge has detailed statistics on Subversion usage available at So, please everybody grab a piece, I already had mine :-) _____ _..--'''@ @'''--.._ .' @_/-//-\/>/>'/ @ '. ( @ /_ On Wed, May 26, 2010 at 20:28, Sebastian Kayser wrote: > * rupert THURNER wrote: >> great, that worked. do we have a trick to make the test script work as >> well? it contains "pwd" (which gives "trunk") to call the freshly >> compiled ccache (which is deep in th ework directory), so the result >> is: >> >> gmake[3]: Entering directory >> `/home/rupert/mgar/pkg/ccache/trunk/work/solaris9-sparc/build-isa-sparcv8/ccache-3.0pre1' >> CC='/opt/studio/SOS12/SUNWspro/bin/cc' ./test.sh >> starting testsuite base >> ./test.sh: /home/rupert/mgar/pkg/ccache/trunk/ccache: not found >> SUITE: "base", TEST: "" - Expected "cache hit (preprocessed)" to be 0, got >> ./test.sh: /home/rupert/mgar/pkg/ccache/trunk/ccache: not found >> TEST FAILED > > I get the slight feeling that all those answers here seduce you to give up > troubleshooting yourself ... I bet you could have figured this out too. you probably noticed that i prefer to have as short as possible and as default as possible gar-makefiles, and fix things upstream. the reason is very simple: any line we write is work, and needs to be ported, and supported. and you are completely right: if i am not able to fix it in 10 minutes i leave it. opencsw is nice, but it is in my free time and there might be other priorities in somebodies life than hunting down some stupid shell anachronism introduced in the computer science stone age. but your statement really provoked me to look it up :) and the result was that the problem boils down to "find the absolute path of a script", http://dbaspot.com/forums/shell/379501-finding-absolute-path-script-within.html, saying: * "sh", pwd, dirname $0 can all be tricked into giving a wrong result. which then needs a workaround like your proposal. * bash gives the desired result with script_path=${0%/*} but finding the absolute path is only necessary as test.sh itself is ugly and changes directories inside itself. rupert. From phil at bolthole.com Wed May 26 23:21:06 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 26 May 2010 14:21:06 -0700 Subject: [csw-maintainers] BerkeleyDB upgrade In-Reply-To: References: <4C32281F-89A3-4B57-B840-699CA6795EDB@opencsw.org> Message-ID: On Wed, May 26, 2010 at 1:18 PM, Dagobert Michelsen wrote: > .... >> The following packages do not exist any more as the base packages are >> deprecated: >> >> - berkeleydb_doc ? ? ?CSWbdbdoc >> - berkeleydb_devel ? ?CSWbdbdevel >.... > > Phil: Could you please completely remove these two packages? > okay. removed from current current. (5.8 dirs are left alone) From bwalton at opencsw.org Thu May 27 04:19:43 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 26 May 2010 22:19:43 -0400 Subject: [csw-maintainers] gar makepatch support Message-ID: <1274926197-sup-6663@pinkfloyd.chass.utoronto.ca> Hi All, I just committed r10012 that adds support for the 'makepatch' target in GAR again. This feature is completely reworked to use git as the underlying mechanism for tracking changes. You'll notice that after source extraction there is output from git as it takes a snapshot of the pristine state of things. Then, after each patch (whether created with git or with diff or with...) git is used to record the commit. Should you subsequently make changes, you can call `gmake makepatch` and get a new patch file stored in files/. Patches can be generated from any modulation (including more than one modulation per call to makepatch). If you find that you'd like to use git more deeply for your patch creation, you can clone this repository externally. To this end, I did a few things that will make it nicer for you: The upstream source is on the default branch 'master' and has a tag named upstream-$(GARVERSION). All patches are applied on a branch named 'csw' and the final existing patch is tagged with csw-$(GARVERSION). Between the tags and branches, you can see differences between upstream and each individual patch very easily. I'll be documenting a new variable shortly as well. This is GIT_COMMIT_OPTS, which defaults to '-v'. The -v will show the patch text during the interactive commit message creation. You can override this with whatever you like (I use -s to get a Signed-off-by: tag, for example). Please let me know if you have any issues with this change. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu May 27 04:25:49 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 26 May 2010 22:25:49 -0400 Subject: [csw-maintainers] gar makepatch support In-Reply-To: <1274926197-sup-6663@pinkfloyd.chass.utoronto.ca> References: <1274926197-sup-6663@pinkfloyd.chass.utoronto.ca> Message-ID: <1274927050-sup-5521@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Wed May 26 22:19:43 -0400 2010: ...oh, and it'll squawk about adding proper settings for name and email in your ~/.gitconfig too. The help text is (hopefully) clear, but if not, you basically want to do: git config --global user.name "Your Name" git config --global user.email "$you at opencsw.org" Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Thu May 27 06:34:31 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 26 May 2010 21:34:31 -0700 Subject: [csw-maintainers] gar makepatch support In-Reply-To: <1274927050-sup-5521@pinkfloyd.chass.utoronto.ca> References: <1274926197-sup-6663@pinkfloyd.chass.utoronto.ca> <1274927050-sup-5521@pinkfloyd.chass.utoronto.ca> Message-ID: errr. I'm confused. what's the point of git if were using svn? From skayser at opencsw.org Thu May 27 09:17:30 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 27 May 2010 09:17:30 +0200 Subject: [csw-maintainers] gar makepatch support In-Reply-To: References: <1274926197-sup-6663@pinkfloyd.chass.utoronto.ca> <1274927050-sup-5521@pinkfloyd.chass.utoronto.ca> Message-ID: <4BFE1C8A.7060502@opencsw.org> Philip Brown wrote on 27.05.2010 06:34: > errr. I'm confused. what's the point of git if were using svn? Creating patches for locally extracted upstream sources is a breeze with git (no remote repo, out-of-the-box patch file creation, ...). Many of us have been using it manually for a while (cf. all those 000*-* patches in GAR) and Ben has now kindly spent some time to make it a more integrated part of the whole GAR build workflow - one which doesn't require intimate git knowledge to use it. Sebastian From bwalton at opencsw.org Thu May 27 13:32:50 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 27 May 2010 07:32:50 -0400 Subject: [csw-maintainers] gar makepatch support In-Reply-To: References: <1274926197-sup-6663@pinkfloyd.chass.utoronto.ca> <1274927050-sup-5521@pinkfloyd.chass.utoronto.ca> Message-ID: <1274959724-sup-6064@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu May 27 00:34:31 -0400 2010: > errr. I'm confused. what's the point of git if were using svn? Well, the patch generation step requires knowledge of what the original source tree looked like. Previously this was done by extracting and patching second pristine copy and then doing a recursive diff between the two trees. This got broken at some point and was a pain to fix. It was easier (and better, imo) to integrate git into the extract and patch steps than it was to fix the old method. Using git may offer other benefits too, if the maintainer has need/desier of these capabilities and a willingness to learn more git. For people that don't care about it, it'll hopefully be nothing more than extra output during the build process. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bonivart at opencsw.org Thu May 27 15:25:47 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 27 May 2010 15:25:47 +0200 Subject: [csw-maintainers] gar makepatch support In-Reply-To: <1274959724-sup-6064@pinkfloyd.chass.utoronto.ca> References: <1274926197-sup-6663@pinkfloyd.chass.utoronto.ca> <1274927050-sup-5521@pinkfloyd.chass.utoronto.ca> <1274959724-sup-6064@pinkfloyd.chass.utoronto.ca> Message-ID: I'm trying to update cswclassutils: ==> Snapshotting extracted source tree with git /bin/sh: work/solaris9-i386/build-isa-i386/cswclassutils-1.37: does not exist I manually create that dir just to see what happens: ==> Snapshotting extracted source tree with git Initialized empty Git repository in /home/bonivart/mgar/pkg/cswclassutils/trunk/work/solaris9-i386/build-isa-i386/cswclassutils-1.37/.git/ # On branch master # # Initial commit # nothing to commit (create/copy files and use "git add" to track) fatal: Failed to resolve 'HEAD' as a valid ref. fatal: You are on a branch yet to be born gmake[1]: *** [post-extract-gitsnap] Error 128 gmake[1]: Leaving directory `/home/bonivart/mgar/pkg/cswclassutils/trunk' gmake: *** [merge-isa-i386] Error 2 -- /peter From bwalton at opencsw.org Thu May 27 15:52:20 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 27 May 2010 09:52:20 -0400 Subject: [csw-maintainers] gar makepatch support In-Reply-To: References: <1274926197-sup-6663@pinkfloyd.chass.utoronto.ca> <1274927050-sup-5521@pinkfloyd.chass.utoronto.ca> <1274959724-sup-6064@pinkfloyd.chass.utoronto.ca> Message-ID: <1274968300-sup-2913@pinkfloyd.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Thu May 27 09:25:47 -0400 2010: > I'm trying to update cswclassutils: Which has no sources that get extracted. A case I hadn't accounted for. Try r10017. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bonivart at opencsw.org Thu May 27 16:14:21 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 27 May 2010 16:14:21 +0200 Subject: [csw-maintainers] gar makepatch support In-Reply-To: <1274968300-sup-2913@pinkfloyd.chass.utoronto.ca> References: <1274926197-sup-6663@pinkfloyd.chass.utoronto.ca> <1274927050-sup-5521@pinkfloyd.chass.utoronto.ca> <1274959724-sup-6064@pinkfloyd.chass.utoronto.ca> <1274968300-sup-2913@pinkfloyd.chass.utoronto.ca> Message-ID: On Thu, May 27, 2010 at 3:52 PM, Ben Walton wrote: > Excerpts from Peter Bonivart's message of Thu May 27 09:25:47 -0400 2010: > >> I'm trying to update cswclassutils: > > Which has no sources that get extracted. ?A case I hadn't accounted > for. ?Try r10017. Now it works. Thanks for the quick fix. -- /peter From bwalton at opencsw.org Thu May 27 16:22:39 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 27 May 2010 10:22:39 -0400 Subject: [csw-maintainers] gar makepatch support In-Reply-To: <1274968300-sup-2913@pinkfloyd.chass.utoronto.ca> References: <1274926197-sup-6663@pinkfloyd.chass.utoronto.ca> <1274927050-sup-5521@pinkfloyd.chass.utoronto.ca> <1274959724-sup-6064@pinkfloyd.chass.utoronto.ca> <1274968300-sup-2913@pinkfloyd.chass.utoronto.ca> Message-ID: <1274970135-sup-7896@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Thu May 27 09:52:20 -0400 2010: > Which has no sources that get extracted. A case I hadn't accounted > for. Try r10017. Sorry, that was to the wrong gar branch. Try r10018. Thanks. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Thu May 27 18:18:49 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 27 May 2010 09:18:49 -0700 Subject: [csw-maintainers] problems accessing svn tree Message-ID: Soooo.... I'm having problems with svn access now. both from www and login.bo.opencsw.org I created a directory, with svn mkdir gawk $ svn status gawk A gawk $ svn commit gawk Authentication realm: SourceForge Subversion area Password for 'theferret': Adding gawk svn: Server sent unexpected return value (405 Method Not Allowed) in response to MKCOL request for '/svnroot/gar/!svn/wrk/35c0442c-1ce9-6e0e-d98c-956ed6aea838/csw/mgar/pkg/gawk' svn: Your commit message was left in a temporary file: svn: '/home/phil/gar/svn-commit.2.tmp' Whassup with that? From phil at bolthole.com Thu May 27 23:13:22 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 27 May 2010 14:13:22 -0700 Subject: [csw-maintainers] problems accessing svn tree In-Reply-To: References: Message-ID: Mystery solved: On Thu, May 27, 2010 at 9:18 AM, Philip Brown wrote: > > Password for 'theferret': > Adding ? ? ? ? gawk > svn: Server sent unexpected return value (405 Method Not Allowed) in > response to MKCOL request for > '/svnroot/gar/!svn/wrk/35c0442c-1ce9-6e0e-d98c-956ed6aea838/csw/mgar/pkg/gawk' > a more accurate message would have been: "error, cant create: directory already exists in subversion" :-/ (I "own", the package, but someone else had set up a directory in svn, and I didnt know it) From bwalton at opencsw.org Fri May 28 05:34:42 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 27 May 2010 23:34:42 -0400 Subject: [csw-maintainers] away for the weekend Message-ID: <1275017603-sup-7383@pinkfloyd.chass.utoronto.ca> Hi All, I'll be away for the weekend and totally disconnected. Please be patient with buildfarm requests as there'll be a gap in timezone coverage...although it's sometimes hard to tell, Dago does sleep sometimes! :) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Fri May 28 15:20:42 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 28 May 2010 06:20:42 -0700 Subject: [csw-maintainers] Important: X11 related packages, and buildfarm Message-ID: <20100528132042.GA34110@bolthole.com> Hi folks, this is to let everyone know what is going on with X related packages these days. Summary: We are in a transition period. things under /opt/csw/X11 are deprecated. We are in the process of recompiling graphical foundation stuff to be sun X11 dependant once more, so be aware. Status is updated on http://wiki.opencsw.org/project-x11-reloaded Details: Many months ago now, we started down a road of modernization for our X11 related libs. Tehre were multiple reasons for this decision; one of which was that we started to see more and more expectation of the newer X11 development files, in newer stuff that is gtk related. We started down a transition road, of first providing the latest X11 core libs in /opt/csw/X11 (X11R7), and then recompiling various foundational libraries to use those, instead of sun ones. We just started rerolling things like xpm, and gtk, to use the new libs. Unfortunately, this turned out to not be the best path, for two reasons. One of which was that we lose some hardware acceleration, by not using Sun X11 libs. Another was that there started to be cross-version pollution of "libX11.so". Some higher level applications ended up pulling in both our version, and the sun version. This is Not Good. "back in the day", we already did some ugly hacks to squeeze in libXrender for solaris 8, even when solaris 10 technically shipped with it. So, we are now taking that one further, and doing it "nicely". (fyi, the sol10 xrender is now too old to use anyway) We now have the package "sunx11_devel". This provides a few foundational things that are only needed at compile time, such as certain magic pkg-config ".pc" files that tend to be expected from modern packages these days. This allowed compilation of an up to date libXrender, and things are now progressing from there. Things are going well, but this is a Very Large Effort. On the one hand, we need to recompile all the CSW-X11 converted packages, back to use sun X11. But even after that... we need to then keep updating our X chain, so we can do things like get a new GNOME in the house! So, more volunteers in this effort to share the load around, would be greatly appreciated. Even being willing to pick up just one piece here and there(in a timely manner!) would be a great help to avoid burnout in those folks who are currently involved in it. From dam at opencsw.org Fri May 28 15:33:00 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 28 May 2010 15:33:00 +0200 Subject: [csw-maintainers] problems accessing svn tree In-Reply-To: References: Message-ID: <400ECA65-7BED-43D2-954C-CEEB4844972E@opencsw.org> Hi Phil, Am 27.05.2010 um 23:13 schrieb Philip Brown: > On Thu, May 27, 2010 at 9:18 AM, Philip Brown > wrote: >> >> Password for 'theferret': >> Adding gawk >> svn: Server sent unexpected return value (405 Method Not Allowed) in >> response to MKCOL request for >> '/svnroot/gar/!svn/wrk/35c0442c-1ce9-6e0e-d98c-956ed6aea838/csw/ >> mgar/pkg/gawk' > > a more accurate message would have been: > > "error, cant create: directory already exists in subversion" :-/ > > (I "own", the package, but someone else had set up a directory in svn, > and I didnt know it) It is often the case that maintainers add stubs as a courtesy. This is one of the reasons I check out the whole tree. I can assure you the diskspace is not relevant, there is still lots of space free on the diskarray. Best regards -- Dago From phil at bolthole.com Fri May 28 17:09:55 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 28 May 2010 08:09:55 -0700 Subject: [csw-maintainers] problems accessing svn tree In-Reply-To: <400ECA65-7BED-43D2-954C-CEEB4844972E@opencsw.org> References: <400ECA65-7BED-43D2-954C-CEEB4844972E@opencsw.org> Message-ID: On Fri, May 28, 2010 at 6:33 AM, Dagobert Michelsen wrote: > > > It is often the case that maintainers add stubs as a courtesy. > This is one of the reasons I check out the whole tree. I can > assure you the diskspace is not relevant, there is still lots > of space free on the diskarray. > I prefer my environment to be less cluttered, reguardless of disk space used. From phil at bolthole.com Fri May 28 18:28:48 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 28 May 2010 09:28:48 -0700 Subject: [csw-maintainers] beware of xcb Message-ID: FYI, while the whole X11 thing is fresh in our minds: our "new X11 tree" (which is now deprecated :) made use of xcb. Which is a newfangled library to "replace" libX11. We should actually *avoid* this, because it will in theory slow most people down, presuming "most people" are going to be using an X server shipped by SUn. Sun Xlib will use the most efficient "local transport" methods possible. special solaris local-memory transports. But if you are using xcb to talk to a Sun Xserver, it will have to go through generic transports, which will in theory introduce higher latency. A small snippet from a much larger thread: http://www.mail-archive.com/xwin-discuss at mail.opensolaris.org/msg02214.html The sun X11 team is looking at properly porting/integrating xcb into opensolaris. But for NOW.. Xlib gives the best performance. From phil at bolthole.com Sun May 30 00:57:45 2010 From: phil at bolthole.com (Philip Brown) Date: Sat, 29 May 2010 15:57:45 -0700 Subject: [csw-maintainers] beware of xcb Message-ID: <20100529225744.GA65148@bolthole.com> oh, btw, a prior message in the email thread I referenced, is actually much more enlightening: http://www.mail-archive.com/xwin-discuss at mail.opensolaris.org/msg02154.html Mentions fun things like, "Linux distros that adopted libxcb discovered the threading changes caused Java to deadlock - how do we make sure we avoid this on Solaris? " From dam at opencsw.org Mon May 31 16:00:32 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 31 May 2010 16:00:32 +0200 Subject: [csw-maintainers] x11-reloaded: CSWgd Message-ID: Hi, I just rebuild CSWgd against Sun X11: Roger: I have made a branch for this: What next? Best regards -- Dago From dam at opencsw.org Mon May 31 16:42:03 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 31 May 2010 16:42:03 +0200 Subject: [csw-maintainers] Buildfarm configuration for x11-reloaded Message-ID: Hi, as the x11 recompilation will take up some more efforts I have now reverted the current* servers back to the released current/ packages. The testing* servers will also be synced for now to current/ and then the packages from experimental/x11-reloaded will be updated. Just let me know if you have any issues. Best regards -- Dago From dam at opencsw.org Wed May 26 10:24:34 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 26 May 2010 08:24:34 -0000 Subject: [csw-maintainers] [buildfarm-announce] Updating all Sun Studio compilers Message-ID: <69C473A4-88EA-4A35-8FBC-F97107571C26@opencsw.org> Hi, I am just updating all Sun Studio compilers on the OpenCSW buildfarm to the latest patchset now. Sorry for the inconvenience -- Dago _______________________________________________ buildfarm-announce mailing list buildfarm-announce at opencsw.org https://lists.opencsw.org/mailman/listinfo/buildfarm-announce From joel at rosdahl.net Sun May 30 19:31:27 2010 From: joel at rosdahl.net (Joel Rosdahl) Date: Sun, 30 May 2010 19:31:27 +0200 Subject: [csw-maintainers] Fwd: [ccache] solaris compile error In-Reply-To: References: <4BFADC8F.9080108@rosdahl.net> <20100525.10221400.3558006443@gyor.oxdrove.co.uk> Message-ID: <4C02A0EF.30409@rosdahl.net> Hi, You have to use GCC to run the test suite since ccache doesn't work with other compilers. I've fixed the pwd problem and some other Solaris-related problems issues in test.sh and they will be part of the next release. -- Joel On 2010-05-26 19:54, rupert THURNER wrote: > great, that worked. do we have a trick to make the test script work as > well? it contains "pwd" (which gives "trunk") to call the freshly > compiled ccache (which is deep in th ework directory), so the result > is: > > > gmake[3]: Entering directory > `/home/rupert/mgar/pkg/ccache/trunk/work/solaris9-sparc/build-isa-sparcv8/ccache-3.0pre1' > CC='/opt/studio/SOS12/SUNWspro/bin/cc' ./test.sh > starting testsuite base > ./test.sh: /home/rupert/mgar/pkg/ccache/trunk/ccache: not found > SUITE: "base", TEST: "" - Expected "cache hit (preprocessed)" to be 0, got > ./test.sh: /home/rupert/mgar/pkg/ccache/trunk/ccache: not found > TEST FAILED > > > > On Tue, May 25, 2010 at 12:22, James Lee wrote: >> On 24/05/10, 21:18:07, rupert THURNER wrote regarding >> [csw-maintainers] Fwd: [ccache] solaris compile error: >> >>> ---------- Forwarded message ---------- >>> From: Joel Rosdahl >>> Date: Mon, May 24, 2010 at 22:07 >>> Subject: Re: [ccache] solaris compile error >>> To: "rupert.thurner" >>> Cc: ccache at lists.samba.org >> >> >>>> gmake[3]: Entering directory `/home/rupert/mgar/pkg/ccache/trunk/work/ >>>> solaris9-sparc/build-isa-sparcv8/ccache-3.0pre1' >>>> /opt/studio/SOS12/SUNWspro/bin/cc -xO3 -m32 -xarch=v8 -xnorunpath -O - >>>> I/opt/csw/include -I. -c -o util.o util.c >>>> "util.c", line 68: incomplete struct/union/enum timeval: tv >>>> "util.c", line 71: warning: implicit function declaration: >>>> gettimeofday >> >> config.h.in defines _XOPEN_SOURCE which is preventing the use of struct >> timeval tv and gettimeofday(). Try adding "#define __EXTENSIONS__". >> >> >> >> James. >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers >> .:: This mailing list's archive is public. ::. >> From joel at rosdahl.net Mon May 31 22:13:23 2010 From: joel at rosdahl.net (Joel Rosdahl) Date: Mon, 31 May 2010 22:13:23 +0200 Subject: [csw-maintainers] Fwd: [ccache] solaris compile error In-Reply-To: <4C02A0EF.30409@rosdahl.net> References: <4BFADC8F.9080108@rosdahl.net> <20100525.10221400.3558006443@gyor.oxdrove.co.uk> <4C02A0EF.30409@rosdahl.net> Message-ID: <4C041863.8030303@rosdahl.net> I just realized that my statement was a bit to restrictive. What I should have said was something like "officially, ccache only supports GCC and the test suite does not (yet) support other compilers". In other words: support for other compilers haven't been dropped, I just haven't checked whether they work. And I hope it's quite likely that they do. -- Joel On 2010-05-30 19:31, Joel Rosdahl wrote: > Hi, > > You have to use GCC to run the test suite since ccache doesn't work with > other compilers. I've fixed the pwd problem and some other > Solaris-related problems issues in test.sh and they will be part of the > next release. > > -- Joel > > On 2010-05-26 19:54, rupert THURNER wrote: >> great, that worked. do we have a trick to make the test script work as >> well? it contains "pwd" (which gives "trunk") to call the freshly >> compiled ccache (which is deep in th ework directory), so the result >> is: >> >> >> gmake[3]: Entering directory >> `/home/rupert/mgar/pkg/ccache/trunk/work/solaris9-sparc/build-isa-sparcv8/ccache-3.0pre1' >> CC='/opt/studio/SOS12/SUNWspro/bin/cc' ./test.sh >> starting testsuite base >> ./test.sh: /home/rupert/mgar/pkg/ccache/trunk/ccache: not found >> SUITE: "base", TEST: "" - Expected "cache hit (preprocessed)" to be 0, got >> ./test.sh: /home/rupert/mgar/pkg/ccache/trunk/ccache: not found >> TEST FAILED >> >> >> >> On Tue, May 25, 2010 at 12:22, James Lee wrote: >>> On 24/05/10, 21:18:07, rupert THURNER wrote regarding >>> [csw-maintainers] Fwd: [ccache] solaris compile error: >>> >>>> ---------- Forwarded message ---------- >>>> From: Joel Rosdahl >>>> Date: Mon, May 24, 2010 at 22:07 >>>> Subject: Re: [ccache] solaris compile error >>>> To: "rupert.thurner" >>>> Cc: ccache at lists.samba.org >>> >>> >>>>> gmake[3]: Entering directory `/home/rupert/mgar/pkg/ccache/trunk/work/ >>>>> solaris9-sparc/build-isa-sparcv8/ccache-3.0pre1' >>>>> /opt/studio/SOS12/SUNWspro/bin/cc -xO3 -m32 -xarch=v8 -xnorunpath -O - >>>>> I/opt/csw/include -I. -c -o util.o util.c >>>>> "util.c", line 68: incomplete struct/union/enum timeval: tv >>>>> "util.c", line 71: warning: implicit function declaration: >>>>> gettimeofday >>> >>> config.h.in defines _XOPEN_SOURCE which is preventing the use of struct >>> timeval tv and gettimeofday(). Try adding "#define __EXTENSIONS__". >>> >>> >>> >>> James. >>> _______________________________________________ >>> maintainers mailing list >>> maintainers at lists.opencsw.org >>> https://lists.opencsw.org/mailman/listinfo/maintainers >>> .:: This mailing list's archive is public. ::. >>> >