From wilbury at opencsw.org Wed Apr 4 22:59:43 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Wed, 04 Apr 2012 22:59:43 +0200 Subject: [csw-maintainers] Strange issue with UNCOMMITTED Message-ID: <4F7CB63F.6010009@opencsw.org> Hi, I've run into one (for me) strange issue: What I do: $ mgar commit -f -m "Correct dependencies and reinplacements." $ mgar build install merge package ... But still get: CSWpdns: If any of the reported errors were false positives, you can override them pasting the lines below to the GAR recipe. CHECKPKG_OVERRIDES_CSWpdns += pkginfo-opencsw-repository-uncommitted Please note that checkpkg isn't suggesting you should simply add these overrides How can this be avoided/solved? Thanks. -- Juraj Lutter From bonivart at opencsw.org Wed Apr 4 23:11:10 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 4 Apr 2012 23:11:10 +0200 Subject: [csw-maintainers] Strange issue with UNCOMMITTED In-Reply-To: <4F7CB63F.6010009@opencsw.org> References: <4F7CB63F.6010009@opencsw.org> Message-ID: On Wed, Apr 4, 2012 at 10:59 PM, Juraj Lutter wrote: > Hi, > > I've run into one (for me) strange issue: > > What I do: > > $ mgar commit -f -m "Correct dependencies and reinplacements." > $ mgar build install merge package > ... > > But still get: > CSWpdns: > If any of the reported errors were false positives, you can override them > pasting the lines below to the GAR recipe. > CHECKPKG_OVERRIDES_CSWpdns += pkginfo-opencsw-repository-uncommitted > Please note that checkpkg isn't suggesting you should simply add these > overrides > > How can this be avoided/solved? What does "svn status" say? From skayser at opencsw.org Wed Apr 4 23:12:54 2012 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 4 Apr 2012 23:12:54 +0200 Subject: [csw-maintainers] Strange issue with UNCOMMITTED In-Reply-To: <4F7CB63F.6010009@opencsw.org> References: <4F7CB63F.6010009@opencsw.org> Message-ID: <20120404211254.GQ15375@sebastiankayser.de> Hey Juraj, * Juraj Lutter wrote: > I've run into one (for me) strange issue: > > What I do: > > $ mgar commit -f -m "Correct dependencies and reinplacements." > $ mgar build install merge package > ... > > But still get: > CSWpdns: > If any of the reported errors were false positives, you can override them > pasting the lines below to the GAR recipe. > CHECKPKG_OVERRIDES_CSWpdns += pkginfo-opencsw-repository-uncommitted > Please note that checkpkg isn't suggesting you should simply add these > overrides the uncommitted tag indicates uncomitted files in your local checkout. What does svn status say? Sebastian From wilbury at opencsw.org Wed Apr 4 23:17:31 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Wed, 04 Apr 2012 23:17:31 +0200 Subject: [csw-maintainers] Strange issue with UNCOMMITTED In-Reply-To: <20120404211254.GQ15375@sebastiankayser.de> References: <4F7CB63F.6010009@opencsw.org> <20120404211254.GQ15375@sebastiankayser.de> Message-ID: <4F7CBA6B.9050101@opencsw.org> seems like svn:ignore issue. what is the correct form of it? thanks. On 04/04/2012 11:12 PM, Sebastian Kayser wrote: > Hey Juraj, > > * Juraj Lutter wrote: >> I've run into one (for me) strange issue: >> >> What I do: >> >> $ mgar commit -f -m "Correct dependencies and reinplacements." >> $ mgar build install merge package >> ... >> >> But still get: >> CSWpdns: >> If any of the reported errors were false positives, you can override them >> pasting the lines below to the GAR recipe. >> CHECKPKG_OVERRIDES_CSWpdns += pkginfo-opencsw-repository-uncommitted >> Please note that checkpkg isn't suggesting you should simply add these >> overrides > > the uncommitted tag indicates uncomitted files in your local checkout. > What does svn status say? > > Sebastian > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -- Juraj Lutter From wilbury at opencsw.org Wed Apr 4 23:28:36 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Wed, 04 Apr 2012 23:28:36 +0200 Subject: [csw-maintainers] Strange issue with UNCOMMITTED In-Reply-To: <4F7CBA6B.9050101@opencsw.org> References: <4F7CB63F.6010009@opencsw.org> <20120404211254.GQ15375@sebastiankayser.de> <4F7CBA6B.9050101@opencsw.org> Message-ID: <4F7CBD04.8080307@opencsw.org> On 04/04/2012 11:17 PM, Juraj Lutter wrote: >> >> the uncommitted tag indicates uncomitted files in your local checkout. >> What does svn status say? wilbury@[unstable10x.1 /home/wilbury/b/powerdns/trunk]$ svn status ? work/solaris10-i386 -- Juraj Lutter From bonivart at opencsw.org Wed Apr 4 23:34:21 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 4 Apr 2012 23:34:21 +0200 Subject: [csw-maintainers] Strange issue with UNCOMMITTED In-Reply-To: <4F7CBD04.8080307@opencsw.org> References: <4F7CB63F.6010009@opencsw.org> <20120404211254.GQ15375@sebastiankayser.de> <4F7CBA6B.9050101@opencsw.org> <4F7CBD04.8080307@opencsw.org> Message-ID: On Wed, Apr 4, 2012 at 11:28 PM, Juraj Lutter wrote: > On 04/04/2012 11:17 PM, Juraj Lutter wrote: >>> >>> the uncommitted tag indicates uncomitted files in your local checkout. >>> What does svn status say? > > wilbury@[unstable10x.1 /home/wilbury/b/powerdns/trunk]$ svn status > ? ? ? ? work/solaris10-i386 bonivart at unstable9x[trunk]$ svn pg svn:ignore cookies download work You set it with "svn ps" but something must be wrong for you not to have it already. From wilbury at opencsw.org Wed Apr 4 23:36:18 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Wed, 04 Apr 2012 23:36:18 +0200 Subject: [csw-maintainers] Strange issue with UNCOMMITTED In-Reply-To: References: <4F7CB63F.6010009@opencsw.org> <20120404211254.GQ15375@sebastiankayser.de> <4F7CBA6B.9050101@opencsw.org> <4F7CBD04.8080307@opencsw.org> Message-ID: <4F7CBED2.8090105@opencsw.org> On 04/04/2012 11:34 PM, Peter Bonivart wrote: >> wilbury@[unstable10x.1 /home/wilbury/b/powerdns/trunk]$ svn status >> ? work/solaris10-i386 > > bonivart at unstable9x[trunk]$ svn pg svn:ignore > cookies > download > work > > You set it with "svn ps" but something must be wrong for you not to > have it already. I have found out that "work" directory was under version control, too. Therefore it always was "?" which instrumented checkpkg to complain. -- Juraj Lutter From jh at opencsw.org Thu Apr 5 07:47:15 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Thu, 05 Apr 2012 07:47:15 +0200 Subject: [csw-maintainers] Push py_cairo to testing In-Reply-To: <4F7CBD04.8080307@opencsw.org> References: <4F7CB63F.6010009@opencsw.org> <20120404211254.GQ15375@sebastiankayser.de> <4F7CBA6B.9050101@opencsw.org> <4F7CBD04.8080307@opencsw.org> Message-ID: <4F7D31E3.6040302@opencsw.org> Hi, as reported tonight in irc the py_cairo package in testing/dublin is build against 2.5. Please someone who knows how to do it push the new package from unstable to testing/dublin :) Thx Jan From maciej at opencsw.org Thu Apr 5 08:55:19 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 5 Apr 2012 07:55:19 +0100 Subject: [csw-maintainers] Push py_cairo to testing In-Reply-To: <4F7D31E3.6040302@opencsw.org> References: <4F7CB63F.6010009@opencsw.org> <20120404211254.GQ15375@sebastiankayser.de> <4F7CBA6B.9050101@opencsw.org> <4F7CBD04.8080307@opencsw.org> <4F7D31E3.6040302@opencsw.org> Message-ID: It's me who usually does this but I am on vacations with no access to the buildfarm. The integration can be done with the integrate_catalog.py script. Buildfarm admins should be able to do that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Thu Apr 5 09:02:07 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 5 Apr 2012 08:02:07 +0100 Subject: [csw-maintainers] Strange issue with UNCOMMITTED In-Reply-To: <4F7CBED2.8090105@opencsw.org> References: <4F7CB63F.6010009@opencsw.org> <20120404211254.GQ15375@sebastiankayser.de> <4F7CBA6B.9050101@opencsw.org> <4F7CBD04.8080307@opencsw.org> <4F7CBED2.8090105@opencsw.org> Message-ID: How did you start the package? 'mgar newpkg foo', 'svn copy foo bar' or something else (what exactly?)? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilbury at opencsw.org Thu Apr 5 12:33:35 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Thu, 05 Apr 2012 12:33:35 +0200 Subject: [csw-maintainers] Strange issue with UNCOMMITTED In-Reply-To: References: <4F7CB63F.6010009@opencsw.org> <20120404211254.GQ15375@sebastiankayser.de> <4F7CBA6B.9050101@opencsw.org> <4F7CBD04.8080307@opencsw.org> <4F7CBED2.8090105@opencsw.org> Message-ID: <4F7D74FF.9050306@opencsw.org> On 04/05/2012 09:02 AM, Maciej (Matchek) Blizi?ski wrote: > How did you start the package? 'mgar newpkg foo', 'svn copy foo bar' or > something else (what exactly?)? Something else. I have used existing powerdns package which I have modified. Never mind, I have already fixed it. otis -- Juraj Lutter From jeff at cjsa.com Thu Apr 5 12:48:07 2012 From: jeff at cjsa.com (Jeffery Small) Date: Thu, 5 Apr 2012 10:48:07 GMT Subject: [csw-maintainers] Problems upgrading Message-ID: In an attempt to get the latest version of samba, I knew I would regret the upgrade process! I'm upgrading from "current" on my SPARC Solaris 10 machine. Things really started to fall apart during the upgrade as all sorts of changes began to break the ability for the upgrade to continue. I've solved a number of problems, such as sendmail being left in an unusable state due to the directory shuffle from /opts/csw/{etc,var} to /{etc,var}/opt/csw. Finally, downloads of new packages came to a crawl. There seems to be a serious authentication problem with the relocation of the openssl files. I have: /etc/opt/csw/sasldb2 /etc/opt/csw/ssl/{certs.openssl.cnf,private} and there are now sumlinks under /opt/csw/etc that point to these. There are also links under /optcsw/ssl which point all over the place but eventually resolve in /etc/opt/csw/ssl. However, fetchmail is now spewing out a stream of the following: fetchmail: Server certificate verification error: unable to get local issuer certificate fetchmail: This means that the root signing certificate (issued for /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO High-Assurance Secure Server CA) is not in the trusted CA certificate locations, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page. fetchmail: Server certificate verification error: certificate not trusted fetchmail: Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!) I have tried running c_rehash (which still references "/opt/csw/ssl") but this has not improved anything. Any suggestions how to calm this beast? Thanks. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From maciej at opencsw.org Thu Apr 5 13:48:08 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 5 Apr 2012 12:48:08 +0100 Subject: [csw-maintainers] Strange issue with UNCOMMITTED In-Reply-To: <4F7D74FF.9050306@opencsw.org> References: <4F7CB63F.6010009@opencsw.org> <20120404211254.GQ15375@sebastiankayser.de> <4F7CBA6B.9050101@opencsw.org> <4F7CBD04.8080307@opencsw.org> <4F7CBED2.8090105@opencsw.org> <4F7D74FF.9050306@opencsw.org> Message-ID: General advice: use mgar newpkg foo, otherwise you have to know and remember a number of tedious details. I will review your recipe when I'm back. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Thu Apr 5 16:26:25 2012 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 05 Apr 2012 10:26:25 -0400 Subject: [csw-maintainers] Problems upgrading In-Reply-To: References: Message-ID: <1333635478-sup-9953@pinkfloyd.chass.utoronto.ca> Excerpts from jeff's message of Thu Apr 05 06:48:07 -0400 2012: > fetchmail: Server certificate verification error: unable > to get local issuer certificate fetchmail: This means that > the root signing certificate (issued for /C=GB/ST=Greater > Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO High-Assurance > Secure Server CA) is not in the trusted CA certificate > locations, I just checked my local root ca stores and I don't have that key either...(I checked both CSW and Linux). This all worked fine before the upgrade though, I assume? Maybe that certificate was removed from CSWcacertificates for some reason? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Apr 5 16:29:55 2012 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 05 Apr 2012 10:29:55 -0400 Subject: [csw-maintainers] Push py_cairo to testing In-Reply-To: References: <4F7CB63F.6010009@opencsw.org> <20120404211254.GQ15375@sebastiankayser.de> <4F7CBA6B.9050101@opencsw.org> <4F7CBD04.8080307@opencsw.org> <4F7D31E3.6040302@opencsw.org> Message-ID: <1333636172-sup-9759@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Thu Apr 05 02:55:19 -0400 2012: > It's me who usually does this but I am on vacations with no access > to the buildfarm. The integration can be done with the > integrate_catalog.py script. Buildfarm admins should be able to do > that. I'll put this on my todo list for this evening. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Thu Apr 5 20:59:29 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 5 Apr 2012 19:59:29 +0100 Subject: [csw-maintainers] libpng respin Message-ID: Can anyone respin libpng? There is a security vulnerability in < 1.2.48 while we are at 1.2.46. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bonivart at opencsw.org Thu Apr 5 21:05:37 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 5 Apr 2012 21:05:37 +0200 Subject: [csw-maintainers] libpng respin In-Reply-To: References: Message-ID: 2012/4/5 Maciej (Matchek) Blizi?ski : > Can anyone respin libpng? There is a? security vulnerability in < 1.2.48 > while we are at 1.2.46. Seems like Dago has been working on the recipe, it's now at 1.5.4. I'm testing if it builds. /peter From maciej at opencsw.org Thu Apr 5 21:07:55 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 5 Apr 2012 20:07:55 +0100 Subject: [csw-maintainers] libpng respin In-Reply-To: References: Message-ID: We need to rebuild the earlier build, it should be in a branch. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bonivart at opencsw.org Thu Apr 5 21:19:12 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 5 Apr 2012 21:19:12 +0200 Subject: [csw-maintainers] libpng respin In-Reply-To: References: Message-ID: 2012/4/5 Maciej (Matchek) Blizi?ski : > We need to rebuild the earlier build, it should be in a branch. Ok, found a branch called libpng3 with 1.2.46 in the Makefile. I'm trying to build 1.2.49 now. /peter From bonivart at opencsw.org Thu Apr 5 22:04:09 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 5 Apr 2012 22:04:09 +0200 Subject: [csw-maintainers] libpng respin In-Reply-To: References: Message-ID: On Thu, Apr 5, 2012 at 9:19 PM, Peter Bonivart wrote: > 2012/4/5 Maciej (Matchek) Blizi?ski : >> We need to rebuild the earlier build, it should be in a branch. > > Ok, found a branch called libpng3 with 1.2.46 in the Makefile. I'm > trying to build 1.2.49 now. Seemed to work, I have put the packages in experimental to start with. /peter From maciej at opencsw.org Thu Apr 5 22:21:32 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 5 Apr 2012 21:21:32 +0100 Subject: [csw-maintainers] libpng respin In-Reply-To: References: Message-ID: No dia 5 de Abr de 2012 21:04, "Peter Bonivart" escreveu: > > On Thu, Apr 5, 2012 at 9:19 PM, Peter Bonivart wrote: > > 2012/4/5 Maciej (Matchek) Blizi?ski : > >> We need to rebuild the earlier build, it should be in a branch. > > > > Ok, found a branch called libpng3 with 1.2.46 in the Makefile. I'm > > trying to build 1.2.49 now. > > Seemed to work, I have put the packages in experimental to start with. Cool, thanks a lot. If they pass a smoke test (e.g. a binary linking against then runs), you can push them to unstable. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From bonivart at opencsw.org Fri Apr 6 00:27:29 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 6 Apr 2012 00:27:29 +0200 Subject: [csw-maintainers] libpng respin In-Reply-To: References: Message-ID: 2012/4/5 Maciej (Matchek) Blizi?ski : > Cool, thanks a lot. If they pass a smoke test (e.g. a binary linking against > then runs), you can push them to unstable. I tried it with James Lee's pngcrush and it complains a little, see below, but it does the job. /peter Warning: versions are different between png.h and png.c png.h version: 1.2.43 png.c version: 1.2.49 | pngcrush 1.7.11 | Copyright (C) 1998-2002,2006-2010 Glenn Randers-Pehrson | Copyright (C) 2005 Greg Roelofs | This is a free, open-source program. Permission is irrevocably | granted to everyone to use this version of pngcrush without | payment of any fee. | Executable name is pngcrush | It was built with libpng version 1.2.43, and is | running with libpng version 1.2.49 - March 29, 2012 | Copyright (C) 1998-2004,2006-2010 Glenn Randers-Pehrson, | Copyright (C) 1996, 1997 Andreas Dilger, | Copyright (C) 1995, Guy Eric Schalnat, Group 42 Inc., | and zlib version 1.2.4, Copyright (C) 1998-2002 (or later), | Jean-loup Gailly and Mark Adler. Recompressing UpTriangle.png Total length of data found in IDAT chunks = 196 IDAT length with method 1 (fm 0 zl 4 zs 0) = 33 IDAT length with method 2 (fm 1 zl 4 zs 0) = 45 IDAT length with method 3 (fm 5 zl 4 zs 1) = 45 IDAT length with method 4 (fm 0 zl 9 zs 1) = 33 IDAT length with method 7 (fm 0 zl 9 zs 0) = 29 Best pngcrush method = 7 (fm 0 zl 9 zs 0) for UpTriangle2.png (85.20% IDAT reduction) (47.44% filesize reduction) CPU time used = 0.000 seconds (decoding 0.000, encoding 0.000, other 0.000 seconds) peter at opensolaris:~$ ls -ld UpTriangle* -rw-r--r-- 1 peter staff 352 2012-04-06 00:22 UpTriangle.png -rw-r--r-- 1 root root 185 2012-04-06 00:22 UpTriangle2.png From jeff at cjsa.com Fri Apr 6 02:01:57 2012 From: jeff at cjsa.com (Jeffery Small) Date: Fri, 6 Apr 2012 00:01:57 GMT Subject: [csw-maintainers] A couple of sendmail issues Message-ID: I just though I would share a couple of issues that I had when upgrading to the latest version of sendmail (8.14.5). Besides the obvious problems due to the relocation of the etc and var files, there were changes made to the cf configuration files for solaris that cause a number of things to break on my system. In the previous version of sendmail, the following .mc configuration files we referenced: OSTYPE(`solaris8')dnl DOMAIN(`solaris-generic')dnl The new configuration wants to reference OSTYPE(`solaris9csw') in order to pick up the new paths, but this file also eliminates the lines: ifdef(`UUCP_MAILER_ARGS',, `define(`UUCP_MAILER_ARGS', `uux \ - -r -a$g $h!rmail ($u)')') FEATURE(`local_lmtp')dnl I can understand removing the obsolete uucp line, but why the second? For people relying upon that feature, it causes problems and requires the creation of a custom ostype file when one was not required previously. More problematic was the complete elimination of the "domain/solaris-generic" file and change to DOMAIN(`generic') which eliminates: FEATURE(`use_ct_file')dnl FEATURE(`accept_unqualified_senders')dnl FEATURE(`accept_unresolvable_domains')dnl FEATURE(`relay_entire_domain')dnl This caused me all sorts of problems until I tracked down the situation and created my own customized domain file. I'm curious why configuration changes which alter program behavior are being made to packages that so many people rely upon? And there is no documentation of these changes. In my case, I configure a program like sendmail and then I don't look at it again for years. When I upgrade a package, I expect it to go smoothly. When some critical component like this breaks, despite the notes I keep on the setup for these programs, it is still a lot of work to bring myself back up to speed on all of the configuration issues. And when I do a large update involving hundreds of packages, the issues are immense. I mention this, using the example of sendmail, in order raise the subject and to see if these sorts of things are being considered as part of the CSW release strategy. However, please don't get me wrong. I'm still extremely appreciative of all the work everyone is doing to keep this project moving forward. I wish I had more free time these days to be involved myself. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From bwalton at opencsw.org Fri Apr 6 03:48:45 2012 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 05 Apr 2012 21:48:45 -0400 Subject: [csw-maintainers] Push py_cairo to testing In-Reply-To: <1333636172-sup-9759@pinkfloyd.chass.utoronto.ca> References: <4F7CB63F.6010009@opencsw.org> <20120404211254.GQ15375@sebastiankayser.de> <4F7CBA6B.9050101@opencsw.org> <4F7CBD04.8080307@opencsw.org> <4F7D31E3.6040302@opencsw.org> <1333636172-sup-9759@pinkfloyd.chass.utoronto.ca> Message-ID: <1333676860-sup-9735@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Thu Apr 05 10:29:55 -0400 2012: > Excerpts from Maciej (Matchek) Blizi?ski's message of Thu Apr 05 02:55:19 -0400 2012: > > > It's me who usually does this but I am on vacations with no access > > to the buildfarm. The integration can be done with the > > integrate_catalog.py script. Buildfarm admins should be able to do > > that. > > I'll put this on my todo list for this evening. Attempted but denied by db permissions. :) sqlobject.dberrors.OperationalError: INSERT command denied to user 'pkg_maintainer'@'192.168.1.2' for table 'srv4_file_in_catalog' + bin/pkgdb add-to-cat SunOS5.11 sparc dublin 4b03dcd3a41d2e453daa6e3c7cae7492 I can become you briefly and run the script with your credentials if that's the easiest work around for now...? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Fri Apr 6 03:51:56 2012 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 05 Apr 2012 21:51:56 -0400 Subject: [csw-maintainers] key signing delegation Message-ID: <1333676992-sup-4932@pinkfloyd.chass.utoronto.ca> Hi All, I think we need to consider adding at least one more person with the rights to the gpg key. At the current time, both Maciej and Ihsan are indisposed...the pass phrase has expired and the catalog is not being signed. Does anyone object to giving the passphrase to a third person? If not, is anyone willing to take on the responsibility? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bonivart at opencsw.org Fri Apr 6 10:12:36 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 6 Apr 2012 10:12:36 +0200 Subject: [csw-maintainers] A couple of sendmail issues In-Reply-To: References: Message-ID: On Fri, Apr 6, 2012 at 2:01 AM, Jeffery Small wrote: > > I just though I would share a couple of issues that I had when upgrading to > the latest version of sendmail (8.14.5). > > Besides the obvious problems due to the relocation of the etc and var files, > there were changes made to the cf configuration files for solaris that cause > a number of things to break on my system. > > In the previous version of sendmail, the following .mc configuration files > we referenced: > > ? ? ? ?OSTYPE(`solaris8')dnl > ? ? ? ?DOMAIN(`solaris-generic')dnl > > The new configuration wants to reference OSTYPE(`solaris9csw') in order to > pick up the new paths, but this file also eliminates the lines: > > ? ? ? ?ifdef(`UUCP_MAILER_ARGS',, `define(`UUCP_MAILER_ARGS', `uux \ > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?- -r -a$g $h!rmail ($u)')') > ? ? ? ?FEATURE(`local_lmtp')dnl > > I can understand removing the obsolete uucp line, but why the second? ?For > people relying upon that feature, it causes problems and requires the creation > of a custom ostype file when one was not required previously. > > More problematic was the complete elimination of the "domain/solaris-generic" > file and change to DOMAIN(`generic') which eliminates: > > ? ? ? ?FEATURE(`use_ct_file')dnl > ? ? ? ?FEATURE(`accept_unqualified_senders')dnl > ? ? ? ?FEATURE(`accept_unresolvable_domains')dnl > ? ? ? ?FEATURE(`relay_entire_domain')dnl > > This caused me all sorts of problems until I tracked down the situation and > created my own customized domain file. > > I'm curious why configuration changes which alter program behavior are > being made to packages that so many people rely upon? ?And there is no > documentation of these changes. ?In my case, I configure a program like > sendmail and then I don't look at it again for years. ?When I upgrade a > package, I expect it to go smoothly. ?When some critical component like > this breaks, despite the notes I keep on the setup for these programs, > it is still a lot of work to bring myself back up to speed on all of the > configuration issues. ?And when I do a large update involving hundreds of > packages, the issues are immense. > > I mention this, using the example of sendmail, in order raise the subject > and to see if these sorts of things are being considered as part of the CSW > release strategy. ?However, please don't get me wrong. ?I'm still extremely > appreciative of all the work everyone is doing to keep this project moving > forward. ?I wish I had more free time these days to be involved myself. Sorry to hear you had a hard time upgrading. I'm a long time user of this package myself and the old one from 2007 had a bunch of really annoying problems as well such as hanging indefinitely during installation and messing with the Solaris Sendmail. My first update of the package didn't change that much, it was mostly new source, kill some bugs and remove the fiddling with Solaris Sendmail. Recently though, I worked with Rafael Ostertag on the configuration and we tried to do it more like we used it and also allow for easy configuration of the spamassassin-milter and milter-greylist. It's during this some things changed that affected you. However, this should only matter if you're installing from scratch, if you're doing an upgrade you should have your own mc-file to generate the cf-file from. The features you're mentioning may very well have already been custom, they are not part of the source anyway and usually put directly in the main mc-file if wanted. Also, as a general comment, it's hard to get a real smooth upgrade when we change maintainers and it's been years between releases and CSW policies have changed during that time (like /opt/csw/etc to /etc/opt/csw). If I maintained only this package maybe I could work like crazy to include complicated scripts that tested and took care of everything but sometimes it's better to get an updated package out there with source that is considered safe and following our current policies. This package was out for testing for a long time, I received some feedback, fixed everything and would be glad to work with you to make it better as well. /peter From jeff at cjsa.com Sat Apr 7 01:10:54 2012 From: jeff at cjsa.com (Jeffery Small) Date: Fri, 6 Apr 2012 16:10:54 -0700 (PDT) Subject: [csw-maintainers] A couple of sendmail issues References: Message-ID: <201204062310.q36NAsZO013754@cjsa2.com> Peter wrote: >Sorry to hear you had a hard time upgrading. >I'm a long time user of this [Sendmail] package myself and the old one >from 2007 had a bunch of really annoying problems as well such as hanging >indefinitely during installation and messing with the Solaris Sendmail. My >first update of the package didn't change that much, it was mostly new >source, kill some bugs and remove the fiddling with Solaris Sendmail. >Recently though, I worked with Rafael Ostertag on the configuration and we >tried to do it more like we used it and also allow for easy configuration >of the spamassassin-milter and milter-greylist. It's during this some >things changed that affected you. >However, this should only matter if you're installing from scratch, if >you're doing an upgrade you should have your own mc-file to generate the >cf-file from. The features you're mentioning may very well have already >been custom, they are not part of the source anyway and usually put >directly in the main mc-file if wanted. >Also, as a general comment, it's hard to get a real smooth upgrade when we >change maintainers and it's been years between releases and CSW policies >have changed during that time (like /opt/csw/etc to /etc/opt/csw). If I >maintained only this package maybe I could work like crazy to include >complicated scripts that tested and took care of everything but sometimes >it's better to get an updated package out there with source that is >considered safe and following our current policies. This package was out >for testing for a long time, I received some feedback, fixed everything >and would be glad to work with you to make it better as well. Peter: I did get everything working after a careful comparison between the two releases. You are correct that I should merge the requirements from the ostype and domain files into the master site .mc file. I just wanted to give some feedback on how the update was affecting people at the other end of the chain. I know that things have to move forward and this entails unavoidable modifications, so I'm not arguing against that. I think the most important change I could suggest is that a section be added to the package documentation page which included special notes for upgrading between releases. I realize that there are now special migration files being added to the old /opt/csw/{etc,var} locations, and notes are displated as part of the install output, but when you are doing a massive upgrade or install, these messages are easy to miss and you may have no clue to go looking for files in the directory hierarchy. It would be good to be able to go to the package page and read about the significant changes taking place. In the case of this release of Sendmail, this might include a list pointing out: * File location migration to /etc/opt/csw/ * The specific changes to the ostype and domain configuration files and the need to update the references in the site .mc file * Brief instructions for rebuilding the sendmail.cf file * Brief instructions for checking & restarting the sendmail service (svcs and svcadm) Earlier release notes would include: * Instructions on deactivating/reactivating the Sun Sendmail using the oracle-sendmail-{de,re}activate.sh scripts You get the drift. This would be a common place to go for all packages which would give users a heads up on changes and tips on how to address problems. I don't think this would be too hard to implement, as these notes could be updated during the development cycle as changes were made, and then published at the time a package was pushed out to testing. Another tweak that might be a good idea is that pkgutil.conf could have an admin email option added. Then, during an install or upgrade, special notifications could be logged to a file and then, at the end of the process, have that log emailed to the user. The log could contain the same notes as on the package webpage, or even just a link to the relevant pages for the user to review. This would be another way of making sure the important info gets before the user instead of rapidly scrolling off the screen during the install/upgrade process. Those are a couple of ideas that I think could significantly improve the CSW experience. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From bwalton at opencsw.org Sat Apr 7 01:11:51 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 06 Apr 2012 19:11:51 -0400 Subject: [csw-maintainers] Push py_cairo to testing In-Reply-To: <4F7D31E3.6040302@opencsw.org> References: <4F7CB63F.6010009@opencsw.org> <20120404211254.GQ15375@sebastiankayser.de> <4F7CBA6B.9050101@opencsw.org> <4F7CBD04.8080307@opencsw.org> <4F7D31E3.6040302@opencsw.org> Message-ID: <1333753893-sup-6514@pinkfloyd.chass.utoronto.ca> Excerpts from Jan Holzhueter's message of Thu Apr 05 01:47:15 -0400 2012: Hi Jan, > as reported tonight in irc the py_cairo package in testing/dublin is > build against 2.5. Please someone who knows how to do it push the > new package from unstable to testing/dublin :) This update is now on it's way. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Apr 7 04:12:08 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 06 Apr 2012 22:12:08 -0400 Subject: [csw-maintainers] key signing delegation In-Reply-To: References: <1333676992-sup-4932@pinkfloyd.chass.utoronto.ca> Message-ID: <1333764668-sup-4946@pinkfloyd.chass.utoronto.ca> Excerpts from Juraj Lutter's message of Fri Apr 06 06:41:16 -0400 2012: Hi Juraj, > I can take it. That would be fine with me. If nobody else has any issues with this, Maciej could hook you up at the camp. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bonivart at opencsw.org Sat Apr 7 09:03:13 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Sat, 7 Apr 2012 09:03:13 +0200 Subject: [csw-maintainers] A couple of sendmail issues In-Reply-To: <201204062310.q36NAsZO013754@cjsa2.com> References: <201204062310.q36NAsZO013754@cjsa2.com> Message-ID: On Sat, Apr 7, 2012 at 1:10 AM, Jeffery Small wrote: > I think the most important change I could suggest is that a section be added > to the package documentation page which included special notes for upgrading > between releases. ?I realize that there are now special migration files being > added to the old /opt/csw/{etc,var} locations, and notes are displated as part > of the install output, but when you are doing a massive upgrade or install, > these messages are easy to miss and you may have no clue to go looking for > files in the directory hierarchy. ?It would be good to be able to go to the > package page and read about the significant changes taking place. ?In the > case of this release of Sendmail, this might include a list pointing out: > > ? ? ? ?* File location migration to /etc/opt/csw/ > ? ? ? ?* The specific changes to the ostype and domain configuration files > ? ? ? ? ? ?and the need to update the references ?in the site .mc file > ? ? ? ?* Brief instructions for rebuilding the sendmail.cf file > ? ? ? ?* Brief instructions for checking & restarting the sendmail service > ? ? ? ? ? ?(svcs and svcadm) > > Earlier release notes would include: > > ? ? ? ?* Instructions on deactivating/reactivating the Sun Sendmail using > ? ? ? ? ? ?the oracle-sendmail-{de,re}activate.sh scripts > > You get the drift. ?This would be a common place to go for all packages > which would give users a heads up on changes and tips on how to address > problems. ?I don't think this would be too hard to implement, as these > notes could be updated during the development cycle as changes were made, > and then published at the time a package was pushed out to testing. Do you mean on our web site? Because what is displayed at the end of install is in here: /opt/csw/share/doc/sendmail. It doesn't contain all the things you suggest though, that could be improved. I have also wanted the package browser on our web site to be able to display notes from the maintainer, now we use the wiki for that but it hasn't caught on with either maintainers or users. > Another tweak that might be a good idea is that pkgutil.conf could have > an admin email option added. ?Then, during an install or upgrade, special > notifications could be logged to a file and then, at the end of the > process, have that log emailed to the user. ?The log could contain the > same notes as on the package webpage, or even just a link to the relevant > pages for the user to review. ?This would be another way of making sure the > important info gets before the user instead of rapidly scrolling off the > screen during the install/upgrade process. Today, everything displayed is from the actual packages themselves, not from pkgutil so that would take some standardized naming or similar to be able to collect the files. Is there anything to learn here from other OS:es? How do they handle it? I remember a couple of years ago when I upgraded RH and they suddenly had switched to running BIND in chroot, that was a bit of a surprise I didn't notice until some hours later. /peter From jeff at cjsa.com Sun Apr 8 05:54:08 2012 From: jeff at cjsa.com (Jeffery Small) Date: Sun, 8 Apr 2012 03:54:08 GMT Subject: [csw-maintainers] xscreensaver and libkrb4.so.2 Message-ID: After my recent upgrade in testing I discovered that xscreensaver is no longer working under my gnome desktop. when I try to start it manually it reports: 5-> xscreensaver -no-splash ld.so.1: xscreensaver: fatal: libkrb4.so.2: open failed: \ No such file or directory Killed Sure enough, there is no libkrb4.so.2 remaining on the system. I see that this has apparently been replaced with libkrb5.so.3, however the CSWxsave package has not been upgraded to use this. (it is still at 5.11,REV=2010.07.12). It is interesting that when I do a file search for libkrb5.so.3 it reports a pile of packages as dependent upon CSWlibkrb5-3, including CSWxsave. When I do a search for libkrb4.so.2 it also reports CSWxsave as the only package dependent upon this library. So there seems to be some sort of inconsistency in how this is getting logged in the database. Maybe this is provides a clue as to why the CSWxsave package got missed in the upgrade. Can xscreensaver please be repackaged to use the current library? Thanks. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From jeff at cjsa.com Sun Apr 8 06:13:04 2012 From: jeff at cjsa.com (Jeffery Small) Date: Sun, 8 Apr 2012 04:13:04 GMT Subject: [csw-maintainers] Question about stub files Message-ID: Just out of curiosity, what is the rationale behind the proliferation of all these *_stub packages? From the few that I have investigated, they mostly seem to contain only a single license file. Why add all this package clutter? It seems as though they can be removed without causing problems. I'm sure I must be missing something. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From jeff at cjsa.com Sun Apr 8 06:26:37 2012 From: jeff at cjsa.com (Jeffery Small) Date: Sun, 8 Apr 2012 04:26:37 GMT Subject: [csw-maintainers] A couple of sendmail issues References: <201204062310.q36NAsZO013754@cjsa2.com> Message-ID: Peter Bonivart writes: >Do you mean on our web site? Because what is displayed at the end of >install is in here: /opt/csw/share/doc/sendmail. It doesn't contain >all the things you suggest though, that could be improved. I have also >wanted the package browser on our web site to be able to display notes >from the maintainer, now we use the wiki for that but it hasn't caught >on with either maintainers or users. Yes, this README.postinstall information is some of what I'm getting at. If this type of info could be linked directly to the various package pages, it would be very useful as a first place to go in addressing a problem. This is the first time I ever realized that these files were actually on my machine in the doc directory. Is this something I and other end users should have been aware of? If so, I wonder how I missed learning about it. So thanks for bringing that to my attention. >Is there anything to learn here from other OS:es? How do they handle >it? I remember a couple of years ago when I upgraded RH and they >suddenly had switched to running BIND in chroot, that was a bit of a >surprise I didn't notice until some hours later. I personally don't have any experience with other systems, although I am just now jumping in to Ubuntu linux, so maybe I'll eventually learn something there. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From maciej at opencsw.org Sun Apr 8 09:29:32 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 8 Apr 2012 08:29:32 +0100 Subject: [csw-maintainers] Question about stub files In-Reply-To: References: Message-ID: No dia 8 de Abr de 2012 05:13, "Jeffery Small" escreveu: > > Just out of curiosity, what is the rationale behind the proliferation > of all these *_stub packages? From the few that I have investigated, > they mostly seem to contain only a single license file. Why add all this > package clutter? It seems as though they can be removed without causing > problems. (...) They are a byproduct of package splits and renames. They are required in the catalog, and required during upgrades, but many can be removed later on. Pkgutil knows which ones you can remove, see the --cleanup option. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sun Apr 8 09:38:52 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 8 Apr 2012 08:38:52 +0100 Subject: [csw-maintainers] xscreensaver and libkrb4.so.2 In-Reply-To: References: Message-ID: No dia 8 de Abr de 2012 04:54, "Jeffery Small" escreveu: > Can xscreensaver please be repackaged to use the current library? Thanks. Have you tried respinning the build recipe from Subversion? The package is currently orphaned, so if you care about this package, it's the best way to get things moving forward. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Sun Apr 8 13:26:46 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 08 Apr 2012 07:26:46 -0400 Subject: [csw-maintainers] Question about stub files In-Reply-To: References: Message-ID: <1333884211-sup-7358@pinkfloyd.chass.utoronto.ca> Excerpts from jeff's message of Sun Apr 08 00:13:04 -0400 2012: Hi Jeff, > Just out of curiosity, what is the rationale behind the > proliferation of all these *_stub packages? From the few that I > have investigated, they mostly seem to contain only a single license > file. Why add all this package clutter? It seems as though they > can be removed without causing problems. I'm sure I must be missing > something. As Maciej mentioned, they're used only for transitions to provide a dependency path. On your system, you would have had CSWfoo/foo. When foo was updated to modern standards, it may have become CSWlibfoo1/libfoo1 and CSWfoo-dev/foo_dev. To allow for a clean upgrade path, CSWfoo/foo_stub was created with dependencies on the two new packages. Other uses of _stub packages are to fix names (CSWfoodev -> CSWfoo-dev) for standardization or just nicer style now that we have longer names to work with. The _stub packages can be safely removed once you've done the upgrade as the real parts of that package are elsewhere at that point. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sun Apr 8 16:07:36 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 08 Apr 2012 10:07:36 -0400 Subject: [csw-maintainers] xscreensaver and libkrb4.so.2 In-Reply-To: References: Message-ID: <1333893892-sup-1678@pinkfloyd.chass.utoronto.ca> Hi Jeff, > > Can xscreensaver please be repackaged to use the current library? > > Thanks. > > Have you tried respinning the build recipe from Subversion? The > package is currently orphaned, so if you care about this package, > it's the best way to get things moving forward. For fun, I spun this build. It's a non-GAR recipe that Phil wrote. Compilation is fine but I don't have stagepkg in my PATH and didn't poke around for it. It's likely a fairly easy update if you're interested. The noted discrepancy in the database isn't actually a discrepancy. The binaries in that package do depend on libkrb4, so they're still in the table that tracks that. Unfortunately, nothing provides that library any longer so there is a breakage. If you want/need this update, I'd suggest turning it into a GAR recipe and updating it to use the latest krb5 libs. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From jeff at cjsa.com Sun Apr 8 22:48:17 2012 From: jeff at cjsa.com (Jeffery Small) Date: Sun, 8 Apr 2012 20:48:17 GMT Subject: [csw-maintainers] Question about stub files References: Message-ID: >They are a byproduct of package splits and renames. They are required in >the catalog, and required during upgrades, but many can be removed later >on. Pkgutil knows which ones you can remove, see the --cleanup option. That's great. Thanks. I'm still migrating from pkg-get to pkgutil and wasn't aware of that option. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From bwalton at opencsw.org Mon Apr 9 02:49:34 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 08 Apr 2012 20:49:34 -0400 Subject: [csw-maintainers] Question about stub files In-Reply-To: References: Message-ID: <1333932403-sup-1151@pinkfloyd.chass.utoronto.ca> Excerpts from jeff's message of Sun Apr 08 16:48:17 -0400 2012: Hi Jeff, > That's great. Thanks. I'm still migrating from pkg-get to pkgutil > and wasn't aware of that option. Did you by any chance do your upgrade with pkg-get? If so, that would have potentially caused some of your problem. Due to the way it does the upgrade, you could have ended up with no libssl for chunks of the upgrade. That can wreak havoc much like what you described. The pkg-get upgrade process is a series of recursive remove/add steps, while the pkgutil upgrade is a series of iterative removals followed by iterative installs. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From jeff at cjsa.com Mon Apr 9 19:31:49 2012 From: jeff at cjsa.com (Jeffery Small) Date: Mon, 9 Apr 2012 17:31:49 GMT Subject: [csw-maintainers] Question about stub files References: <1333932403-sup-1151@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: >> That's great. Thanks. I'm still migrating from pkg-get to pkgutil >> and wasn't aware of that option. >Did you by any chance do your upgrade with pkg-get? If so, that would >have potentially caused some of your problem. Due to the way it does >the upgrade, you could have ended up with no libssl for chunks of the >upgrade. That can wreak havoc much like what you described. >The pkg-get upgrade process is a series of recursive remove/add steps, >while the pkgutil upgrade is a series of iterative removals followed >by iterative installs. Yes, I was still using pkg-get because I have a large perl script based upon it that integrates the upgrade/install process with local package caching for quick access to the records of installed packages. I did notice that midway through the upgrade process everything broke because the pkg-get script was renamed out from under me! It took some investigation to figure out what was happening and correct. I'm currently in the process of rewriting my script to use pkgutil in place of pkg-get. Too many tasks and not enought time! Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From maciej at opencsw.org Mon Apr 9 22:19:16 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 9 Apr 2012 21:19:16 +0100 Subject: [csw-maintainers] The dublin release: remaining tasks In-Reply-To: References: <7490fe1e4762.4f62f80c@contac-dt.de> <7490d3d657bb.4f630628@contac-dt.de> Message-ID: Status report request! - any serious breakages in the current catalog? - we need to investigate the krb5 issue - either rebuild deps or re-release the old lib - any reason not to release now that anyone knows of? - shall we make the release while in Bratislava? (And pop an actual champagne?) -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Mon Apr 9 22:24:01 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 9 Apr 2012 21:24:01 +0100 Subject: [csw-maintainers] Question about stub files In-Reply-To: References: <1333932403-sup-1151@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 9 de Abr de 2012 18:32, "Jeffery Small" escreveu: Out of curiosity, are you able to post from a non-opencsw email address? > Ben Walton writes: > > >> That's great. Thanks. I'm still migrating from pkg-get to pkgutil > >> and wasn't aware of that option. > > >Did you by any chance do your upgrade with pkg-get? If so, that would > >have potentially caused some of your problem. Due to the way it does > >the upgrade, you could have ended up with no libssl for chunks of the > >upgrade. That can wreak havoc much like what you described. > > >The pkg-get upgrade process is a series of recursive remove/add steps, > >while the pkgutil upgrade is a series of iterative removals followed > >by iterative installs. > > Yes, I was still using pkg-get because I have a large perl script based > upon it that integrates the upgrade/install process with local package > caching for quick access to the records of installed packages. I did > notice that midway through the upgrade process everything broke because the > pkg-get script was renamed out from under me! Sorry to hear that. We tried to make it as announced as possible, this was our last resort to tell the users that pkg-get is going away. > It took some investigation > to figure out what was happening and correct. I'm currently in the process > of rewriting my script to use pkgutil in place of pkg-get. Too many tasks > and not enought time! Hopefully the rewrite isn't hard, unless you do things like parsing stdout. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Mon Apr 9 22:34:12 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 9 Apr 2012 21:34:12 +0100 Subject: [csw-maintainers] The dublin release: remaining tasks In-Reply-To: References: <7490fe1e4762.4f62f80c@contac-dt.de> <7490d3d657bb.4f630628@contac-dt.de> Message-ID: One note about releasing packages this week: If anyone has any bugs to fix that would be only rev bumps (no version changes), now would be a good time. Your fix will go into Dublin. If you upload a version upgrade, it will not be integrated into Dublin and will not be in the Dublin release. So if you have a bug to fix, don't make a version bump at the same time. For example, I uploaded gcc-4.7 to unstable, but it won't be in Dublin. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeff at cjsa.com Mon Apr 9 23:50:45 2012 From: jeff at cjsa.com (Jeffery Small) Date: Mon, 9 Apr 2012 21:50:45 GMT Subject: [csw-maintainers] Question about stub files References: <1333932403-sup-1151@pinkfloyd.chass.utoronto.ca> Message-ID: " Maciej wrote: >Out of curiosity, are you able to post from a non-opencsw email address? Sorry, I'm not sure what you are getting at here? If you are asking about the health of my sendmail installation, then I have resolved all of my problems and everything is working fine on that front now. >>the pkg-get script was renamed out from under me! >Sorry to hear that. We tried to make it as announced as possible, this was >our last resort to tell the users that pkg-get is going away. I know that there has been some discussion about pkgutil previously. I just hadn't realized that pkg-get was seen as actually now being incompatible with the upgrade process. One thing to consider when making the next formal release would be to somehow force the upgrade to the pkg-get package to take precedence over all others. This way, pkg-get would be replaced with the notice about pkgutil before any other packages are downloaded and there would not be anything blowing up in the middle of the upgrade process. Another thought might be to replace pkg-get with a new small script that prints a warning about switching to pkgutil and then rewriting and issuing all pkg-get calls using pkgutil. I don't know how sensible this would be and whether this would cause great problems or not based upon the changes in the way package dependencies. I will be making a direct head-to-head comparison between the two tools in the next day or two. >> It took some investigation to figure out what was happening and correct. >> I'm currently in the process of rewriting my script to use pkgutil in >> place of pkg-get. Too many tasks and not enought time! >Hopefully the rewrite isn't hard, unless you do things like parsing stdout. It probably won't be too hard. It's just a matter of blocking out some time to get started! I hope I'm not coming off as too much of a complainer. I don't have time to work directly on packages these days, but I hope I can help a bit by being a canary in the coal mine and helpfully report problems before they make it out into the wild! Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From wilbury at opencsw.org Tue Apr 10 00:20:46 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Tue, 10 Apr 2012 00:20:46 +0200 Subject: [csw-maintainers] problem running mgar newpkg Message-ID: <4F8360BE.8080206@opencsw.org> Hi, I run: wilbury@[unstable10x.0 /home/wilbury/b]$ mgar newpkg ragel Creating package skeleton for ragel X.Y. A ragel A ragel/trunk A ragel/trunk/files A ragel/branches A ragel/tags Traceback (most recent call last): File "", line 1, in ? ImportError: No module named mako.template Do we have any cure on this? thanks. -- Juraj Lutter From skayser at opencsw.org Tue Apr 10 00:23:36 2012 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 10 Apr 2012 00:23:36 +0200 Subject: [csw-maintainers] problem running mgar newpkg In-Reply-To: <4F8360BE.8080206@opencsw.org> References: <4F8360BE.8080206@opencsw.org> Message-ID: <20120409222336.GR15375@sebastiankayser.de> * Juraj Lutter wrote: > wilbury@[unstable10x.0 /home/wilbury/b]$ mgar newpkg ragel > Creating package skeleton for ragel X.Y. > A ragel > A ragel/trunk > A ragel/trunk/files > A ragel/branches > A ragel/tags > Traceback (most recent call last): > File "", line 1, in ? > ImportError: No module named mako.template > > Do we have any cure on this? Yup, this should be able to help: pkgutil -i py_mako Curious, where did you get mgar from? If installed via pkgutil, this should have pulled in py_mako already via its dependency on gar_dev. Sebastian From wilbury at opencsw.org Tue Apr 10 00:27:27 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Tue, 10 Apr 2012 00:27:27 +0200 Subject: [csw-maintainers] problem running mgar newpkg In-Reply-To: <20120409222336.GR15375@sebastiankayser.de> References: <4F8360BE.8080206@opencsw.org> <20120409222336.GR15375@sebastiankayser.de> Message-ID: <4F83624F.8050300@opencsw.org> On 04/10/2012 12:23 AM, Sebastian Kayser wrote: > Yup, this should be able to help: > > pkgutil -i py_mako > > Curious, where did you get mgar from? If installed via pkgutil, this > should have pulled in py_mako already via its dependency on gar_dev. Running it on unstable10x box in buildfarm. -- Juraj Lutter From skayser at opencsw.org Tue Apr 10 00:28:42 2012 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 10 Apr 2012 00:28:42 +0200 Subject: [csw-maintainers] problem running mgar newpkg In-Reply-To: <20120409222336.GR15375@sebastiankayser.de> References: <4F8360BE.8080206@opencsw.org> <20120409222336.GR15375@sebastiankayser.de> Message-ID: <20120409222842.GS15375@sebastiankayser.de> * Sebastian Kayser wrote: > * Juraj Lutter wrote: > > wilbury@[unstable10x.0 /home/wilbury/b]$ mgar newpkg ragel > > Creating package skeleton for ragel X.Y. > > A ragel > > A ragel/trunk > > A ragel/trunk/files > > A ragel/branches > > A ragel/tags > > Traceback (most recent call last): > > File "", line 1, in ? > > ImportError: No module named mako.template > > > > Do we have any cure on this? > > Yup, this should be able to help: > > pkgutil -i py_mako > > Curious, where did you get mgar from? If installed via pkgutil, this > should have pulled in py_mako already via its dependency on gar_dev. On second thought, this could also happen if /opt/csw/bin is not first in path. I guess, mgar should make its PATH contain /opt/csw/bin first (and not prepend it as it does currently). Sebastian From skayser at opencsw.org Tue Apr 10 00:38:47 2012 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 10 Apr 2012 00:38:47 +0200 Subject: [csw-maintainers] problem running mgar newpkg In-Reply-To: <4F83624F.8050300@opencsw.org> References: <4F8360BE.8080206@opencsw.org> <20120409222336.GR15375@sebastiankayser.de> <4F83624F.8050300@opencsw.org> Message-ID: <20120409223847.GT15375@sebastiankayser.de> * Juraj Lutter wrote: > On 04/10/2012 12:23 AM, Sebastian Kayser wrote: > > Yup, this should be able to help: > > > > pkgutil -i py_mako > > > > Curious, where did you get mgar from? If installed via pkgutil, this > > should have pulled in py_mako already via its dependency on gar_dev. > > Running it on unstable10x box in buildfarm. Alright, py_mako is there, so - short of patching mgar - this should indeed only be a matter of putting /opt/csw/bin first in your $PATH. Sebastian From bwalton at opencsw.org Tue Apr 10 01:44:29 2012 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 09 Apr 2012 19:44:29 -0400 Subject: [csw-maintainers] catalog signing Message-ID: <1334014930-sup-5810@pinkfloyd.chass.utoronto.ca> Hi All, Does anyone object if I step in and re-instate the gpg agent's key while Maciej and Ihsan are indisposed? The policy indicates that the key was to be held by Treasurer and Secretary, so I've not touched it. Our catalogs are unsigned at the moment though and it doesn't look like it will be re-instated until the camp. If nobody objects, I can intervene for the time being... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Tue Apr 10 09:09:47 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 10 Apr 2012 08:09:47 +0100 Subject: [csw-maintainers] problem running mgar newpkg In-Reply-To: <20120409223847.GT15375@sebastiankayser.de> References: <4F8360BE.8080206@opencsw.org> <20120409222336.GR15375@sebastiankayser.de> <4F83624F.8050300@opencsw.org> <20120409223847.GT15375@sebastiankayser.de> Message-ID: No dia 9 de Abr de 2012 23:38, "Sebastian Kayser" escreveu: > > * Juraj Lutter wrote: > > On 04/10/2012 12:23 AM, Sebastian Kayser wrote: > > > Yup, this should be able to help: > > > > > > pkgutil -i py_mako > > > > > > Curious, where did you get mgar from? If installed via pkgutil, this > > > should have pulled in py_mako already via its dependency on gar_dev. > > > > Running it on unstable10x box in buildfarm. > > Alright, py_mako is there, so - short of patching mgar - this should > indeed only be a matter of putting /opt/csw/bin first in your $PATH. I thought that having it in front is what you always do unless you want to break things. Is it about /opt/csw/bin/python vs /usr/bin/python? In most scripts I write: /use/bin/env python2.6 Since there isn't a 2.6 Python on Solaris, this always picks the right Python on both Solaris and Linux. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilbury at opencsw.org Tue Apr 10 09:59:24 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Tue, 10 Apr 2012 09:59:24 +0200 Subject: [csw-maintainers] problem running mgar newpkg In-Reply-To: References: <4F8360BE.8080206@opencsw.org> <20120409222336.GR15375@sebastiankayser.de> <4F83624F.8050300@opencsw.org> <20120409223847.GT15375@sebastiankayser.de> Message-ID: <4F83E85C.6010508@opencsw.org> On 04/10/2012 09:09 AM, Maciej (Matchek) Blizi?ski wrote: > I thought that having it in front is what you always do unless you want > to break things. This one did the job. Thanks. -- Juraj Lutter From bonivart at opencsw.org Tue Apr 10 10:28:27 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 10 Apr 2012 10:28:27 +0200 Subject: [csw-maintainers] catalog signing In-Reply-To: <1334014930-sup-5810@pinkfloyd.chass.utoronto.ca> References: <1334014930-sup-5810@pinkfloyd.chass.utoronto.ca> Message-ID: On Tue, Apr 10, 2012 at 1:44 AM, Ben Walton wrote: > > Hi All, > > Does anyone object if I step in and re-instate the gpg agent's key > while Maciej and Ihsan are indisposed? ?The policy indicates that the > key was to be held by Treasurer and Secretary, so I've not touched it. > Our catalogs are unsigned at the moment though and it doesn't look > like it will be re-instated until the camp. > > If nobody objects, I can intervene for the time being... Please do. :) From bonivart at opencsw.org Tue Apr 10 10:33:59 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 10 Apr 2012 10:33:59 +0200 Subject: [csw-maintainers] Question about stub files In-Reply-To: References: <1333932403-sup-1151@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Apr 9, 2012 at 11:50 PM, Jeffery Small wrote: > I know that there has been some discussion about pkgutil previously. > I just hadn't realized that pkg-get was seen as actually now being > incompatible with the upgrade process. ?One thing to consider when making > the next formal release would be to somehow force the upgrade to the > pkg-get package to take precedence over all others. ?This way, pkg-get > would be replaced with the notice about pkgutil before any other packages > are downloaded and there would not be anything blowing up in the middle > of the upgrade process. I don't think we can do anything like that since Phil doesn't allow changes to his script as far as I know. That's the main reason behind fully deprecating pkg-get, that we can't move on when one of the tools are unsupported by its author and doesn't allow for changes by the community. > I will be making a direct head-to-head > comparison between the two tools in the next day or two. I'm interested in your findings, please post some summary. > I hope I'm not coming off as too much of a complainer. ?I don't have time > to work directly on packages these days, but I hope I can help a bit by > being a canary in the coal mine and helpfully report problems before they > make it out into the wild! All help is appreciated! :) /peter From dam at opencsw.org Tue Apr 10 11:13:18 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 10 Apr 2012 11:13:18 +0200 Subject: [csw-maintainers] Question about stub files In-Reply-To: References: <1333932403-sup-1151@pinkfloyd.chass.utoronto.ca> Message-ID: <1CEDEBE9-C4B9-4B4E-BF7B-AD539EE66923@opencsw.org> Hi, Am 10.04.2012 um 10:33 schrieb Peter Bonivart: > On Mon, Apr 9, 2012 at 11:50 PM, Jeffery Small wrote: >> I know that there has been some discussion about pkgutil previously. >> I just hadn't realized that pkg-get was seen as actually now being >> incompatible with the upgrade process. One thing to consider when making >> the next formal release would be to somehow force the upgrade to the >> pkg-get package to take precedence over all others. This way, pkg-get >> would be replaced with the notice about pkgutil before any other packages >> are downloaded and there would not be anything blowing up in the middle >> of the upgrade process. > > I don't think we can do anything like that since Phil doesn't allow > changes to his script as far as I know. That's the main reason behind > fully deprecating pkg-get, that we can't move on when one of the tools > are unsupported by its author and doesn't allow for changes by the > community. We already replaced pkg-get with such a stub. The problem is that pkg-get does not updates itself first, so every user that has an old copy of pkg-get almost certainly breaks update and there is nothing we can do about it. This was one of the reasons why we deprecated pkg-get. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From bwalton at opencsw.org Tue Apr 10 15:27:57 2012 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 10 Apr 2012 09:27:57 -0400 Subject: [csw-maintainers] Question about stub files In-Reply-To: References: <1333932403-sup-1151@pinkfloyd.chass.utoronto.ca> Message-ID: <1334064400-sup-4922@pinkfloyd.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Tue Apr 10 04:33:59 -0400 2012: > On Mon, Apr 9, 2012 at 11:50 PM, Jeffery Small wrote: > > I know that there has been some discussion about pkgutil > > previously. I just hadn't realized that pkg-get was seen as > > actually now being incompatible with the upgrade process. ?One > > thing to consider when making the next formal release would be to > > somehow force the upgrade to the pkg-get package to take > > precedence over all others. ?This way, pkg-get would be replaced > > with the notice about pkgutil before any other packages are > > downloaded and there would not be anything blowing up in the > > middle of the upgrade process. > > I don't think we can do anything like that since Phil doesn't allow > changes to his script as far as I know. That's the main reason > behind fully deprecating pkg-get, that we can't move on when one of > the tools are unsupported by its author and doesn't allow for > changes by the community. Yes, we're limited in what we can do here. Communication is the only tool we've got. We can make more announcements and posts once we cut the dublin release (hopefully at the camp). Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From jeff at cjsa.com Wed Apr 11 14:54:11 2012 From: jeff at cjsa.com (Jeffery Small) Date: Wed, 11 Apr 2012 12:54:11 GMT Subject: [csw-maintainers] Notes on pkgutil vs. pkg-get Message-ID: Someone asked for anything I learned while comparing pkgutil to pkg-get. Here are a few brief notes for whatever it use it may be. 1) pkg-get had a -S (sync) option that does not exists in pkgutil. However, the -f (force) option probably does the same thing, and hopefully better. There is a -S option that can be assigned as part of pkgaddopts to suppress printing of the license files. I don't know if this will cause anyone any problems. It should probably be documented somewhere. 2) The pkgutil naming of the catalog and descriptions files is quite different from pkg-get. Additionally, the new catalog file has the new hash and PGP signature lines at the head and the tail. Most of these lines are not typical "#" comment lines. Therefore, pkg-get routines that look for these files and parse the content will not work without some modification. 3) The "-s url" option in pkg-get is now "-t url". Those were the major changes that I noticed. By the way, when using the -f option to roll back a package, let's say from unstable to testing, will this also automatically roll back all dependencies as well? However this works, it would be good to document it fully so that there is no question as to what you are doing when using it. I hope this info is of some help. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From jh at opencsw.org Wed Apr 11 15:36:57 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Wed, 11 Apr 2012 15:36:57 +0200 Subject: [csw-maintainers] Samba update (The dublin release: remaining tasks) In-Reply-To: References: <7490fe1e4762.4f62f80c@contac-dt.de> <7490d3d657bb.4f630628@contac-dt.de> Message-ID: <4F8588F9.8010907@opencsw.org> Hi, I just pushed a new release of samba to unstable. Since it is a security release and only fixes: CVE-2012-1182 ( http://www.samba.org/samba/history/samba-3.6.4.html ) it should be pushed to dublin. Greetings Jan Am 09.04.12 22:34, schrieb Maciej (Matchek) Blizi?ski: > One note about releasing packages this week: > > If anyone has any bugs to fix that would be only rev bumps (no version > changes), now would be a good time. Your fix will go into Dublin. If you > upload a version upgrade, it will not be integrated into Dublin and will > not be in the Dublin release. So if you have a bug to fix, don't make a > version bump at the same time. > > For example, I uploaded gcc-4.7 to unstable, but it won't be in Dublin. > > Maciej > > > > _______________________________________________ > 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 Wed Apr 11 20:09:36 2012 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 11 Apr 2012 14:09:36 -0400 Subject: [csw-maintainers] Notes on pkgutil vs. pkg-get In-Reply-To: References: Message-ID: <1334167665-sup-9735@pinkfloyd.chass.utoronto.ca> Excerpts from jeff's message of Wed Apr 11 08:54:11 -0400 2012: Hi Jeff, > 3) The "-s url" option in pkg-get is now "-t url". An important distinction between these two options is that pkg-get would _only_ consider packages at the alternate url. Thus, you didn't get any required dependency updates from the main catalog. With pkgutil, on the other hand, you get your primary catalog, with this temporary catalog overlaid. That means you'll get any packages from the temporary url and any dependencies that may live in the main catalog. It's much more useful this way. :) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From wilbury at opencsw.org Wed Apr 11 21:26:13 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Wed, 11 Apr 2012 21:26:13 +0200 Subject: [csw-maintainers] wintercamp Message-ID: <4F85DAD5.5030108@opencsw.org> Hi folks, sorry for so late response, I was way too overworked and overloaded past weeks in addition to some serious health problem of my girlfriend. I want to know how estimated time of arrival of each attendee so I can organize your transfer from airport to the hotel. Regarding hotel, Saffron seems like a solid and decent choice, it's brand new, I personally have not been there nor have I any feedback. Regarding agenda, I am at work at Friday, probably until 14:00 or 15:00, depends on my workload. Then I can assist you in sightseeing, barseeing, and so on. At Saturday and Sunday we will be at my employer's meeting room instead of Progressbar (don't ask me why, it just happened that way, I will probably make it clear personally.) When is your estimated departure? Do I have to drop you to the airport/railway station? Just let me know please. Looking forward to see you all! :-) -- Juraj Lutter From dam at opencsw.org Wed Apr 11 21:46:52 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 11 Apr 2012 21:46:52 +0200 Subject: [csw-maintainers] wintercamp In-Reply-To: <4F85DAD5.5030108@opencsw.org> References: <4F85DAD5.5030108@opencsw.org> Message-ID: <86B85A21-53C2-47DF-B718-7E7B0C67EDC9@opencsw.org> Hi Juraj, Am 11.04.2012 um 21:26 schrieb Juraj Lutter : > Hi folks, > > sorry for so late response, I was way too overworked and overloaded past > weeks in addition to some serious health problem of my girlfriend. > > I want to know how estimated time of arrival of each attendee so I can > organize your transfer from airport to the hotel. I am arriving via train from Vienna Friday morning 11:32 and will meet up with Maciej at the hotel. > > Regarding hotel, Saffron seems like a solid and decent choice, it's > brand new, I personally have not been there nor have I any feedback. > > Regarding agenda, I am at work at Friday, probably until 14:00 or 15:00, > depends on my workload. Then I can assist you in sightseeing, barseeing, > and so on. At Saturday and Sunday we will be at my employer's meeting > room instead of Progressbar (don't ask me why, it just happened that > way, I will probably make it clear personally.) We will probably start hacking right away at the hotel and may move to your company sometime in Friday. > > When is your estimated departure? Do I have to drop you to the > airport/railway station? Just let me know please. My train departs on Monday at 11:46 back to Vienna, so plenty of time :-) Best regards -- Dago > > Looking forward to see you all! :-) > > -- > Juraj Lutter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From wilbury at opencsw.org Wed Apr 11 21:57:11 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Wed, 11 Apr 2012 21:57:11 +0200 Subject: [csw-maintainers] wintercamp In-Reply-To: <86B85A21-53C2-47DF-B718-7E7B0C67EDC9@opencsw.org> References: <4F85DAD5.5030108@opencsw.org> <86B85A21-53C2-47DF-B718-7E7B0C67EDC9@opencsw.org> Message-ID: <4F85E217.20305@opencsw.org> On 04/11/2012 09:46 PM, Dagobert Michelsen wrote: > We will probably start hacking right away at the hotel and may move to your company sometime in Friday. > >> >> When is your estimated departure? Do I have to drop you to the >> airport/railway station? Just let me know please. > > My train departs on Monday at 11:46 back to Vienna, so plenty of time :-) > Just for the record, my GSM number is +421-907-986-576 -- Juraj Lutter From jeff at cjsa.com Wed Apr 11 22:23:05 2012 From: jeff at cjsa.com (Jeffery Small) Date: Wed, 11 Apr 2012 20:23:05 GMT Subject: [csw-maintainers] Notes on pkgutil vs. pkg-get References: <1334167665-sup-9735@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: >Excerpts from jeff's message of Wed Apr 11 08:54:11 -0400 2012: >> 3) The "-s url" option in pkg-get is now "-t url". >An important distinction between these two options is that pkg-get >would _only_ consider packages at the alternate url. Thus, you didn't >get any required dependency updates from the main catalog. >With pkgutil, on the other hand, you get your primary catalog, with >this temporary catalog overlaid. That means you'll get any packages >from the temporary url and any dependencies that may live in the main >catalog. It's much more useful this way. :) Thanks Ben. That's very good to know! Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From bonivart at opencsw.org Wed Apr 11 22:32:19 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 11 Apr 2012 22:32:19 +0200 Subject: [csw-maintainers] Notes on pkgutil vs. pkg-get In-Reply-To: References: <1334167665-sup-9735@pinkfloyd.chass.utoronto.ca> Message-ID: On Wed, Apr 11, 2012 at 10:23 PM, Jeffery Small wrote: > Ben Walton writes: > >>Excerpts from jeff's message of Wed Apr 11 08:54:11 -0400 2012: > >>> 3) ?The "-s url" option in pkg-get is now "-t url". > >>An important distinction between these two options is that pkg-get >>would _only_ consider packages at the alternate url. ?Thus, you didn't >>get any required dependency updates from the main catalog. > >>With pkgutil, on the other hand, you get your primary catalog, with >>this temporary catalog overlaid. ?That means you'll get any packages >>from the temporary url and any dependencies that may live in the main >>catalog. ?It's much more useful this way. :) > > Thanks Ben. ?That's very good to know! The most obvious example of that would be our experimental repo: http://buildfarm.opencsw.org/experimental.html /peter From rupert at opencsw.org Wed Apr 11 22:36:53 2012 From: rupert at opencsw.org (rupert THURNER) Date: Wed, 11 Apr 2012 22:36:53 +0200 Subject: [csw-maintainers] gar, checkpkg and subversion ... bratislava? In-Reply-To: References: Message-ID: hi, tried to build svn-1.7.4 ... and the result were a lot of checkpkg errors which looked correct ... but i am unsure where they came from, see here: http://sourceforge.net/apps/trac/gar/changeset/17593/csw the subversion lists feedback was: do not build with subversion installed. we do build with subversion installed. would it be possible that you could find a solution in bratislava how to handle this in future? rupert From bwalton at opencsw.org Wed Apr 11 22:44:31 2012 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 11 Apr 2012 16:44:31 -0400 Subject: [csw-maintainers] gar, checkpkg and subversion ... bratislava? In-Reply-To: References: Message-ID: <1334176970-sup-6241@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Wed Apr 11 16:36:53 -0400 2012: Hi Rupert, > the subversion lists feedback was: do not build with subversion > installed. we do build with subversion installed. would it be > possible that you could find a solution in bratislava how to handle > this in future? That seems like a pretty awful requirement. We _should_ be able to find something that's sane/reasonable. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Thu Apr 12 00:50:01 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 11 Apr 2012 23:50:01 +0100 Subject: [csw-maintainers] gar, checkpkg and subversion ... bratislava? In-Reply-To: <1334176970-sup-6241@pinkfloyd.chass.utoronto.ca> References: <1334176970-sup-6241@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 11 de Abr de 2012 21:44, "Ben Walton" escreveu: > > Excerpts from rupert THURNER's message of Wed Apr 11 16:36:53 -0400 2012: > > Hi Rupert, > > > the subversion lists feedback was: do not build with subversion > > installed. we do build with subversion installed. would it be > > possible that you could find a solution in bratislava how to handle > > this in future? > > That seems like a pretty awful requirement. We _should_ be able to > find something that's sane/reasonable. Linking against chosen library may be tricky, but why should subversion not manage that while other software projects manage to do that without problems? Maybe it's a deeply rooted problem, but I don't see why it should be deemed unsolvable. Maybe the subversion build code needs to be reviewed by a lib tool expert? Can we arrange something like that? Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Thu Apr 12 05:06:19 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 12 Apr 2012 05:06:19 +0200 Subject: [csw-maintainers] wintercamp In-Reply-To: <4F85E217.20305@opencsw.org> References: <4F85DAD5.5030108@opencsw.org> <86B85A21-53C2-47DF-B718-7E7B0C67EDC9@opencsw.org> <4F85E217.20305@opencsw.org> Message-ID: Am 11.04.2012 um 21:57 schrieb Juraj Lutter : > On 04/11/2012 09:46 PM, Dagobert Michelsen wrote: >> We will probably start hacking right away at the hotel and may move to your company sometime in Friday. >> >>> >>> When is your estimated departure? Do I have to drop you to the >>> airport/railway station? Just let me know please. >> >> My train departs on Monday at 11:46 back to Vienna, so plenty of time :-) >> > > > Just for the record, my GSM number is +421-907-986-576 +49 170 4457772 Best regards -- Dago > > > -- > Juraj Lutter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From grzemba at contac-dt.de Thu Apr 12 08:24:46 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Thu, 12 Apr 2012 08:24:46 +0200 Subject: [csw-maintainers] wintercamp In-Reply-To: <7430b2904d9b.4f8674f4@contac-dt.de> References: <7430b2904d9b.4f8674f4@contac-dt.de> Message-ID: <7430d95a2d2a.4f86914e@contac-dt.de> Hi Juraj, I am arriving via train from Vienna Friday? evening 19:32 and will walk to the hotel Regards Carsten Am 11.04.12, schrieb Juraj Lutter : > Hi folks, > > sorry for so late response, I was way too overworked and overloaded past > weeks in addition to some serious health problem of my girlfriend. > > I want to know how estimated time of arrival of each attendee so I can > organize your transfer from airport to the hotel. > > Regarding hotel, Saffron seems like a solid and decent choice, it's > brand new, I personally have not been there nor have I any feedback. > > Regarding agenda, I am at work at Friday, probably until 14:00 or 15:00, > depends on my workload. Then I can assist you in sightseeing, barseeing, > and so on. At Saturday and Sunday we will be at my employer's meeting > room instead of Progressbar (don't ask me why, it just happened that > way, I will probably make it clear personally.) > > When is your estimated departure? Do I have to drop you to the > airport/railway station? Just let me know please. > > Looking forward to see you all! :-) > > -- > Juraj Lutter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > > -- Carsten Grzemba Mobil: +49 171 9749479 Email: carsten.grzemba at contac-dt.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Thu Apr 12 08:46:47 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 12 Apr 2012 07:46:47 +0100 Subject: [csw-maintainers] wintercamp In-Reply-To: <7430d95a2d2a.4f86914e@contac-dt.de> References: <7430b2904d9b.4f8674f4@contac-dt.de> <7430d95a2d2a.4f86914e@contac-dt.de> Message-ID: No dia 12 de Abr de 2012 07:25, "Carsten Grzemba" escreveu: > > Hi Juraj, > > I am arriving via train from Vienna Friday evening 19:32 and will walk to the hotel 7000 meters or so? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilbury at opencsw.org Thu Apr 12 09:12:12 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Thu, 12 Apr 2012 09:12:12 +0200 Subject: [csw-maintainers] wintercamp In-Reply-To: References: <7430b2904d9b.4f8674f4@contac-dt.de> <7430d95a2d2a.4f86914e@contac-dt.de> Message-ID: <4F86804C.4090500@opencsw.org> On 04/12/2012 08:46 AM, Maciej (Matchek) Blizi?ski wrote: > > No dia 12 de Abr de 2012 07:25, "Carsten Grzemba" > escreveu: >> >> Hi Juraj, >> >> I am arriving via train from Vienna Friday evening 19:32 and will > walk to the hotel > > 7000 meters or so? No, it's not 7000 meters, it's shorter trip, but when you are not familiar with orientation in (not only) Bratislava, you can easily get lost. Anyway, I can pick you up. -- Juraj Lutter From maciej at opencsw.org Thu Apr 12 09:17:54 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 12 Apr 2012 08:17:54 +0100 Subject: [csw-maintainers] wintercamp In-Reply-To: <4F86804C.4090500@opencsw.org> References: <7430b2904d9b.4f8674f4@contac-dt.de> <7430d95a2d2a.4f86914e@contac-dt.de> <4F86804C.4090500@opencsw.org> Message-ID: No dia 12 de Abr de 2012 08:12, "Juraj Lutter" escreveu: > > On 04/12/2012 08:46 AM, Maciej (Matchek) Blizi?ski wrote: > > > > No dia 12 de Abr de 2012 07:25, "Carsten Grzemba" > > escreveu: > >> > >> Hi Juraj, > >> > >> I am arriving via train from Vienna Friday evening 19:32 and will > > walk to the hotel > > > > 7000 meters or so? > > No, it's not 7000 meters, it's shorter trip, but when you are not > familiar with orientation in (not only) Bratislava, you can easily get > lost. Anyway, I can pick you up. My flight details are: GOING OUT From Dublin(DUB) to Bratislava(BTS) Fri, 13/April/2012 Flight 4282 Depart DUB at 0650 and arrive BTS at 1030 COMING BACK From Bratislava(BTS) to Dublin (DUB) Mon, 16/April/2012 Flight 4283 Depart BTS at 1045 and arrive DUB at 1235 You are working in these hours, I can probably manage to get into the center if I have some directions. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilbury at opencsw.org Thu Apr 12 10:19:56 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Thu, 12 Apr 2012 10:19:56 +0200 Subject: [csw-maintainers] wintercamp In-Reply-To: References: <7430b2904d9b.4f8674f4@contac-dt.de> <7430d95a2d2a.4f86914e@contac-dt.de> <4F86804C.4090500@opencsw.org> Message-ID: <4F86902C.9050308@opencsw.org> On 04/12/2012 09:17 AM, Maciej (Matchek) Blizi?ski wrote: > My flight details are: > > GOING OUT From Dublin(DUB) to Bratislava(BTS) Fri, 13/April/2012 Flight > 4282 Depart DUB at 0650 and arrive BTS at 1030 > > COMING BACK From Bratislava(BTS) to Dublin (DUB) Mon, 16/April/2012 > Flight 4283 Depart BTS at 1045 and arrive DUB at 1235 > > You are working in these hours, I can probably manage to get into the > center if I have some directions. If it comes to pick you up, drop you to the hotel and return back to work, that is not a big problem :-) Weather forecast yields rain so I can probably save you from it ;-) j. -- Juraj Lutter From bonivart at opencsw.org Thu Apr 12 18:22:28 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 12 Apr 2012 18:22:28 +0200 Subject: [csw-maintainers] Notes on pkgutil vs. pkg-get In-Reply-To: References: Message-ID: On Wed, Apr 11, 2012 at 2:54 PM, Jeffery Small wrote: > 1) ?pkg-get had a -S (sync) option that does not exists in pkgutil. > ? ?However, the -f (force) option probably does the same thing, and > ? ?hopefully better. ?There is a -S option that can be assigned as part > ? ?of pkgaddopts to suppress printing of the license files. ?I don't > ? ?know if this will cause anyone any problems. ?It should probably be > ? ?documented somewhere. The -S for pkgaddopts in pkgutil.conf is fed directly to the pkgadd command and is an undocumented feature in Solaris that supresses the copyright. Even though we like the GPL I think most of us hate having it being displayed over and over again, Phil liked it like that but I don't see Linux dists displaying the copyright at install time either. So it's unrelated to the pkg-get -S option. I'll get back to some of your other comments. /peter From bwalton at opencsw.org Thu Apr 12 18:28:57 2012 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 12 Apr 2012 12:28:57 -0400 Subject: [csw-maintainers] Notes on pkgutil vs. pkg-get In-Reply-To: References: Message-ID: <1334248113-sup-3586@pinkfloyd.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Thu Apr 12 12:22:28 -0400 2012: > The -S for pkgaddopts in pkgutil.conf is fed directly to the pkgadd > command and is an undocumented feature in Solaris that supresses the > copyright. Even though we like the GPL I think most of us hate > having it being displayed over and over again, Phil liked it like > that but I don't see Linux dists displaying the copyright at install > time either. +1 for this. It was way too noisy with the license spewed out. :) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From jeff at cjsa.com Thu Apr 12 21:13:18 2012 From: jeff at cjsa.com (Jeffery Small) Date: Thu, 12 Apr 2012 19:13:18 GMT Subject: [csw-maintainers] Notes on pkgutil vs. pkg-get References: <1334248113-sup-3586@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: >Excerpts from Peter Bonivart's message of Thu Apr 12 12:22:28 -0400 2012: >> The -S for pkgaddopts in pkgutil.conf is fed directly to the pkgadd >> command and is an undocumented feature in Solaris that supresses the >> copyright. Even though we like the GPL I think most of us hate >> having it being displayed over and over again, Phil liked it like >> that but I don't see Linux dists displaying the copyright at install >> time either. >+1 for this. It was way too noisy with the license spewed out. :) Agreed! Thanks for the option. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From maciej at opencsw.org Fri Apr 13 07:33:29 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 13 Apr 2012 06:33:29 +0100 Subject: [csw-maintainers] wintercamp In-Reply-To: <4F86902C.9050308@opencsw.org> References: <7430b2904d9b.4f8674f4@contac-dt.de> <7430d95a2d2a.4f86914e@contac-dt.de> <4F86804C.4090500@opencsw.org> <4F86902C.9050308@opencsw.org> Message-ID: http://wiki.opencsw.org/wintercamp-2011 I just updated the topic list. If any of you wants another topic to be discussed, please add it to the list on the wiki. The deadline is Saturday 10:00 CEST. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sat Apr 14 15:25:40 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 14 Apr 2012 14:25:40 +0100 Subject: [csw-maintainers] Fwd: Wintercamp 2011 is this weekend In-Reply-To: References: Message-ID: A repost from users at . ---------- Mensagem encaminhada ---------- De: Maciej (Matchek) Blizi?ski Data: 14 de Abril de 2012 09:44 Assunto: Re: Wintercamp 2011 is this weekend Para: OpenCSW users The first day is starting. We've initiated a hangout on G+ (look for the +OpenCSW page; it's a multi-way video conference). The meeting minutes viewable are at: https://docs.google.com/document/d/1C1uTlJj2-0H3kNZzEQUUjZL298WOxz6kQTr72zIiEe8/edit Our G+ page: https://plus.google.com/101553438503824697034 We're also monitoring the #opencsw IRC channel. If you have any questions, join in and ask. Take the advantage of project members being in one place! Maciej From maciej at opencsw.org Sat Apr 14 19:47:13 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 14 Apr 2012 19:47:13 +0200 Subject: [csw-maintainers] Announce support for pkgutil Message-ID: Hi Peter, Here's a proposed bit of logic for pkgutil: if it tries to get the catalog file and gets a 404, it could look for 00ANNOUNCE and if it's present, display the contents to the user and exit with status code > 0. It would handle this kind of a situation: http://buildfarm.opencsw.org/opencsw/stable-mockup/ More context: killing stable release in the wintercamp minutes. https://docs.google.com/document/d/1C1uTlJj2-0H3kNZzEQUUjZL298WOxz6kQTr72zIiEe8/edit What do you think? Maciej From bonivart at opencsw.org Sat Apr 14 21:17:11 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Sat, 14 Apr 2012 21:17:11 +0200 Subject: [csw-maintainers] Announce support for pkgutil In-Reply-To: References: Message-ID: 2012/4/14 Maciej (Matchek) Blizi?ski : > Hi Peter, > > Here's a proposed bit of logic for pkgutil: if it tries to get the > catalog file and gets a 404, it could look for 00ANNOUNCE and if it's > present, display the contents to the user and exit with status code > > 0. It would handle this kind of a situation: > http://buildfarm.opencsw.org/opencsw/stable-mockup/ > > More context: killing stable release in the wintercamp minutes. > https://docs.google.com/document/d/1C1uTlJj2-0H3kNZzEQUUjZL298WOxz6kQTr72zIiEe8/edit > > What do you think? I'm not sure wget can really tell me a 404 occurred, I think it's just an exit code for "server error" which I think we can assume is a 404 and try for 00ANNOUNCE. If there's a more serious error the worst case is that wget will fail again I guess. /peter From maciej at opencsw.org Sat Apr 14 21:19:31 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 14 Apr 2012 21:19:31 +0200 Subject: [csw-maintainers] Announce support for pkgutil In-Reply-To: References: Message-ID: No dia 14 de Abril de 2012 21:17, Peter Bonivart escreveu: > I'm not sure wget can really tell me a 404 occurred, I somehow thought that you're doing a call directly from perl. > I think it's just > an exit code for "server error" which I think we can assume is a 404 > and try for 00ANNOUNCE. If there's a more serious error the worst case > is that wget will fail again I guess. That would work. From bwalton at opencsw.org Sat Apr 14 23:14:49 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 14 Apr 2012 17:14:49 -0400 Subject: [csw-maintainers] [csw-users] whole catalog atom feeds In-Reply-To: References: <1332716390-sup-2086@pinkfloyd.chass.utoronto.ca> <3985B3C9-010F-4F41-88ED-402E0AF4A19B@opencsw.org> Message-ID: <1334437310-sup-5402@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Fri Apr 13 09:42:25 -0400 2012: > What's the current status? Have they been added? I'm applying a stylesheet to do the transformation between formats. There are a few things the linter has picked up that I want to address and then I'll make them live. I should be done tonight. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sun Apr 15 02:46:23 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 14 Apr 2012 20:46:23 -0400 Subject: [csw-maintainers] [csw-users] whole catalog atom feeds In-Reply-To: <1334437310-sup-5402@pinkfloyd.chass.utoronto.ca> References: <1332716390-sup-2086@pinkfloyd.chass.utoronto.ca> <3985B3C9-010F-4F41-88ED-402E0AF4A19B@opencsw.org> <1334437310-sup-5402@pinkfloyd.chass.utoronto.ca> Message-ID: <1334450762-sup-3009@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Sat Apr 14 17:14:49 -0400 2012: > I'm applying a stylesheet to do the transformation between formats. > There are a few things the linter has picked up that I want to > address and then I'll make them live. I should be done tonight. These are now in place and should be maintained in sync with the atom feeds. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bonivart at opencsw.org Sun Apr 15 09:14:09 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 15 Apr 2012 09:14:09 +0200 Subject: [csw-maintainers] Announce support for pkgutil In-Reply-To: References: Message-ID: 2012/4/14 Maciej (Matchek) Blizi?ski : > I somehow thought that you're doing a call directly from perl. No, that would require depending on Perl modules not in core Perl. Lots of things could be done differently if I had the luxury of using any CPAN module. :) /peter From dam at opencsw.org Sun Apr 15 10:35:31 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 15 Apr 2012 10:35:31 +0200 Subject: [csw-maintainers] Unified package listing needed Message-ID: <4EC79363-EBC4-4427-A0CF-65E3CE91D6AC@opencsw.org> Hi, I noticed that some packages do not have a webpage, e.g. http://mirror.opencsw.org/opencsw/unstable/sparc/5.10/pm_dbd_sybase_ocs-1.11%2cREV%3d2010.11.23-SunOS5.9-sparc-CSW.pkg.gz While there is http://www.opencsw.org/packages/CSWpm-dbd-sybase-freetds/ there also should be http://www.opencsw.org/packages/CSWpm-dbd-sybase-ocs/ I guess this is because the data is taken from the x86 catalog only? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From bwalton at opencsw.org Sun Apr 15 14:53:51 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 15 Apr 2012 08:53:51 -0400 Subject: [csw-maintainers] Announce support for pkgutil In-Reply-To: References: Message-ID: <1334494374-sup-6534@pinkfloyd.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Sun Apr 15 03:14:09 -0400 2012: > No, that would require depending on Perl modules not in core Perl. > Lots of things could be done differently if I had the luxury of > using any CPAN module. :) Does the picture change if you ignore the older best-effort releases? I know you strive to make pkgutil work on as many targets as possible, I'm just asking the question. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sun Apr 15 15:31:58 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 15 Apr 2012 09:31:58 -0400 Subject: [csw-maintainers] Unified package listing needed In-Reply-To: <4EC79363-EBC4-4427-A0CF-65E3CE91D6AC@opencsw.org> References: <4EC79363-EBC4-4427-A0CF-65E3CE91D6AC@opencsw.org> Message-ID: <1334496578-sup-7778@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Sun Apr 15 04:35:31 -0400 2012: > I guess this is because the data is taken from the x86 catalog only? Yes, that's the reason. Let me talk to a colleague who deals with OLAP stuff about good table structures for this data and nice ways of presenting it. We should be able to develop this side-by-side using entirely new tables. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From grzemba at contac-dt.de Mon Apr 16 17:55:17 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Mon, 16 Apr 2012 17:55:17 +0200 Subject: [csw-maintainers] Script for check package db consistence Message-ID: <7470c5f93033.4f8c5d05@contac-dt.de> Hi, I create a script which check, if all needed libs for a CSW package are delivered by a other (depended) CSW package (xscreensaver problem with libkrb4) I analyze the catalog data for this with the script. ? @Maciej: But my first test delivers also this libs: libc.so.1 not found, needed in pkg CSWaalib libm.so.1 not found, needed in pkg CSWaalib libsocket.so.1 not found, needed in pkg CSWaalib libnsl.so.1 not found, needed in pkg CSWaalib I think we should have something like a white list for Solaris standard libs, what do you mean? -- Carsten Grzemba -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Mon Apr 16 19:24:09 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 16 Apr 2012 18:24:09 +0100 Subject: [csw-maintainers] Spring cleaning Message-ID: One thought about the spring cleaning we did: When we were dropping packages, we were dropping them from the 5.9 and the 5.10 catalog. With packages such as Firefox, the argument is that a newer Firefox is available from elsewhere. However, it's only true for Solaris 10, not for Solaris 9. I don't think there is a Firefox for Solaris 9. Therefore, maybe we should not drop some of the packages from the 5.9 catalog? Thoughts? Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Mon Apr 16 19:27:06 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 16 Apr 2012 18:27:06 +0100 Subject: [csw-maintainers] Script for check package db consistence In-Reply-To: <7470c5f93033.4f8c5d05@contac-dt.de> References: <7470c5f93033.4f8c5d05@contac-dt.de> Message-ID: No dia 16 de Abril de 2012 16:55, Carsten Grzemba escreveu: > > libc.so.1 not found, needed in pkg CSWaalib > libm.so.1 not found, needed in pkg CSWaalib > libsocket.so.1 not found, needed in pkg CSWaalib > libnsl.so.1 not found, needed in pkg CSWaalib > > I think we should have something like a white list for Solaris standard libs, > what do you mean? Yes, you can make a whitelist based on the contents of /usr/lib. Maciej From grzemba at contac-dt.de Mon Apr 16 19:29:49 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Mon, 16 Apr 2012 19:29:49 +0200 Subject: [csw-maintainers] Spring cleaning In-Reply-To: <7430eb0a6c17.4f8c56fd@contac-dt.de> References: <7430eb0a6c17.4f8c56fd@contac-dt.de> Message-ID: <7430dca96916.4f8c732d@contac-dt.de> Should we send this question on the users at lists.opencsw.org list? Am 16.04.12, schrieb Maciej (Matchek) Blizi?ski : > One thought about the spring cleaning we did: When we were dropping packages, we were dropping them from the 5.9 and the 5.10 catalog. With packages such as Firefox, the argument is that a newer Firefox is available from elsewhere. However, it's only true for Solaris 10, not for Solaris 9. I don't think there is a Firefox for Solaris 9. Therefore, maybe we should not drop some of the packages from the 5.9 catalog? > > > > Thoughts? > > > Maciej > > > > -- Carsten Grzemba Tel.:?? +49 3677 64740 Mobil: +49 171 9749479 Fax::?? +49 3677 6474111 Email: carsten.grzemba at contac-dt.de contac Datentechnik GmbH -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Mon Apr 16 19:35:31 2012 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 16 Apr 2012 13:35:31 -0400 Subject: [csw-maintainers] Spring cleaning In-Reply-To: References: Message-ID: <1334597477-sup-2984@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Mon Apr 16 13:24:09 -0400 2012: > One thought about the spring cleaning we did: When we were dropping > packages, we were dropping them from the 5.9 and the 5.10 > catalog. With packages such as Firefox, the argument is that a newer > Firefox is available from elsewhere. However, it's only true for > Solaris 10, not for Solaris 9. I don't think there is a Firefox for > Solaris 9. Therefore, maybe we should not drop some of the packages > from the 5.9 catalog? Given that firefox is a moving target and in fairly constant need of updates to address new security issues, it's not attractive to put it in a catalog unless it's updated regularly. As solaris 9 is now best effort and building FF for it has always been a pita, I don't see keeping it around as a good option. I also think that the number of folks wanting FF on solaris 9 has to be quite small so there are unlikely to be many ruffled feathers over the removal. Personally, I'm ok with the choice made at the camp. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Mon Apr 16 19:44:09 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 16 Apr 2012 18:44:09 +0100 Subject: [csw-maintainers] Spring cleaning In-Reply-To: <1334597477-sup-2984@pinkfloyd.chass.utoronto.ca> References: <1334597477-sup-2984@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 16 de Abril de 2012 18:35, Ben Walton escreveu: > I also think that the number of folks wanting FF on solaris 9 has to > be quite small so there are unlikely to be many ruffled feathers over > the removal. I asked on the users list. If no one responds, we don't need to do anything. If someone asks for FF to be added back, we could do it I suppose, in the 5.9 catalog only. This means it wouldn't appear on the website, for instance. Let's see if anyone responds to my question. Maciej From bwalton at opencsw.org Mon Apr 16 22:02:29 2012 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 16 Apr 2012 16:02:29 -0400 Subject: [csw-maintainers] Spring cleaning In-Reply-To: References: <1334597477-sup-2984@pinkfloyd.chass.utoronto.ca> Message-ID: <1334606422-sup-8287@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Mon Apr 16 13:44:09 -0400 2012: > I asked on the users list. If no one responds, we don't need to do > anything. If someone asks for FF to be added back, we could do it I > suppose, in the 5.9 catalog only. This means it wouldn't appear on > the website, for instance. Let's see if anyone responds to my > question. The user that responded indicated that they'd like it available still. Given that the package will always be present in allpkgs for those that really want it, removing it from the catalog still seems like a good choice...that won't remove it from systems, it just prevents new installations. At the same time, running an EOL solaris with an EOL firefox really is a weapon you should be allowed to hurt yourself with, so leaving it in the catalog isn't a big deal either, I guess. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Tue Apr 17 02:00:03 2012 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 16 Apr 2012 20:00:03 -0400 Subject: [csw-maintainers] package browser Message-ID: <1334620559-sup-7639@pinkfloyd.chass.utoronto.ca> Hi All, In order to squash all of the issues we fight with our current package browser (mostly the disparity between various catalogs), I think we should move to something like this: http://www.archlinux.org/packages/ It's got nice, quick filtering on various criteria and a decent URL scheme as well. With a fairly small amount of work, I can make the web db maintenance code populate some new tables for use by a new package browser and then start working on the display code. (It'll be a few days before I can start this (end of the week or so) due to other things I've got up in the air.) If you would like changes to the above, let's discuss them. It's a pretty good starting point, I think. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Tue Apr 17 07:23:35 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 17 Apr 2012 06:23:35 +0100 Subject: [csw-maintainers] package browser In-Reply-To: <1334620559-sup-7639@pinkfloyd.chass.utoronto.ca> References: <1334620559-sup-7639@pinkfloyd.chass.utoronto.ca> Message-ID: I'm just about to do something along similar lines in the package browser. Here's the proof of concept: http://quinoa.blizinski.pl/~maciej/opencsw/test.html It does not require any new tables in MySQL, but instead adds a run time dependency on the buildfarm. I think this is acceptable. Part of the reason to do that is the download links. What's the main problem that we want to solve here? Showing which packages are in which catalogs? Or showing metadata for each package to see e.g. maintainer changes? Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Tue Apr 17 14:57:34 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 17 Apr 2012 14:57:34 +0200 Subject: [csw-maintainers] Spring cleaning In-Reply-To: <1334606422-sup-8287@pinkfloyd.chass.utoronto.ca> References: <1334597477-sup-2984@pinkfloyd.chass.utoronto.ca> <1334606422-sup-8287@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 16 de Abril de 2012 22:02, Ben Walton escreveu: > > At the same time, running an EOL solaris with an EOL firefox really is > a weapon you should be allowed to hurt yourself with, so leaving it in > the catalog isn't a big deal either, I guess. When we introduce tiers support, Firefox will land in the unmaintained area. Until then, I'm inclined to do what he user suggests. From maciej at opencsw.org Tue Apr 17 14:58:05 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 17 Apr 2012 14:58:05 +0200 Subject: [csw-maintainers] Tiers and metadata support progress In-Reply-To: References: Message-ID: I have made progress in the last month, but it's not there yet and requires more work. There are also some design issues to work out. I will try to get in done in about 3 months. When we're done, we'd release Kiel and maybe move any further targets to Bratislava. One question is how do we handle transition to the new mirror layout. Consider: opencsw/dublin/sparc/5.10/catalog opencsw/kiel/core/sparc/5.10/catalog Is that an acceptable layout? Note that users will have to change the URL scheme they subscribe to. I would suggest forcing users to choose which tiers they subscribe to. This is fine for users who subscribe to names. What about those who subscribe to the functional names? What happens when we flip the 'testing' symlink from dublin (no tiers) to kiel (with tiers)? From daniel at opencsw.org Thu Apr 19 01:39:23 2012 From: daniel at opencsw.org (Daniel Pocock) Date: Thu, 19 Apr 2012 01:39:23 +0200 Subject: [csw-maintainers] building reSIProcate on build10s Message-ID: <4F8F50AB.2050802@opencsw.org> I've recently migrated reSIProcate upstream to autotools, in the hope of easier build and packaging, particularly for the SIP proxy (repro) and TURN server (reTurn) However, I'm running into some issues just doing a test compile on the build10s machine. This command should build rutil, one of the foundation libraries, and run some test cases: $ ./configure \ CXXFLAGS="-I/opt/csw/include -mt -library=stlport4 " \ LDFLAGS="-L/opt/csw/lib -DTHREAD=MULTI -mt -dalign -V -v" \ --with-c-ares && \ gmake -C rutil clean && \ gmake -C rutil check It stops while linking the first test case - am I doing something wrong with CXXFLAGS or LDFLAGS, is there possibly some issue with this machine? I notice the librutil.so was built, and the class referred to, RRCache.o, was linked into the shared library. Making check in test gmake[1]: Entering directory `/home/daniel/ws/resip-trunk.git/rutil/test' gmake testCoders testCountStream testData testDataPerformance testDataStream testDnsUtil testFifo testFileSystem testInserter testIntrusiveList testLogger testMD5Stream testParseBuffer testRandomHex testRandomThread testThreadIf testXMLCursor gmake[2]: Entering directory `/home/daniel/ws/resip-trunk.git/rutil/test' source='testCoders.cxx' object='testCoders.o' libtool=no \ DEPDIR=.deps depmode=none /bin/bash ../../build-aux/depcomp \ CC -DHAVE_CONFIG_H -I. -I../.. -I/opt/csw/include -mt -library=stlport4 -DRESIP_OSTYPE_LINUX -DRESIP_ARCH_SPARC -DRESIP_LARCH_sparc -D_REENTRANT -DRESIP_TOOLCHAIN_GNU -c -o testCoders.o testCoders.cxx /bin/bash ../../libtool --tag=CXX --mode=link CC -I/opt/csw/include -mt -library=stlport4 -DRESIP_OSTYPE_LINUX -DRESIP_ARCH_SPARC -DRESIP_LARCH_sparc -D_REENTRANT -DRESIP_TOOLCHAIN_GNU -L/opt/csw/lib -DTHREAD=MULTI -mt -dalign -V -v -o testCoders testCoders.o ../librutil.la -lpthread -lsocket -lnsl libtool: link: CC -I/opt/csw/include -mt -DRESIP_OSTYPE_LINUX -DRESIP_ARCH_SPARC -DRESIP_LARCH_sparc -D_REENTRANT -DRESIP_TOOLCHAIN_GNU -DTHREAD=MULTI -mt -dalign -V -v -o .libs/testCoders testCoders.o -L/opt/csw/lib ../.libs/librutil.so -library=stlport4 -lcares -lrt -lpthread -lsocket -lnsl -mt -R/usr/local/lib ### command line files and options (expanded): ### -I/opt/csw/include -DRESIP_OSTYPE_LINUX -DRESIP_ARCH_SPARC -DRESIP_LARCH_sparc -D_REENTRANT -DRESIP_TOOLCHAIN_GNU -DTHREAD=MULTI -xmemalign=8s -V -v -o .libs/testCoders testCoders.o -L/opt/csw/lib ../.libs/librutil.so -lcares -lrt -lpthread -lsocket -lnsl -mt -R/usr/local/lib -library=no%Cstd,stlport4 CC: Sun C++ 5.9 SunOS_sparc Patch 124863-28 2011/12/14 ### CC: Note: NLSPATH = /opt/SUNWspro/prod/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/opt/SUNWspro/prod/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat ### CC: Note: LD_LIBRARY_PATH = (null) ### CC: Note: LD_RUN_PATH = (null) ### CC: Note: LD_OPTIONS = (null) ln -s /opt/SUNWspro/prod/lib /tmp/lib_link.19882.0 ln -s /opt/SUNWspro/prod/lib /tmp/lib_base_link.19882.1 /usr/ccs/bin/ld -zld32=-S/tmp/lib_base_link.19882.1/libldstab_ws.so -zld64=-S/tmp/lib_base_link.19882.1/v9/libldstab_ws.so -zld32=-S/tmp/lib_base_link.19882.1/libCCexcept.so.1 -zld64=-S/tmp/lib_base_link.19882.1/v9/libCCexcept.so.1 -V -R/usr/local/lib -R/opt/SUNWspro/lib/rw7:/opt/SUNWspro/lib/stlport4:/opt/SUNWspro/lib/sparc:/opt/SUNWspro/lib:/usr/ccs/lib:/lib:/usr/lib -o .libs/testCoders /opt/SUNWspro/prod/lib/crti.o /opt/SUNWspro/prod/lib/CCrti.o /opt/SUNWspro/prod/lib/crt1.o /opt/SUNWspro/prod/lib/values-xa.o -Y P,/opt/SUNWspro/lib/rw7:/opt/SUNWspro/lib/stlport4:/opt/SUNWspro/lib/sparc:/opt/SUNWspro/prod/lib/rw7:/opt/SUNWspro/prod/lib/stlport4:/opt/SUNWspro/prod/lib/sparc:/opt/SUNWspro/lib:/opt/SUNWspro/prod/lib:/usr/ccs/lib:/lib:/usr/lib testCoders.o -L/opt/csw/lib ../.libs/librutil.so -lcares -lrt -lpthread -lsocket -lnsl -lstlport -lrt -lCrun -lm -lthread -lc /opt/SUNWspro/prod/lib/CCrtn.o /opt/SUNWspro/prod/lib/crtn.o >&/tmp/ld.19882.2.err /opt/SUNWspro/prod/bin/c++filt -V -filt=no%stdlib /tmp/c++filt.19882.3.err /opt/SUNWspro/prod/bin/c++filt: Sun C++ 5.9 SunOS_sparc 2007/05/03 rm /tmp/ld.19882.2.err /opt/SUNWspro/prod/bin/stdlibfilt -stderr &,int&) ../.libs/librutil.so ld: fatal: Symbol referencing errors. No output written to .libs/testCoders rm /tmp/c++filt.19882.3.err rm /tmp/lib_link.19882.0 rm /tmp/lib_base_link.19882.1 gmake[2]: *** [testCoders] Error 1 gmake[2]: Leaving directory `/home/daniel/ws/resip-trunk.git/rutil/test' gmake[1]: *** [check-am] Error 2 gmake[1]: Leaving directory `/home/daniel/ws/resip-trunk.git/rutil/test' gmake: *** [check-recursive] Error 1 gmake: Leaving directory `/home/daniel/ws/resip-trunk.git/rutil' From dam at opencsw.org Thu Apr 19 11:04:09 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 19 Apr 2012 11:04:09 +0200 Subject: [csw-maintainers] Adjustment of linker search pathes Message-ID: <8FA41E72-4BA0-4D1B-AB59-D98AEE51DF3C@opencsw.org> Hi, in r17763 I have adjusted the linker search pathes to prefer libs and includes when changing prefix to something special, like /opt/csw/gxx. If you see anything suspicious just let me know. http://sourceforge.net/apps/trac/gar/changeset/17763 Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From daniel at opencsw.org Thu Apr 19 16:06:24 2012 From: daniel at opencsw.org (Daniel Pocock) Date: Thu, 19 Apr 2012 16:06:24 +0200 Subject: [csw-maintainers] setting *FLAGS? Message-ID: <4F901BE0.8070206@opencsw.org> I notice there are many ways people set CXXFLAGS, LDFLAGS, etc from within mgar Makefiles Let's say I want to use bdb, I notice several versions are available: daniel at login [login]:~/opencsw/resiprocate/trunk > ls -d /opt/csw/bdb* /opt/csw/bdb4 /opt/csw/bdb42 /opt/csw/bdb44 /opt/csw/bdb47 /opt/csw/bdb48 Should I just do something like this? BDB_HOME = /opt/csw/bdb48 BDB_INC = $(BDB_HOME)/include BDB_LIB = $(BDB_HOME)/lib EXTRA_CFLAGS += -I$(BDB_INC) EXTRA_CXXFLAGS += -I$(BDB_INC) EXTRA_LINKER_FLAGS += -L$(BDB_LIB) Or should I set LDFLAGS directly? LDFLAGS += -L$(BDB_LIB) or something completely different? From dam at opencsw.org Thu Apr 19 16:17:47 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 19 Apr 2012 16:17:47 +0200 Subject: [csw-maintainers] setting *FLAGS? In-Reply-To: <4F901BE0.8070206@opencsw.org> References: <4F901BE0.8070206@opencsw.org> Message-ID: <94B2A488-35E0-44F0-A005-74B065E14EA4@opencsw.org> Hi Daniel, Am 19.04.2012 um 16:06 schrieb Daniel Pocock: > I notice there are many ways people set CXXFLAGS, LDFLAGS, etc from > within mgar Makefiles > > Let's say I want to use bdb, I notice several versions are available: > > daniel at login [login]:~/opencsw/resiprocate/trunk > ls -d /opt/csw/bdb* > /opt/csw/bdb4 > /opt/csw/bdb42 > /opt/csw/bdb44 > /opt/csw/bdb47 > /opt/csw/bdb48 > > Should I just do something like this? The correct solution is BDB_HOME = $(prefix)/bdb48 EXTRA_LIB = $(BDB_HOME)/lib EXTRA_INC = $(BDB_HOME)/include The main difference is that EXTRA_LIB propapages correctly to -L and -R during LDFLAGS and LD_OPTIONS and additionally gets the 64 bit subdir appended on 64 bit ISAs. See here for an example: https://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/openldap/trunk/Makefile#L132 > BDB_HOME = /opt/csw/bdb48 > BDB_INC = $(BDB_HOME)/include > BDB_LIB = $(BDB_HOME)/lib > > EXTRA_CFLAGS += -I$(BDB_INC) > EXTRA_CXXFLAGS += -I$(BDB_INC) > EXTRA_LINKER_FLAGS += -L$(BDB_LIB) Usually you set the preprocessor flags EXTRA_CPPFLAGS += -I$(BDB_INC) but CFLAGS and CXXFLAGS is also fine. LINKER_FLAGS is essentially ok as it propagates to LDFLAGS and LD_OPTIONS: https://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/gar.conf.mk#L693 However, it does not append 64 bit subdirectory and hence will fail if 64 bit build is requested. > Or should I set LDFLAGS directly? > > LDFLAGS += -L$(BDB_LIB) Setting LDFLAGS overwrites all flags regardless of the +=. If you want to add something please always use EXTRA_LDFLAGS += -L$(BDB_LIB) This is a general design principle of GAR: If you set you overwrite it, EXTRA_ adds the value to the default. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From daniel at opencsw.org Thu Apr 19 17:31:20 2012 From: daniel at opencsw.org (Daniel Pocock) Date: Thu, 19 Apr 2012 17:31:20 +0200 Subject: [csw-maintainers] setting *FLAGS? In-Reply-To: <94B2A488-35E0-44F0-A005-74B065E14EA4@opencsw.org> References: <4F901BE0.8070206@opencsw.org> <94B2A488-35E0-44F0-A005-74B065E14EA4@opencsw.org> Message-ID: <4F902FC8.5000803@opencsw.org> > The correct solution is > BDB_HOME = $(prefix)/bdb48 > EXTRA_LIB = $(BDB_HOME)/lib > EXTRA_INC = $(BDB_HOME)/include > > The main difference is that EXTRA_LIB propapages correctly to -L and -R > during LDFLAGS and LD_OPTIONS and additionally gets the 64 bit subdir > appended on 64 bit ISAs. Great, thanks for setting me straight with this Yesterday I was trying to build it by running configure and gmake manually. Today I'm trying to build with mgar - I've added resiprocate to the mgar repository. However, I still find that the binaries refuse to link. All the libraries compile and link, but when it tries to make a binary, it fails Exactly the same code compiles and runs on Linux, so I suspect it is some variation in CXXFLAGS or LDFLAGS - are there any common problems with C++ code that need a particular flag on Solaris/SunPro? $ mgar clean && mgar build .... libtool: link: /opt/SUNWspro/bin/CC -xO3 -m32 -xarch=sparc -I/opt/csw/bdb48/include -DRESIP_OSTYPE_SUNOS -DRESIP_ARCH_SPARC -DRESIP_LARCH_SPARC -D_REENTRANT -DRESIP_TOOLCHAIN_SUNPRO -m32 -xarch=sparc -o .libs/repro repro.o -L/opt/csw/lib -L/opt/csw/bdb48/lib ./.libs/librepro.so -ldb_cxx ../resip/dum/.libs/libdum.so ../resip/stack/.libs/libresip.so ../rutil/.libs/librutil.so -library=stlport4 -lcares -lrt -lssl -lpthread -lsocket -lnsl -R/opt/csw/lib Undefined first referenced symbol in file void resip::SipStack::post(const std::auto_ptr) ./.libs/librepro.so bool resip::RRCache::lookup(const resip::Data&,int,int,std::vector&,int&) ../rutil/.libs/librutil.so ld: fatal: Symbol referencing errors. No output written to .libs/repro gmake[3]: *** [repro] Error 1 From dam at opencsw.org Thu Apr 19 17:36:56 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 19 Apr 2012 17:36:56 +0200 Subject: [csw-maintainers] setting *FLAGS? In-Reply-To: <4F902FC8.5000803@opencsw.org> References: <4F901BE0.8070206@opencsw.org> <94B2A488-35E0-44F0-A005-74B065E14EA4@opencsw.org> <4F902FC8.5000803@opencsw.org> Message-ID: Hi Daniel, Am 19.04.2012 um 17:31 schrieb Daniel Pocock: > >> The correct solution is >> BDB_HOME = $(prefix)/bdb48 >> EXTRA_LIB = $(BDB_HOME)/lib >> EXTRA_INC = $(BDB_HOME)/include >> >> The main difference is that EXTRA_LIB propapages correctly to -L and -R >> during LDFLAGS and LD_OPTIONS and additionally gets the 64 bit subdir >> appended on 64 bit ISAs. > > Great, thanks for setting me straight with this > > Yesterday I was trying to build it by running configure and gmake manually. > > Today I'm trying to build with mgar - I've added resiprocate to the mgar > repository. > > However, I still find that the binaries refuse to link. All the > libraries compile and link, but when it tries to make a binary, it fails > > Exactly the same code compiles and runs on Linux, so I suspect it is > some variation in CXXFLAGS or LDFLAGS - are there any common problems > with C++ code that need a particular flag on Solaris/SunPro? > > > $ mgar clean && mgar build > > .... > > libtool: link: /opt/SUNWspro/bin/CC -xO3 -m32 -xarch=sparc > -I/opt/csw/bdb48/include -DRESIP_OSTYPE_SUNOS -DRESIP_ARCH_SPARC > -DRESIP_LARCH_SPARC -D_REENTRANT -DRESIP_TOOLCHAIN_SUNPRO -m32 > -xarch=sparc -o .libs/repro repro.o -L/opt/csw/lib -L/opt/csw/bdb48/lib > ./.libs/librepro.so -ldb_cxx ../resip/dum/.libs/libdum.so > ../resip/stack/.libs/libresip.so ../rutil/.libs/librutil.so > -library=stlport4 -lcares -lrt -lssl -lpthread -lsocket -lnsl -R/opt/csw/lib > Undefined first referenced > symbol in file > void resip::SipStack::post(const > std::auto_ptr) ./.libs/librepro.so > bool resip::RRCache::lookup(const > resip::Data&,int,int,std::vector&,int&) > ../rutil/.libs/librutil.so > ld: fatal: Symbol referencing errors. No output written to .libs/repro > gmake[3]: *** [repro] Error 1 Do you have committed your work? In which location in the GAR tree are you building? Maybe other maintainers can have a look... Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From daniel at opencsw.org Thu Apr 19 17:48:31 2012 From: daniel at opencsw.org (Daniel Pocock) Date: Thu, 19 Apr 2012 17:48:31 +0200 Subject: [csw-maintainers] setting *FLAGS? In-Reply-To: References: <4F901BE0.8070206@opencsw.org> <94B2A488-35E0-44F0-A005-74B065E14EA4@opencsw.org> <4F902FC8.5000803@opencsw.org> Message-ID: <4F9033CF.3060901@opencsw.org> On 19/04/12 17:36, Dagobert Michelsen wrote: > Hi Daniel, > > Am 19.04.2012 um 17:31 schrieb Daniel Pocock: > >> >>> The correct solution is >>> BDB_HOME = $(prefix)/bdb48 >>> EXTRA_LIB = $(BDB_HOME)/lib >>> EXTRA_INC = $(BDB_HOME)/include >>> >>> The main difference is that EXTRA_LIB propapages correctly to -L and -R >>> during LDFLAGS and LD_OPTIONS and additionally gets the 64 bit subdir >>> appended on 64 bit ISAs. >> >> Great, thanks for setting me straight with this >> >> Yesterday I was trying to build it by running configure and gmake manually. >> >> Today I'm trying to build with mgar - I've added resiprocate to the mgar >> repository. >> >> However, I still find that the binaries refuse to link. All the >> libraries compile and link, but when it tries to make a binary, it fails >> >> Exactly the same code compiles and runs on Linux, so I suspect it is >> some variation in CXXFLAGS or LDFLAGS - are there any common problems >> with C++ code that need a particular flag on Solaris/SunPro? >> >> >> $ mgar clean && mgar build >> >> .... >> >> libtool: link: /opt/SUNWspro/bin/CC -xO3 -m32 -xarch=sparc >> -I/opt/csw/bdb48/include -DRESIP_OSTYPE_SUNOS -DRESIP_ARCH_SPARC >> -DRESIP_LARCH_SPARC -D_REENTRANT -DRESIP_TOOLCHAIN_SUNPRO -m32 >> -xarch=sparc -o .libs/repro repro.o -L/opt/csw/lib -L/opt/csw/bdb48/lib >> ./.libs/librepro.so -ldb_cxx ../resip/dum/.libs/libdum.so >> ../resip/stack/.libs/libresip.so ../rutil/.libs/librutil.so >> -library=stlport4 -lcares -lrt -lssl -lpthread -lsocket -lnsl -R/opt/csw/lib >> Undefined first referenced >> symbol in file >> void resip::SipStack::post(const >> std::auto_ptr) ./.libs/librepro.so >> bool resip::RRCache::lookup(const >> resip::Data&,int,int,std::vector&,int&) >> ../rutil/.libs/librutil.so >> ld: fatal: Symbol referencing errors. No output written to .libs/repro >> gmake[3]: *** [repro] Error 1 > > Do you have committed your work? In which location in the GAR tree are > you building? Maybe other maintainers can have a look... > Yes, the latest work is committed https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/resiprocate/trunk I get the error just running mgar clean && mgar build another useful test is $ (cd work/build-isa-sparcv8plus/resiprocate-1.8.0 && gmake -C rutil check) That should just build and run the most simple test cases - but it also fails with the same linker error when it gets to the first binary From maciej at opencsw.org Thu Apr 19 18:41:48 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 19 Apr 2012 18:41:48 +0200 Subject: [csw-maintainers] pkgname2catalogname Message-ID: The Department of Random Restful Utilities teases you with code of a utility printing catalognames based on pkgnames you give it. #!/usr/bin/env python2.6 import json import sys import urllib2 base_url = "http://buildfarm.opencsw.org/pkgdb/rest" url = ("%s/catalogs/unstable/i386/SunOS5.10/pkgnames/%s/" % (base_url, sys.argv[1])) j = urllib2.urlopen(url).read() print json.loads(j)["catalogname"] Error checking? What error checking? Enjoy! From daniel at opencsw.org Fri Apr 20 02:04:10 2012 From: daniel at opencsw.org (Daniel Pocock) Date: Fri, 20 Apr 2012 02:04:10 +0200 Subject: [csw-maintainers] [csw-buildfarm] Fwd: OpenCSW catalog update report (ganglia) In-Reply-To: <72A5C75A-AEFF-40CE-A46C-C30600992B56@opencsw.org> References: <4ED05794.9040605@opencsw.org> <742E888E-D268-4EAB-942E-CE014C48A297@opencsw.org> <4ED2515E.1010103@opencsw.org> <4ED251FF.8000107@opencsw.org> <4ED36B53.7070006@opencsw.org> <72A5C75A-AEFF-40CE-A46C-C30600992B56@opencsw.org> Message-ID: <4F90A7FA.6030005@opencsw.org> >> 3. be aware the this gmond version doesn't run on a non-global zone >> >> http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=100 > > If course the webserver runs in a non-global zone :-P > Could you please apply Brians patch as cited in the patch report? > I've added some code to detect this condition on Solaris more elegantly - can you try the 3.3.7 package on a host that is a non-global zone? It is in /home/experimental/ganglia/3.3.7 Also, 3.3.x series has a great new web interface compared to older versions - can you put the package gangliaweb on a publicly available web server perhaps so I can see reports from the build farm? gangliaweb: only needed on the web server gangliaagent: install to all hosts you want to monitor Everything should just work automatically From dam at opencsw.org Fri Apr 20 12:56:36 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Apr 2012 12:56:36 +0200 Subject: [csw-maintainers] setting *FLAGS? In-Reply-To: <4F9033CF.3060901@opencsw.org> References: <4F901BE0.8070206@opencsw.org> <94B2A488-35E0-44F0-A005-74B065E14EA4@opencsw.org> <4F902FC8.5000803@opencsw.org> <4F9033CF.3060901@opencsw.org> Message-ID: Hi Daniel, Am 19.04.2012 um 17:48 schrieb Daniel Pocock: > On 19/04/12 17:36, Dagobert Michelsen wrote: >> Am 19.04.2012 um 17:31 schrieb Daniel Pocock: >>> Today I'm trying to build with mgar - I've added resiprocate to the mgar >>> repository. >>> >>> However, I still find that the binaries refuse to link. All the >>> libraries compile and link, but when it tries to make a binary, it fails >>> >>> Exactly the same code compiles and runs on Linux, so I suspect it is >>> some variation in CXXFLAGS or LDFLAGS - are there any common problems >>> with C++ code that need a particular flag on Solaris/SunPro? >>> >>> $ mgar clean && mgar build >>> >>> .... >>> >>> libtool: link: /opt/SUNWspro/bin/CC -xO3 -m32 -xarch=sparc >>> -I/opt/csw/bdb48/include -DRESIP_OSTYPE_SUNOS -DRESIP_ARCH_SPARC >>> -DRESIP_LARCH_SPARC -D_REENTRANT -DRESIP_TOOLCHAIN_SUNPRO -m32 >>> -xarch=sparc -o .libs/repro repro.o -L/opt/csw/lib -L/opt/csw/bdb48/lib >>> ./.libs/librepro.so -ldb_cxx ../resip/dum/.libs/libdum.so >>> ../resip/stack/.libs/libresip.so ../rutil/.libs/librutil.so >>> -library=stlport4 -lcares -lrt -lssl -lpthread -lsocket -lnsl -R/opt/csw/lib >>> Undefined first referenced >>> symbol in file >>> void resip::SipStack::post(const >>> std::auto_ptr) ./.libs/librepro.so >>> bool resip::RRCache::lookup(const >>> resip::Data&,int,int,std::vector&,int&) >>> ../rutil/.libs/librutil.so >>> ld: fatal: Symbol referencing errors. No output written to .libs/repro >>> gmake[3]: *** [repro] Error 1 >> >> Do you have committed your work? In which location in the GAR tree are >> you building? Maybe other maintainers can have a look... > > Yes, the latest work is committed > > https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/resiprocate/trunk > > I get the error just running > > mgar clean && mgar build > > another useful test is > > $ (cd work/build-isa-sparcv8plus/resiprocate-1.8.0 && gmake -C rutil > check) > > That should just build and run the most simple test cases - but it also > fails with the same linker error when it gets to the first binary Indeed: > unstable9s% nm -A .libs/librepro.so | c++filt | grep post > ... > .libs/librepro.so: [1272] | 0| 0|FUNC |GLOB |0 |UNDEF |void resip::SipStack::post(const std::auto_ptr) > ... The problem is here: > unstable9s% nm -A ../resip/stack/.libs/libresip.so | c++filt | grep post > ... > ../resip/stack/.libs/libresip.so: [6069] | 1561800| 104|FUNC |GLOB |0 |10 |void resip::SipStack::post(std::auto_ptr) Please note the missing "const" here. As expected the header definitions differ from the method signature: > SipStack.hxx: void post(const std::auto_ptr message); > SipStack.cxx:SipStack::post(std::auto_ptr message) Sun Studio honours "const" for mangling whereas GCC does not, so the error is a result of the stricter checks of Sun Studio (which is IMHO a good thing). After removing the "const" in the header definition compilation succeeds to another "const"-error which should be easy to fix. Additionally, there are some warnings which you may want to address: > "../../rutil/dns/DnsStub.hxx", line 20: Warning: Last line in file "../../rutil/dns/DnsAAAARecord.hxx" is not terminated with a newline. > "../../rutil/dns/DnsStub.hxx", line 21: Warning: Last line in file "../../rutil/dns/DnsCnameRecord.hxx" is not terminated with a newline. > "../../rutil/dns/DnsStub.hxx", line 22: Warning: Last line in file "../../rutil/dns/DnsHostRecord.hxx" is not terminated with a newline. > "../../rutil/dns/DnsStub.hxx", line 23: Warning: Last line in file "../../rutil/dns/DnsNaptrRecord.hxx" is not terminated with a newline. > "../../rutil/dns/DnsStub.hxx", line 24: Warning: Last line in file "../../rutil/dns/DnsSrvRecord.hxx" is not terminated with a newline. > "../../rutil/dns/RRFactory.hxx", line 5: Warning: Last line in file "../../rutil/dns/RROverlay.hxx" is not terminated with a newline. > "../../rutil/dns/ExternalDns.hxx", line 26: Warning: Identifier expected instead of "}". > "../../resip/stack/DnsInterface.hxx", line 12: Warning: Last line in file "../../rutil/dns/RRVip.hxx" is not terminated with a newline. > 8 Warning(s) detected. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From daniel at opencsw.org Fri Apr 20 13:42:56 2012 From: daniel at opencsw.org (Daniel Pocock) Date: Fri, 20 Apr 2012 13:42:56 +0200 Subject: [csw-maintainers] setting *FLAGS? In-Reply-To: References: <4F901BE0.8070206@opencsw.org> <94B2A488-35E0-44F0-A005-74B065E14EA4@opencsw.org> <4F902FC8.5000803@opencsw.org> <4F9033CF.3060901@opencsw.org> Message-ID: <4F914BC0.6010607@opencsw.org> > Sun Studio honours "const" for mangling whereas GCC does not, so the error is a result > of the stricter checks of Sun Studio (which is IMHO a good thing). I agree this should be tidied up, if it's just one or two cases of the problem, I'll fix it upstream. However, is there any flag for the compiler to behave more like gcc, in case the problem is too tedious to fix quickly? There are a number of issues that are simply more urgently in need of testing and fixing (e.g. we found a hash algorithm that was broken by the gcc optimizer on certain platforms), and so I'm keen to get a full run of the test cases on Solaris as quickly as possible. > After removing the "const" in the header definition compilation succeeds to another > "const"-error which should be easy to fix. > > Additionally, there are some warnings which you may want to address: > >> "../../rutil/dns/DnsStub.hxx", line 20: Warning: Last line in file "../../rutil/dns/DnsAAAARecord.hxx" is not terminated with a newline. >> "../../rutil/dns/DnsStub.hxx", line 21: Warning: Last line in file "../../rutil/dns/DnsCnameRecord.hxx" is not terminated with a newline. >> "../../rutil/dns/DnsStub.hxx", line 22: Warning: Last line in file "../../rutil/dns/DnsHostRecord.hxx" is not terminated with a newline. >> "../../rutil/dns/DnsStub.hxx", line 23: Warning: Last line in file "../../rutil/dns/DnsNaptrRecord.hxx" is not terminated with a newline. >> "../../rutil/dns/DnsStub.hxx", line 24: Warning: Last line in file "../../rutil/dns/DnsSrvRecord.hxx" is not terminated with a newline. >> "../../rutil/dns/RRFactory.hxx", line 5: Warning: Last line in file "../../rutil/dns/RROverlay.hxx" is not terminated with a newline. >> "../../rutil/dns/ExternalDns.hxx", line 26: Warning: Identifier expected instead of "}". I checked that one already, C99 permits a comma after the last element of an enum, but it was prohibited in prior standards. >> "../../resip/stack/DnsInterface.hxx", line 12: Warning: Last line in file "../../rutil/dns/RRVip.hxx" is not terminated with a newline. >> 8 Warning(s) detected. Thanks for taking the time to look at this From pfelecan at opencsw.org Fri Apr 20 19:23:42 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 20 Apr 2012 19:23:42 +0200 Subject: [csw-maintainers] commit privilege for gar / sourceforge Message-ID: I started the "garification" of the packages under my responsibility. Everything works fine with the exception of the ability to commit in the repository. I already used my sourceforge account to modify the project's wiki. Is it possible that a kind administrator gives me the privilege and the required information for this kind of action? TIA -- Peter From dam at opencsw.org Fri Apr 20 21:22:24 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Apr 2012 21:22:24 +0200 Subject: [csw-maintainers] setting *FLAGS? In-Reply-To: <4F914BC0.6010607@opencsw.org> References: <4F901BE0.8070206@opencsw.org> <94B2A488-35E0-44F0-A005-74B065E14EA4@opencsw.org> <4F902FC8.5000803@opencsw.org> <4F9033CF.3060901@opencsw.org> <4F914BC0.6010607@opencsw.org> Message-ID: <308685CE-FCA6-46A4-9A56-A5517EA0B14F@opencsw.org> Hi Daniel, Am 20.04.2012 um 13:42 schrieb Daniel Pocock: >> Sun Studio honours "const" for mangling whereas GCC does not, so the error is a result >> of the stricter checks of Sun Studio (which is IMHO a good thing). > > I agree this should be tidied up, if it's just one or two cases of the > problem, I'll fix it upstream. > > However, is there any flag for the compiler to behave more like gcc, in > case the problem is too tedious to fix quickly? I doubt that as the const-issue is tightly coupled to the way the mangling is done. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Fri Apr 20 21:36:03 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Apr 2012 21:36:03 +0200 Subject: [csw-maintainers] commit privilege for gar / sourceforge In-Reply-To: References: Message-ID: Hi Peter, Am 20.04.2012 um 19:23 schrieb Peter FELECAN: > I started the "garification" of the packages under my > responsibility. This is excellent news! Thanks Peter :-) > Everything works fine with the exception of the ability > to commit in the repository. I already used my sourceforge account to > modify the project's wiki. I think you mean the wikidot-wiki which is not coupled to sourceforge. Somehow you were not in the membership list for "gar" on SF. > Is it possible that a kind administrator > gives me the privilege and the required information for this kind of > action? Sure, I added "pfelecan" (I hope this is you, there was no realname for that account on SF configured). You should be able to commit now. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From daniel at opencsw.org Fri Apr 20 21:42:43 2012 From: daniel at opencsw.org (Daniel Pocock) Date: Fri, 20 Apr 2012 21:42:43 +0200 Subject: [csw-maintainers] libCstd or stlport? Message-ID: <4F91BC33.80509@opencsw.org> I notice that reSIProcate has previously been compiled on Solaris using -library=stlport, and I believe this is still necessary or the code doesn't compile. Without -library=stlport, it stops like this: libtool: compile: /opt/SUNWspro/bin/CC -DHAVE_CONFIG_H -I. -I.. -I/opt/csw/bdb48/include -I/opt/csw/include -xO3 -m32 -xarch=sparc -DRESIP_OSTYPE_SUNOS -DRESIP_ARCH_SPARC -DRESIP_LARCH_SPARC -D_REENTRANT -DRESIP_TOOLCHAIN_SUNPRO -c DnsUtil.cxx -KPIC -DPIC -o .libs/DnsUtil.o "DnsUtil.cxx", line 550: Error: Formal argument x of type const std::pair& in call to std::list >::push_back(const std::pair&) is being passed std::pair. 1 Error(s) detected. However, I noticed that dependenices (e.g. /opt/csw/bdb48/lib/libdb_cxx-4.8.so) are linked against libCstd If I add -library=stlport, the code builds, but the repro binary fails with a Segmentation fault, before it even enters the main function. The stack trace shows a combination of libCstd and stlport classes. Can anyone comment on how to deal with this situation? Is there a convenient way to get versions of the dependencies that are not libCstd dependent? Or does the upstream project need to drop the requirement for stlport? Regards, Daniel From pfelecan at opencsw.org Fri Apr 20 21:40:39 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 20 Apr 2012 21:40:39 +0200 Subject: [csw-maintainers] commit privilege for gar / sourceforge In-Reply-To: (Dagobert Michelsen's message of "Fri, 20 Apr 2012 21:36:03 +0200") References: Message-ID: Dagobert Michelsen writes: > Hi Peter, > > Am 20.04.2012 um 19:23 schrieb Peter FELECAN: >> Is it possible that a kind administrator >> gives me the privilege and the required information for this kind of >> action? > > Sure, I added "pfelecan" (I hope this is you, there was no realname for that > account on SF configured). You should be able to commit now. It's me indeed. I just commited my first package. Thank you. -- Peter From dam at opencsw.org Sat Apr 21 21:54:12 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 21 Apr 2012 21:54:12 +0200 Subject: [csw-maintainers] libCstd or stlport? In-Reply-To: <4F91BC33.80509@opencsw.org> References: <4F91BC33.80509@opencsw.org> Message-ID: Hi Daniel, Am 20.04.2012 um 21:42 schrieb Daniel Pocock: > I notice that reSIProcate has previously been compiled on Solaris using > -library=stlport, and I believe this is still necessary or the code > doesn't compile. Without -library=stlport, it stops like this: > > libtool: compile: /opt/SUNWspro/bin/CC -DHAVE_CONFIG_H -I. -I.. > -I/opt/csw/bdb48/include -I/opt/csw/include -xO3 -m32 -xarch=sparc > -DRESIP_OSTYPE_SUNOS -DRESIP_ARCH_SPARC -DRESIP_LARCH_SPARC -D_REENTRANT > -DRESIP_TOOLCHAIN_SUNPRO -c DnsUtil.cxx -KPIC -DPIC -o .libs/DnsUtil.o > "DnsUtil.cxx", line 550: Error: Formal argument x of type const > std::pair& in call to > std::list >::push_back(const > std::pair&) is being passed std::pair resip::Data>. > 1 Error(s) detected. > > However, I noticed that dependenices (e.g. > /opt/csw/bdb48/lib/libdb_cxx-4.8.so) are linked against libCstd > > If I add -library=stlport, the code builds, but the repro binary fails > with a Segmentation fault, before it even enters the main function. The > stack trace shows a combination of libCstd and stlport classes. > > Can anyone comment on how to deal with this situation? Is there a > convenient way to get versions of the dependencies that are not libCstd > dependent? Or does the upstream project need to drop the requirement > for stlport? Unfortunately you are right: http://docs.oracle.com/cd/E19205-01/819-5267/bkakg/index.html "STLport is binary incompatible with the default libCstd"... I guess we need a special version like the gxx tree for libCstd and stlport. However, it is worse with stlport as the shipped 4.5.3 *may* be incompatible with any other version of stlport in the future as also said in the linked document. I suggest having /opt/csw/stlport and see how far we can get. Regarding BDB I guess that I will rebuild 4.8 against stlport as modulation or different branch and see if that solves the issue. Unfortunately I probably won't be able to do that before start of next week. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From pfelecan at opencsw.org Sun Apr 22 08:20:51 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 22 Apr 2012 08:20:51 +0200 Subject: [csw-maintainers] mgar usage feedback : documentation Message-ID: I started the migration of my packages from personal recipes to gar based recipes.Being still a candid with this system, I'm trying to give you my feedback in hope to clarify and enhance its usage. The first step was to read the documentation. It's a little bit scattered: our main site, SourceForce, Wikidot. I managed to use my first recipe without pain excepting the looooong mgar up --all. I think that showing how to extract specific recipes is better but I'll come back on this issue later. The manual page and the local documentation, i.e., that installed by the mgar package, is quite sketchy. In my opinion, it's a good thing to have a complete local documentation which reflects the content of the centralized one. -- Peter From pfelecan at opencsw.org Sun Apr 22 08:36:58 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 22 Apr 2012 08:36:58 +0200 Subject: [csw-maintainers] mgar usage feedback 2 : checking out a recipe Message-ID: As I mentioned in my first feedback, extracting the recipes with mgar up --all is too long if what I wish is to extract only one or a handful of recipes. I tried: mgar up lsdvd but it complained with: This command is supposed to be run from within a package build directory (i.e. one with a build recipe). Please change to one and re-run this command. The same occurred when I set the current directory to the build-tree. I don't say that it's not correct given the action that I request: an update. But, when I ask for a full update (mgar up --all) it *checks* out the recipes, consequently I expected to have the same behavior when requesting one recipe. For the moment, the only way to check out one recipe is to use subversion, which is fine and natural but non orthogonal in mgar: svn checkout \ https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/lsdvd \ ~/opencsw/lsdvd Either we modify mgar to have an orthogonal behavior or we document clearly how to extract specific recipes without incurring the excessive load of checking out everything. I'm in favor of the former and here is my proposition: When wishing to checkout or update a recipe, the following command should be given, whichever current directory: mgar up recipe -- Peter From bonivart at opencsw.org Sun Apr 22 10:16:31 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 22 Apr 2012 10:16:31 +0200 Subject: [csw-maintainers] Web site problems Message-ID: >From IRC: [00:37:50] Hi, Having a problem: I goto http://www.opencsw.org/get-it/ That's a link to This page has moved to Getting Started with OpenCSW with link: http://www.opencsw.org/manual/for-administrators/getting-started.html [00:38:12] that gets me: Forbidden: You don't have permission to access /~dam/opencsw_policy/for-administrators/getting-started.html on this server. [00:38:39] So, as fas as I can tell, I can't get to basic install directions. /peter From bwalton at opencsw.org Sun Apr 22 14:13:54 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 22 Apr 2012 08:13:54 -0400 Subject: [csw-maintainers] mgar usage feedback 2 : checking out a recipe In-Reply-To: References: Message-ID: <1335096160-sup-7349@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Sun Apr 22 02:36:58 -0400 2012: Hi Peter, > mgar up --all > > is too long if what I wish is to extract only one or a handful of > recipes. If you run simply 'mgar up' from the trunk/ of the recipe you're working on, you'll get that recipe and the gar code only. I can't remember the last time I used --all. So if you're updating 3 recipes, there will still be three checks for gar code, but that's much better than checking the whole tree. > update. But, when I ask for a full update (mgar up --all) it *checks* out > the recipes, consequently I expected to have the same behavior when > requesting one recipe. There might be some room for fixes to orthogonality as you mentioned though. > mgar up recipe I think this would be a good change as it eliminates the constraint of being in trunk/ to do the single-package update. There would be corner cases that make the implementation a little bit less than straight forward though. In the case where you're in ~/opencsw (my checkout tree), it could test for -d $recipe/trunk. >From outside of ~/opencsw, the same test could be done after cd'ing to ~/opencsw. Our tree isn't flat though. We've made subdirectories to hold various collections like perl modules, ruby gems, etc. This opens up the possibility of name clashes (shouldn't happen, but could) and it might also require multiple checks for the recipe if the top-level check fails. For practical purposes, ignoring the sub-grouped packages would be a good start. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Sun Apr 22 15:57:28 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 22 Apr 2012 15:57:28 +0200 Subject: [csw-maintainers] Web site problems In-Reply-To: References: Message-ID: <1E1A221A-D101-4E79-803A-F5F029BF677F@opencsw.org> Hi Peter, Am 22.04.2012 um 10:16 schrieb Peter Bonivart: > From IRC: > > [00:37:50] Hi, Having a problem: I goto > http://www.opencsw.org/get-it/ That's a link to This page has moved > to Getting Started with OpenCSW with link: > http://www.opencsw.org/manual/for-administrators/getting-started.html > [00:38:12] that gets me: Forbidden: You don't have permission > to access /~dam/opencsw_policy/for-administrators/getting-started.html > on this server. > [00:38:39] So, as fas as I can tell, I can't get to basic > install directions. Argh, this is really bad. It resulted in a chapter rename. This is fixed now. However, we should change the rewriting and depend on my personal home to install CSWopencsw-policy on www and link from within the webserver. Best regards -- Dago From bwalton at opencsw.org Sun Apr 22 18:05:58 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 22 Apr 2012 12:05:58 -0400 Subject: [csw-maintainers] gar, checkpkg and subversion ... bratislava? In-Reply-To: References: Message-ID: <1335110585-sup-2791@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Wed Apr 11 16:36:53 -0400 2012: Hi Rupert, > tried to build svn-1.7.4 ... and the result were a lot of checkpkg > errors which looked correct ... but i am unsure where they came from, > see here: http://sourceforge.net/apps/trac/gar/changeset/17593/csw I dug into this a bit last night and some more this morning. It looks like the DESTDIR setting for the python swig binding installation was $(DESTDIR)/lib/python. This was causing the extra /lib/python path to be prepended to the otherwise sane file layout. I'm down to the following list of checkpkg issues: CHECKPKG_OVERRIDES_CSWjavasvn += bad-rpath-entry|/lib|/tmp/pkg_Vsw_QH/CSWjavasvn/root/opt/csw/lib/svn/libsvnjavahl-1.so.0.0.0 CHECKPKG_OVERRIDES_CSWjavasvn += bad-rpath-entry|/opt/SUNWspro/lib|/tmp/pkg_Vsw_QH/CSWjavasvn/root/opt/csw/lib/svn/libsvnjavahl-1.so.0.0.0 CHECKPKG_OVERRIDES_CSWjavasvn += bad-rpath-entry|/opt/SUNWspro/lib/rw7|/tmp/pkg_Vsw_QH/CSWjavasvn/root/opt/csw/lib/svn/libsvnjavahl-1.so.0.0.0 These need attention but I think they're not the same problems you were facing. One thought I just had is that the build may work for me and not for you (or others that looked) due environmental differences. The primary steps that GAR runs are done in a mostly sanitized environment using 'env -i' where only things we explicitly want to push there are set. The python and other language bindings for subversion are built in custom stages and are not subjected to this clean environment. I just the build with the following (now committed) patch applied and get the same results: Index: Makefile =================================================================== --- Makefile (revision 17811) +++ Makefile (working copy) @@ -351,8 +351,8 @@ touch \ $(WORKSRC)/subversion/bindings/swig/python/*.c \ $(WORKSRC)/subversion/bindings/swig/python/*.py - @$(BUILD_ENV) gmake -C $(WORKSRC) swig-py - @$(INSTALL_ENV) gmake -C $(WORKSRC) install-swig-py DESTDIR=$(DESTDIR) + @/usr/bin/env -i $(BUILD_ENV) /opt/csw/bin/gmake -C $(WORKSRC) swig-py + @/usr/bin/env -i $(INSTALL_ENV) /opt/csw/bin/gmake -C $(WORKSRC) install-swig-py DESTDIR=$(DESTDIR) #@$(TEST_ENV) gmake -C $(WORKSRC) check-swig-py @$(MAKECOOKIE) I think this change should likely be applied to the others as well once they're verified. Can someone try the recipe now and see if it works for anyone other than me? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sun Apr 22 19:28:00 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 22 Apr 2012 13:28:00 -0400 Subject: [csw-maintainers] gar, checkpkg and subversion ... bratislava? In-Reply-To: <1335110585-sup-2791@pinkfloyd.chass.utoronto.ca> References: <1335110585-sup-2791@pinkfloyd.chass.utoronto.ca> Message-ID: <1335115645-sup-3626@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Sun Apr 22 12:05:58 -0400 2012: > I think this change should likely be applied to the others as well > once they're verified. This is now done. The build runs fine for me with the cleaned environment for all language bindings. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sun Apr 22 20:36:33 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 22 Apr 2012 20:36:33 +0200 Subject: [csw-maintainers] gar, checkpkg and subversion ... bratislava? In-Reply-To: <1335115645-sup-3626@pinkfloyd.chass.utoronto.ca> References: <1335110585-sup-2791@pinkfloyd.chass.utoronto.ca> <1335115645-sup-3626@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 22 de Abr de 2012 19:28, "Ben Walton" escreveu: > > Excerpts from Ben Walton's message of Sun Apr 22 12:05:58 -0400 2012: > > > I think this change should likely be applied to the others as well > > once they're verified. > > This is now done. The build runs fine for me with the cleaned > environment for all language bindings. \o/ Very cool idea to clean the environment. Perhaps we could add the env cleaning idiom to our porting FAQ? (for the lack of a better place) -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Sun Apr 22 22:32:11 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 22 Apr 2012 16:32:11 -0400 Subject: [csw-maintainers] gar, checkpkg and subversion ... bratislava? In-Reply-To: References: <1335110585-sup-2791@pinkfloyd.chass.utoronto.ca> <1335115645-sup-3626@pinkfloyd.chass.utoronto.ca> Message-ID: <1335126496-sup-7265@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Sun Apr 22 14:36:33 -0400 2012: > Very cool idea to clean the environment. Perhaps we could add the > env cleaning idiom to our porting FAQ? (for the lack of a better > place) That's probably a good place to note it. Something else to consider might be to have GAR ensure that the environment is always clean instead of only during the important phases. A change to explicit export for all values. This might be most easily accomplished by having mgar invoke gmake as /usr/bin/env -i /opt/csw/gmake. This switch would likely break a few recipes that have implicit dependencies on values from the environment that the maintainer likely doesn't even realize. I found several of these assumptions in my own recipes after the switch Dago implemented to see configure/build/test run in a clean environment. Thoughts? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From grzemba at contac-dt.de Mon Apr 23 09:28:20 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Mon, 23 Apr 2012 09:28:20 +0200 Subject: [csw-maintainers] bad-rpath-entry Message-ID: <7470e5aa1a60.4f9520b4@contac-dt.de> What is bad on this entry?: CHECKPKG_OVERRIDES_CSWnetsnmp += bad-rpath-entry|/opt/csw/lib/|/tmp/pkg_LKUeaT/CSWnetsnmp/root/opt/csw/lib/perl/site_perl/auto/NetSNMP/ASN/ASN.so -- Carsten Grzemba -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilbury at opencsw.org Mon Apr 23 09:30:41 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Mon, 23 Apr 2012 09:30:41 +0200 Subject: [csw-maintainers] bad-rpath-entry In-Reply-To: <7470e5aa1a60.4f9520b4@contac-dt.de> References: <7470e5aa1a60.4f9520b4@contac-dt.de> Message-ID: <4F950521.8040803@opencsw.org> On 04/23/2012 09:28 AM, Carsten Grzemba wrote: > What is bad on this entry?: > > CHECKPKG_OVERRIDES_CSWnetsnmp += > bad-rpath-entry|/opt/csw/lib/|/tmp/pkg_LKUeaT/CSWnetsnmp/root/opt/csw/lib/perl/site_perl/auto/NetSNMP/ASN/ASN.so Look for norunpath in porting FAQ. -- Juraj Lutter From dam at opencsw.org Mon Apr 23 10:34:33 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 23 Apr 2012 10:34:33 +0200 Subject: [csw-maintainers] bad-rpath-entry In-Reply-To: <4F950521.8040803@opencsw.org> References: <7470e5aa1a60.4f9520b4@contac-dt.de> <4F950521.8040803@opencsw.org> Message-ID: <5DCDC01F-1365-4586-B768-3404D0694A2C@opencsw.org> Hi Carsten, Am 23.04.2012 um 09:30 schrieb Juraj Lutter: > On 04/23/2012 09:28 AM, Carsten Grzemba wrote: >> What is bad on this entry?: >> >> CHECKPKG_OVERRIDES_CSWnetsnmp += >> bad-rpath-entry|/opt/csw/lib/|/tmp/pkg_LKUeaT/CSWnetsnmp/root/opt/csw/lib/perl/site_perl/auto/NetSNMP/ASN/ASN.so > > Look for norunpath in porting FAQ. Not this time, it is the trailing '/' that disturbs checkpkg. Just overwrite it, /opt/csw/lib/ is as good as /opt/csw/lib. Best regards -- Dago From maciej at opencsw.org Mon Apr 23 10:59:09 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 23 Apr 2012 10:59:09 +0200 Subject: [csw-maintainers] bad-rpath-entry In-Reply-To: <5DCDC01F-1365-4586-B768-3404D0694A2C@opencsw.org> References: <7470e5aa1a60.4f9520b4@contac-dt.de> <4F950521.8040803@opencsw.org> <5DCDC01F-1365-4586-B768-3404D0694A2C@opencsw.org> Message-ID: No dia 23 de Abril de 2012 10:34, Dagobert Michelsen escreveu: > > Not this time, it is the trailing '/' that disturbs checkpkg. Just overwrite it, > /opt/csw/lib/ is as good as /opt/csw/lib. Override, not overwrite. ;-) Where is the surplus slash coming from? We have fixed krb5-config, haven't we? From grzemba at contac-dt.de Mon Apr 23 11:22:26 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Mon, 23 Apr 2012 11:22:26 +0200 Subject: [csw-maintainers] bad-rpath-entry In-Reply-To: <74a0fb372055.4f951f23@contac-dt.de> References: <74a0fb372055.4f951f23@contac-dt.de> Message-ID: <74a0adaa2124.4f953b72@contac-dt.de> But because of the temporary path prefix /tmp/pkg_LKUeaT/.. I can't override this. And without the prefix it seams that the override will not match? Am 23.04.12, schrieb Dagobert Michelsen : > Hi Carsten, > > Am 23.04.2012 um 09:30 schrieb Juraj Lutter: > > On 04/23/2012 09:28 AM, Carsten Grzemba wrote: > >> What is bad on this entry?: > >> > >> CHECKPKG_OVERRIDES_CSWnetsnmp += > >> bad-rpath-entry|/opt/csw/lib/|/tmp/pkg_LKUeaT/CSWnetsnmp/root/opt/csw/lib/perl/site_perl/auto/NetSNMP/ASN/ASN.so > > > > Look for norunpath in porting FAQ. > > Not this time, it is the trailing '/' that disturbs checkpkg. Just overwrite it, > /opt/csw/lib/ is as good as /opt/csw/lib. > > > Best regards > > ? -- Dago > -- Carsten Grzemba Tel.:?? +49 3677 64740 Mobil: +49 171 9749479 Fax::?? +49 3677 6474111 Email: carsten.grzemba at contac-dt.de contac Datentechnik GmbH -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Mon Apr 23 11:24:57 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 23 Apr 2012 11:24:57 +0200 Subject: [csw-maintainers] bad-rpath-entry In-Reply-To: <74a0adaa2124.4f953b72@contac-dt.de> References: <74a0fb372055.4f951f23@contac-dt.de> <74a0adaa2124.4f953b72@contac-dt.de> Message-ID: Hi Carsten, Am 23.04.2012 um 11:22 schrieb Carsten Grzemba: > But because of the temporary path prefix /tmp/pkg_LKUeaT/.. I can't override this. > And without the prefix it seams that the override will not match? To get something done you can just add CHECKPKG_OVERRIDES_CSWnetsnmp += bad-rpath-entry This override (:-) all errors of this kind. Best regards -- Dago > > Am 23.04.12, schrieb Dagobert Michelsen : >> >> Hi Carsten, >> >> Am 23.04.2012 um 09:30 schrieb Juraj Lutter: >> > On 04/23/2012 09:28 AM, Carsten Grzemba wrote: >> >> What is bad on this entry?: >> >> >> >> CHECKPKG_OVERRIDES_CSWnetsnmp += >> >> bad-rpath-entry|/opt/csw/lib/|/tmp/pkg_LKUeaT/CSWnetsnmp/root/opt/csw/lib/perl/site_perl/auto/NetSNMP/ASN/ASN.so >> > >> > Look for norunpath in porting FAQ. >> >> Not this time, it is the trailing '/' that disturbs checkpkg. Just overwrite it, >> /opt/csw/lib/ is as good as /opt/csw/lib. >> >> >> Best regards >> >> -- Dago > -- > Carsten Grzemba > Tel.: +49 3677 64740 > Mobil: +49 171 9749479 > Fax:: +49 3677 6474111 > Email: carsten.grzemba at contac-dt.de > contac Datentechnik GmbH _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at opencsw.org Mon Apr 23 15:13:39 2012 From: daniel at opencsw.org (Daniel Pocock) Date: Mon, 23 Apr 2012 15:13:39 +0200 Subject: [csw-maintainers] libCstd or stlport? In-Reply-To: References: <4F91BC33.80509@opencsw.org> Message-ID: <4F955583.8050700@opencsw.org> On 21/04/12 21:54, Dagobert Michelsen wrote: > Hi Daniel, > > Am 20.04.2012 um 21:42 schrieb Daniel Pocock: >> I notice that reSIProcate has previously been compiled on Solaris using >> -library=stlport, and I believe this is still necessary or the code >> doesn't compile. Without -library=stlport, it stops like this: >> >> libtool: compile: /opt/SUNWspro/bin/CC -DHAVE_CONFIG_H -I. -I.. >> -I/opt/csw/bdb48/include -I/opt/csw/include -xO3 -m32 -xarch=sparc >> -DRESIP_OSTYPE_SUNOS -DRESIP_ARCH_SPARC -DRESIP_LARCH_SPARC -D_REENTRANT >> -DRESIP_TOOLCHAIN_SUNPRO -c DnsUtil.cxx -KPIC -DPIC -o .libs/DnsUtil.o >> "DnsUtil.cxx", line 550: Error: Formal argument x of type const >> std::pair& in call to >> std::list >::push_back(const >> std::pair&) is being passed std::pair> resip::Data>. >> 1 Error(s) detected. >> >> However, I noticed that dependenices (e.g. >> /opt/csw/bdb48/lib/libdb_cxx-4.8.so) are linked against libCstd >> >> If I add -library=stlport, the code builds, but the repro binary fails >> with a Segmentation fault, before it even enters the main function. The >> stack trace shows a combination of libCstd and stlport classes. >> >> Can anyone comment on how to deal with this situation? Is there a >> convenient way to get versions of the dependencies that are not libCstd >> dependent? Or does the upstream project need to drop the requirement >> for stlport? > > Unfortunately you are right: > http://docs.oracle.com/cd/E19205-01/819-5267/bkakg/index.html > "STLport is binary incompatible with the default libCstd"... > > I guess we need a special version like the gxx tree for libCstd and stlport. > However, it is worse with stlport as the shipped 4.5.3 *may* be incompatible with > any other version of stlport in the future as also said in the linked document. > I suggest having /opt/csw/stlport and see how far we can get. Regarding BDB I guess > that I will rebuild 4.8 against stlport as modulation or different branch and > see if that solves the issue. Unfortunately I probably won't be able to do that > before start of next week. > I had a closer look at the resip code I fixed all the issues discussed in the other email thread (e.g. the const stuff) I then tried the libCstd compile, and got the new problems. Some of the issues were just similar to the prototype problems that were discovered last week. The compiler seems to be more strict when using libCstd than using stlport However, I now get stuck on a much more messy looking error regarding templates. I'm going to post that on the resiprocate list and see if anyone familiar with the code has suggestions. It may or may not be possible to adapt resiprocate for libCstd From jh at opencsw.org Mon Apr 23 15:34:57 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Mon, 23 Apr 2012 15:34:57 +0200 Subject: [csw-maintainers] rework cswinitsmf In-Reply-To: <4F955583.8050700@opencsw.org> References: <4F91BC33.80509@opencsw.org> <4F955583.8050700@opencsw.org> Message-ID: <4F955A81.8040007@opencsw.org> Hi, as discovered today the cswinitsmf (actually the smf part of it) probably needs a rework. When you install a zone and you have a package with smf support installed in the global zone the smf is not imported on the new installed zone. The reason for this is that there is no smf service running yet in the zone so svccfg import etc. do not work. The smf database is created on first boot. But only with manifests that are in /var/svc/manifest. Maybe we should move our manifests to that place too. (I don't now if we ever did or what the reason was not to move it to that place? ) Thoughts? Greetings Jan From bonivart at opencsw.org Mon Apr 23 16:28:54 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 23 Apr 2012 16:28:54 +0200 Subject: [csw-maintainers] rework cswinitsmf In-Reply-To: <4F955A81.8040007@opencsw.org> References: <4F91BC33.80509@opencsw.org> <4F955583.8050700@opencsw.org> <4F955A81.8040007@opencsw.org> Message-ID: On Mon, Apr 23, 2012 at 3:34 PM, Jan Holzhueter wrote: > Maybe we should move our manifests to that place too. (I don't now if we > ever did or what the reason was not to move it to that place? ) For the same reason we don't put configuration directly into /etc, Sun created /etc/opt and /var/opt to get some separation and we used it. Unfortunately they have hardcoded some paths like /usr/sadm for class action scripts and apparently /var/svc as well. Kind of makes it hard to follow guidelines when you lose functionality. :-/ I guess we could move our manifests as long as we make sure name clashes are unlikely (csw-prefix?). The /usr/sadm I don't think we can do anything about. /peter From maciej at opencsw.org Mon Apr 23 22:25:32 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 23 Apr 2012 22:25:32 +0200 Subject: [csw-maintainers] gar, checkpkg and subversion ... bratislava? In-Reply-To: <1335126496-sup-7265@pinkfloyd.chass.utoronto.ca> References: <1335110585-sup-2791@pinkfloyd.chass.utoronto.ca> <1335115645-sup-3626@pinkfloyd.chass.utoronto.ca> <1335126496-sup-7265@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 22 de Abril de 2012 22:32, Ben Walton escreveu: > Something else to consider might be to have GAR ensure that the > environment is always clean instead of only during the important > phases. A change to explicit export for all values. > It wouldn't be backward-compatible, so there is some potential for disruption for old recipes. How could it be achieved, if at all? When you write your own rules, you always inherit the environment, unless you specifically clean it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Mon Apr 23 22:30:43 2012 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 23 Apr 2012 16:30:43 -0400 Subject: [csw-maintainers] gar, checkpkg and subversion ... bratislava? In-Reply-To: References: <1335110585-sup-2791@pinkfloyd.chass.utoronto.ca> <1335115645-sup-3626@pinkfloyd.chass.utoronto.ca> <1335126496-sup-7265@pinkfloyd.chass.utoronto.ca> Message-ID: <1335212910-sup-4207@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Mon Apr 23 16:25:32 -0400 2012: > No dia 22 de Abril de 2012 22:32, Ben Walton escreveu: > > > Something else to consider might be to have GAR ensure that the > > environment is always clean instead of only during the important > > phases. A change to explicit export for all values. > > > > It wouldn't be backward-compatible, so there is some potential for > disruption for old recipes. That is possible, yes. The end result should be better recipes though. > How could it be achieved, if at all? When you write your own rules, > you always inherit the environment, unless you specifically clean > it. If GAR doesn't detect a specific variable in the environment, it re-execs itself with a clean environment plus this value? This should be done before anything else is executed. A better place to do it would be within mgar though, which would give it (another!) advantage over running GAR directly via gmake. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Tue Apr 24 15:08:23 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 24 Apr 2012 15:08:23 +0200 Subject: [csw-maintainers] libCstd or stlport? In-Reply-To: References: <4F91BC33.80509@opencsw.org> Message-ID: <13FD2960-9335-4C26-B034-D80E59829373@opencsw.org> Hi Daniel, Am 21.04.2012 um 21:54 schrieb Dagobert Michelsen: > Am 20.04.2012 um 21:42 schrieb Daniel Pocock: >> I notice that reSIProcate has previously been compiled on Solaris using >> -library=stlport, and I believe this is still necessary or the code >> doesn't compile. Without -library=stlport, it stops like this: >> >> libtool: compile: /opt/SUNWspro/bin/CC -DHAVE_CONFIG_H -I. -I.. >> -I/opt/csw/bdb48/include -I/opt/csw/include -xO3 -m32 -xarch=sparc >> -DRESIP_OSTYPE_SUNOS -DRESIP_ARCH_SPARC -DRESIP_LARCH_SPARC -D_REENTRANT >> -DRESIP_TOOLCHAIN_SUNPRO -c DnsUtil.cxx -KPIC -DPIC -o .libs/DnsUtil.o >> "DnsUtil.cxx", line 550: Error: Formal argument x of type const >> std::pair& in call to >> std::list >::push_back(const >> std::pair&) is being passed std::pair> resip::Data>. >> 1 Error(s) detected. >> >> However, I noticed that dependenices (e.g. >> /opt/csw/bdb48/lib/libdb_cxx-4.8.so) are linked against libCstd >> >> If I add -library=stlport, the code builds, but the repro binary fails >> with a Segmentation fault, before it even enters the main function. The >> stack trace shows a combination of libCstd and stlport classes. >> >> Can anyone comment on how to deal with this situation? Is there a >> convenient way to get versions of the dependencies that are not libCstd >> dependent? Or does the upstream project need to drop the requirement >> for stlport? > > Unfortunately you are right: > http://docs.oracle.com/cd/E19205-01/819-5267/bkakg/index.html > "STLport is binary incompatible with the default libCstd"... > > I guess we need a special version like the gxx tree for libCstd and stlport. > However, it is worse with stlport as the shipped 4.5.3 *may* be incompatible with > any other version of stlport in the future as also said in the linked document. > I suggest having /opt/csw/stlport and see how far we can get. Regarding BDB I guess > that I will rebuild 4.8 against stlport as modulation or different branch and > see if that solves the issue. Unfortunately I probably won't be able to do that > before start of next week. I have now updated libstlport.so.1 to the latest patchlevel and build bdb 4.8 against stlport available at http://buildfarm.opencsw.org/experimental.html#stlport If you want I can install these for you on the testing hosts. Is there a specific ISA you want to test? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From grzemba at contac-dt.de Tue Apr 24 16:55:54 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Tue, 24 Apr 2012 16:55:54 +0200 Subject: [csw-maintainers] package naming convention Message-ID: <7430897b2a3e.4f96db1a@contac-dt.de> Hi, is there a package naming convention for CSW packages? for instance: Python binding for netsnmp CSWnetsnmp-py or CSWpynetsnmp or something else? -- Carsten Grzemba -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Tue Apr 24 16:57:26 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 24 Apr 2012 16:57:26 +0200 Subject: [csw-maintainers] package naming convention In-Reply-To: <7430897b2a3e.4f96db1a@contac-dt.de> References: <7430897b2a3e.4f96db1a@contac-dt.de> Message-ID: Hi Carsten, Am 24.04.2012 um 16:55 schrieb Carsten Grzemba: > is there a package naming convention for CSW packages? > for instance: Python binding for netsnmp > CSWnetsnmp-py or > CSWpynetsnmp or > something else? If it has a well-known name that one should be used. In any other case Python modules should be named CSWpy- so like CSWpy-netsnmp / py_netsnmp (automatically generated conforming catalog name) Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From grzemba at contac-dt.de Tue Apr 24 16:58:08 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Tue, 24 Apr 2012 16:58:08 +0200 Subject: [csw-maintainers] Fwd: package naming convention Message-ID: <7430b8896bbb.4f96dba0@contac-dt.de> Oh, I see it just in the moment, there is a recommendation from check-pkg CSWpy-... -- Carsten Grzemba Tel.:?? +49 3677 64740 Mobil: +49 171 9749479 Fax::?? +49 3677 6474111 Email: carsten.grzemba at contac-dt.de contac Datentechnik GmbH -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: Carsten Grzemba Subject: package naming convention Date: Tue, 24 Apr 2012 16:55:54 +0200 Size: 1390 URL: From bwalton at opencsw.org Tue Apr 24 18:05:41 2012 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 24 Apr 2012 12:05:41 -0400 Subject: [csw-maintainers] package naming convention In-Reply-To: <7430897b2a3e.4f96db1a@contac-dt.de> References: <7430897b2a3e.4f96db1a@contac-dt.de> Message-ID: <1335283492-sup-4536@pinkfloyd.chass.utoronto.ca> Excerpts from Carsten Grzemba's message of Tue Apr 24 10:55:54 -0400 2012: Hi Carsten, > CSWnetsnmp-py or > CSWpynetsnmp or Typically we're doing: CSWpy-netsnmp -> py_netsnmp. Perl modules are pm-/pm_ and ruby, if you build one woulbe rb18-/rb18_ or rb191-/rb191_. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Wed Apr 25 11:31:25 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 25 Apr 2012 11:31:25 +0200 Subject: [csw-maintainers] Google Wave at Rizzoma Message-ID: Hi folks, there is a new company Rizzoma providing wave and I have imported our wave documents and linked them from the wiki so we have them when the Google wave is finally turned off. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Wed Apr 25 12:48:54 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 25 Apr 2012 12:48:54 +0200 Subject: [csw-maintainers] Google Wave at Rizzoma In-Reply-To: References: Message-ID: No dia 25 de Abril de 2012 11:31, Dagobert Michelsen escreveu: > there is a new company Rizzoma providing wave and I have imported our wave documents > and linked them from the wiki so we have them when the Google wave is finally turned off. Thanks Dago. From grzemba at contac-dt.de Wed Apr 25 14:20:38 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Wed, 25 Apr 2012 14:20:38 +0200 Subject: [csw-maintainers] new pkg old libs? Message-ID: <741080169cf.4f980836@contac-dt.de> Hi, is it still a valid way to provide old libs via a tarball file like files/old_libs_s.tar.gz, even though there are now separate lib packages? The old package containig the lib will now obsoleted by the base package. e.g: the active version CSWnetsnmp contains the whole stuff the new version is splited in CSWnetsnmp, CSWlibnetsnmp25, ... and there are old lib's used by other packages lib...so.10 and lib..so.15 -- Carsten Grzemba Tel.:?? +49 3677 64740 Mobil: +49 171 9749479 Fax::?? +49 3677 6474111 Email: carsten.grzemba at contac-dt.de contac Datentechnik GmbH -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Wed Apr 25 14:38:20 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 25 Apr 2012 14:38:20 +0200 Subject: [csw-maintainers] new pkg old libs? In-Reply-To: <741080169cf.4f980836@contac-dt.de> References: <741080169cf.4f980836@contac-dt.de> Message-ID: No dia 25 de Abril de 2012 14:20, Carsten Grzemba escreveu: > the new version is splited in CSWnetsnmp, CSWlibnetsnmp25, ... > and there are old lib's used by other packages lib...so.10 and lib..so.15 If the other packages aren't hard to build, you can rebuild them all. It depends what's easier to do. From dam at opencsw.org Wed Apr 25 14:42:22 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 25 Apr 2012 14:42:22 +0200 Subject: [csw-maintainers] new pkg old libs? In-Reply-To: <741080169cf.4f980836@contac-dt.de> References: <741080169cf.4f980836@contac-dt.de> Message-ID: Hi Carsten, Am 25.04.2012 um 14:20 schrieb Carsten Grzemba: > is it still a valid way to provide old libs via a tarball file like files/old_libs_s.tar.gz, even though there are now separate lib packages? > The old package containig the lib will now obsoleted by the base package. > e.g: > the active version CSWnetsnmp contains the whole stuff > > the new version is splited in CSWnetsnmp, CSWlibnetsnmp25, ... > and there are old lib's used by other packages lib...so.10 and lib..so.15 This is valid, yes. But as netsnmp does not have that many dependencies we should just rebuild them for the upcoming release: - 389 rebuild from you :-) - cyrus_impad from Rafi - mbrowse either rebuild or drop - ntp rebuild from James - php rebuild from Ben Just let me know when you have finished a new CSWnetsnmp with split libs and without legacy libs, put it in /home/experimental/netsnmp, I'll install it then on testing* and we can rebuild the upper packages against it, put it also in experimental and upload the whole bunch at once. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From grzemba at contac-dt.de Thu Apr 26 10:54:28 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Thu, 26 Apr 2012 10:54:28 +0200 Subject: [csw-maintainers] rpath nigthmare Message-ID: <74a0a69e4111.4f992964@contac-dt.de> Hi, if I build netsnmp I have trouble to get useful search paths for so objects in the libs. If I leave the '-L/opt/csw/lib -R/opt/csw/lib/$ISALIST -R/opt/csw/lib' in LDFLAGS of mgar modenv, then it builds all. But in build python module I get the damaged search path /opt/csw/SALIST and the wrong/old libs...so.15? from /opt/csw/lib is used. ?? find object=libnetsnmp.so.15; required by build/lib.solaris-2.10-i86pc-2.6/netsnmp/client_intf.so ??? search path=/opt/csw/lib/SALIST:/opt/csw/lib:/opt/csw/lib/$ISALIST:/opt/csw/lib? (RPATH from file build/lib.solaris-2.10-i86pc-2.6/netsnmp/client_intf.so) ??? trying path=/opt/csw/lib/SALIST/libnetsnmp.so.15 ??? trying path=/opt/csw/lib/libnetsnmp.so.15 If I remove the -L and -R from LDFLAGS from mgar modenv all builds well except for one perlmodule perl/agent/default_store. There I get the strange search path ?? find object=libnetsnmp.so.25; required by blib/arch/auto/NetSNMP/agent/default_store/default_store.so ??? search path=/home/cgrzemba/opencsw/netsnmp/trunk/work/build-isa-pentium_pro/net-snmp-5.6.1.1/perl/agent/default_store/../../../snmplib/.libs:/usr/lib ?(RPATH from file blib/arch/auto/NetSNMP/agent/default_store/default_store.so) ??? trying path=/home/cgrzemba/opencsw/netsnmp/trunk/work/build-isa-pentium_pro/net-snmp-5.6.1.1/perl/agent/default_store/../../../snmplib/.libs/libnetsnmp.so.25 ??????? libnetsnmp.so.25 =>????? /home/cgrzemba/opencsw/netsnmp/trunk/work/build-isa-pentium_pro/net-snmp-5.6.1.1/perl/agent/default_store/../../../snmplib/.libs/libnetsnmp.so.25 Any hints? -- Carsten Grzemba -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Thu Apr 26 10:58:39 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 26 Apr 2012 10:58:39 +0200 Subject: [csw-maintainers] rpath nigthmare In-Reply-To: <74a0a69e4111.4f992964@contac-dt.de> References: <74a0a69e4111.4f992964@contac-dt.de> Message-ID: Hi Carsten, Am 26.04.2012 um 10:54 schrieb Carsten Grzemba: > if I build netsnmp I have trouble to get useful search paths for so objects in the libs. > > If I leave the '-L/opt/csw/lib -R/opt/csw/lib/$ISALIST -R/opt/csw/lib' in LDFLAGS of mgar modenv, then it builds all. > > But in build python module I get the damaged search path /opt/csw/SALIST and the wrong/old libs...so.15 from /opt/csw/lib is used. This is because LDFLAGS is passed via shell and the variable is evaluated a different number of times in the main and the module build. This cannot be solved with LDFLAGS, but only via LD_OPTIONS or alternatively skip $ISALIST completely. It is just an optimization. Just say NOISALIST = 1 for now. IIRC LD_OPTIONS was also not possible as this prefers installed libraries always before newly build ones. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From daniel at opencsw.org Thu Apr 26 16:20:15 2012 From: daniel at opencsw.org (Daniel Pocock) Date: Thu, 26 Apr 2012 16:20:15 +0200 Subject: [csw-maintainers] libCstd or stlport? In-Reply-To: <13FD2960-9335-4C26-B034-D80E59829373@opencsw.org> References: <4F91BC33.80509@opencsw.org> <13FD2960-9335-4C26-B034-D80E59829373@opencsw.org> Message-ID: <4F99599F.4000204@opencsw.org> On 24/04/12 15:08, Dagobert Michelsen wrote: > Hi Daniel, > > Am 21.04.2012 um 21:54 schrieb Dagobert Michelsen: >> Am 20.04.2012 um 21:42 schrieb Daniel Pocock: >>> I notice that reSIProcate has previously been compiled on Solaris using >>> -library=stlport, and I believe this is still necessary or the code >>> doesn't compile. Without -library=stlport, it stops like this: >>> >>> libtool: compile: /opt/SUNWspro/bin/CC -DHAVE_CONFIG_H -I. -I.. >>> -I/opt/csw/bdb48/include -I/opt/csw/include -xO3 -m32 -xarch=sparc >>> -DRESIP_OSTYPE_SUNOS -DRESIP_ARCH_SPARC -DRESIP_LARCH_SPARC -D_REENTRANT >>> -DRESIP_TOOLCHAIN_SUNPRO -c DnsUtil.cxx -KPIC -DPIC -o .libs/DnsUtil.o >>> "DnsUtil.cxx", line 550: Error: Formal argument x of type const >>> std::pair& in call to >>> std::list >::push_back(const >>> std::pair&) is being passed std::pair>> resip::Data>. >>> 1 Error(s) detected. >>> >>> However, I noticed that dependenices (e.g. >>> /opt/csw/bdb48/lib/libdb_cxx-4.8.so) are linked against libCstd >>> >>> If I add -library=stlport, the code builds, but the repro binary fails >>> with a Segmentation fault, before it even enters the main function. The >>> stack trace shows a combination of libCstd and stlport classes. >>> >>> Can anyone comment on how to deal with this situation? Is there a >>> convenient way to get versions of the dependencies that are not libCstd >>> dependent? Or does the upstream project need to drop the requirement >>> for stlport? >> >> Unfortunately you are right: >> http://docs.oracle.com/cd/E19205-01/819-5267/bkakg/index.html >> "STLport is binary incompatible with the default libCstd"... >> >> I guess we need a special version like the gxx tree for libCstd and stlport. >> However, it is worse with stlport as the shipped 4.5.3 *may* be incompatible with >> any other version of stlport in the future as also said in the linked document. >> I suggest having /opt/csw/stlport and see how far we can get. Regarding BDB I guess >> that I will rebuild 4.8 against stlport as modulation or different branch and >> see if that solves the issue. Unfortunately I probably won't be able to do that >> before start of next week. > > I have now updated libstlport.so.1 to the latest patchlevel and build bdb 4.8 > against stlport available at > http://buildfarm.opencsw.org/experimental.html#stlport > > If you want I can install these for you on the testing hosts. Is there a specific > ISA you want to test? I've had a play with things in the resip stack itself - I've now got it working with libCstd. In the long run, I think the stlport stuff will make OpenCSW more flexible, but it is not blocking resiprocate any more. I found some limitations of libCstd: - remove_if doesn't want to take an object as a predicate, it only wants a non-object function pointer - auto-boxing doesn't work in some cases, it is necessary to be more explicit - odd errors about casts appear when trying to use a custom allocator with std::list. I've reverted to the default allocator (the custom one is there for performance reasons) - the compiler also seems even more pedantic about function prototypes in headers if I use libCstd rather than stlport If you want to see the details of things that needed tweaking and how I solved each of them, it is all logged here: http://list.resiprocate.org/archive/resiprocate-commit/ From james at opencsw.org Fri Apr 27 11:45:57 2012 From: james at opencsw.org (James Lee) Date: Fri, 27 Apr 2012 09:45:57 GMT Subject: [csw-maintainers] setting *FLAGS? In-Reply-To: <4F914BC0.6010607@opencsw.org> References: <4F901BE0.8070206@opencsw.org> <94B2A488-35E0-44F0-A005-74B065E14EA4@opencsw.org> <4F902FC8.5000803@opencsw.org> <4F9033CF.3060901@opencsw.org> <4F914BC0.6010607@opencsw.org> Message-ID: <20120427.9455700.3300982234@gyor.oxdrove.co.uk> On 20/04/12, 12:42:56, Daniel Pocock wrote regarding Re: [csw-maintainers] setting *FLAGS?: > > Sun Studio honours "const" for mangling whereas GCC does not, so the > > error is a result > > of the stricter checks of Sun Studio (which is IMHO a good thing). > I agree this should be tidied up, if it's just one or two cases of the > problem, I'll fix it upstream. > However, is there any flag for the compiler to behave more like gcc, in > case the problem is too tedious to fix quickly? Indeed there is: CC -compat=g ... That will cause problems if you are making a library with a C++ API. However, compiler deficiencies (in this case gcc's) are not an excuse for sloppy code, best to fix the consts. On an unrelated matter I just found this related problem: https://forums.oracle.com/forums/thread.jspa?threadID=2313694 ...ouch. Ah, the good old days of FORTRAN when the compiler let you change the global value of a numeric constant, eg 2, by passing it to a subroutine. James. From grzemba at contac-dt.de Fri Apr 27 11:58:15 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Fri, 27 Apr 2012 11:58:15 +0200 Subject: [csw-maintainers] net-snmp new pkg old libs? In-Reply-To: <74a0f5735e7c.4f9a6d42@contac-dt.de> References: <74a0f5735e7c.4f9a6d42@contac-dt.de> Message-ID: <74a0a5782e01.4f9a89d7@contac-dt.de> Hi, the packages are on /home/eperimental/net-snmp. For rebuild of 389-Directory-Server I will wait some days if there a version 1.2.10.5 released in the next days. Regards Am 25.04.12, schrieb Dagobert Michelsen : > Hi Carsten, > > Am 25.04.2012 um 14:20 schrieb Carsten Grzemba: > > is it still a valid way to provide old libs via a tarball file like files/old_libs_s.tar.gz, even though there are now separate lib packages? > > The old package containig the lib will now obsoleted by the base package. > > e.g: > > the active version CSWnetsnmp contains the whole stuff > > > > the new version is splited in CSWnetsnmp, CSWlibnetsnmp25, ... > > and there are old lib's used by other packages lib...so.10 and lib..so.15 > > This is valid, yes. But as netsnmp does not have that many dependencies we should just > rebuild them for the upcoming release: > > - 389 rebuild from you :-) > - cyrus_impad from Rafi > - mbrowse either rebuild or drop > - ntp rebuild from James > - php rebuild from Ben > > Just let me know when you have finished a new CSWnetsnmp with split libs and > without legacy libs, put it in /home/experimental/netsnmp, I'll install it then > on testing* and we can rebuild the upper packages against it, put it also in > experimental and upload the whole bunch at once. > > > Best regards > > ? -- Dago > > > -- > "You don't become great by trying to be great, you become great by wanting to do something, > and then doing it so hard that you become great in the process." - xkcd #896 > > > -- Carsten Grzemba -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Fri Apr 27 13:13:49 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 27 Apr 2012 13:13:49 +0200 Subject: [csw-maintainers] net-snmp new pkg old libs? In-Reply-To: <74a0a5782e01.4f9a89d7@contac-dt.de> References: <74a0f5735e7c.4f9a6d42@contac-dt.de> <74a0a5782e01.4f9a89d7@contac-dt.de> Message-ID: <70C09C40-51AD-41F9-983B-6AD739E8EFF5@opencsw.org> Hi Carsten, Am 27.04.2012 um 11:58 schrieb Carsten Grzemba: > the packages are on /home/eperimental/net-snmp. I installed the new net-snmp it on testing*, please use these machines for rebuild. Best regards -- Dago > > Regards > > Am 25.04.12, schrieb Dagobert Michelsen : >> >> Hi Carsten, >> >> Am 25.04.2012 um 14:20 schrieb Carsten Grzemba: >> > is it still a valid way to provide old libs via a tarball file like files/old_libs_s.tar.gz, even though there are now separate lib packages? >> > The old package containig the lib will now obsoleted by the base package. >> > e.g: >> > the active version CSWnetsnmp contains the whole stuff >> > >> > the new version is splited in CSWnetsnmp, CSWlibnetsnmp25, ... >> > and there are old lib's used by other packages lib...so.10 and lib..so.15 >> >> This is valid, yes. But as netsnmp does not have that many dependencies we should just >> rebuild them for the upcoming release: >> >> - 389 rebuild from you :-) >> - cyrus_impad from Rafi >> - mbrowse either rebuild or drop >> - ntp rebuild from James >> - php rebuild from Ben >> >> Just let me know when you have finished a new CSWnetsnmp with split libs and >> without legacy libs, put it in /home/experimental/netsnmp, I'll install it then >> on testing* and we can rebuild the upper packages against it, put it also in >> experimental and upload the whole bunch at once. >> >> >> Best regards >> >> -- Dago >> >> >> -- >> "You don't become great by trying to be great, you become great by wanting to do something, >> and then doing it so hard that you become great in the process." - xkcd #896 >> > -- > Carsten Grzemba > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Fri Apr 27 13:16:50 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 27 Apr 2012 13:16:50 +0200 Subject: [csw-maintainers] net-snmp new pkg old libs? In-Reply-To: <70C09C40-51AD-41F9-983B-6AD739E8EFF5@opencsw.org> References: <74a0f5735e7c.4f9a6d42@contac-dt.de> <74a0a5782e01.4f9a89d7@contac-dt.de> <70C09C40-51AD-41F9-983B-6AD739E8EFF5@opencsw.org> Message-ID: No dia 27 de Abril de 2012 13:13, Dagobert Michelsen escreveu: > I installed the new net-snmp it on testing*, please use these machines for > rebuild. > Is this a good idea? I was promoting the notion that test machines are explicitly not for rebuilding. If you have a rebuild that might break stuff, do it in unstable, and do it quickly. Our automated release process allows for that. You shouldn't release packages built on testing machines. Maybe you can use them to test if your updated recipes work. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Fri Apr 27 13:23:40 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 27 Apr 2012 13:23:40 +0200 Subject: [csw-maintainers] net-snmp new pkg old libs? In-Reply-To: References: <74a0f5735e7c.4f9a6d42@contac-dt.de> <74a0a5782e01.4f9a89d7@contac-dt.de> <70C09C40-51AD-41F9-983B-6AD739E8EFF5@opencsw.org> Message-ID: <26B6100C-DC15-409A-868F-9E9ECEBAF482@opencsw.org> Hi Maciej, Am 27.04.2012 um 13:16 schrieb Maciej (Matchek) Blizi?ski: > No dia 27 de Abril de 2012 13:13, Dagobert Michelsen escreveu: > I installed the new net-snmp it on testing*, please use these machines for rebuild. > > Is this a good idea? I was promoting the notion that test machines are explicitly not for rebuilding. If you have a rebuild that might break stuff, do it in unstable, and do it quickly. Our automated release process allows for that. > > You shouldn't release packages built on testing machines. Maybe you can use them to test if your updated recipes work. No problem :-) Should I then update unstable* with the updated netsnmp now? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Fri Apr 27 13:45:11 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 27 Apr 2012 13:45:11 +0200 Subject: [csw-maintainers] net-snmp new pkg old libs? In-Reply-To: <26B6100C-DC15-409A-868F-9E9ECEBAF482@opencsw.org> References: <74a0f5735e7c.4f9a6d42@contac-dt.de> <74a0a5782e01.4f9a89d7@contac-dt.de> <70C09C40-51AD-41F9-983B-6AD739E8EFF5@opencsw.org> <26B6100C-DC15-409A-868F-9E9ECEBAF482@opencsw.org> Message-ID: No dia 27 de Abril de 2012 13:23, Dagobert Michelsen escreveu: > No problem :-) Should I then update unstable* with the updated netsnmp now? Are the updated packages already in the repository? I remember that we didn't want to install experimental packages on unstable hosts, but maybe it doesn't have to apply to libraries that don't have many dependencies. Maciej From yann at pleiades.fr.eu.org Fri Apr 27 14:43:36 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Fri, 27 Apr 2012 14:43:36 +0200 Subject: [csw-maintainers] checkpkg issues with last openssl build Message-ID: Hi everybody, I am currently having some checkpkg problem with the last openssl build (which contains a security fix, so quick help is welcome :) ). CHECKPKG_OVERRIDES_CSWlibssl0-9-8 += bad-rpath-entry|/opt/csw/lib/sparcv8plus+vis|/tmp/pkg_0mVWKJ/CSWlibssl0-9-8/root/opt/csw/lib/sparcv8plus+vis/libcrypto.so.0.9.7 CHECKPKG_OVERRIDES_CSWlibssl0-9-8 += bad-rpath-entry|/opt/csw/lib/sparcv8plus+vis|/tmp/pkg_0mVWKJ/CSWlibssl0-9-8/root/opt/csw/lib/sparcv8plus+vis/libssl.so.0.9.7 I used to have an override for this one, but the temporary path (/tmp/pkg_*) preprended now prevents it from working. Is this some bug in the GAR system ? * Unused Override: CSWossldevel: surplus-dependency CSWlibssl-dev * Unused Override: CSWosslutils: archall-devel-package * Unused Override: CSWossl: archall-devel-package * Unused Override: CSWosslrt: archall-devel-package These ones are automatically added by "OBSOLETED_BY" macros, I could stop using the macro but I would rather have the macro fixed so it doesn't trigger checkpkg warnings. I don't know if I am missing something there but any help is welcome :) Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Fri Apr 27 14:47:30 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 27 Apr 2012 14:47:30 +0200 Subject: [csw-maintainers] checkpkg issues with last openssl build In-Reply-To: References: Message-ID: <82703A87-F9A4-4915-B7BC-C5CA1EFCCC1F@opencsw.org> Hi Yann, Am 27.04.2012 um 14:43 schrieb Yann Rouillard: > I am currently having some checkpkg problem with the last openssl build (which contains a security fix, so quick help is welcome :) ). > > CHECKPKG_OVERRIDES_CSWlibssl0-9-8 += bad-rpath-entry|/opt/csw/lib/sparcv8plus+vis|/tmp/pkg_0mVWKJ/CSWlibssl0-9-8/root/opt/csw/lib/sparcv8plus+vis/libcrypto.so.0.9.7 > CHECKPKG_OVERRIDES_CSWlibssl0-9-8 += bad-rpath-entry|/opt/csw/lib/sparcv8plus+vis|/tmp/pkg_0mVWKJ/CSWlibssl0-9-8/root/opt/csw/lib/sparcv8plus+vis/libssl.so.0.9.7 > > I used to have an override for this one, but the temporary path (/tmp/pkg_*) preprended now prevents it from working. > Is this some bug in the GAR system ? First the RPATH of /opt/csw/lib/sparcv8plus+vis containing the ISA suffix looks wrong. Are you not also using $ISALIST? Then this could be skipped. Maybe Maciej has an idea on the tmp pathes. To get going you can override all RPATH errors with CHECKPKG_OVERRIDES_CSWlibssl0-9-8 += bad-rpath-entry > * Unused Override: CSWossldevel: surplus-dependency CSWlibssl-dev > * Unused Override: CSWosslutils: archall-devel-package > * Unused Override: CSWossl: archall-devel-package > * Unused Override: CSWosslrt: archall-devel-package > > These ones are automatically added by "OBSOLETED_BY" macros, I could stop using the macro but I would rather have the macro fixed so it doesn't trigger checkpkg warnings. This is normal and they are safe to ignore - that's why they are warnings instead of errors. The reason is that the automatic rules just override errors which can occur without checking if they occur (this would require checking code inside the obsoletion which is only done at a much later stage). Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From yann at pleiades.fr.eu.org Fri Apr 27 15:00:44 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Fri, 27 Apr 2012 15:00:44 +0200 Subject: [csw-maintainers] checkpkg issues with last openssl build In-Reply-To: <82703A87-F9A4-4915-B7BC-C5CA1EFCCC1F@opencsw.org> References: <82703A87-F9A4-4915-B7BC-C5CA1EFCCC1F@opencsw.org> Message-ID: Hi Dam, Thanks for the quick answer. My comments below. Le 27 avril 2012 14:47, Dagobert Michelsen a ?crit : > > I used to have an override for this one, but the temporary path > (/tmp/pkg_*) preprended now prevents it from working. > > Is this some bug in the GAR system ? > > First the RPATH of /opt/csw/lib/sparcv8plus+vis containing the ISA suffix > looks wrong. > Are you not also using $ISALIST? Then this could be skipped. > The old 0.9.7 libraries are pre-compiled, I didn't re-compile them since some time. I would rather drop these old libraries, there are not supported by upstream anymore and there are only four package still linked to 0.9.7: jabberd, conserver, libpq and anjuta (see https://www.opencsw.org/mantis/search.php?project_id=0&search=0.9.7&sticky_issues=on&sortby=last_updated&dir=DESC&hide_status_id=90) > > Maybe Maciej has an idea on the tmp pathes. > > To get going you can override all RPATH errors with > CHECKPKG_OVERRIDES_CSWlibssl0-9-8 += bad-rpath-entry Thanks, will do that while waiting for the final fix. > > * Unused Override: CSWossldevel: surplus-dependency CSWlibssl-dev > > * Unused Override: CSWosslutils: archall-devel-package > > * Unused Override: CSWossl: archall-devel-package > > * Unused Override: CSWosslrt: archall-devel-package > > > > These ones are automatically added by "OBSOLETED_BY" macros, I could > stop using the macro but I would rather have the macro fixed so it doesn't > trigger checkpkg warnings. > > This is normal and they are safe to ignore - that's why they are warnings > instead of errors. > The reason is that the automatic rules just override errors which can > occur without checking > if they occur (this would require checking code inside the obsoletion > which is only done at a > much later stage). > Are these overrides still useful in some case ? Yann > > > Best regards > > -- Dago > > -- > "You don't become great by trying to be great, you become great by wanting > to do something, > and then doing it so hard that you become great in the process." - xkcd > #896 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Fri Apr 27 15:31:30 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 27 Apr 2012 15:31:30 +0200 Subject: [csw-maintainers] checkpkg issues with last openssl build In-Reply-To: References: <82703A87-F9A4-4915-B7BC-C5CA1EFCCC1F@opencsw.org> Message-ID: <45907588-5244-4CB4-B8DD-31B32DC17A5E@opencsw.org> Hi Yann, Am 27.04.2012 um 15:00 schrieb Yann Rouillard: > The old 0.9.7 libraries are pre-compiled, I didn't re-compile them since some time. > I would rather drop these old libraries, there are not supported by upstream anymore and there are only four package still linked to 0.9.7: > jabberd IIRC we tried to rebuild it but it prove to be difficult and not supported by upstream anyway as it was not meant to be distributed as binary. Or am I mixing things up here? > conserver This should probably be rebuild. > libpq Rafi: Do you think we can drop this? > anjuta Maciej: I guess this can be dropped. > (see https://www.opencsw.org/mantis/search.php?project_id=0&search=0.9.7&sticky_issues=on&sortby=last_updated&dir=DESC&hide_status_id=90 ) > > > * Unused Override: CSWossldevel: surplus-dependency CSWlibssl-dev > > * Unused Override: CSWosslutils: archall-devel-package > > * Unused Override: CSWossl: archall-devel-package > > * Unused Override: CSWosslrt: archall-devel-package > > > > These ones are automatically added by "OBSOLETED_BY" macros, I could stop using the macro but I would rather have the macro fixed so it doesn't trigger checkpkg warnings. > > This is normal and they are safe to ignore - that's why they are warnings instead of errors. > The reason is that the automatic rules just override errors which can occur without checking > if they occur (this would require checking code inside the obsoletion which is only done at a > much later stage). > > Are these overrides still useful in some case ? Yes, that's why they are in there :-) Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Fri Apr 27 15:32:20 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 27 Apr 2012 15:32:20 +0200 Subject: [csw-maintainers] checkpkg issues with last openssl build In-Reply-To: References: <82703A87-F9A4-4915-B7BC-C5CA1EFCCC1F@opencsw.org> Message-ID: No dia 27 de Abril de 2012 15:00, Yann Rouillard escreveu: > Maybe Maciej has an idea on the tmp pathes. This is a bug. I will try to fix it this weekend. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Fri Apr 27 15:38:23 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 27 Apr 2012 15:38:23 +0200 Subject: [csw-maintainers] [csw-pkgrequests] New package request : Apache 2.4.x In-Reply-To: <79daac4d-3f54-4bbf-b1fe-760e131509da@iris> References: <79daac4d-3f54-4bbf-b1fe-760e131509da@iris> Message-ID: Hi Igor, Am 27.04.2012 um 15:31 schrieb Igor Gali?: > ----- Original Message ----- >> Dear maintainers, >> >> A new package request has been received from Brian King >> (mailto:Brian.King at bellaliant.ca). Apache 2.4.x is requested to be >> added to our catalog. >> >> Here is the attached message : >> >> We would like to start using the new apache 2.4.x line but would also >> like to stick with opencsw packaging, rather than rolling our own. >> Are there any plans to start packaging apache 2.4 >> (http://httpd.apache.org/download.cgi#apache24) in the near future? > > \o/ > > if you need any help with packaging 2.4 I would love to assist > > (I'm alredy running it in production, albeit on Linux) Excellent, Ben can for sure use a helping hand as the update is probably quite some work. Brian: Feel free to join us on #opencsw at Freenode IRC for progress. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Fri Apr 27 16:19:09 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 27 Apr 2012 16:19:09 +0200 Subject: [csw-maintainers] xscreensaver and libkrb4.so.2 In-Reply-To: References: Message-ID: <2BA942F3-6258-4A3A-A511-841C37DAD443@opencsw.org> Hi Jeffery, Am 08.04.2012 um 05:54 schrieb Jeffery Small: > After my recent upgrade in testing I discovered that xscreensaver is no > longer working under my gnome desktop. when I try to start it manually it > reports: > > 5-> xscreensaver -no-splash > ld.so.1: xscreensaver: fatal: libkrb4.so.2: open failed: \ > No such file or directory > Killed > > Sure enough, there is no libkrb4.so.2 remaining on the system. > > I see that this has apparently been replaced with libkrb5.so.3, however > the CSWxsave package has not been upgraded to use this. (it is still at > 5.11,REV=2010.07.12). > > It is interesting that when I do a file search for libkrb5.so.3 it reports > a pile of packages as dependent upon CSWlibkrb5-3, including CSWxsave. > When I do a search for libkrb4.so.2 it also reports CSWxsave as the only > package dependent upon this library. So there seems to be some sort of > inconsistency in how this is getting logged in the database. Maybe this is > provides a clue as to why the CSWxsave package got missed in the upgrade. > > Can xscreensaver please be repackaged to use the current library? Thanks. I am currently taking a look at this. The problem is that xscreensaver requires the kerberos v4 API which requires krb5 to be compiled in krb4 compat mode which we currently don't have. Do you need kerberos support? If not, I have prepared a preliminary package to test in http://buildfarm.opencsw.org/experimental.html#xscreensaver which will show up shortly. Please let me know if this works for you. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From opk at opencsw.org Fri Apr 27 16:59:31 2012 From: opk at opencsw.org (Oliver Kiddle) Date: Fri, 27 Apr 2012 16:59:31 +0200 Subject: [csw-maintainers] release pygtk 2.17.0 In-Reply-To: References: <7490b80167d2.4f5dc937@contac-dt.de> Message-ID: <23428.1335538771@thecus.kiddle.eu> On 12 Mar, Maciej (Matchek) Blizi?ski wrote: > Looking at http://www.opencsw.org/packages/pygtk/ I see gnome and > skencil as dependencies. You can see if skencil still works. Gnome is If you look back in the list archives, you'll see I sent a message about skencil on 19 Oct 2010. It would really be best to simply remove skencil from the package repository: nobody wants it and it doesn't work. Oliver From bwalton at opencsw.org Fri Apr 27 19:03:36 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 27 Apr 2012 13:03:36 -0400 Subject: [csw-maintainers] Fwd: [csw-users] CSWsyslogng version mismatch Message-ID: <1335546192-sup-7734@pinkfloyd.chass.utoronto.ca> There is some sort of breakage here...the old version is still in the 5.11 catalogs. Maciej? Thanks -Ben --- Begin forwarded message from dennis jenkins --- From: dennis jenkins To: users Date: Fri, 27 Apr 2012 11:42:49 -0400 Subject: [csw-users] CSWsyslogng version mismatch Hello. My system is Solaris 11 (11/11) [1]. I wish to install CSWsyslog_ng. "pkgutil" shows that it would install version 3.0.5,REV=2010.02.27 (over 2 years old) [2], but the OpenCSW online package index shows that it should install 3.2.5,REV=2012.03.19 (yeah!) [3] I've tried both "testing" and "unstable". I've refreshed my catalog several times. What am I missing? How do I get OpenCSW to give me the more recent syslog_ng? Thank you for your time. [1] (root at sol-11: <~>) # uname -a SunOS sol-11-ai-mad-1 5.11 11.0 i86pc i386 i86pc (root at sol-11: <~>) # cat /etc/release Oracle Solaris 11 11/11 X86 Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved. Assembled 18 October 2011 [2] (root at sol-11: <~>) # /opt/csw/bin/pkgutil -a | grep CSWsyslogng syslog_ng CSWsyslogng 3.0.5,REV=2010.02.27 135.5 KB (root at sol-11: <~>) # /opt/csw/bin/pkgutil --catinfo URL http://mirror.opencsw.org/opencsw/unstable/i386/5.11 Release - Creation time 2012-04-27T13:33:47Z Number of pkgs 3453 File /var/opt/csw/pkgutil/catalog.mirror.opencsw.org_opencsw_unstable_i386_5.11 [3] http://www.opencsw.org/packages/syslog_ng/ Hello. ?? My system is Solaris 11 (11/11) [1].? I wish to install CSWsyslog_ng.? "pkgutil" shows that it would install version 3.0.5,REV=2010.02.27 (over 2 years old) [2], but the OpenCSW online package index shows that it should install 3.2.5,REV=2012.03.19 (yeah!) [3] ?? I've tried both "testing" and "unstable".? I've refreshed my catalog several times.? What am I missing?? How do I get OpenCSW to give me the more recent syslog_ng? ?? Thank you for your time. [1] (root at sol-11: <~>) # uname -a SunOS sol-11-ai-mad-1 5.11 11.0 i86pc i386 i86pc (root at sol-11: <~>) # cat /etc/release ?????????????????????????? Oracle Solaris 11 11/11 X86 ? Copyright (c) 1983, 2011, Oracle and/or its affiliates.? All rights reserved. ??????????????????????????? Assembled 18 October 2011 [2] (root at sol-11: <~>) # /opt/csw/bin/pkgutil -a | grep CSWsyslogng syslog_ng??????????? CSWsyslogng????????? 3.0.5,REV=2010.02.27?????? 135.5 KB (root at sol-11: <~>) # /opt/csw/bin/pkgutil --catinfo URL???????????? [1]http://mirror.opencsw.org/opencsw/unstable/i386/5.11 Release???????? - Creation time?? 2012-04-27T13:33:47Z Number of pkgs? 3453 File??????????? /var/opt/csw/pkgutil/catalog.mirror.opencsw.org_opencsw_unstable_i386_5.11 [3] [2]http://www.opencsw.org/packages/syslog_ng/ References Visible links 1. http://mirror.opencsw.org/opencsw/unstable/i386/5.11 2. http://www.opencsw.org/packages/syslog_ng/ --- End forwarded message --- -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Mon Apr 30 09:11:58 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 30 Apr 2012 08:11:58 +0100 Subject: [csw-maintainers] checkpkg issues with last openssl build In-Reply-To: <45907588-5244-4CB4-B8DD-31B32DC17A5E@opencsw.org> References: <82703A87-F9A4-4915-B7BC-C5CA1EFCCC1F@opencsw.org> <45907588-5244-4CB4-B8DD-31B32DC17A5E@opencsw.org> Message-ID: 2012/4/27 Dagobert Michelsen > > Hi Yann, > > Am 27.04.2012 um 15:00 schrieb Yann Rouillard: > > The old 0.9.7 libraries are pre-compiled, I didn't re-compile them since some time. > > I would rather drop these old libraries, there are not supported by upstream anymore and there are only four package still linked to 0.9.7: > > > jabberd > > IIRC we tried to rebuild it but it prove to be difficult and not > supported by upstream anyway as it was not meant to be distributed > as binary. Or am I mixing things up here? > > > conserver > > This should probably be rebuild. > > > libpq > > Rafi: Do you think we can drop this? There's a number of reverse dependencies. aide Advanced Intrusion Detection Environment courier_auth Generic authentication API for Courier mail services dovecot Secure IMAP server exim The Exim Mail Transfer Agent libpqxx C++ client API for PostgreSQL. Supersedes older libpq++ interface. nagios_plugins plugins for nagios php5_pdopgsql The pdopgsql extention for PHP5 php5_pgsql The pgsql extention for PHP5 By the way, how is the new PHP linked against the old libpq while the new one is already in place? pm_dbdpg DBD-Pg: PostgreSQL database driver for the DBI module postgresqlcontrib utilities not part of the core PostgreSQL distribution pypgsql A Python DB-API 2.0 interface to PostgreSQL v7.x py_psycopg2 Psycopg2 is a PostgreSQL adapter for Python sasl_sql Cyrus Simple Authentication and Security Layer SQL Binding At least some of them look like they can be rebuilt. > > > anjuta > > Maciej: I guess this can be dropped. Done. From maciej at opencsw.org Mon Apr 30 09:17:27 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 30 Apr 2012 08:17:27 +0100 Subject: [csw-maintainers] checkpkg issues with last openssl build In-Reply-To: References: <82703A87-F9A4-4915-B7BC-C5CA1EFCCC1F@opencsw.org> Message-ID: 2012/4/27 Maciej (Matchek) Blizi?ski : > No dia 27 de Abril de 2012 15:00, Yann Rouillard > escreveu: > >> Maybe Maciej has an idea on the tmp pathes. > > > This is a bug. I will try to fix it this weekend. Fixed in r17901. http://sourceforge.net/apps/trac/gar/changeset/17901 From dam at opencsw.org Mon Apr 30 09:36:01 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 30 Apr 2012 09:36:01 +0200 Subject: [csw-maintainers] xscreensaver and libkrb4.so.2 In-Reply-To: <1333893892-sup-1678@pinkfloyd.chass.utoronto.ca> References: <1333893892-sup-1678@pinkfloyd.chass.utoronto.ca> Message-ID: Hi Ben, Am 08.04.2012 um 16:07 schrieb Ben Walton: > Hi Jeff, > >>> Can xscreensaver please be repackaged to use the current library? >>> Thanks. >> >> Have you tried respinning the build recipe from Subversion? The >> package is currently orphaned, so if you care about this package, >> it's the best way to get things moving forward. > > For fun, I spun this build. It's a non-GAR recipe that Phil wrote. > Compilation is fine but I don't have stagepkg in my PATH and didn't > poke around for it. It's likely a fairly easy update if you're > interested. > > The noted discrepancy in the database isn't actually a discrepancy. > The binaries in that package do depend on libkrb4, so they're still in > the table that tracks that. Unfortunately, nothing provides that > library any longer so there is a breakage. > > If you want/need this update, I'd suggest turning it into a GAR recipe > and updating it to use the latest krb5 libs. This is not possible as xscreensaver requires the kerberos 4 API and we have not compiled our kerberos 5 with krb4 compat mode. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From grzemba at contac-dt.de Mon Apr 30 11:19:10 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Mon, 30 Apr 2012 11:19:10 +0200 Subject: [csw-maintainers] OBSOLETED_BY_ not work? Message-ID: <7430d0d25294.4f9e752e@contac-dt.de> Hi, /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.9 --architecture i386 d9b1f8d5af903ced92e4fbf24f5de2bb reports many errors of this kind: CHECKPKG_OVERRIDES_CSWpoppler-data += file-collision|/opt/csw/share/poppler/cMap/Adobe-Japan1/RKSJ-H|CSWpoppler-data|CSWpopplerdata CSWpoppler-data replaces CSWpopplerdata the recipe contains: OBSOLETED_BY_CSWpoppler-data = CSWpopplerdata What's wrong? -- Carsten Grzemba -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Mon Apr 30 11:26:12 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 30 Apr 2012 11:26:12 +0200 Subject: [csw-maintainers] OBSOLETED_BY_ not work? In-Reply-To: <7430d0d25294.4f9e752e@contac-dt.de> References: <7430d0d25294.4f9e752e@contac-dt.de> Message-ID: <198E6B2D-1226-46C3-8A19-5BCBB298A4CF@opencsw.org> Hi Carsten, Am 30.04.2012 um 11:19 schrieb Carsten Grzemba: > /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.9 --architecture i386 d9b1f8d5af903ced92e4fbf24f5de2bb > > reports many errors of this kind: > > CHECKPKG_OVERRIDES_CSWpoppler-data += file-collision|/opt/csw/share/poppler/cMap/Adobe-Japan1/RKSJ-H|CSWpoppler-data|CSWpopplerdata > > CSWpoppler-data replaces CSWpopplerdata > > the recipe contains: > > OBSOLETED_BY_CSWpoppler-data = CSWpopplerdata > > What's wrong? The old package and catalogname didn't match: CSWpopplerdata -> poppler_data so you need CATALOGNAME_CSWpopplerdata = poppler_data_stub or the new obsoleted package has the same catalog name as the current one. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From james at opencsw.org Mon Apr 30 13:21:16 2012 From: james at opencsw.org (James Lee) Date: Mon, 30 Apr 2012 11:21:16 GMT Subject: [csw-maintainers] Solaris 10 revision suppport? Message-ID: <20120430.11211600.3907441236@gyor.oxdrove.co.uk> What is the CSW support for the revisions of Solaris 10? This page: http://www.opencsw.org/manual/for-administrators/introduction.html says "Solaris 10 is fully supported." which isn't true as CSWorbit2 2.14.19,REV=2011.12.08 doesn't work with Solaris 10U4. Either we consider this a bug and fix it or CSW is only supported on certain revisions of Solaris 10, either way I'm happy but if taking the latter it would help to explain this better, that is at a minimum change the above web page. ** A Failure ** $ soffice ld.so.1: soffice.bin: fatal: libresolv.so.2: version `SUNW_2.2.2' not found (required by file /opt/csw/lib/sparcv8/libORBit-2.so.0) ld.so.1: soffice.bin: fatal: libresolv.so.2: open failed: No such file or directory ld.so.1: soffice.bin: fatal: relocation error: file /opt/csw/openoffice.org/program/../basis-link/program/ucpgvfs1.uno.so: symbol gnome_vfs_initialized: referenced symbol not found Killed This problem is not limited to CSWorbit2 but potentially affects any linkage to versioned symbols present on the build machines but not on the client's OS. ** Explanation ** libresolv.so.2 has versioned symbols and libORBit-2.so.0 requires version SUNW_2.2.2 which is not present in Solaris 10U4. U6 works. I don't have quick access to U5, maybe someone will please check U5. Check the versions, examples run on a new system: $ /usr/ccs/bin/elfdump -v /opt/csw/lib/libORBit-2.so.0.1.0 Version Needed Section: .SUNW_version file version libpthread.so.1 SUNW_1.2 libresolv.so.2 SUNW_2.2.2 SUNWprivate_2.1 libnsl.so.1 SUNW_1.7 SUNWprivate_1.1 libsocket.so.1 SUNW_1.4 libc.so.1 SUNW_0.7 $ /usr/ccs/bin/elfdump -v /lib/libresolv.so.2 Version Definition Section: .SUNW_version index version dependency [1] libresolv.so.2 [ BASE ] [2] SUNW_2.2.2 SUNW_2.2.1 [3] SUNW_2.2.1 SUNW_2.2 [4] SUNW_2.2 SUNW_2.1 [5] SUNW_2.1 [6] SUNWprivate_2.2 SUNWprivate_2.1 [7] SUNWprivate_2.1 ... ** Workaround ** Use old orbit: http://csw.informatik.uni-erlangen.de/oldpkgs/allpkgs/orbit2-2.14.19,REV =2011.06.10-SunOS5.9-sparc-CSW.pkg.gz ** Solutions ** 1. Link with a mapfile and select a universal version. This means users don't take advantage of whatever a new version brings. 2. Link twice, once normally and then with a mapfile and do something clever based on the OS. 3. Build on a low rev machine. Probably not acceptable, eg, cc 12.3 might not run. 4. Clients update Solaris. For this to be acceptable do the following: + Change support statement in the user guide + packages that need specific updates or patches use baulking checkinstall scripts. + (suggestion) pkgutil to check the OS update in addition to checkinstall. checkinstall is the correct place but pkgutil can provides early detections and prevent a failed partial update. James. From bonivart at opencsw.org Mon Apr 30 13:29:04 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 30 Apr 2012 13:29:04 +0200 Subject: [csw-maintainers] Solaris 10 revision suppport? In-Reply-To: <20120430.11211600.3907441236@gyor.oxdrove.co.uk> References: <20120430.11211600.3907441236@gyor.oxdrove.co.uk> Message-ID: On Mon, Apr 30, 2012 at 1:21 PM, James Lee wrote: > + (suggestion) pkgutil to check the OS update in addition to > ? checkinstall. ? checkinstall is the correct place but pkgutil can > ? provides early detections and prevent a failed partial update. I'm all for that but I just want to clear up a thing first. Isn't the update releases just rollups of patches (and being able to boot/install new hardware)? My question for the implementation is: should I not look for specific patch levels instead of the update level? Wouldn't a fully patched U4 system be just fine? /peter From jh at opencsw.org Mon Apr 30 13:34:39 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Mon, 30 Apr 2012 13:34:39 +0200 Subject: [csw-maintainers] Solaris 10 revision suppport? In-Reply-To: <20120430.11211600.3907441236@gyor.oxdrove.co.uk> References: <20120430.11211600.3907441236@gyor.oxdrove.co.uk> Message-ID: <4F9E78CF.1080407@opencsw.org> Hi Am 30.04.12 13:21, schrieb James Lee: > What is the CSW support for the revisions of Solaris 10? > > This page: > http://www.opencsw.org/manual/for-administrators/introduction.html > > says "Solaris 10 is fully supported." which isn't true as CSWorbit2 > 2.14.19,REV=2011.12.08 doesn't work with Solaris 10U4. Either we > consider this a bug and fix it or CSW is only supported on certain > revisions of Solaris 10, either way I'm happy but if taking the latter it > would help to explain this better, that is at a minimum change the above > web page. yes this needs a fix. I have it still on my agenda to write something :) Didn't have the time yet. > > ** A Failure ** > > $ soffice > ld.so.1: soffice.bin: fatal: libresolv.so.2: version `SUNW_2.2.2' not > found (required by file /opt/csw/lib/sparcv8/libORBit-2.so.0) > ld.so.1: soffice.bin: fatal: libresolv.so.2: open failed: No such file or > directory > ld.so.1: soffice.bin: fatal: relocation error: file > /opt/csw/openoffice.org/program/../basis-link/program/ucpgvfs1.uno.so: > symbol gnome_vfs_initialized: referenced symbol not found > Killed > > > This problem is not limited to CSWorbit2 but potentially affects any > linkage to versioned symbols present on the build machines but not on the > client's OS. > > > > > ** Explanation ** > > libresolv.so.2 has versioned symbols and libORBit-2.so.0 requires > version SUNW_2.2.2 which is not present in Solaris 10U4. U6 works. I > don't have quick access to U5, maybe someone will please check U5. To see when which version was introduced: https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/libresolv2/common/mapfile-vers src.opensolaris is down atm. > ** Solutions ** > > 1. Link with a mapfile and select a universal version. This means users > don't take advantage of whatever a new version brings. Do you need a map file? We have the same problem with samba atm. But with libc version. If you don't use the functions which are provided by the version. In this case libresolve pvs -ds -N SUNW_2.2.2 /usr/lib/libresolv.so.2 |more SUNW_2.2.2: inet_aton; SUNW_2.2.1: res_ndestroy; would the linker link to older version? I have not found any docs on that. If it does the best way would be if it's auto* test (as in the samba case) to hack it to fail the test for it. > > > 3. Build on a low rev machine. Probably not acceptable, eg, cc 12.3 > might not run. Yes this will not work. As we are on update 9 on the buildfarm. > > > 4. Clients update Solaris. For this to be acceptable do the following: > + Change support statement in the user guide This will happen. > + packages that need specific updates or patches use baulking > checkinstall scripts. We can't distribute the patches. > + (suggestion) pkgutil to check the OS update in addition to > checkinstall. checkinstall is the correct place but pkgutil can > provides early detections and prevent a failed partial update. probably a good idea. Greetings Jan From jh at opencsw.org Mon Apr 30 13:37:08 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Mon, 30 Apr 2012 13:37:08 +0200 Subject: [csw-maintainers] Solaris 10 revision suppport? In-Reply-To: References: <20120430.11211600.3907441236@gyor.oxdrove.co.uk> Message-ID: <4F9E7964.1090906@opencsw.org> Am 30.04.12 13:29, schrieb Peter Bonivart: > My question for the implementation is: should I not look for specific > patch levels instead of the update level? Wouldn't a fully patched U4 > system be just fine? Yes patched version is fine to. So you need to check for kernel Version. Which is crazy compare stuff :) The patch table is: https://blogs.oracle.com/patch/entry/solaris_10_kernel_patchid_progression Greetings Jan From maciej at opencsw.org Mon Apr 30 15:04:02 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 30 Apr 2012 14:04:02 +0100 Subject: [csw-maintainers] [checkpkg] Shared library related bugfix pushed Message-ID: I have pushed a bugfix today, which removes a problem with shared library checking. The bug was causing checkpkg to classify binaries as non-binaries, which in turn broke shared library checking functions, including package split suggestions. It is fixed now in the repository, please update your subversion clients. To get the fixed code, run: mgar up-buildsys The fixed code will correctly index new packages, but since the bug was in the indexing part, there is a number of packages that have inaccurate metadata in the database. Sorry for the inconvenience! Maciej [1] http://wiki.opencsw.org/gar-wrapper