From maciej at opencsw.org Wed Jun 1 16:50:01 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 1 Jun 2011 15:50:01 +0100 Subject: [csw-maintainers] Further improvements to our website In-Reply-To: <4DE3F9E8.7020303@wbonnet.net> References: <4DE3F9E8.7020303@wbonnet.net> Message-ID: 2011/5/30 William Bonnet : > I'll be happy to have help for the web site. The website is easy to hack. It > is a standard wordpress site. The theme is under svn. If someone wants to > give a try on the website, i can help you to setup a local copy of the > website. The missing data you'll need are a database dump. I will try to set it up on my virtual Solaris host to see how hard or easy it is. If I have any questions, I'll update this thread. Maciej From bonivart at opencsw.org Wed Jun 1 19:12:05 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 1 Jun 2011 19:12:05 +0200 Subject: [csw-maintainers] User request from our old friends: zabbix Message-ID: As you know our old friends are not very responsive these days and this request just came in, unanswered of course: "Zabbix is an enterprise-class open source distributed monitoring solution. http://www.zabbix.com/" Someone interested in an alternative to Nagios/Cacti may want to build it. /peter From ja at opencsw.org Thu Jun 2 10:20:10 2011 From: ja at opencsw.org (Juergen Arndt) Date: Thu, 2 Jun 2011 10:20:10 +0200 Subject: [csw-maintainers] User request from our old friends: zabbix In-Reply-To: References: Message-ID: On 01.06.2011, at 19:12, Peter Bonivart wrote: > As you know our old friends are not very responsive these days and > this request just came in, unanswered of course: > > "Zabbix is an enterprise-class open source distributed monitoring solution. > > http://www.zabbix.com/" > > Someone interested in an alternative to Nagios/Cacti may want to build it. I give it a try, but compiling zabbix on solaris seems to be not very straight forward (at least for me), so I'll need some time. Regards, Juergen -- Juergen Arndt From bonivart at opencsw.org Thu Jun 2 10:41:18 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 2 Jun 2011 10:41:18 +0200 Subject: [csw-maintainers] User request from our old friends: zabbix In-Reply-To: References: Message-ID: On Thu, Jun 2, 2011 at 10:20 AM, Juergen Arndt wrote: > I give it a try, but compiling zabbix on solaris seems to be not very straight forward (at least for me), so I'll need some time. Cool! Maybe others can chip in if you have some specific problem. /peter From maciej at opencsw.org Thu Jun 2 12:22:05 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 2 Jun 2011 11:22:05 +0100 Subject: [csw-maintainers] Uncommitted packages in experimental In-Reply-To: References: Message-ID: Hello fellow maintainers, Currently, packages tagged uncommitted are not included in the experimental catalogs. I find that I often want to try installing packages before I commit code to the repository. To do that, I write shell scripts to push packages out, then run gunzip and pkgadd. It would be easier if my uncommitted packages were available for installation from experimental. Do others think it's a good idea to allow uncommitted packages in experimental? Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert at opencsw.org Thu Jun 2 16:55:05 2011 From: rupert at opencsw.org (rupert THURNER) Date: Thu, 2 Jun 2011 16:55:05 +0200 Subject: [csw-maintainers] --catalog-release does not exist ? In-Reply-To: References: Message-ID: what does the error message "--catalog-release does not exist" mean? and i am wondering why this error message cannot be presented in 2 lines insead of 40 :) $ csw-upload-pkg pkgs/02.Jun.2011/* Processing 2 file(s). Please wait. Uploading 'pkgs/02.Jun.2011/mercurial-1.8.4,REV=2011.06.02-SunOS5.9-i386-CSW.pkg.gz' Uploading 'pkgs/02.Jun.2011/mercurial-1.8.4,REV=2011.06.02-SunOS5.9-sparc-CSW.pkg.gz' Checking 1 package(s) against catalog unstable sparc SunOS5.9 ERROR: --catalog-release does not exist Checking 1 package(s) against catalog unstable i386 SunOS5.9 ERROR: --catalog-release does not exist Checking 1 package(s) against catalog unstable sparc SunOS5.10 ERROR: --catalog-release does not exist Checking 1 package(s) against catalog unstable i386 SunOS5.10 ERROR: --catalog-release does not exist Checks failed for catalogs: - sparc SunOS5.9 mercurial-1.8.4,REV=2011.06.02-SunOS5.9-sparc-CSW.pkg.gz To see errors, run: /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.9 --architecture sparc 5c73fa54a7b1e7fc0c3972748464c826 - i386 SunOS5.9 mercurial-1.8.4,REV=2011.06.02-SunOS5.9-i386-CSW.pkg.gz To see errors, run: /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.9 --architecture i386 b2bb56a6f126713461695972ec8b9a3a - sparc SunOS5.10 mercurial-1.8.4,REV=2011.06.02-SunOS5.9-sparc-CSW.pkg.gz To see errors, run: /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.10 --architecture sparc 5c73fa54a7b1e7fc0c3972748464c826 - i386 SunOS5.10 mercurial-1.8.4,REV=2011.06.02-SunOS5.9-i386-CSW.pkg.gz To see errors, run: 6 b2bb56a6f126713461695972ec8b9a3a Packages have not been submitted to the unstable catalog. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Thu Jun 2 17:02:51 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 02 Jun 2011 11:02:51 -0400 Subject: [csw-maintainers] --catalog-release does not exist ? In-Reply-To: References: Message-ID: <1307026928-sup-7585@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Thu Jun 02 10:55:05 -0400 2011: Hi Rupert, > what does the error message "--catalog-release does not exist" mean? > and i am wondering why this error message cannot be presented in 2 > lines insead of 40 :) As for why it breaks, I need to push an update to cswutils. That'll be pushed later today, I hope. The error message length I'll leave to Maciej. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Jun 2 17:06:53 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 02 Jun 2011 11:06:53 -0400 Subject: [csw-maintainers] [csw-buildfarm] Please install CSWlibnspr4 In-Reply-To: <7CDB44A5-E199-4D08-994A-D71EE08E3F44@opencsw.org> References: <7CDB44A5-E199-4D08-994A-D71EE08E3F44@opencsw.org> Message-ID: <1307027144-sup-4030@pinkfloyd.chass.utoronto.ca> Excerpts from Juergen Arndt's message of Thu Jun 02 04:22:16 -0400 2011: [+maintainers] Hi Juergen, > could you please install the package CSWlibnspr4. It is needed for > compiling zabbix. Solving needed dependencies ... Package CSWlibnspr4 not in catalog. Exiting. Not sure what's up. The package is listed at opencsw.org/packages/... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Thu Jun 2 17:22:49 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 2 Jun 2011 16:22:49 +0100 Subject: [csw-maintainers] [csw-buildfarm] Please install CSWlibnspr4 In-Reply-To: <1307027144-sup-4030@pinkfloyd.chass.utoronto.ca> References: <7CDB44A5-E199-4D08-994A-D71EE08E3F44@opencsw.org> <1307027144-sup-4030@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/6/2 Ben Walton : > [+maintainers] > > Hi Juergen, > >> could you please install the package CSWlibnspr4. It is needed for >> compiling zabbix. > > Solving needed dependencies ... > Package CSWlibnspr4 not in catalog. Exiting. > > Not sure what's up. ?The package is listed at opencsw.org/packages/... There is an older version of the nspr package in the catalog. The updated version has not been released because of a file conflict with CSWmozilla (although the current package conflicts with it as well, as far as I remember). Maciej From maciej at opencsw.org Thu Jun 2 18:10:08 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 2 Jun 2011 17:10:08 +0100 Subject: [csw-maintainers] --catalog-release does not exist ? In-Reply-To: References: Message-ID: 2011/6/2 rupert THURNER : > what does the error message "--catalog-release does not exist" mean? In this case the failure occurs, because /usr/bin/checkpkg is currently the legacy checkpkg, and has different command line options; it thinks that --catalog-release is a package to examine. If you use csw-upload-pkg from gar sources, the upload will work. csw-upload-pkg from gar sources uses checkpkg from the same location. Ben will deploy a fix soon. 2011/6/2 rupert THURNER : > and i am wondering why this error message cannot be presented in 2 lines > insead of 40 :) You wouldn't be yourself if you didn't, Rupert! ;-) I don't have a good idea how to shorten the output without losing information. csw-upload-pkg runs checkpkg for each catalog, and I didn't want to make it stop after the first failure. It's useful to know whether a set of packages fails for all catalogs or just one. If it was a web interface, it would be easier, because a summary could be displayed, with a "show more" button. Here, you run the tool, and either it prints something to the screen, or it doesn't. As always, I'm accepting volunteer efforts to improve checkpkg. The sources are publicly available, and the bit of code that drives this part of interaction is in the _RunCheckpkg function[1] in csw_upload_pkg.py. Feel free to hack at it and send me a patch! Maciej [1] http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/python/csw_upload_pkg.py#L487 From bwalton at opencsw.org Thu Jun 2 20:00:08 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 02 Jun 2011 14:00:08 -0400 Subject: [csw-maintainers] Uncommitted packages in experimental In-Reply-To: References: Message-ID: <1307037572-sup-4349@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej Blizi?ski's message of Thu Jun 02 06:22:05 -0400 2011: > Do others think it's a good idea to allow uncommitted packages in > experimental? I don't see the harm in it, but I've personally gotten used to just committing often and early with svn. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert at opencsw.org Thu Jun 2 22:06:48 2011 From: rupert at opencsw.org (rupert THURNER) Date: Thu, 2 Jun 2011 22:06:48 +0200 Subject: [csw-maintainers] Fwd: complicated build, subversion client In-Reply-To: <1306800816-sup-4668@pinkfloyd.chass.utoronto.ca> References: <20110529181632.GA9828@ted.stsp.name> <20110529223727.GB9828@ted.stsp.name> <1306800816-sup-4668@pinkfloyd.chass.utoronto.ca> Message-ID: On Tue, May 31, 2011 at 02:25, Ben Walton wrote: > Excerpts from rupert THURNER's message of Mon May 30 16:08:35 -0400 2011: > > Hi Rupert, > > > You could separate out svnserve and other repository administration > > *binaries* (svnadmin, svnlook, svndumpfilter) into a separate > > package. > > This sounds like a good idea. I've seen a few bug requests for it. stefan had the the convincing argument that we won't save any space on this as we need to deliver all the dependencies anyway as file:// needs to be supported see "libraries" below. my personal favourite as svn client currently is git. no svn necessary at all. just three commands are necessary: git svn clone https://whatever git svn rebase # update git svn dcommit # commit > With the svn libraries it's a different story. You will want all of > > them on both the client and server. This means you'll need most (and > > probably all) dependencies on both sides. > > This would be a good subversion-common package. Both the server and > client packages could then depend on it. > > > I suppose the LDAP dependecy comes from berkeley DB? Subversion has > > no direct dependency on LDAP. > > Does checkpkg tell you it's a surplus dep? If so, you could just drop > it. It may be pulled in via something else and not actually be > required. I haven't looked at it though. > > > You could also take a look at how the Debian packages for Subversion > > split things up. They probably have things split up as much as > > reasonably possible. > > It looks like a fairly monolithic setup there. > > > The files that don't compile with SUN's cc are generated by SWIG. > > Can you figure out if it's possible to make SWIG generate code that > > compiles with gcc as well as Sun's cc? If so we might be able to fix > > your problem by changing the way we generate these files. > > Might John's updated swig packages alleviate this? > > > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/subversion/trunk/files/0001-make-subversion-sysconfigdir-as-it-should-be-for-csw.patch > > > > That patch looks fine. If there is a pre-processor macro that > > identifies a CWS build we could also include this change upstream > > wrapped in the right #ifdef. > > Aside from the fact that this should be handled by autoconf (or > whatever build system they're using) instead of the way they're doing > it, I agree that the current patch shouldn't be too onerous to > support. If they use autoconf and you'd like a hand building a patch > for that to make this sane, let me know. > > > > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/subversion/trunk/files/fixme.sh > > > > This I don't really understand. > > This may be replaceable by the 'STRIP_LIBTOOL = 1' capability that > Mike introduced to GAR, but I'm not sure. STRIP_LIBTOOL is there as well. > > > Note that as of Subversion 1.7 the build system will always use the > > libtool program that was used to compile APR. This was done so we > > could remove the configure script code for finding the right libtool > > and let APR sort this out for us instead. > > This should be a good change overall, I think. That will likely mean > that it uses /opt/csw/bin/libtool (or whatever). It may be possible > that the version of libtool changes between subversion releases though > since it won't be in lockstep with apr. > > > I suppose the above is something with the fixme.sh gone wrong? > > I've never seen an error like this. > > I'd suspect the same thing. > > Hopefully some of my feedback is useful too. many thanks, much appreciated :) i tried removing fixme.sh, but it still goes wrong. let me copy the part out of libtool where it fails: if test -n "$relink_command"; then # Determine the prefix the user has applied to our future dir. inst_prefix_dir=`$echo "$destdir" | $SED "s%$libdir\$%%"` # Don't allow the user to place us outside of our expected # location b/c this prevents finding dependent libraries that # are installed to the same prefix. # At present, this check doesn't affect windows .dll's that # are installed into $libdir/../bin (currently, that works fine) # but it's something to keep an eye on. if test "$inst_prefix_dir" = "$destdir"; then $echo "$modename: error: cannot install \`$file' to a directory not ending in $libdir" 1>&2 exit $EXIT_FAILURE fi if test -n "$inst_prefix_dir"; then # Stick the inst_prefix_dir data into the link command. relink_command=`$echo "$relink_command" | $SP2NL | $SED "s%@inst_prefix_dir@%-inst-prefix-dir $inst_prefix_dir%" | $NL2SP` else relink_command=`$echo "$relink_command" | $SP2NL | $SED "s%@inst_prefix_dir@%%" | $NL2SP` fi kr, rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Thu Jun 2 22:10:31 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 2 Jun 2011 22:10:31 +0200 Subject: [csw-maintainers] stub naming In-Reply-To: References: <201105041748.p44HmMF9026139@login.bo.opencsw.org> <1304650265-sup-8640@pinkfloyd.chass.utoronto.ca> <1305474909-sup-7699@pinkfloyd.chass.utoronto.ca> <1305509630-sup-9069@pinkfloyd.chass.utoronto.ca> <1307043617-sup-9241@pinkfloyd.chass.utoronto.ca> Message-ID: <17A2F4C7-0AB7-4634-B062-74D79C3FD9C6@opencsw.org> Hi Phil, (moving to maintainers@) Am 02.06.2011 um 21:55 schrieb Philip Brown: > On Thu, Jun 2, 2011 at 12:41 PM, Ben Walton wrote: >> Excerpts from Philip Brown's message of Tue May 17 12:47:05 -0400 2011: >> >>> FYI, to tie loose ends together in this archive; since you declined >>> to start a vote off, I have started a discussion about stub naming >>> on the maintainer list . >> >> Nobody seems to have an opinion on this in your spun out >> thread...batching? > > Well, on the one hand, there has been no general discussion, which is > unfortunate. However, nor is there a "majority of maintainers" (or > even anything close to it) who have spoken up on this issue. Please > set up a vote on it. > > I would suggest a format similar to > http://wiki.opencsw.org/vote-release-process, and that the ballot > reference the wiki page, giving as voting choices only, > > "option A, on http....." > "option B, on http..." > > that way, people have to at least go to the page, to know what they > are voting for. I don't see a need for this. If there are no strong opinions and almost same amounts on both sides it would be a waste of resources. The argument that _stub should be appended to the *existing* catalog name is IMHO good as it groups the package file together with the old (pre-stub) package. I changed my opinion as this argument convinced me. Aside from that I don't think there is a notable difference how stubs are named. So I suggest just going with that until someone has a strong other opinion, ok? Best regards -- Dago From dam at opencsw.org Thu Jun 2 22:17:42 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 2 Jun 2011 22:17:42 +0200 Subject: [csw-maintainers] Fwd: complicated build, subversion client In-Reply-To: References: <20110529181632.GA9828@ted.stsp.name> <20110529223727.GB9828@ted.stsp.name> <1306800816-sup-4668@pinkfloyd.chass.utoronto.ca> Message-ID: <732A717A-4B6E-4432-B544-D0046C111556@opencsw.org> Hi Rupert, Am 02.06.2011 um 22:06 schrieb rupert THURNER: > many thanks, much appreciated :) i tried removing fixme.sh, but it still goes wrong. let me copy the part out of libtool where it fails: Could you please commit what you have so I 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 rupert at opencsw.org Thu Jun 2 23:31:52 2011 From: rupert at opencsw.org (rupert THURNER) Date: Thu, 2 Jun 2011 23:31:52 +0200 Subject: [csw-maintainers] Uncommitted packages in experimental In-Reply-To: References: Message-ID: 2011/6/2 Maciej Blizi?ski > Hello fellow maintainers, > > Currently, packages tagged uncommitted are not included in the experimental > catalogs. I find that I often want to try installing packages before I > commit code to the repository. To do that, I write shell scripts to push > packages out, then run gunzip and pkgadd. It would be easier if my > uncommitted packages were available for installation from experimental. > > Do others think it's a good idea to allow uncommitted packages in > experimental? > imo it would be better to keep it transparent for others - i.e. if the package is public, the source which was used to get it is as well public. rupert -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Thu Jun 2 23:38:39 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 2 Jun 2011 23:38:39 +0200 Subject: [csw-maintainers] Uncommitted packages in experimental In-Reply-To: References: Message-ID: <5750C825-844F-4B3B-A722-8BC36AAB94E5@opencsw.org> Hi, Am 02.06.2011 um 23:31 schrieb rupert THURNER: > 2011/6/2 Maciej Blizi?ski > Hello fellow maintainers, > > Currently, packages tagged uncommitted are not included in the experimental catalogs. I find that I often want to try installing packages before I commit code to the repository. To do that, I write shell scripts to push packages out, then run gunzip and pkgadd. It would be easier if my uncommitted packages were available for installation from experimental. > > Do others think it's a good idea to allow uncommitted packages in experimental? > > imo it would be better to keep it transparent for others - i.e. if the package is public, the source which was used to get it is as well public. +1 for me. What's wrong with an early commit? It helps making the work available to others. 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 ellson at opencsw.org Thu Jun 2 23:42:14 2011 From: ellson at opencsw.org (John Ellson) Date: Thu, 02 Jun 2011 17:42:14 -0400 Subject: [csw-maintainers] graphviz: pushed to unstable - problem analysis, solution, and next issue Message-ID: <4DE803B6.2000102@opencsw.org> The latest graphviz-2.28.0 build looks much better. It has been pushed to unstable and I've given it a quick test on my nice new solaris-10 virtual host. The work-around for the libtool problem (see below) was to build on machines *without* the older CSWgraphvizdevel installed. Next problem: - Can someone advise me how to deal with the ImageMagic issue of depending on the older graphviz libraries? Maciej made changes (thank you) so that this won't be a problem next time, but this time its still a problem. I think Maciej suggested shipping the old libs along with the new packages? Is it kosher to just copy the old binary images in to the new packages? How would I actually do that? John Problem analysis. During "make install", libtool relinks libraries against the final installation location. But the dependent libraries from the graphviz packages haven't been installed yet, so libtool picks up the old libraries incorrectly (but only if the -devel package is installed). In fact the libtool manual states: "Currently it is not generally possible to install into a temporary staging area that contains needed third-party libraries which are not yet visible at their final location." and yet, the earlier release built ok, so my working theory (now verified) is that it won't add incorrect libraries during the relink if they don't exist at all. John From maciej at opencsw.org Thu Jun 2 23:57:16 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 2 Jun 2011 22:57:16 +0100 Subject: [csw-maintainers] Uncommitted packages in experimental In-Reply-To: <5750C825-844F-4B3B-A722-8BC36AAB94E5@opencsw.org> References: <5750C825-844F-4B3B-A722-8BC36AAB94E5@opencsw.org> Message-ID: 2011/6/2 Dagobert Michelsen : > Hi, > Am 02.06.2011 um 23:31 schrieb rupert THURNER: > > 2011/6/2 Maciej Blizi?ski >> >> Hello fellow maintainers, >> >> Currently, packages tagged uncommitted are not included in the >> experimental catalogs. I find that I often want to try installing packages >> before I commit code to the repository. To do that, I write shell scripts to >> push packages out, then run gunzip and pkgadd. It would be easier if my >> uncommitted packages were available for installation from experimental. >> >> Do others think it's a good idea to allow uncommitted packages in >> experimental? > > imo it would be better to keep it transparent for others - i.e. if the > package is public, the source which was used to get it is as well public. > > +1 for me. What's wrong with an early commit? It helps making the work > available > to others. Looking back at my work with MySQL and PostgreSQL, it would be a long, long chain of annoying, meaningless commits. In git speak, it would be work in a local branch, experimenting that I would not like to push out before I arrive at a reasonable state and clean it up. The question I was asking is - given that I do build uncommitted packages for experimentation purposes (like, really, it's going to explode if you touch it) - can we make it easier to get these experimental packages out of the buildfarm? If the experimental catalogs can't be used for this purpose, I will continue using shell scripts wrapping scp, pkgrm, gunzip and pkgadd. Maciej From dam at opencsw.org Thu Jun 2 23:58:45 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 2 Jun 2011 23:58:45 +0200 Subject: [csw-maintainers] graphviz: pushed to unstable - problem analysis, solution, and next issue In-Reply-To: <4DE803B6.2000102@opencsw.org> References: <4DE803B6.2000102@opencsw.org> Message-ID: <7451E333-554B-4CE0-984D-156FE76A8E10@opencsw.org> Hi John, Am 02.06.2011 um 23:42 schrieb John Ellson: > Next problem: > > - Can someone advise me how to deal with the ImageMagic issue of > depending on the older graphviz libraries? > Maciej made changes (thank you) so that this won't be a problem next > time, but this time its still a problem. > > I think Maciej suggested shipping the old libs along with the new > packages? Is it kosher to just copy the old binary images > in to the new packages? How would I actually do that? The "classical" approach is to use a version modulation and build all necessary versions in one build and then merge them. As this can be tricky the "modern" approach is to just use different recipes to build the libraries. See for example libflac4, libflac7 and libflac8 which build the necessary libraries. Also libtool/branches/libldtl3 libttol/branches/libtool24 could be used to study the technology (please don't use the path layout from libtool, though. The correct one is the one used for libflac*). Best regards -- Dago From ellson at opencsw.org Fri Jun 3 00:05:31 2011 From: ellson at opencsw.org (John Ellson) Date: Thu, 02 Jun 2011 18:05:31 -0400 Subject: [csw-maintainers] graphviz: pushed to unstable - problem analysis, solution, and next issue In-Reply-To: <7451E333-554B-4CE0-984D-156FE76A8E10@opencsw.org> References: <4DE803B6.2000102@opencsw.org> <7451E333-554B-4CE0-984D-156FE76A8E10@opencsw.org> Message-ID: <4DE8092B.4030102@opencsw.org> Dago, This really sounds like a lot of work for a one-time problem. Is there an alternative? Could graphviz-2.28.0 be installed on the current build hosts and then ImageMagic rebuilt for a simultaneous release? John On 06/02/2011 05:58 PM, Dagobert Michelsen wrote: > Hi John, > > Am 02.06.2011 um 23:42 schrieb John Ellson: >> Next problem: >> >> - Can someone advise me how to deal with the ImageMagic issue of >> depending on the older graphviz libraries? >> Maciej made changes (thank you) so that this won't be a problem next >> time, but this time its still a problem. >> >> I think Maciej suggested shipping the old libs along with the new >> packages? Is it kosher to just copy the old binary images >> in to the new packages? How would I actually do that? > The "classical" approach is to use a version modulation and build all > necessary versions in one build and then merge them. As this can be tricky > the "modern" approach is to just use different recipes to build the libraries. > See for example libflac4, libflac7 and libflac8 which build the necessary > libraries. Also > libtool/branches/libldtl3 > libttol/branches/libtool24 > could be used to study the technology (please don't use the path layout > from libtool, though. The correct one is the one used for libflac*). > > > Best regards > > -- Dago > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From phil at bolthole.com Fri Jun 3 00:08:27 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 2 Jun 2011 15:08:27 -0700 Subject: [csw-maintainers] graphviz: pushed to unstable - problem analysis, solution, and next issue In-Reply-To: <4DE8092B.4030102@opencsw.org> References: <4DE803B6.2000102@opencsw.org> <7451E333-554B-4CE0-984D-156FE76A8E10@opencsw.org> <4DE8092B.4030102@opencsw.org> Message-ID: On Thu, Jun 2, 2011 at 3:05 PM, John Ellson wrote: > Dago, > > This really sounds like a lot of work for a one-time problem. > > Is there an alternative? ? ?Could graphviz-2.28.0 be installed on the > current build hosts and then ImageMagic rebuilt for a simultaneous release? > that is certainly an even better solution, if there is nothing else depending on the older libraries. From maciej at opencsw.org Fri Jun 3 16:38:23 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Fri, 3 Jun 2011 15:38:23 +0100 Subject: [csw-maintainers] Further improvements to our website In-Reply-To: References: <4DE3F9E8.7020303@wbonnet.net> Message-ID: 2011/6/1 Maciej Blizi?ski : > 2011/5/30 William Bonnet : >> I'll be happy to have help for the web site. The website is easy to hack. It >> is a standard wordpress site. The theme is under svn. If someone wants to >> give a try on the website, i can help you to setup a local copy of the >> website. The missing data you'll need are a database dump. > > I will try to set it up on my virtual Solaris host to see how hard or > easy it is. ?If I have any questions, I'll update this thread. No luck so far. I've installed our apache, php and mysql. I can run phpinfo() - it works. What doesn't work, is installing mantis. When enter the top level link, I'm redirected to admin/install.php, and all I see is a blank page. When running via curl, it just returns: maciej at quince:~$ curl 'http://buildfarm.home.blizinski.pl/mantisbt-1.2.5/admin/install.php' maciej at quince:~$ I configured PHP to log to /var/tmp/php.log, but the file does not exist (and is not created). From my php.ini: error_reporting = E_ALL display_errors = On log_errors = On log_errors_max_len = 1024 error_log = "/var/tmp/php.log" There's nothing in Apache's error_log. I'm a bit out of ideas. Where else can I look? Maciej From dam at opencsw.org Fri Jun 3 18:04:45 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 3 Jun 2011 18:04:45 +0200 Subject: [csw-maintainers] Rebuild of imagemagick In-Reply-To: <4DE810E0.4050502@opencsw.org> References: <4DE810E0.4050502@opencsw.org> Message-ID: <7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org> Hi John, Am 03.06.2011 um 00:38 schrieb John Ellson: > OK, I'm going to try rebuilding ImageMagick against graphviz-2.28.0 for a simultaneous release. > > On the current* build hosts, could you please: > > Uninstall graphviz*-2.26.3 and ImageMagick > > Install graphviz-2.28.0 and graphvizdevel-2.28.0 from the unstable catalog. Umh, the usual procedure is to just update unstable and build graphviz there. I am doing this now, ok? BTW, Roger had quite some effort in a 64 bit Imagemagick: http://wiki.opencsw.org/project-imagemagick64 Maybe we can continue this project and finish up in a joint effort? Roger: Haven't heard from you in a while, everything ok? :-) Best regards -- Dago > > Thanks. > > John > > -------- Original Message -------- > Subject: Re: [csw-maintainers] graphviz: pushed to unstable - problem analysis, solution, and next issue > Date: Thu, 2 Jun 2011 15:08:27 -0700 > From: Philip Brown > Reply-To: List for OpenCSW maintainers > To: List for OpenCSW maintainers > > On Thu, Jun 2, 2011 at 3:05 PM, John Ellson wrote: > > Dago, > > > > This really sounds like a lot of work for a one-time problem. > > > > Is there an alternative? Could graphviz-2.28.0 be installed on the > > current build hosts and then ImageMagic rebuilt for a simultaneous release? > > > > that is certainly an even better solution, if there is nothing else > depending on the older libraries. > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > > _______________________________________________ > buildfarm mailing list > buildfarm at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/buildfarm -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at bolthole.com Fri Jun 3 18:13:22 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 3 Jun 2011 09:13:22 -0700 Subject: [csw-maintainers] [csw-buildfarm] Rebuild of imagemagick In-Reply-To: <7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org> References: <4DE810E0.4050502@opencsw.org> <7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org> Message-ID: > Umh, the usual procedure is to just update unstable and build graphviz there. > I am doing this now, ok? > BTW, Roger had quite some effort in a 64 bit Imagemagick: > ??http://wiki.opencsw.org/project-imagemagick64 > Maybe we can continue this project and finish up in a joint effort? Or, since existing is not 64bit... perhaps just do a 32bit rebuild to fix this problem, and focus on 64bit for later. No need to make the existing workload on this multi-level project larger than it already is. From ellson at opencsw.org Fri Jun 3 18:29:15 2011 From: ellson at opencsw.org (John Ellson) Date: Fri, 03 Jun 2011 12:29:15 -0400 Subject: [csw-maintainers] [csw-buildfarm] Rebuild of imagemagick In-Reply-To: References: <4DE810E0.4050502@opencsw.org> <7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org> Message-ID: <4DE90BDB.9040708@opencsw.org> On 06/03/2011 12:13 PM, Philip Brown wrote: >> Umh, the usual procedure is to just update unstable and build graphviz there. >> I am doing this now, ok? Absolutely. You're expert. I'm still learning. >> BTW, Roger had quite some effort in a 64 bit Imagemagick: >> http://wiki.opencsw.org/project-imagemagick64 >> Maybe we can continue this project and finish up in a joint effort? > Or, since existing is not 64bit... perhaps just do a 32bit rebuild to > fix this problem, and focus on 64bit for later. > No need to make the existing workload on this multi-level project > larger than it already is. Yes, I'm willing to go further with ImageMagick, but I was proposing just the minimal changes need to get it out with graphviz-2.28.0 as a first step. John From bwalton at opencsw.org Fri Jun 3 18:54:44 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 03 Jun 2011 12:54:44 -0400 Subject: [csw-maintainers] time to deprecate CSWmozilla Message-ID: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca> Hi All, As CSWmozilla is currently squatting on some nspr header files and nobody has interest in rebuilding it (we have firefox, etc), I think we should drop it from the catalog. Anything that packages the header files where they belong should declare I with CSWmozilla and people that want both on their systems will need to make a choice between modern packages and a 5 year old mozilla. Thoughts? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Fri Jun 3 18:55:28 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 03 Jun 2011 12:55:28 -0400 Subject: [csw-maintainers] Fwd: Re: [csw-pkgsubmissions] newpkgs git, git_completion, git_cvs, git_dev(...) Message-ID: <1307120105-sup-1298@pinkfloyd.chass.utoronto.ca> Oops. Mistyped the list address in my mailer. Thanks -Ben --- Begin forwarded message from Ben Walton --- From: Ben Walton To: pkgsubmissions Cc: maintainers Date: Fri, 03 Jun 2011 12:52:16 -0400 Subject: Re: [csw-pkgsubmissions] newpkgs git, git_completion, git_cvs, git_dev(...) Excerpts from Philip Brown's message of Fri Jun 03 11:46:30 -0400 2011: > A slight adjustment, since Dagobert just posted on the maintainers > list that he changed his position on the issue(and he suggested that > we proceed that way without voting): > Will you now act in the way you seem to think I should act, and change > *your* position? Fine. It's not worth a vote over something so dumb. I think that filename grouping is a bit more useful than searching the catalog, but still not much, imo. Either way, I can see that I'm now the minority position. > Or will you insist on having a vote? No, I value the time of all involved and wouldn't waste it on something like this. > either way, it would be beneficial to see an official notice on how > things will work. > ie: a writeup by "the board", on how official votes are triggered. Sure. Once I've cleared a few other things away I'll sit down and draft something. Thanks -Ben --- End forwarded message --- -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From ellson at opencsw.org Fri Jun 3 19:27:26 2011 From: ellson at opencsw.org (John Ellson) Date: Fri, 03 Jun 2011 13:27:26 -0400 Subject: [csw-maintainers] [csw-buildfarm] Rebuild of imagemagick In-Reply-To: <4DE90BDB.9040708@opencsw.org> References: <4DE810E0.4050502@opencsw.org> <7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org> <4DE90BDB.9040708@opencsw.org> Message-ID: <4DE9197E.4030000@opencsw.org> I took a look at the 64bit Imagemagick wiki page (nice job, btw). AFAICT the current state of the 64bit builds is: imagemagick (Roger) depends on graphviz (John) depends on ghostscript (John) depends on libcups (Dago) depends on krb5_lib (Maciej) Is there any status update on krb5_lib and libcups? Should I be trying a ghostscript 64bit build? John On 06/03/2011 12:29 PM, John Ellson wrote: > On 06/03/2011 12:13 PM, Philip Brown wrote: >>> Umh, the usual procedure is to just update unstable and build >>> graphviz there. >>> I am doing this now, ok? > > Absolutely. You're expert. I'm still learning. > >>> BTW, Roger had quite some effort in a 64 bit Imagemagick: >>> http://wiki.opencsw.org/project-imagemagick64 >>> Maybe we can continue this project and finish up in a joint effort? >> Or, since existing is not 64bit... perhaps just do a 32bit rebuild to >> fix this problem, and focus on 64bit for later. >> No need to make the existing workload on this multi-level project >> larger than it already is. > > Yes, I'm willing to go further with ImageMagick, but I was proposing > just the minimal changes need to get it out with graphviz-2.28.0 as a > first step. > > John > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From phil at bolthole.com Fri Jun 3 19:35:31 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 3 Jun 2011 10:35:31 -0700 Subject: [csw-maintainers] [csw-buildfarm] Rebuild of imagemagick In-Reply-To: <4DE9197E.4030000@opencsw.org> References: <4DE810E0.4050502@opencsw.org> <7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org> <4DE90BDB.9040708@opencsw.org> <4DE9197E.4030000@opencsw.org> Message-ID: On Fri, Jun 3, 2011 at 10:27 AM, John Ellson wrote: > I took a look at the 64bit Imagemagick wiki page (nice job, btw). > > AFAICT the current state of the 64bit builds is: > > ? ?imagemagick (Roger) depends on > ? ? ? ?graphviz (John) depends on > ? ? ? ? ? ?ghostscript (John) depends on > ? ? ? ? ? ? ? ?libcups (Dago) depends on > ? ? ? ? ? ? ? ? ? ?krb5_lib (Maciej) > > > Is there any status update on krb5_lib and libcups? ? ?Should I be trying a > ghostscript 64bit build? A side comment: Sometimes, it is okay to have a 64bit library with "less" features, than no 64bit at all. So, at any point in the chain there, you might make a choice of, "oh well, it would be nice to have [gs/cups/krb support] some day, but for now, I'm just going to unplug the 64bit pipeline." (Although of course, you need to document this very strongly if you choose this path) What makes a good choice of choosing a cutoff point, is when the stuff you are chopping is not used by the top level. The idea situation being, that , when "someday" comes... since imagemagic does not directly use krb5 or cups(?), the library upgrade lower down, will be transparent. From phil at bolthole.com Fri Jun 3 19:43:55 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 3 Jun 2011 10:43:55 -0700 Subject: [csw-maintainers] time to deprecate CSWmozilla In-Reply-To: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca> References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca> Message-ID: On Fri, Jun 3, 2011 at 9:54 AM, Ben Walton wrote: > > Hi All, > > As CSWmozilla is currently squatting on some nspr header files and > nobody has interest in rebuilding it (we have firefox, etc), I think > we should drop it from the catalog. ?Anything that packages the header > files where they belong should declare I with CSWmozilla and people > that want both on their systems will need to make a choice between > modern packages and a 5 year old mozilla. > Actually, I think "seamonkey" was already supposed to "replace" mozilla for most everyone that cared. we most likely only kept it around for header files. There's just a question remaining, about what to do about the 2 packages that depend on it. They are both rather old.. (and orphaned), but unfortunately, both sound somewhat useful. epiphany The web browser for the GNOME Desktop liferea news aggregator for online news feeds From ellson at opencsw.org Fri Jun 3 19:44:36 2011 From: ellson at opencsw.org (John Ellson) Date: Fri, 03 Jun 2011 13:44:36 -0400 Subject: [csw-maintainers] [csw-buildfarm] Rebuild of imagemagick In-Reply-To: References: <4DE810E0.4050502@opencsw.org> <7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org> <4DE90BDB.9040708@opencsw.org> <4DE9197E.4030000@opencsw.org> Message-ID: <4DE91D84.8000908@opencsw.org> On 06/03/2011 01:35 PM, Philip Brown wrote: > On Fri, Jun 3, 2011 at 10:27 AM, John Ellson wrote: >> I took a look at the 64bit Imagemagick wiki page (nice job, btw). >> >> AFAICT the current state of the 64bit builds is: >> >> imagemagick (Roger) depends on >> graphviz (John) depends on >> ghostscript (John) depends on >> libcups (Dago) depends on >> krb5_lib (Maciej) >> >> >> Is there any status update on krb5_lib and libcups? Should I be trying a >> ghostscript 64bit build? > A side comment: > > Sometimes, it is okay to have a 64bit library with "less" features, > than no 64bit at all. > > So, at any point in the chain there, you might make a choice of, "oh > well, it would be nice to have [gs/cups/krb support] some day, but for > now, I'm just going to unplug the 64bit pipeline." > (Although of course, you need to document this very strongly if you > choose this path) > > What makes a good choice of choosing a cutoff point, is when the stuff > you are chopping is not used by the top level. > The idea situation being, that , when "someday" comes... since > imagemagic does not directly use krb5 or cups(?), the library upgrade > lower down, will be transparent. > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > Yes, I was thinking that it would be easy to drop the ghostscript plugin from graphviz. (Its used to import custom node shapes in PostScript - a feature that isn't used much, better to use SVG these days anyway.) It would also be easy to drop the graphviz dependency from ghostscript. But, if the goal is to use ImageMagic to drive the creation of a 64bit distribution, then there is less point in taking shortcuts. John From ellson at opencsw.org Fri Jun 3 19:46:58 2011 From: ellson at opencsw.org (John Ellson) Date: Fri, 03 Jun 2011 13:46:58 -0400 Subject: [csw-maintainers] [csw-buildfarm] Rebuild of imagemagick In-Reply-To: <4DE91D84.8000908@opencsw.org> References: <4DE810E0.4050502@opencsw.org> <7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org> <4DE90BDB.9040708@opencsw.org> <4DE9197E.4030000@opencsw.org> <4DE91D84.8000908@opencsw.org> Message-ID: <4DE91E12.7040005@opencsw.org> On 06/03/2011 01:44 PM, John Ellson wrote: > On 06/03/2011 01:35 PM, Philip Brown wrote: >> On Fri, Jun 3, 2011 at 10:27 AM, John Ellson wrote: >>> I took a look at the 64bit Imagemagick wiki page (nice job, btw). >>> >>> AFAICT the current state of the 64bit builds is: >>> >>> imagemagick (Roger) depends on >>> graphviz (John) depends on >>> ghostscript (John) depends on >>> libcups (Dago) depends on >>> krb5_lib (Maciej) >>> >>> >>> Is there any status update on krb5_lib and libcups? Should I be >>> trying a >>> ghostscript 64bit build? >> A side comment: >> >> Sometimes, it is okay to have a 64bit library with "less" features, >> than no 64bit at all. >> >> So, at any point in the chain there, you might make a choice of, "oh >> well, it would be nice to have [gs/cups/krb support] some day, but for >> now, I'm just going to unplug the 64bit pipeline." >> (Although of course, you need to document this very strongly if you >> choose this path) >> >> What makes a good choice of choosing a cutoff point, is when the stuff >> you are chopping is not used by the top level. >> The idea situation being, that , when "someday" comes... since >> imagemagic does not directly use krb5 or cups(?), the library upgrade >> lower down, will be transparent. >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers >> .:: This mailing list's archive is public. ::. >> > > Yes, I was thinking that it would be easy to drop the ghostscript > plugin from graphviz. > (Its used to import custom node shapes in PostScript - a feature that > isn't used much, better to use SVG these days anyway.) > > It would also be easy to drop the graphviz dependency from ghostscript. Sorry. I meant to say: "... from ImageMagick" > > But, if the goal is to use ImageMagic to drive the creation of a 64bit > distribution, then there is less point in taking shortcuts. > > > John > _______________________________________________ > 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 Fri Jun 3 19:57:34 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 03 Jun 2011 13:57:34 -0400 Subject: [csw-maintainers] time to deprecate CSWmozilla In-Reply-To: References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca> Message-ID: <1307123778-sup-3520@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Jun 03 13:43:55 -0400 2011: > Actually, I think "seamonkey" was already supposed to "replace" > mozilla for most everyone that cared. we most likely only kept it > around for header files. I think that's likely right. > There's just a question remaining, about what to do about the 2 > packages that depend on it. > They are both rather old.. (and orphaned), but unfortunately, both > sound somewhat useful. > > epiphany The web browser for the GNOME Desktop > liferea news aggregator for online news feeds Both of these will be vulnerable to all the same exploits as the ancient mozilla since they use its rendering engine. Let's remove them too...unless somebody wants to modernize them? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Fri Jun 3 20:15:24 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 3 Jun 2011 11:15:24 -0700 Subject: [csw-maintainers] time to deprecate CSWmozilla In-Reply-To: <1307123778-sup-3520@pinkfloyd.chass.utoronto.ca> References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca> <1307123778-sup-3520@pinkfloyd.chass.utoronto.ca> Message-ID: On Fri, Jun 3, 2011 at 10:57 AM, Ben Walton wrote: > >> epiphany ? ?The web browser for the GNOME Desktop >> liferea ? ?news aggregator for online news feeds > > Both of these will be vulnerable to all the same exploits as the > ancient mozilla since they use its rendering engine. ?Let's remove > them too...unless somebody wants to modernize them? > I would guess they could be recompiled against seamonkey. a quick googling for seamonkey indicates that people have been compiling it against seamonkey for some time. From phil at bolthole.com Fri Jun 3 20:15:53 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 3 Jun 2011 11:15:53 -0700 Subject: [csw-maintainers] time to deprecate CSWmozilla In-Reply-To: References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca> <1307123778-sup-3520@pinkfloyd.chass.utoronto.ca> Message-ID: On Fri, Jun 3, 2011 at 11:15 AM, Philip Brown wrote: > On Fri, Jun 3, 2011 at 10:57 AM, Ben Walton wrote: >> >>> epiphany ? ?The web browser for the GNOME Desktop >>> liferea ? ?news aggregator for online news feeds >> >> Both of these will be vulnerable to all the same exploits as the >> ancient mozilla since they use its rendering engine. ?Let's remove >> them too...unless somebody wants to modernize them? >> > > I would guess they could be recompiled against seamonkey. > > a quick googling for seamonkey indicates that people have been > compiling it against seamonkey for some time. Doh. lifearea + seamonkey From phil at bolthole.com Fri Jun 3 23:53:46 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 3 Jun 2011 14:53:46 -0700 Subject: [csw-maintainers] initialization problem: struct + union Message-ID: Hitting a problem trying to get something to compile with sun cc. problem is auto-definition of a struct that has a union in it. I forget what the hack is, to get sun cc to accept this sort of thing :( A chopped down version, which compiles with gcc, but fails under sun cc: ( complains about the {integer:2} thing at bottom) #include union types { char *string; int integer; }; typedef struct { char *option; int type; union types default_value; } config_opt_t; #define INTEGER 1 config_opt_t config_opts[] = { { "snmp_timeout", INTEGER, {integer:2} }, }; From maciej at opencsw.org Sat Jun 4 09:02:47 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 4 Jun 2011 08:02:47 +0100 Subject: [csw-maintainers] [csw-buildfarm] Rebuild of imagemagick In-Reply-To: <4DE9197E.4030000@opencsw.org> References: <4DE810E0.4050502@opencsw.org> <7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org> <4DE90BDB.9040708@opencsw.org> <4DE9197E.4030000@opencsw.org> Message-ID: 2011/6/3 John Ellson : > I took a look at the 64bit Imagemagick wiki page (nice job, btw). > > AFAICT the current state of the 64bit builds is: > > ? ?imagemagick (Roger) depends on > ? ? ? ?graphviz (John) depends on > ? ? ? ? ? ?ghostscript (John) depends on > ? ? ? ? ? ? ? ?libcups (Dago) depends on > ? ? ? ? ? ? ? ? ? ?krb5_lib (Maciej) Slight correction: krb5_lib is maintained by Dago, and libcups is maintained by me. Maciej From maciej at opencsw.org Sat Jun 4 11:17:20 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 4 Jun 2011 10:17:20 +0100 Subject: [csw-maintainers] time to deprecate CSWmozilla In-Reply-To: References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca> <1307123778-sup-3520@pinkfloyd.chass.utoronto.ca> Message-ID: Em 03/06/2011 19:15, "Philip Brown" escreveu: > > On Fri, Jun 3, 2011 at 10:57 AM, Ben Walton wrote: > > > >> epiphany The web browser for the GNOME Desktop > >> liferea news aggregator for online news feeds > > > > Both of these will be vulnerable to all the same exploits as the > > ancient mozilla since they use its rendering engine. Let's remove > > them too...unless somebody wants to modernize them? > > > > I would guess they could be recompiled against seamonkey. > > a quick googling for seamonkey indicates that people have been > compiling it against seamonkey for some time. What next steps do you suggest? Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at bolthole.com Sat Jun 4 17:18:52 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 4 Jun 2011 08:18:52 -0700 Subject: [csw-maintainers] time to deprecate CSWmozilla In-Reply-To: References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca> <1307123778-sup-3520@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/6/4 Maciej Blizi?ski : > Em 03/06/2011 19:15, "Philip Brown" escreveu: > >> I would guess they could be recompiled against seamonkey. >> >> a quick googling for seamonkey indicates that people have been >> compiling it against seamonkey for some time. > > What next steps do you suggest? > I would suggest that someone who is interested in repackaging them, attempt to compile against seamonkey. and if it fails, pull up the relevant patches, and try it again. debian and ubuntu seem to have patches, according to google From ellson at opencsw.org Sat Jun 4 19:06:19 2011 From: ellson at opencsw.org (John Ellson) Date: Sat, 04 Jun 2011 13:06:19 -0400 Subject: [csw-maintainers] how to set up a local buildhost? Message-ID: <4DEA660B.4080102@opencsw.org> Now that I have Solaris-10 running on a virtual host locally, is there an easy way I can set it up as a buildhost? If I could do that, I could use it to build the graphviz nightly development snapshots. John From ellson at opencsw.org Sat Jun 4 19:35:56 2011 From: ellson at opencsw.org (John Ellson) Date: Sat, 04 Jun 2011 13:35:56 -0400 Subject: [csw-maintainers] pkg-config failure unstable9[xs] Message-ID: <4DEA6CFC.7060500@opencsw.org> The ImageMagick builds on unstable9[sx] are failing with: libtool: compile: /opt/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I./config -I/opt/csw/include/freetype2 -I/opt/csw/include -I/opt /csw/X11/include -I/opt/csw/include -I/opt/csw/X11/include -I/opt/csw/include/libxml2 -I/opt/csw/include/lqr-1 -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -xopenmp -xO3 -m32 -xarch=v8 -D_REENTRANT -c coders/svg.c -KPIC -DPIC -o coders/.libs/coders_svg_la-svg.o "coders/svg.c", line 93: cannot find include file: "librsvg/rsvg.h" "coders/svg.c", line 95: cannot find include file: "librsvg/rsvg-cairo.h" "coders/svg.c", line 97: cannot find include file: "librsvg/librsvg-features.h" Is the librvg on unstable9[xs] out of date? Or possibly pixman? ellson at unstable9s:ellson> pkg-config --cflags librsvg-2.0 sh: gnome-config: not found Package pixman-1 was not found in the pkg-config search path. Perhaps you should add the directory containing `pixman-1.pc' to the PKG_CONFIG_PATH environment variable Package 'pixman-1', required by 'cairo', not found ellson at current9s:ellson> pkg-config --cflags librsvg-2.0 -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS -DXTHREADS -DXUSE_MTSAFE_API -I/opt/csw/include/librsvg-2 -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -I/opt/csw/include/gtk-2.0 -I/opt/csw/include/cairo -I/opt/csw/include/pixman-1 -I/opt/csw/include/freetype2 -I/opt/csw/include -I/opt/csw/include/libpng12 John From maciej at opencsw.org Sat Jun 4 19:51:21 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 4 Jun 2011 18:51:21 +0100 Subject: [csw-maintainers] how to set up a local buildhost? In-Reply-To: <4DEA660B.4080102@opencsw.org> References: <4DEA660B.4080102@opencsw.org> Message-ID: Em 04/06/2011 18:06, "John Ellson" escreveu: > > Now that I have Solaris-10 running on a virtual host locally, is there > an easy way I can set it up as a buildhost? > > If I could do that, I could use it to build the graphviz nightly > development snapshots. It is an excellent idea to set up a build host! I have a partly written howto document. I can send you a copy and help you with any issues you might run into along the way. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at bolthole.com Sat Jun 4 21:42:55 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 4 Jun 2011 12:42:55 -0700 Subject: [csw-maintainers] how to set up a local buildhost? In-Reply-To: <4DEA660B.4080102@opencsw.org> References: <4DEA660B.4080102@opencsw.org> Message-ID: On Sat, Jun 4, 2011 at 10:06 AM, John Ellson wrote: > Now that I have Solaris-10 running on a virtual host locally, is there > an easy way I can set it up as a buildhost? > > If I could do that, I could use it to build the graphviz nightly > development snapshots. err.. what do you mean by buildhost? one that all maintainers can use? or just personal? If personal, it should be as easy as just "install the packages you need. install suncc. go compile stuff" :) (and if it isnt, we need to improve it, so it's easier for our users to do compiles themselves) From ellson at opencsw.org Sat Jun 4 21:55:16 2011 From: ellson at opencsw.org (John Ellson) Date: Sat, 04 Jun 2011 15:55:16 -0400 Subject: [csw-maintainers] how to set up a local buildhost? In-Reply-To: References: <4DEA660B.4080102@opencsw.org> Message-ID: <4DEA8DA4.8000304@opencsw.org> On 06/04/2011 03:42 PM, Philip Brown wrote: > On Sat, Jun 4, 2011 at 10:06 AM, John Ellson wrote: >> Now that I have Solaris-10 running on a virtual host locally, is there >> an easy way I can set it up as a buildhost? >> >> If I could do that, I could use it to build the graphviz nightly >> development snapshots. > err.. what do you mean by buildhost? > > one that all maintainers can use? or just personal? Just for me personally to build on. I want to generate binary packages from the latest development sources, that can be installed in /opt/csw/. I'd make these nightly development packages available on http://www.graphviz.org. I do this now for rpms, and debs, and MacOS pkgs > If personal, it should be as easy as just > "install the packages you need. install suncc. go compile stuff" > :) What about gar scripts? Just "pkg-get -i gar" ? What about catalog support for a graphviz.org collection? > (and if it isnt, we need to improve it, so it's easier for our users > to do compiles themselves) > _______________________________________________ John From bwalton at opencsw.org Sun Jun 5 02:07:57 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 04 Jun 2011 20:07:57 -0400 Subject: [csw-maintainers] [csw-buildfarm] pkg-config failure unstable9[xs] In-Reply-To: <4DEA6CFC.7060500@opencsw.org> References: <4DEA6CFC.7060500@opencsw.org> Message-ID: <1307232386-sup-7830@pinkfloyd.chass.utoronto.ca> Excerpts from John Ellson's message of Sat Jun 04 13:35:56 -0400 2011: > Is the librvg on unstable9[xs] out of date? Or possibly pixman? I just installed CSWlibpixman-dev on the unstable* hosts. It wasn't there at all. That seems to make unstable9x look like current9x. Let me know if you spot any other issues. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sun Jun 5 04:33:18 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 04 Jun 2011 22:33:18 -0400 Subject: [csw-maintainers] how to set up a local buildhost? In-Reply-To: <4DEA8DA4.8000304@opencsw.org> References: <4DEA660B.4080102@opencsw.org> <4DEA8DA4.8000304@opencsw.org> Message-ID: <1307241076-sup-4963@pinkfloyd.chass.utoronto.ca> Excerpts from John Ellson's message of Sat Jun 04 15:55:16 -0400 2011: Hi John, > What about gar scripts? Just "pkg-get -i gar" ? You'll want to do: pkgutil -i CSWgar-dev In a day or so when Phil has pushed CSWmgar, you can either add that manually or update CSWgar-dev to pull it in too. With mgar installed, you can follow the instructions at: http://wiki.opencsw.org/gar-wrapper > What about catalog support for a graphviz.org collection? There is buildcat for this. I haven't used it myself, but Peter or Dago could help with this as they're quite familiar with it. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Sun Jun 5 05:29:42 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 4 Jun 2011 20:29:42 -0700 Subject: [csw-maintainers] how to set up a local buildhost? In-Reply-To: <4DEA8DA4.8000304@opencsw.org> References: <4DEA660B.4080102@opencsw.org> <4DEA8DA4.8000304@opencsw.org> Message-ID: On Sat, Jun 4, 2011 at 12:55 PM, John Ellson wrote: > > What about catalog support for a graphviz.org collection? I'm not sure what you mean by that. From james at opencsw.org Sun Jun 5 10:24:13 2011 From: james at opencsw.org (James Lee) Date: Sun, 05 Jun 2011 08:24:13 GMT Subject: [csw-maintainers] initialization problem: struct + union In-Reply-To: References: Message-ID: <20110605.8241300.1660397962@gyor.oxdrove.co.uk> On 03/06/11, 22:53:46, Philip Brown wrote regarding [csw-maintainers] initialization problem: struct + union: > A chopped down version, which compiles with gcc, but fails under sun cc: > ( complains about the {integer:2} thing at bottom) > #include > union types { > char *string; > int integer; > }; > typedef struct { > char *option; > int type; > union types default_value; > } config_opt_t; > #define INTEGER 1 > config_opt_t config_opts[] = { > { "snmp_timeout", INTEGER, {integer:2} }, > }; Remove the type qualifier and it compiles with just a warning. config_opt_t config_opts[] = { { "snmp_timeout", INTEGER, 2 }, }; Simple case warning avoidance, declare integer first: union types { int integer; char *string; }; Extending the code to use both types in the union this complies with warning and runs: $ cat test.c #include union types { char *string; int integer; }; typedef struct { char *option; int type; union types default_value; } config_opt_t; #define INTEGER 1 #define STRING 2 config_opt_t config_opts[] = { { "snmp_timeout", INTEGER, 2 }, { "snmp_message", STRING, "time out exceeded" }, }; int main(int argc, char* argv[]) { int i; for (i = 0; i < sizeof(config_opts) / sizeof(config_opt_t); i++) { switch (config_opts[i].type) { case INTEGER: printf("%s: %d\n", config_opts[i].option, config_opts[i].default_value.integer); break; case STRING: printf("%s: %s\n", config_opts[i].option, config_opts[i].default_value.string); break; } } return 0; } $ cc test.c "test.c", line 16: warning: improper pointer/integer combination: op "=" $ ./a.out snmp_timeout: 2 snmp_message: time out exceeded James. From bwalton at opencsw.org Sun Jun 5 14:37:03 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 05 Jun 2011 08:37:03 -0400 Subject: [csw-maintainers] how to set up a local buildhost? In-Reply-To: References: <4DEA660B.4080102@opencsw.org> <4DEA8DA4.8000304@opencsw.org> Message-ID: <1307277386-sup-4020@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sat Jun 04 23:29:42 -0400 2011: > On Sat, Jun 4, 2011 at 12:55 PM, John Ellson wrote: > > > > What about catalog support for a graphviz.org collection? > > I'm not sure what you mean by that. He wants the ability to build a catalog from his local set similar to what we do for the experimental repos. It could then be fed to pkgutil -t, etc. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sun Jun 5 15:01:59 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 05 Jun 2011 09:01:59 -0400 Subject: [csw-maintainers] time to deprecate CSWmozilla In-Reply-To: References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca> <1307123778-sup-3520@pinkfloyd.chass.utoronto.ca> Message-ID: <1307278894-sup-1960@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sat Jun 04 11:18:52 -0400 2011: > I would suggest that someone who is interested in repackaging them, > attempt to compile against seamonkey. and if it fails, pull up the > relevant patches, and try it again. debian and ubuntu seem to have > patches, according to google If someone were interested in packaging them, they would have done so already. Why not abandon them until such time as somebody does have interest so that we can stop blocking progress on the nspr issue that people do care about? I suggest we remove all three from the catalog. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From ellson at opencsw.org Sun Jun 5 15:30:15 2011 From: ellson at opencsw.org (John Ellson) Date: Sun, 05 Jun 2011 09:30:15 -0400 Subject: [csw-maintainers] [csw-buildfarm] pkg-config failure unstable9[xs] In-Reply-To: <1307232386-sup-7830@pinkfloyd.chass.utoronto.ca> References: <4DEA6CFC.7060500@opencsw.org> <1307232386-sup-7830@pinkfloyd.chass.utoronto.ca> Message-ID: <4DEB84E7.3030609@opencsw.org> On 06/04/2011 08:07 PM, Ben Walton wrote: > I just installed CSWlibpixman-dev on the unstable* hosts. It wasn't > there at all. That seems to make unstable9x look like current9x. Thanks > Let me know if you spot any other issues. I believe the libxml2 package on current9[xs] is newer than on unstable9[sx] ? >From diff'ing the two /opt/csw/include/libxml2/libxml/xmlversion.h I get: < #define LIBXML_DOTTED_VERSION "2.7.8" --- > #define LIBXML_DOTTED_VERSION "2.7.7" This is causing some unresolved symbols in ImageMagick. Could you update CSWlibxml2 on unstable please? [ BTW How to I list the installed package with its package version number? "pkg-get -l" just gives me the name ] I'm also seeing a problem with Undefined symbol: XSolarisIASetProcessInfo /lib/libX11.so.4 Is that something you might recognise? John From dam at opencsw.org Sun Jun 5 15:55:04 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 5 Jun 2011 15:55:04 +0200 Subject: [csw-maintainers] [csw-buildfarm] pkg-config failure unstable9[xs] In-Reply-To: <4DEB84E7.3030609@opencsw.org> References: <4DEA6CFC.7060500@opencsw.org> <1307232386-sup-7830@pinkfloyd.chass.utoronto.ca> <4DEB84E7.3030609@opencsw.org> Message-ID: Hi John, Am 05.06.2011 um 15:30 schrieb John Ellson: > On 06/04/2011 08:07 PM, Ben Walton wrote: >> I just installed CSWlibpixman-dev on the unstable* hosts. It wasn't >> there at all. That seems to make unstable9x look like current9x. > > Thanks >> Let me know if you spot any other issues. > > I believe the libxml2 package on current9[xs] is newer than on > unstable9[sx] ? > From diff'ing the two /opt/csw/include/libxml2/libxml/xmlversion.h I get: > < #define LIBXML_DOTTED_VERSION "2.7.8" > --- >> #define LIBXML_DOTTED_VERSION "2.7.7" > > > This is causing some unresolved symbols in ImageMagick. Could you > update CSWlibxml2 on unstable please? This does not look good: unstable9x# pkgutil -c libxml2 package installed catalog CSWlibxml2 2.7.8,REV=2011.03.21 SAME CSWlibxml2-2 2.7.8,REV=2011.03.24 SAME CSWlibxml2devel 2.7.7,REV=2010.04.10 SAME Ben: Would you mind having a look and re-release the devel package? > [ BTW How to I list the installed package with its package version > number? "pkg-get -l" just gives me the name ] Try pkgutil -c libxml2 as seen above. > I'm also seeing a problem with Undefined symbol: > XSolarisIASetProcessInfo /lib/libX11.so.4 > > Is that something you might recognise? Yes, these are still artifacts from http://wiki.opencsw.org/project-x11 where we tried to build the complete set against an OpenCSW X11. However, this doesn't prove good and the above error is an indication of mixed libx11.so.4 and libx11.so.6 linkage. The correct action is to find the "old" package and rebuild it against SUNW x11. Best regards -- Dago From ellson at opencsw.org Sun Jun 5 16:11:13 2011 From: ellson at opencsw.org (John Ellson) Date: Sun, 05 Jun 2011 10:11:13 -0400 Subject: [csw-maintainers] [csw-buildfarm] pkg-config failure unstable9[xs] In-Reply-To: References: <4DEA6CFC.7060500@opencsw.org> <1307232386-sup-7830@pinkfloyd.chass.utoronto.ca> <4DEB84E7.3030609@opencsw.org> Message-ID: <4DEB8E81.1070700@opencsw.org> On 06/05/2011 09:55 AM, Dagobert Michelsen wrote: > I'm also seeing a problem with Undefined symbol: >> XSolarisIASetProcessInfo /lib/libX11.so.4 >> >> Is that something you might recognise? > Yes, these are still artifacts from > http://wiki.opencsw.org/project-x11 > where we tried to build the complete set against an OpenCSW X11. However, > this doesn't prove good and the above error is an indication of mixed > libx11.so.4 and libx11.so.6 linkage. The correct action is to find the > "old" package and rebuild it against SUNW x11. Possibly librsvg-2 ? ellson at current9s:ellson> ldd /opt/csw/lib/librsvg-2.so | grep libX libXrender.so.1 => /opt/csw/lib/sparcv8/libXrender.so.1 libX11.so.4 => /usr/lib/libX11.so.4 libXext.so.0 => /usr/openwin/lib/libXext.so.0 From ellson at opencsw.org Sun Jun 5 16:40:21 2011 From: ellson at opencsw.org (John Ellson) Date: Sun, 05 Jun 2011 10:40:21 -0400 Subject: [csw-maintainers] [csw-buildfarm] pkg-config failure unstable9[xs] In-Reply-To: References: <4DEA6CFC.7060500@opencsw.org> <1307232386-sup-7830@pinkfloyd.chass.utoronto.ca> <4DEB84E7.3030609@opencsw.org> Message-ID: <4DEB9555.7040107@opencsw.org> On 06/05/2011 09:55 AM, Dagobert Michelsen wrote: > >> I'm also seeing a problem with Undefined symbol: >> XSolarisIASetProcessInfo /lib/libX11.so.4 >> >> Is that something you might recognise? > Yes, these are still artifacts from > http://wiki.opencsw.org/project-x11 > where we tried to build the complete set against an OpenCSW X11. However, > this doesn't prove good and the above error is an indication of mixed > libx11.so.4 and libx11.so.6 linkage. The correct action is to find the > "old" package and rebuild it against SUNW x11. > Not sure if these cause any problems, but I noticed that these x11 packages are installed on unstable but not on current. CSWx11common 1.0,REV=2009.05.24 SAME CSWx11kbproto 1.0.4,REV=2010.02.20 SAME CSWx11xextproto 7.1.1,REV=2010.02.20 SAME CSWx11xproto 7.0.16,REV=2010.02.20 SAME From ellson at opencsw.org Sun Jun 5 17:00:41 2011 From: ellson at opencsw.org (John Ellson) Date: Sun, 05 Jun 2011 11:00:41 -0400 Subject: [csw-maintainers] [csw-buildfarm] pkg-config failure unstable9[xs] In-Reply-To: References: <4DEA6CFC.7060500@opencsw.org> <1307232386-sup-7830@pinkfloyd.chass.utoronto.ca> <4DEB84E7.3030609@opencsw.org> Message-ID: <4DEB9A19.1020403@opencsw.org> On 06/05/2011 09:55 AM, Dagobert Michelsen wrote: > >> I'm also seeing a problem with Undefined symbol: >> XSolarisIASetProcessInfo /lib/libX11.so.4 >> >> Is that something you might recognise? > Yes, these are still artifacts from > http://wiki.opencsw.org/project-x11 > where we tried to build the complete set against an OpenCSW X11. However, > this doesn't prove good and the above error is an indication of mixed > libx11.so.4 and libx11.so.6 linkage. The correct action is to find the > "old" package and rebuild it against SUNW x11. I think I'm seeing the same problem I had with graphviz. If there are installed .so for the package from an old installation then libtool tries to link them into the new build. I can't find any libX11.so.4 in any products in the build tree, but I do find it in: ellson at unstable9s:lib> ldd libMagick.so.10.0.4 | grep X11 libX11.so.4 => /usr/openwin/lib/libX11.so.4 ImageMagic doesn't have a -devel package, so could you please uninstall ImageMagic entirely from unstable6[sx] while I try rebuilding? John From ellson at opencsw.org Sun Jun 5 18:34:45 2011 From: ellson at opencsw.org (John Ellson) Date: Sun, 05 Jun 2011 12:34:45 -0400 Subject: [csw-maintainers] gar and php question Message-ID: <4DEBB025.6010702@opencsw.org> I'm trying to build the php extension for graphviz. The configure file looks for a php executable to use to extract php configuration details. It expects "php" in the regular PATH, but the opencsw php is installed in /opt/csw/php5/bin/php. I've tried adding this to my PATH, but configure still doesn't find it. Q1. Does GAR restrict or override PATH during builds? Q2. Could php be installed (perhaps as a softlink, perhaps as an alternative) in /opt/csw/bin ? John From phil at bolthole.com Sun Jun 5 19:03:53 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 5 Jun 2011 10:03:53 -0700 Subject: [csw-maintainers] time to deprecate CSWmozilla In-Reply-To: <1307278894-sup-1960@pinkfloyd.chass.utoronto.ca> References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca> <1307123778-sup-3520@pinkfloyd.chass.utoronto.ca> <1307278894-sup-1960@pinkfloyd.chass.utoronto.ca> Message-ID: On Sun, Jun 5, 2011 at 6:01 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Sat Jun 04 11:18:52 -0400 2011: > >> I would suggest that someone who is interested in repackaging them, >> attempt to compile against seamonkey. and if it fails, pull up the >> relevant patches, and try it again. debian and ubuntu seem to have >> patches, according to google > > If someone were interested in packaging them, they would have done so > already. so you're suggesting that from now on, no-one should ever bother requesting anyone take over orphaned packages, becuase "if anyone were interested in packaging them, they would have done so already". we can wait a week. From phil at bolthole.com Sun Jun 5 19:07:49 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 5 Jun 2011 10:07:49 -0700 Subject: [csw-maintainers] [csw-buildfarm] pkg-config failure unstable9[xs] In-Reply-To: <4DEB9555.7040107@opencsw.org> References: <4DEA6CFC.7060500@opencsw.org> <1307232386-sup-7830@pinkfloyd.chass.utoronto.ca> <4DEB84E7.3030609@opencsw.org> <4DEB9555.7040107@opencsw.org> Message-ID: On Sun, Jun 5, 2011 at 7:40 AM, John Ellson wrote: > > > Not sure if these cause any problems, but I noticed that these x11 > packages are installed on unstable but not on current. > > CSWx11common ? ? ? ? ? ? ?1.0,REV=2009.05.24 > SAME > CSWx11kbproto ? ? ? ? ? ? 1.0.4,REV=2010.02.20 > SAME > CSWx11xextproto ? ? ? ? ? 7.1.1,REV=2010.02.20 > SAME > CSWx11xproto ? ? ? ? ? ? ?7.0.16,REV=2010.02.20 ? ? SAME > it would be better if these were removed. they are probably messing things up. From phil at bolthole.com Sun Jun 5 19:12:50 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 5 Jun 2011 10:12:50 -0700 Subject: [csw-maintainers] gar and php question In-Reply-To: <4DEBB025.6010702@opencsw.org> References: <4DEBB025.6010702@opencsw.org> Message-ID: >Q2. Could php be installed (perhaps as a softlink, perhaps as an >alternative) in /opt/csw/bin ? i think this is a reasonable thing to do. and, no need to make it an "alternative". just make the link. From ellson at opencsw.org Sun Jun 5 20:53:08 2011 From: ellson at opencsw.org (John Ellson) Date: Sun, 05 Jun 2011 14:53:08 -0400 Subject: [csw-maintainers] Rebuild of imagemagick In-Reply-To: <7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org> References: <4DE810E0.4050502@opencsw.org> <7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org> Message-ID: <4DEBD094.9080301@opencsw.org> On 06/03/2011 12:04 PM, Dagobert Michelsen wrote: > Hi John, > > Am 03.06.2011 um 00:38 schrieb John Ellson: >> OK, I'm going to try rebuilding ImageMagick against graphviz-2.28.0 >> for a simultaneous release. >> >> On the current* build hosts, could you please: >> >> Uninstall graphviz*-2.26.3 and ImageMagick >> >> Install graphviz-2.28.0 and graphvizdevel-2.28.0 from the >> unstable catalog. > > Umh, the usual procedure is to just update unstable and build graphviz > there. > I am doing this now, ok? Unstable is a mess. Can we go back to plan A (above) ? Cranky John > > BTW, Roger had quite some effort in a 64 bit Imagemagick: > http://wiki.opencsw.org/project-imagemagick64 > Maybe we can continue this project and finish up in a joint effort? > > Roger: Haven't heard from you in a while, everything ok? :-) > > > Best regards > > -- Dago > >> >> Thanks. >> >> John >> >> -------- Original Message -------- >> Subject: Re: [csw-maintainers] graphviz: pushed to unstable - >> problem analysis, solution, and next issue >> Date: Thu, 2 Jun 2011 15:08:27 -0700 >> From: Philip Brown >> Reply-To: List for OpenCSW maintainers >> To: List for OpenCSW maintainers >> >> >> >> On Thu, Jun 2, 2011 at 3:05 PM, John Ellson wrote: >> > Dago, >> > >> > This really sounds like a lot of work for a one-time problem. >> > >> > Is there an alternative? Could graphviz-2.28.0 be installed on the >> > current build hosts and then ImageMagic rebuilt for a simultaneous release? >> > >> >> that is certainly an even better solution, if there is nothing else >> depending on the older libraries. >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers >> .:: This mailing list's archive is public. ::. >> >> _______________________________________________ >> buildfarm mailing list >> buildfarm at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/buildfarm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellson at opencsw.org Sun Jun 5 20:56:33 2011 From: ellson at opencsw.org (John Ellson) Date: Sun, 05 Jun 2011 14:56:33 -0400 Subject: [csw-maintainers] /opt/csw/bin/csw-upload-pkg still doesn't work on login Message-ID: <4DEBD161.3020601@opencsw.org> ellson at login:newpkgs> csw-upload-pkg *2.28.0,REV=2011.06.05* Processing 35 file(s). Please wait. Uploading 'graphviz-2.28.0,REV=2011.06.05-SunOS5.9-i386-CSW.pkg.gz' ... Checking 19 package(s) against catalog unstable sparc SunOS5.9 ERROR: --catalog-release does not exist Checking 19 package(s) against catalog unstable i386 SunOS5.9 ERROR: --catalog-release does not exist Checking 19 package(s) against catalog unstable sparc SunOS5.10 ERROR: --catalog-release does not exist Checking 19 package(s) against catalog unstable i386 SunOS5.10 ERROR: --catalog-release does not exist Checks failed for catalogs: ... The version in the gar checkout works ok. From ellson at opencsw.org Sun Jun 5 21:03:15 2011 From: ellson at opencsw.org (John Ellson) Date: Sun, 05 Jun 2011 15:03:15 -0400 Subject: [csw-maintainers] libxml2 broken Message-ID: <4DEBD2F3.8070808@opencsw.org> Trying to repackage libxml2 from trunk, with *no* changes, fails because of test failures during "make package" John ./runtest && ./testrecurse && ./testapi && ./testchar&& ./testdict && ./runxmlconf ## XML regression tests File ./test/ebcdic_566012.xml generated an error ## XML regression tests on memory File ./test/ebcdic_566012.xml generated an error ## XML entity subst regression tests File ./test/ebcdic_566012.xml generated an error ## XML Namespaces regression tests ## Error cases regression tests ## Error cases stream regression tests ## Reader regression tests Result for ./test/ebcdic_566012.xml failed File ./test/ebcdic_566012.xml generated an error ## Reader entities substitution regression tests Result for ./test/ebcdic_566012.xml failed File ./test/ebcdic_566012.xml generated an error ## Reader on memory regression tests Result for ./test/ebcdic_566012.xml failed File ./test/ebcdic_566012.xml generated an error ## Walker regression tests Failed to parse ./test/ebcdic_566012.xml File ./test/ebcdic_566012.xml generated an error ## SAX1 callbacks regression tests Failed to parse ./test/ebcdic_566012.xml File ./test/ebcdic_566012.xml generated an error ## SAX2 callbacks regression tests Failed to parse ./test/ebcdic_566012.xml File ./test/ebcdic_566012.xml generated an error ## XML push regression tests Failed to parse ./test/ebcdic_566012.xml File ./test/ebcdic_566012.xml generated an error ## HTML regression tests ## Push HTML regression tests ## HTML SAX regression tests ## Valid documents regression tests ## Validity checking regression tests ## General documents valid regression tests ## XInclude regression tests ## XInclude xmlReader regression tests ## XInclude regression tests stripping include nodes ## XInclude xmlReader regression tests stripping include nodes ## XPath expressions regression tests ## XPath document queries regression tests ## XPointer document queries regression tests ## xml:id regression tests ## URI parsing tests ## URI base composition tests ## Path URI conversion tests ## Schemas regression tests ## Relax-NG regression tests ## Relax-NG streaming regression tests ## Pattern regression tests ## C14N with comments regression tests ## C14N without comments regression tests ## C14N exclusive without comments regression tests ## C14N 1.1 without comments regression tests ## Catalog and Threads regression tests Total 2819 tests, 10 errors, 0 leaks gmake[2]: *** [runtests] Error 1 gmake[2]: Leaving directory `/home/ellson/mgar/pkg/libxml2/trunk/work/solaris9-sparc/build-isa-sparcv8/libxml2-2.7.8' gmake[1]: *** [test-work/solaris9-sparc/build-isa-sparcv8/libxml2-2.7.8/Makefile] Error 2 gmake[1]: Leaving directory `/home/ellson/mgar/pkg/libxml2/trunk' make: *** [merge-isa-sparcv8] Error 2 From dam at opencsw.org Sun Jun 5 21:30:42 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 5 Jun 2011 21:30:42 +0200 Subject: [csw-maintainers] Errors on current graphviz update Message-ID: Hi John, I get the following errors on graphviz update from unstable: => Installing CSWgraphviz-2.28.0,REV=2011.06.04 (23/24) ... Please see /opt/csw/share/doc/graphviz/license for license information. dot -c is running now to record available graphviz plugins. Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found Installation of was successful. Best regards -- Dago PS: It may be best to open up a webpage with "project-graphviz" which denotes the state of the current subprojects (imagemagick, libxml etc.) From ellson at opencsw.org Sun Jun 5 21:57:17 2011 From: ellson at opencsw.org (John Ellson) Date: Sun, 05 Jun 2011 15:57:17 -0400 Subject: [csw-maintainers] Errors on current graphviz update In-Reply-To: References: Message-ID: <4DEBDF9D.3010707@opencsw.org> On 06/05/2011 03:30 PM, Dagobert Michelsen wrote: > Hi John, > > I get the following errors on graphviz update from unstable: > > => Installing CSWgraphviz-2.28.0,REV=2011.06.04 (23/24) ... > Please see /opt/csw/share/doc/graphviz/license for license information. > > dot -c is running now to record available graphviz plugins. > > Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found What machine were you installing on? unstable9s ? Graphviz was built on current9s. Lots of stuff is broken in unstable9[sx] > > PS: It may be best to open up a webpage with "project-graphviz" which denotes the > state of the current subprojects (imagemagick, libxml etc.) Good idea, except that Firefox-3.6.17 doesn't seem to like the Javascript from http://wiki.opencsw.org/ Try to "Sign in" or "Create account" and it just hangs with "javascript:;" on the bottom status bar. John From ellson at opencsw.org Sun Jun 5 22:07:39 2011 From: ellson at opencsw.org (John Ellson) Date: Sun, 05 Jun 2011 16:07:39 -0400 Subject: [csw-maintainers] Errors on current graphviz update In-Reply-To: References: Message-ID: <4DEBE20B.4000504@opencsw.org> On 06/05/2011 03:30 PM, Dagobert Michelsen wrote: > PS: It may be best to open up a webpage with "project-graphviz" which denotes the > state of the current subprojects (imagemagick, libxml etc.) There was another way to sign up, by trying to create a page. I did that, now I have a user account on the wiki for "ellson at opencsw.org", but it still won't let me create a page. Now it says: "Permissions error. Please note: Sorry, you cannot create a page in this category. Only member of this site, site administrators and perhaps selected moderators are allowed to do it." I was trying to use the entry-widget on the left to create "project-graphviz" John From bonivart at opencsw.org Sun Jun 5 22:12:32 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 5 Jun 2011 22:12:32 +0200 Subject: [csw-maintainers] Errors on current graphviz update In-Reply-To: <4DEBDF9D.3010707@opencsw.org> References: <4DEBDF9D.3010707@opencsw.org> Message-ID: On Sun, Jun 5, 2011 at 9:57 PM, John Ellson wrote: > Good idea, except that Firefox-3.6.17 doesn't seem to like the > Javascript from http://wiki.opencsw.org/ > > Try to "Sign in" or "Create account" and it just hangs with > "javascript:;" on the bottom status bar. Man, you do attract problems like a magnet. You can create a dir "graphviz" under experimental. On the web page for experimental there will then be a link to create a wiki project. That's probably what Dago meant. Regarding wiki access you need to apply for membership on our specific wiki. You now have a wikidot account, good, apply for membership on the OpenCSW wiki and I will approve it, then you can create/edit pages. /peter From ellson at opencsw.org Sun Jun 5 22:14:45 2011 From: ellson at opencsw.org (John Ellson) Date: Sun, 05 Jun 2011 16:14:45 -0400 Subject: [csw-maintainers] php5 broken Message-ID: <4DEBE3B5.4050904@opencsw.org> I just tried repackaging php5 with *no* changes. (I was investing how hard it would be to add a softlink: /opt/csw/bin/php -> /opt/csw/php5/bin/php ) Why would it even fail for "surplus-dependency" ? What harm is there? John If any of the reported errors were false positives, you can override them pasting the lines below to the GAR recipe. CHECKPKG_OVERRIDES_CSWphp5-mysql += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-gettext += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-gmp += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-dba += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-tidy += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-gd += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-sysvshm += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-hash += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-xsl += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-mssql += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-dom += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-sqlite += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-bcmath += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-imap += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-session += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-sysvmsg += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-zip += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-soap += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-json += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-xmlrpc += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-bz2 += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-pdo += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-shmop += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-posix += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-sysvsem += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-curl += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-wddx += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-xmlreader += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-ftp += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-mcrypt += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-sockets += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-openssl += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-iconv += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-calendar += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-mysqli += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-tokenizer += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-pgsql += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-mbstring += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-xmlwriter += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-readline += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-ldap += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-odbc += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-pcntl += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-pspell += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-exif += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-snmp += surplus-dependency|CSWphp5 CHECKPKG_OVERRIDES_CSWphp5-ctype += surplus-dependency|CSWphp5 Please note that checkpkg isn't suggesting you should simply add these overrides do the Makefile. It only informs what the overrides could look like. You need to understand what are the reported issues about and use your best judgement to decide whether to fix the underlying problems or override them. For more information, scroll up and read the detailed messages. WARNING: Some overrides did not match any errors. They can be removed, as they don't take any effect anyway. If you're getting errors at the same time, maybe you didn't specify the overrides correctly. * Unused Override: CSWphp5sqlite: archall-devel-package * Unused Override: CSWphp5ldap: archall-devel-package * Unused Override: CSWphp5pdo: archall-devel-package * Unused Override: CSWphp5mssql: archall-devel-package * Unused Override: CSWphp5-pdoodbc: surplus-dependency CSWphp5-pdo * Unused Override: CSWphp5zip: archall-devel-package * Unused Override: CSWphp5sysvshm: archall-devel-package * Unused Override: CSWphp5xmlwriter: archall-devel-package * Unused Override: CSWphp5pdomysql: archall-devel-package * Unused Override: CSWphp5mcrypt: archall-devel-package * Unused Override: CSWphp5mysql: archall-devel-package * Unused Override: CSWphp5dba: archall-devel-package * Unused Override: CSWphp5xmlrpc: archall-devel-package * Unused Override: CSWphp5exif: archall-devel-package * Unused Override: CSWap2modphp5: archall-devel-package * Unused Override: CSWphp5bz2: archall-devel-package * Unused Override: CSWphp5pdoodbc: archall-devel-package * Unused Override: CSWphp5pdopgsql: archall-devel-package * Unused Override: CSWphp5pgsql: archall-devel-package * Unused Override: CSWphp5ftp: archall-devel-package * Unused Override: CSWphp5calendar: archall-devel-package * Unused Override: CSWphp5pdosqlite: archall-devel-package * Unused Override: CSWphp5-pdopgsql: surplus-dependency CSWphp5-pdo * Unused Override: CSWphp5posix: archall-devel-package * Unused Override: CSWphp5sockets: archall-devel-package * Unused Override: CSWphp5-pdosqlite: surplus-dependency CSWphp5-pdo * Unused Override: CSWphp5pcntl: archall-devel-package * Unused Override: CSWphp5mysqli: archall-devel-package * Unused Override: CSWphp5tidy: archall-devel-package * Unused Override: CSWphp5odbc: archall-devel-package * Unused Override: CSWphp5readline: archall-devel-package * Unused Override: CSWphp5gmp: archall-devel-package * Unused Override: CSWphp5gd: archall-devel-package * Unused Override: CSWphp5openssl: archall-devel-package * Unused Override: CSWphp5session: archall-devel-package * Unused Override: CSWphp5xmlreader: archall-devel-package * Unused Override: CSWphp5bcmath: archall-devel-package * Unused Override: CSWphp5-pdomysql: surplus-dependency CSWphp5-pdo * Unused Override: CSWphp5ctype: archall-devel-package * Unused Override: CSWphp5gettext: archall-devel-package * Unused Override: CSWphp5iconv: archall-devel-package * Unused Override: CSWphp5hash: archall-devel-package * Unused Override: CSWphp5imap: archall-devel-package * Unused Override: CSWphp5sysvsem: archall-devel-package * Unused Override: CSWphp5snmp: archall-devel-package * Unused Override: CSWphp5dom: archall-devel-package * Unused Override: CSWphp5wddx: archall-devel-package * Unused Override: CSWphp5soap: archall-devel-package * Unused Override: CSWphp5shmop: archall-devel-package * Unused Override: CSWphp5sysvmsg: archall-devel-package * Unused Override: CSWphp5json: archall-devel-package * Unused Override: CSWphp5tokenizer: archall-devel-package * Unused Override: CSWphp5curl: archall-devel-package * Unused Override: CSWphp5xsl: archall-devel-package * Unused Override: CSWphp5mbstring: archall-devel-package * Unused Override: CSWphp5pspell: archall-devel-package gmake: *** [pkgcheck] Error 2 gmake: Leaving directory `/home/ellson/mgar/pkg/php5/trunk' Connection to current9s closed. gmake: *** [platforms] Error 2 ellson at login:~> From ellson at opencsw.org Sun Jun 5 22:43:21 2011 From: ellson at opencsw.org (John Ellson) Date: Sun, 05 Jun 2011 16:43:21 -0400 Subject: [csw-maintainers] Errors on current graphviz update In-Reply-To: References: <4DEBDF9D.3010707@opencsw.org> Message-ID: <4DEBEA69.7040009@opencsw.org> On 06/05/2011 04:12 PM, Peter Bonivart wrote: > On Sun, Jun 5, 2011 at 9:57 PM, John Ellson wrote: >> Good idea, except that Firefox-3.6.17 doesn't seem to like the >> Javascript from http://wiki.opencsw.org/ >> >> Try to "Sign in" or "Create account" and it just hangs with >> "javascript:;" on the bottom status bar. > Man, you do attract problems like a magnet. I can't be just me? How is anyone else able to maintain any opencsw package these days??? > You can create a dir "graphviz" under experimental. Did that. > On the web page > for experimental there will then be a link to create a wiki project. Yes. Followed that ok. > That's probably what Dago meant. Probably. > Regarding wiki access you need to apply for membership on our specific > wiki. You now have a wikidot account, good, apply for membership on > the OpenCSW wiki and I will approve it, then you can create/edit > pages. Tried that. It said: You can not apply. It seems you have already applied for membership. John (the cranky problem magnet). From ellson at opencsw.org Sun Jun 5 23:31:12 2011 From: ellson at opencsw.org (John Ellson) Date: Sun, 05 Jun 2011 17:31:12 -0400 Subject: [csw-maintainers] http://wiki.opencsw.org/project-graphviz Message-ID: <4DEBF5A0.9010004@opencsw.org> There is a first-cut project page for graphviz now available at: http://wiki.opencsw.org/project-graphviz John From ellson at opencsw.org Sun Jun 5 23:39:44 2011 From: ellson at opencsw.org (John Ellson) Date: Sun, 05 Jun 2011 17:39:44 -0400 Subject: [csw-maintainers] Errors on current graphviz update In-Reply-To: References: Message-ID: <4DEBF7A0.4010708@opencsw.org> Dago, I couldn't reproduce this here. I installed graphviz-2.28.0,REV=2011.06.05-SunOS5.9-i386-CSW.pkg.gz No problems during the "dot -c" postinstall step, and it tested fine with: echo "digraph {hello->world}" | dot -v -Tps:lasi Any chance you could try installing on something other than unstable8[sx] ? John On 06/05/2011 03:30 PM, Dagobert Michelsen wrote: > Hi John, > > I get the following errors on graphviz update from unstable: > > => Installing CSWgraphviz-2.28.0,REV=2011.06.04 (23/24) ... > Please see /opt/csw/share/doc/graphviz/license for license information. > > dot -c is running now to record available graphviz plugins. > > Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found > Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found > Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found > Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found > Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found > Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found > Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found > Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found > > Installation of was successful. > > > Best regards > > -- Dago > > PS: It may be best to open up a webpage with "project-graphviz" which denotes the > state of the current subprojects (imagemagick, libxml etc.) From ellson at opencsw.org Sun Jun 5 23:54:04 2011 From: ellson at opencsw.org (John Ellson) Date: Sun, 05 Jun 2011 17:54:04 -0400 Subject: [csw-maintainers] Errors on current graphviz update In-Reply-To: <4DEBF7A0.4010708@opencsw.org> References: <4DEBF7A0.4010708@opencsw.org> Message-ID: <4DEBFAFC.2030706@opencsw.org> This may be the problem: ellson at unstable9s:ellson> ldd /opt/csw/lib/sparcv8/libpangocairo-1.0.so.0 | grep X11 libX11.so.4 => /usr/lib/libX11.so.4 John On 06/05/2011 05:39 PM, John Ellson wrote: > Dago, > > I couldn't reproduce this here. I installed > graphviz-2.28.0,REV=2011.06.05-SunOS5.9-i386-CSW.pkg.gz > No problems during the "dot -c" postinstall step, and it tested fine with: > echo "digraph {hello->world}" | dot -v -Tps:lasi > > Any chance you could try installing on something other than unstable8[sx] ? > > John > > > On 06/05/2011 03:30 PM, Dagobert Michelsen wrote: >> Hi John, >> >> I get the following errors on graphviz update from unstable: >> >> => Installing CSWgraphviz-2.28.0,REV=2011.06.04 (23/24) ... >> Please see /opt/csw/share/doc/graphviz/license for license information. >> >> dot -c is running now to record available graphviz plugins. >> >> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found >> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found >> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found >> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found >> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found >> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found >> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found >> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found >> >> Installation of was successful. >> >> >> Best regards >> >> -- Dago >> >> PS: It may be best to open up a webpage with "project-graphviz" which denotes the >> state of the current subprojects (imagemagick, libxml etc.) > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From maciej at opencsw.org Mon Jun 6 02:36:42 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 6 Jun 2011 01:36:42 +0100 Subject: [csw-maintainers] libxml2 broken In-Reply-To: <4DEBD2F3.8070808@opencsw.org> References: <4DEBD2F3.8070808@opencsw.org> Message-ID: 2011/6/5 John Ellson : > Trying to repackage libxml2 from trunk, with *no* changes, fails because > of test failures during "make package" I don't know exactly what state is libxml currently in, there is a couple of possibilities: - there was work on it going on, and not yet finished. Looking at the package database[1], the last published version was built from revision 13937 - it was released despite failing unit tests - something in the environment changed, causing tests to fail Maciej [1] http://www.opencsw.org/packages/CSWlibxml2-2/ From ellson at opencsw.org Mon Jun 6 02:53:48 2011 From: ellson at opencsw.org (John Ellson) Date: Sun, 05 Jun 2011 20:53:48 -0400 Subject: [csw-maintainers] libxml2 broken In-Reply-To: References: <4DEBD2F3.8070808@opencsw.org> Message-ID: <4DEC251C.5060106@opencsw.org> On 06/05/2011 08:36 PM, Maciej Blizi?ski wrote: > 2011/6/5 John Ellson : >> Trying to repackage libxml2 from trunk, with *no* changes, fails because >> of test failures during "make package" > I don't know exactly what state is libxml currently in, there is a > couple of possibilities: > > - there was work on it going on, and not yet finished. Looking at the > package database[1], the last published version was built from > revision 13937 That revision doesn't build now either. gar//gar.pkg.mk:106: *** The deprecated variable 'NOISAEXEC' is defined, this is now the default, please remove the line. Stop. > - it was released despite failing unit tests > - something in the environment changed, causing tests to fail > > Maciej > > [1] http://www.opencsw.org/packages/CSWlibxml2-2/ > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From maciej at opencsw.org Mon Jun 6 02:55:38 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 6 Jun 2011 01:55:38 +0100 Subject: [csw-maintainers] libxml2 broken In-Reply-To: <4DEC251C.5060106@opencsw.org> References: <4DEBD2F3.8070808@opencsw.org> <4DEC251C.5060106@opencsw.org> Message-ID: 2011/6/6 John Ellson : > On 06/05/2011 08:36 PM, Maciej Blizi?ski wrote: >> 2011/6/5 John Ellson : >>> Trying to repackage libxml2 from trunk, with *no* changes, fails because >>> of test failures during "make package" >> I don't know exactly what state is libxml currently in, there is a >> couple of possibilities: >> >> - there was work on it going on, and not yet finished. ?Looking at the >> package database[1], the last published version was built from >> revision 13937 > > That revision doesn't build now either. > > gar//gar.pkg.mk:106: *** The deprecated variable 'NOISAEXEC' is defined, > this is now the default, please remove the line. Stop. There was a GAR change since - if you check out GAR from the same revision, you'll get the compatible code. Maciej From maciej at opencsw.org Mon Jun 6 02:57:45 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 6 Jun 2011 01:57:45 +0100 Subject: [csw-maintainers] /opt/csw/bin/csw-upload-pkg still doesn't work on login In-Reply-To: <4DEBD161.3020601@opencsw.org> References: <4DEBD161.3020601@opencsw.org> Message-ID: 2011/6/5 John Ellson : > ellson at login:newpkgs> csw-upload-pkg *2.28.0,REV=2011.06.05* > Processing 35 file(s). Please wait. > Uploading 'graphviz-2.28.0,REV=2011.06.05-SunOS5.9-i386-CSW.pkg.gz' > ... > Checking 19 package(s) against catalog unstable sparc SunOS5.9 > ERROR: --catalog-release does not exist > (...) > The version in the gar checkout works ok. Please keep using the version from GAR sources, until Ben and I finish sorting out the version in /opt/csw/bin. Maciej From maciej at opencsw.org Mon Jun 6 02:58:50 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 6 Jun 2011 01:58:50 +0100 Subject: [csw-maintainers] Rebuild of imagemagick In-Reply-To: <4DEBD094.9080301@opencsw.org> References: <4DE810E0.4050502@opencsw.org> <7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org> <4DEBD094.9080301@opencsw.org> Message-ID: 2011/6/5 John Ellson > > Unstable is a mess. In what way? I am aware of the X11 libraries that need to be removed. Is there anything else? Maciej From ellson at opencsw.org Mon Jun 6 03:21:55 2011 From: ellson at opencsw.org (John Ellson) Date: Sun, 05 Jun 2011 21:21:55 -0400 Subject: [csw-maintainers] Rebuild of imagemagick In-Reply-To: References: <4DE810E0.4050502@opencsw.org> <7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org> <4DEBD094.9080301@opencsw.org> Message-ID: <4DEC2BB3.9050007@opencsw.org> On 06/05/2011 08:58 PM, Maciej Blizi?ski wrote: > 2011/6/5 John Ellson >> Unstable is a mess. > In what way? I am aware of the X11 libraries that need to be removed. > Is there anything else? Probably its mostly the libxml2 issue now: current9s has CSWlibxml2-dev and a newer CSWlibxml2devel. ellson at unstable9s:ellson> pkgutil -c libxml2 You're not root and didn't set -W, using home dir. package installed catalog CSWlibxml2 2.7.8,REV=2011.03.21 SAME CSWlibxml2-2 2.7.8,REV=2011.03.24 SAME CSWlibxml2devel 2.7.7,REV=2010.04.10 SAME CSWpy-libxml2 2.7.8,REV=2011.03.24 SAME CSWpylibxml2 2.7.8,REV=2011.03.21 SAME ellson at current9s:ellson> pkgutil -c libxml2 You're not root and didn't set -W, using home dir. package installed catalog CSWlibxml2 2.7.8,REV=2011.03.24 SAME CSWlibxml2-2 2.7.8,REV=2011.03.24 SAME CSWlibxml2-dev 2.7.8,REV=2011.03.24 SAME CSWlibxml2devel 2.7.8,REV=2011.03.24 SAME CSWpy-libxml2 2.7.8,REV=2011.03.24 SAME CSWpylibxml2 2.7.8,REV=2011.03.24 SAME Also, if the plan is for me to try to build ImageMagick on unstable, I need CSWimagemagick uninstalled, and CSWgraphviz-2.28.0 + CSWgraphvizdevel-2.28.0 installed. John > Maciej > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From ellson at opencsw.org Mon Jun 6 03:28:23 2011 From: ellson at opencsw.org (John Ellson) Date: Sun, 05 Jun 2011 21:28:23 -0400 Subject: [csw-maintainers] libxml2 broken In-Reply-To: References: <4DEBD2F3.8070808@opencsw.org> <4DEC251C.5060106@opencsw.org> Message-ID: <4DEC2D37.2010809@opencsw.org> On 06/05/2011 08:55 PM, Maciej Blizi?ski wrote: > 2011/6/6 John Ellson : >> On 06/05/2011 08:36 PM, Maciej Blizi?ski wrote: >>> 2011/6/5 John Ellson : >>>> Trying to repackage libxml2 from trunk, with *no* changes, fails because >>>> of test failures during "make package" The test failures are only from test/ebcdic_566012.xml. If that test is removed, "make check" succeeds. I suspect the problem is that CSWiconv doesn't have EBCDIC support: ellson at current9s:ellson> iconv -l | grep -i ebcdic ellson at current9s:ellson> We could fix CSWiconv or disable the test in CSWlibxml2 John >>> I don't know exactly what state is libxml currently in, there is a >>> couple of possibilities: >>> >>> - there was work on it going on, and not yet finished. Looking at the >>> package database[1], the last published version was built from >>> revision 13937 >> That revision doesn't build now either. >> >> gar//gar.pkg.mk:106: *** The deprecated variable 'NOISAEXEC' is defined, >> this is now the default, please remove the line. Stop. > There was a GAR change since - if you check out GAR from the same > revision, you'll get the compatible code. > > 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 Mon Jun 6 03:44:02 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 05 Jun 2011 21:44:02 -0400 Subject: [csw-maintainers] /opt/csw/bin/csw-upload-pkg still doesn't work on login In-Reply-To: <4DEBD161.3020601@opencsw.org> References: <4DEBD161.3020601@opencsw.org> Message-ID: <1307324599-sup-631@pinkfloyd.chass.utoronto.ca> Excerpts from John Ellson's message of Sun Jun 05 14:56:33 -0400 2011: > ellson at login:newpkgs> csw-upload-pkg *2.28.0,REV=2011.06.05* > Processing 35 file(s). Please wait. > Uploading 'graphviz-2.28.0,REV=2011.06.05-SunOS5.9-i386-CSW.pkg.gz' > ... > Checking 19 package(s) against catalog unstable sparc SunOS5.9 > ERROR: --catalog-release does not exist > Checking 19 package(s) against catalog unstable i386 SunOS5.9 > ERROR: --catalog-release does not exist > Checking 19 package(s) against catalog unstable sparc SunOS5.10 > ERROR: --catalog-release does not exist > Checking 19 package(s) against catalog unstable i386 SunOS5.10 > ERROR: --catalog-release does not exist > Checks failed for catalogs: > ... This should actually be solved now, but Dago will need to update the CSWcswutils that got batched last night on login. Dago, can you push that update as I don't have the rights? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Jun 6 03:47:43 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 05 Jun 2011 21:47:43 -0400 Subject: [csw-maintainers] time to deprecate CSWmozilla In-Reply-To: References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca> <1307123778-sup-3520@pinkfloyd.chass.utoronto.ca> <1307278894-sup-1960@pinkfloyd.chass.utoronto.ca> Message-ID: <1307324723-sup-7673@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sun Jun 05 13:03:53 -0400 2011: > so you're suggesting that from now on, no-one should ever bother > requesting anyone take over orphaned packages, becuase "if anyone > were interested in packaging them, they would have done so already". No, the request is fine and I don't mind waiting a week as you suggest. I'm just saying that we shouldn't let orphaned packages[1] impede work on things that people do actively care about. Thanks -Ben [1] Especially those that are known broken, have security issues and are at legacy versions. I would consider an orphaned but current package differently. -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Jun 6 03:58:08 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 05 Jun 2011 21:58:08 -0400 Subject: [csw-maintainers] gar and php question In-Reply-To: References: <4DEBB025.6010702@opencsw.org> Message-ID: <1307325421-sup-8953@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sun Jun 05 13:12:50 -0400 2011: > i think this is a reasonable thing to do. > and, no need to make it an "alternative". just make the link. We should look at dropping php4 at this point and moving php5 into the normal namespace. That's a big project though and I haven't quite finished the php5 update (I think it's done but I haven't tested after the last revision), so I don't want to add extra complexity just yet. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Jun 6 04:08:41 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 05 Jun 2011 22:08:41 -0400 Subject: [csw-maintainers] Rebuild of imagemagick In-Reply-To: <4DEC2BB3.9050007@opencsw.org> References: <4DE810E0.4050502@opencsw.org> <7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org> <4DEBD094.9080301@opencsw.org> <4DEC2BB3.9050007@opencsw.org> Message-ID: <1307325614-sup-4801@pinkfloyd.chass.utoronto.ca> Excerpts from John Ellson's message of Sun Jun 05 21:21:55 -0400 2011: > Probably its mostly the libxml2 issue now: > > current9s has CSWlibxml2-dev and a newer CSWlibxml2devel. I've just re-pushed the libxml2 dev packages to unstable so they'll be properly available in unstable. I will pop around and stuff them on by hand shortly too. I don't know why they weren't in the original set that was uploaded. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Jun 6 04:43:42 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 05 Jun 2011 22:43:42 -0400 Subject: [csw-maintainers] php5 broken In-Reply-To: <4DEBE3B5.4050904@opencsw.org> References: <4DEBE3B5.4050904@opencsw.org> Message-ID: <1307328137-sup-8660@pinkfloyd.chass.utoronto.ca> Excerpts from John Ellson's message of Sun Jun 05 16:14:45 -0400 2011: Hi John, > I just tried repackaging php5 with *no* changes. > > (I was investing how hard it would be to add a softlink: > /opt/csw/bin/php -> /opt/csw/php5/bin/php > ) > > Why would it even fail for "surplus-dependency" ? What harm is > there? I'm not sure what's going on with this and can't look tonight. I may have committed something wrong with this build description or ...? I'm pretty close to having php5 updated and I can add the symlink before it's released. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Jun 6 04:44:53 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 05 Jun 2011 22:44:53 -0400 Subject: [csw-maintainers] libxml2 broken In-Reply-To: <4DEC2D37.2010809@opencsw.org> References: <4DEBD2F3.8070808@opencsw.org> <4DEC251C.5060106@opencsw.org> <4DEC2D37.2010809@opencsw.org> Message-ID: <1307328238-sup-7520@pinkfloyd.chass.utoronto.ca> Excerpts from John Ellson's message of Sun Jun 05 21:28:23 -0400 2011: > We could fix CSWiconv or disable the test in CSWlibxml2 I'm not sure what's happening here as I don't recall the test suite having any failures when I last updated this package. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Jun 6 04:45:47 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 05 Jun 2011 22:45:47 -0400 Subject: [csw-maintainers] [csw-buildfarm] pkg-config failure unstable9[xs] In-Reply-To: References: <4DEA6CFC.7060500@opencsw.org> <1307232386-sup-7830@pinkfloyd.chass.utoronto.ca> <4DEB84E7.3030609@opencsw.org> Message-ID: <1307328323-sup-2858@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Sun Jun 05 09:55:04 -0400 2011: > Ben: Would you mind having a look and re-release the devel package? Done. The unstable* hosts were updated too. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Jun 6 04:46:15 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 05 Jun 2011 22:46:15 -0400 Subject: [csw-maintainers] [csw-buildfarm] pkg-config failure unstable9[xs] In-Reply-To: References: <4DEA6CFC.7060500@opencsw.org> <1307232386-sup-7830@pinkfloyd.chass.utoronto.ca> <4DEB84E7.3030609@opencsw.org> <4DEB9555.7040107@opencsw.org> Message-ID: <1307328358-sup-8886@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sun Jun 05 13:07:49 -0400 2011: > it would be better if these were removed. they are probably messing > things up. I'll do this tomorrow unless Dago beats me to it. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Mon Jun 6 05:36:19 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 5 Jun 2011 20:36:19 -0700 Subject: [csw-maintainers] [csw-buildfarm] Rebuild of imagemagick In-Reply-To: References: <4DE810E0.4050502@opencsw.org> <7DAE16D0-33E8-45DE-A387-0B1F09925429@opencsw.org> <4DEBD094.9080301@opencsw.org> Message-ID: John has made a reasonable request to the buildfarm maintainers. twice now. Are you folks going to ignore buildfarm requests for the non-"unstable" machines now? From phil at bolthole.com Mon Jun 6 05:40:17 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 5 Jun 2011 20:40:17 -0700 Subject: [csw-maintainers] gar and php question In-Reply-To: <1307325421-sup-8953@pinkfloyd.chass.utoronto.ca> References: <4DEBB025.6010702@opencsw.org> <1307325421-sup-8953@pinkfloyd.chass.utoronto.ca> Message-ID: On Sun, Jun 5, 2011 at 6:58 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Sun Jun 05 13:12:50 -0400 2011: > >> i think this is a reasonable thing to do. >> and, no need to make it an "alternative". just make the link. > > We should look at dropping php4 at this point and moving php5 into the > normal namespace. i'm not sure that that serves any useful purpose, other than /opt/csw/bin/php I think adding the symlink, effectively accomplishes "moving php5 into the normal namespace" Methinks that any auto-detect stuff will most likely invoke "php (some command" to determine location and flags for things. From skayser at opencsw.org Mon Jun 6 08:55:05 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 6 Jun 2011 08:55:05 +0200 Subject: [csw-maintainers] Further improvements to our website In-Reply-To: References: <4DE3F9E8.7020303@wbonnet.net> Message-ID: <20110606065505.GJ29708@sebastiankayser.de> * Maciej Blizi??ski wrote: > I've installed our apache, php and mysql. I can run phpinfo() - it > works. What doesn't work, is installing mantis. When enter the top > level link, I'm redirected to admin/install.php, and all I see is a > blank page. I ran into the same issue. Tried Mantis 1.2.5 (latest) and 1.2.4 (just to double check) and it wasn't until I hit admin/check.php that I saw session module related errors. Installing the PHP5 session module helped in my case. pkgutil -i php5_session Can you check whether it does the job for you too? If so, I am going to uninstall it again on my box, verify the issue, and report a bug upstream. Sebastian From skayser at opencsw.org Mon Jun 6 10:01:15 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 6 Jun 2011 10:01:15 +0200 Subject: [csw-maintainers] Further improvements to our website In-Reply-To: <20110606065505.GJ29708@sebastiankayser.de> References: <4DE3F9E8.7020303@wbonnet.net> <20110606065505.GJ29708@sebastiankayser.de> Message-ID: <20110606080114.GK29708@sebastiankayser.de> * Sebastian Kayser wrote: > * Maciej Blizi??ski wrote: > > I've installed our apache, php and mysql. I can run phpinfo() - it > > works. What doesn't work, is installing mantis. When enter the top > > level link, I'm redirected to admin/install.php, and all I see is a > > blank page. > > I ran into the same issue. Tried Mantis 1.2.5 (latest) and 1.2.4 (just > to double check) and it wasn't until I hit admin/check.php that I saw > session module related errors. Installing the PHP5 session module helped > in my case. > > pkgutil -i php5_session Adding to this: what made debugging hard is the use of the @ operator in install.php which - as I just learnt - suppresses even critical errors, leaving no indication as to why a script terminates early [1]. Removing this operator (for the core.php inclusion) should help to identify the culprit [2]. Sebastian [1] http://php.net/manual/en/language.operators.errorcontrol.php [2] http://paste.pocoo.org/show/401482/ From ellson at opencsw.org Mon Jun 6 12:17:57 2011 From: ellson at opencsw.org (John Ellson) Date: Mon, 06 Jun 2011 06:17:57 -0400 Subject: [csw-maintainers] graphviz builds - build farm requests Message-ID: <4DECA955.9020408@opencsw.org> I see graphvizdevel installed on unstable9s, but that imagemagick is still installed. How did that happen? I thought there was a dependency from imagemagick on libgvc.so from graphviz-2.26.3 ? Doesn't pkg-get or pkgutil check? 1) Could you install graphvizdevel on unstable9x as well? (I only have resources for testing on i386 architecture here). 2) Please uninstall imagemagick from unstable9[sx] while I rebuild. I still think libtool gets confused if old copies of the package's .so are still installed. I currently get this error when building imagemagick on unstable8s I think because its picking up the old libs. libtool: link: /opt/SUNWspro/bin/cc -G -z defs -M coders/.libs/svg.so.exp -h svg.so -o coders/.libs/svg.so coders/.libs/coders_svg_la-svg.o -R/home/ellson/mgar/pkg/ImageMagick/trunk/work/solaris9-sparc/build-isa-sparcv8/ImageMagick-6.6.0-9/magick/.libs -R/home/ellson/mgar/pkg/ImageMagick/trunk/work/solaris9-sparc/build-isa-sparcv8/ImageMagick-6.6.0-9/wand/.libs -R/opt/csw/lib -R/opt/csw/X11/lib -L/home/ellson/mgar/pkg/ImageMagick/trunk/work/solaris9-sparc/build-isa-sparcv8/ImageMagick-6.6.0-9/magick/.libs -L/home/ellson/mgar/pkg/ImageMagick/trunk/work/solaris9-sparc/build-isa-sparcv8/ImageMagick-6.6.0-9/wand/.libs -L/opt/csw/X11/lib -L/opt/csw/lib magick/.libs/libMagickCore.so wand/.libs/libMagickWand.so /home/ellson/mgar/pkg/ImageMagick/trunk/work/solaris9-sparc/build-isa-sparcv8/ImageMagick-6.6.0-9/magick/.libs/libMagickCore.so -llcms -ltiff -lfreetype -ljpeg -llqr-1 -lfontconfig -lXext -lXt -lbz2 -lltdl -lSM -lICE -lX11 -lsocket -lnsl -lmtsk -lrsvg-2 -lgdk_pixbuf-2.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lpthread -lthread -lrt -lglib-2.0 -lintl -lxml2 -lz -lm -lc -m32 -xarch=v8 -Wl,-zlazyload -m32 -xarch=v8 ld: warning: file /home/ellson/mgar/pkg/ImageMagick/trunk/work/solaris9-sparc/build-isa-sparcv8/ImageMagick-6.6.0-9/magick/.libs/libMagickCore.so: linked to magick/.libs/libMagickCore.so: attempted multiple inclusion of file Undefined first referenced symbol in file XSolarisIASetProcessInfo /lib/libX11.so.4 ld: fatal: Symbol referencing errors. No output written to coders/.libs/svg.so gmake[3]: *** [coders/svg.la] Error 1 After I get imagemagick to build and package on unstable9[sx], do I still need to build and package on current9[sx] ? John From dam at opencsw.org Mon Jun 6 14:03:57 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 6 Jun 2011 14:03:57 +0200 Subject: [csw-maintainers] graphviz builds - build farm requests In-Reply-To: <4DECA955.9020408@opencsw.org> References: <4DECA955.9020408@opencsw.org> Message-ID: <8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org> Hi John, Am 06.06.2011 um 12:17 schrieb John Ellson: > I see graphvizdevel installed on unstable9s, but that imagemagick is > still installed. How did that happen? I would say this is normal as CSWimagemagick depends on CSWgraphviz, but not CSWgraphvizdevel. > I thought there was a dependency > from imagemagick on libgvc.so from graphviz-2.26.3 ? Doesn't pkg-get > or pkgutil check? They check explicit package dependencies when set, but the dependency is more defined as above. > 1) Could you install graphvizdevel on unstable9x as well? (I only have > resources for testing on i386 architecture here). I have uninstalled CSWgraphvizdevel on all unstable* hosts now. > 2) Please uninstall imagemagick from unstable9[sx] while I rebuild. Uninstalled from all unstable* hosts. > After I get imagemagick to build and package on unstable9[sx], do I > still need to build and package on current9[sx] ? It is recommended ATM, but if you make sure that it works with the versions in current a direct release to unstable should be no problem. 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 Mon Jun 6 15:05:12 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 06 Jun 2011 09:05:12 -0400 Subject: [csw-maintainers] gar and php question In-Reply-To: References: <4DEBB025.6010702@opencsw.org> <1307325421-sup-8953@pinkfloyd.chass.utoronto.ca> Message-ID: <1307365421-sup-6666@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sun Jun 05 23:40:17 -0400 2011: > i'm not sure that that serves any useful purpose, other than > /opt/csw/bin/php I think adding the symlink, effectively > accomplishes "moving php5 into the normal namespace" Well, it is useful as php4 is not supported upstream and we have the supported branch (although even our php5 version is unsupported now until I get the update finished). Removing it from the catalog won't prevent those that want it from getting it, but we should make those people 'work' for it and not provide some pretense that it's a supported package. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From ellson at opencsw.org Mon Jun 6 15:35:23 2011 From: ellson at opencsw.org (John Ellson) Date: Mon, 06 Jun 2011 09:35:23 -0400 Subject: [csw-maintainers] graphviz builds - build farm requests In-Reply-To: <8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org> References: <4DECA955.9020408@opencsw.org> <8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org> Message-ID: <4DECD79B.90601@opencsw.org> >> 1) Could you install graphvizdevel on unstable9x as well? (I only have >> resources for testing on i386 architecture here). > I have uninstalled CSWgraphvizdevel on all unstable* hosts now. > No, please *install* graphvizdevel-2.28.0 ons unstable9s and unstable9x. graphviz is built. Now I need graphvizdevel for building imagemagick. John From maciej at opencsw.org Mon Jun 6 15:39:32 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 6 Jun 2011 14:39:32 +0100 Subject: [csw-maintainers] Further improvements to our website In-Reply-To: <20110606065505.GJ29708@sebastiankayser.de> References: <4DE3F9E8.7020303@wbonnet.net> <20110606065505.GJ29708@sebastiankayser.de> Message-ID: 2011/6/6 Sebastian Kayser : > * Maciej Blizi??ski wrote: >> I've installed our apache, php and mysql. ?I can run phpinfo() - it >> works. ?What doesn't work, is installing mantis. ?When enter the top >> level link, I'm redirected to admin/install.php, and all I see is a >> blank page. > > I ran into the same issue. Tried Mantis 1.2.5 (latest) and 1.2.4 (just > to double check) and it wasn't until I hit admin/check.php that I saw > session module related errors. Installing the PHP5 session module helped > in my case. > > ?pkgutil -i php5_session > > Can you check whether it does the job for you too? If so, I am going to > uninstall it again on my box, verify the issue, and report a bug > upstream. Yes, that was the problem. I wouldn't think that you could suppress error reporting to such a high degree. I understand that it makes sense to suppress errors sent to the browser - you might want to avoid revealing internal server information. But why suppress errors sent to a log file? Thanks for the help! Maciej From dam at opencsw.org Mon Jun 6 15:40:43 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 6 Jun 2011 15:40:43 +0200 Subject: [csw-maintainers] libxml2 broken In-Reply-To: <4DEC2D37.2010809@opencsw.org> References: <4DEBD2F3.8070808@opencsw.org> <4DEC251C.5060106@opencsw.org> <4DEC2D37.2010809@opencsw.org> Message-ID: <65D204EA-6681-4CAD-87C7-D383CD6E1875@opencsw.org> Hi John, Am 06.06.2011 um 03:28 schrieb John Ellson: > On 06/05/2011 08:55 PM, Maciej Blizi?ski wrote: >> 2011/6/6 John Ellson : >>> On 06/05/2011 08:36 PM, Maciej Blizi?ski wrote: >>>> 2011/6/5 John Ellson : >>>>> Trying to repackage libxml2 from trunk, with *no* changes, fails because >>>>> of test failures during "make package" > > The test failures are only from test/ebcdic_566012.xml. If that test > is removed, "make check" succeeds. > > I suspect the problem is that CSWiconv doesn't have EBCDIC support: > > ellson at current9s:ellson> iconv -l | grep -i ebcdic > ellson at current9s:ellson> > > We could fix CSWiconv or disable the test in CSWlibxml2 Always good to keep the eyes open. I just looked at the libiconv recipe and "NOTES" from libiconv-1.13.1 says Q: Support EBCDIC ? A: No! However, the packaged and released libxml2 2.7.8 does also not pass this test. Ben: Do you want to report this upstream? Best regards -- Dago From dam at opencsw.org Mon Jun 6 15:46:59 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 6 Jun 2011 15:46:59 +0200 Subject: [csw-maintainers] graphviz builds - build farm requests In-Reply-To: <4DECD79B.90601@opencsw.org> References: <4DECA955.9020408@opencsw.org> <8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org> <4DECD79B.90601@opencsw.org> Message-ID: <5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org> Hi John, Am 06.06.2011 um 15:35 schrieb John Ellson: >>> 1) Could you install graphvizdevel on unstable9x as well? (I only have >>> resources for testing on i386 architecture here). >> I have uninstalled CSWgraphvizdevel on all unstable* hosts now. > > No, please *install* graphvizdevel-2.28.0 ons unstable9s and unstable9x. > > graphviz is built. Now I need graphvizdevel for building imagemagick. Ahhhh, sorry. Doing this now. This gave the following errors on current9s: > => Installing CSWgraphviz-2.28.0,REV=2011.06.05 (8/9) ... > Please see /opt/csw/share/doc/graphviz/license for license information. > > dot -c is running now to record available graphviz plugins. > > Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found > Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found > > Installation of was successful. > > => Installing CSWgraphvizdevel-2.28.0,REV=2011.06.05 (9/9) ... > ... 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 ellson at opencsw.org Mon Jun 6 16:20:33 2011 From: ellson at opencsw.org (John Ellson) Date: Mon, 06 Jun 2011 10:20:33 -0400 Subject: [csw-maintainers] graphviz builds - build farm requests In-Reply-To: <5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org> References: <4DECA955.9020408@opencsw.org> <8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org> <4DECD79B.90601@opencsw.org> <5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org> Message-ID: <4DECE231.7010804@opencsw.org> On 06/06/2011 09:46 AM, Dagobert Michelsen wrote: > >> => Installing CSWgraphviz-2.28.0,REV=2011.06.05 (8/9) ... >> Please see /opt/csw/share/doc/graphviz/license for license information. >> >> dot -c is running now to record available graphviz plugins. >> >> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found >> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found >> >> Installation of was successful. >> >> => Installing CSWgraphvizdevel-2.28.0,REV=2011.06.05 (9/9) ... >> ... > Do you see the same errors on current9x ? I'm guessing no, because it installs on my home box ok. From dam at opencsw.org Mon Jun 6 16:44:10 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 6 Jun 2011 16:44:10 +0200 Subject: [csw-maintainers] graphviz builds - build farm requests In-Reply-To: <4DECE231.7010804@opencsw.org> References: <4DECA955.9020408@opencsw.org> <8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org> <4DECD79B.90601@opencsw.org> <5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org> <4DECE231.7010804@opencsw.org> Message-ID: <110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org> Hi John, Am 06.06.2011 um 16:20 schrieb John Ellson: > On 06/06/2011 09:46 AM, Dagobert Michelsen wrote: >> >>> => Installing CSWgraphviz-2.28.0,REV=2011.06.05 (8/9) ... >>> Please see /opt/csw/share/doc/graphviz/license for license information. >>> >>> dot -c is running now to record available graphviz plugins. >>> >>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found >>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found >>> >>> Installation of was successful. >>> >>> => Installing CSWgraphvizdevel-2.28.0,REV=2011.06.05 (9/9) ... >>> ... >> > > Do you see the same errors on current9x ? I'm guessing no, because > it installs on my home box ok. In fact I do: > *** Installing on unstable9x > => Fetching new catalog and descriptions (http://mirror/opencsw-future/unstable/i386/5.9) if available ... > --2011-06-06 15:45:40-- http://mirror/opencsw-future/unstable/i386/5.9/catalog > Resolving proxy... 192.168.1.6 > Connecting to proxy|192.168.1.6|:3128... connected. > Proxy request sent, awaiting response... 200 OK > Length: 588293 (575K) [text/plain] > Saving to: `/var/opt/csw/pkgutil/catalog.mirror_opencsw-future_unstable_i386_5.9.tmp' > > 0K .......... .......... .......... .......... .......... 8% 7.02M 0s > 50K .......... .......... .......... .......... .......... 17% 10.7M 0s > 100K .......... .......... .......... .......... .......... 26% 11.0M 0s > 150K .......... .......... .......... .......... .......... 34% 12.4M 0s > 200K .......... .......... .......... .......... .......... 43% 10.3M 0s > 250K .......... .......... .......... .......... .......... 52% 10.5M 0s > 300K .......... .......... .......... .......... .......... 60% 11.9M 0s > 350K .......... .......... .......... .......... .......... 69% 11.4M 0s > 400K .......... .......... .......... .......... .......... 78% 10.7M 0s > 450K .......... .......... .......... .......... .......... 87% 11.2M 0s > 500K .......... .......... .......... .......... .......... 95% 10.7M 0s > 550K .......... .......... .... 100% 11.6M=0.05s > > 2011-06-06 15:45:40 (10.5 MB/s) - `/var/opt/csw/pkgutil/catalog.mirror_opencsw-future_unstable_i386_5.9.tmp' saved [588293/588293] > > --2011-06-06 15:45:40-- http://mirror/opencsw-future/unstable/i386/5.9/descriptions > Resolving proxy... 192.168.1.6 > Connecting to proxy|192.168.1.6|:3128... connected. > Proxy request sent, awaiting response... 200 OK > Length: 169252 (165K) [text/plain] > Saving to: `/var/opt/csw/pkgutil/descriptions.mirror_opencsw-future_unstable_i386_5.9.tmp' > > 0K .......... .......... .......... .......... .......... 30% 6.86M 0s > 50K .......... .......... .......... .......... .......... 60% 10.8M 0s > 100K .......... .......... .......... .......... .......... 90% 10.9M 0s > 150K .......... ..... 100% 14.3M=0.02s > > 2011-06-06 15:45:40 (9.40 MB/s) - `/var/opt/csw/pkgutil/descriptions.mirror_opencsw-future_unstable_i386_5.9.tmp' saved [169252/169252] > > ==> 3026 packages loaded from /var/opt/csw/pkgutil/catalog.mirror_opencsw-future_unstable_i386_5.9 > Solving needed dependencies ... > Solving dependency order ... > Install 2 NEW packages: CSWgraphviz-2.28.0,REV=2011.06.05 CSWgraphvizdevel-2.28.0,REV=2011.06.05 > Install 7 UPDATED packages: CSWlibcdt5-2.28.0,REV=2011.06.05 CSWlibcgraph6-2.28.0,REV=2011.06.05 CSWlibgraph5-2.28.0,REV=2011.06.05 CSWlibgvc6-2.28.0,REV=2011.06.05 CSWlibgvpr2-2.28.0,REV=2011.06.05 CSWlibpathplan4-2.28.0,REV=2011.06.05 CSWlibxdot4-2.28.0,REV=2011.06.05 > 93 CURRENT packages: CSWbonobo2-2.24.3,REV=2010.06.25 CSWbzip2-1.0.6,REV=2010.09.21 CSWcacertificates-20091101,REV=2009.11.01 CSWcas-cpsampleconf-1.42,REV=2010.11.26 CSWcas-crontab-1.42,REV=2010.11.26 CSWcas-etcservices-1.42,REV=2011.02.16 CSWcas-inetd-1.42,REV=2010.11.26 CSWcas-initsmf-1.44,REV=2011.04.21 CSWcas-migrateconf-1.42,REV=2010.11.26 CSWcas-postmsg-1.42,REV=2010.11.26 CSWcas-preserveconf-1.42,REV=2010.11.26 CSWcas-pycompile-1.42,REV=2010.11.26 CSWcas-texinfo-1.42,REV=2010.11.26 CSWcas-usergroup-1.42,REV=2010.11.26 CSWcommon-1.5,REV=2010.12.11 CSWcswclassutils-1.42,REV=2010.11.26 CSWdbusglib-0.86,REV=2010.07.04 CSWexpat-2.0.1,REV=2009.01.22 CSWfam-2.70,REV=2010.06.15 CSWfconfig-2.6.0,REV=2009.04.24 CSWftype2-2.4.2,REV=2010.08.19 CSWgamin-0.1.9,REV=2010.06.15 CSWgcc4corert-4.3.3,REV=2009.05.07 CSWgcc4g++rt-4.3.3,REV=2009.05.07 CSWgconf2-2.28.1,REV=2010.06.26 CSWgcrypt-1.4.6,REV=2010.08.19 CSWggettext-0.18.1.1,p,REV=2011.03.15 CSWggettext-data-0.18.1.1,p,REV=2011.03.15 CSWggettextrt-0.18.1.1,p,REV=2011.03.15 CSWglib2-2.23.5,REV=2010.03.09 CSWgnomevfs2-2.21.90 CSWgnutls-2.10.4,REV=2011.01.18 CSWgpgerr-1.9,REV=2010.09.16 CSWgs-8.71,REV=2010.03.23 CSWgsfonts-8.11 CSWgtk2-2.18.9,REV=2010.06.07 CSWgts-0.7.6,REV=2009.05.20 CSWiconv-1.13.1,REV=2009.07.31 CSWisaexec-0.2,REV=2009.03.26 CSWjbig2dec-0.11,REV=2010.05.17 CSWjbigkit-2.0,REV=2008.10.28 CSWjpeg-7,REV=2009.08.17 CSWkrb5lib-1.4.4,REV=2006.12.27 CSWlibasprintf0-0.18.1.1,p,REV=2011.03.15 CSWlibatk-1.30.0,REV=2010.05.06 CSWlibcairo-1.8.10,REV=2010.06.07 CSWlibcroco-0.6.2,REV=2009.10.09 CSWlibcups-1.4.5,REV=2010.12.24 CSWlibcups2-1.4.5,REV=2010.12.24 CSWlibcupscgi1-1.4.5,REV=2010.12.24 CSWlibcupsdriver1-1.4.5,REV=2010.12.24 CSWlibcupsimage2-1.4.5,REV=2010.12.24 CSWlibcupsmime1-1.4.5,REV=2010.12.24 CSWlibcupsppdc1-1.4.5,REV=2010.12.24 CSWlibdbus-1.3.1,REV=2010.07.04 CSWlibgettextlib0-14-1-0.18.1.1,p,REV=2011.02.12 CSWlibgettextlib0-17-0.18.1.1,p,REV=2011.02.12 CSWlibgettextlib0-18-1-0.18.1.1,p,REV=2011.02.12 CSWlibgettextpo0-0.18.1.1,p,REV=2011.02.12 CSWlibgettextsrc0-18-1-0.18.1.1,p,REV=2011.02.12 CSWlibgnutls13-2.0.4,REV=2011.01.18 CSWlibgnutls26-2.10.4,REV=2011.01.18 CSWlibgsf-1.9.1 CSWlibidl-0.8.14,REV=2010.03.31 CSWlibintl2-0.18.1.1,p,REV=2011.02.12 CSWlibintl3-0.18.1.1,p,REV=2011.02.12 CSWlibintl8-0.18.1.1,p,REV=2011.03.15 CSWliblasi-1.1.0,REV=2009.05.28 CSWlibltdl7-2.4,REV=2011.04.20 CSWlibpixman1-0-0.21.4,REV=2011.02.02 CSWlibpopt-1.15,REV=2009.10.29 CSWlibrsvg-2.26.0,REV=2009.12.20 CSWlibtasn1-3-2.9,REV=2011.05.05 CSWlibxft2-2.1.14,REV=2010.06.07 CSWlibxml2-2-2.7.8,REV=2011.03.24 CSWlibxml2-2.7.8,REV=2011.03.21 CSWlibxml2devel-2.7.8,REV=2011.03.24 CSWlibxrender-0.9.5,REV=2010.05.20 CSWncurses-5.7,REV=2010.05.21 CSWorbit2-2.14.18,REV=2010.03.31 CSWossl-0.9.8r,REV=2011.02.12 CSWossldevel-0.9.8r,REV=2011.02.12 CSWosslrt-0.9.8r,REV=2011.02.12 CSWosslutils-0.9.8r,REV=2011.02.12 CSWpango-1.28.0,REV=2010.06.07 CSWpixman-0.21.4,REV=2011.02.02 CSWpng-1.2.44,REV=2010.06.28 CSWreadline-6.1,REV=2010.01.01 CSWsunmath-2007.08.04 CSWterminfo-5.7,REV=2010.05.21 CSWtiff-3.9.4,REV=2010.07.05 CSWxpm-3.5.8,REV=2010.05.24 CSWzlib-1.2.5,REV=2010.09.22 > ... > => Installing CSWlibgvpr2-2.28.0,REV=2011.06.05 (7/9) ... > Please see /opt/csw/share/doc/libgvpr2/license for license information. > > Installation of was successful. > > => Installing CSWgraphviz-2.28.0,REV=2011.06.05 (8/9) ... > Please see /opt/csw/share/doc/graphviz/license for license information. > > dot -c is running now to record available graphviz plugins. > > Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found > Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found > Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found > Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found > Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found > Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found > Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found > Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found > > Installation of was successful. > > => Installing CSWgraphvizdevel-2.28.0,REV=2011.06.05 (9/9) ... > Please see /opt/csw/share/doc/graphvizdevel/license for license information. > > Installation of was successful. 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 ellson at opencsw.org Mon Jun 6 17:39:24 2011 From: ellson at opencsw.org (John Ellson) Date: Mon, 06 Jun 2011 11:39:24 -0400 Subject: [csw-maintainers] pkg-config setup for X11 ? In-Reply-To: <110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org> References: <4DECA955.9020408@opencsw.org> <8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org> <4DECD79B.90601@opencsw.org> <5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org> <4DECE231.7010804@opencsw.org> <110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org> Message-ID: <4DECF4AC.9070503@opencsw.org> What is the correct PKG_CONFIG_PATH these days, particularly for X11 ? I currently have: ellson at unstable9s:ellson> echo $PKG_CONFIG_PATH /opt/csw/lib/pkgconfig:/opt/csw/X11/lib/pkgconfig But this yields: ellson at unstable9s:ellson> pkg-config --libs x11 -L/opt/csw/lib -lX11 which does not provide the -L /usr/openwin/lib -lXext needed by, e.g. /opt/csw/lib/libcairo.so ellson at unstable9s:ellson> ldd /opt/csw/lib/libcairo.so | grep X libXrender.so.1 => /opt/csw/lib/sparcv8/libXrender.so.1 libX11.so.4 => /usr/lib/libX11.so.4 libXext.so.0 => /usr/openwin/lib/libXext.so.0 From phil at bolthole.com Mon Jun 6 19:07:49 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 6 Jun 2011 10:07:49 -0700 Subject: [csw-maintainers] pkg-config setup for X11 ? In-Reply-To: <4DECF4AC.9070503@opencsw.org> References: <4DECA955.9020408@opencsw.org> <8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org> <4DECD79B.90601@opencsw.org> <5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org> <4DECE231.7010804@opencsw.org> <110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org> <4DECF4AC.9070503@opencsw.org> Message-ID: On Mon, Jun 6, 2011 at 8:39 AM, John Ellson wrote: > What is the correct PKG_CONFIG_PATH these days, particularly for X11 ? > > > I currently have: > > ? ?ellson at unstable9s:ellson> echo $PKG_CONFIG_PATH > ? ?/opt/csw/lib/pkgconfig:/opt/csw/X11/lib/pkgconfig This is fatally wrong. Remove PKG_CONFIG_PATH completely. Then make sure that sunx11_devel is installed. That hacks in pkgconfig knowlege of x11, xext, xproto, and a few other things. From phil at bolthole.com Mon Jun 6 19:09:57 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 6 Jun 2011 10:09:57 -0700 Subject: [csw-maintainers] gar and php question In-Reply-To: <1307365421-sup-6666@pinkfloyd.chass.utoronto.ca> References: <4DEBB025.6010702@opencsw.org> <1307325421-sup-8953@pinkfloyd.chass.utoronto.ca> <1307365421-sup-6666@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Jun 6, 2011 at 6:05 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Sun Jun 05 23:40:17 -0400 2011: > >> i'm not sure that that serves any useful purpose, other than >> /opt/csw/bin/php I think adding the symlink, effectively >> accomplishes "moving php5 into the normal namespace" > > Well, it is useful as php4 is not supported upstream and we have the > supported branch (although even our php5 version is unsupported now > until I get the update finished). ?Removing it from the catalog won't > prevent those that want it from getting it, but we should make those > people 'work' for it why? > and not provide some pretense that it's a supported package. we have plenty of packages that are no longer "supported" (ie: orphaned), but we still keep available. What specific problem does it solve to remove php4 from our catalog? From bwalton at opencsw.org Mon Jun 6 19:53:16 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 06 Jun 2011 13:53:16 -0400 Subject: [csw-maintainers] gar and php question In-Reply-To: References: <4DEBB025.6010702@opencsw.org> <1307325421-sup-8953@pinkfloyd.chass.utoronto.ca> <1307365421-sup-6666@pinkfloyd.chass.utoronto.ca> Message-ID: <1307382737-sup-3595@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Jun 06 13:09:57 -0400 2011: > > Well, it is useful as php4 is not supported upstream and we have > > the supported branch (although even our php5 version is > > unsupported now until I get the update finished). ?Removing it > > from the catalog won't prevent those that want it from getting it, > > but we should make those people 'work' for it > > why? Because they can file bugs on it or expect some level of response from us because it's in the catalog. > > and not provide some pretense that it's a supported package. > > we have plenty of packages that are no longer "supported" (ie: > orphaned), but we still keep available. What specific problem does > it solve to remove php4 from our catalog? It's legacy software (as deemed by the upstream). What benefit is there in retaining it? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Mon Jun 6 20:10:56 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 6 Jun 2011 19:10:56 +0100 Subject: [csw-maintainers] graphviz builds - build farm requests In-Reply-To: <4DECE231.7010804@opencsw.org> References: <4DECA955.9020408@opencsw.org> <8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org> <4DECD79B.90601@opencsw.org> <5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org> <4DECE231.7010804@opencsw.org> Message-ID: 2011/6/6 John Ellson : > On 06/06/2011 09:46 AM, Dagobert Michelsen wrote: >> >>> => Installing CSWgraphviz-2.28.0,REV=2011.06.05 (8/9) ... >>> Please see /opt/csw/share/doc/graphviz/license for license information. >>> >>> dot -c is running now to record available graphviz plugins. >>> >>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found >>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found >>> >>> Installation of was successful. >>> >>> => Installing CSWgraphvizdevel-2.28.0,REV=2011.06.05 (9/9) ... >>> ... >> > Do you see the same errors on current9x ? ? ? ?I'm guessing no, because > it installs on my home box ok. Looking at the package metadata: http://buildfarm.opencsw.org/pkgdb/srv4/a8cd2d66ee68ee509d749f16dd52d143/ The libgvplugin_lasi.so.6 is provided by the same package as the binary. I don't quite understand why would this shared library be not found during runtime. From phil at bolthole.com Mon Jun 6 20:20:02 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 6 Jun 2011 11:20:02 -0700 Subject: [csw-maintainers] gar and php question In-Reply-To: <1307382737-sup-3595@pinkfloyd.chass.utoronto.ca> References: <4DEBB025.6010702@opencsw.org> <1307325421-sup-8953@pinkfloyd.chass.utoronto.ca> <1307365421-sup-6666@pinkfloyd.chass.utoronto.ca> <1307382737-sup-3595@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Jun 6, 2011 at 10:53 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Mon Jun 06 13:09:57 -0400 2011: > >> > Well, it is useful as php4 is not supported upstream and we have >> > the supported branch (although even our php5 version is >> > unsupported now until I get the update finished). ?Removing it >> > from the catalog won't prevent those that want it from getting it, >> > but we should make those people 'work' for it >> >> why? > > Because they can file bugs on it or expect some level of response from > us because it's in the catalog. again, this is no different from our many other packages that are orphaned, and people will get no response from doing that on those either :-/ >> we have plenty of packages that are no longer "supported" (ie: >> orphaned), but we still keep available. ?What specific problem does >> it solve to remove php4 from our catalog? > > It's legacy software (as deemed by the upstream). ?What benefit is > there in retaining it? okay, that's a better reason to consider removing it. But that being said.. we ARE sometimes in the "business" of providing "legacy" frameworks. Doing a bit of digging, it appears we agreed on the following, back in 2009: >> it doesnt look like there are any dependancies of OURS that use it. >> However, it would need to be carefully announced ahead of time to users. > >Agreed. > >-Ben So, please go ahead and announce , that we plan to remove it within [insert timeframe here]. (and to holler if this for some reason is a problem for someone, and why) And then after that time, we can remove it. Since this is by definition extreme legacy software, the people may not keep up to date with announcements, etc :-} so we may want to set a somewhat longer timeframe than would otherwise be fine. July 1st? From ellson at opencsw.org Mon Jun 6 20:30:25 2011 From: ellson at opencsw.org (John Ellson) Date: Mon, 06 Jun 2011 14:30:25 -0400 Subject: [csw-maintainers] graphviz builds - build farm requests In-Reply-To: References: <4DECA955.9020408@opencsw.org> <8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org> <4DECD79B.90601@opencsw.org> <5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org> <4DECE231.7010804@opencsw.org> Message-ID: <4DED1CC1.3030409@opencsw.org> On 06/06/2011 02:10 PM, Maciej Blizi?ski wrote: > 2011/6/6 John Ellson : >> On 06/06/2011 09:46 AM, Dagobert Michelsen wrote: >>>> => Installing CSWgraphviz-2.28.0,REV=2011.06.05 (8/9) ... >>>> Please see /opt/csw/share/doc/graphviz/license for license information. >>>> >>>> dot -c is running now to record available graphviz plugins. >>>> >>>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found >>>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found >>>> >>>> Installation of was successful. >>>> >>>> => Installing CSWgraphvizdevel-2.28.0,REV=2011.06.05 (9/9) ... >>>> ... >> Do you see the same errors on current9x ? I'm guessing no, because >> it installs on my home box ok. > Looking at the package metadata: > > http://buildfarm.opencsw.org/pkgdb/srv4/a8cd2d66ee68ee509d749f16dd52d143/ > > The libgvplugin_lasi.so.6 is provided by the same package as the > binary. I don't quite understand why would this shared library be not > found during runtime. Maciej, I don't either understand either. Also its working on my Solaris-10-i386 box at home. I suspect the message is a bit misleading. The failure is occuring because libgvplugin_lasi.so.6 can't be loaded, but it might be one of the libs used by the plugin that is "file not found" I don't see any problems with "ldd libgvplugin_lasi.so.6", but perhaps root's environment that is different? Unfortunately I can't debug because "dot -c" needs to run as root in order to write /opt/csw/lib/graphviz/config6 If you had a chance to run "dot -c" under gdb as root to see whats happening, that would be really helpful? John From ellson at opencsw.org Mon Jun 6 20:46:46 2011 From: ellson at opencsw.org (John Ellson) Date: Mon, 06 Jun 2011 14:46:46 -0400 Subject: [csw-maintainers] request for packages on unstable9[sx] Message-ID: <4DED2096.4020607@opencsw.org> I'm going backwards, and accelerating :-( The ImageMagic build is failing with: Undefined first referenced symbol in file XSolarisIASetProcessInfo /lib/libX11.so.4 I believe the reference is coming from librsvg-2.so, so I'm trying to repackage that. Request: Please install: CSWmozilla on unstable9[sx] for librsvg rebuild. From phil at bolthole.com Mon Jun 6 20:48:34 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 6 Jun 2011 11:48:34 -0700 Subject: [csw-maintainers] initialization problem: struct + union In-Reply-To: <20110605.8241300.1660397962@gyor.oxdrove.co.uk> References: <20110605.8241300.1660397962@gyor.oxdrove.co.uk> Message-ID: On Sun, Jun 5, 2011 at 1:24 AM, James Lee wrote: > > $ cc test.c > "test.c", line 16: warning: improper pointer/integer combination: op "=" > $ ./a.out > snmp_timeout: 2 > snmp_message: time out exceeded > > Thanks for following through all the way to a test case. I had actually tried that type of mod, but I guess I overreacted when I saw "improper pointer/integer combination" and didnt notice it was only a "warning" :-} real program (mbrowse) now compiles fine. From dam at opencsw.org Mon Jun 6 21:32:55 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 6 Jun 2011 21:32:55 +0200 Subject: [csw-maintainers] [csw-buildfarm] request for packages on unstable9[sx] In-Reply-To: <4DED2096.4020607@opencsw.org> References: <4DED2096.4020607@opencsw.org> Message-ID: Hi John, Am 06.06.2011 um 20:46 schrieb John Ellson: > I'm going backwards, and accelerating :-( > > The ImageMagic build is failing with: > Undefined first referenced > symbol in file > XSolarisIASetProcessInfo /lib/libX11.so.4 > > I believe the reference is coming from librsvg-2.so, so I'm trying to > repackage that. I don't think so, as "ldd -r librsvg-2.so" does not link to libX11.so.6. The linkage to libX11.so.4 is the correct one. The error is caused by applications being linked to libX11.so.6 which however pull in libX11.so.4 earlier by another dependency. > Request: Please install: CSWmozilla on unstable9[sx] for librsvg rebuild. Apart from the above comment I cannot see CSWmozilla as a dependency on http://www.opencsw.org/package/librsvg/ John, from my impression you are moving too fast shooting at everything that doesn't immediately jump away :-) I suggest you come over to #opencsw so we can investigate the problem ground up logically. 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 phil at bolthole.com Tue Jun 7 00:52:51 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 6 Jun 2011 15:52:51 -0700 Subject: [csw-maintainers] An end to IRC back-biting ? Message-ID: So I happened to be in opencsw irc today, and noticed a board member stirring up bad feeling about me on it. And this griping was done, after the irc bot had already announced I had addressed the issue Maciej had found, in svn, almost as soon as he let me know about it. Dagobert, bonivart_mac: Reviewed phil's package, found a surplus dep. :) self_publishing-- it's funny that his own packages gets released immedlately, no independent testing there double standard yes, no testing and no review As I pointed out in the channel afterwards: if someone actually VOLUNTEERED to always test my packages, in the same timeframe that I usually test others, I would LOVE to have someone else look at my packages There was absolutely no positive effect to be gained from sniping about me on the public channel, or even mentioning the issue on irc in the first place, particularly as I'd already addressed the issue. How about we have an end to negatively talking behind peoples' backs, on the supposedly " 'friendly' solaris channel"? From ellson at opencsw.org Tue Jun 7 00:57:22 2011 From: ellson at opencsw.org (John Ellson) Date: Mon, 06 Jun 2011 18:57:22 -0400 Subject: [csw-maintainers] graphviz-2.28.0 lt_dlopen() problem In-Reply-To: <110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org> References: <4DECA955.9020408@opencsw.org> <8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org> <4DECD79B.90601@opencsw.org> <5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org> <4DECE231.7010804@opencsw.org> <110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org> Message-ID: <4DED5B52.6070302@opencsw.org> Dago, I'm totally baffled by this one. The problem happens during package installation of CSWgraphviz-2.28.0 when "dot -c" is run to check which plugins can be successfully loaded and record their capabilities in the config6 file. > dot -c is running now to record available graphviz plugins. > > Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found This only happens when running on Solaris-9, even though the binaries were built on Solaris-9. The binaries for Solaris-10, also built on Solaris-9, don't have this problem. This only happens with this plugin. All the other plugins load as expected. (This plugin happens to be the only one containing C++ code, but the C++ is wrapped in a C function.) The error is reported by: lt_dlopen() which is from libtool. The path "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" is correct and the plugin exists there. Inspecting with ldd and elfdump show nothing unexpected. Could it be some security feature??? (something like selinux ?) Could it be something related to preload? Could it be something related to C++? The problem can be reproduced on unstable9s or testing9s using the attached code. John -------------- next part -------------- A non-text attachment was scrubbed... Name: test.c Type: text/x-csrc Size: 89 bytes Desc: not available URL: From ellson at opencsw.org Tue Jun 7 01:00:23 2011 From: ellson at opencsw.org (John Ellson) Date: Mon, 06 Jun 2011 19:00:23 -0400 Subject: [csw-maintainers] graphviz-2.28.0 lt_dlopen() problem In-Reply-To: <4DED5B52.6070302@opencsw.org> References: <4DECA955.9020408@opencsw.org> <8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org> <4DECD79B.90601@opencsw.org> <5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org> <4DECE231.7010804@opencsw.org> <110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org> <4DED5B52.6070302@opencsw.org> Message-ID: <4DED5C07.1010201@opencsw.org> [Sorry. Try that attachment again.] On 06/06/2011 06:57 PM, John Ellson wrote: > Dago, > > I'm totally baffled by this one. The problem happens during package installation of CSWgraphviz-2.28.0 when "dot -c" is run to check which plugins can be successfully loaded and record their capabilities in the config6 file. > > >> dot -c is running now to record available graphviz plugins. >> >> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found > > This only happens when running on Solaris-9, even though the binaries > were built on Solaris-9. > The binaries for Solaris-10, also built on Solaris-9, don't have this > problem. > > This only happens with this plugin. All the other plugins load as expected. > (This plugin happens to be the only one containing C++ code, but the C++ > is wrapped in a C function.) > > The error is reported by: lt_dlopen() which is from libtool. > > The path "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" is correct and > the plugin exists there. > > Inspecting with ldd and elfdump show nothing unexpected. > > > > > Could it be some security feature??? (something like selinux ?) > > Could it be something related to preload? > > Could it be something related to C++? > > > > The problem can be reproduced on unstable9s or testing9s using the > attached code. > > > John > > > > > > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.c Type: text/x-csrc Size: 770 bytes Desc: not available URL: From phil at bolthole.com Tue Jun 7 01:22:34 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 6 Jun 2011 16:22:34 -0700 Subject: [csw-maintainers] graphviz-2.28.0 lt_dlopen() problem In-Reply-To: <4DED5B52.6070302@opencsw.org> References: <4DECA955.9020408@opencsw.org> <8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org> <4DECD79B.90601@opencsw.org> <5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org> <4DECE231.7010804@opencsw.org> <110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org> <4DED5B52.6070302@opencsw.org> Message-ID: On Mon, Jun 6, 2011 at 3:57 PM, John Ellson wrote: > .... >> >> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found >.... > > The error is reported by: lt_dlopen() ?which is from libtool. > well... maybe its a libtool problem. Try loading an older version of liblt and see what happens. and/or a small posibility that something in your environment on the sol9 box is messing things up. try with "env - blahblah", or a different sol9 box. From bwalton at opencsw.org Tue Jun 7 02:46:20 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 06 Jun 2011 20:46:20 -0400 Subject: [csw-maintainers] libxml2 broken In-Reply-To: <65D204EA-6681-4CAD-87C7-D383CD6E1875@opencsw.org> References: <4DEBD2F3.8070808@opencsw.org> <4DEC251C.5060106@opencsw.org> <4DEC2D37.2010809@opencsw.org> <65D204EA-6681-4CAD-87C7-D383CD6E1875@opencsw.org> Message-ID: <1307407557-sup-3296@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Mon Jun 06 09:40:43 -0400 2011: > Always good to keep the eyes open. I just looked at the libiconv recipe and > "NOTES" from libiconv-1.13.1 says > > Q: Support EBCDIC ? > A: No! > > However, the packaged and released libxml2 2.7.8 does also not pass this test. > > Ben: Do you want to report this upstream? Sure. Let me get a good set of info together to shoot up there and I'll do so. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bonivart at opencsw.org Tue Jun 7 10:57:59 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 7 Jun 2011 10:57:59 +0200 Subject: [csw-maintainers] An end to IRC back-biting ? In-Reply-To: References: Message-ID: On Tue, Jun 7, 2011 at 12:52 AM, Philip Brown wrote: > So I happened to be in opencsw irc today, and noticed a board member > stirring up bad feeling about me on it. > > ... > > How about we have an end to negatively talking behind peoples' backs, > on the supposedly > " 'friendly' solaris channel"? I don't think this qualifies as "talking behind peoples backs" at all, you were online and could have engaged at any time, apparently you did so after I was already offline. Whether or not you feel it was negative (for you) I stand by what I said. /peter From dam at opencsw.org Tue Jun 7 16:29:28 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 7 Jun 2011 16:29:28 +0200 Subject: [csw-maintainers] Rebuild of ImageMagick Message-ID: Hi, I am currently looking at a rebuild of ImageMagick and noticed some things on legacy libraries: They seem to require tons of other libs and configuration files which would be pulled in from the ordinary CSWimagemagick. The only dependencies are CSWpstoedit CSWkofficegcc Peter: Would you mind rebuilding pstoedit against an updated imagemagick on unstable* ? I would like to completely drop CSWkofficegcc as it is already old, broken and I don't see anyone is interested in it any more. After that we could just ditch the old libraries *.so.10, *.so.2 and *.so.3 John: After that I could release ImageMagick build against the updated graphviz. Roger: Feel free to chime in and take over at any time :-) 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 ellson at opencsw.org Tue Jun 7 16:35:43 2011 From: ellson at opencsw.org (John Ellson) Date: Tue, 07 Jun 2011 10:35:43 -0400 Subject: [csw-maintainers] Rebuild of ImageMagick In-Reply-To: References: Message-ID: <4DEE373F.4030404@opencsw.org> On 06/07/2011 10:29 AM, Dagobert Michelsen wrote: > Hi, > > I am currently looking at a rebuild of ImageMagick and noticed some things on legacy libraries: > They seem to require tons of other libs and configuration files which would be pulled in from > the ordinary CSWimagemagick. The only dependencies are > CSWpstoedit > CSWkofficegcc > > Peter: Would you mind rebuilding pstoedit against an updated imagemagick on unstable* ? > > I would like to completely drop CSWkofficegcc as it is already old, broken and I don't > see anyone is interested in it any more. > > After that we could just ditch the old libraries *.so.10, *.so.2 and *.so.3 > > John: After that I could release ImageMagick build against the updated graphviz. Dago, I notice you have a new librsvg too? So am I correct that I should rebuild graphviz once librsvg is installed on current9[sx] ? Is librvg built for 64bits? Should I attempt to turn that on in the graphviz build? John > Roger: Feel free to chime in and take over at any time :-) > > > Best regards > > -- Dago > From dam at opencsw.org Tue Jun 7 16:49:20 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 7 Jun 2011 16:49:20 +0200 Subject: [csw-maintainers] Rebuild of ImageMagick In-Reply-To: <4DEE373F.4030404@opencsw.org> References: <4DEE373F.4030404@opencsw.org> Message-ID: Hi John, Am 07.06.2011 um 16:35 schrieb John Ellson: > On 06/07/2011 10:29 AM, Dagobert Michelsen wrote: >> I am currently looking at a rebuild of ImageMagick and noticed some things on legacy libraries: >> They seem to require tons of other libs and configuration files which would be pulled in from >> the ordinary CSWimagemagick. The only dependencies are >> CSWpstoedit >> CSWkofficegcc >> >> Peter: Would you mind rebuilding pstoedit against an updated imagemagick on unstable* ? >> >> I would like to completely drop CSWkofficegcc as it is already old, broken and I don't >> see anyone is interested in it any more. >> >> After that we could just ditch the old libraries *.so.10, *.so.2 and *.so.3 >> >> John: After that I could release ImageMagick build against the updated graphviz. > > Dago, > > I notice you have a new librsvg too? So am I correct that I should > rebuild graphviz once librsvg is installed on current9[sx] ? As it has the new library naming, yes. Apart from that there should be no change as the soname is identical to the old one. > Is librvg built for 64bits? Nope, there are too many missing bits for gnome not ready yet. > Should I attempt to turn that on in the graphviz build? You can try and disable all components not ready yet. That would make the shortcomings visible and you could file bugs for these and enable them one by one as they become available. 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 phil at bolthole.com Tue Jun 7 17:12:33 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 7 Jun 2011 08:12:33 -0700 Subject: [csw-maintainers] Rebuild of ImageMagick In-Reply-To: References: Message-ID: On Tue, Jun 7, 2011 at 7:29 AM, Dagobert Michelsen wrote: > > > I would like to completely drop CSWkofficegcc as it is already old, broken and I don't > see anyone is interested in it any more. this is probably a good idea. But... given the size of it, you should make a "plan to drop" announcement on users/announce list first, and wait a bit for feedback. From dam at opencsw.org Tue Jun 7 17:17:25 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 7 Jun 2011 17:17:25 +0200 Subject: [csw-maintainers] graphviz-2.28.0 lt_dlopen() problem In-Reply-To: <4DED5B52.6070302@opencsw.org> References: <4DECA955.9020408@opencsw.org> <8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org> <4DECD79B.90601@opencsw.org> <5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org> <4DECE231.7010804@opencsw.org> <110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org> <4DED5B52.6070302@opencsw.org> Message-ID: <4588683D-334A-4E83-ABB5-A1DA7E8B1987@opencsw.org> Hi John, Am 07.06.2011 um 00:57 schrieb John Ellson: > I'm totally baffled by this one. The problem happens during package installation of CSWgraphviz-2.28.0 when "dot -c" is run to check which plugins can be successfully loaded and record their capabilities in the config6 file. > >> dot -c is running now to record available graphviz plugins. >> >> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found > > This only happens when running on Solaris-9, even though the binaries > were built on Solaris-9. > The binaries for Solaris-10, also built on Solaris-9, don't have this > problem. In fact they do, probably we have tested the wrong thing: unstable10s# dot -c Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found > This only happens with this plugin. All the other plugins load as expected. > (This plugin happens to be the only one containing C++ code, but the C++ > is wrapped in a C function.) > > The error is reported by: lt_dlopen() which is from libtool. > > The path "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" is correct and > the plugin exists there. > > Inspecting with ldd and elfdump show nothing unexpected. Try "ldd -r" and you see that there are lots of errors. The come from /opt/csw/lib/libLASi.so because there has been no NEEDED for libCstd.so for Sun Studio in it. Try adding -lCstd to the linker flags of liblasi and I am confident it will work then. 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 Tue Jun 7 17:40:58 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 7 Jun 2011 17:40:58 +0200 Subject: [csw-maintainers] graphviz-2.28.0 lt_dlopen() problem In-Reply-To: <4588683D-334A-4E83-ABB5-A1DA7E8B1987@opencsw.org> References: <4DECA955.9020408@opencsw.org> <8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org> <4DECD79B.90601@opencsw.org> <5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org> <4DECE231.7010804@opencsw.org> <110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org> <4DED5B52.6070302@opencsw.org> <4588683D-334A-4E83-ABB5-A1DA7E8B1987@opencsw.org> Message-ID: Hi John, Am 07.06.2011 um 17:17 schrieb Dagobert Michelsen: > Am 07.06.2011 um 00:57 schrieb John Ellson: >> I'm totally baffled by this one. The problem happens during package installation of CSWgraphviz-2.28.0 when "dot -c" is run to check which plugins can be successfully loaded and record their capabilities in the config6 file. >> >>> dot -c is running now to record available graphviz plugins. >>> >>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found >> >> This only happens when running on Solaris-9, even though the binaries >> were built on Solaris-9. >> The binaries for Solaris-10, also built on Solaris-9, don't have this >> problem. > > In fact they do, probably we have tested the wrong thing: > > unstable10s# dot -c > Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found > Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found > >> This only happens with this plugin. All the other plugins load as expected. >> (This plugin happens to be the only one containing C++ code, but the C++ >> is wrapped in a C function.) >> >> The error is reported by: lt_dlopen() which is from libtool. >> >> The path "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" is correct and >> the plugin exists there. >> >> Inspecting with ldd and elfdump show nothing unexpected. > > Try "ldd -r" and you see that there are lots of errors. The come from > /opt/csw/lib/libLASi.so > because there has been no NEEDED for libCstd.so for Sun Studio in it. > Try adding -lCstd to the linker flags of liblasi and I am confident it will > work then. I rebuild liblasi and everything looks good. I am commiting my work so you can rebuild and rerelease the liblasi packages. 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 Wed Jun 8 03:12:38 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 07 Jun 2011 21:12:38 -0400 Subject: [csw-maintainers] An end to IRC back-biting ? In-Reply-To: References: Message-ID: <1307493218-sup-8821@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Jun 06 18:52:51 -0400 2011: Hi Phil, > There was absolutely no positive effect to be gained from sniping > about me on the public channel, or even mentioning the issue on irc > in the first place, particularly as I'd already addressed the issue. You frustrate people. People need to vent and say things like this when they're frustrated. As many of us hang out in irc all the time, it's the natural place to do so. It's the kind of thing friends do with each other. This particular jab stems from the perception that you hold yourself as better than everyone else in the project. You may not actually feel this way, but to put it succinctly, this is the impression you give. It's perception that counts here. If you could step back and see how your interactions with people negatively colour their view of you, you might come to realize why we're all so frustrated. We've tried explaining it to you but you've ignored, misinterpreted or outright dismissed the explanations. I've gotten to the point where I find it incredibly difficult to engage you at all. I'm sure you've noticed that I walk away from conversations with you, knowing full well that you'll reply anyway. You may have also noticed a distinct lack of response to mailing list threads you start. People just don't think it's worth their time. Is it just me? Maybe. I don't think it's all you as it does take two to tango. That being said, I have to wonder why so many others share the same sentiment? Then I'd wonder why everyone else is able to interact so positively all the time? > How about we have an end to negatively talking behind peoples' > backs, on the supposedly " 'friendly' solaris channel"? The channel _is_ very friendly. I don't think I'd be stretching things in the least to say that we're one of the best resources on the net for helpful advice on solaris. If you hung out and actually participated in the community, perhaps you'd agree. Although you may take this as just another personal attack, please accept it as a sincere, honest and direct response. It's borne out of the same frustration that Maciej and Peter feel when they take part in irc conversations such as the one you quoted. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From ellson at opencsw.org Wed Jun 8 04:40:55 2011 From: ellson at opencsw.org (John Ellson) Date: Tue, 07 Jun 2011 22:40:55 -0400 Subject: [csw-maintainers] graphviz-2.28.0 lt_dlopen() problem In-Reply-To: References: <4DECA955.9020408@opencsw.org> <8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org> <4DECD79B.90601@opencsw.org> <5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org> <4DECE231.7010804@opencsw.org> <110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org> <4DED5B52.6070302@opencsw.org> <4588683D-334A-4E83-ABB5-A1DA7E8B1987@opencsw.org> Message-ID: <4DEEE137.6040304@opencsw.org> Dago, I don't know how you got liblasi to build? I had to change to: CXXFLAGS = -L/usr/lib -lCstd -norunpath Then the "make test" would pass the first build. But then the 64bit build failed with: Linking CXX shared library libLASi.so cd /home/ellson/mgar/pkg/liblasi/trunk/work/solaris9-sparc/build-isa-sparcv9/libLASi-1.1.0/src && /opt/csw/bin/cmake -E cmake_link_script CMakeFiles/LASi.dir/link.txt --verbose=1 /opt/SUNWspro/bin/CC -KPIC -L/usr/lib -lCstd -norunpath -G -hlibLASi.so.0 -o libLASi.so.0.0.1 CMakeFiles/LASi.dir/drawGlyph.o CMakeFiles/LASi.dir/glyphMgr.o CMakeFiles/LASi.dir/psDoc.o CMakeFiles/LASi.dir/util.o -L/opt/csw/lib/sparcv9 -L/opt/csw/lib/64 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lpthread -lthread -lrt -lglib-2.0 -lintl -lpangoft2-1.0 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lpthread -lthread -lrt -lglib-2.0 -lintl -lfreetype -lm -lpango-1.0 -lpangoft2-1.0 -lfontconfig -lm -R/opt/csw/lib/sparcv9:/opt/csw/lib/64: ld: fatal: file /opt/csw/lib/sparcv9/libfreetype.so: wrong ELF class: ELFCLASS64 ld: fatal: file /opt/csw/lib/sparcv9/libfreetype.so: wrong ELF class: ELFCLASS64 ld: fatal: File processing errors. No output written to libLASi.so.0.0.1 gmake[4]: *** [src/libLASi.so.0.0.1] Error 1 gmake[4]: Leaving directory `/home/ellson/mgar/pkg/liblasi/trunk/work/solaris9-sparc/build-isa-sparcv9/libLASi-1.1.0' So I disabled the 64bit build for now. John On 06/07/2011 11:40 AM, Dagobert Michelsen wrote: > Hi John, > > Am 07.06.2011 um 17:17 schrieb Dagobert Michelsen: >> Am 07.06.2011 um 00:57 schrieb John Ellson: >>> I'm totally baffled by this one. The problem happens during package installation of CSWgraphviz-2.28.0 when "dot -c" is run to check which plugins can be successfully loaded and record their capabilities in the config6 file. >>> >>>> dot -c is running now to record available graphviz plugins. >>>> >>>> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found >>> This only happens when running on Solaris-9, even though the binaries >>> were built on Solaris-9. >>> The binaries for Solaris-10, also built on Solaris-9, don't have this >>> problem. >> In fact they do, probably we have tested the wrong thing: >> >> unstable10s# dot -c >> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found >> Warning: Could not load "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" - file not found >> >>> This only happens with this plugin. All the other plugins load as expected. >>> (This plugin happens to be the only one containing C++ code, but the C++ >>> is wrapped in a C function.) >>> >>> The error is reported by: lt_dlopen() which is from libtool. >>> >>> The path "/opt/csw/lib/graphviz/libgvplugin_lasi.so.6" is correct and >>> the plugin exists there. >>> >>> Inspecting with ldd and elfdump show nothing unexpected. >> Try "ldd -r" and you see that there are lots of errors. The come from >> /opt/csw/lib/libLASi.so >> because there has been no NEEDED for libCstd.so for Sun Studio in it. >> Try adding -lCstd to the linker flags of liblasi and I am confident it will >> work then. > I rebuild liblasi and everything looks good. I am commiting my work so > you can rebuild and rerelease the liblasi packages. > > > Best regards > > -- Dago > > From ellson at opencsw.org Wed Jun 8 04:52:06 2011 From: ellson at opencsw.org (John Ellson) Date: Tue, 07 Jun 2011 22:52:06 -0400 Subject: [csw-maintainers] csw-update-pkg does more checks???? In-Reply-To: <4DEEE137.6040304@opencsw.org> References: <4DECA955.9020408@opencsw.org> <8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org> <4DECD79B.90601@opencsw.org> <5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org> <4DECE231.7010804@opencsw.org> <110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org> <4DED5B52.6070302@opencsw.org> <4588683D-334A-4E83-ABB5-A1DA7E8B1987@opencsw.org> <4DEEE137.6040304@opencsw.org> Message-ID: <4DEEE3D6.8060700@opencsw.org> liblasi built, passed its tests, successfully packaged, so I thought I'd try pushing it with csw-update-pkg, but no, apparently csw-update-pkg does some additional tests, tests that absolutely couldn't have been done earlier in the build process ?!, which failed. ellson at login:~> mgar/pkg/liblasi/trunk/gar/bin/csw-upload-pkg newpkgs/liblasi* There is a problem with the presented file list. * CheckpkgTag(None, 'bad-arch-or-os-release', 'liblasi arch=unknown osrel=unspecified') * CheckpkgTag(None, 'sparc-unspecified-missing', 'liblasi0') * CheckpkgTag(None, 'i386-unspecified-missing', 'liblasi0') * CheckpkgTag(None, 'i386-unspecified-missing', 'liblasi_dev') * CheckpkgTag(None, 'sparc-unspecified-missing', 'liblasi_stub') * CheckpkgTag(None, 'sparc-unspecified-missing', 'liblasi_dev') * CheckpkgTag(None, 'i386-unspecified-missing', 'liblasi_stub') * CheckpkgTag(None, 'bad-vendor-tag', 'filename=liblasi expected=CSW actual=UNKN') I give up..... perhaps tomorrow? Cranky John From maciej at opencsw.org Wed Jun 8 04:54:57 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Wed, 8 Jun 2011 03:54:57 +0100 Subject: [csw-maintainers] csw-update-pkg does more checks???? In-Reply-To: <4DEEE3D6.8060700@opencsw.org> References: <4DECA955.9020408@opencsw.org> <8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org> <4DECD79B.90601@opencsw.org> <5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org> <4DECE231.7010804@opencsw.org> <110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org> <4DED5B52.6070302@opencsw.org> <4588683D-334A-4E83-ABB5-A1DA7E8B1987@opencsw.org> <4DEEE137.6040304@opencsw.org> <4DEEE3D6.8060700@opencsw.org> Message-ID: Hi John, To address the subject - yes, it does more checks. For example, if you give it a sparc package with foo, it will expect there to be also a i386 package with foo, and it will complain if it's not there. 2011/6/8 John Ellson : > liblasi built, passed its tests, successfully packaged, so I thought I'd > try pushing it with csw-update-pkg, but no, apparently csw-update-pkg > does some additional tests, tests that absolutely couldn't have been > done earlier in the build process ?!, which failed. > > ellson at login:~> mgar/pkg/liblasi/trunk/gar/bin/csw-upload-pkg > newpkgs/liblasi* > There is a problem with the presented file list. > * CheckpkgTag(None, 'bad-arch-or-os-release', 'liblasi arch=unknown > osrel=unspecified') > * CheckpkgTag(None, 'sparc-unspecified-missing', 'liblasi0') > * CheckpkgTag(None, 'i386-unspecified-missing', 'liblasi0') > * CheckpkgTag(None, 'i386-unspecified-missing', 'liblasi_dev') > * CheckpkgTag(None, 'sparc-unspecified-missing', 'liblasi_stub') > * CheckpkgTag(None, 'sparc-unspecified-missing', 'liblasi_dev') > * CheckpkgTag(None, 'i386-unspecified-missing', 'liblasi_stub') > * CheckpkgTag(None, 'bad-vendor-tag', 'filename=liblasi expected=CSW > actual=UNKN') I suspect that a non-package file was passed as an argument. What was the exact file list? (i.e. output of echo newpkgs/liblasi*) Maciej From ellson at opencsw.org Wed Jun 8 05:01:40 2011 From: ellson at opencsw.org (John Ellson) Date: Tue, 07 Jun 2011 23:01:40 -0400 Subject: [csw-maintainers] csw-update-pkg does more checks???? In-Reply-To: References: <4DECA955.9020408@opencsw.org> <8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org> <4DECD79B.90601@opencsw.org> <5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org> <4DECE231.7010804@opencsw.org> <110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org> <4DED5B52.6070302@opencsw.org> <4588683D-334A-4E83-ABB5-A1DA7E8B1987@opencsw.org> <4DEEE137.6040304@opencsw.org> <4DEEE3D6.8060700@opencsw.org> Message-ID: <4DEEE614.9030405@opencsw.org> On 06/07/2011 10:54 PM, Maciej Blizi?ski wrote: > > I suspect that a non-package file was passed as an argument. > > What was the exact file list? (i.e. output of echo newpkgs/liblasi*) Ah! You're so correct. I had a directory in there named liblasi. newpkgs/liblasi*gz worked much better. Thanks. John From dam at opencsw.org Wed Jun 8 09:14:54 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 8 Jun 2011 09:14:54 +0200 Subject: [csw-maintainers] graphviz-2.28.0 lt_dlopen() problem In-Reply-To: <4DEEE137.6040304@opencsw.org> References: <4DECA955.9020408@opencsw.org> <8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org> <4DECD79B.90601@opencsw.org> <5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org> <4DECE231.7010804@opencsw.org> <110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org> <4DED5B52.6070302@opencsw.org> <4588683D-334A-4E83-ABB5-A1DA7E8B1987@opencsw.org> <4DEEE137.6040304@opencsw.org> Message-ID: <81BB72F4-974D-40C9-BFD9-C889534B1EF4@opencsw.org> Hi John, Am 08.06.2011 um 04:40 schrieb John Ellson: > I don't know how you got liblasi to build? I had to change to: > CXXFLAGS = -L/usr/lib -lCstd -norunpath This has a number of issues: 1. Setting CXXFLAGS unconditionally overwrites the GAR defaults. This means that e.g. -xarch=sparcv8 and -m64 is overwritten resulting in failing 64 build and sparcv8+ (compiler default) binaries in sparcv8 dirs. EXTRA_* makes sure the value is appended to the GAR defaults. 2. /usr/lib only contains 32 bit libraries. If you build things with 64 bit the best way is to use EXTRA_LIB = which gets the ISA-specific subdirectory attached by default. LDFLAGS does not work because it is not set in the configure-custom rule for cmake. This was done manually by the original Makefile author and would need adjustment by someone who knows cmake (not me). The failing test for 64 bit seems to origin from a missing sparcv9/pango-querymodules because binaries for 64 bit are stripped by default and just libs are in the package. Fixing CSWpango now. It is a long way to 64 bit... Additionally, I recommend not pushing things with controversial overrides in it. As it worked for me it would be better to reply with "I get error abc on host xyz and can't find the cause". 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 ellson at opencsw.org Wed Jun 8 14:09:26 2011 From: ellson at opencsw.org (John Ellson) Date: Wed, 08 Jun 2011 08:09:26 -0400 Subject: [csw-maintainers] graphviz-2.28.0 lt_dlopen() problem In-Reply-To: <81BB72F4-974D-40C9-BFD9-C889534B1EF4@opencsw.org> References: <4DECA955.9020408@opencsw.org> <8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org> <4DECD79B.90601@opencsw.org> <5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org> <4DECE231.7010804@opencsw.org> <110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org> <4DED5B52.6070302@opencsw.org> <4588683D-334A-4E83-ABB5-A1DA7E8B1987@opencsw.org> <4DEEE137.6040304@opencsw.org> <81BB72F4-974D-40C9-BFD9-C889534B1EF4@opencsw.org> Message-ID: <4DEF6676.1070900@opencsw.org> Dago, Re: liblasi This worked much better: EXTRA_LIB = -L/usr/lib -lCstd -norunpath 64 bit is disabled (fails tests) Makefile contains the following overrides: # That is ok CHECKPKG_OVERRIDES_CSWliblasi-dev += file-with-bad-content|/usr/local|root/opt/csw/share/doc/liblasi/examples/README # Not sure about these CHECKPKG_OVERRIDES_CSWliblasi0 += bad-rpath-entry|/opt/SUNWspro/lib/v8|opt/csw/lib/libLASi.so.0.0.1 CHECKPKG_OVERRIDES_CSWliblasi0 += bad-rpath-entry|/opt/SUNWspro/lib/rw7|opt/csw/lib/libLASi.so.0.0.1 CHECKPKG_OVERRIDES_CSWliblasi0 += bad-rpath-entry|/lib|opt/csw/lib/libLASi.so.0.0.1 CHECKPKG_OVERRIDES_CSWliblasi0 += bad-rpath-entry|/opt/SUNWspro/lib|opt/csw/lib/libLASi.so.0.0.1 OK to push? John On 06/08/2011 03:14 AM, Dagobert Michelsen wrote: > Hi John, > > Am 08.06.2011 um 04:40 schrieb John Ellson: >> I don't know how you got liblasi to build? I had to change to: >> CXXFLAGS = -L/usr/lib -lCstd -norunpath > This has a number of issues: > > 1. Setting CXXFLAGS unconditionally overwrites the GAR defaults. > This means that e.g. -xarch=sparcv8 and -m64 is overwritten > resulting in failing 64 build and sparcv8+ (compiler default) > binaries in sparcv8 dirs. EXTRA_* makes sure the value is > appended to the GAR defaults. > > 2. /usr/lib only contains 32 bit libraries. If you build things > with 64 bit the best way is to use EXTRA_LIB = which > gets the ISA-specific subdirectory attached by default. > > LDFLAGS does not work because it is not set in the configure-custom rule > for cmake. This was done manually by the original Makefile author and > would need adjustment by someone who knows cmake (not me). > > The failing test for 64 bit seems to origin from a missing > sparcv9/pango-querymodules > because binaries for 64 bit are stripped by default and just libs are in the > package. Fixing CSWpango now. It is a long way to 64 bit... > > Additionally, I recommend not pushing things with controversial overrides > in it. As it worked for me it would be better to reply with "I get > error abc on host xyz and can't find the cause". > > > Best regards > > -- Dago > From dam at opencsw.org Wed Jun 8 14:13:52 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 8 Jun 2011 14:13:52 +0200 Subject: [csw-maintainers] graphviz-2.28.0 lt_dlopen() problem In-Reply-To: <4DEF6676.1070900@opencsw.org> References: <4DECA955.9020408@opencsw.org> <8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org> <4DECD79B.90601@opencsw.org> <5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org> <4DECE231.7010804@opencsw.org> <110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org> <4DED5B52.6070302@opencsw.org> <4588683D-334A-4E83-ABB5-A1DA7E8B1987@opencsw.org> <4DEEE137.6040304@opencsw.org> <81BB72F4-974D-40C9-BFD9-C889534B1EF4@opencsw.org> <4DEF6676.1070900@opencsw.org> Message-ID: Hi John, Am 08.06.2011 um 14:09 schrieb John Ellson: > Dago, > > Re: liblasi > > This worked much better: > > EXTRA_LIB = -L/usr/lib -lCstd -norunpath > > 64 bit is disabled (fails tests) > > Makefile contains the following overrides: > > # That is ok > CHECKPKG_OVERRIDES_CSWliblasi-dev += > file-with-bad-content|/usr/local|root/opt/csw/share/doc/liblasi/examples/README > > # Not sure about these > CHECKPKG_OVERRIDES_CSWliblasi0 += > bad-rpath-entry|/opt/SUNWspro/lib/v8|opt/csw/lib/libLASi.so.0.0.1 > CHECKPKG_OVERRIDES_CSWliblasi0 += > bad-rpath-entry|/opt/SUNWspro/lib/rw7|opt/csw/lib/libLASi.so.0.0.1 > CHECKPKG_OVERRIDES_CSWliblasi0 += > bad-rpath-entry|/lib|opt/csw/lib/libLASi.so.0.0.1 > CHECKPKG_OVERRIDES_CSWliblasi0 += > bad-rpath-entry|/opt/SUNWspro/lib|opt/csw/lib/libLASi.so.0.0.1 > > > OK to push? No, see my previous mail. Using EXTRA_LIB instead of EXTRA_CXXFLAGS I used earlier mixes up -norunpath to -L-norunpath basically disabling it. See for an explanation http://wiki.opencsw.org/checkpkg-error-tags#bad-rpath-entry On one hand I find it pretty enlighting to see issues coming up, however, the shere amount of issues on 64 bit is quite... frightening. However, I am confident that most of them should be fixed soon with the updated released of pango/cairo/liblasi. Best regards -- Dago From dam at opencsw.org Wed Jun 8 19:53:48 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 8 Jun 2011 19:53:48 +0200 Subject: [csw-maintainers] Status of Graphviz update and assorted packages Message-ID: <117AB9B9-7C77-481A-9995-35B974926944@opencsw.org> Hi, the major Graphviz update is coming along. Due to historic dependencies the updated Graphviz will be acompanied by a bunch of other packages which also have been rebuild due to older libs from graphviz we would like to abandon. This is especially CSWimagemagick As the updated ImageMagick also some older libs we would like to get rid of Peter Felecan will also rebuild CSWpstoedit against the updated ImageMagick. The packages will be collected in /home/experimental/graphviz and released in one large set. The updated ImageMagick will still be 32 bit only for now, but the project "imagemagick64" will be done when all dependencies are ready at a later time. Testing the updated GraphViz resulted in a chained fault to be detected in liblasi/pango/cairo which I have fixed. These will be released one at a time as there is no strict dependency on the above. 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 Wed Jun 8 19:57:36 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 8 Jun 2011 19:57:36 +0200 Subject: [csw-maintainers] Status of Graphviz update and assorted packages In-Reply-To: <117AB9B9-7C77-481A-9995-35B974926944@opencsw.org> References: <117AB9B9-7C77-481A-9995-35B974926944@opencsw.org> Message-ID: <596B00C9-3DD2-4917-98AC-2AA8EAFCB248@opencsw.org> Hi folks, Am 08.06.2011 um 19:53 schrieb Dagobert Michelsen: > As the updated ImageMagick also some older libs we would like to get rid of Peter Felecan > will also rebuild CSWpstoedit against the updated ImageMagick. I meant "As the updated ImageMagick also CONTAINS some older libs we would like to get rid of, AND Peter Felecan will also rebuild CSWpstoedit against the updated ImageMagick." :-) -- "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 phil at bolthole.com Wed Jun 8 20:35:58 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 8 Jun 2011 11:35:58 -0700 Subject: [csw-maintainers] An end to IRC back-biting ? In-Reply-To: <1307493218-sup-8821@pinkfloyd.chass.utoronto.ca> References: <1307493218-sup-8821@pinkfloyd.chass.utoronto.ca> Message-ID: On Tue, Jun 7, 2011 at 6:12 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Mon Jun 06 18:52:51 -0400 2011: > > Hi Phil, > >> There was absolutely no positive effect to be gained from sniping >> about me on the public channel, or even mentioning the issue on irc >> in the first place, particularly as I'd already addressed the issue. > > You frustrate people. ?People need to vent and say things like this > when they're frustrated. ?As many of us hang out in irc all the time, > it's the natural place to do so. ?It's the kind of thing friends do > with each other. >... > It's perception that counts here. >.... > Is it just me? ?Maybe. ?I don't think it's all you as it does take two > to tango. ?That being said, I have to wonder why so many others share > the same sentiment? Right now, "so many others share the same sentiment", because it has become accepted practice to bitch about me to others, rather than engage with me. You mention people's perceptions of me; however, people's views of a person, are strongly shaped by what other people say about that person. Even people who have not had issues with me in the past, have their attitude biased against me because of this stuff. It's self-fullfilling. If people are getting reinforced by comments on irc, "Phil is difficult to deal with", then as part of human nature, they will view everything I say through a "negative" filter, even when the content is neutral. What I quoted from irc is a perfect example of the locked-in bias. My behaviour was exemplary in this issue: I responded quickly, and in a manner favorable to the person who approached me.. **yet they still griped about me** ?? How is this in any way equitable? How did my actions in this case, in any way merit this treatment? It seems like just the opposite should be the case. An unbiased person might have even taken a moment to say, "Huh. Phil is responsive to complaints about his own packages. Maybe I should try to be equally responsive". But the anti-Phil bias is so strong in some people, the notion of cutting me some slack, or giving me some positive credit, seems impossible. >> How about we have an end to negatively talking behind peoples' >> backs, on the supposedly " 'friendly' solaris channel"? > > The channel _is_ very friendly. except towards me. unjustifiably. you suggest I hang out there more, but why would I wish to when people treat me like this? it's extremely unpleasant. From dam at opencsw.org Wed Jun 8 20:56:43 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 8 Jun 2011 20:56:43 +0200 Subject: [csw-maintainers] An end to IRC back-biting ? In-Reply-To: References: <1307493218-sup-8821@pinkfloyd.chass.utoronto.ca> Message-ID: <5111CA35-F2C8-4BE3-930E-42BA8099C704@opencsw.org> Hi Phil, Am 08.06.2011 um 20:35 schrieb Philip Brown: > you suggest I hang out there more, but why would I wish to when people > treat me like this? it's extremely unpleasant. Because it is easy to read an email wrong. IRC is more like talking and talking gives a much more accurate picture of someone and misunderstanding is harder :-) 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 bonivart at opencsw.org Wed Jun 8 21:28:12 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 8 Jun 2011 21:28:12 +0200 Subject: [csw-maintainers] An end to IRC back-biting ? In-Reply-To: References: <1307493218-sup-8821@pinkfloyd.chass.utoronto.ca> Message-ID: On Wed, Jun 8, 2011 at 8:35 PM, Philip Brown wrote: > What I quoted from irc is a perfect example of the locked-in bias. > My behaviour was exemplary in this issue: I responded quickly, and in > a manner favorable to the person who approached me.. I don't think you're getting the context of what you quoted from IRC. The thing is that you have always portrayed yourself as the only thing guaranteeing quality from Blastwave/OpenCSW, without you checking every package it would all go to hell. We have had many examples of you stating that fact in one way or another, the latest just recently regarding the upcoming vote. Now peer review using checkpkg from GAR spotted an error in one of your packages which at least I thought was somewhat amusing. I mean, if you had used GAR yourself you would have known this, even if you hadn't used GAR but tried the new upload feature it would have been caught there but instead you totally missed it which just proves two points - human inspection is inconsistent and you shouldn't inspect your own packages. To me, that's what those comments were about, that you yourself made the case for us. You demonstrated why the current system is bad. /peter From phil at bolthole.com Wed Jun 8 22:32:55 2011 From: phil at bolthole.com (Philip Brown) Date: Wed, 8 Jun 2011 13:32:55 -0700 Subject: [csw-maintainers] Fwd: Kerberos support for SSHD on Solaris 10 In-Reply-To: References: Message-ID: A note for the current, or any future, kerb maintainers. This is a forward, from a local user group list that I'm on. The user expected it to look in the solaris-documented location for krb5.conf(4) /etc/krb5/xxxxx It would appear to check /etc/krb5.conf:/opt/csw/etc/krb5.conf however, it should probably look in /etc/opt/csw/krb5.conf:/etc/krb5/krb5.conf:/etc/krb5.conf:/opt/csw/etc/krb5.conf (check all local locations, in that order, and then as a last-ditch effort, check for a "global" one) ---------- Forwarded message ---------- From: Chris McDermott Date: Wed, Jun 8, 2011 at 1:01 PM Subject: Re: Kerberos support for SSHD on Solaris 10 Just to close the loop on this, I was able to use truss to figure out that the csw openssh daemon was looking for the krb5.conf and krb5.keytab files in a different location, and thus authentication was failing. ?I created symlinks: /etc/krb5.conf -> /etc/krb5/krb5.conf /etc/krb5.keytab -> /etc/krb5/krb5.keytab And everything works great now. Thanks everyone! Chris From dam at opencsw.org Wed Jun 8 22:37:39 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 8 Jun 2011 22:37:39 +0200 Subject: [csw-maintainers] Fwd: Kerberos support for SSHD on Solaris 10 In-Reply-To: References: Message-ID: Hi, Am 08.06.2011 um 22:32 schrieb Philip Brown: > A note for the current, or any future, kerb maintainers. Added to http://wiki.opencsw.org/project-kerberos64 Best regards -- Dago From bwalton at opencsw.org Thu Jun 9 03:09:34 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 08 Jun 2011 21:09:34 -0400 Subject: [csw-maintainers] An end to IRC back-biting ? In-Reply-To: References: <1307493218-sup-8821@pinkfloyd.chass.utoronto.ca> Message-ID: <1307581706-sup-7318@pinkfloyd.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Wed Jun 08 15:28:12 -0400 2011: Hi Peter, > To me, that's what those comments were about, that you yourself made > the case for us. You demonstrated why the current system is bad. And importantly, Maciej demonstrated how the new system can work well. :) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Thu Jun 9 23:09:31 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 9 Jun 2011 23:09:31 +0200 Subject: [csw-maintainers] Fwd: [csw-pkgrequests] New package request : Dovecot Version latest References: <201106092059.p59KxerI024801@www.opencsw.org> Message-ID: <105EB3FF-3D80-4419-A5B3-A4C932917DD8@opencsw.org> Hi Jake, any interest in also packaging dovecot 2? Best regards -- Dago Anfang der weitergeleiteten E-Mail: > Von: pkgrequest at lists.opencsw.org > Datum: 9. Juni 2011 22:59:40 MESZ > An: pkgrequests at lists.opencsw.org > Betreff: [csw-pkgrequests] New package request : Dovecot Version latest > > Dear maintainers, > > A new package request has been received from Gil Salazar (mailto:GILSALES at AG.ARIZONA.EDU). Dovecot Version latest is requested to be added to our catalog. > > Here is the attached message : > > It would be a big help if someone could provide Dovecot 2 in this package. I have had troubles compiling all the necessary dependencies. Thank you very much in advance > ~Gil > _______________________________________________ > pkgrequests mailing list > pkgrequests at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/pkgrequests -- "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 jgoerzen at opencsw.org Fri Jun 10 01:30:56 2011 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Thu, 09 Jun 2011 16:30:56 -0700 Subject: [csw-maintainers] Fwd: [csw-pkgrequests] New package request : Dovecot Version latest In-Reply-To: <105EB3FF-3D80-4419-A5B3-A4C932917DD8@opencsw.org> References: <201106092059.p59KxerI024801@www.opencsw.org> <105EB3FF-3D80-4419-A5B3-A4C932917DD8@opencsw.org> Message-ID: <4DF157B0.9040603@opencsw.org> On 06/09/11 14:09, Dagobert Michelsen wrote: > Hi Jake, > > any interest in also packaging dovecot 2? > > Best regards > > -- Dago > > Anfang der weitergeleiteten E-Mail: > >> Von: pkgrequest at lists.opencsw.org >> Datum: 9. Juni 2011 22:59:40 MESZ >> An: pkgrequests at lists.opencsw.org >> Betreff: [csw-pkgrequests] New package request : Dovecot Version latest >> >> Dear maintainers, >> >> A new package request has been received from Gil Salazar (mailto:GILSALES at AG.ARIZONA.EDU). Dovecot Version latest is requested to be added to our catalog. >> >> Here is the attached message : >> >> It would be a big help if someone could provide Dovecot 2 in this package. I have had troubles compiling all the necessary dependencies. Thank you very much in advance >> ~Gil >> _______________________________________________ >> pkgrequests mailing list >> pkgrequests at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/pkgrequests Hi Dago, Yes, I was planning on it this month to get it done (upgrade to dovecot 2.0.13) At the moment I'm trying to work out the _devel to _dev package naming change and update the dependencies before doing a major version jump and risk trying to do too much at once. updated packages are now in experimental that I should be submitting soon.. then I'll get to work on dovecot 2 Thanks, Jake From dam at opencsw.org Fri Jun 10 14:55:11 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 10 Jun 2011 14:55:11 +0200 Subject: [csw-maintainers] Fixing a date for the Summercamp 2011 Message-ID: Hi folks, there is still some time left, but I already set up a doodle poll for the technical Summercamp 2011 in Kiel, Germany: http://doodle.com/ewfzuze75afweueq 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 phil at bolthole.com Sat Jun 11 06:22:17 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 10 Jun 2011 21:22:17 -0700 Subject: [csw-maintainers] An end to IRC back-biting ? In-Reply-To: <1307581706-sup-7318@pinkfloyd.chass.utoronto.ca> References: <1307493218-sup-8821@pinkfloyd.chass.utoronto.ca> <1307581706-sup-7318@pinkfloyd.chass.utoronto.ca> Message-ID: On Wed, Jun 8, 2011 at 6:09 PM, Ben Walton wrote: > Excerpts from Peter Bonivart's message of Wed Jun 08 15:28:12 -0400 2011: > > Hi Peter, > >> To me, that's what those comments were about, that you yourself made >> the case for us. You demonstrated why the current system is bad. > > And importantly, Maciej demonstrated how the new system can work > well. :) So, the new system is "Maciej personally checks everyone's packages"? Great, I'm all for that! :) Otherwise, I dont see how this demonstrates that in the new system, all packages are going to be looked at by a second party. That was the missing element here. For the record.. I did see an error about "unneeded dependancy" *before* I submitted it. Unfortunately, I incorrectly judged it a false error, so did the equivalent of a override in gar. If I used gar, I would have done the same thing, so no, gar would not have magically fixed this. If anything, this incident shows *more strongly*, the benefit of having at least 2 humans carefully look at a package before release. The "new system" does not in any way ensure that. I firmly believe that it will shepherd in the exact opposite: a time when the majority of packages will be released with only one person ever having looked at them. This is a bad thing. From rupert at opencsw.org Sat Jun 11 06:45:43 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 11 Jun 2011 06:45:43 +0200 Subject: [csw-maintainers] oracle raises the operating system maintenance by a factor of 6, solaris will be history soon? Message-ID: there are rumors that oracle raises the maintenance price for solaris by a factor of 6, is this true? do you feel some impact for the usage of solaris by this or not yet? rupert From ellson at opencsw.org Sat Jun 11 13:31:16 2011 From: ellson at opencsw.org (John Ellson) Date: Sat, 11 Jun 2011 07:31:16 -0400 Subject: [csw-maintainers] pango -> graphviz -> imagemagick Message-ID: <4DF35204.8050101@opencsw.org> The process to get to a graphviz-2.28.0 release, as I understand it from discussions with Dago, is as follows: 1. Wait for latest liblasi to show up on current9[sx] to resolve a problem with a missing shared lib dependency that broke "dot -c" during graphviz installs. Status: CSWliblasi 1.1.0,REV=2011.06.09 installed 2. Wait on latest pango to show up on current9[sx] -- to be honest I can't remember if this is essential, but Dago has made extensive build fixes and may (I'm not sure) have repackaged the libs such that I need changes in graphviz' Makefile. Also the new pango is expected to be 64bit ready. Status: not yet available. When pango is available the remaining steps are: 3. Build graphviz-2.28.0 as normal on current9[sx], but hold the resulting packages in /home/experimental/graphviz/ until imagemagick is also built. 4. Install CSWgraphviz & CSWgraphvizdevel on unstable9[sx] 5. Build imagemagic on unstable9[sx] and save resulting packages in /home/experimental/graphviz/ 6. Release graphviz and imagemagick packages simultaneously. So, bottom line, where is pango? John From dam at opencsw.org Sat Jun 11 15:04:10 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 11 Jun 2011 15:04:10 +0200 Subject: [csw-maintainers] pango -> graphviz -> imagemagick In-Reply-To: <4DF35204.8050101@opencsw.org> References: <4DF35204.8050101@opencsw.org> Message-ID: <201757B1-6569-4EC8-B782-976932B72134@opencsw.org> Hi John, Am 11.06.2011 um 13:31 schrieb John Ellson: > The process to get to a graphviz-2.28.0 release, as I understand it from > discussions with Dago, is as follows: > > 1. Wait for latest liblasi to show up on current9[sx] to resolve a > problem with a missing shared lib dependency that broke "dot -c" during > graphviz installs. > > Status: CSWliblasi 1.1.0,REV=2011.06.09 installed This problem in fact needs an updated liblasi -> pango -> cairo. There is no need for a respin of graphviz as the sonames stay the same. > 2. Wait on latest pango to show up on current9[sx] -- to be honest I > can't remember if this is essential, but Dago has made extensive build > fixes and may (I'm not sure) have repackaged the libs such that I need > changes in graphviz' Makefile. Also the new pango is expected to be > 64bit ready. > > Status: not yet available. There is currently a discussion about package renaming, but this does not affect the release of graphviz as explained above. An updated pango will be released in the next few days. > When pango is available the remaining steps are: > > 3. Build graphviz-2.28.0 as normal on current9[sx], but hold the > resulting packages in /home/experimental/graphviz/ until imagemagick > is also built. ImageMagick has already been rebuild and put in /home/experimental/graphviz to be released _together in one batch_. > 4. Install CSWgraphviz & CSWgraphvizdevel on unstable9[sx] > > 5. Build imagemagic on unstable9[sx] and save resulting packages in > /home/experimental/graphviz/ > > 6. Release graphviz and imagemagick packages simultaneously. I don't think you need another rebuild of graphviz. What is missing for a release is pstoedit by Peter Felecan, which is needed because of the imagemagick rebuild. It is in progress right now. When Peter has delivered this to /home/experimental/graphbiz you can release all packages together immediately I would say. Best regards -- Dago From maciej at opencsw.org Sun Jun 12 01:18:08 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sun, 12 Jun 2011 00:18:08 +0100 Subject: [csw-maintainers] Idea for a new check: binary name conflicts Message-ID: Hello fellow maintainers, One of our guidelines has historically been to not provide binaries in /opt/csw/bin named the same way as the ones in /usr/bin. For instance, bug 4533 has been filed because cups packages provide /opt/csw/bin/lp which conflicts with /usr/bin/lp. What are your thoughts on adding a check for binary name conflicts? Maciej [1] https://www.opencsw.org/mantis/view.php?id=4533 From bwalton at opencsw.org Sun Jun 12 03:56:57 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 11 Jun 2011 21:56:57 -0400 Subject: [csw-maintainers] Idea for a new check: binary name conflicts In-Reply-To: References: Message-ID: <1307843586-sup-7663@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej Blizi?ski's message of Sat Jun 11 19:18:08 -0400 2011: Hi Maciej, > One of our guidelines has historically been to not provide binaries > in /opt/csw/bin named the same way as the ones in /usr/bin. For > instance, bug 4533 has been filed because cups packages provide > /opt/csw/bin/lp which conflicts with /usr/bin/lp. I'm not sure I'd consider this a problem. If you're using cups, you most likely want /opt/csw/bin/lp. You don't want to have to learn new commands for things that have traditional names (lp, lpstat, etc) because cups is in play either. > What are your thoughts on adding a check for binary name conflicts? I don't see it as a conflict personally. The filesystem provides a separate name space and we're using it. If you want the system lp, either set the path accordingly or fully qualify it. No point in jumping through hoops for something like this, imo. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sun Jun 12 03:58:52 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 11 Jun 2011 21:58:52 -0400 Subject: [csw-maintainers] oracle raises the operating system maintenance by a factor of 6, solaris will be history soon? In-Reply-To: References: Message-ID: <1307843833-sup-8328@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Sat Jun 11 00:45:43 -0400 2011: Hi Rupert, > there are rumors that oracle raises the maintenance price for > solaris by a factor of 6, is this true? do you feel some impact for > the usage of solaris by this or not yet? I hadn't heard this, but even without altering current pricing, they're making solaris too expensive for us. Our campus license is being extended at the current price so we're registering systems. After a cut-off date, no new systems will be eligible for this and we'll pay 'market' rates which for us will be a deal breaker. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Sun Jun 12 05:11:04 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 11 Jun 2011 20:11:04 -0700 Subject: [csw-maintainers] Idea for a new check: binary name conflicts In-Reply-To: <1307843586-sup-7663@pinkfloyd.chass.utoronto.ca> References: <1307843586-sup-7663@pinkfloyd.chass.utoronto.ca> Message-ID: On Sat, Jun 11, 2011 at 6:56 PM, Ben Walton wrote: > > I don't see it as a conflict personally. ?The filesystem provides a > separate name space and we're using it. ?If you want the system lp, > either set the path accordingly or fully qualify it. ?No point in > jumping through hoops for something like this, imo. Not everyone gets to dictate to their users, "Your path WILL be this, and you dont get to change it". Having to pre-screen support calls with, "and what is your $PATH set to?", gets unpleasant. And its all very well to say, "if they change their PATH, they're unsupported", but those people still CALL. So you first have to remember to figure out, "oh, maybe they're using [this path], not [path we expect], and that changes everything". It's nicer for support people, to have a consistently working environment reguardless of which order someone's $PATH is set to. From bonivart at opencsw.org Sun Jun 12 15:24:00 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 12 Jun 2011 15:24:00 +0200 Subject: [csw-maintainers] Idea for a new check: binary name conflicts In-Reply-To: <1307843586-sup-7663@pinkfloyd.chass.utoronto.ca> References: <1307843586-sup-7663@pinkfloyd.chass.utoronto.ca> Message-ID: On Sun, Jun 12, 2011 at 3:56 AM, Ben Walton wrote: > Excerpts from Maciej Blizi?ski's message of Sat Jun 11 19:18:08 -0400 2011: > > Hi Maciej, > >> One of our guidelines has historically been to not provide binaries >> in /opt/csw/bin named the same way as the ones in /usr/bin. ?For >> instance, bug 4533 has been filed because cups packages provide >> /opt/csw/bin/lp which conflicts with /usr/bin/lp. > > I'm not sure I'd consider this a problem. ?If you're using cups, you > most likely want /opt/csw/bin/lp. ?You don't want to have to learn new > commands for things that have traditional names (lp, lpstat, etc) > because cups is in play either. > >> What are your thoughts on adding a check for binary name conflicts? > > I don't see it as a conflict personally. ?The filesystem provides a > separate name space and we're using it. ?If you want the system lp, > either set the path accordingly or fully qualify it. ?No point in > jumping through hoops for something like this, imo. I agree with Ben here. /peter From maciej at opencsw.org Sun Jun 12 17:45:02 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sun, 12 Jun 2011 16:45:02 +0100 Subject: [csw-maintainers] An end to IRC back-biting ? In-Reply-To: References: <1307493218-sup-8821@pinkfloyd.chass.utoronto.ca> <1307581706-sup-7318@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/6/11 Philip Brown : > For the record.. I did see an error about "unneeded dependancy" > *before* I submitted it. > Unfortunately, I incorrectly judged it a false error, so did the > equivalent of a override in gar. > If I used gar, I would have done the same thing, (...) Not necessarily. Here's what would have probably happened if you used GAR: A surplus-dependency [1] error would be thrown. As far as shared library analysis goes, checkpkg is almost never wrong about them. Youd have confidence in the results you're looking at, and you would not dismiss the error message. If you wanted to see more details, you would go to the buildfarm database, and look at the package metadata[2]. You would look at the NEEDED section of your binary, and see that openssl is not there. At this point you would understand that the dependency is not necessary. Maciej [1] http://wiki.opencsw.org/checkpkg-error-tags#surplus-dependency [2] http://buildfarm.opencsw.org/pkgdb/srv4/ecb59b20f4e4226a83a67b1bfe9f8379/ From phil at bolthole.com Sun Jun 12 19:52:58 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 12 Jun 2011 10:52:58 -0700 Subject: [csw-maintainers] An end to IRC back-biting ? In-Reply-To: References: <1307493218-sup-8821@pinkfloyd.chass.utoronto.ca> <1307581706-sup-7318@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/6/12 Maciej Blizi?ski : > 2011/6/11 Philip Brown : >> For the record.. I did see an error about "unneeded dependancy" >> *before* I submitted it. >> Unfortunately, I incorrectly judged it a false error, so did the >> equivalent of a override in gar. >> If I used gar, I would have done the same thing, (...) > > Not necessarily. ?Here's what would have probably happened if you used GAR: > > A surplus-dependency [1] error would be thrown. ?As far as shared > library analysis goes, checkpkg is almost never wrong about them. >... Maciej, the python version of checkpkg and the ksh version, use basically the same method of checking. They are exactly as reliable as each other. So no, nothing would have changed if I had used gar checkpkg. Now how about addressing the other part of my email, reguarding ensuring that at least two humans examine a package? Feel free to change the subject line to something more appropriate, for wider discussion. From maciej at opencsw.org Sun Jun 12 23:02:41 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sun, 12 Jun 2011 22:02:41 +0100 Subject: [csw-maintainers] Idea for a new check: binary name conflicts In-Reply-To: References: <1307843586-sup-7663@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/6/12 Peter Bonivart : > On Sun, Jun 12, 2011 at 3:56 AM, Ben Walton wrote: >> Excerpts from Maciej Blizi?ski's message of Sat Jun 11 19:18:08 -0400 2011: >> >> Hi Maciej, >> >>> One of our guidelines has historically been to not provide binaries >>> in /opt/csw/bin named the same way as the ones in /usr/bin. ?For >>> instance, bug 4533 has been filed because cups packages provide >>> /opt/csw/bin/lp which conflicts with /usr/bin/lp. >> >> I'm not sure I'd consider this a problem. ?If you're using cups, you >> most likely want /opt/csw/bin/lp. ?You don't want to have to learn new >> commands for things that have traditional names (lp, lpstat, etc) >> because cups is in play either. >> >>> What are your thoughts on adding a check for binary name conflicts? >> >> I don't see it as a conflict personally. ?The filesystem provides a >> separate name space and we're using it. ?If you want the system lp, >> either set the path accordingly or fully qualify it. ?No point in >> jumping through hoops for something like this, imo. > > I agree with Ben here. My inclination was also that it is alright to provide binaries with the same names. In my case, there was a number of scripts written by developers, who expected there to be a 'lp' command. If we provided binaries with a different name in /opt/csw/bin, then we would also need to make symlinks to them from elsewhere, the same way symlink in /opt/csw/gnu are provided. I would also need to add /opt/csw/gnu (or equivalent) to $PATH. At the end of the day, it would be not much different from just providing /opt/csw/bin/lp, just more complex. In the case of CUPS, I have removed the stock Solaris printing packages, so /usr/bin/lp and others were removed from the system. Any more opinions from other maintainers? Maciej From phil at bolthole.com Mon Jun 13 00:11:42 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 12 Jun 2011 15:11:42 -0700 Subject: [csw-maintainers] Idea for a new check: binary name conflicts In-Reply-To: References: <1307843586-sup-7663@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/6/12 Maciej Blizi?ski : > ... > In the case of CUPS, I have removed the stock Solaris printing > packages, so /usr/bin/lp and others were removed from the system. waitaminit... do you mean that in your cups package, you *force* removal of the solaris printing packages? without giving the user/admin a choice? Didnt we have a policy discussion about this sort of thing a while back? I dont remember the exact details, but I thought the general result was that we should try to give the user a choice in the matter. From bwalton at opencsw.org Mon Jun 13 02:17:20 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 12 Jun 2011 20:17:20 -0400 Subject: [csw-maintainers] Idea for a new check: binary name conflicts In-Reply-To: References: <1307843586-sup-7663@pinkfloyd.chass.utoronto.ca> Message-ID: <1307924216-sup-6771@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sun Jun 12 18:11:42 -0400 2011: > waitaminit... do you mean that in your cups package, you *force* > removal of the solaris printing packages? > without giving the user/admin a choice? I read that as 'on my systems, I...' Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Mon Jun 13 02:37:53 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 12 Jun 2011 17:37:53 -0700 Subject: [csw-maintainers] Idea for a new check: binary name conflicts In-Reply-To: <1307924216-sup-6771@pinkfloyd.chass.utoronto.ca> References: <1307843586-sup-7663@pinkfloyd.chass.utoronto.ca> <1307924216-sup-6771@pinkfloyd.chass.utoronto.ca> Message-ID: On Sun, Jun 12, 2011 at 5:17 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Sun Jun 12 18:11:42 -0400 2011: > >> waitaminit... do you mean that in your cups package, you *force* >> removal of the solaris printing packages? >> without giving the user/admin a choice? > > I read that as 'on my systems, I...' I understood that as an additional possibility. But even if that is so, accomodations need to be made for those who dont do that. Contrariwise, if "we" are going to take the attitude of, "we wont make you remove the solaris ones, but things wont really work properly if you dont", then we probably should have a "remove sol lp, or quit installation" catch in the package, I would think. From maciej at opencsw.org Mon Jun 13 07:35:31 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 13 Jun 2011 06:35:31 +0100 Subject: [csw-maintainers] csw-update-pkg does more checks???? In-Reply-To: <4DEEE614.9030405@opencsw.org> References: <4DECA955.9020408@opencsw.org> <8B671369-C08D-4EFA-A109-FC5EEF4C1ED4@opencsw.org> <4DECD79B.90601@opencsw.org> <5E7F6B25-9CB0-409A-9467-A64407A73029@opencsw.org> <4DECE231.7010804@opencsw.org> <110C3BFB-8521-43B1-83E8-DD8E0A8C22BD@opencsw.org> <4DED5B52.6070302@opencsw.org> <4588683D-334A-4E83-ABB5-A1DA7E8B1987@opencsw.org> <4DEEE137.6040304@opencsw.org> <4DEEE3D6.8060700@opencsw.org> <4DEEE614.9030405@opencsw.org> Message-ID: 2011/6/8 John Ellson : > On 06/07/2011 10:54 PM, Maciej Blizi?ski wrote: >> >> I suspect that a non-package file was passed as an argument. >> >> What was the exact file list? (i.e. output of echo newpkgs/liblasi*) > > Ah! You're so correct. I had a directory in there named liblasi. I added a new check for file names[1]; files need to end with either .pkg.gz or .pkg. If they do not, csw-upload-pkg will additionally display a 'bad-filename' error message, with the bad filename. In this case it would show something like: bad-filename filename=liblasi Maciej [1] http://sourceforge.net/apps/trac/gar/changeset/14796 From maciej at opencsw.org Mon Jun 13 12:05:41 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 13 Jun 2011 11:05:41 +0100 Subject: [csw-maintainers] Code and package reviews Message-ID: 2011/6/11 Philip Brown : > On Wed, Jun 8, 2011 at 6:09 PM, Ben Walton wrote: >> Excerpts from Peter Bonivart's message of Wed Jun 08 15:28:12 -0400 2011: >> >> Hi Peter, >> >>> To me, that's what those comments were about, that you yourself made >>> the case for us. You demonstrated why the current system is bad. >> >> And importantly, Maciej demonstrated how the new system can work >> well. :) > (...) > If anything, this incident shows *more strongly*, the benefit of > having at least 2 humans carefully look at a package before release. > > The "new system" does not in any way ensure that. > I firmly believe that it will shepherd in the exact opposite: a time > when the majority of packages will be released with only one person > ever having looked at them. > This is a bad thing. > > Now how about addressing the other part of my email, reguarding > ensuring that at least two humans examine a package? I expect that your position can be described as "the release manager position ensures that packages are always examined". While on some level it is true, it still depends on there being a person who believes that examining packages is important, and who is willing to spend their time on it. Therefore, just saying "a human must examine all packages" doesn't solve the problem. If there's no one around willing to be involved, any written rules are in vein. Our aim is to build a culture in which peer review is one of the key elements. There needs to be an environment which encourages peer reviews and makes them easy. The first place is the devel mailing list. If you examine its archives, you'll see a number of discussions[1]. Some issues are very easy to spot there. For example, if there's a code commit adding a lot of overrides, it's a good indicator that the maintainer is facing problems and could use some help. The second place is the buildfarm database, which allows browsing package metadata[2]. It's the easiest way to inspect certain features of packages such as lists of binaries, their properties, required shared libraries, etc. Discussions usually take place on the devel mailing list, to avoid overwhelming the maintainers list. There are also the atom feeds[3], showing package updates. All the interested parties (not necessarily just maintainers) can monitor feeds in a reader, and react to updates of packages that interest them. It is important that the senior members of the project actively participate in code and package reviews, serving as a good example to more junior members. While this strategy does not claim to "ensure that X number of humans will always do Y", it addresses the underlying issue of getting people involved in the release process and quality assurance through peer review. Maciej [1] http://lists.opencsw.org/pipermail/devel/2011-June/thread.html [2] http://buildfarm.opencsw.org/pkgdb/ [3] Testing location: http://buildfarm.opencsw.org/~bwalton/ From ellson at opencsw.org Mon Jun 13 13:49:34 2011 From: ellson at opencsw.org (John Ellson) Date: Mon, 13 Jun 2011 07:49:34 -0400 Subject: [csw-maintainers] pango -> graphviz -> imagemagick In-Reply-To: <201757B1-6569-4EC8-B782-976932B72134@opencsw.org> References: <4DF35204.8050101@opencsw.org> <201757B1-6569-4EC8-B782-976932B72134@opencsw.org> Message-ID: <4DF5F94E.8040408@opencsw.org> On 06/11/2011 09:04 AM, Dagobert Michelsen wrote: >> 6. Release graphviz and imagemagick packages simultaneously. > > I don't think you need another rebuild of graphviz. > > What is missing for a release is pstoedit by Peter Felecan, which is needed > because of the imagemagick rebuild. It is in progress right now. When > Peter has delivered this to /home/experimental/graphbiz you can > release all packages together immediately I would say. Dago, How is this going? John From dam at opencsw.org Mon Jun 13 14:35:00 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 13 Jun 2011 14:35:00 +0200 Subject: [csw-maintainers] pango -> graphviz -> imagemagick In-Reply-To: <4DF5F94E.8040408@opencsw.org> References: <4DF35204.8050101@opencsw.org> <201757B1-6569-4EC8-B782-976932B72134@opencsw.org> <4DF5F94E.8040408@opencsw.org> Message-ID: <6029000D-B3DD-43A2-9557-80FDFD10C3B8@opencsw.org> Hi John, Von meinem iPad gesendet Am 13.06.2011 um 13:49 schrieb John Ellson : > On 06/11/2011 09:04 AM, Dagobert Michelsen wrote: > >>> 6. Release graphviz and imagemagick packages simultaneously. >> >> I don't think you need another rebuild of graphviz. >> >> What is missing for a release is pstoedit by Peter Felecan, which is needed >> because of the imagemagick rebuild. It is in progress right now. When >> Peter has delivered this to /home/experimental/graphbiz you can >> release all packages together immediately I would say. > > > Dago, > > How is this going? Do you mean how it works or how it is coming along? I hope Peter is delivering the updated package in the next few days, then you can use csw-upload-pkg and submitpkg to deliver all packages in one batch. This is important, as there are library interdependencies from Graphviz to Imagemagick to pstoedit. Best regards -- Dago From phil at bolthole.com Mon Jun 13 16:09:24 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 13 Jun 2011 07:09:24 -0700 Subject: [csw-maintainers] Code and package reviews In-Reply-To: References: Message-ID: 2011/6/13 Maciej Blizi?ski : > 2011/6/11 Philip Brown : > >> (...) >> If anything, this incident shows *more strongly*, the benefit of >> having at least 2 humans carefully look at a package before release. >> >> The "new system" does not in any way ensure that. > > I expect that your position can be described as "the release manager > position ensures that packages are always examined". yes. > Our aim is to build a culture in which peer review is one of the key > elements. ?There needs to be an environment which encourages peer > reviews and makes them easy. >.... you took the time to write a lot of things in your email. Thank you. However, while the things you wrote were "good", and "true"... they still did not concretely address the issue :( I think the rest of what you wrote, can be summed up, with a minor insert, as follows: > It is important that the senior members of the project actively > participate in code and package reviews, serving as a good example to > more junior members. > [ So we **hope** that people will review packages] This is exactly the problem that I see. There have been a few people complaining about "lack of consistency" with the current release process. But how is a release strategy built around "hope", more consistent???? > While this strategy does not claim to "ensure that X number of humans > will always do Y", it addresses the underlying issue of getting people > involved in the release process and quality assurance through peer > review. It does not seem like it _adequately_ addresses the issue. Providing people an optional mechanism to improve quality, does not mean they will use it. "consistently". Providing people an optional mechanism to "get involved", does not mean they *will* get involved. Some people.. including *you* Maciej... keep pressing the claims that everything should be automated, for "consistency". So why are you not automating a 2nd party validation check? From pfelecan at acm.org Mon Jun 13 18:20:50 2011 From: pfelecan at acm.org (Peter FELECAN) Date: Mon, 13 Jun 2011 18:20:50 +0200 Subject: [csw-maintainers] pango -> graphviz -> imagemagick In-Reply-To: <6029000D-B3DD-43A2-9557-80FDFD10C3B8@opencsw.org> (Dagobert Michelsen's message of "Mon, 13 Jun 2011 14:35:00 +0200") References: <4DF35204.8050101@opencsw.org> <201757B1-6569-4EC8-B782-976932B72134@opencsw.org> <4DF5F94E.8040408@opencsw.org> <6029000D-B3DD-43A2-9557-80FDFD10C3B8@opencsw.org> Message-ID: Dagobert Michelsen writes: > Hi John, > > Von meinem iPad gesendet > > Am 13.06.2011 um 13:49 schrieb John Ellson : > >> On 06/11/2011 09:04 AM, Dagobert Michelsen wrote: >> >>>> 6. Release graphviz and imagemagick packages simultaneously. >>> >>> I don't think you need another rebuild of graphviz. >>> >>> What is missing for a release is pstoedit by Peter Felecan, which is needed >>> because of the imagemagick rebuild. It is in progress right now. When >>> Peter has delivered this to /home/experimental/graphbiz you can >>> release all packages together immediately I would say. >> >> >> Dago, >> >> How is this going? > > Do you mean how it works or how it is coming along? I hope Peter is > delivering the updated package in the next few days, then you can use > csw-upload-pkg and submitpkg to deliver all packages in one > batch. This is important, as there are library interdependencies from > Graphviz to Imagemagick to pstoedit. Done. -- Peter FELECAN mailto:pfelecan at acm.org From bwalton at opencsw.org Fri Jun 17 04:20:35 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 16 Jun 2011 22:20:35 -0400 Subject: [csw-maintainers] time to deprecate CSWmozilla In-Reply-To: <1307324723-sup-7673@pinkfloyd.chass.utoronto.ca> References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca> <1307123778-sup-3520@pinkfloyd.chass.utoronto.ca> <1307278894-sup-1960@pinkfloyd.chass.utoronto.ca> <1307324723-sup-7673@pinkfloyd.chass.utoronto.ca> Message-ID: <1308277170-sup-1017@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Sun Jun 05 21:47:43 -0400 2011: > No, the request is fine and I don't mind waiting a week as you > suggest. I'm just saying that we shouldn't let orphaned packages[1] > impede work on things that people do actively care about. Ok, so anybody that wants to update nspr properly is now able to do so and mark it 'I' with CSWmozilla. When it's released, CSWmozilla should be dropped from the catalog. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Fri Jun 17 12:00:08 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Fri, 17 Jun 2011 11:00:08 +0100 Subject: [csw-maintainers] New check: depending alternatives Message-ID: Hello maintainers, I've just added[1] a new check. If a package contains a file of the cswalternatives class, checkpkg will expect a dependency on CSWalternatives. For those who are interested in how the code works, the dependency is declared via the NeedFile() function. Inside the check, it is declared that our package under check needs the /opt/csw/sbin/alternatives file. There is no need to specifically list CSWalternatives. Checkpkg resolves the /opt/csw/sbin/alternatives path to the package that contains it. Maciej [1] http://sourceforge.net/apps/trac/gar/changeset/14834 From bwalton at opencsw.org Sat Jun 18 15:52:55 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 18 Jun 2011 09:52:55 -0400 Subject: [csw-maintainers] proposal Message-ID: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca> Hi All, I think we've waited long enough on this. Here is the proposal that myself and others are setting forward regarding the changed release process: http://wiki.opencsw.org/automated-release-proposal If you like it, feel free to add your name at the bottom. It's not an exclusive thing. The names there now are people that were involved in the discussions at winter camp and then later as this has progressed. I'm aware of one more person that will be signing it but there is no reason to delay this further, I don't think. Comments welcome. Once this has been digested, Phil will write the cons side of the ballot and I'll do the pros. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Sat Jun 18 16:16:48 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 18 Jun 2011 07:16:48 -0700 Subject: [csw-maintainers] proposal In-Reply-To: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca> References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca> Message-ID: On Sat, Jun 18, 2011 at 6:52 AM, Ben Walton wrote: > > Hi All, > > I think we've waited long enough on this. ?Here is the proposal that > myself and others are setting forward regarding the changed release > process: http://wiki.opencsw.org/automated-release-proposal > > If you like it, feel free to add your name at the bottom. huh? What's the point of that? we're going to vote on it, why are you telling people to do that, AND vote? It seems like nothing more than a "lobbying" effort to try to bias people towards it, rather than just having a clean vote. > Comments welcome. ?Once this has been digested, Phil will write the > cons side of the ballot and I'll do the pros. Ben, I believe that, weeks ago now, you said you would write up something on what procedures opencsw would have to amend proposals prior to vote. You have not done that. I would like to put forward an amendment to the proposal. Are you going to disallow any kind of formal *on-list* amendment mechanism? From rupert at opencsw.org Sat Jun 18 17:21:55 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 18 Jun 2011 17:21:55 +0200 Subject: [csw-maintainers] proposal In-Reply-To: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca> References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca> Message-ID: how much benefit does this give that it is enabled like this? it looks very "spammy" to me and takes up half of my laptop screen ... Automated Release Proposal - Agile Project Management Agility and flexibility even in case of disruptive situations www.cougarpartners.com - Process control World's leading provider on process diagnostic technology:Savcor Forest www.savcor.com - WS_FTP Server Test frei leichter, sicherer File Transfer + flexible Benutzerverwaltung IpswitchFT.com/FTPServer - Software Testing Event Jetzt anmelden zum Q-Event `11 der bbv Software Services AG in Luzern www.bbv.ch rupert. On Sat, Jun 18, 2011 at 15:52, Ben Walton wrote: > > Hi All, > > I think we've waited long enough on this. Here is the proposal that > myself and others are setting forward regarding the changed release > process: http://wiki.opencsw.org/automated-release-proposal > > If you like it, feel free to add your name at the bottom. It's not an > exclusive thing. The names there now are people that were involved in > the discussions at winter camp and then later as this has progressed. > I'm aware of one more person that will be signing it but there is no > reason to delay this further, I don't think. > > Comments welcome. Once this has been digested, Phil will write the > cons side of the ballot and I'll do the pros. > > Thanks > -Ben > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Sat Jun 18 20:51:06 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 18 Jun 2011 14:51:06 -0400 Subject: [csw-maintainers] proposal In-Reply-To: References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca> Message-ID: <1308420263-sup-8511@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sat Jun 18 10:16:48 -0400 2011: > huh? What's the point of that? we're going to vote on it, why are you > telling people to do that, AND vote? Well, if enough members support it before the vote happens, there is no need for a vote as it will have passed without the formality of ballot bin. > It seems like nothing more than a "lobbying" effort to try to bias > people towards it, rather than just having a clean vote. The original names can be considered authorship. Allowing people to sign on now can possibly prevent a vote at all. The supporters and the one that has signaled intent make up just shy of 50% of the active members. If 4 more people support the proposal, there is no need to vote and we save time. > > Comments welcome. ?Once this has been digested, Phil will write the > > cons side of the ballot and I'll do the pros. > > Ben, I believe that, weeks ago now, you said you would write up > something on what procedures opencsw would have to amend proposals > prior to vote. You have not done that. Sorry, been busy. It is on my todo list and maybe I'll work on it this weekend if I find the time. > I would like to put forward an amendment to the proposal. Are you > going to disallow any kind of formal *on-list* amendment mechanism? Please provide your amendment for public review and get the support of every currently signed member. Modifications without the support of everyone that has already signed off on the current form might invalidate their support, thus 100% approval for the change. I don't think that's unreasonable when you're talking about 33% of the membership. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Jun 18 20:51:56 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 18 Jun 2011 14:51:56 -0400 Subject: [csw-maintainers] proposal In-Reply-To: References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca> Message-ID: <1308423068-sup-8691@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Sat Jun 18 11:21:55 -0400 2011: Hi Rupert, > how much benefit does this give that it is enabled like this? it > looks very "spammy" to me and takes up half of my laptop screen ... Sorry about this. Unfortunately, there isn't much we can do about it. If you have a wikidot account (Peter Bonivart can help you with that), you don't see the ads. I forget that they're even there until things like this happen. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert at opencsw.org Sat Jun 18 22:15:26 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 18 Jun 2011 22:15:26 +0200 Subject: [csw-maintainers] proposal In-Reply-To: <1308423068-sup-8691@pinkfloyd.chass.utoronto.ca> References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca> <1308423068-sup-8691@pinkfloyd.chass.utoronto.ca> Message-ID: On Sat, Jun 18, 2011 at 20:51, Ben Walton wrote: > Excerpts from rupert THURNER's message of Sat Jun 18 11:21:55 -0400 2011: > > Hi Rupert, > > > how much benefit does this give that it is enabled like this? it > > looks very "spammy" to me and takes up half of my laptop screen ... > > Sorry about this. Unfortunately, there isn't much we can do about > it. If you have a wikidot account (Peter Bonivart can help you with > that), you don't see the ads. I forget that they're even there until > things like this happen. > this is the first thing people see if they come to the opencsw wiki ... and i am really wondering if opencsw or the server operator has some financial benefit? if not, i would strongly advocate to switch this off. if its built into the wiki software, then switch to a reasonable wiki, like http://moinmo.in or mediawiki, or redmine, or whatever. rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at bolthole.com Sat Jun 18 23:22:31 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 18 Jun 2011 14:22:31 -0700 Subject: [csw-maintainers] proposal In-Reply-To: <1308420263-sup-8511@pinkfloyd.chass.utoronto.ca> References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca> <1308420263-sup-8511@pinkfloyd.chass.utoronto.ca> Message-ID: On Sat, Jun 18, 2011 at 11:51 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Sat Jun 18 10:16:48 -0400 2011: > >> huh? What's the point of that? we're going to vote on it, why are you >> telling people to do that, AND vote? > > Well, if enough members support it before the vote happens, there is > no need for a vote as it will have passed without the formality of > ballot bin. When member(s) of the board, attempt to completely change the way opencsw operates, and they are at the same time *specfiically* attempting to avoid a formal vote while doing so, there is something extremely wrong. Is no-one else concerned about this? ??? >> I would like to put forward an amendment to the proposal. Are you >> going to disallow any kind of formal *on-list* amendment mechanism? > > Please provide your amendment for public review and get the support of > every currently signed member. ?Modifications without the support of > everyone that has already signed off on the current form might > invalidate their support, thus 100% approval for the change. This is a ludicrous methodology. But now it seems clear your real reason for getting people to "sign" it. You making the barrier to suggest changes impossible to overcome. This is abuse of power, yet again. To people who arent saying anything about this because they agree about the direction it is headed... consider that the same political railroading will also be used in the future, for issues that you do NOT agree with. Speak up now if that thought bothers you. If the majority of voting members votes a particular way, I'm not going to fight it. What concerns me the most, is that if the board is so convinced this is "the will of the majority", then why are they fighting so hard to allow the majority to have a clean vote, instead of these underhanded tactics? From bwalton at opencsw.org Sun Jun 19 04:20:14 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 18 Jun 2011 22:20:14 -0400 Subject: [csw-maintainers] proposal In-Reply-To: References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca> <1308423068-sup-8691@pinkfloyd.chass.utoronto.ca> Message-ID: <1308449688-sup-9855@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Sat Jun 18 16:15:26 -0400 2011: Hi Rupert, > this is the first thing people see if they come to the opencsw wiki > ... and i am really wondering if opencsw or the server operator has > some financial benefit? if not, i would strongly advocate to switch > this off. if its built into the wiki software, then switch to a > reasonable wiki, like http://moinmo.in or mediawiki, or redmine, or > whatever. Well, I don't know all of the original considerations, but wikidot has provided a good service, I think. We're on the free plan[1] where we get no control of the ads. We could host our own, I guess. I'm not sure why we didn't, but I suspect it's partially because nobody wanted to tend one of the wiki packages which see a fairly constant update requirement. I don't have much against the ads from wikidot myself as they need to make money and they're giving us a free service. (I barely notice ads on pages these days unless they're big, singing, dancing, spinning and bouncing.) Does an adblock plugin squash this? Thanks -Ben [1] http://www.wikidot.com/plans -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sun Jun 19 13:34:25 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 19 Jun 2011 07:34:25 -0400 Subject: [csw-maintainers] proposal In-Reply-To: References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca> <1308420263-sup-8511@pinkfloyd.chass.utoronto.ca> Message-ID: <1308482786-sup-7548@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sat Jun 18 17:22:31 -0400 2011: > When member(s) of the board, attempt to completely change the way > opencsw operates, and they are at the same time *specfiically* > attempting to avoid a formal vote while doing so, there is something > extremely wrong. No avoidance here. If there isn't 50% support up front, the vote will be run. It can be run anyway although I'd personally see it as wasting time if a majority clearly supports the change in an open, documented fashion. (I don't expect that this will actually happen and fully expect to run a ballot bin.) > >> I would like to put forward an amendment to the proposal. Are you > >> going to disallow any kind of formal *on-list* amendment > >> mechanism? > > > > Please provide your amendment for public review and get the > > support of every currently signed member. ?Modifications without > > the support of everyone that has already signed off on the current > > form might invalidate their support, thus 100% approval for the > > change. > > This is a ludicrous methodology. But now it seems clear your real > reason for getting people to "sign" it. You making the barrier to > suggest changes impossible to overcome. Say for a minute that there were no names undersigning the proposal. There would still be multiple people that worked on it and put it forward. Do you feel that you have some intrinsic right to be able to alter this proposal? I think it would be ludicrous to not hold your changes until it meets the support of the people that put forward the original. Go ahead and propose your changes on the list. Do you not think they'll be accepted by the people that have worked on the current proposal? Why is that? Is it because the changes would run counter to the meat of the current proposal? If so, why would you expect a change like that to be accepted? If not, why are you worried about getting the support of the current set of authors? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert at opencsw.org Sun Jun 19 15:00:55 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 19 Jun 2011 15:00:55 +0200 Subject: [csw-maintainers] experimental: subversion --> git, mercurial Message-ID: hi, as an experiment, i tried to convert the subversion gar repository to git and mercurial: * http://code.google.com/p/gar/ (hg) * https://github.com/opencsw/gar (git) where i was aware of a user name i entered you as owner as well. what i am not sure is how to handle externals and patches onto them, but i saw posts like: * http://www.undefinedrange.com/posts/git-submodules-external-repositories-and-deployment what do you think, in general about a conversion, and in special, how to do this patching? rupert. On Thu, Jan 6, 2011 at 02:30, Ben Walton wrote: > Excerpts from rupert THURNER's message of Wed Jan 05 14:12:46 -0500 2011: > > Hi Rupert, > > I'm sorry this wasn't easier for you. > > > * try to build, not all patches applied > > * throw away the old patches, check in > > First, a recommendation: Never throw away patch/script/foo files from > an existing build until you've got a working replacement. I've kicked > myself a few times for doing this. :) > > In a situation like this, I'd see if I could get the patches to apply > manually using patch or other methods. > > > * "gmake extract" to get the source back > > * edit the files again like it should be > > Although it may not complain, makepatch would prefer to be called > after `gmake patch` to ensure all existing patches are applied. I > forget whether I enforced this with a constraint or not...If not, I > don't recall a the reason why I didn't. > > > * "gmake makepatch" > > * "gmake package", failed as there is a new file which would need > > patching as well. > > > * "gmake clean", "gmake extract" again > > * edit the file > > * "gmake makepatch" again > > Did you see your first patch applied in this process at all? If not, > you're working on a pre-patched set of files. > > > then i forgot to delete a line in a file which is already patched, and > > i thought about repeating above procedure again: > > 1. gmake extract > > applied patch 001 > > 2. gmake makepatch > > tried to apply patch 001 again > > which failed. > > This is likely due to creating a patch against the unpatched tree > above. If so, I should look at making sure makepatch cannot run > unless the patch target has already been called. You could, > potentially still have problems though... > > > then i gave up for the moment ... but this cannot be it, isn't it? > > should we switch to the whole source from subversion to git and it > > would be neater? then patches could be rebased instead of applied > > newly. > > I wouldn't object[1], but others may disagree. It's also a huge > undertaking. I know that many others are also using git quite a bit > lately too. > > The first major portion of this transition would require separating > GAR (the tool) from the build recipes. Git simply doesn't handle > (nicely) the idea of an external like subversion does. This would be > the final impetus to separate the two, most likely using Sebastian's > excellent mgar! > > I know that Maciej has been having both success and frustration using > the git-svn bridge as of late... > > Thanks > -Ben > > [1] It would actually make my day! > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sun Jun 19 15:57:44 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sun, 19 Jun 2011 14:57:44 +0100 Subject: [csw-maintainers] Idea for a new check: binary name conflicts In-Reply-To: <1307924216-sup-6771@pinkfloyd.chass.utoronto.ca> References: <1307843586-sup-7663@pinkfloyd.chass.utoronto.ca> <1307924216-sup-6771@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/6/13 Ben Walton : > Excerpts from Philip Brown's message of Sun Jun 12 18:11:42 -0400 2011: > >> waitaminit... do you mean that in your cups package, you *force* >> removal of the solaris printing packages? >> without giving the user/admin a choice? > > I read that as 'on my systems, I...' Yes, that's what I meant. Maciej From skayser at opencsw.org Sun Jun 19 17:56:25 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 19 Jun 2011 17:56:25 +0200 Subject: [csw-maintainers] experimental: subversion --> git, mercurial In-Reply-To: References: Message-ID: <20110619155625.GC25705@sebastiankayser.de> Hi Rupert, * rupert THURNER wrote: > as an experiment, i tried to convert the subversion gar repository to git > and mercurial: > ? *? [1]http://code.google.com/p/gar/? (hg) > ? *? [2]https://github.com/opencsw/gar? (git) > where i was aware of a user name i entered you as owner as well. > what i am not sure is how to handle externals and patches onto them to clarify, you are referring to the gar/ subtree (not the pkg/ subtree which is also hosted in the GAR repo currently), right? Regarding externals, there's mgar, a wrapper around GAR which doesn't rely on svn:externals [1,2]. It currently pulls gar/ from our subversion repository and I could adjust it to pull from git instead (if folks around here deem it useful to have gar/ hosted in a git repo). Sebastian [1] http://wiki.opencsw.org/gar-wrapper [2] http://www.opencsw.org/packages/mgar/ From bwalton at opencsw.org Mon Jun 20 03:27:20 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 19 Jun 2011 21:27:20 -0400 Subject: [csw-maintainers] experimental: subversion --> git, mercurial In-Reply-To: References: Message-ID: <1308533109-sup-6441@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Sun Jun 19 09:00:55 -0400 2011: Hi Rupert, > as an experiment, i tried to convert the subversion gar repository to git > and mercurial: > * http://code.google.com/p/gar/ (hg) > * https://github.com/opencsw/gar (git) I like this! :) I'm not keen on mercurial given my exposure to it, but anything distributed would be a step up. > what i am not sure is how to handle externals and patches onto them, > but i saw posts like: > * > http://www.undefinedrange.com/posts/git-submodules-external-repositories-and-deployment > what do you think, in general about a conversion, and in special, > how to do this patching? I'm not sure what you mean by 'patches onto them' but basically, submodules suck for our use case, in my estimation. They're excellent in projects where you're pulling in external code as a source library. The most common example I see is that many projects have gnulib as a submodule. When they're polishing a new release, they update the gnulib submodule to current as part of that process. They won't work nicely in our pkg/$foo/trunk setup though as we'd be constantly required to update the sha1 reference to the submodule for every recipe change. As Sebastian mentioned, we can (and should!) do away with externals and, if they're still in use, the old garlinks in favour of the new mgar wrapper. If we did this, we could (as long as Sebastian is on board), merge mgar directly into the gar/v2 git repository and release an actual package for it. mgar is packaged now, but it could be extended to deliver the rest of the gar code with it. The impact of this would be that people would be forced to use mgar to interact with gar (or create their own new frankenstein) and people would need to learn/use git. Many of us are already using git where possible, so that's not likely a big hurdle. Using mgar is a positive experience and doesn't change workflow much beyond s/(svn|gmake)/mgar/ now. Gar would have a package and we could still have a devel mode for gar where the local git (or hg) repo is tracked against the head of the main branch. Good for users, good for devs. This might be a nice test of the waters for a move away from svn instead of attempting to move gar and all of the recipes in one shot. Is anyone else excited by this idea? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Mon Jun 20 06:59:26 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 19 Jun 2011 21:59:26 -0700 Subject: [csw-maintainers] proposal In-Reply-To: <1308482786-sup-7548@pinkfloyd.chass.utoronto.ca> References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca> <1308420263-sup-8511@pinkfloyd.chass.utoronto.ca> <1308482786-sup-7548@pinkfloyd.chass.utoronto.ca> Message-ID: On Sun, Jun 19, 2011 at 4:34 AM, Ben Walton wrote: > ... > Say for a minute that there were no names undersigning the proposal. > There would still be multiple people that worked on it and put it > forward. ?Do you feel that you have some intrinsic right to be able to > alter this proposal? The trouble here is that we still have no proper (and by that I mean, documented and officially approved) procedures for even creating a proposal, let alone amendment to the proposal, and then approving or rejecting them. As I have pointed out to the board previously, debian (for just one example) has fully written up details of one way to do this. A handwavy summary of that being: 1. an initial proposal is made 2. some formal discussion period (**ON THE LIST**) happens (off-list discussion may or may not happen, but the one that actually counts, is the bits done on the developer list that is fully archivable by all members, fully accessible by all members, and fully open to all members) 3. If an amendment is proposed, then that is discussed. If consensus(s) is reached, then the proposal is amended. (it is also possible that after discussion, the proposal is withdrawn) If no consensus is reached, then when voting time comes, both versions of the proposal are put up for vote. The voting ballot then becomes, "Vote for one of the following: a) accept proposal documented [here] b) accept proposal as amended and documented [here] c) reject all versions of proposal" ( 4. otherwise, a summary of the proposal and its side effects is drawn up, and the proposal is voted on) > If so, why would you expect a > change like that to be accepted? ?If not, why are you worried about > getting the support of the current set of authors? I am more concerned about "oh hey we reached X number of people with their names on the document, so there's no reason to have discussion on the mailing list, or a vote; the proposal to change our practices is 'deemed as passed'. Done. From now on we do this [this way]. From bonivart at opencsw.org Mon Jun 20 10:24:02 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 20 Jun 2011 10:24:02 +0200 Subject: [csw-maintainers] proposal In-Reply-To: References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca> <1308423068-sup-8691@pinkfloyd.chass.utoronto.ca> Message-ID: On Sat, Jun 18, 2011 at 10:15 PM, rupert THURNER wrote: > this is the first thing people see if they come to the opencsw wiki ... and > i am really wondering if opencsw or the server operator has some financial > benefit? if not, i would strongly advocate to switch this off. if its built > into the wiki software, then switch to a reasonable wiki, like > http://moinmo.in or mediawiki, or redmine, or whatever. But the wiki is not really public facing, it's mostly for maintainers and those usually have an account on the wiki and do not see the ads when logged in. When I created the wiki ads were optional, they no longer are. I guess wikidot.com is not free to operate... :) Please start a new thread if this is important to you, it's irrelevant for this one. /peter From bonivart at opencsw.org Tue Jun 21 17:29:29 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 21 Jun 2011 17:29:29 +0200 Subject: [csw-maintainers] /testing sendmail 8.14.5 Message-ID: I have done some work to the Sendmail 8.14.2 package from 2007. During all this time Mike Watters, Benny von Mossner and Maciej Blizinski have also contributed. There's quite a few changes and it's a lot simpler now. It doesn't mess with Solaris built-in Sendmail but instead delivers a script to help with this. Change list: + it's in GAR + large file support + post install message to explain changes + fix paths in sendmail.cf and cswsendmail + include deactivate/reactivate scripts + migrate conf from /opt/csw/etc/mail + use alternatives to clear collisions with postfix + never start cswsendmail by default (collides with system sendmail) + path to sendmail.cf in binary (/etc/opt/csw/mail) + bdb hash support + remove all custom handling of conf files, users and so on. Replace with cas + contrib package These bugs should be fixed: #2915 Must stop built-in sendmail manually -> n/a #3864 Sendmail must be relinked with new berkeley db -> bdb48 #4150 Sendmail 8.14.4 released -> this is 8.14.5 #4486 Provide sendmail's contrib/ tools as a separate package? There's three packages: sendmail, sendmail_contrib and libmilter. You can find them here: http://buildfarm.opencsw.org/experimental.html#sendmail. Please help test both new installs and upgrades. Does it work at all? Things to do differently? /peter From bwalton at opencsw.org Thu Jun 23 03:47:43 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 22 Jun 2011 21:47:43 -0400 Subject: [csw-maintainers] proposal In-Reply-To: References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca> <1308420263-sup-8511@pinkfloyd.chass.utoronto.ca> <1308482786-sup-7548@pinkfloyd.chass.utoronto.ca> Message-ID: <1308792965-sup-4934@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Jun 20 00:59:26 -0400 2011: > On Sun, Jun 19, 2011 at 4:34 AM, Ben Walton wrote: > > ... > > Say for a minute that there were no names undersigning the proposal. > > There would still be multiple people that worked on it and put it > > forward. ?Do you feel that you have some intrinsic right to be able to > > alter this proposal? > > The trouble here is that we still have no proper (and by that I mean, > documented and officially approved) procedures for even creating a > proposal, let alone amendment to the proposal, and then approving or > rejecting them. And if we try to accomplish these things with you, we'll get nowhere. We've tried this with the policy project. Both Maciej and Peter gave up working with you. I'm more and more convinced that for such a small group of people, the level of overhead involved with processes such as those in use at Debian are not worthwhile. Not that they're bad. They're just very heavy weight. If you'd like to see changes to the proposal, put them forward. If they build on it in a constructive manner such that the those signed on find them appealing, they'll be incorporated. Otherwise they won't. > 1. an initial proposal is made Done. > 2. some formal discussion period (**ON THE LIST**) happens > (off-list discussion may or may not happen, but the one that > actually counts, is the bits done on the developer list > that is fully archivable by all members, fully accessible by > all members, and fully open to all members) Please discuss. That's why the proposal was announced. > 3. If an amendment is proposed, then that is discussed. If > consensus(s) is reached, then the proposal is amended. > (it is also possible that after discussion, the proposal is withdrawn) > If no consensus is reached, then when voting time comes, both > versions of the proposal are put up for vote. Right. Put it out there and see if you get consensus. As I said, if you put something constructive together there is no reason it wouldn't be accepted. If you try to strip out the heart of the proposal, nobody is going to bite on it, thus no consensus, thus no change. Unless you've got a reasonable number of people (eg: more than one) wanting a certain amendment, I don't see why it would hit the ballot. > I am more concerned about "oh hey we reached X number of people with > their names on the document, so there's no reason to have discussion > on the mailing list, or a vote; the proposal to change our practices > is 'deemed as passed'. Done. From now on we do this [this way]. Nobody is quelling discussion. You're just not discussing it. You'll note that the names on the list are the ones that do the bulk of the on-list discussing anyway and we've already talked about this. There will be a vote as well, although I stand by the statement that if we had 50% + 1 people sign the proposal a vote is a waste of time. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Thu Jun 23 18:49:55 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 23 Jun 2011 09:49:55 -0700 Subject: [csw-maintainers] proposal In-Reply-To: <1308792965-sup-4934@pinkfloyd.chass.utoronto.ca> References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca> <1308420263-sup-8511@pinkfloyd.chass.utoronto.ca> <1308482786-sup-7548@pinkfloyd.chass.utoronto.ca> <1308792965-sup-4934@pinkfloyd.chass.utoronto.ca> Message-ID: On Wed, Jun 22, 2011 at 6:47 PM, Ben Walton wrote: > ... > > Unless you've got a reasonable number of people (eg: more than one) > wanting a certain amendment, I don't see why it would hit the ballot. Because as you have pointed out, the people who pay attention and speak up on the list, are already in favor of the proposal as it is. The whole point of having voting in the first place, rather than just a "voice vote" on the list is to "poll" the wishes of people who do not speak up on the maintainers list. Also: it doesnt "harm" anything, to have an amendment on the ballot. if the silent folks dont want it, they wont vote for it. Allowing people more options in a vote, shouldnt be something you need to avoid. Rather, it should be favored. politicians who attempt to limit voters' choices, are politicians who manipulate the whole principles of democratic voting. From jcraig at opencsw.org Thu Jun 23 19:58:04 2011 From: jcraig at opencsw.org (Jonathan Craig) Date: Thu, 23 Jun 2011 13:58:04 -0400 Subject: [csw-maintainers] proposal In-Reply-To: References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca> <1308420263-sup-8511@pinkfloyd.chass.utoronto.ca> <1308482786-sup-7548@pinkfloyd.chass.utoronto.ca> <1308792965-sup-4934@pinkfloyd.chass.utoronto.ca> Message-ID: On Thu, Jun 23, 2011 at 12:49 PM, Philip Brown wrote: > politicians who attempt to limit voters' choices, are politicians who > manipulate the whole principles of democratic voting. Phil, I dont nearly have the time I would like to participate in this organization and you are one of the reasons that I am personally not vocal on this list. While most posts are constructive and attempt to help one further their issues your posts generally do not. I don't need you to lecture me on the evils of authoritative systems. The way you drone on with comments like the above implies that others have hidden agendas with aims to destroy the world as we know and your simply trying to save the unwashed masses from their machinations. Any post authored by you which is longer than a single word, "batched", tends to raise my blood pressure to unhealthy limits. The reason governing systems don't employ direct democracy is that it doesn't scale. We can't vote on every clause for every law we might elect to have. Voters tend to decide major issues: Automated publishing system vs. Human controlled w/ manual inspection. Once the main issue is decided then everyone digs in and crafts the best solution that fulfills this goal. To date, the only person I recall staking out a position that a manual process is preferred is you. For my two cents worth: Given the size of the group and the demands in terms of packages to support, automated publishing solutions turn a subjective process into an objective process. Any subjective control that needs to be wielded can be handled by the bug process. Increasing the ease and throughput of package development will be beneficial and is unlikely to bring an end to democracy. Not even the US IRS attempts to individually review every tax return. Automation, and the development of an effective exceptions process, allows one to handle this with increased efficiency. While you have whined incessantly on this list about amendments, I don't recall actually seeing an amendment. Stop complaining about how you should have the right to control the ballot before you start turning out some verbage. If your changes have merit, then people will listen and incorporate your ideas. Your current strategy seems to employ a delaying tactic in the hopes that everyone will get tired and leave so you may maintain the status quo. If you want to be heard, then lets see some original ideas that don't try to codify the status quo or stop whining about the downfall of the democratic state. If you instead choose to continue attacking the governing process or try to convince me of your virtue, don't bother as I'm tired of those tactics already. I'm sorry my post doesn't forward the discussion beyond stating: +1 to an automated process From phil at bolthole.com Thu Jun 23 23:39:32 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 23 Jun 2011 14:39:32 -0700 Subject: [csw-maintainers] proposal In-Reply-To: References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca> <1308420263-sup-8511@pinkfloyd.chass.utoronto.ca> <1308482786-sup-7548@pinkfloyd.chass.utoronto.ca> <1308792965-sup-4934@pinkfloyd.chass.utoronto.ca> Message-ID: Hi Jonathan, I was going to write more, but perhaps it is better for me to just write on the most important bits here: On Thu, Jun 23, 2011 at 10:58 AM, Jonathan Craig wrote: > Your current strategy seems > to employ a delaying tactic in the hopes that everyone will get tired > and leave so you may maintain the status quo. actually, just the opposite is true. I've been petitioning the board for an EARLIER vote on the related issues, for over a month now. They have been delaying things, and making things more complicated for voting for anything other than the new proposal. If you disbelieve this, then request access to the full archives of the board mailing list for the last 2 months. my first emails to them about getting a vote going, was back on may 9th I put forth a proposal for voting. I took the time to write up a template for general "proposal" type ballots. They are the ones who delayed things, and then, weeks later, finally brought forward a "vote" which was vastly different to the one I requested, in order to favor their position. Which is why I am complaining so strongly about manipulation of the voting process. If you wish to know more, then rather than attempting to summarize over 30 emails, I will repeat my suggestion that you request access to the full archives of the board mailing list. You might find my original email sent to them on may 9th, to be enlightening in the area of how you view my motivations on this. >?If you want to be > heard, then lets see some original ideas that don't try to codify the > status quo or stop whining about the downfall of the democratic state. I have been putting together something which will go out in a few hours. I was pondering whether or not to break it up into separate emails. But given that some people have complained when I send out my disagreements one email at a time, I'm trying to make a single email out of it. From ellson at opencsw.org Fri Jun 24 00:51:52 2011 From: ellson at opencsw.org (John Ellson) Date: Thu, 23 Jun 2011 18:51:52 -0400 Subject: [csw-maintainers] where is graphviz-2.28 ? Message-ID: <4E03C388.2070207@opencsw.org> If I'm being impatient, then I'm sorry, but I don't seem to be able to get graphviz-2.28 from the openCSW mirrors yet. Is there some problem? Also, I'm wondering why the catalog at http://www.opencsw.org/get-it/packages/ still shows a few 2.26.3 packages? graphviz2 2.26.3,REV=2010.08.05 Stub to the CSWgraphviz package graphvizdoc 2.26.3,REV=2010.08.05 Graphviz documentation graphvizgraphs 2.26.3,REV=2010.08.05 Graphviz example graphs These are no-arch packages, and they possibly haven't changed since 2.26.3, but they are provided from the latest 2.28.0 sources so I think they should be updated. John From phil at bolthole.com Fri Jun 24 01:04:39 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 23 Jun 2011 16:04:39 -0700 Subject: [csw-maintainers] where is graphviz-2.28 ? In-Reply-To: <4E03C388.2070207@opencsw.org> References: <4E03C388.2070207@opencsw.org> Message-ID: On Thu, Jun 23, 2011 at 3:51 PM, John Ellson wrote: > If I'm being impatient, then I'm sorry, but I don't seem to be able to get > graphviz-2.28 from the openCSW mirrors yet. ?Is there some problem? > Ah, my apologies. sorry for the lack of feedback on this one. there would seem to indeed be a problem. ERROR 1062 (23000) at line 34: Duplicate entry '/opt/csw/bin/compare' for key 1 DB Update failed. Possibly a filename collision our search page, shows CSWschilyutils /opt/csw/bin/compare CSWimagemagick /opt/csw/bin/compare Should I release "all the rest", but hold off on the imagemagic packages until we figure out what to do about that one? Or hold everything in your very large set (51 packages)until that is redone? From ellson at opencsw.org Fri Jun 24 01:24:11 2011 From: ellson at opencsw.org (John Ellson) Date: Thu, 23 Jun 2011 19:24:11 -0400 Subject: [csw-maintainers] where is graphviz-2.28 ? In-Reply-To: References: <4E03C388.2070207@opencsw.org> Message-ID: <4E03CB1B.9020408@opencsw.org> On 06/23/2011 07:04 PM, Philip Brown wrote: > On Thu, Jun 23, 2011 at 3:51 PM, John Ellson wrote: >> If I'm being impatient, then I'm sorry, but I don't seem to be able to get >> graphviz-2.28 from the openCSW mirrors yet. Is there some problem? >> > Ah, my apologies. sorry for the lack of feedback on this one. > > there would seem to indeed be a problem. > > ERROR 1062 (23000) at line 34: Duplicate entry '/opt/csw/bin/compare' for key 1 > DB Update failed. Possibly a filename collision > > our search page, shows > CSWschilyutils /opt/csw/bin/compare > CSWimagemagick /opt/csw/bin/compare > > Should I release "all the rest", but hold off on the imagemagic > packages until we figure out what to do about that one? > Or hold everything in your very large set (51 packages)until that is redone? I think imagemagic has to be released at the same time, because the old version won't work with the new graphviz libs. Possibly just /opt/csw/bin/compare can be excluded, but this is upto Dago. Can you explain the other issue with the version numbers on the noarch packages? Or is it just that the update stopped half way, or is there some other problem? John From phil at bolthole.com Fri Jun 24 01:32:08 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 23 Jun 2011 16:32:08 -0700 Subject: [csw-maintainers] where is graphviz-2.28 ? In-Reply-To: <4E03CB1B.9020408@opencsw.org> References: <4E03C388.2070207@opencsw.org> <4E03CB1B.9020408@opencsw.org> Message-ID: On Thu, Jun 23, 2011 at 4:24 PM, John Ellson wrote: > > > I think imagemagic has to be released at the same time, because the old > version won't work with the new graphviz libs. > Possibly just ? /opt/csw/bin/compare can be excluded, but this is upto Dago. okay, holding ALL 51 packages :( > Can you explain the other issue with the version numbers on the ?noarch > packages? ?Or is it just that the update stopped half way, or is there some > other problem? sorry, dont understand/recall what you are referring to there. From bwalton at opencsw.org Fri Jun 24 02:19:19 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 23 Jun 2011 20:19:19 -0400 Subject: [csw-maintainers] proposal In-Reply-To: References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca> <1308420263-sup-8511@pinkfloyd.chass.utoronto.ca> <1308482786-sup-7548@pinkfloyd.chass.utoronto.ca> <1308792965-sup-4934@pinkfloyd.chass.utoronto.ca> Message-ID: <1308874720-sup-1393@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Jun 23 17:39:32 -0400 2011: > actually, just the opposite is true. I've been petitioning the board > for an EARLIER vote on the related issues, for over a month > now. They Yes, we've been seeing the same things on board@ as we get on maintainers at . Things like "good news, I solved the problem with this so we can keep a human release manager," etc...eg: working diligently to derail this. The vote writeup you did was an attempt at this. I _want_ you to do this writeup as much as possible as that removes avenues for complaint later. What I'm not going to allow is for this to be hijacked and derailed by changing the content of the vote. Admittedly, I've been slow in handling some of this this. There are a few reasons for that, not the least of which is that it's absolutely painful moving forward as I know that each step is met with the same thing. > If you disbelieve this, then request access to the full archives of > the board mailing list for the last 2 months. Anyone that wishes may see this. There's nothing to hide there. > my first emails to them about getting a vote going, was back on may > 9th The vote will open on Monday the 27th. That should be plenty of time to wrap up any discussion assuming you get your proposed amendments out tonight. If real back and forth debate is still happening at that time, we can delay. Real debate would be welcome. I'm going to be thrilled when this is settled though as there are other OpenCSW things I'd like to spend time on. > I put forth a proposal for voting. I took the time to write up a > template for general "proposal" type ballots. They are the ones who > delayed things, and then, weeks later, finally brought forward a > "vote" which was vastly different to the one I requested, in order > to favor their position. The problem here is that you didn't request a vote. You knew a vote was coming and tried to steer it away from the heart of what we put forward. We can and will use this template that you have put together although the wording will need work as we will be voting on the proposal, not your wish for status quo. As in many other cases, I'm done discussing this with you unless you advance something useful to the discussion. By useful, I mean constructive. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Fri Jun 24 02:49:59 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 23 Jun 2011 17:49:59 -0700 Subject: [csw-maintainers] proposal In-Reply-To: <1308874720-sup-1393@pinkfloyd.chass.utoronto.ca> References: <1308404814-sup-2642@pinkfloyd.chass.utoronto.ca> <1308420263-sup-8511@pinkfloyd.chass.utoronto.ca> <1308482786-sup-7548@pinkfloyd.chass.utoronto.ca> <1308792965-sup-4934@pinkfloyd.chass.utoronto.ca> <1308874720-sup-1393@pinkfloyd.chass.utoronto.ca> Message-ID: On Thu, Jun 23, 2011 at 5:19 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Thu Jun 23 17:39:32 -0400 2011: > >> actually, just the opposite is true. I've been petitioning the board >> for an EARLIER vote on the related issues, for over a month >> now. They > > Yes, we've been seeing the same things on board@ as we get on > maintainers at . ?Things like "good news, I solved the problem with this > so we can keep a human release manager,"[....] > > The vote writeup you did was an attempt at this. ?I _want_ you to do > this writeup as much as possible as that removes avenues for complaint > later. ?What I'm not going to allow is for this to be hijacked and > derailed by changing the content of the vote. > What you really seem be saying here is, "What I'm not going to allow, is for a vote on whether or not to keep a human release manager", even if everything else about the "new process", migration to current, etc. is kept intact. Which is exactly what I've been saying; you are controlling and limiting voting choices. To diffuse other people's accusations about "It's all about Phil trying to keep control": I don't care whether the release manager is me, or someone else. Frankly, I'm rather tired of dealing with it myself. I speak up for it, because I honestly believe that opencsw is better off with *A* release manager, or a release manager group **in addition to** automation, vs pure automation all by itself. Anyways. next email is my? proposed amendments From phil at bolthole.com Fri Jun 24 02:53:21 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 23 Jun 2011 17:53:21 -0700 Subject: [csw-maintainers] amendments and issues with recent prop Message-ID: Since the recent thread had gotten filled up with some things that were only semi-relevant to the direct issue, or in some cases not at all relevant, I thought it would be useful if I started a fresh thread. The following are some proposed amendments to the proposal given at http://wiki.opencsw.org/automated-release-proposal Each item below is a separate issue; this email is a collection of suggested amendments, not an "all or nothing" document. Some items are related to specific wording of the proposal. Other items are related to technical issues that need to be addressed. It is possible that some problems have arisen due to some maintainers potentially misunderstanding how things *currently* work. Some of the items below might help spread knowledge around more widely. Sorry that this is long: however, people complain when I break things up into smaller emails also, so it's a lose-lose situation no matter what I do. Wording problems are grouped in the first section, technical issues are grouped in the later section. 1. Amendment: more technical details need to be given. (perhaps as a side referenced document) The proposal suggests that opencsw adopt a "new system", without *fully* *defining* this new system at a technical level. There are some technical specifics, but not full coverage. There is a lot of [will do, in the future] language without giving specifics. OpenCSW is supposed to be a technical organization. It seems to me that we should be voting on specific full technical implementations, rather than something with fuzzy chunks in it 2. Amendment: Removal of "Anyone can participate[in the new process]", and related lines. This line falsely implies that currently, people are somehow blocked from participating now. This is untrue, both at the direct package level and at the discussion level, as shown below. Therefore this red herring should be removed. (and possibly, maintainers should be re-informed of some facts): At the discussion level, all packages "held" from release, are discussed in the pkgsubmissions mail list. Right now, "anyone can participate" in the discussion of a held package. At the direct package participation level: If a maintainer chooses to have their packages examined/tested before pushing them out to the general public, they can already drop them in "experimental" and ask that people look at them before publicly pushing them out to newpkgs. The fact that others rarely choose look at them now when a maintainer requests feedback, is not a failure of the current system, but rather an indication that maintainers rarely choose to look at other people's packages. It is doubtful that a wholesale "new system" will change that. If people rarely even look at packages when a maintainer *specifically requests* feedback, it seems less likely when the whole thing is automated and there is no explicit request to do so. 3. Removal or adjustment of "Packages are subject to stalls or rejections for non-policy reasons." First of all, it implies, FALSELY, that a package can be completely rejected by the release manager with no recourse. As formalized in http://wiki.opencsw.org/release-manager , a maintainer can always call for a vote if they disagree with the stance that the release manager has taken. This has already happened, twice, and after the vote, the package(s) were released, so it is a proven effective method. Additionally, it does not recognize the benefit that policy is not and should not be set in stone for all time. If a release manager holds a package, for reasons that are not currently policy, but perhaps should be, then it is a good thing that discussion take place. Similarly, it is actually a good thing if the issue gets forced to a vote, because that way, policy can be officially adjusted, as the majority vote decides. 4. Removal of "All code, tools and documentation will available for all to see and improve." This falsely implies that there is "hidden code and/or tools". There is not. All code that is actually necessary for the release process is already completely public and published. Most other stuff isnt strictly "published", but is readable by any maintainer who actually cares, in my home directory on bender. It isnt much more than convenient aliases,etc. I have, akin to aliases in a .bashrc, etc. The release process as a whole has been fully documented also. If anyone cares to dispute this, then please point out specific areas or tools that either lack documentation, or are hidden. I have previously requested this, when this claim was made recently, but was only met with groundless mumblings that things were still somehow "hidden", without any specifics given. 5. Removal of "unclear path to resolution of disputes" claim. There is actually a clear path: discussion on pkgsubmissions list -> discussion on maintainers list -> vote if needed. As far as complexity, this is virtually identical to the "new" path to resolution. The main difference is only that under the current system, a package deemed as "bad" will never be released, whereas under the "new" system, a package deemed as "bad" will first be released publically, but then after some indeterminate length of time.. potentially a **month or more**.. eventually be retracted. 6. Removal or adjustment of "All participants will have equal standing". It would actually be harmful to opencsw to follow that sentiment completely. Specifically, to have two new maintainers sign off on each others packages, will inevitably lead to some mistakes that could be avoided by the oversight of more experienced maintainers. 7. A technical implementation issue, that is not properly addressed in the proposal: There is no such thing as a *fully* automated release system: at some point, issues come up that require manual intervention. For example, package renames, and removals. or fixing bugs in some unforseen interaction of the system and a new package. The proposal declares that catalog signatures will be generated automatically. However, who or what group will be responsible to manage the catalog when the automated system is either inadequate, or fails? 8. A technical implementation issue not addressed at all in the proposal: What about package takeovers? is it going to be allowable for any maintainer to take over any package, at any time? or remove any package at any time? 9. A technical implementation issue not addressed at all in the proposal: "A package may not progress from unstable to current with open bugs." It has been written elsewhere, that this progress will be automated, after (2 weeks time). However, what about the problem when two new upgrades are released together, as follows: libA1(.1) upgrades libA1(.0) libB1(.1) upgrades libB1(.0), and depends on libA1. It FAILS if run against the older libA1.0 [ I am using the (.1, .0) syntax above, to indicate minor rev changes to the hypothetical libraries, where the SONAME does not change. ] A bug is filed against libA1(.1) The bug is not addressed within 2 weeks. (lets say the bug is filed on the 13th day) However, libB1(.1) has no bugs filed. It then gets auto-migrated to current. Where it will then be non-functional, and break everything depending on "libB1" I have used the example of shared libraries here, but the problem is generic, for any time that two packages are pending migration from unstable to current at the same time, with one dependent on the other. It could well be that they are from completely diferent maintainers. maintainer A, releases libA1 update to unstable. a day or two later, maintainer B updates libB1 based on that update, and releases libB1 to unstable. 12 days later, libA1 is blocked from release to current, but libB1 will sail through 2 days later. Note that this is particularly important when someone decides to do a "complicated" upgrade set that has 10, 20, 30 or more packages 10. technical implementation suggestion: If the goal is to make it *easier* for people to get involved in the QA process, I would suggest that either a different mechanism than bug filing be used, OR an alternative interface to the bug system be provided. I personally feel that the existing "exchange emails over the pkgsubmissions mailing list" is the smallest pain point in this sort of process. Forcing people to move to (our existing) bug system for this kind of discussion, makes it *more* difficult, not easier, to be involved in QA, in my opinion. It's possible other bug systems would do better; I'm just limiting my comments to our existing one. 11. technical implementation issue: "By opening up the QA process such that multiple people can easily participate and have equal standing on the matters at hand, we feel that overall package quality will improve;" Unfortunately, (as mentioned on maintainers list previously), making the capability available, does not actually mean that people will definitely make use of it. The new proposal as prototyped, currently allows for LESS people to scrutinize a package than currently. At the moment, a release manager is guaranteed to at least glance at it. Whereas with the "new process", a package may (and I claim, will *usually*) get released with no-one but the maintainer ever looking at it. If the goal is truly, "more/better QA", then a proposed remedy for this, is to put in mandatory hooks for the "migrate from unstable to current" step, to require that at least one other person besides maintainer has examined the package. If on the other hand, the goal is really "to allow packages to be released with no one but the maintainer ever looking at it", then all claims about better QA should be removed from the proposal, and the stated "benefits" of the proposal should be updated to reflect that. From bonivart at opencsw.org Fri Jun 24 11:22:45 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 24 Jun 2011 11:22:45 +0200 Subject: [csw-maintainers] /testing SpamAssassin 3.3.2 (Fwd: ANNOUNCE: Apache SpamAssassin 3.3.2 available) Message-ID: There's new packages to test in: http://buildfarm.opencsw.org/experimental.html#spamassassin /peter ---------- Forwarded message ---------- From: Warren Togami Date: Fri, Jun 24, 2011 at 1:40 AM Subject: ANNOUNCE: Apache SpamAssassin 3.3.2 available To: announce at spamassassin.apache.org Release Notes -- Apache SpamAssassin -- Version 3.3.2 Introduction ------------ This is a minor release, primarily to support perl-5.12 and later. Additionally several other minor bugs are fixed. Downloading and availability ---------------------------- Downloads are available from: http://spamassassin.apache.org/downloads.cgi md5sum of archive files: ?253f8fcbeb6c8bfcab9d139865c1a404 ?Mail-SpamAssassin-3.3.2.tar.bz2 ?d1d62cc5c6eac57e88c4006d9633b81e ?Mail-SpamAssassin-3.3.2.tar.gz ?06d84d34834d9aecdcdffcc4de08b2a7 ?Mail-SpamAssassin-3.3.2.zip ?72f8075499c618518c68c7399f02b458 Mail-SpamAssassin-rules-3.3.2-r1104058.tar.gz sha1sum of archive files: ?f38480352935fe3bb849a27a52615e400dee7d66 ?Mail-SpamAssassin-3.3.2.tar.bz2 ?de954f69e190496eff4a796a9bab61747f03072b ?Mail-SpamAssassin-3.3.2.tar.gz ?edc6297dc651eeb7a4872f596ec5a54aeea85349 ?Mail-SpamAssassin-3.3.2.zip ?a199d5f0f8c2381e3dfe421e7a774356b3ffda4b Mail-SpamAssassin-rules-3.3.2-r1104058.tar.gz Note that the *-rules-*.tar.gz files are only necessary if you cannot, or do not wish to, run "sa-update" after install to download the latest fresh rules. See the INSTALL and UPGRADE files in the distribution for important installation notes. GPG Verification Procedure -------------------------- The release files also have a .asc accompanying them. ?The file serves as an external GPG signature for the given release file. ?The signing key is available via the wwwkeys.pgp.net key server, as well as http://www.apache.org/dist/spamassassin/KEYS The key information is: pub ? 4096R/F7D39814 2009-12-02 ? ? ?Key fingerprint = D809 9BC7 9E17 D7E4 9BC2 ?1E31 FDE5 2F40 F7D3 9814 uid ? ? ? ? ? ? ? ? ?SpamAssassin Project Management Committee uid ? ? ? ? ? ? ? ? ?SpamAssassin Signing Key (Code Signing Key, replacement for 1024D/265FA05B) sub ? 4096R/7B3265A5 2009-12-02 To verify a release file, download the file with the accompanying .asc file and run the following commands: ?gpg -v --keyserver wwwkeys.pgp.net --recv-key F7D39814 ?gpg --verify Mail-SpamAssassin-3.3.2.tar.bz2.asc ?gpg --fingerprint F7D39814 Then verify that the key matches the signature. Note that older versions of gnupg may not be able to complete the steps above. Specifically, GnuPG v1.0.6, 1.0.7 & 1.2.6 failed while v1.4.11 worked flawlessly. See http://www.apache.org/info/verification.html for more information on verifying Apache releases. Summary of major changes since 3.3.1 ------------------------------------ NOTE: Complete changes are available at http://svn.apache.org/repos/asf/spamassassin/branches/3.3/Changes Bug #6353: Fix FH_FROMEML_NOTLD, add MISSING_FROM Bug #6427: Spamc windows header library missing two defines. Bug #6476: patch to fix missing sa-awl man page bug Bug #6470: Small change in windows to exit stating that the exit status is unknown. ?Thanks to Daniel Lemke for many of these small win32 patches. Bug #6314: Complete removal of spamassassin.spec Bug #6589: Errors in man pages Bug #6588: Small bug in the regexp caught by Jose Borges Ferreira in Bug #6515: spamd timeout_child option overrides time_limit configuration option with nastier behaviour Bug #6490: Mail::SpamAssassin::Plugin::SPF - Two enhancement issues Bug #6562: NULL reference bug in libspamc. Quick workaround to avoid a crash. Bug #6454: wrong status test on $sth->rows in BayesStore::PgSQL Bug #6418: Cannot Log to stderr without timestamps Bug #6403: GMail should use ESMTPSA to indicate that it is in fact authenticated, but doesn't Bug #6229: TextCat is too case sensitive Bug #6241: mkrules does not understand newer options and "else" Bug #6382: add missing unwhitelist_from_dkim, remove facebook and linkedin from dkim whitelisting Bug #5744: some documentation fixes Bug #6447: new feature to bayes autolearning: learn-on-error Bug #6566: X-Ham-Report default wording ("has identified this incoming email as possible spam") is confusing and inaccurate Bug #6468: splice() offset past end of array in HTML.pm Bug #6377: win32: spamd signal handling Bug #6376: win32: consider negative pids under windows in spamds waitpid Bug #6375: win32: posix macro not implemented - spamd Bug #6336: "Illegal octal digit 9" received during rules compile Bug #6526: Disable rfc-ignorant.org Bug #6531: clear_uridnsbl_skip_domain feature to allow admin override of default configuration Bug #5491: MIME_QP_LONG_LINE triggering on valid email Bug #6558: body rules having "tflags multiple" may cause infinite loop when compiled - a workaround Bug #6557: Use same age limits in ruleqa as in sa-updates Bug #6548: spamd protocol examples are wrong Bug #6500: clear_originating_ip_headers seems to be broken Bug #6565: check_rbl_sub rules - all dots need to be escaped - commit felicity/70_dnswl.cf and felicity/70_iadb.cf too Bug #6565: check_rbl_sub rules - all dots need to be escaped Bug #6578: Move TLD regexp to RegistrarBoundaries and make FreeMail use it Bug #6392: fix one more case of a 'goto into a construct' this one occured with sa-compile Bug #6443: Metadata Headers are Case-Sensitive Bug #5690: tune BAD_ENC_HEADER score down Bug #6022, tune TVD_RCVD_IP score down Bug #6394: too high score for FREEMAIL_ENVFROM_END_DIGIT Bug #6499: and mailing list: wrapped scores for rules DKIMDOMAIN_IN_DWL*, ACCESSDB and SHORTCIRCUIT into a suitable ifplugin/endif to avoid lint warnings; removed score for nonexistent rule SUBJ_RE_NUM. Bug #6242: merge the boundary fix in r931527 to the 3.3 branch Bug #6460: RCVD_ILLEGAL_IP false positives Bug #6506: Modifying a list while traversing it with a foreach Bug #6488: Lint errors with Perl 5.12.1 in AntiVirus.pm Bug #6467: Remove assigned 223/8 from RCVD_ILLEGAL_IP Bug #6419: Resolve rounding issue irregularity with spamd/spamc Bug #5894: spamd doesn't use vpopmail virtual users' dirs - removed one extra space Bug #6416: avoid undef warnings in AutoWhitelist.pm as a result of incorrect Received header field or its incorrect parsing Bug #6415: Open of auto-whitelist file failed: Insecure dependency in eval Bug #6299: update, enhance, and expand RCVD_ILLEGAL_IP from Bug #6392: Test suite fails with perl 5.12.0 Bug #6412: remove .yu TLD and add .me SLDs Bug #6395: backport - improved URI parsing Bug #6393: make File::Copy module load conditional on 'sa-learn --upgrade' with DBM files, not very commonly used Bug #6396: Use of uninitialized value in lc at lib/Mail/SpamAssassin/Plugin/MIMEEval.pm About Apache SpamAssassin ------------------------- Apache SpamAssassin is a mature, widely-deployed open source project that serves as a mail filter to identify spam. SpamAssassin uses a variety of mechanisms including mail header and text analysis, Bayesian filtering, DNS blocklists, and collaborative filtering databases. In addition, Apache SpamAssassin has a modular architecture that allows other technologies to be quickly incorporated as an addition or as a replacement for existing methods. Apache SpamAssassin typically runs on a server, classifies and labels spam before it reaches your mailbox, while allowing other components of a mail system to act on its results. Most of the Apache SpamAssassin is written in Perl, with heavily traversed code paths carefully optimized. Benefits are portability, robustness and facilitated maintenance. It can run on a wide variety of POSIX platforms. The server and the Perl library feels at home on Unix and Linux platforms, and reportedly also works on MS Windows systems under ActivePerl. For more information, visit http://spamassassin.apache.org/ About The Apache Software Foundation ------------------------------------ Established in 1999, The Apache Software Foundation provides organizational, legal, and financial support for more than 100 freely-available, collaboratively-developed Open Source projects. The pragmatic Apache License enables individual and commercial users to easily deploy Apache software; the Foundation's intellectual property framework limits the legal exposure of its 2,500+ contributors. For more information, visit http://www.apache.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: announce-unsubscribe at spamassassin.apache.org For additional commands, e-mail: announce-help at spamassassin.apache.org From bwalton at opencsw.org Fri Jun 24 15:13:34 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 24 Jun 2011 09:13:34 -0400 Subject: [csw-maintainers] gar tip Message-ID: <1308921100-sup-6070@pinkfloyd.chass.utoronto.ca> Hi All, Peter and I just realized that not everyone is aware of the templated GAR recipe feature. In opencsw/ (or opencsw/cpan, etc), you can type: gmake newpkg-foo This will give you a templated base recipe file. It's custom to each specialized category (cpan, etc) so that things like gmake newpkg-Some::Cool:Perl will generate a recipe for CSWpm-some-cool-perl/pm_some_cool_perl, etc. It should save you some typing and give you a standard base recipe to start from. HTH. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From ellson at opencsw.org Fri Jun 24 15:49:16 2011 From: ellson at opencsw.org (John Ellson) Date: Fri, 24 Jun 2011 09:49:16 -0400 Subject: [csw-maintainers] where is graphviz-2.28 ? In-Reply-To: References: <4E03C388.2070207@opencsw.org> <4E03CB1B.9020408@opencsw.org> Message-ID: <4E0495DC.2070508@opencsw.org> On 06/23/2011 07:32 PM, Philip Brown wrote: > On Thu, Jun 23, 2011 at 4:24 PM, John Ellson wrote: >> >> >> I think imagemagic has to be released at the same time, because the old >> version won't work with the new graphviz libs. >> Possibly just /opt/csw/bin/compare can be excluded, but this is upto Dago. > > okay, holding ALL 51 packages :( Ok. Dago said he would fix this asap, when he gets back. > > >> Can you explain the other issue with the version numbers on the noarch >> packages? Or is it just that the update stopped half way, or is there some >> other problem? > > sorry, dont understand/recall what you are referring to there. If you go to: http://www.opencsw.org/get-it/packages/ and search for "graphviz" you will see that the graphviz-2.28 packages are already posted *except* for the 3 noarch packages which are still at 2.26.3 Why are any 2.28 packages posted if the release is blocked? Or, conversely, why aren't all 2.28 packages posted? John From phil at bolthole.com Fri Jun 24 16:00:51 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 24 Jun 2011 07:00:51 -0700 Subject: [csw-maintainers] where is graphviz-2.28 ? In-Reply-To: <4E0495DC.2070508@opencsw.org> References: <4E03C388.2070207@opencsw.org> <4E03CB1B.9020408@opencsw.org> <4E0495DC.2070508@opencsw.org> Message-ID: On Fri, Jun 24, 2011 at 6:49 AM, John Ellson wrote: > >>> Can you explain the other issue with the version numbers on the ?noarch >>> packages? ?Or is it just that the update stopped half way, or is there >>> some >>> other problem? >> >> sorry, dont understand/recall what you are referring to there. > > > If you go to: > > ?http://www.opencsw.org/get-it/packages/ > > and search for "graphviz" you will see that the graphviz-2.28 packages are > already posted *except* for the 3 noarch packages which are still at 2.26.3 ah. yes, your guess is right, that's just where the update stopped, there is no problem with the ARCH=all packages that I am aware of. From bonivart at opencsw.org Fri Jun 24 16:04:29 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 24 Jun 2011 16:04:29 +0200 Subject: [csw-maintainers] where is graphviz-2.28 ? In-Reply-To: References: <4E03C388.2070207@opencsw.org> <4E03CB1B.9020408@opencsw.org> <4E0495DC.2070508@opencsw.org> Message-ID: On Fri, Jun 24, 2011 at 4:00 PM, Philip Brown wrote: > ah. yes, your guess is right, that's just where the update stopped, So why did you say that it was batched then? /peter From phil at bolthole.com Fri Jun 24 16:31:49 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 24 Jun 2011 07:31:49 -0700 Subject: [csw-maintainers] where is graphviz-2.28 ? In-Reply-To: References: <4E03C388.2070207@opencsw.org> <4E03CB1B.9020408@opencsw.org> <4E0495DC.2070508@opencsw.org> Message-ID: On Fri, Jun 24, 2011 at 7:04 AM, Peter Bonivart wrote: > On Fri, Jun 24, 2011 at 4:00 PM, Philip Brown wrote: >> ah. yes, your guess is right, that's just where the update stopped, > > So why did you say that it was batched then? unfortunately, I emailed prematurely. Normally, I wait until after the "register in database and copy over" stuff is complete, but in this case, since it was such a huge batch, (which probably takes over 10 mins to complete, rather than the usual <1 min) I must have kicked off that stuff, sent the email to let John know I had touched it, and then moved on to do other things. I should better have written "batching", I suppose. From bonivart at opencsw.org Fri Jun 24 16:37:56 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 24 Jun 2011 16:37:56 +0200 Subject: [csw-maintainers] where is graphviz-2.28 ? In-Reply-To: References: <4E03C388.2070207@opencsw.org> <4E03CB1B.9020408@opencsw.org> <4E0495DC.2070508@opencsw.org> Message-ID: On Fri, Jun 24, 2011 at 4:31 PM, Philip Brown wrote: > I should better have written "batching", I suppose. No, you should have said what was wrong with it. You didn't follow through with the batching but never updated the status either so the maintainer was just left waiting for it to appear on the mirrors which would have never happened. /peter From ellson at opencsw.org Fri Jun 24 17:10:26 2011 From: ellson at opencsw.org (John Ellson) Date: Fri, 24 Jun 2011 11:10:26 -0400 Subject: [csw-maintainers] where is graphviz-2.28 ? In-Reply-To: References: <4E03C388.2070207@opencsw.org> <4E03CB1B.9020408@opencsw.org> <4E0495DC.2070508@opencsw.org> Message-ID: <4E04A8E2.1060602@opencsw.org> On 06/24/2011 10:37 AM, Peter Bonivart wrote: > On Fri, Jun 24, 2011 at 4:31 PM, Philip Brown wrote: >> I should better have written "batching", I suppose. > > No, you should have said what was wrong with it. You didn't follow > through with the batching but never updated the status either so the > maintainer was just left waiting for it to appear on the mirrors which > would have never happened. > > /peter I'm sure Philip is doing the best he could under a heavy workload. I'm more concerned that the failed batching process: a) failed because of checks that should have been done much earlier in the process. b) left the web pages in an inaccurate and inconsistent state. John From jcraig at opencsw.org Fri Jun 24 17:30:00 2011 From: jcraig at opencsw.org (Jonathan Craig) Date: Fri, 24 Jun 2011 11:30:00 -0400 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: Message-ID: On Thu, Jun 23, 2011 at 8:53 PM, Philip Brown wrote: > > Sorry that this is long: however, people complain when I break things > up into smaller emails also, so it's a lose-lose situation no matter > what I do. Yes, we know you are a misunderstood hero. > 1. Amendment: more technical details need to be given. > ?(perhaps as a side referenced document) > ?The proposal suggests that opencsw adopt a "new system", without > *fully* *defining* this new system at a technical level. There are > some technical specifics, but not full coverage. > ?There is a lot of [will do, in the future] language without giving specifics. > ?OpenCSW is supposed to be a technical organization. It seems to me > that we should be voting on specific full technical implementations, > rather than something with fuzzy chunks in it First, this isn't an amendment its a complaint. An amendment would be to start producing the technical details not lament their absence. This is a volunteer organization and not a fortune 100 conglomerate who can afford to pour millions into development of supporting systems like this. This aspect of OpenCSW is a sideshow for what the organization is all about, namely turning out packages for end users. To suggest that something be fully spec'd out and voted upon is to declare "let's do nothing" as nobody has that kind of time or interest (IMHO). This amounts to a stalling tactic designed to paralyze progress. > > 2. Amendment: Removal of "Anyone can participate[in the new process]", > and related lines. > This line falsely implies that currently, people are somehow blocked > from participating now. > This is untrue, both at the direct package level and at the discussion > level, as shown below. Therefore this red herring should be removed. > (and possibly, maintainers should be re-informed of some facts): > > ? At the discussion level, all packages "held" from release, are > discussed in the pkgsubmissions mail list. > ? Right now, "anyone can participate" in the discussion of a held package. > > ?At the direct package participation level: > ? If a maintainer chooses to have their packages examined/tested > before pushing them out to the general public, they can already drop > them in "experimental" and ask that people look at them before > publicly pushing them out to newpkgs. > > ?The fact that others rarely choose look at them now when a > maintainer requests feedback, is not a failure of the current system, > but rather an indication that maintainers rarely choose to look at > other people's packages. It is doubtful that a wholesale "new system" > will change that. > > If people rarely even look at packages when a maintainer *specifically > requests* feedback, it seems less likely when the whole thing is > automated and there is no explicit request to do so. > What is troubling is that one all powerful being gets to arbitrarily block someone progress and force them to beg for support and understanding. As to participation, it is already stated that a third party (you if you care to) can file a bug and seek changes prior to publication. You may always appeal closed bugs on the list if you feel a maintainer is abusing their maintainer power. If a maintainer is uncooperative and releases poor packages this will be born out in the bug tracker. If the current bug tracker is too cumbersome then maybe we should look at another, such as Jira. > > 3. Removal or adjustment of "Packages are subject to stalls or > rejections for non-policy reasons." > > First of all, it implies, FALSELY, that a package can be completely > rejected by the release manager with no recourse. As formalized in > http://wiki.opencsw.org/release-manager , a maintainer can always call > for a vote if they disagree with the stance that the release manager > has taken. This has already happened, twice, and after the vote, the > package(s) were released, so it is a proven effective method. > > Additionally, it does not recognize the benefit that policy is not and > should not be set in stone for all time. If a release manager holds a > package, for reasons that are not currently policy, but perhaps should > be, then it is a good thing that discussion take place. Similarly, it > is actually a good thing if the issue gets forced to a vote, because > that way, policy can be officially adjusted, as the majority vote > decides. > Automation doesn't fix policy for all time as it can grow and change along with our understanding. What it does is force policies to be codified and enforced by an inanimate process without the ability to adjust policy on a whim. > 4. Removal of "All code, tools and documentation will available for > all to see and improve." > ?This falsely implies that there is "hidden code and/or tools". There is not. > ?All code that is actually necessary for the release process is > already completely public and published. > ?Most other stuff isnt strictly "published", but is readable by any > maintainer who actually cares, in my home > ?directory on bender. It isnt much more than convenient aliases,etc. I > have, akin to aliases in a .bashrc, etc. > > The release process as a whole has been fully documented also. > If anyone cares to dispute this, then please point out specific areas > or tools that either lack documentation, or are hidden. ? I have > previously requested this, when this claim was made recently, but was > only met with groundless mumblings that things were still somehow > "hidden", without any specifics given. This is simply defensive. I don't care if its fully documented my experience leads me to believe that an automated approach will be less frustrating and more deterministic. I want the comfort of having my package pass all known tests and flowing through without me wondering whether I've forgotten something. The more this relies on human interaction the less likely it will be that the automated checks will be put in place to help me turn out more packages quicker with better quality. > 5. Removal of "unclear path to resolution of disputes" claim. > ?There is actually a clear path: > ?discussion on pkgsubmissions list -> discussion on maintainers list > -> vote if needed. > ?As far as complexity, this is virtually identical to the "new" path > to resolution. The main difference is only that under the current > system, a package deemed as "bad" will never be released, whereas > under the "new" system, a package deemed as "bad" will first be > released publically, but then after some indeterminate length of > time.. potentially a **month or more**.. eventually be retracted. Yes, the process begins with a public flogging that feels like a "oh, you dumb shit you forgot" even when that wasn't the message intended. When a piece of code tells me I cant submit a package that is uncommitted, I say, "Oh doh, I knew that" and fix it. When it gets posted to everyone for all time, I get frustrated. > > 6. Removal or adjustment of "All participants will have equal standing". > ?It would actually be harmful to opencsw to follow that sentiment > completely. Specifically, to have two new maintainers sign off on each > others packages, will inevitably lead to some mistakes that could be > avoided by the oversight of more experienced maintainers. > You can't have both sides of an argument unless your talking to yourself in a closet. You are both for full classless participation in a democratic process and then argue unless its two neophytes colluding to avoid doing the right thing. This is hardly a serious concern and the damage would be limited, IMHO. > > > 7. A technical implementation issue, that is not properly addressed in > the proposal: > > There is no such thing as a *fully* automated release system: at some > point, issues come up that require manual intervention. For example, > package renames, and removals. or fixing bugs in some unforseen > interaction of the system and a new package. > > The proposal declares that catalog signatures will be generated > automatically. However, who or what group will be responsible to > manage the catalog when the automated system is either inadequate, or > fails? Closest thing to a constructive request so far. This is of course voiced as a complaint instead of a fully formed and documented solution. I agree given the dynamics involved a group of SME's will need to be responsible for arbitrating breakdowns and enhancing the automation to accommodate future recurrences. "A group of subject matter experts will be established to support and maintain the release system. This group will be subordinate to the board and responsible for seeing that packaging policy to properly enforced by the release systems. In the event an unforeseen issue disrupts the release process they are empowered to manually augment the system to enable timely release of packages. Such manual intervention will be logged with the understanding that repeated manual intervention will require enhancements to the release system to accommodate routine exceptions." I think most would have thought that something like this was inherent to any automated solution, but it doesn't hurt to write a little verbage to outline expectations. > > 8. A technical implementation issue not addressed at all in the proposal: > What about package takeovers? is it going to be allowable for any > maintainer to take over any package, at any time? or remove any > package at any time? > Agreed, any release mechanism must have a method to accommodate package takeovers. It should do so in a manner consistent with published policy. Again, I see the complaint but no solution. That is of course unless your implying that a human release manager can handle this bit of nastiness as they see fit. Personally, having a clear process for taking over a package and an automated solution to enable "proper" takeover is better than doing this in the darkness of night. > 9. A technical implementation issue not addressed at all in the proposal: > > "A package may not progress from unstable to current with open bugs." > > It has been written elsewhere, that this progress will be automated, > after (2 weeks time). > However, what about the problem when two new upgrades are released > together, as follows: > ?libA1(.1) upgrades libA1(.0) > ?libB1(.1) upgrades libB1(.0), and depends on libA1. It FAILS if run > against the older libA1.0 > [ I am using the (.1, .0) syntax above, to indicate minor rev changes > to the hypothetical libraries, where the SONAME does not change. ] > > ?A bug is filed against libA1(.1) > ? The bug is not addressed within 2 weeks. (lets say the bug is filed > on the 13th day) > However, libB1(.1) has no bugs filed. It then gets auto-migrated to > current. Where it will then be non-functional, > and break everything depending on "libB1" > > I have used the example of shared libraries here, but the problem is > generic, for any time that two packages are pending migration from > unstable to current at the same time, with one dependent on the other. > It could well be that they are from completely diferent maintainers. > maintainer A, releases libA1 update to unstable. a day or two later, > maintainer B updates libB1 based on that update, and releases libB1 to > unstable. 12 days later, libA1 is blocked from release to current, but > libB1 will sail through 2 days later. > > Note that this is particularly important when someone decides to do a > "complicated" upgrade set that has 10, 20, 30 or more packages > This may prove too complicated to code and we might throw our hands in the air and give up. Or, someone may see this as an interesting dilemma and work on a process and some code to handle this kind of dependency. It would be nice if the maintainer could code these dependency into their submit and see that its handled to their wishes. That puts the maintainer in the drivers seat, where the responsibility belongs. > > 10. technical implementation suggestion: > > If the goal is to make it *easier* for people to get involved in the > QA process, I would suggest that either a different mechanism than bug > filing be used, OR an alternative interface to the bug system be > provided. > I personally feel that the existing "exchange emails over the > pkgsubmissions mailing list" is the smallest pain point in this sort > of process. > Forcing people to move to (our existing) bug system for this kind of > discussion, makes it *more* difficult, not easier, to be involved in > QA, in my opinion. It's possible other bug systems would do better; > I'm just limiting my comments to our existing one. Ah, but the bug system keeps the conversation on point. In a mail list an email is likely to get hijacked into a different directions when you begin a philosophical debate over which approach is "best". That is less likely to happen in the context of a bug report as the writer is conscious of the fact that this is all being filed against a specific instance. And the original maintainer may not even care about the philosophical differences they simply need to get a package published so they can get some other (possibly paid) work done. Like me, I build packages that by paying job needs, Not because packaging applications is "Fun!". > > 11. technical implementation issue: > > ?"By opening up the QA process such that multiple people can easily > participate and have equal standing on the matters at hand, we feel > that overall package quality will improve;" > > Unfortunately, (as mentioned on maintainers list previously), making > the capability available, does not actually mean that people will > definitely make use of it. > The new proposal as prototyped, currently allows for LESS people to > scrutinize a package than currently. Bullshit, it is your conjecture that apathy will rain and reduce involvement beyond the current level. If you choose to review and file bugs on every application that releases then it has the same level of critique. If you can get one other person to do the same (oh and by the way they cant today) then it doubles. > At the moment, a release manager is guaranteed to at least glance at > it. Whereas with the "new process", a package may (and I claim, will > *usually*) get released with no-one but the maintainer ever looking at > it. I glance at every release already, then I mark the email "read" unless its a package that holds interest to me. > > If the goal is truly, "more/better QA", then a proposed remedy for > this, is to put in mandatory hooks for the "migrate from unstable to > current" step, to require that at least one other person besides > maintainer has examined the package. > The automated system does allows for more/better QA as indicated above. If quality suffers then we can look at this enforcement. So far its not a policy of the organization and I doubt you would get much support for making it policy absent some reoccurring issue. > If on the other hand, the goal is really "to allow packages to be > released with no one but the maintainer ever looking at it", then all > claims about better QA should be removed from the proposal, and the > stated "benefits" of the proposal should be updated to reflect that. No the goal is to determine the problems and teach an automated system to apply this to every package, all the time. Not allow a handful (or one) person to arbitrarily decide to "look into" a package and place it on hold until their curiosity is satisfied. I can afford to call shenanigans on your post as I'm simply a maintainer of a handful of packages and at worst I'm risking a few future packages enduring more scrutiny as a result. I've been witness to these types of attempts to derail any progress you don't believe in. Your collection of amendments boil down to a list of complaints that point towards status quo. Do we need a vote that simply and plainly declares the organizations direction towards automated systems? I would think that the support the existing proposal has would make this fairly clear, but maybe you need more. If a vote is required I guess we could do that but do you really think you have an unvoiced constituency that will keep us on the path of a human centric release process, or will this essentially be another 7 - 14 day delaying tactic? From phil at bolthole.com Fri Jun 24 18:55:41 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 24 Jun 2011 09:55:41 -0700 Subject: [csw-maintainers] where is graphviz-2.28 ? In-Reply-To: <4E04A8E2.1060602@opencsw.org> References: <4E03C388.2070207@opencsw.org> <4E03CB1B.9020408@opencsw.org> <4E0495DC.2070508@opencsw.org> <4E04A8E2.1060602@opencsw.org> Message-ID: On Fri, Jun 24, 2011 at 8:10 AM, John Ellson wrote: > > I'm more concerned that the failed batching process: > > ? ? ? ?a) failed because of checks that should have been done much earlier > in the process. > > ? ? ? ?b) left the web pages in an inaccurate and inconsistent state. > yeah, it's "not pretty", registration wise. theoretically, name collision checks should already have been handled by gar. Just goes to show, that it's Not A Good Idea, to put 100% confidence in a single automated process. No process is 100% bug free. For QA purposes, it's a benefit to have 2 independant checks. in smaller batches of 1 or two packages, it's easy for me to re-register the "old" versions. For this huge thing, it's a considerable chunk of work. If there isnt going to be a quick (day or two) moving forward, then I will spend the time to de-rev the registrations. Otherwise, it seems simplest for me to just wait for the update and push the batch through. Which way would you recommend we go? From ellson at opencsw.org Fri Jun 24 20:55:09 2011 From: ellson at opencsw.org (John Ellson) Date: Fri, 24 Jun 2011 14:55:09 -0400 Subject: [csw-maintainers] where is graphviz-2.28 ? In-Reply-To: References: <4E03C388.2070207@opencsw.org> <4E03CB1B.9020408@opencsw.org> <4E0495DC.2070508@opencsw.org> <4E04A8E2.1060602@opencsw.org> Message-ID: <4E04DD8D.7050109@opencsw.org> On 06/24/2011 12:55 PM, Philip Brown wrote: > On Fri, Jun 24, 2011 at 8:10 AM, John Ellson wrote: >> I'm more concerned that the failed batching process: >> >> a) failed because of checks that should have been done much earlier >> in the process. >> >> b) left the web pages in an inaccurate and inconsistent state. >> > yeah, it's "not pretty", registration wise. > theoretically, name collision checks should already have been handled by gar. > Just goes to show, that it's Not A Good Idea, to put 100% confidence > in a single automated process. > No process is 100% bug free. For QA purposes, it's a benefit to have 2 > independant checks. > > in smaller batches of 1 or two packages, it's easy for me to > re-register the "old" versions. > For this huge thing, it's a considerable chunk of work. > If there isnt going to be a quick (day or two) moving forward, then I > will spend the time to de-rev the registrations. Otherwise, it seems > simplest for me to just wait for the update and push the batch > through. > > Which way would you recommend we go? > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > I'm assuming that the ImageMagic fix is small and that we should have a new set of packages in a few days, but Dago didn't say when he was going to be back. I'm not even so worried about the web pages on this occasion. It just seems to me that some scripts need to be fixed so that web updates are atomic and only happen if batching is successful. For this release of graphviz, I suggest just waiting a few days, and re batch. Thanks john From phil at bolthole.com Fri Jun 24 21:29:22 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 24 Jun 2011 12:29:22 -0700 Subject: [csw-maintainers] where is graphviz-2.28 ? In-Reply-To: <4E04DD8D.7050109@opencsw.org> References: <4E03C388.2070207@opencsw.org> <4E03CB1B.9020408@opencsw.org> <4E0495DC.2070508@opencsw.org> <4E04A8E2.1060602@opencsw.org> <4E04DD8D.7050109@opencsw.org> Message-ID: On Fri, Jun 24, 2011 at 11:55 AM, John Ellson wrote: > > I'm assuming that the ImageMagic fix is small and that we should have a new > set of packages in a few days, but Dago didn't say when he was going to be > back. > > I'm not even so worried about the web pages on this occasion. ? It just > seems to me that some scripts need to be fixed so that web updates are > atomic and only happen if batching is successful. Would be useful. However, at my utility script level, there is unfortunately no concept of a maintainer-grouped-batch at the moment. There is only individual-package visibility. As I said, this isnt a problem with smaller grouped packages, so there isnt much incentive to write something fancier. I could in theory write something that would be more package-group aware. However, it would probably involve a lot of saved state, and a high (relative) degree of inner complexity. Which would mean high likelyhood of bugs. My gut level risk/reward analyzer suggests it would probably end up causing more problems than it would solve. > For this release of graphviz, I suggest just waiting a few days, and re batch. okie dokie. just give me a nudge :) From phil at bolthole.com Sat Jun 25 00:42:22 2011 From: phil at bolthole.com (Philip Brown) Date: Fri, 24 Jun 2011 15:42:22 -0700 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: Message-ID: On Fri, Jun 24, 2011 at 8:30 AM, Jonathan Craig wrote: > On Thu, Jun 23, 2011 at 8:53 PM, Philip Brown wrote: >.... > Ah, but the bug system keeps the conversation on point. ?In a mail > list an email is likely to get hijacked into a different directions > when you begin a philosophical debate over which approach is "best". > That is less likely to happen in the context of ?a bug report as the > writer is conscious of the fact that this is all being filed against a > specific instance. ?And the original maintainer may not even care > about the philosophical differences they simply need to get a package > published so they can get some other (possibly paid) work done. Your reply about motivations, actually aligns with what I'm trying to highlight. A person who "just wants to get a package published", and doesnt care about the finer points of issues... well.. doesnt care. They "just want to get it published" as quickly as possble, without necessarily looking at whether it meshes well with opencsw as a whole. It is beneficial to overall opencsw package quality and consistency, that someone else, with an objective eye also looks at the package. >> 11. technical implementation issue: >> >> ?"By opening up the QA process such that multiple people can easily >> participate and have equal standing on the matters at hand, we feel >> that overall package quality will improve;" >>[...] > >> At the moment, a release manager is guaranteed to at least glance at >> it. Whereas with the "new process", a package may (and I claim, will >> *usually*) get released with no-one but the maintainer ever looking at >> it. > > I glance at every release already, then I mark the email "read" unless > its a package that holds interest to me. It seems you are saying that you "look at the pkgsubmissions mailing list already". But that is missing the point of what I'm bringing up in this issue. How many times do you actually look at the package directly? I would guess very rarely. Do some experimental math for a moment. think of how many times you actually look at a package, compared to how many are released. Then compare to how many active maintainers we have. We'll charitably assume that they look at "someone else's package" with the same frequency that you do. add up (number of maintainers) * ( number of other packages looked at /year) Then compare that number to the total number of packages *released* every year (we've released 754 this year so far. that does not count upgrades to same package, so probably 800), and maybe you'll realize then just how many packages we can reasonably predict that no-one but the maintainer will ever look at, if they do it on an "if I'm interested" basis. > The automated system does allows for more/better QA as indicated > above. ?If quality suffers then we can look at this enforcement. If no-one is LOOKING at organization-wide quality, then no-one will realize that quality is suffering. If you're making the assumption "if something is wrong, someone will file a bug", unfortunately that is not true. A package can have very bad bugs,and still no-one may report it for a long time. Hopefully, some of the other long time maintainers will back me up on this, if they are reading. "no bugs filed" does not neccessarily mean "no one wants that software". It often means "they chose to get it from someplace else, that works, instead" Also, once quality of a "product" suffers below some point... "customers" tend to go elsewhere. irreversibly. So an attitude of "well if it makes a mess, we can always fix it later", can cause harm to the overall popularity of opencsw long term. >> If on the other hand, the goal is really "to allow packages to be >> released with no one but the maintainer ever looking at it", then all >> claims about better QA should be removed from the proposal, and the >> stated "benefits" of the proposal should be updated to reflect that. > > No the goal is to determine the problems and teach an automated system > to apply this to every package, all the time. you say "no" to start, but?the rest of your post seems to resonate strongly with an actual practice of ([you] just want to get your packaged out there, with automated checks only, as fast as possible. Without being hindered by 2nd party checks on it) If so, fine, that's your opinion and wish. I believe it is the wish of some other maintainers also. If that's' what the majority of voters want, so be it. I'm just saying lets be honest about what we're voting for. From jcraig at opencsw.org Sat Jun 25 02:52:09 2011 From: jcraig at opencsw.org (Jonathan Craig) Date: Fri, 24 Jun 2011 20:52:09 -0400 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: Message-ID: On Fri, Jun 24, 2011 at 6:42 PM, Philip Brown wrote: > On Fri, Jun 24, 2011 at 8:30 AM, Jonathan Craig wrote: >> On Thu, Jun 23, 2011 at 8:53 PM, Philip Brown wrote: >>.... > Your reply about motivations, actually aligns with what I'm trying to highlight. > A person who "just wants to get a package published", and doesnt care > about the finer points of issues... well.. doesnt care. ?They "just > want to get it published" as quickly as possble, without necessarily > looking at whether it meshes well with opencsw as a whole. > It is ?beneficial to overall opencsw package quality and consistency, > that someone else, with an objective eye also looks at the package. > > That the reality of volunteer maintainers. I pay attention to what I have time to pay attention which is not the same as being unconcerned with quality. I'm not just flopping out my own packages, I'm trying to use the tools and documentation to turn out the best package I can. For me better tools that provide "code coverage" and better documentation is what I need. >>> 11. technical implementation issue: >>> >>> ?"By opening up the QA process such that multiple people can easily >>> participate and have equal standing on the matters at hand, we feel >>> that overall package quality will improve;" >>>[...] >> >>> At the moment, a release manager is guaranteed to at least glance at >>> it. Whereas with the "new process", a package may (and I claim, will >>> *usually*) get released with no-one but the maintainer ever looking at >>> it. >> >> I glance at every release already, then I mark the email "read" unless >> its a package that holds interest to me. > > It seems you are saying that you "look at the pkgsubmissions mailing > list already". > But that is missing the point of what I'm bringing up in this issue. > How many times do you actually look at the package directly? > I would guess very rarely. > Do some experimental math for a moment. > think of how many times you actually look at a package, compared to > how many are released. > Then compare to how many active maintainers we have. We'll charitably > assume that they look at "someone else's package" with the same > frequency that you do. > add up (number of maintainers) * ( number of other packages looked at /year) > Ah, but the reality is that I pay greater attention to list emails that are associated with bug reports. Thats were I really feel I can learn something. Package submissions are only of interest if the package is of interest. When I look at others packages its usually because I'm trying to determine how they've solved a similar packaging issue in the past. > > >> The automated system does allows for more/better QA as indicated >> above. ?If quality suffers then we can look at this enforcement. > > If no-one is LOOKING at organization-wide quality, then no-one will > realize that quality is suffering. > If you're making the assumption "if something is wrong, someone will > file a bug", unfortunately that is not true. > A package can have very bad bugs,and still no-one may report it for a > long time. Hopefully, some of the other long time maintainers will > back me up on this, if they are reading. > "no bugs filed" does not neccessarily mean "no one wants that > software". It often means "they chose to get it from someplace else, > that works, instead" If you lose your maintainer group because the process of publication is too cumbersome then you end up with no packages. Lack of new and updated packages will drive away customers even faster in my opinion. > > Also, once quality of a "product" suffers below some point... > "customers" tend to go elsewhere. irreversibly. > So an attitude of "well if it makes a mess, we can always fix it > later", can cause harm to the overall popularity of opencsw long term. > I have no reason to believe that the core of maintainers would let things fall that far or the belief that enforced human inspection would prevent it. >>> If on the other hand, the goal is really "to allow packages to be >>> released with no one but the maintainer ever looking at it", then all >>> claims about better QA should be removed from the proposal, and the >>> stated "benefits" of the proposal should be updated to reflect that. >> >> No the goal is to determine the problems and teach an automated system >> to apply this to every package, all the time. > > you say "no" to start, but?the rest of your post seems to resonate > strongly with an actual practice of > ([you] just want to get your packaged out there, with automated checks > only, as fast as possible. Without being hindered by 2nd party checks > on it) You seem to continuously ignore the reality that the proposed process allows anyone to review any package and seek corrections prior to publication. IMO, this is a form of intellectual dishonesty. You haven't said it but from your posts I can only assume that if you can't be the "human" in human centric then you have no wish to participate. You can provide the same level of human oversight of the current system in the proposed solution. The only difference is you need to do it as a customer of the package maintainer instead of lord and master. As to human vs automated processes you are ignoring that an automated process can apply the same level of scrutiny to every package regardless of the number submitted. Further, the process of teaching the system to check our packages provides a great deal of insight into how to improve the overall process. Much more so than a single individual eye balling a subset and then one-off resolving problems with a couple of keystrokes. > > If so, fine, that's your opinion and wish. I believe it is the wish of > some other maintainers also. If that's' what the majority of voters > want, so be it. ?I'm just saying lets be honest about what we're > voting for. Your implying others haven't been honest in their portrayal of the desired solution, while I submit you could be accused of this very thing. I've never said that manual inspection isn't beneficial I'm simply arguing that a subjective inspection by a small group (or one individual) shouldn't be a gate in the production of new packages. Reading your email I've only seen a mild attack on my motives and an empty complaint that the new system inhibits one's ability to critique submitted packages. As to support for status quo vs an automated system I've yet to see any support beyond yourself for the status quo. At some point you will need to come to grips with the proposed change an either embrace it or move on. If you can't be vested in developing a better automated process then I fear you will be marginalized and left in the past. Another victim of progress much like those who once made buggy whips and rail against the noisy new fangled contraptions called cars. Again, do you honestly believe that there is insufficient support for moving forward with an automated approach. Once we determine this direction, and I feel its been determined, the rest can fall into place with all parties vested in achieving the same goal. From rupert at opencsw.org Sat Jun 25 12:58:12 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 25 Jun 2011 12:58:12 +0200 Subject: [csw-maintainers] experimental: subversion --> git, mercurial In-Reply-To: <1308533109-sup-6441@pinkfloyd.chass.utoronto.ca> References: <1308533109-sup-6441@pinkfloyd.chass.utoronto.ca> Message-ID: i see, you are of course right. lets tackle it stepwise thought. currently gar is syncronised manually on git and hg. lets assume we would extend this experiment a little bit, deciding for the moment onto git. what i would miss currently are two things: 1. a short description how i set up my environment so i can deliver, say mercurial. currently i do check out the whole mgar tree, the externals are replaced with symbolic links. what would be the best approach if gar is in git? cd ~ pkg=mercurial mkdir git-experiment cd git-experiment git clone https://rthurner at github.com/opencsw/gar.git gar git svn clone https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/${pkg} ${pkg} ln -s ${pkg}/trunk/gar gar 2. how would i create a new package stub using git? rupert On Mon, Jun 20, 2011 at 03:27, Ben Walton wrote: > Excerpts from rupert THURNER's message of Sun Jun 19 09:00:55 -0400 2011: > > Hi Rupert, > > > as an experiment, i tried to convert the subversion gar repository to git > > and mercurial: > > * http://code.google.com/p/gar/ (hg) > > * https://github.com/opencsw/gar (git) > > I like this! :) I'm not keen on mercurial given my exposure to it, > but anything distributed would be a step up. > > > what i am not sure is how to handle externals and patches onto them, > > but i saw posts like: > > * > > > http://www.undefinedrange.com/posts/git-submodules-external-repositories-and-deployment > > > what do you think, in general about a conversion, and in special, > > how to do this patching? > > I'm not sure what you mean by 'patches onto them' but basically, > submodules suck for our use case, in my estimation. They're excellent > in projects where you're pulling in external code as a source library. > The most common example I see is that many projects have gnulib as a > submodule. When they're polishing a new release, they update the > gnulib submodule to current as part of that process. They won't work > nicely in our pkg/$foo/trunk setup though as we'd be constantly > required to update the sha1 reference to the submodule for every > recipe change. > > As Sebastian mentioned, we can (and should!) do away with externals > and, if they're still in use, the old garlinks in favour of the new > mgar wrapper. > > If we did this, we could (as long as Sebastian is on board), merge > mgar directly into the gar/v2 git repository and release an actual > package for it. mgar is packaged now, but it could be extended to > deliver the rest of the gar code with it. > > The impact of this would be that people would be forced to use mgar to > interact with gar (or create their own new frankenstein) and people > would need to learn/use git. Many of us are already using git where > possible, so that's not likely a big hurdle. Using mgar is a positive > experience and doesn't change workflow much beyond s/(svn|gmake)/mgar/ > now. > > Gar would have a package and we could still have a devel mode for gar > where the local git (or hg) repo is tracked against the head of the > main branch. Good for users, good for devs. > > This might be a nice test of the waters for a move away from svn > instead of attempting to move gar and all of the recipes in one shot. > > Is anyone else excited by this idea? > > Thanks > -Ben > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sat Jun 25 13:11:20 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 25 Jun 2011 12:11:20 +0100 Subject: [csw-maintainers] Code and package reviews In-Reply-To: References: Message-ID: 2011/6/13 Philip Brown : > 2011/6/13 Maciej Blizi?ski : >> 2011/6/11 Philip Brown : >> >>> (...) >>> If anything, this incident shows *more strongly*, the benefit of >>> having at least 2 humans carefully look at a package before release. >>> >>> The "new system" does not in any way ensure that. >> >> I expect that your position can be described as "the release manager >> position ensures that packages are always examined". > > yes. > > >> Our aim is to build a culture in which peer review is one of the key >> elements. ?There needs to be an environment which encourages peer >> reviews and makes them easy. >>.... > > you took the time to write a lot of things in your email. Thank you. > However, ?while the things you wrote were "good", and "true"... they > still did not concretely address the issue :( I'm still unsure about your use of quotes or scare quotes, when you quote the word good, which of the three you mean: - something somebody else said that you quote here - the literal: g, o, o, d - not good > I think the rest of what you wrote, can be summed up, with a minor > insert, as follows: > >> It is important that the senior members of the project actively >> participate in code and package reviews, serving as a good example to >> more junior members. >> [ So we **hope** that people will review packages] > > This is exactly the problem that I see. > There have been a few people complaining about "lack of consistency" > with the current release process. > But how is a release strategy built around "hope", more consistent???? Let's consider three separate issues: 1. Package review 2. Policy development 3. Policy enforcement The inconsistency that the proposal refers to, and attempts to improve, is in point 3 above. It seems to me that in your paragraph above, you refer to point 1. How would you define consistency in the context of a human examining a svr4 file? >> While this strategy does not claim to "ensure that X number of humans >> will always do Y", it addresses the underlying issue of getting people >> involved in the release process and quality assurance through peer >> review. > > It does not seem like it _adequately_ addresses the issue. > Providing people an optional mechanism to improve quality, does not > mean they will use it. "consistently". > Providing people an optional mechanism to "get involved", does not > mean they *will* get involved. > > Some people.. including *you* Maciej... keep pressing the claims that > everything should be automated, for "consistency". > So why are you not automating a 2nd party validation check? Do you have any specific solution in mind? How would it work? Maciej From maciej at opencsw.org Sat Jun 25 13:47:45 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 25 Jun 2011 12:47:45 +0100 Subject: [csw-maintainers] Code and package reviews In-Reply-To: References: Message-ID: I've received a complaint for mixing technical and non-technical issues in one email. Sorry about that. Here's the amended version of the email. 2011/6/13 Philip Brown : > I think the rest of what you wrote, can be summed up, with a minor > insert, as follows: > >> It is important that the senior members of the project actively >> participate in code and package reviews, serving as a good example to >> more junior members. >> [ So we **hope** that people will review packages] > > This is exactly the problem that I see. > There have been a few people complaining about "lack of consistency" > with the current release process. > But how is a release strategy built around "hope", more consistent???? Let's consider three separate issues: 1. Package review 2. Policy development 3. Policy enforcement The inconsistency that the proposal refers to, and attempts to improve, is in point 3 above. ?It seems to me that in your paragraph above, you refer to point 1. How would you define consistency in the context of a human examining a svr4 file? >> While this strategy does not claim to "ensure that X number of humans >> will always do Y", it addresses the underlying issue of getting people >> involved in the release process and quality assurance through peer >> review. > > It does not seem like it _adequately_ addresses the issue. > Providing people an optional mechanism to improve quality, does not > mean they will use it. "consistently". > Providing people an optional mechanism to "get involved", does not > mean they *will* get involved. > > Some people.. including *you* Maciej... keep pressing the claims that > everything should be automated, for "consistency". > So why are you not automating a 2nd party validation check? Do you have any specific solution in mind? ?How would it work? Maciej From bwalton at opencsw.org Sat Jun 25 15:24:52 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 25 Jun 2011 09:24:52 -0400 Subject: [csw-maintainers] experimental: subversion --> git, mercurial In-Reply-To: References: <1308533109-sup-6441@pinkfloyd.chass.utoronto.ca> Message-ID: <1309008070-sup-7506@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Sat Jun 25 06:58:12 -0400 2011: Hi Rupert, > 1. a short description how i set up my environment so i can > deliver, say mercurial. currently i do check out the whole mgar > tree, the externals are replaced with symbolic links. what would be > the best approach if gar is in git? > > cd ~ > pkg=mercurial > mkdir git-experiment > cd git-experiment > git clone https://rthurner at github.com/opencsw/gar.git gar > git svn clone > https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/${pkg} ${pkg} > ln -s ${pkg}/trunk/gar gar I think this would become: mgar init (maybe re-init to help with svn -> git) That would wrap the two steps that it currently does which are: svn co gar/mgar -> ~/opencsw/.builsys/ svn co gar/pkg -> ~/opencsw/ Replacing them with: git clone gar/mgar -> ... svn co gar/pkg -> ... You would then use mgar as you currently do (or if you're still doing the svn/gmake manually, those would remain the same for the time being. > 2. how would i create a new package stub using git? This would (assuming we only use git/hg for that gar code and not the whole package tree) be the same. You'd do: cd ~/opencsw gmake newpkg-foo The whole idea of transitioning the gar code to something other than svn is made immensely easier by having it wrapped in mgar. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Jun 25 15:46:44 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 25 Jun 2011 09:46:44 -0400 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: Message-ID: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> Excerpts from Jonathan Craig's message of Fri Jun 24 11:30:00 -0400 2011: Hi Jonathan, Thanks for writing such a well thought out response. I think it sounds better when it comes from a 'new' voice. I agree with your main points and have snipped out anything that you've covered adequately. The remainder of this mail deals with the useful items you've pulled out. > "A group of subject matter experts will be established to support > and maintain the release system. This group will be subordinate to > the board and responsible for seeing that packaging policy to > properly enforced by the release systems. In the event an > unforeseen issue disrupts the release process they are empowered to > manually augment the system to enable timely release of packages. > Such manual intervention will be logged with the understanding that > repeated manual intervention will require enhancements to the > release system to accommodate routine exceptions." I agree with what you say here. An automated process does not imply a people-free process. The tools will evolve and improve over time. It will be people that drive the changes. This would be a good overall change to the proposal and I would support something like this. The key points for me are that 'group will be established' must be defined to allow anyone interested to participate. It should not exclude anyone that wants to extend effort toward making things flow and improving the tools. It should not by default give one or two maintainers more power than others. We'd need something that encourages more people to become SME's or at the very least doesn't discourage them. Setting hard barriers of any sort in place would be counter to the goals of the new system. [I can see that you understand this fully, I just want my rationale here to be crystal clear.] > I think most would have thought that something like this was > inherent to any automated solution, but it doesn't hurt to write a > little verbage to outline expectations. Agreed. This comment is well thought out and helpful. If you'd like to polish your statement above, I think that it fits well with the proposal as currently written. Although I won't speak for the other signers, I think it would meet with acceptance. Alternately, as most everyone understands this implicitly it may not be required. > handle this bit of nastiness as they see fit. Personally, having a > clear process for taking over a package and an automated solution to > enable "proper" takeover is better than doing this in the darkness > of night. Agreed. This is a tools implementing policy issue. > dependency. It would be nice if the maintainer could code these > dependency into their submit and see that its handled to their > wishes. That puts the maintainer in the drivers seat, where the > responsibility belongs. I actually had a similar thought earlier today when reading the graphviz thread. If we supplied a cswdepend file that held REV= info in addition to the package name, our tools could look at that and make smarter choices. This could allow for mypkg requires yourpkg with version >= %Y%m%d. (There are a lot of details in something like this and it doesn't belong in this thread...) Thanks! -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert at opencsw.org Sat Jun 25 16:50:20 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 25 Jun 2011 16:50:20 +0200 Subject: [csw-maintainers] experimental: subversion --> git, mercurial In-Reply-To: <1309008070-sup-7506@pinkfloyd.chass.utoronto.ca> References: <1308533109-sup-6441@pinkfloyd.chass.utoronto.ca> <1309008070-sup-7506@pinkfloyd.chass.utoronto.ca> Message-ID: On Sat, Jun 25, 2011 at 15:24, Ben Walton wrote: > Excerpts from rupert THURNER's message of Sat Jun 25 06:58:12 -0400 2011: > > Hi Rupert, > > > 1. a short description how i set up my environment so i can > > deliver, say mercurial. currently i do check out the whole mgar > > tree, the externals are replaced with symbolic links. what would be > > the best approach if gar is in git? > > > > cd ~ > > pkg=mercurial > > mkdir git-experiment > > cd git-experiment > > git clone https://rthurner at github.com/opencsw/gar.git gar > > git svn clone > > https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/${pkg} ${pkg} > > ln -s ${pkg}/trunk/gar gar > > I think this would become: > > mgar init (maybe re-init to help with svn -> git) > > this seems not to work yet ... rupert at login:~/git-ben $ mgar init mercurial -bash: mgar: command not found rupert at unstable9s:~/git-ben $ mgar bash: mgar: command not found That would wrap the two steps that it currently does which are: > svn co gar/mgar -> ~/opencsw/.builsys/ > svn co gar/pkg -> ~/opencsw/ > > Replacing them with: > git clone gar/mgar -> ... > svn co gar/pkg -> ... > > You would then use mgar as you currently do (or if you're still doing > the svn/gmake manually, those would remain the same for the time > being. > > > 2. how would i create a new package stub using git? > > This would (assuming we only use git/hg for that gar code and not the > whole package tree) be the same. You'd do: > > cd ~/opencsw > gmake newpkg-foo > > The whole idea of transitioning the gar code to something other than > svn is made immensely easier by having it wrapped in mgar. > > i created, as experiment, https://github.com/opencsw/mercurial, and i tried to write a description which one could execute with the existing buildserver installation. would this be ok like this: https://github.com/opencsw/gar/wiki/move-a-package-from-sourceforge.subversion-to-github.opencsw ? rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Sat Jun 25 17:01:59 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 25 Jun 2011 11:01:59 -0400 Subject: [csw-maintainers] experimental: subversion --> git, mercurial In-Reply-To: References: <1308533109-sup-6441@pinkfloyd.chass.utoronto.ca> <1309008070-sup-7506@pinkfloyd.chass.utoronto.ca> Message-ID: <1309013532-sup-8950@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Sat Jun 25 10:50:20 -0400 2011: Hi Rupert, > > mgar init (maybe re-init to help with svn -> git) > > > > > this seems not to work yet ... > > rupert at login:~/git-ben > $ mgar init mercurial > -bash: mgar: command not found There are two problems here. 1. You likely don't have CSWmgar installed. 2. The mgar tool will need to learn how to checkout the git repo instead of the svn repo. It was a "hypothetically this would become." Sebastian would have the best idea of how easy something like this would be to implement. > > i created, as experiment, https://github.com/opencsw/mercurial, > and i tried to write a description which one could execute with the > existing buildserver installation. would this be ok like this: > https://github.com/opencsw/gar/wiki/move-a-package-from-sourceforge.subversion-to-github.opencsw > ? I don't have time for a full review now, but this would raise an interesting issue. Currently we have one big repository for every package. What you've detailed here would see a separate repository for each package description. I can see pros and cons to this and will outline some of them later[1] I think a big consideration will be performance. While subversion _really_ sucks when working on the whole tree, git will (almost) always work on the whole tree as it doesn't have the notion of checking out bits and pieces of a repository like svn doesn (this would hold for hg too, iiuc). Git is inherently faster than svn but it may still be slow to work with the whole tree... Thanks -Ben [1] It's my son's birthday party today soI'll be more offline than on. -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sat Jun 25 19:16:59 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 25 Jun 2011 18:16:59 +0100 Subject: [csw-maintainers] time to deprecate CSWmozilla In-Reply-To: <1308277170-sup-1017@pinkfloyd.chass.utoronto.ca> References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca> <1307123778-sup-3520@pinkfloyd.chass.utoronto.ca> <1307278894-sup-1960@pinkfloyd.chass.utoronto.ca> <1307324723-sup-7673@pinkfloyd.chass.utoronto.ca> <1308277170-sup-1017@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/6/17 Ben Walton : > Excerpts from Ben Walton's message of Sun Jun 05 21:47:43 -0400 2011: > >> No, the request is fine and I don't mind waiting a week as you >> suggest. ?I'm just saying that we shouldn't let orphaned packages[1] >> impede work on things that people do actively care about. > > Ok, so anybody that wants to update nspr properly is now able to do so > and mark it 'I' with CSWmozilla. ?When it's released, CSWmozilla > should be dropped from the catalog. A week has now passed. I took a look at nspr today. /opt/csw/share/aclocal/nspr.m4 from nspr_dev conflicts not only with CSWmozilla, but also with CSWsunbird. http://www.opencsw.org/packages/cswsunbird/ Do we drop both CSWmozilla and CSWsunbird? Maciej From bwalton at opencsw.org Sat Jun 25 19:24:04 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 25 Jun 2011 13:24:04 -0400 Subject: [csw-maintainers] time to deprecate CSWmozilla In-Reply-To: References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca> <1307123778-sup-3520@pinkfloyd.chass.utoronto.ca> <1307278894-sup-1960@pinkfloyd.chass.utoronto.ca> <1307324723-sup-7673@pinkfloyd.chass.utoronto.ca> <1308277170-sup-1017@pinkfloyd.chass.utoronto.ca> Message-ID: <1309022494-sup-2783@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej Blizi?ski's message of Sat Jun 25 13:16:59 -0400 2011: Hi Maciej, > http://www.opencsw.org/packages/cswsunbird/ > > Do we drop both CSWmozilla and CSWsunbird? It's abandoned upstream as they recommend using thunderbird 3 with the lighting extension. Dropping both has my support. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sat Jun 25 20:26:15 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 25 Jun 2011 19:26:15 +0100 Subject: [csw-maintainers] time to deprecate CSWmozilla In-Reply-To: <1309022494-sup-2783@pinkfloyd.chass.utoronto.ca> References: <1307119971-sup-334@pinkfloyd.chass.utoronto.ca> <1307123778-sup-3520@pinkfloyd.chass.utoronto.ca> <1307278894-sup-1960@pinkfloyd.chass.utoronto.ca> <1307324723-sup-7673@pinkfloyd.chass.utoronto.ca> <1308277170-sup-1017@pinkfloyd.chass.utoronto.ca> <1309022494-sup-2783@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/6/25 Ben Walton : > Excerpts from Maciej Blizi?ski's message of Sat Jun 25 13:16:59 -0400 2011: > > Hi Maciej, > >> http://www.opencsw.org/packages/cswsunbird/ >> >> Do we drop both CSWmozilla and CSWsunbird? > > It's abandoned upstream as they recommend using thunderbird 3 with the > lighting extension. ?Dropping both has my support. Cool. The updated packages are available for testing. http://buildfarm.opencsw.org/experimental.html#nspr This is nspr-4.8.7. The version 4.8.8 is out, but doesn't compile, unfortunately. Maciej From skayser at opencsw.org Sun Jun 26 00:10:18 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 26 Jun 2011 00:10:18 +0200 Subject: [csw-maintainers] experimental: subversion --> git, mercurial In-Reply-To: <1309013532-sup-8950@pinkfloyd.chass.utoronto.ca> References: <1308533109-sup-6441@pinkfloyd.chass.utoronto.ca> <1309008070-sup-7506@pinkfloyd.chass.utoronto.ca> <1309013532-sup-8950@pinkfloyd.chass.utoronto.ca> Message-ID: <20110625221018.GU25705@sebastiankayser.de> * Ben Walton wrote: > Excerpts from rupert THURNER's message of Sat Jun 25 10:50:20 -0400 2011: > > > mgar init (maybe re-init to help with svn -> git) > > > > > this seems not to work yet ... > > > > rupert at login:~/git-ben > > $ mgar init mercurial > > -bash: mgar: command not found > > There are two problems here. > > 1. You likely don't have CSWmgar installed. Just asked for it to be installed on the buildfarm, should be available soon on the actual build hosts. On private boxes a simple 'pkgutil -i mgar' against current/ should do. If anyone has any questions on mgar, please let me know. Basically, it's a wrapper around GAR to which you can feed the exact same commands as to gmake plus some logic around it to populate and manage the build tree (and only keep a single, central copy of a gar branch while doing so). mgar init will checkout the full build tree (not only a single package) to , thus in Rupert's example above the result might not be as expected. > 2. The mgar tool will need to learn how to checkout the git repo > instead of the svn repo. > > It was a "hypothetically this would become." Sebastian would have the > best idea of how easy something like this would be to implement. I'll think about it (and it should be fairly easy to implement), but can we take one step back for a second? From what I understand, we have two aspects, is that correct? 1) move mgar/gar/ to git 2) move mgar/pkg/* to git The first item should be straight forward (and sort of behind the scenes) in case we switch to mgar as the canonical build tool/interface. The second one will need adjustments to gar itself (e.g. UNCOMMITTED handling), some thought on whether to have a single repo or multiple ones, and will imply a noticable change in terms of SCM for all maintainers working with the pkg build repository. Can I suggest to create a wikidot wiki page with a rationale and a brief plan of actions (for both points) so that we can assemble a list of things to consider? > > > i created, as experiment, https://github.com/opencsw/mercurial, > > and i tried to write a description which one could execute with the > > existing buildserver installation. would this be ok like this: > > https://github.com/opencsw/gar/wiki/move-a-package-from-sourceforge.subversion-to-github.opencsw > > ? > > I don't have time for a full review now, but this would raise an > interesting issue. Currently we have one big repository for every > package. What you've detailed here would see a separate repository > for each package description. I can see pros and cons to this and > will outline some of them later[1] If a full repository (containing all build recipes) is reasonable fast to work with, we might actually address the people who currently prefer to work with individual package checkouts (cause the current full svn checkout is too slow for them). If not, we could consider to start using the OPENCSW_REPOSITORY info in the packages to establish a central package-version to build recipe location mapping db. Which can then e.g. be used by mgar to checkout a single build recipe. Just thinking out loud. Sebastian From maciej at opencsw.org Sun Jun 26 00:45:19 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 25 Jun 2011 23:45:19 +0100 Subject: [csw-maintainers] Assessing catalog quality Message-ID: Hello fellow maintainers, Phil has recently mentioned[1] the issue of organization-wide quality. I believe it is a very important one. It would be beneficial for our project to come up with a way to track the quality of our catalog. We could see trends and react when something bad is happening, and also see when the catalog is improving. We could come up with a set of metrics that would be periodically applied and recorded. With time, we would accumulate information about which direction is our catalog heading. We already have one metric, implemented by William: package count[2]. It is already a useful metric, allowing us to see how the catalog grows in the number of packages. It isn't a quality metric, though. Quality metrics will require some consideration, and we need to acknowledge that there will be no perfect metric to measure catalog quality. However, an imperfect metric is definitely better than no metric. Here's my question to maintainers: What metrics would you apply to the catalog for the purpose of catalog quality evaluation? Which aspects of packages, or interactions between packages would you take into consideration? Do you have any already working code that could be used for this purpose? Maciej [1] http://lists.opencsw.org/pipermail/maintainers/2011-June/014860.html [2] http://www.opencsw.org/get-it/package-statistics/ From skayser at opencsw.org Sun Jun 26 00:30:58 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 26 Jun 2011 00:30:58 +0200 Subject: [csw-maintainers] gar tip In-Reply-To: <1308921100-sup-6070@pinkfloyd.chass.utoronto.ca> References: <1308921100-sup-6070@pinkfloyd.chass.utoronto.ca> Message-ID: <20110625223058.GV25705@sebastiankayser.de> * Ben Walton wrote: > Peter and I just realized that not everyone is aware of the templated > GAR recipe feature. In opencsw/ (or opencsw/cpan, etc), you can type: > > gmake newpkg-foo > > This will give you a templated base recipe file. It's custom to each > specialized category (cpan, etc) so that things like gmake > newpkg-Some::Cool:Perl will generate a recipe for > CSWpm-some-cool-perl/pm_some_cool_perl, etc. When you use mgar you can already also use: mgar newpkg and it will populate the template's version field too. Beyond that (not yet implemented), what would you think about populating the template even further, by simply passing the upstream URL to newpkg? mgar newpkg http://foo.org/files/bla-1.2.3.tar.gz It would then: * check whether the file is available * regex-retrieve NAME (bla) and VERSION (1.2.3) * regex-retrieve MASTER_SITES (http://foo.org/files/) * adjust the DISTFILES .tar.gz extension (if != .tar.gz) * possibly run an initial 'mgar makesum' Helpful or too much magic? Sebastian From jcraig at opencsw.org Sun Jun 26 02:04:35 2011 From: jcraig at opencsw.org (Jonathan Craig) Date: Sat, 25 Jun 2011 20:04:35 -0400 Subject: [csw-maintainers] Assessing catalog quality In-Reply-To: References: Message-ID: 2011/6/25 Maciej Blizi?ski > > Here's my question to maintainers: What metrics would you apply to the > catalog for the purpose of catalog quality evaluation? ?Which aspects > of packages, or interactions between packages would you take into > consideration? ?Do you have any already working code that could be > used for this purpose? Here are some thoughts, but I'm not knowledgeable enough of the internals of package publishing to know if they are determinable. Positive measures could include: ? New package submission - Count of packages that didn't previously exist ? Updated packages ? ? ? ? ? - Count of packages that increment their version number Negative measure could include: ? Patched packages ? ? ? ? ? - Count of packages submitted that didn't increment their version number Neutral but interesting stats could include: ? Number of gar managed packages?????? - new or updated packages managed by gar ? Number of non-gar managed packages - new or updated packages from outside of gar -- These speaks to quality if one accepts that packages built and maintained through gar are both easier to update and/or takeover ? Number of package takeovers????????????? - indicative of the stability of the maintainer-ship Other non-catalog stats to report ? Track / Report post counts to the various mailing lists? - indicative of the vibrancy of the various constituencies ? Wiki updates (Gar/OpenCSW)?????????????????????????????????? - indicative of readily available documentation ? OpenCSW site updates??????????????????????????????????????????? - indicative of the freshness of the site From phil at bolthole.com Sun Jun 26 02:33:58 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 25 Jun 2011 17:33:58 -0700 Subject: [csw-maintainers] Code and package reviews In-Reply-To: References: Message-ID: 2011/6/25 Maciej Blizi?ski : > 2011/6/13 Philip Brown : > >> you took the time to write a lot of things in your email. Thank you. >> However, ?while the things you wrote were "good", and "true"... they >> still did not concretely address the issue :( > > I'm still unsure about your use of quotes or scare quotes, when you > quote the word good, which of the three you mean: > > - something somebody else said that you quote here > - the literal: g, o, o, d I am not a sarcastic person. When I write the word "good", in quotes or otherwise, I mean "good" :) everything you wrote was a positive thing everything you wrote was true. but something can be both good, and true, yet still not address the issue. technical reply, will follow in your [written for technical issues] email From phil at bolthole.com Sun Jun 26 02:48:35 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 25 Jun 2011 17:48:35 -0700 Subject: [csw-maintainers] Code and package reviews In-Reply-To: References: Message-ID: 2011/6/25 Maciej Blizi?ski : > I've received a complaint for mixing technical and non-technical > issues in one email. ?Sorry about that. ?Here's the amended version of > the email. > > 2011/6/13 Philip Brown : > >> This is exactly the problem that I see. >> There have been a few people complaining about "lack of consistency" >> with the current release process. >> But how is a release strategy built around "hope", more consistent???? > > Let's consider three separate issues: > > 1. Package review > 2. Policy development > 3. Policy enforcement > > The inconsistency that the proposal refers to, and attempts to > improve, is in point 3 above. ?It seems to me that in your paragraph > above, you refer to point 1. > > How would you define consistency in the context of a human examining a > svr4 file? No manual human process can be perfectly consistent, I grant that. My position is that "A person, or persons, have a specific responsability to at least glance at a package before release; if they dont, a package wont get released" is **more** consistent than "all packages will automatically be released within 2 weeks. Unless someone, maybe, possibly, decides to look at someone else's packages (without any prompting to do so) in that time window, and notices a problem, and files a bug about it" In the first example, it is guaranteed that a 2nd human has at least "touched" the package. guaranteed. that's 100% consistency right there. There is no such guarantee in the new proposal, as it currently stands. >> Some people.. including *you* Maciej... keep pressing the claims that >> everything should be automated, for "consistency". >> So why are you not automating a 2nd party validation check? > > Do you have any specific solution in mind? ?How would it work? Since I have had no visibility into the new system, it is rather difficult for me to suggest a "specific" solution. In a more general view, it could work possibly similar to below: * new package drop into "unstable". They are flagged somehow/somewhere as "needs review" * Any motivated maintainer can go look at [the list of packages that "needs review"], and.... (unsure what goes here, exactly. In an ideal-yet-simple world, perhaps click someplace, and have a browsable interface to show layout of files, and optional click-to-view-file interface?) If the maintainer wants to *really* check out details, they would just install it from the "unstable" tree. * if no problems seen, then after looking at above, the 3rd-party maintainer clicks checkbox, "yes looks okay to me". package then gets cleared for migration to "current", after the 2 week period also elapses. From phil at bolthole.com Sun Jun 26 03:16:51 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 25 Jun 2011 18:16:51 -0700 Subject: [csw-maintainers] Assessing catalog quality In-Reply-To: References: Message-ID: On Sat, Jun 25, 2011 at 5:04 PM, Jonathan Craig wrote: > 2011/6/25 Maciej Blizi?ski >> >> Here's my question to maintainers: What metrics would you apply to the >> catalog for the purpose of catalog quality evaluation? ?Which aspects >> of packages, or interactions between packages would you take into >> consideration? ?Do you have any already working code that could be >> used for this purpose? > > Here are some thoughts, but I'm not knowledgeable enough of the > internals of package publishing to know if they are determinable. > > Positive measures could include: > ? New package submission - Count of packages that didn't previously exist > ? Updated packages ? ? ? ? ? - Count of packages that increment their > version number > > Negative measure could include: > ? Patched packages ? ? ? ? ? - Count of packages submitted that didn't > increment their version number > [...] This seems to be numerical "quality" based. Which, while a good thing, is not all I was concerned with. What you wrote, is in some ways more "quantity/freshness" based. In addition to the things you wrote, I was also thinking of overall consistency between packages. In ways that *cannot* be measured by simple pre-release scripts. Many things can be. But not everything. Random things like... i dunno.. naming of rc files, and placement, in complex cases. there's other random small stuff like that. To me, its the difference between, "hey lets just automate the BSD ports tree to autocompile stuff for solaris instead", vs "Hey lets look at the BSD ports tree, *package by package*, and ensure that BSD-isms are replaced with more Solaris standard stuff". Yes it's possible to write a robo-compiler mechanism. But it yields "higher quality" for a Solaris user, to have the packages individually considered, *on top of* the initial grunt work done by robo-porting. Yes, metrics are good! But not as an end in and of itself. To take the biggest programmer metric failure: How do you measure the "quality" of a programmer's work? At one point, IBM said, "We'll measure it based on KLOC". Epic Fail. After 40 years, there is still no uniform "metric" for that sort of thing. Nor is it possible to uniformly create one. Some kinds of quality are simply not possible to reduce to "metrics". From phil at bolthole.com Sun Jun 26 03:26:15 2011 From: phil at bolthole.com (Philip Brown) Date: Sat, 25 Jun 2011 18:26:15 -0700 Subject: [csw-maintainers] gar tip In-Reply-To: <20110625223058.GV25705@sebastiankayser.de> References: <1308921100-sup-6070@pinkfloyd.chass.utoronto.ca> <20110625223058.GV25705@sebastiankayser.de> Message-ID: On Sat, Jun 25, 2011 at 3:30 PM, Sebastian Kayser wrote: > > > and it will populate the template's version field too. Beyond that (not > yet implemented), what would you think about populating the template > even further, by simply passing the upstream URL to newpkg? > > ?mgar newpkg http://foo.org/files/bla-1.2.3.tar.gz > that sounds pretty nice! as long as you allowed an override for name, because some of the software archive filenames are pretty silly :-/ From bwalton at opencsw.org Sun Jun 26 04:46:20 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 25 Jun 2011 22:46:20 -0400 Subject: [csw-maintainers] gar tip In-Reply-To: References: <1308921100-sup-6070@pinkfloyd.chass.utoronto.ca> <20110625223058.GV25705@sebastiankayser.de> Message-ID: <1309056336-sup-9343@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Sat Jun 25 21:26:15 -0400 2011: > On Sat, Jun 25, 2011 at 3:30 PM, Sebastian Kayser wrote: > > > > > > and it will populate the template's version field too. Beyond that (not > > yet implemented), what would you think about populating the template > > even further, by simply passing the upstream URL to newpkg? > > > > ?mgar newpkg http://foo.org/files/bla-1.2.3.tar.gz > > > > that sounds pretty nice! > > > as long as you allowed an override for name, because some of the > software archive filenames are pretty silly :-/ Agreed. This might be something best handled by real arguments. -u http://..., -n name, etc? The idea is great though! Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert at opencsw.org Sun Jun 26 08:58:35 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 26 Jun 2011 08:58:35 +0200 Subject: [csw-maintainers] experimental: subversion --> git, mercurial In-Reply-To: <20110625221018.GU25705@sebastiankayser.de> References: <1308533109-sup-6441@pinkfloyd.chass.utoronto.ca> <1309008070-sup-7506@pinkfloyd.chass.utoronto.ca> <1309013532-sup-8950@pinkfloyd.chass.utoronto.ca> <20110625221018.GU25705@sebastiankayser.de> Message-ID: On Sun, Jun 26, 2011 at 00:10, Sebastian Kayser wrote: > * Ben Walton wrote: > > Excerpts from rupert THURNER's message of Sat Jun 25 10:50:20 -0400 2011: > > > > mgar init (maybe re-init to help with svn -> git) > > > > > > > this seems not to work yet ... > > > > > > rupert at login:~/git-ben > > > $ mgar init mercurial > > > -bash: mgar: command not found > > > > There are two problems here. > > > > 1. You likely don't have CSWmgar installed. > > Just asked for it to be installed on the buildfarm, should be available > soon on the actual build hosts. On private boxes a simple 'pkgutil -i > mgar' against current/ should do. If anyone has any questions on mgar, > please let me know. > > Basically, it's a wrapper around GAR to which you can feed the exact > same commands as to gmake plus some logic around it to populate and > manage the build tree (and only keep a single, central copy of a gar > branch while doing so). mgar init will checkout the full build > tree (not only a single package) to , thus in Rupert's example > above the result might not be as expected. > > > 2. The mgar tool will need to learn how to checkout the git repo > > instead of the svn repo. > > > > It was a "hypothetically this would become." Sebastian would have the > > best idea of how easy something like this would be to implement. > > I'll think about it (and it should be fairly easy to implement), but can > we take one step back for a second? From what I understand, we have two > aspects, is that correct? > > 1) move mgar/gar/ to git > 2) move mgar/pkg/* to git > > The first item should be straight forward (and sort of behind the > scenes) in case we switch to mgar as the canonical build tool/interface. > > The second one will need adjustments to gar itself (e.g. UNCOMMITTED > handling), some thought on whether to have a single repo or multiple > ones, and will imply a noticable change in terms of SCM for all > maintainers working with the pkg build repository. > > Can I suggest to create a wikidot wiki page with a rationale and a brief > plan of actions (for both points) so that we can assemble a list of > things to consider? > > > > > i created, as experiment, https://github.com/opencsw/mercurial, > > > and i tried to write a description which one could execute with the > > > existing buildserver installation. would this be ok like this: > > > > https://github.com/opencsw/gar/wiki/move-a-package-from-sourceforge.subversion-to-github.opencsw > > > ? > > > > I don't have time for a full review now, but this would raise an > > interesting issue. Currently we have one big repository for every > > package. What you've detailed here would see a separate repository > > for each package description. I can see pros and cons to this and > > will outline some of them later[1] > > If a full repository (containing all build recipes) is reasonable fast > to work with, we might actually address the people who currently prefer > to work with individual package checkouts (cause the current full svn > checkout is too slow for them). > > If not, we could consider to start using the OPENCSW_REPOSITORY info in > the packages to establish a central package-version to build recipe > location mapping db. Which can then e.g. be used by mgar to checkout a > single build recipe. Just thinking out loud. to get a feeling for the question how to get a full checkout, i created: * https://github.com/opencsw/pkg (submodules) * https://github.com/opencsw/pkg-all (full repo) the pkg-all feels quite heavy. creating it took nearly 9 hours, its 100mb big, takes more than 5 minutes to push and clone, see below. and, it cannot be cloned in parts, like the subversion tree before. and, it is not open to have partial migration. $ time git svn clone https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg pkg-all ... real 509m37.383s user 109m23.710s sys 378m14.304s rupert at login:~/git-experiment/pkg-all $ time git push origin master Counting objects: 87829, done. Delta compression using up to 24 threads. Compressing objects: 100% (51647/51647), done. Writing objects: 100% (87829/87829), 95.34 MiB | 352 KiB/s, done. Total 87829 (delta 31596), reused 85545 (delta 29312) To git at github.com:opencsw/pkg-all.git * [new branch] master -> master real 5m6.088s user 0m56.358s sys 0m6.002s -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert at opencsw.org Sun Jun 26 10:25:12 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 26 Jun 2011 10:25:12 +0200 Subject: [csw-maintainers] wiki access? In-Reply-To: References: Message-ID: i tried to edit http://wiki.opencsw.org as user ThurnerRupert, but it would not let me. joining returned: You can not apply. It seems you have already applied for membership. where does such an application go? it seems to be my fault that i cannot remember when i applied, and not tracking it ... rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From trygvis at opencsw.org Sun Jun 26 12:04:38 2011 From: trygvis at opencsw.org (=?UTF-8?B?VHJ5Z3ZlIExhdWdzdMO4bA==?=) Date: Sun, 26 Jun 2011 12:04:38 +0200 Subject: [csw-maintainers] Assessing catalog quality In-Reply-To: References: Message-ID: <4E070436.7080407@opencsw.org> On 6/26/11 12:45 AM, Maciej Blizi?ski wrote: > Hello fellow maintainers, > > Phil has recently mentioned[1] the issue of organization-wide quality. > I believe it is a very important one. > > It would be beneficial for our project to come up with a way to track > the quality of our catalog. We could see trends and react when > something bad is happening, and also see when the catalog is > improving. We could come up with a set of metrics that would be > periodically applied and recorded. With time, we would accumulate > information about which direction is our catalog heading. > > We already have one metric, implemented by William: package count[2]. > It is already a useful metric, allowing us to see how the catalog > grows in the number of packages. It isn't a quality metric, though. > Quality metrics will require some consideration, and we need to > acknowledge that there will be no perfect metric to measure catalog > quality. However, an imperfect metric is definitely better than no > metric. > > Here's my question to maintainers: What metrics would you apply to the > catalog for the purpose of catalog quality evaluation? Which aspects > of packages, or interactions between packages would you take into > consideration? Do you have any already working code that could be > used for this purpose? Number of overrides is one thing that comes to mind. -- Trygve From phil at bolthole.com Sun Jun 26 15:55:16 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 26 Jun 2011 06:55:16 -0700 Subject: [csw-maintainers] wiki access? In-Reply-To: References: Message-ID: I think this means, "you are already a 'member', but you dont have permissions to edit that page" On Sun, Jun 26, 2011 at 1:25 AM, rupert THURNER wrote: > i tried to edit http://wiki.opencsw.org as user ThurnerRupert, but it would > not let me. joining returned: > You can not apply. > It seems you have already applied for membership. > where does such an application go? it seems to be my fault that i cannot > remember when i applied, and not tracking it ... > rupert. > From skayser at opencsw.org Sun Jun 26 16:47:57 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 26 Jun 2011 16:47:57 +0200 Subject: [csw-maintainers] experimental: subversion --> git, mercurial In-Reply-To: References: <1308533109-sup-6441@pinkfloyd.chass.utoronto.ca> <1309008070-sup-7506@pinkfloyd.chass.utoronto.ca> <1309013532-sup-8950@pinkfloyd.chass.utoronto.ca> <20110625221018.GU25705@sebastiankayser.de> Message-ID: <20110626144757.GW25705@sebastiankayser.de> * rupert THURNER wrote: > to get a feeling for the question how to get a full checkout, i created: > *?[5]https://github.com/opencsw/pkg? (submodules) > *?[6]https://github.com/opencsw/pkg-all?(full repo) Cool, thanks alot for the experiment! > the pkg-all feels quite heavy. creating it took nearly 9 hours, its 100mb > big, takes more than 5 minutes to push and clone, see below. and, it > cannot be cloned in parts, like the subversion tree before. and, it is not > open to have partial migration. > $ time git svn clone > [7]https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg pkg-all > ... > real ? ?509m37.383s > user ? ?109m23.710s > sys ? ? 378m14.304s > > rupert at login:~/git-experiment/pkg-all > $ time git push origin master > Counting objects: 87829, done. > Delta compression using up to 24 threads. > Compressing objects: 100% (51647/51647), done. > Writing objects: 100% (87829/87829), 95.34 MiB | 352 KiB/s, done. > Total 87829 (delta 31596), reused 85545 (delta 29312) > To git at github.com:opencsw/pkg-all.git > ?* [new branch] ? ? ?master -> master > real ? ?5m6.088s > user ? ?0m56.358s > sys ? ? 0m6.002s The operations above are one off, right? To add some further figures, a git clone of the full repo takes ~2mins for me, git log . in a package directory ~12 seconds. $ time git clone git://github.com/opencsw/pkg-all.git remote: Counting objects: 87829, done. remote: Compressing objects: 100% (49363/49363), done. Indexing 87829 objects. remote: Total 87829 (delta 31596), reused 87829 (delta 31596) 100% (87829/87829) done Resolving 31596 deltas. 100% (31596/31596) done Checking files out... 100% (12273/12273) done real 1m56.048s user 0m16.952s sys 0m3.641s $ pwd /home/ska/tmp/gittest/pkg-all/lang-python/sqlobject/trunk $ time git log . >/dev/null real 0m11.587s user 0m11.532s sys 0m0.052s Sebastian From bwalton at opencsw.org Sun Jun 26 17:21:37 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 26 Jun 2011 11:21:37 -0400 Subject: [csw-maintainers] experimental: subversion --> git, mercurial In-Reply-To: <20110626144757.GW25705@sebastiankayser.de> References: <1308533109-sup-6441@pinkfloyd.chass.utoronto.ca> <1309008070-sup-7506@pinkfloyd.chass.utoronto.ca> <1309013532-sup-8950@pinkfloyd.chass.utoronto.ca> <20110625221018.GU25705@sebastiankayser.de> <20110626144757.GW25705@sebastiankayser.de> Message-ID: <1309101553-sup-7811@pinkfloyd.chass.utoronto.ca> Excerpts from Sebastian Kayser's message of Sun Jun 26 10:47:57 -0400 2011: > The operations above are one off, right? To add some further > figures, a git clone of the full repo takes ~2mins for me, git log > . in a package directory ~12 seconds. The initial price of a clone will be the heaviest as only new references are transferred after that. 2 minutes isn't that bad for a large repo like the package tree. Was the log operation on a local or network mounted filesystem? What about a subsequent run of the same operation (cold vs hot cache)? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sun Jun 26 17:45:26 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sun, 26 Jun 2011 16:45:26 +0100 Subject: [csw-maintainers] Code and package reviews In-Reply-To: References: Message-ID: 2011/6/26 Philip Brown : > 2011/6/25 Maciej Blizi?ski : >> I've received a complaint for mixing technical and non-technical >> issues in one email. ?Sorry about that. ?Here's the amended version of >> the email. >> >> 2011/6/13 Philip Brown : >> >>> This is exactly the problem that I see. >>> There have been a few people complaining about "lack of consistency" >>> with the current release process. >>> But how is a release strategy built around "hope", more consistent???? >> >> Let's consider three separate issues: >> >> 1. Package review >> 2. Policy development >> 3. Policy enforcement >> >> The inconsistency that the proposal refers to, and attempts to >> improve, is in point 3 above. ?It seems to me that in your paragraph >> above, you refer to point 1. >> >> How would you define consistency in the context of a human examining a >> svr4 file? > > No manual human process can be perfectly consistent, I grant that. > My position is that ?"A person, or persons, have a specific > responsability to at least glance at a package before release; if they > dont, a package wont get released" ?is **more** consistent than > > "all packages will automatically be released within 2 weeks. ?Unless > someone, maybe, possibly, decides to look at someone else's packages > (without any prompting to do so) in that time window, and notices a > problem, and files a bug about it" > > In the first example, it is guaranteed that a 2nd human has at least > "touched" the package. guaranteed. that's 100% consistency right > there. > There is no such guarantee in the new proposal, as it currently stands. The guarantee you mention, is a guarantee that a button is pressed. There's no guarantee whether the human actually did anything or not. Claiming 100% consistency is a bit of a stretch in my opinion. The non-inclusion of reviews as a gating factor in the proposal is intentional. It might of course change - but so far, it has been group's intention not to involve a human controlling package releases. Peer reviews are an excellent mechanism to improve quality. My intention is to create an environment in which maintainers want their packages reviewed. >>> Some people.. including *you* Maciej... keep pressing the claims that >>> everything should be automated, for "consistency". >>> So why are you not automating a 2nd party validation check? >> >> Do you have any specific solution in mind? ?How would it work? > > > Since I have had no visibility into the new system, it is rather > difficult for me to suggest a "specific" solution. > In a more general view, it could work possibly similar to below: > > > * new package drop into "unstable". ? They are flagged > somehow/somewhere as "needs review" > * Any motivated maintainer can go look at [the list of packages that > "needs review"], and.... > ? (unsure what goes here, exactly. In an ideal-yet-simple world, > perhaps click someplace, and have a browsable > ?interface to show layout of files, and optional click-to-view-file interface?) > ?If the maintainer wants to *really* check out details, they would > just install it from the "unstable" tree. > * if no problems seen, then after looking at above, the 3rd-party > maintainer clicks checkbox, "yes looks okay to me". > ?package then gets cleared for migration to "current", after the 2 > week period also elapses. How about a similar setup, in which there is no review based gating, but accounting of reviews. For example, there could be a tool allowing maintainers to mark packages as reviewed and accepted. Package review status would then appear on the web, in places such as maintainer's page, and package pages in the buildfarm database. It would be a form a beneficial peer pressure, where maintainers would be proud of having their packages reviewed. Maciej From skayser at opencsw.org Sun Jun 26 17:40:39 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 26 Jun 2011 17:40:39 +0200 Subject: [csw-maintainers] wiki access? In-Reply-To: References: Message-ID: <20110626154039.GX25705@sebastiankayser.de> Hi Rupert, * rupert THURNER wrote: > i tried to edit [1]http://wiki.opencsw.org as user ThurnerRupert, > but it would not let me. joining returned: You can not apply. It > seems you have already applied for membership. no need to join if you've already applied. Application will likely go to Peter and maybe to Maciej, too [1]. Chances are, they already granted you access if you've applied previously. Can you add a new page (form at the bottom of the left navbar) after you've logged in? Sebastian [1] http://wiki.opencsw.org/3rd-party-services#toc5 From bonivart at opencsw.org Sun Jun 26 19:17:09 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 26 Jun 2011 19:17:09 +0200 Subject: [csw-maintainers] wiki access? In-Reply-To: References: Message-ID: On Sun, Jun 26, 2011 at 10:25 AM, rupert THURNER wrote: > i tried to edit http://wiki.opencsw.org as user ThurnerRupert, but it would > not let me. joining returned: I have added you now. You should now be able to add/edit pages. /peter From bonivart at opencsw.org Sun Jun 26 19:28:49 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 26 Jun 2011 19:28:49 +0200 Subject: [csw-maintainers] Assessing catalog quality In-Reply-To: <4E070436.7080407@opencsw.org> References: <4E070436.7080407@opencsw.org> Message-ID: 2011/6/26 Trygve Laugst?l : > Number of overrides is one thing that comes to mind. +1. We also need to analyze the overrides but that's a different matter. Also, the package freshness William used to publish is a good metric, I think we can agree that in general newer packages are better than older packages, they follow our current standard better and are more up to date with upstream versions. I know that in some cases an old package can be perfect, there's just no action going on upstream but for the whole catalog I think it would be interesting to see how many packages are 1-3 months old, 3-6 months old, 6-12 months old or older than a year e.g. Also, regarding the talks about peer review, why not use that as a quality metric. /peter From skayser at opencsw.org Sun Jun 26 20:03:58 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 26 Jun 2011 20:03:58 +0200 Subject: [csw-maintainers] experimental: subversion --> git, mercurial In-Reply-To: <1309101553-sup-7811@pinkfloyd.chass.utoronto.ca> References: <1308533109-sup-6441@pinkfloyd.chass.utoronto.ca> <1309008070-sup-7506@pinkfloyd.chass.utoronto.ca> <1309013532-sup-8950@pinkfloyd.chass.utoronto.ca> <20110625221018.GU25705@sebastiankayser.de> <20110626144757.GW25705@sebastiankayser.de> <1309101553-sup-7811@pinkfloyd.chass.utoronto.ca> Message-ID: <20110626180358.GY25705@sebastiankayser.de> * Ben Walton wrote: > Excerpts from Sebastian Kayser's message of Sun Jun 26 10:47:57 -0400 2011: > > > The operations above are one off, right? To add some further > > figures, a git clone of the full repo takes ~2mins for me, git log > > . in a package directory ~12 seconds. > > The initial price of a clone will be the heaviest as only new > references are transferred after that. 2 minutes isn't that bad for a > large repo like the package tree. Sorry, I'll have to revert my 2 minute clone estimate, that was on my vserver with a very thick uplink. Re-tried on my home server (~100 KiB/s), clone took about 20mins. :/ > Was the log operation on a local or network mounted filesystem? What > about a subsequent run of the same operation (cold vs hot cache)? Local file system, same result on subsequent runs (git 1.4.4.4). On my server at home (git 1.7.5.4) the log operation on a directory is faster and takes ~2 seconds (both for initial and subsequent runs). Sebastian From dam at opencsw.org Sun Jun 26 20:49:23 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 26 Jun 2011 20:49:23 +0200 Subject: [csw-maintainers] Assessing catalog quality In-Reply-To: References: Message-ID: Hi Maciej, Am 26.06.2011 um 00:45 schrieb Maciej Blizi?ski: > Here's my question to maintainers: What metrics would you apply to the > catalog for the purpose of catalog quality evaluation? Which aspects > of packages, or interactions between packages would you take into > consideration? Do you have any already working code that could be > used for this purpose? I like to look at the sum of the weighted bug counts: http://www.opencsw.org/buglist/buglist.cgi It would be even better if bugs were reported against specific package revisions, so it would be possible to calculate the bugginess of a specific catalog release. Best regards -- Dago From rupert at opencsw.org Sun Jun 26 22:00:40 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 26 Jun 2011 22:00:40 +0200 Subject: [csw-maintainers] experimental: subversion --> git, mercurial In-Reply-To: <20110626180358.GY25705@sebastiankayser.de> References: <1308533109-sup-6441@pinkfloyd.chass.utoronto.ca> <1309008070-sup-7506@pinkfloyd.chass.utoronto.ca> <1309013532-sup-8950@pinkfloyd.chass.utoronto.ca> <20110625221018.GU25705@sebastiankayser.de> <20110626144757.GW25705@sebastiankayser.de> <1309101553-sup-7811@pinkfloyd.chass.utoronto.ca> <20110626180358.GY25705@sebastiankayser.de> Message-ID: On Sun, Jun 26, 2011 at 20:03, Sebastian Kayser wrote: > * Ben Walton wrote: > > Excerpts from Sebastian Kayser's message of Sun Jun 26 10:47:57 -0400 > 2011: > > > > > The operations above are one off, right? To add some further > > > figures, a git clone of the full repo takes ~2mins for me, git log > > > . in a package directory ~12 seconds. > > > > The initial price of a clone will be the heaviest as only new > > references are transferred after that. 2 minutes isn't that bad for a > > large repo like the package tree. > > Sorry, I'll have to revert my 2 minute clone estimate, that was on my > vserver with a very thick uplink. Re-tried on my home server (~100 > KiB/s), clone took about 20mins. :/ > > > Was the log operation on a local or network mounted filesystem? What > > about a subsequent run of the same operation (cold vs hot cache)? > > Local file system, same result on subsequent runs (git 1.4.4.4). On my > server at home (git 1.7.5.4) the log operation on a directory is faster > and takes ~2 seconds (both for initial and subsequent runs). > > started http://wiki.opencsw.org/dvcs. rupert -------------- next part -------------- An HTML attachment was scrubbed... URL: From william at wbonnet.net Sun Jun 26 22:02:40 2011 From: william at wbonnet.net (William Bonnet) Date: Sun, 26 Jun 2011 22:02:40 +0200 Subject: [csw-maintainers] Assessing catalog quality In-Reply-To: References: Message-ID: <4E079060.5050104@wbonnet.net> Hi Some of the indicators you mention already exist. I provide the url in the rest of the message. Let me know if you need to summarize all this under a specific "catalog qa page" > Positive measures could include: > New package submission - Count of packages that didn't previously exist > Updated packages - Count of packages that increment their > version number These are available from : http://www.opencsw.org/get-it/package-statistics/ It's a monthly view > Negative measure could include: > Patched packages - Count of packages submitted that didn't > increment their version number Pretty much easy to compute (taking in account what is already done) > Neutral but interesting stats could include: > Number of gar managed packages - new or updated packages managed by gar > Number of non-gar managed packages - new or updated packages from > outside of gar This is available from http://www.opencsw.org/qa/ This page provides several link to the different catagories. You will find the detailled list of data and instant values. I started to created some statistics based upon these data. I can push it son now that there are some data to display :) > -- These speaks to quality if one accepts that packages built and > maintained through gar are both easier to update and/or takeover > Number of package takeovers - indicative of the > stability of the maintainer-ship It's not too difficult to implement > Other non-catalog stats to report > Track / Report post counts to the various mailing lists - > indicative of the vibrancy of the various constituencies > Wiki updates (Gar/OpenCSW) - > indicative of readily available documentation > OpenCSW site updates - > indicative of the freshness of the site Existing solution does not cover this. It does not mean it cannot be done nor it's a bad idea :P It just mean it has tobe done ;) Cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From phil at bolthole.com Mon Jun 27 01:29:27 2011 From: phil at bolthole.com (Philip Brown) Date: Sun, 26 Jun 2011 16:29:27 -0700 Subject: [csw-maintainers] Code and package reviews In-Reply-To: References: Message-ID: 2011/6/26 Maciej Blizi?ski : > > The non-inclusion of reviews as a gating factor in the proposal is > intentional. ?It might of course change - but so far, it has been > group's intention not to involve a human controlling package releases. > > Peer reviews are an excellent mechanism to improve quality. ?My > intention is to create an environment in which maintainers want their > packages reviewed. providing some kind of positive motivation is nice. Its a great management strategy. but what could be used as sufficient motivation? >Package review status would then appear on the web, in places such as >maintainer's page, and package pages in the buildfarm database. It >would be a form a beneficial peer pressure, where maintainers would be >proud of having their packages reviewed btw, we've tried similar incentives before, in the form of the bug scoring page. While I think this sort of thing appeals to some, it is not universal. Sadly, no amount of "incentive" helps in the case of a person who has the attitude of, "nothing appeals more to me than not having someone else review my work" Additionally , it often happens, in all kinds of areas (software programming, article writing, and others) that the people who are most resistant to having others review their work, are the ones that need it most :( Is that something you are ok with? Because that's what this sort of thing comes down to in the end, really. From bwalton at opencsw.org Mon Jun 27 03:55:55 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 26 Jun 2011 21:55:55 -0400 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> Message-ID: <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Sat Jun 25 09:46:44 -0400 2011: Hi Jonathan, > Alternately, as most everyone understands this implicitly it may not > be required. Do you wish to see the clarifying statement added to the proposal before the vote? If not, that's ok. As you say, most understand that it's implied. I'd still like to start the vote tomorrow, so let me know if you're working on this. Phil: I've modified the vote writeup such that it's talking about the proposal as written. Please fill out the cons side. If Jonathan does put forward an ammendment that's accepted, you can update as necessary before the vote if started. Maciej: Would you mind preparing the ballot bin stuff? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Mon Jun 27 11:21:53 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 27 Jun 2011 10:21:53 +0100 Subject: [csw-maintainers] Code and package reviews In-Reply-To: References: Message-ID: 2011/6/27 Philip Brown : > 2011/6/26 Maciej Blizi?ski : >> >> The non-inclusion of reviews as a gating factor in the proposal is >> intentional. ?It might of course change - but so far, it has been >> group's intention not to involve a human controlling package releases. >> >> Peer reviews are an excellent mechanism to improve quality. ?My >> intention is to create an environment in which maintainers want their >> packages reviewed. > > providing some kind of positive motivation is nice. Its a great > management strategy. > but what could be used as sufficient motivation? My first thought is: giving helpful reviews! This does of course mean pointing out issues, but also giving explanations why the issues in question are important, and suggestions how to tackle them. >>Package review status would then appear on the web, in places such as >>maintainer's page, and package pages in the buildfarm database. ?It >>would be a form a beneficial peer pressure, where maintainers would be >>proud of having their packages reviewed > > btw, we've tried similar incentives before, in the form of the bug scoring page. > While I think this sort of thing appeals to some, it is not universal. > > > Sadly, no amount of "incentive" helps in the case of a person who has > the attitude of, > "nothing appeals more to me than not having someone else review my work" > Additionally , it often happens, in all kinds of areas (software > programming, article writing, and others) > that the people who are most resistant to having others review their > work, are the ones that need it most > :( > > Is that something you are ok with? Because that's what this sort of > thing comes down to in the end, really. Am I OK with people resisting reviews? Nobody can stop anybody from reviewing their work if it's published, but there can be someone not willing to listen, or not willing to follow suggestions. Am I OK with people willing to listen or not following suggestions? It depends. If this happens, it's either because they don't understand the problem, or because they don't share goals with the reviewer. The second issue is harder, in such case the two people need to talk. It helps if agreed goals of the group are available in writing, so that a common ground can be established. The reviewer also needs to take it into account that the review receiver has no obligation to follow all the suggestions. If there are suggestions that are not part of group's common goals, the review receiver may simply decline to follow them, and that's fine. The reviewer needs to understand that he or she needs to be reasonable and that it is a conversation between equals. The reviewer's role is only to help. While I'm not OK with someone not understanding what the issue is, I'm OK with someone declining to follow a suggestion if the package complies with our standards and policies. For example, if the issue is that the package is missing a dependency, it's a clear policy issue. If the issue is something like whether to use a regular file or a symlink to one, and it doesn't pose an operational problem, then the reviewer should let go and save stamina for another time. Maciej From dam at opencsw.org Mon Jun 27 12:46:30 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 27 Jun 2011 12:46:30 +0200 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs augeas In-Reply-To: <201106271040.p5RAeKhU002689@login.bo.opencsw.org> References: <201106271040.p5RAeKhU002689@login.bo.opencsw.org> Message-ID: <76FD8688-EE6F-4705-80FD-06C37A63F1F2@opencsw.org> Hi Mark, Am 27.06.2011 um 12:40 schrieb Mark Phillips: >> Additionally, and possibly not coincidentally, there is indication >> that your package stuff was not actually committed into subversion? >> >> OPENCSW_REPOSITORY=https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/augeas/trunk at UNCOMMITTED > > Hmm, should all be there. My checkout is committed... > > current10x:augeas$ svn info | grep URL > URL: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/augeas > current10x:augeas$ svn st > X trunk/gar > > Performing status on external item at 'trunk/gar' > > It was probably the case that the roll that's sitting in experimental hadn't > yet been committed - I tend to svn commit after I've rolled the package and > installed it, testing that it at least installs properly. When I'm confident it > does, it then gets committed. > > Hope that helps. It explains what is in the package. However, the procedure you use is somewhat illegal, because the package contains a reference to the repository of the time the package was build. This makes it possible to check out the specific revision a package was built from. If you commit later this does not work. For your own testing this is not relevant, but for submission it is mandatory that everything has been checked in prior to building the package. It is sufficient to do a gmake platforms-repackage after commiting to get valid packages. 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 phil at bolthole.com Mon Jun 27 15:08:39 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 27 Jun 2011 06:08:39 -0700 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: Message-ID: Snipping a lot for readability. I'm trying to do that in a way that still preserves what I believe to be original meaning and intent. If I botch it, my apologies, please correct it. On Fri, Jun 24, 2011 at 5:52 PM, Jonathan Craig wrote: > On Fri, Jun 24, 2011 at 6:42 PM, Philip Brown wrote: >> >> It seems you are saying that you "look at the pkgsubmissions mailing >> list already". >[...] > > Ah, but the reality is that I pay greater attention to list emails > that are associated with bug reports. ?Thats were I really feel I can > learn something. In a way, your reply backs up what I am saying. You pay (greater) attention, when *someone else* has noticed an issue. But what if no-one is comitted to examining and bringing up issues in the first place? This is a core concern I have. ?[...] > You seem to continuously ignore the reality that the proposed process > allows anyone to review any package and seek corrections prior to > publication. ?IMO, this is a form of intellectual dishonesty. ?You > haven't said it but from your posts I can only assume that if you > can't be the "human" in human centric then you have no wish to > participate. I thought I have explicitly said the opposite. I dont care if it's me, but I believe there does need to be *someone*, or someones, with that explicit task, otherwise it wont get fully done. > As to human vs automated processes you are ignoring that an automated > process can apply the same level of scrutiny to every package > regardless of the number submitted. People keep trying to force this into a "human, OR automated process", and claiming this is what I want. Yet not once have I advocated getting rid of the automated process. My preference is for "human examination, AND automated process". I have been requesting this be made available as a choice, but it is being blocked. From phil at bolthole.com Mon Jun 27 15:22:44 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 27 Jun 2011 06:22:44 -0700 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> Message-ID: On Sun, Jun 26, 2011 at 6:55 PM, Ben Walton wrote: > > > Phil: I've modified the vote writeup such that it's talking about the > proposal as written. ?Please fill out the cons side. ?If Jonathan does > put forward an ammendment that's accepted, you can update as necessary > before the vote if started. Ben: So, to be clear: you are rejecting every single one of my wording amendments? Even though some of them clearly point out that the proposal claims things that are false? Jonathan made *comments* about my proposed amendments 2,3,4&5 However, I dont see that he refuted what I was saying. For example, on #3, he did comment on my complaint about the "set in stone" bit, but did not argue with my statement that the release manager cannot currently "reject" a package. Therefore, the "reject" part should be taken out of the proposal, because it is undisputedly false. It would be nice if you reviewed his comments on 2,4 & 5 more carefully also. From bwalton at opencsw.org Mon Jun 27 15:23:16 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 27 Jun 2011 09:23:16 -0400 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: Message-ID: <1309180908-sup-782@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Jun 27 09:08:39 -0400 2011: > People keep trying to force this into a "human, OR automated process", > and claiming this is what I want. > Yet not once have I advocated getting rid of the automated process. My > preference is for > "human examination, AND automated process". We currently have a human examination with 'automated' process wrapped around it. Normally we'd refer to this as status quo. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From jcraig at opencsw.org Mon Jun 27 17:09:32 2011 From: jcraig at opencsw.org (Jonathan Craig) Date: Mon, 27 Jun 2011 11:09:32 -0400 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> Message-ID: On Sun, Jun 26, 2011 at 9:55 PM, Ben Walton wrote: > Excerpts from Ben Walton's message of Sat Jun 25 09:46:44 -0400 2011: > > Phil: I've modified the vote writeup such that it's talking about the > proposal as written. ?Please fill out the cons side. ?If Jonathan does > put forward an ammendment that's accepted, you can update as necessary > before the vote if started. > Here is my proposed amendment with the pre/post paragraphs to indicate placement within current proposal. Wasn't really sure whether this was to be submitted by mail or simply edited into wiki page. -- amendment -- Any bug filed has the potential to trigger the creation of new policy. This would require list discussion and in some cases a vote if there is no clear consensus from that discussion. New policy will be implemented as a check within checkpkg. As part of this effort a group of volunteer subject matter experts will be established to support and maintain the release system. Membership in the group is open and the purpose is to establish a broad list of individuals who are best capable of supporting and improving the release system. This group will be subordinate to the board and responsible for seeing that packaging policy is properly enforced by the release system. In the event an unforeseen issue disrupts the release process they are empowered to manually augment the system to enable timely release of packages. Such intervention will be logged with the understanding that repeated manual intervention will require enhancements to the release system to accommodate routine exceptions. All items that fail checks in checkpkg may be overridden to allow package-local exceptions to policy when/where required. These overrides are visible in the package delivered to the system and the code repository. Additionally, they can be queried for in the package database. -- end -- From phil at bolthole.com Mon Jun 27 18:42:34 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 27 Jun 2011 09:42:34 -0700 Subject: [csw-maintainers] Code and package reviews In-Reply-To: References: Message-ID: 2011/6/27 Maciej Blizi?ski : > 2011/6/27 Philip Brown : >> 2011/6/26 Maciej Blizi?ski : >>> >>> The non-inclusion of reviews as a gating factor in the proposal is >>> intentional. ?It might of course change - but so far, it has been >>> group's intention not to involve a human controlling package releases. >>> >>> Peer reviews are an excellent mechanism to improve quality. ?My >>> intention is to create an environment in which maintainers want their >>> packages reviewed. >> >> providing some kind of positive motivation is nice. Its a great >> management strategy. >> but what could be used as sufficient motivation? > > My first thought is: giving helpful reviews! ?This does of course mean > pointing out issues, but also giving explanations why the issues in > question are important, and suggestions how to tackle them. Errr... not sure how that is motivational there. maybe I'm not understanding what you're saying. On the other side of the field, I have a thought on motivation for the people doing the actual reviewing: Those who participate and do... (? x amount of package reviews per month/week, and also file 'y' amount of feedback/whatever?) could get to be recognized as being on "the review team" ? From maciej at opencsw.org Mon Jun 27 19:29:26 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 27 Jun 2011 18:29:26 +0100 Subject: [csw-maintainers] Code and package reviews In-Reply-To: References: Message-ID: 2011/6/27 Philip Brown : > 2011/6/27 Maciej Blizi?ski : >> 2011/6/27 Philip Brown : >>> 2011/6/26 Maciej Blizi?ski : >>>> >>>> The non-inclusion of reviews as a gating factor in the proposal is >>>> intentional. ?It might of course change - but so far, it has been >>>> group's intention not to involve a human controlling package releases. >>>> >>>> Peer reviews are an excellent mechanism to improve quality. ?My >>>> intention is to create an environment in which maintainers want their >>>> packages reviewed. >>> >>> providing some kind of positive motivation is nice. Its a great >>> management strategy. >>> but what could be used as sufficient motivation? >> >> My first thought is: giving helpful reviews! ?This does of course mean >> pointing out issues, but also giving explanations why the issues in >> question are important, and suggestions how to tackle them. > > > Errr... not sure how that is motivational there. maybe I'm not > understanding what you're saying. The motivation can flow from the helpfulness of reviews. It's the "thank goodness my package was reviewed" feeling. It's when a maintainer is glad and grateful for the feedback which allowed them to make their package better. > On the other side of the field, ?I have a thought on motivation for > the people doing the actual reviewing: > > Those who participate and do... (? x amount of package reviews per > month/week, and also file 'y' amount of feedback/whatever?) could get > to be recognized as being on "the review team" ? Yes, sounds like a good idea. Reviewing takes time and skill. Only having packages for review doesn't get them reviewed if there are no reviewers around. Recognition for doing reviews would definitely help. Maciej From bwalton at opencsw.org Mon Jun 27 21:29:21 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 27 Jun 2011 15:29:21 -0400 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> Message-ID: <1309202812-sup-7249@pinkfloyd.chass.utoronto.ca> Excerpts from Jonathan Craig's message of Mon Jun 27 11:09:32 -0400 2011: Hi Jonathan, > Here is my proposed amendment with the pre/post paragraphs to > indicate placement within current proposal. Wasn't really sure > whether this was to be submitted by mail or simply edited into wiki > page. I approve of this addition. I'd appreciate it if signers of the current proposal provide an explicit ACK to this change (or a NACK as they set fit). Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Jun 27 21:32:34 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 27 Jun 2011 15:32:34 -0400 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> Message-ID: <1309202971-sup-990@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Jun 27 09:22:44 -0400 2011: Hi Phil, > So, to be clear: you are rejecting every single one of my wording > amendments? Even though some of them clearly point out that the > proposal claims things that are false? I'll give this another read tonight. > It would be nice if you reviewed his comments on 2,4 & 5 more > carefully also. Fine. I'll go over this again tonight and provide explicit feedback on each point. I didn't think that was still necessary, but I'm obviously mistaken. As we need a bit of time for people to ACK/NACK Jonathan's addition to the proposal the vote can't start tonight anyway. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bonivart at opencsw.org Mon Jun 27 21:33:15 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 27 Jun 2011 21:33:15 +0200 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: <1309202812-sup-7249@pinkfloyd.chass.utoronto.ca> References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309202812-sup-7249@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Jun 27, 2011 at 9:29 PM, Ben Walton wrote: > Excerpts from Jonathan Craig's message of Mon Jun 27 11:09:32 -0400 2011: > > Hi Jonathan, > >> Here is my proposed amendment with the pre/post paragraphs to >> indicate placement within current proposal. ?Wasn't really sure >> whether this was to be submitted by mail or simply edited into wiki >> page. > > I approve of this addition. ?I'd appreciate it if signers of the > current proposal provide an explicit ACK to this change (or a NACK as > they set fit). OK with me as well. /peter From maciej at opencsw.org Mon Jun 27 21:35:04 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 27 Jun 2011 20:35:04 +0100 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: <1309202812-sup-7249@pinkfloyd.chass.utoronto.ca> References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309202812-sup-7249@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/6/27 Ben Walton : > Excerpts from Jonathan Craig's message of Mon Jun 27 11:09:32 -0400 2011: > > Hi Jonathan, > >> Here is my proposed amendment with the pre/post paragraphs to >> indicate placement within current proposal. ?Wasn't really sure >> whether this was to be submitted by mail or simply edited into wiki >> page. > > I approve of this addition. ?I'd appreciate it if signers of the > current proposal provide an explicit ACK to this change (or a NACK as > they set fit). Looks good! From trygvis at opencsw.org Mon Jun 27 21:39:11 2011 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Mon, 27 Jun 2011 21:39:11 +0200 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: <1309202812-sup-7249@pinkfloyd.chass.utoronto.ca> References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309202812-sup-7249@pinkfloyd.chass.utoronto.ca> Message-ID: <4E08DC5F.3030603@opencsw.org> On 6/27/11 9:29 PM, Ben Walton wrote: > Excerpts from Jonathan Craig's message of Mon Jun 27 11:09:32 -0400 2011: > > Hi Jonathan, > >> Here is my proposed amendment with the pre/post paragraphs to >> indicate placement within current proposal. Wasn't really sure >> whether this was to be submitted by mail or simply edited into wiki >> page. > > I approve of this addition. I'd appreciate it if signers of the > current proposal provide an explicit ACK to this change (or a NACK as > they set fit). ACK -- Trygve From dam at opencsw.org Mon Jun 27 21:45:34 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 27 Jun 2011 21:45:34 +0200 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: <1309202812-sup-7249@pinkfloyd.chass.utoronto.ca> References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309202812-sup-7249@pinkfloyd.chass.utoronto.ca> Message-ID: Am 27.06.2011 um 21:29 schrieb Ben Walton : > Excerpts from Jonathan Craig's message of Mon Jun 27 11:09:32 -0400 2011: > > Hi Jonathan, > >> Here is my proposed amendment with the pre/post paragraphs to >> indicate placement within current proposal. Wasn't really sure >> whether this was to be submitted by mail or simply edited into wiki >> page. > > I approve of this addition. I'd appreciate it if signers of the > current proposal provide an explicit ACK to this change (or a NACK as > they set fit). +1 Best regards -- Dago From maciej at opencsw.org Mon Jun 27 22:01:54 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Mon, 27 Jun 2011 21:01:54 +0100 Subject: [csw-maintainers] how to set up a local buildhost? In-Reply-To: <4DEA8DA4.8000304@opencsw.org> References: <4DEA660B.4080102@opencsw.org> <4DEA8DA4.8000304@opencsw.org> Message-ID: 2011/6/4 John Ellson : > What about gar scripts? ? Just "pkg-get -i gar" ? There is also the mgar package, which I highly recommend. It was recently impossible to run checkpkg in an off-buildfarm setting. Last week was a bugfix week for checkpkg, thanks to Igor who attacked and didn't let go until checkpkg was working. Currently, checkpkg will work off-buildfarm if CATALOG_RELEASE is set to current or unstable in your ~/.garrc. I will send a separate, more detailed update to the list later in the week. Maciej From skayser at opencsw.org Mon Jun 27 22:08:44 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 27 Jun 2011 22:08:44 +0200 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: <1309202812-sup-7249@pinkfloyd.chass.utoronto.ca> References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309202812-sup-7249@pinkfloyd.chass.utoronto.ca> Message-ID: <20110627200844.GF25705@sebastiankayser.de> * Ben Walton wrote: > Excerpts from Jonathan Craig's message of Mon Jun 27 11:09:32 -0400 2011: > > Here is my proposed amendment with the pre/post paragraphs to > > indicate placement within current proposal. Wasn't really sure > > whether this was to be submitted by mail or simply edited into wiki > > page. > > I approve of this addition. I'd appreciate it if signers of the > current proposal provide an explicit ACK to this change (or a NACK as > they set fit). ACK. Thanks guys! Sebastian From phil at bolthole.com Tue Jun 28 02:54:06 2011 From: phil at bolthole.com (Philip Brown) Date: Mon, 27 Jun 2011 17:54:06 -0700 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: <1309180908-sup-782@pinkfloyd.chass.utoronto.ca> References: <1309180908-sup-782@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Jun 27, 2011 at 6:23 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Mon Jun 27 09:08:39 -0400 2011: > >> People keep trying to force this into a "human, OR automated process", >> and claiming this is what I want. >> Yet not once have I advocated getting rid of the automated process. My >> preference is for >> "human examination, AND automated process". > > We currently have a human examination with 'automated' process wrapped > around it. ?Normally we'd refer to this as status quo. I guess there's a bit of ambiguity there. there is currently "automated process" in the sense of compiler helpers and checks in gar. But there isnt so much "automated process" with the (take package, and help it flow out to "current") part of things. So in this context, "automated process" is best read as "automated release & validation process". I think a lot of the new proposal is very good in that reguard: making that flow a less manual process gets a thumbs up from me; its way too manual for my liking also. The amount of by-hand messing around with files currently required is not a good thing in my opinion. I also like the fact that the new proposal has *some* measure of automated quality control, in the sense of the "check for bugs before migrating from unstable to current" stuff. Additionally, there is great positive potential for the tie-in for reviewers, in the other thread Maciej started. All of these things are, in my opinion, better than "status quo". I would not prefer things to remain "status quo" indefinately; I myself would like to see most of the improvements suggested in the proposal. Just not 100% of them. From bwalton at opencsw.org Tue Jun 28 05:54:27 2011 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 27 Jun 2011 23:54:27 -0400 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: Message-ID: <1309233097-sup-5348@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Jun 23 20:53:21 -0400 2011: Hi Phil, [In the future, please format your emails in a legible fashion. It's very hard to read through the seemingly random line breaks, extra long lines, missing spaces, strange indentations, etc.] > 1. Amendment: more technical details need to be given. (perhaps as > a side referenced document) The proposal suggests that opencsw adopt > a "new system", without *fully* *defining* this new system at a > technical level. There are some technical specifics, but not full > coverage. There is a lot of [will do, in the future] language > without giving specifics. OpenCSW is supposed to be a technical > organization. It seems to me that we should be voting on specific > full technical implementations, rather than something with fuzzy > chunks in it Some things are technical and require a full technical writeup. Some things are not technical. While the changes required by this proposal will be technical, this proposal is addressing an organizational issue. It says: We want to change directions and start automating the release process. This includes catalog updates, mirror pushes, QA processes, etc. While Maciej has written an excellent tool that handles a large portion of what we think the details will look like, there is more yet to do. At the current time, writing all of the code and tools would be counter-productive as we have not formally adopted the new direction yet. Determining all of the details to begin implementation up front is equally pointless. If the proposal is accepted, there is more discussion to be had. > 2. Amendment: Removal of "Anyone can participate[in the new > process]", and related lines. This line falsely implies that > currently, people are somehow blocked from participating now. This > is untrue, both at the direct package level and at the discussion > level, as shown below. Therefore this red herring should be removed. > (and possibly, maintainers should be re-informed of some facts): Please don't pass this off as 'uninformed maintainers' as that is not what you're dealing with here. We're all well versed in how things work. Participation implies that people work together on an even footing to advance a goal they share. The current system is anything but participatory. In the sense of the proposal, this means that anyone is able to work on the code or documentation. Anyone will be able to review packages and fully contribute to the QA process (regardless if their view lines up with yours). Anyone will be able to suggest modifications to the process and if they're accepted, help implement them. This does not describe the current process. > At the discussion level, all packages "held" from release, are > discussed in the pkgsubmissions mail list. Right now, "anyone can > participate" in the discussion of a held package. People can talk until they're blue in the face, but unless we beat you down with a vote (something that wasn't an option until the election, I might add), packages don't flow unless you allow it. Not participatory. Also, don't overlook the fact that currently packages might be submitted privately. Any ensuing discussion at that point is private. The other party will still talk until they're blue in the face, but it won't be visible to anyone else. > At the direct package participation level: If a maintainer chooses > to have their packages examined/tested before pushing them out to > the general public, they can already drop them in "experimental" and > ask that people look at them before publicly pushing them out to > newpkgs. "Pay no attention to the man behind the curtain." This isn't what we're talking about here. We're talking about holding an equal status in the process. To play on Jonathan's wording, we'd see everyone be freemen instead of serfs. > The fact that others rarely choose look at them now when a > maintainer requests feedback, is not a failure of the current > system, but rather an indication that maintainers rarely choose to > look at other people's packages. It is doubtful that a wholesale > "new system" will change that. There is nothing to be gained presently as it doesn't matter what anyone but the release manager thinks. The new system lays the groundwork for people to begin feeling as though participation might be rewarding instead of masochistic. > If people rarely even look at packages when a maintainer *specifically > requests* feedback, it seems less likely when the whole thing is > automated and there is no explicit request to do so. Given that you've taken the 'anyone can participate' out of context, I'll ignore this bit. > 3. Removal or adjustment of "Packages are subject to stalls or > rejections for non-policy reasons." > > First of all, it implies, FALSELY, that a package can be completely > rejected by the release manager with no recourse. As formalized in > http://wiki.opencsw.org/release-manager , a maintainer can always > call for a vote if they disagree with the stance that the release > manager has taken. This has already happened, twice, and after the > vote, the package(s) were released, so it is a proven effective > method. First off, a vote is a new found power tool that didn't exist until the recent election (on paper yes, in practice no). Before that it was your way or no way, so please don't fall back on this "but you can vote" line that you keep trotting out. This is simply a delay that you've needed to resort to in recent times when you feel that you know better than everyone else but can't bend people to your way of thinking...or tire them out. Secondly, while it's true that we now have a big hammer to wield, it's not something that a small group of people wish to use every time. If we resorted to this every time a package was rejected based on your personal preference, we'd do nothing else. Thus, _in practice_ you can and do reject packages on a regular basis. If you don't believe this, please review the list of stalled packages in (and don't rely on the out of date 00-README that your documentation indicates is the place to look). Thirdly, the wiki page you linked to was only just written when csw-upload-package was originally floated. It is something you wrote without soliciting any input or feedback. You now provide that as a reference to policy? This is about as useful to the discussion as a backronym is to knowing what /etc means. > Additionally, it does not recognize the benefit that policy is not > and should not be set in stone for all time. If a release manager > holds a package, for reasons that are not currently policy, but > perhaps should be, then it is a good thing that discussion take > place. Similarly, it is actually a good thing if the issue gets > forced to a vote, because that way, policy can be officially > adjusted, as the majority vote decides. If this is true, why were there no votes in the two years you yourself were on the board? Why did every issue raised end with the other person giving up? I agree that votes can be useful, but I submit for the record (again!) that for a group our size, they're far too much overhead just to overrule the opinion of a single person. The proposal makes no claims that policy _should_ be set in stone for all time. It only states that the tools should enforce policy as it currently exists. This will require code changes over time to both tighten and relax various checks. The proposal also in no way inhibits new policy from being formed. Issues worthy of policy modification can and will be discussed. When required, votes can decide the outcome. My preference is for people to agree to disagree and move on when they're outnumbered as that is what happens in real life. _Most_ people already do this. > 4. Removal of "All code, tools and documentation will available for > all to see and improve." This falsely implies that there is "hidden > code and/or tools". There is not. All code that is actually > necessary for the release process is already completely public and > published. Published where? I don't see a complete list of tools anywhere so this is hard to judge. > Most other stuff isnt strictly "published", but is readable by any > maintainer who actually cares, in my home directory on bender. It > isnt much more than convenient aliases,etc. I have, akin to aliases > in a .bashrc, etc. Why isn't this published? This is about as open as OpenVMS. Look but don't touch. Do you really think that aliases in your shell environment count as open to the public? > The release process as a whole has been fully documented also. If > anyone cares to dispute this, then please point out specific areas > or tools that either lack documentation, or are hidden. I have > previously requested this, when this claim was made recently, but > was only met with groundless mumblings that things were still > somehow "hidden", without any specifics given. "A catalog update script is called..." What script? Where is it? Your documentation is hand-wavy at best and nowhere near what you routinely demand of others. (Including here, as item #1!) Nobody (myself included) to my knowledge has requested specific improvements, but you've not (ever) volunteered this type of improvement yourself. You recently implemented a cron job to remind you to manually run some part of the process. Is this documented? > 5. Removal of "unclear path to resolution of disputes" claim. There > is actually a clear path: discussion on pkgsubmissions list -> > discussion on maintainers list -> vote if needed. As far as > complexity, this is virtually identical to the "new" path to > resolution. The main difference is only that under the current > system, a package deemed as "bad" will never be released, whereas > under the "new" system, a package deemed as "bad" will first be > released publically, but then after some indeterminate length of > time.. potentially a **month or more**.. eventually be retracted. I submit that this is not clear. Especially to newcomers. Any attempts at clarifying this have met with the same thing we see here. Delays. Demands for fully formed policy that is never good enough. Discussions that just don't end until the other party tires, etc. Currently it can take a "**month or more**" to get good packages out the door. You've stated on several occasions that QA people everywhere have the privileges that you exercise; This may be true, but I submit that you've gone beyond this. The tail, more often than not, wags the dog. > 6. Removal or adjustment of "All participants will have equal > standing". It would actually be harmful to opencsw to follow that > sentiment completely. Specifically, to have two new maintainers sign > off on each others packages, will inevitably lead to some mistakes > that could be avoided by the oversight of more experienced > maintainers. First, please don't extrapolate the proposal to things that have not been decided yet. You're implying that there will be some sort of sign-off process. While it's not outside the realm of possibility that there may come to be a system that resembles this, it is not a part of the proposal. (I would not support a system that sets us up for the master/slave relationship again.) Second, there is no need to remove or adjust this. It's _what we want_ Phil. OpenCSW should encourage new people to publish packages. Will they make mistakes? Sure. Will they learn as time goes on? Sure. The key point is that in the current system, interactions leave them with a lot of stick and next to no carrot. (While this isn't a theoretical deficiency in the current package flow, it's a practical one.) By opening the process and giving new people an equal voice, we intend to drastically change the carrot/stick ratio. > 7. A technical implementation issue, that is not properly addressed > in the proposal: > > There is no such thing as a *fully* automated release system: at > some point, issues come up that require manual intervention. For > example, package renames, and removals. or fixing bugs in some > unforseen interaction of the system and a new package. > > The proposal declares that catalog signatures will be generated > automatically. However, who or what group will be responsible to > manage the catalog when the automated system is either inadequate, > or fails? This is covered quite adequately by Jonathan's proposed amendment. Again, my thanks to Jonathan for providing constructive feedback. As long as Peter F, William and Geoff are ok with the change, this will land on the proposal before the vote. > 8. A technical implementation issue not addressed at all in the > proposal: What about package takeovers? is it going to be allowable > for any maintainer to take over any package, at any time? or remove > any package at any time? Please see answer #1 > 9. A technical implementation issue not addressed at all in the > proposal: > > "A package may not progress from unstable to current with open > bugs." Please see answer #1. > 10. technical implementation suggestion: > > If the goal is to make it *easier* for people to get involved in the > QA process, I would suggest that either a different mechanism than > bug filing be used, OR an alternative interface to the bug system be > provided. I personally feel that the existing "exchange emails over > the pkgsubmissions mailing list" is the smallest pain point in this > sort of process. Forcing people to move to (our existing) bug > system for this kind of discussion, makes it *more* difficult, not > easier, to be involved in QA, in my opinion. It's possible other bug > systems would do better; I'm just limiting my comments to our > existing one. Things like this will be good discussion if the proposal is adopted. Nobody loves mantis and we've already discussed jira as a possible upgrade. I do however think that Jonathan is correct that a good bug tracking system is the best place for these discussions. Some things will need to move to the list, but having a record of this discussion attached in a meaningful way (meta data, in a sense) to the package is quite helpful. > 11. technical implementation issue: > > "By opening up the QA process such that multiple people can easily > participate and have equal standing on the matters at hand, we feel > that overall package quality will improve;" > > Unfortunately, (as mentioned on maintainers list previously), making > the capability available, does not actually mean that people will > definitely make use of it. The new proposal as prototyped, > currently allows for LESS people to scrutinize a package than > currently. Actually, it allows for more people to scrutinize a package, and more easily at that. As written, it simply requires less scrutiny. > At the moment, a release manager is guaranteed to at least glance at > it. Whereas with the "new process", a package may (and I claim, will > *usually*) get released with no-one but the maintainer ever looking > at it. Once again, I'd note that you can and do just 'run the scripts' too. If you take 'glance' to mean cut/paste the file name into the cli then I'd accept your statement. Other than that the words guaranteed and glance taken to mean "inspected every package equally" do not apply to the current process. > If the goal is truly, "more/better QA", then a proposed remedy for > this, is to put in mandatory hooks for the "migrate from unstable to > current" step, to require that at least one other person besides > maintainer has examined the package. We have different views of how to achieve more/better QA. You prefer the parent/child approach while we'd treat everyone as adults. You'd take status quo with a few new tools written. We think the status quo is not adequate for fostering new maintainers that might grow to be capable of providing good QA or at the very least not requiring it constantly. We also think that QA as administered by feedback from other maintainers and bug reports would be both more productive and more encouraging than the current system. This will lead to more willingness to address issues that are found. That leads directly to improved quality. The proposal does not say that quality will improve immediately, it simply says that it will improve. Maybe it will take time to shake off the low morale and attract new blood? Maybe things will spring back to life quickly? My crystal ball isn't working. I do however feel that quality will, at a minimum, not decline. I'm a consumer of the packages we release and have no interest in causing myself more work by allowing catalog quality to deteriorate. As far as I know, all signers are also catalog consumers and feel the same way. (I suspect they all run more boxes than I do and have more at stake.) > If on the other hand, the goal is really "to allow packages to be > released with no one but the maintainer ever looking at it", then > all claims about better QA should be removed from the proposal, and > the stated "benefits" of the proposal should be updated to reflect > that. Modification of the wording is only required if we feel your statements are correct. This is not in fact the goal of the proposal. Thus concludes my response to your proposed amendments and requested corrections. Unless you have actual constructive requests that improve the proposal without altering its intent, do not expect any further replies from me on this matter. One evening devoted to a single person/response is enough. When I've collected the remaining ACK/NACK for Jonathan's amendment, we can move forward with the vote. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From gadavis at opencsw.org Tue Jun 28 18:52:54 2011 From: gadavis at opencsw.org (Geoff Davis) Date: Tue, 28 Jun 2011 09:52:54 -0700 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: <1309202812-sup-7249@pinkfloyd.chass.utoronto.ca> References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309202812-sup-7249@pinkfloyd.chass.utoronto.ca> Message-ID: I agree to it as well. On Jun 27, 2011, at 12:29 PM, Ben Walton wrote: > Excerpts from Jonathan Craig's message of Mon Jun 27 11:09:32 -0400 2011: > > Hi Jonathan, > >> Here is my proposed amendment with the pre/post paragraphs to >> indicate placement within current proposal. Wasn't really sure >> whether this was to be submitted by mail or simply edited into wiki >> page. > > I approve of this addition. I'd appreciate it if signers of the > current proposal provide an explicit ACK to this change (or a NACK as > they set fit). > > Thanks > -Ben > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From phil at bolthole.com Tue Jun 28 19:59:37 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 28 Jun 2011 10:59:37 -0700 Subject: [csw-maintainers] tech board? Message-ID: This was taken from a longer reply to a different email. I think it may merit separate discussion. . Up to you folks. Ben wrote: > I agree that votes can be useful, but I submit for > the record (again!) that for a group our size, they're far too much > overhead just to overrule the opinion of a single person. > [..] > My preference is for people > to agree to disagree and move on when they're outnumbered as that is > what happens in real life. _Most_ people already do this. When "a majority" of the group have spoken, this makes sense. However, "for a group our size", having even 3 or 4 people chime in on a technical issue, does not constitute a majority. It could be that the majority is actually against the 3 or 4. In contrast, if you think having things decided by a smaller number of people is "more efficient" or something, than having full membership votes, then I would suggest having a "technical board" put together, so that sort of thing could be worked out faster. In that sort of situation, if the tech board is X people, and (X/2)+1 agree on something, then it could be considered settled. I think the problem here might be that you may think that (you+personX+personY) already compose a "tech board", so if those people agree, you think everyone else should give way. To which I say, if you wish opencsw to work that way, then make the "tech board" a formal entity. Until then, the only really "everyone's opinion is equal" appropriate way to resolve deadlock, is a full vote, to make sure that everyone's opinion is equally heard. From phil at bolthole.com Tue Jun 28 20:30:45 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 28 Jun 2011 11:30:45 -0700 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: <1309233097-sup-5348@pinkfloyd.chass.utoronto.ca> References: <1309233097-sup-5348@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Jun 27, 2011 at 8:54 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Thu Jun 23 20:53:21 -0400 2011: > > Hi Phil, > > [In the future, please format your emails in a legible fashion. ?It's > very hard to read through the seemingly random line breaks, extra long > lines, missing spaces, strange indentations, etc.] Sorry, It's "gmail behaving badly", I suppose. (web interface). I thought it was wrapping things appropriately, but I guess not. Suggestions on how to improve gmail configs would be nice. First of all, thank you for spending what was obviously considerable time writing your response. I appreciate that you were willing to put in that effort. You went to more effort than I requested though. I only requested a re-review of 2-5. On the negative side.. a chunk of what you wrote, was non-factual. There was a chunk of ad-homimem attacks, and stating assumptions about my motivation. You also spent many paragraphs writing about "feelings". Can we leave those out and have an objective discussion? I will attempt to clip out all that stuff, and continue with a fact-based discussion. I also removed the parts where you factually responded to what I wrote, such as #10. Thank you for that. >> 2. Amendment: Removal of "Anyone can participate[in the new >> process]", and related lines. ?This line falsely implies that >> currently, people are somehow blocked from participating now. >... > In the sense of the proposal, this means that anyone is able to work > on the code or documentation. ?Anyone will be able to review packages > and fully contribute to the QA process (regardless if their view lines > up with yours). ?Anyone will be able to suggest modifications to the > process and if they're accepted, help implement them. I think perhaps there is ambiguity of wording then. I was reading it as relating to just the day-to-day flow of packages, but it seems you intend it to cover more meaning that that. The current summary merely reads, "1. Anyone can participate". I would like to suggest you expand it to include the meaning that you wrote above. Perhaps, "1. Anyone can participate in shaping the code, documentation, and the overall process itself" >>[3] First of all, it implies, FALSELY, that a package can be completely >> rejected by the release manager with no recourse. As formalized in >> http://wiki.opencsw.org/release-manager , a maintainer can always >> call for a vote if they disagree with the stance that the release >> manager has taken. This has already happened, twice, and after the >> vote, the package(s) were released, so it is a proven effective >> method. > > First off, a vote is a new found power tool that didn't exist until > the recent election (on paper yes, in practice no). Before that it > was your way or no way, [assumptions and accusations about motivation snipped] you're essentially contradicting yourself. past situations are irrelevant: what matters is current policy. current policy is that people can request a vote on this sort of thing. Additionally, it is more than theoretical: it has been done so twice, AND I have abided by the vote without further complaint. So it is a proven effective tool. Therefore, please adjust the wording. >> 11. technical implementation issue: ... >> Unfortunately, (as mentioned on maintainers list previously), making >> the capability available, does not actually mean that people will >> definitely make use of it. The new proposal as prototyped, >> currently allows for LESS people to scrutinize a package than >> currently. > > Actually, it allows for more people to scrutinize a package, and more > easily at that. what you wrote, does not contradict what I said. The new system as proposed, allows both "more people" and *also* "less people", unless hooks are put in to specifically require "at least one other person". ########################################## This ends my official response to your comments on the proposal. I hope you will take a little extra time to consider them. Below, is a response to some (but not all of the ) incorrect things you wrote, that I would like to respond to, even though they are not directly bearing on the above. > Also, don't overlook the fact that currently packages might be > submitted privately. ?Any ensuing discussion at that point is private. > The other party will still talk until they're blue in the face, but it > won't be visible to anyone else. You seem to be complaining on behalf of people who have no complaint. I think I can accurately say that the people who choose to submit packages privately to me, do so because we work well together, and they that is the individual's choice. The people who do that, work well with me. But if a problem occurs, they know that they always have recourse to a public discussion of issues. > ?If > we resorted to this every time a package was rejected based on your > personal preference, we'd do nothing else. ?Thus, _in practice_ you > can and do reject packages on a regular basis. This is a gross distortion of fact. You talk about "in practice". So, "practically" go do a count of how many packages have been "denied" in the manner you describe, over the last 6 months. (if you choose to do this, please be specific about package names) No more than 3, I would guess. 1 vote every 2 months, is "doing nothing else"? Please be more objective in the future. > If you don't believe this, please review the list of stalled packages > in [newpkgs] you mean old files in newpkgs? that is not a valid way to tally this: a lot of those are actually files that have just not been cleaned up properly, when a maintainer submitted new files to fix issues with the older ones. (sometimes due to renames) a couple are ones that i myself should have removed on publishing, but missed them. Some I think are ones where I pointed out clear, undisputed policy issues.. but the maintainer just forgot to come back to them. If you took the time to actually go through the pkgsubmissions list and count that way, I think it would be close to my estimate of 3 in 6 months. I've taken the liberty to clean up some of the bogus lagging ones now. but the others are still there for now, simply because its a lot of hassle for me to go dig up specifics for each and every one. > Thirdly, the wiki page you linked to [about release managers] > was only just written when > csw-upload-package was originally floated. ?It is something you wrote > without soliciting any input or feedback. ?You now provide that as a > reference to policy? I wrote that as a summary for what I do in pratice.?I consider that a "draft policy"; it describes our "de facto" existing policies accurately, I think. It seemed appropriate that if people were voting against "a release manager", they should at least have some definition about what a release manager is and does. If people cared enough about having a release manager, to have a separate vote/discussion on that page, I'd be happy to see it amended. > If this is true, why were there no votes in the two years you yourself > were on the board? ?Why did every issue raised end with the other > person giving up? I would guess for two reasons: 1. we did not have a nice method of voting during that time 2. people may have incorrectly assumed that since I was President, I would either not allow the vote (ahem, sounds familiar), or not abide by it. In both cases, such assumptions would have been incorrect. [bit about technical issue resolution, moved to separate email, "tech board?" ] >> 5. Removal of "unclear path to resolution of disputes" claim. ?There >> is actually a clear path: discussion on pkgsubmissions list -> >> discussion on maintainers list -> vote if needed. ?As far as >> complexity, this is virtually identical to the "new" path to >> resolution. >.... > > Currently it can take a "**month or more**" to get good packages out > the door. only very very rarely. In real-world QA, that sometimes happens. In the NEW system, that will most likely happen sometimes too. Are you planning to put in some kind of "hey this has been waiting, lets ignore all bug reports and publish it"! system? If not, then this is a bogus comparison. From pfelecan at opencsw.org Tue Jun 28 22:05:29 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 28 Jun 2011 22:05:29 +0200 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: <1309202812-sup-7249@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Mon, 27 Jun 2011 15:29:21 -0400") References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309202812-sup-7249@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > Excerpts from Jonathan Craig's message of Mon Jun 27 11:09:32 -0400 2011: > > Hi Jonathan, > >> Here is my proposed amendment with the pre/post paragraphs to >> indicate placement within current proposal. Wasn't really sure >> whether this was to be submitted by mail or simply edited into wiki >> page. > > I approve of this addition. I'd appreciate it if signers of the > current proposal provide an explicit ACK to this change (or a NACK as > they set fit). ++ -- Peter From pfelecan at opencsw.org Tue Jun 28 22:33:01 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 28 Jun 2011 22:33:01 +0200 Subject: [csw-maintainers] Assessing catalog quality In-Reply-To: (Philip Brown's message of "Sat, 25 Jun 2011 18:16:51 -0700") References: Message-ID: Philip Brown writes: > How do you measure the "quality" of a programmer's work? > At one point, IBM said, "We'll measure it based on KLOC". > Epic Fail. > > After 40 years, there is still no uniform "metric" for that sort of > thing. Nor is it possible to uniformly create one. > Some kinds of quality are simply not possible to reduce to "metrics". LOC is the beginning of effort measure. Not really a failure except when used as a silver bullet. Quality measure starts when you assess cyclomatic complexity, function point, regression, &c. But that is CS 101... -- Peter From phil at bolthole.com Tue Jun 28 22:51:32 2011 From: phil at bolthole.com (Philip Brown) Date: Tue, 28 Jun 2011 13:51:32 -0700 Subject: [csw-maintainers] Assessing catalog quality In-Reply-To: References: Message-ID: On Tue, Jun 28, 2011 at 1:33 PM, Peter FELECAN wrote: > Philip Brown writes: > >> How do you measure the "quality" of a programmer's work? >> At one point, IBM said, "We'll measure it based on KLOC". >> Epic Fail. >> >> After 40 years, there is still no uniform "metric" for that sort of >> thing. Nor is it possible to uniformly create one. >> Some kinds of quality are simply not possible to reduce to "metrics". > > LOC is the beginning of effort measure. Not really a failure except when > used as a silver bullet. (...) yes and no. it can *sometimes* be useful as a relative measure. but the problem lies in the management axiom of (make sure you reward what you are really interested in). When "more KLOC=good", programmers start to needlessly bloat programs. (the extra irony being that in reality, usually a program is good specifically because it has fewer lines) That type of scenario is true failure of applying metrics to a problem. Probably many others here have also experienced the unwanted side effects of other metrics gone bad. For example; When metrics management people decide "bugs closed quickly=good", then support people start "accidentally" closing bug reports that have been open long enough to make them start looking bad. And, curiously, there is no way to re-open the original bug, you must create a whole new ticket. Resetting the time factor. What an amazing coincidence Similarly, when companies decide "few bugs filed=good", and motivate staff based on low total bug count... and then the staff then proceeds to make it almost impossible for people to actually open a bug. Attempting to "increase quality" based on blind application of metrics, can sometimes lead to places not originally intended. Even when there is not deliberate subversion of the metrics like the above examples... sometimes they subconciously skew people towards unwanted behaviour. So, metrics need to be applied cautiously. From bwalton at opencsw.org Thu Jun 30 02:45:56 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 29 Jun 2011 20:45:56 -0400 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> Message-ID: <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca> Excerpts from Jonathan Craig's message of Mon Jun 27 11:09:32 -0400 2011: Hi Jonathan, > Here is my proposed amendment with the pre/post paragraphs to indicate > placement within current proposal. Wasn't really sure whether this > was to be submitted by mail or simply edited into wiki page. William gave this an ACK in irc, so please go ahead and add the paragraph to the proposal. I hope he'll still send a mail to this thread but I'd like to move forward. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From william at wbonnet.net Thu Jun 30 06:53:27 2011 From: william at wbonnet.net (William Bonnet) Date: Thu, 30 Jun 2011 06:53:27 +0200 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca> References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca> Message-ID: <4E0C0147.4080100@wbonnet.net> Hi all Late late late .... :) Sorry Yes i do ack cheers W. Le 30/06/2011 02:45, Ben Walton a ?crit : > Excerpts from Jonathan Craig's message of Mon Jun 27 11:09:32 -0400 2011: > > Hi Jonathan, > >> Here is my proposed amendment with the pre/post paragraphs to indicate >> placement within current proposal. Wasn't really sure whether this >> was to be submitted by mail or simply edited into wiki page. > William gave this an ACK in irc, so please go ahead and add the > paragraph to the proposal. I hope he'll still send a mail to this > thread but I'd like to move forward. > > Thanks > -Ben > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From maciej at opencsw.org Thu Jun 30 11:25:26 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 30 Jun 2011 10:25:26 +0100 Subject: [csw-maintainers] Assessing catalog quality In-Reply-To: References: Message-ID: 2011/6/28 Philip Brown : > Attempting to "increase quality" based on blind application of > metrics, can sometimes lead to places not originally intended. Even > when there is not deliberate subversion of the metrics like the above > examples... sometimes they subconciously skew people towards unwanted > behaviour. ?So, metrics need to be applied cautiously. Certainly. Does it mean that you agree that cautiously applied metrics can be useful? Or do you believe that there are no meaningful metrics that can be used to assess the quality of our package catalog, and the only thing we have to go on, is people's opinions? Maciej From phil at bolthole.com Thu Jun 30 18:09:51 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 30 Jun 2011 09:09:51 -0700 Subject: [csw-maintainers] Assessing catalog quality In-Reply-To: References: Message-ID: 2011/6/30 Maciej Blizi?ski : > 2011/6/28 Philip Brown : >> Attempting to "increase quality" based on blind application of >> metrics, can sometimes lead to places not originally intended. Even >> when there is not deliberate subversion of the metrics like the above >> examples... sometimes they subconciously skew people towards unwanted >> behaviour. ?So, metrics need to be applied cautiously. > > Certainly. ?Does it mean that you agree that cautiously applied > metrics can be useful? yes. From bwalton at opencsw.org Thu Jun 30 21:33:12 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 30 Jun 2011 15:33:12 -0400 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: <1309461613-sup-5409@pinkfloyd.chass.utoronto.ca> References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca> <4E0C0147.4080100@wbonnet.net> <1309461613-sup-5409@pinkfloyd.chass.utoronto.ca> Message-ID: <1309462365-sup-8809@pinkfloyd.chass.utoronto.ca> > Excerpts from William Bonnet's message of Thu Jun 30 00:53:27 -0400 2011: > Late late late .... :) No problem. Jonathan has now amended the proposal and the ballot is ready to roll. Phil: You're happy with the 'against the proposal' side of the vote writeup? (No longer labelled as 'status quo.') I'm thinking July 1 - July 7 (GMT). Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Thu Jun 30 22:13:30 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 30 Jun 2011 21:13:30 +0100 Subject: [csw-maintainers] Assessing catalog quality In-Reply-To: <4E079060.5050104@wbonnet.net> References: <4E079060.5050104@wbonnet.net> Message-ID: 2011/6/26 William Bonnet : > Some of the indicators you mention already exist. I provide the url in the > rest of the message. Let me know if you need to summarize all this under a > specific "catalog qa page" Cool, this is excellent stuff. William, do you think we could extend your tech behind the package count graph and use it to plot more data? I imagine that there would be a separate package with catalog metrics. Can you share the information on how to create graphs on our web site? Maciej From phil at bolthole.com Thu Jun 30 22:46:46 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 30 Jun 2011 13:46:46 -0700 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: <1309462365-sup-8809@pinkfloyd.chass.utoronto.ca> References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca> <4E0C0147.4080100@wbonnet.net> <1309461613-sup-5409@pinkfloyd.chass.utoronto.ca> <1309462365-sup-8809@pinkfloyd.chass.utoronto.ca> Message-ID: On Thu, Jun 30, 2011 at 12:33 PM, Ben Walton wrote: > > Phil: You're happy with the 'against the proposal' side of the vote > writeup? ?(No longer labelled as 'status quo.') > > I'm thinking July 1 - July 7 (GMT). I would like to request an "amendment" to the ballot itself. The labeling has changed, but semantically, the meaning will be seen as the same. I request that there be an option for those people who see a value in required 2nd party review, to be able to register that opinion with their vote, separate from whether they support the new mechanisms for package release flow. As an example, based on the most recent ballot sample, my proposed single added line would look like this: A) I accept the proposal *B) I would like to see the proposal modified to have some form of 2nd party mandated review C) I do not accept the proposal D) I abstain The specific nature of the review, or persons doing the review, will remain open; the purpose of this vote choice would not be to pick a specific mechanism, but only to register that there is sufficient interest to warrant discussion on it. The "2nd party review" might be via a formal review team. It might be via an elected review manager. It might be through some other means. It might be at initial entry, or it might be only for migration from unstable to current. We havent discussed those things. Rather than spend more time discuss those things right now, I'm suggesting this be inserted as an option into this current vote, as a time saver. If either A or B were chosen, coding, development, etc. on the new mechanisms would still proceed, so there would be virtually no "delay" in that area either way. The only difference between the two, would be that if a noticable amount of people voted for B, it would then be shown as worthwhile to discuss options on review further, while work continued to bring it to Contrariwise, if there was only one person voting for B, it would be clear that further discussion in that area would be a waste of time, and that the issue is dead. From maciej at opencsw.org Thu Jun 30 22:54:50 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 30 Jun 2011 21:54:50 +0100 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca> <4E0C0147.4080100@wbonnet.net> <1309461613-sup-5409@pinkfloyd.chass.utoronto.ca> <1309462365-sup-8809@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/6/30 Philip Brown : > I request that there be an option for those people who see a value in > required 2nd party review, (...) The notion of reviews needs to be defined with more precision. In one understanding, a review means reading and providing feedback, with no decision making. In the other understanding, a review means reading something and making the go / no go decision. The difference is crucial, and you need to specify which one you mean. Maciej From maciej at opencsw.org Thu Jun 30 23:13:47 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Thu, 30 Jun 2011 22:13:47 +0100 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca> <4E0C0147.4080100@wbonnet.net> <1309461613-sup-5409@pinkfloyd.chass.utoronto.ca> <1309462365-sup-8809@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/6/30 Philip Brown : > On Thu, Jun 30, 2011 at 12:33 PM, Ben Walton wrote: >> >> Phil: You're happy with the 'against the proposal' side of the vote >> writeup? ?(No longer labelled as 'status quo.') >> >> I'm thinking July 1 - July 7 (GMT). > > I would like to request an "amendment" to the ballot itself. > The labeling has changed, but semantically, the meaning will be seen > as the same. > > I request that there be an option for those people who see a value in > required 2nd party review, to be able to register that opinion with > their vote, separate from whether they support the new mechanisms for > package release flow. > > As an example, based on the most recent ballot sample, my proposed > single added line would look like this: > > A) I accept the proposal > *B) I would like to see the proposal modified to have some form of 2nd > party mandated review > C) I do not accept the proposal > D) I abstain > > > The specific nature of the review, or persons doing the review, will > remain open; > the purpose of this vote choice would not be to pick a specific > mechanism, but only to register that there is sufficient interest to > warrant discussion on it. > > The "2nd party review" ?might be via a formal review team. It might be > via an elected review manager. It might be through some other means. > It might be at initial entry, or it might be only for migration from > unstable to current. We havent discussed those things. > > Rather than spend more time discuss those things right now, I'm > suggesting this be inserted as an option into this current vote, as a > time saver. > > If either A or B were chosen, coding, development, etc. on the new > mechanisms would still proceed, so there would be virtually no "delay" > in that area either way. The only difference between the two, would be > that if a noticable amount of people voted for B, it would then be > shown as worthwhile to discuss options on review further, while work > continued to bring it to > > > Contrariwise, if there was only one person voting for B, it would be > clear that further discussion in that area would be a waste of time, > and that the issue is dead. Proposal processing goes like this: 1. A proposal is written 2. A vote is held, where options are: accepting, not accepting, abstaining 3. If the vote is conclusive and positive, the proposal is implemented If you have an idea for another proposal, you can write it up and put it up for the vote. The same procedure will be applied. Your argument is that your proposal would be similar to the current one. If this is the case, and the current proposal is accepted, you only need to write up the difference, and we can have the other vote. My role as the secretary is to implement the vote procedure, and the procedure is described as above. I'm sorry, but even if it is suboptimal from your point of view, I am obliged to protect it and ensure that the vote process reaches completion. Maciej From phil at bolthole.com Thu Jun 30 23:54:32 2011 From: phil at bolthole.com (Philip Brown) Date: Thu, 30 Jun 2011 14:54:32 -0700 Subject: [csw-maintainers] amendments and issues with recent prop In-Reply-To: References: <1309009539-sup-9132@pinkfloyd.chass.utoronto.ca> <1309139539-sup-2937@pinkfloyd.chass.utoronto.ca> <1309394682-sup-1467@pinkfloyd.chass.utoronto.ca> <4E0C0147.4080100@wbonnet.net> <1309461613-sup-5409@pinkfloyd.chass.utoronto.ca> <1309462365-sup-8809@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/6/30 Maciej Blizi?ski : > > Proposal processing goes like this: > > 1. A proposal is written > 2. A vote is held, where options are: accepting, not accepting, abstaining > 3. If the vote is conclusive and positive, the proposal is implemented > > If you have an idea for another proposal, you can write it up and put > it up for the vote. ?The same procedure will be applied. ?Your > argument is that your proposal would be similar to the current one. > If this is the case, and the current proposal is accepted, you only > need to write up the difference, and we can have the other vote. > > My role as the secretary is to implement the vote procedure, and the > procedure is described as above. ?I'm sorry, but even if it is > suboptimal from your point of view, I am obliged to protect it and > ensure that the vote process reaches completion. > When was the above procedure voted on? or approved "by consensus"? or even brought up as a proposal for a discussion? As far as I can recall. it wasnt. So I'm missing how it is "your duty" to follow a process that was never approved, to my knowledge? Your description of duty to "protect" a proposal, seems rather odd. A secretary of an organization is traditionally only a recorder and processor of ballots, votes, and other similar duties. Not a champion or protector of any specific proposal. also, I am fully encouraging that this "vote reaches completion". I'm only requesting that the ballot have an additional choice box on it. I'm not requesting on more discussion before the vote. only that the vote have more choices on it. So there is nothing about this threatening "completion of the vote" From rupert.thurner at gmail.com Thu Jun 2 16:30:44 2011 From: rupert.thurner at gmail.com (rupert THURNER) Date: Thu, 02 Jun 2011 14:30:44 -0000 Subject: [csw-maintainers] --catalog-release does not exist ? Message-ID: what does the error message "--catalog-release does not exist" mean? and i am wondering why this error message cannot be presented in 2 lines insead of 40 :) $ csw-upload-pkg pkgs/02.Jun.2011/* Processing 2 file(s). Please wait. Uploading 'pkgs/02.Jun.2011/mercurial-1.8.4,REV=2011.06.02-SunOS5.9-i386-CSW.pkg.gz' Uploading 'pkgs/02.Jun.2011/mercurial-1.8.4,REV=2011.06.02-SunOS5.9-sparc-CSW.pkg.gz' Checking 1 package(s) against catalog unstable sparc SunOS5.9 ERROR: --catalog-release does not exist Checking 1 package(s) against catalog unstable i386 SunOS5.9 ERROR: --catalog-release does not exist Checking 1 package(s) against catalog unstable sparc SunOS5.10 ERROR: --catalog-release does not exist Checking 1 package(s) against catalog unstable i386 SunOS5.10 ERROR: --catalog-release does not exist Checks failed for catalogs: - sparc SunOS5.9 mercurial-1.8.4,REV=2011.06.02-SunOS5.9-sparc-CSW.pkg.gz To see errors, run: /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.9 --architecture sparc 5c73fa54a7b1e7fc0c3972748464c826 - i386 SunOS5.9 mercurial-1.8.4,REV=2011.06.02-SunOS5.9-i386-CSW.pkg.gz To see errors, run: /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.9 --architecture i386 b2bb56a6f126713461695972ec8b9a3a - sparc SunOS5.10 mercurial-1.8.4,REV=2011.06.02-SunOS5.9-sparc-CSW.pkg.gz To see errors, run: /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.10 --architecture sparc 5c73fa54a7b1e7fc0c3972748464c826 - i386 SunOS5.10 mercurial-1.8.4,REV=2011.06.02-SunOS5.9-i386-CSW.pkg.gz To see errors, run: 6 b2bb56a6f126713461695972ec8b9a3a Packages have not been submitted to the unstable catalog. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej.blizinski at gmail.com Sat Jun 4 19:42:06 2011 From: maciej.blizinski at gmail.com (=?UTF-8?Q?Maciej_Blizi=C5=84ski?=) Date: Sat, 04 Jun 2011 17:42:06 -0000 Subject: [csw-maintainers] how to set up a local buildhost? In-Reply-To: <4DEA660B.4080102@opencsw.org> References: <4DEA660B.4080102@opencsw.org> Message-ID: Em 04/06/2011 18:06, "John Ellson" escreveu: > > Now that I have Solaris-10 running on a virtual host locally, is there > an easy way I can set it up as a buildhost? > > If I could do that, I could use it to build the graphviz nightly > development snapshots. It is an excellent idea to set up a build host! I have a partly written howto document. I can send you a copy and help you with any issues you might run into along the way. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From shuttlebox at gmail.com Sun Jun 12 04:06:14 2011 From: shuttlebox at gmail.com (Peter Bonivart) Date: Sun, 12 Jun 2011 02:06:14 -0000 Subject: [csw-maintainers] Idea for a new check: binary name conflicts In-Reply-To: <1307843586-sup-7663@pinkfloyd.chass.utoronto.ca> References: <1307843586-sup-7663@pinkfloyd.chass.utoronto.ca> Message-ID: <-3414185869384472853@unknownmsgid> On 12 jun 2011, at 03:57, Ben Walton wrote: > Excerpts from Maciej Blizi?ski's message of Sat Jun 11 19:18:08 -0400 2011: > > Hi Maciej, > >> One of our guidelines has historically been to not provide binaries >> in /opt/csw/bin named the same way as the ones in /usr/bin. For >> instance, bug 4533 has been filed because cups packages provide >> /opt/csw/bin/lp which conflicts with /usr/bin/lp. > > I'm not sure I'd consider this a problem. If you're using cups, you > most likely want /opt/csw/bin/lp. You don't want to have to learn new > commands for things that have traditional names (lp, lpstat, etc) > because cups is in play either. > >> What are your thoughts on adding a check for binary name conflicts? > > I don't see it as a conflict personally. The filesystem provides a > separate name space and we're using it. If you want the system lp, > either set the path accordingly or fully qualify it. No point in > jumping through hoops for something like this, imo. I agree with Ben here. /peter From rupert.thurner at gmail.com Sun Jun 26 09:08:12 2011 From: rupert.thurner at gmail.com (rupert THURNER) Date: Sun, 26 Jun 2011 07:08:12 -0000 Subject: [csw-maintainers] wiki access? Message-ID: i tried to edit http://wiki.opencsw.org as user ThurnerRupert, but it would not let me. joining returned: You can not apply. It seems you have already applied for membership. where does such an application go? it seems to be my fault that i cannot remember when i applied, and not tracking it ... rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: