From dam at opencsw.org Mon Aug 2 10:04:49 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 2 Aug 2010 10:04:49 +0200 Subject: [csw-maintainers] Packaging gems and package naming conventions In-Reply-To: <1280367168-sup-198@pinkfloyd.chass.utoronto.ca> References: <1280277995-sup-9817@pinkfloyd.chass.utoronto.ca> <9F4573FD-E9DD-45CC-9986-6E2D4C60AFD1@opencsw.org> <1280367168-sup-198@pinkfloyd.chass.utoronto.ca> Message-ID: <44FFA5AA-2C9C-445E-9D56-8FD770DD9012@opencsw.org> Hi Ben, Am 29.07.2010 um 04:07 schrieb Ben Walton: > Excerpts from Dagobert Michelsen's message of Wed Jul 28 03:45:33 > -0400 2010: >> BTW, there is >> http://rubyforge.org/projects/gem2rpm/ >> Maybe this can be used to rip out the dependencies and stuff to make >> an initial GAR Makefile? > > How about the attached script? It likely needs a bit of work yet, but > it hits the basics. I'll take a look when my connectivity is better :-) > There is a wrinkle with gem packaging that I alluded to in > irc...dependency hell the likes the world hasn't seen in a long time. > > Gems can declare dependencies on other gems, including locking down to > a specific version of that gem. While it's easy to say "ok, we'll > just ensure we always update in steps that 'fit'" that won't work in > practice as you may find things like (encountered today): Yep, already noticed. rack 1.1.0 and 1.2.1 are incompatible enough to must have both. > redmine depends on the gem rack = 1.0.1 and complains loudly if you > have some other version. It also depends on rails 2.3.5 and does the > same. > > So...ok, no problem, we'll package multiple versions of gems. How do > we do this sanely? Would our rails gem be rails235? I would prefer to go that way. The current solution of share libraries seems suboptimal to me as it complicates updates. > Would our rails > gems simply deliver rails 2.3.5 and 2.3.8 (current) in a single > package? I would rather not do that as the packages are already really big (1 MB some of them, compressed!). > The first is nasty and ambiguous. The second may work, but makes it > hard to know when versions can be dropped from the package. > > We could make the argument that we only package gems that will > play nicely with each other, but this could rule out various gems from > being packaged. Nope, no option. 'rack' is a must. > Think of the case where we've already pushed rails > (at 2.3.8) and now somebody wants to package redmine[1]. > > [1] This can be worked around as redmine will ship release tarballs > with the full rails stack in the vendor/ dir, but that's not the > point here. It would make packages even bigger. The GEMs packaged now in mgar/pkg/rbgems at http://mirror.opencsw.org/experimental.html#rubygems are packages with standard catalog naming. I tend to redo all of them with explicit stripped version (2.3.5 would become 235), or gem_rubynetldap would become gem_rubynetldap004. There should also be an enpty stub depending on the latest which would be required by packaging with a >= dependency. Other topic: documentation. Having both rdoc and ri docs is quite large, most of the time the documentation is much larger in size and much, much larger in terms of files. I tend to split it off, but the standard _doc and -doc suffixes together with the gem prefix would leave only very little space for the actual gem name making identification difficult. I tend to increase the maximum length of package and catalog names for the sake of consistency. Best regards -- Dago From dam at opencsw.org Mon Aug 2 13:19:24 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 2 Aug 2010 13:19:24 +0200 Subject: [csw-maintainers] Updating the current/ buildfarm to current. Message-ID: <2498E80F-7209-4C2E-BC6E-69AAD5B230CB@opencsw.org> Hi, I am updating the current buildfarm to current/ now. Please stand by. Best regards -- Dago From dam at opencsw.org Mon Aug 2 13:20:21 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 2 Aug 2010 13:20:21 +0200 Subject: [csw-maintainers] Change of compiler location on OpenCSW buildfarm References: <2BA946A2-9D40-4D96-8767-E96AE482CF14@baltic-online.de> Message-ID: Hi, with the deprecation of Solaris 8 I will change the compiler pathes to a more regular scheme. Especially the Sun Studio 12 compiler will be linked to /opt/SUNWspro and gar.conf.mk will be adjusted to the new location. This allows for more sane pathes in applications that record the path (like Perl and Ruby). I plan to make the change this evening (in about 5 hours). The current locations /opt/studio/SOS12/SUNWspro will stay intact, though. Best regards -- Dago From dam at opencsw.org Mon Aug 2 13:34:03 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 2 Aug 2010 13:34:03 +0200 Subject: [csw-maintainers] Minor incompatibility of mGAR v2 and gmake 3.82, please "svn up" Message-ID: <2B99471E-9D75-4A7F-B3FD-1829DD387E34@opencsw.org> Hi, I just noticed that there is a minor incompatibility of mGAR v2 and gmake 3.82 which I just updated. The issue has been fixed in r10680, please update your GAR accordingly. Best regards -- Dago From bwalton at opencsw.org Mon Aug 2 15:06:36 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 02 Aug 2010 09:06:36 -0400 Subject: [csw-maintainers] Change of compiler location on OpenCSW buildfarm In-Reply-To: References: <2BA946A2-9D40-4D96-8767-E96AE482CF14@baltic-online.de> Message-ID: <1280754341-sup-3833@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Mon Aug 02 07:20:21 -0400 2010: > The current locations /opt/studio/SOS12/SUNWspro will stay intact, > though. This is good or else module building would be broken until a re-roll of the interpreters. I'll try to update ruby to have the 'native' path embedded shortly. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Aug 2 21:48:59 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 02 Aug 2010 15:48:59 -0400 Subject: [csw-maintainers] symlinkages relinkage In-Reply-To: References: Message-ID: <1280778484-sup-3226@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Aug 02 11:52:27 -0400 2010: Hi Phil, > When you first brought up the local symlinks issue, I believe one of > the things you complained about, was that the 'common' symlinks were > not uniform, so you could not just remove the LC_TIME symlinks from > coreutils. > > I have now made the links uniform, so I'm requesting that you follow > through with that alternative plan,and redo coreutils without the > LC_TIME symlinks. And, as the links are still there, CSWcommon is still broken. I'm requesting that you fix this package as per the recommendations of the gettext maintainer. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Tue Aug 3 02:08:46 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 02 Aug 2010 20:08:46 -0400 Subject: [csw-maintainers] arbitration request Message-ID: <1280794089-sup-4517@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Aug 02 19:15:42 -0400 2010: > >There is no value in having this link. Coreutils > > could delete it without loss in functionality even when you > > removed > > your links. > > I dont think there is no loss in functionality. But if you do think > that... then by all means please remove the link from coreutils,and > we'll move on! :) Phil, your fix is broken. Dago and I agree on this as does the maintainer of the software in question. Your "fix" causes more work for all involved and breaks allowed functionality. You've put your ego first and abused your position as the release manager to attempt a sabotage of any solution but the one you've put forward by releasing your "more consistent" version of the package out of step with any agreed upon changes to coreutils. In doing so, you've inconvenienced many users as evidenced by the bug reports about this in the last 2 days. I hereby make a formal request to the OpenCSW board to institute a non-partisan arbitration for this issue. I will accept whatever resolution this group arrives at. [And Phil, your habit of hijacking discussions out of public sight is really annoying...] Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Tue Aug 3 03:20:59 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 2 Aug 2010 18:20:59 -0700 Subject: [csw-maintainers] [board] arbitration request In-Reply-To: <1280794089-sup-4517@pinkfloyd.chass.utoronto.ca> References: <1280794089-sup-4517@pinkfloyd.chass.utoronto.ca> Message-ID: FYI, I have reverted the common package to its prior version for now. It will take a while for it to sync out, as usual. From william at wbonnet.net Thu Aug 5 11:38:01 2010 From: william at wbonnet.net (William Bonnet) Date: Thu, 5 Aug 2010 11:38:01 +0200 Subject: [csw-maintainers] Attendees to Summer Camp Message-ID: Hi, The Summer Camp will be held in Paris in a bit more than a week, and I would like to ask people who will attend to the camp to check please that you put your name on the wiki page ( http://wiki.opencsw.org/summercamp-2010 ). I will have soon to publish the list of people accessing the building during the week end to the local security guys. thanks in advance cheers W. From bonivart at opencsw.org Fri Aug 6 00:49:15 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 6 Aug 2010 00:49:15 +0200 Subject: [csw-maintainers] /testing perl respin Message-ID: I have respun Perl 5.10.1 so it records the new compiler location, I also updated it to use bdb48 instead of bdb47. Otherwise no changes have been made. Since it's a widely used package I would like some feedback so we know for sure it works on different systems. You can find the package here: http://mirror.opencsw.org/experimental.html#bonivart Install it easily with: # pkgutil -t http://mirror.opencsw.org/opencsw/experimental/bonivart -i perl -- /peter From bwalton at opencsw.org Fri Aug 6 04:29:47 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 05 Aug 2010 22:29:47 -0400 Subject: [csw-maintainers] away until Monday Message-ID: <1281061712-sup-4859@pinkfloyd.chass.utoronto.ca> Hi All, I'm away for the weekend, so please be patient with any buildfarm requests as it'll only be Dago to handle them. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Fri Aug 6 09:23:39 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 6 Aug 2010 09:23:39 +0200 Subject: [csw-maintainers] Updating current/ now Message-ID: Hi, I am updating the current-servers to current/, please stand by! Sorry for the inconvenience -- Dago From jeff at cjsa.com Fri Aug 6 21:48:09 2010 From: jeff at cjsa.com (Jeffery Small) Date: Fri, 6 Aug 2010 19:48:09 GMT Subject: [csw-maintainers] Need for additional documentation Message-ID: I have been using a very old, locally compiled version of mutt for the past few years because I could never get the CSW version of mutt to work with my predefined macros and key bindings in my muttrc file, and just didn't have the time to devote to tracking down the problem. However, today I bit the bullet and discovered a great surprise; the CSW mutt binary was a link pointing to another link back in /etc/opt/csw/alternatives which was using a slang-compiled version of mutt! Once I relinked to the ncurses version of mutt, everything worked just fine! The point of my story is that I didn't even have any idea that these alternate versions existed and knew nothing about the "alternatives" directory. I keep running across little tricks like this regarding CSW software packages which would should have been configured at installation time had I known about them. Now, maybe there is some note that displays regarding this during a mutt installation or upgrade, but even if that were so, we all know that none of these messages can be seen during a typical install/upgrade if the automatic configuration parameters are set. Everything just scrolls off the screen much too fast to monitor it. For some packages, there are very important steps that need to be done during an installation or checked after an upgrade and this information needs to be placed in some well known location where every user can review it. When I was compiling packages under the old system, I used to include this information in on the webpage for the packager in the News (I think that was what it was called) section. There really ought to me a "Special Instructions" section added to the current web page which just has this important information, like tweaking configuration files, starting services, selection between alternatives, etc. But I would take this a step further. If these notes were packaged up into a file shipped with each package, then the CSW install program could copy this content to a new temporary file during the installation or upgrade process, along with any error or warning messages that occurred, and then display this information to the user for their review after they were done. This would allow a major install or upgrade to occur unattended, with only a need to review the important information immediately after completion. This would be extremely helpful to people installing new CSW packages, since they would get these pointers on how to properly configure the packages in real time without having to hunt through volumes of documentation for answers to questions that they probably don't even know to ask. I'm not suggesting duplicating a package's documentation here. Just a short file with important tips that the packager knows are important for proper use of the software. In my case, I was using mutt long before the the slang/curses split, and it never occurred to me to think that there was even an issue like this to be investigated. Just some friendly feedback for your consideration! :-) Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From ihsan at opencsw.org Mon Aug 9 20:16:06 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Mon, 09 Aug 2010 20:16:06 +0200 Subject: [csw-maintainers] Updating libfaad2 and mpeg4ip In-Reply-To: References: <1280278827-sup-1945@pinkfloyd.chass.utoronto.ca> Message-ID: <4C6045E6.6080101@opencsw.org> On 7/30/10 2:19 AM, Philip Brown wrote: > xmms is ugly. and somewhat orphaned I heard. and there is xmms2. and... > its messy. so anyone else is hereby cordially invited to take it over :-D But it's still one of the MP3 players for Unix. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From bonivart at opencsw.org Thu Aug 12 10:43:45 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 12 Aug 2010 10:43:45 +0200 Subject: [csw-maintainers] Result from ping to maintainers Message-ID: I sent pings 2010-03-29 and forgot about it until Dago posted to one of the guys on my ping list today. So here comes the results. These responded in a timely fashion. - car, responded 2010-03-21, retired - opk, responded 2010-03-24, active - mjensen, responded 2010-03-29, active (ok to take over packages) - angelo, responded 2010-03-29, active - mph, responded 2010-03-29, retired - mmayer, responded 2010-03-31, active - mike, responded 2010-04-04, retired - darin, responded (to a mail from Dago) 2010-04-12, active - rmartin, not known any longer by EDS mail server (probably quit EDS), retired These never replied and after all this time, with bugs open and all, I think they should be listed as retired and their packages free for takeover. Maybe there are some exceptions, I don't know. - ja - mburki - sdean - debertin - drio - michael - harpchad - korpela - dlaigle - aubrey - mueller - wpool - joerg - ryan - fred -- /peter From dam at opencsw.org Thu Aug 12 11:12:06 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 12 Aug 2010 11:12:06 +0200 Subject: [csw-maintainers] Need for additional documentation In-Reply-To: References: Message-ID: Hi Jeffery, Am 06.08.2010 um 21:48 schrieb Jeffery Small: > I have been using a very old, locally compiled version of mutt for > the past > few years because I could never get the CSW version of mutt to work > with > my predefined macros and key bindings in my muttrc file, and just > didn't > have the time to devote to tracking down the problem. However, > today I bit > the bullet and discovered a great surprise; the CSW mutt binary was > a link > pointing to another link back in /etc/opt/csw/alternatives which was > using > a slang-compiled version of mutt! Once I relinked to the ncurses > version > of mutt, everything worked just fine! > > The point of my story is that I didn't even have any idea that these > alternate versions existed and knew nothing about the "alternatives" > directory. I keep running across little tricks like this regarding > CSW > software packages which would should have been configured at > installation > time had I known about them. Now, maybe there is some note that > displays > regarding this during a mutt installation or upgrade, In fact there is after package installation :-) > but even if that > were so, we all know that none of these messages can be seen during a > typical install/upgrade if the automatic configuration parameters > are set. > Everything just scrolls off the screen much too fast to monitor it. True. > For some packages, there are very important steps that need to be done > during an installation or checked after an upgrade and this > information > needs to be placed in some well known location where every user can > review > it. When I was compiling packages under the old system, I used to > include > this information in on the webpage for the packager in the News (I > think > that was what it was called) section. There really ought to me a > "Special > Instructions" section added to the current web page which just has > this > important information, like tweaking configuration files, starting > services, > selection between alternatives, etc. > > But I would take this a step further. If these notes were packaged > up into > a file shipped with each package, then the CSW install program could > copy > this content to a new temporary file during the installation or > upgrade > process, along with any error or warning messages that occurred, and > then > display this information to the user for their review after they were > done. This would allow a major install or upgrade to occur > unattended, > with only a need to review the important information immediately after > completion. This would be extremely helpful to people installing new > CSW packages, since they would get these pointers on how to properly > configure the packages in real time without having to hunt through > volumes > of documentation for answers to questions that they probably don't > even > know to ask. > > I'm not suggesting duplicating a package's documentation here. Just a > short file with important tips that the packager knows are important > for > proper use of the software. In my case, I was using mutt long > before the > the slang/curses split, and it never occurred to me to think that > there was > even an issue like this to be investigated. > > Just some friendly feedback for your consideration! :-) There is obviously some lack of visibility here as you noted correctly. Some notes: 1. Some maintainer already maintain a Changelog per package. The standard location is /opt/csw/share/doc//Changelog 2. There may be some standard on the format of the Changelog, but it may be difficult to extract specific information 3. It would be nice if checkpkg could somehow verify that the Changelog is there and has been updated after the previous package release 4. The changes should be printed on package update and/or stored in an update-log. Regarding 3: checkpkg could verify the existence of Changelog and see that the Changelog provided by the new package only has information prepended. Regarding 4: On package upgrade there could be a hook for pkgutil making a diff of the existing Changelog and the Changelog of the package to be installed and either print the diff or store it in a "system upgrade log" for this upgrade operation. Additionally, on GAR package creation there could be an automatic addition to the Changelog shipped in the package that a packagerelease occured with the timestamp of the package. However, this information must then go back to the repository. On package rejection on release this would lead to superflous release tags in the Changelog. It would be ideal if rejection of a specific package release would also be noted in the Changelog. However, that would require a much more integrated release process making use of CSWREPO inside the package to fix the files/Changelog of the exact package description. But I see no reason why we can't start with 1-4 right now. Best regards -- Dago From dam at opencsw.org Thu Aug 12 11:20:49 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 12 Aug 2010 11:20:49 +0200 Subject: [csw-maintainers] Result from ping to maintainers In-Reply-To: References: Message-ID: <7C272D2C-70FC-46F9-8C6A-1A58AD566BFF@opencsw.org> Hi Peter, Am 12.08.2010 um 10:43 schrieb Peter Bonivart: > I sent pings 2010-03-29 and forgot about it until Dago posted to one > of the guys on my ping list today. So here comes the results. > > These responded in a timely fashion. > > - car, responded 2010-03-21, retired > - opk, responded 2010-03-24, active > - mjensen, responded 2010-03-29, active (ok to take over packages) > - angelo, responded 2010-03-29, active > - mph, responded 2010-03-29, retired > - mmayer, responded 2010-03-31, active > - mike, responded 2010-04-04, retired > - darin, responded (to a mail from Dago) 2010-04-12, active > - rmartin, not known any longer by EDS mail server (probably quit > EDS), retired > > These never replied and after all this time, with bugs open and all, I > think they should be listed as retired and their packages free for > takeover. Maybe there are some exceptions, I don't know. > > - ja J?rgen is also active, despite the fact that he seems to be quite busy at his new workplace. > - mburki > - sdean > - debertin > - drio > - michael > - harpchad > - korpela > - dlaigle Dominique will be at Paris, so he is definitely not retired. > - aubrey > - mueller > - wpool > - joerg > - ryan > - fred I had replied when you last posted this, but it looks like my feedback hasn't found a way into your list :-) I just add my previous reply for update. Best regards -- Dago Am 19.03.2010 um 11:49 schrieb Dagobert Michelsen: > Am 19.03.2010 um 10:53 schrieb Peter Bonivart: >> http://www.opencsw.org/buglist/maintainer.cgi?maintainer=ja > > J?rgen changed the employer and is probably busy at the moment > but told me he is going to continue to work on his packages. > He is a member of the association since 2009-03-27. Maybe > he needs some encouragement :) > >> http://www.opencsw.org/buglist/maintainer.cgi?maintainer=mike > > Mike responds to emails, but hasn't updated stuff in a long while > now, even after ping. > >> http://www.opencsw.org/buglist/maintainer.cgi?maintainer=mburki > > I guess Manuel can safely be considered retrred. > >> http://www.opencsw.org/buglist/maintainer.cgi?maintainer=sdean > > Same. > >> http://www.opencsw.org/buglist/maintainer.cgi?maintainer=debertin > > Last contact with me was in February 2010 when he wanted to > update libsigsegv. > >> http://www.opencsw.org/buglist/maintainer.cgi?maintainer=drio > > Last email was from October 2009 when he said he wanted to update > his packages. Maybe he is busy with other things. > >> http://www.opencsw.org/buglist/maintainer.cgi?maintainer=michael > > Michael is more on sabbatical. He operates the OpenCSW master mirror > at > the University of Erlangen and responds to emails. I guess his > packages > are all safe for takeover. He is a member of the association since > 2008-12-18. > >> http://www.opencsw.org/buglist/maintainer.cgi?maintainer=harpchad > > Chad has lots of other things at the moment, but will jump back in > when he has the opportunity to do so. Currently ping fails. I want > to update his packages CSWglib2 and CSWgnutls. He is a member of > the association since 2009-01-06. > >> http://www.opencsw.org/buglist/maintainer.cgi?maintainer=mph > > I guess it is safe to mark Michael retired. No email for years. > >> http://www.opencsw.org/buglist/maintainer.cgi?maintainer=opk > > Oliver is active. He just hasn't updated his package. A simple ping > will be sufficient here. He is a member of the association since > 2009-01-01. > >> http://www.opencsw.org/buglist/maintainer.cgi?maintainer=korpela > > Last email was from November 2009 when he waited on the release of > wxwidgets. Maybe a ping will suffice. He is a member of the > association since 2009-02-13. > >> http://www.opencsw.org/buglist/maintainer.cgi?maintainer=dlaigle > > Dominique visited the camps in Zurick and Oslo and I met him once > more for work on Kerberos. I have the feeling he is busy with > other things right now, but has worked some ugly things for OpenCSW > in the past. Maybe a ping would be good. He is a founding member > of the association. > >> http://www.opencsw.org/buglist/maintainer.cgi?maintainer=aubrey > > Aubrey last mailed on November 2009 and got some problems with his > update. Maybe a ping will suffice. > >> http://www.opencsw.org/buglist/maintainer.cgi?maintainer=rmartin > > No email for years, IMHO safe for takeover (CSWrssh). > >> http://www.opencsw.org/buglist/maintainer.cgi?maintainer=mmayer > > Last contact was November 2008. Multiple pings since then without > result. > >> http://www.opencsw.org/buglist/maintainer.cgi?maintainer=mueller > > No email for years, IMHO safe for takeover. > >> http://www.opencsw.org/buglist/maintainer.cgi?maintainer=darin > > Last email from November 2009, maybe just needs a ping. > >> http://www.opencsw.org/buglist/maintainer.cgi?maintainer=wpool > > No email for years, IMHO safe for takeover (CSWjboss3, CSWjboss4). > >> http://www.opencsw.org/buglist/maintainer.cgi?maintainer=angelo > > No sign of life since the fork, IMHO safe for takeover (CSWclex). > >> http://www.opencsw.org/buglist/maintainer.cgi?maintainer=car > > Last email from September 2009, Chris Reece is a member of the > association > as of 2008-12-18. > >> http://www.opencsw.org/buglist/maintainer.cgi?maintainer=joerg > > Joerg is active, I just met him a couple of weeks ago and OpenCSW will > also receive updated cdrtools. He maybe just too lenient to close > the bugs and probably only needs a ping. > >> http://www.opencsw.org/buglist/maintainer.cgi?maintainer=ryan > > No sign of life since the fork, IMHO safe for takeover (CSWapg, > CSWeruby). > >> http://www.opencsw.org/buglist/maintainer.cgi?maintainer=fred > > Last email from December 2008, initially joined the project, > pingtest failed multiple times, so IMHO safe for takover (I already > updated his giflib) (CSWgifsicle, CSWgocr, CSWlogrotate, CSWocrad, > multiple Perl modules (!), CSWproftpd, CSWrazor) From bonivart at opencsw.org Thu Aug 12 11:22:53 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 12 Aug 2010 11:22:53 +0200 Subject: [csw-maintainers] Need for additional documentation In-Reply-To: References: Message-ID: On Fri, Aug 6, 2010 at 9:48 PM, Jeffery Small wrote: > When I was compiling packages under the old system, I used to include > this information in on the webpage for the packager in the News (I think > that was what it was called) section. ?There really ought to me a "Special > Instructions" section added to the current web page which just has this > important information, like tweaking configuration files, starting services, > selection between alternatives, etc. I agree, the package browser should include this. If I remember correctly this was actually done in Mantis and then linked from the package browser. We don't have that now on the new web site but it was broken ever since the split even on the old web site. That's one of the reasons I started the wiki. Feel free to make notes there if you wish. http://wiki.opencsw.org/packages -- /peter From maciej at opencsw.org Thu Aug 12 12:12:53 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 12 Aug 2010 11:12:53 +0100 Subject: [csw-maintainers] Need for additional documentation In-Reply-To: References: Message-ID: No dia 12 de Agosto de 2010 10:12, Dagobert Michelsen escreveu: > There is obviously some lack of visibility here as you noted correctly. > > Some notes: > 1. Some maintainer already maintain a Changelog per package. The standard > location is > ? ?/opt/csw/share/doc//Changelog I don't know how wide the adoption is though. I've seen Sebastian updating the change log, but > 2. There may be some standard on the format of the Changelog, but it may be > ? difficult to extract specific information I think Debian has some tools for it. > 3. It would be nice if checkpkg could somehow verify that the Changelog is > there > ? and has been updated after the previous package release This can be arranged. > 4. The changes should be printed on package update and/or stored in an > update-log. > (...) > Regarding 4: On package upgrade there could be a hook for pkgutil making a > diff > of the existing Changelog and the Changelog of the package to be installed > and > either print the diff or store it in a "system upgrade log" for this upgrade > operation. I like this idea. Gentoo displays messages after every emerge run, for example: * IMPORTANT: 1 news items need reading for repository 'gentoo'. * Use eselect news to read news items. When you type "eselect news", it considers the news read and stops displaying this message. We could have something similar: at the end of every run, the package tool would check if all the news have been read and display a notification if necessary. From maciej at opencsw.org Thu Aug 12 16:25:16 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 12 Aug 2010 15:25:16 +0100 Subject: [csw-maintainers] Building MySQL 5.1.x In-Reply-To: <6af4270912270759n100696e2r45e2d5fd940814ed@mail.gmail.com> References: <48E837C1-8FC2-41D0-9379-6BEABF129BD4@opencsw.org> <6af4270912270759n100696e2r45e2d5fd940814ed@mail.gmail.com> Message-ID: With help from Derek (aka des on IRC), I'm putting up mysql-5.1 for testing. I have two questions about mysql-5.1. 1. The mysql user is used by both mysql-5.0 and mysql-5.1 packages. Its home directory is /var/opt/csw/mysql5 in one package and /var/opt/csw/mysql51 in the other. I guess that the final home directory of this user depends on which package gets installed first: 5.0 or 5.1. Do you have any suggestions for a better (unified) home directory for this user? 2. Compilation fails on sparc: "../include/my_global.h", line 1046: #error: sizeof(void *) is neither sizeof(int) nor sizeof(long) nor sizeof(long long) cc: acomp failed for strxmov.c Is this a known problem with a known fix or workaround? Maciej From phil at bolthole.com Thu Aug 12 18:58:57 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 12 Aug 2010 09:58:57 -0700 Subject: [csw-maintainers] Need for additional documentation In-Reply-To: References: Message-ID: On 8/12/10, Dagobert Michelsen wrote: > .... > 3. It would be nice if checkpkg could somehow verify that the > Changelog is there > and has been updated after the previous package release > You are suggesting that every package have a changelog from now on. However, if that were the case, that would accomplish the opposite of what the original poster was asking for: something to bring attention to IMPORTANT things, while ignoring the usual scrolling blah. If you have every package display a changelog, that just adds to "even more scrolling blah" to ignore, and does not solve the original issue. From maciej at opencsw.org Thu Aug 12 19:07:09 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 12 Aug 2010 18:07:09 +0100 Subject: [csw-maintainers] Need for additional documentation In-Reply-To: References: Message-ID: No dia 12 de Agosto de 2010 17:58, Philip Brown escreveu: > You are suggesting that every package have a changelog from now on. > However, if that were the case, that would accomplish the opposite of > what the original poster was asking for: something to bring attention > to IMPORTANT things, while ignoring the usual scrolling blah. > > If you have every package display a changelog, that just adds to "even > more scrolling blah" to ignore, and does not solve the original issue. True. There needs to be the distinction between the changelog which has the "for the record" flavor, and important messages which are of the "you need to read it or you will end up pulling your hair" kind. Implementation would have certain level of complexity: a central place to hold all the messages and hold their read/unread state. Preferably, with not much dependencies, which probably points us at perl. From phil at bolthole.com Thu Aug 12 19:51:34 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 12 Aug 2010 10:51:34 -0700 Subject: [csw-maintainers] Building MySQL 5.1.x In-Reply-To: References: <48E837C1-8FC2-41D0-9379-6BEABF129BD4@opencsw.org> <6af4270912270759n100696e2r45e2d5fd940814ed@mail.gmail.com> Message-ID: On 8/12/10, Maciej (Matchek) Blizinski wrote: > > > 2. Compilation fails on sparc: > > "../include/my_global.h", line 1046: #error: sizeof(void *) is neither > sizeof(int) nor sizeof(long) nor sizeof(long long) > cc: acomp failed for strxmov.c > > Is this a known problem with a known fix or workaround? > well thats surprising. its really just looking for "size of address pointer". So replace with the appropriate typedef, and possibly disable that whole clause. and/or its trying to determine "is this 32bit or 64bit machine". erm.. sigh.. goes to look at code. nope, its like I said the first time. /*blahblahblah*/ typedef int intptr; You may note that there are hardcoded definitions for sections such as #if defined(__APPLE__) && defined(__MACH__) It's whining about SIZEOF_CHARP when in doubt, compare to older versions. The older 5.0.90 has a much simpler, saner approach: #if SIZEOF_CHARP == 4 typedef long my_ptrdiff_t; #else typedef long long my_ptrdiff_t; #endif although REALLY, it should be #if SIZEOF_CHARP == 4 typedef uint32_t my_ptrdiff_t; #else typedef uint64_t my_ptrdiff_t; #endif getting even more fancy, since there are already checks for #ifdef HAVE_SYS_TYPES_H then I think it may be save to have #ifdef HAVE_SYS_TYPES_H # if SIZEOF_CHARP == 4 typedef uint32_t my_ptrdiff_t; # else typedef uint64_t my_ptrdiff_t; # endif #else /* Original dumb #if SIZEOF_CHARP == SIZEOF_INT code here */ #endif HOWEVER, all that being said... the following code works fine in solaris: printf("size of pointer is %d\n", sizeof(void*)); (result: "size of pointer is 4") so, given that SIZEOF_CHARP seems to be getting calculated wrong... maybe you need to figure out why that is, and fix it, first. for what it's worth, I also tried printf("size of charp is %d\n", sizeof(char*)); and that also came out to be 4. From phil at bolthole.com Thu Aug 12 22:45:49 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 12 Aug 2010 13:45:49 -0700 Subject: [csw-maintainers] Need for additional documentation In-Reply-To: References: Message-ID: On 8/12/10, Maciej (Matchek) Blizinski wrote: > > True. There needs to be the distinction between the changelog which > has the "for the record" flavor, and important messages which are of > the "you need to read it or you will end up pulling your hair" kind. > > Implementation would have certain level of complexity: a central place > to hold all the messages and hold their read/unread state. > Preferably, with not much dependencies, which probably points us at > perl. > Pffft. the task of DISPLAYING [whatever] is trivial. The tough part, is determining the policy, and location :) The policy is going to be the tricky part. For example, I can think of at least 3^H4 separate contexts where a packager might choose to display "something" to the user: a) Something Really Important about this specific release! b) Something good to know about this package in general c) "If you are upgrading from version xyz or previous, you need to do..." d) General csw "changelog" tedium, for really bored people who dont have enough to read :) and there's probably more :-/ But please note: in my opinion, an "upstream" software changelog, never belongs here. Only specific "here's a change that will break things for you" warnings. Oh I suppose if there are maintainers who reaaaally want to call that stuff out, we can make a facility for that sort of thing. But I for one, want a "i NEVER want to see that junk" option for it ;-) From bonivart at opencsw.org Thu Aug 12 23:21:15 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 12 Aug 2010 23:21:15 +0200 Subject: [csw-maintainers] Need for additional documentation In-Reply-To: References: Message-ID: Isn't it wrong to put vital information in the package itself? I mean, if there's critical information that the admin needs to read, he should read it _before_ he installs the package so he knows what will happen and what needs to be done. Or are we assuming that everyone will test this on a separate system first? We all know that is not the case and if we assume that we can just use the postmsg class utility to display a files content after each package install since everyone _should_ read everything on the screen. I think this kind of info is better to have separated from the actual package. It's fine to have it included in the package and even displayed during install but it's more important to make it available online. That's also what Jeffery asked for. Now we're trying to make some complicated mechanism instead because that's what we like to do. The obvious and easy way to do this is to write a note on the wiki. -- /peter From phil at bolthole.com Thu Aug 12 23:58:28 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 12 Aug 2010 14:58:28 -0700 Subject: [csw-maintainers] Need for additional documentation In-Reply-To: References: Message-ID: On 8/12/10, Peter Bonivart wrote: > > I think this kind of info is better to have separated from the actual > package. It's fine to have it included in the package and even > displayed during install but it's more important to make it available > online. > > That's also what Jeffery asked for. Now we're trying to make some > complicated mechanism instead because that's what we like to do. The > obvious and easy way to do this is to write a note on the wiki. > Hmm. I didnt see where Jeffery asked for the external note. I read that he commented how that's how he USED to do things in his own packages: put notes in the "news" section of mantis. (unfortunately, I think the link from our "packages" page to the mantis news page for that package, no longer exists) but seemed like he was explicitly asking for an "at install time" nag, not the external thing. From dam at opencsw.org Fri Aug 13 17:24:50 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 13 Aug 2010 17:24:50 +0200 Subject: [csw-maintainers] Fwd: [bug-notifications] [php5 0004520]: mbregex missing from PHP References: Message-ID: Hi Oliver, Anfang der weitergeleiteten E-Mail: > Summary: mbregex missing from PHP > Description: > I'm attempting to migrate an application from blastwave stable to > recent > opencsw and I get the following message: > PHP Fatal error: Call to undefined function mb_ereg_replace > > This can be reproduced easily with: > echo '' | > /opt/csw/php5/bin/php > > According to phpinfo(), php5 was compiled with --enable- > mbregex=shared yet > I can't find any shared library corresponding to mbregex. Has it > perhaps > been forgotten in the packaging. I do have mbstring and it is > enabled in > the configuration file. On the old installation, phpinfo() reports a > bare > --enable-mbregex. Unfortunately PHP is unmaintained at the moment. However, we have some maintainers here who would be willing to help on redoing this when someone takes the stake :-) Best regards -- Dago From jeff at cjsa.com Fri Aug 13 21:28:56 2010 From: jeff at cjsa.com (Jeffery Small) Date: Fri, 13 Aug 2010 19:28:56 GMT Subject: [csw-maintainers] Sendmail Message-ID: I have a question regarding the CSWsendmail package installed and running on my Solaris 10 SPARC system. When I reboot, I see a new message that indicates that a process cannot write to /opt/csw/var/spool/clientmqueue/sm-client.pid which is in use by another process. When I check the processes running I see that in addition to the standard sendmail process: root 690 sendmail: accepting connections there are two queue runners: smmsp 614 sendmail: Queue runner at 00:15:00 for /var/spool/clientmqueue smmsp 680 sendmail: Queue runner at 00:15:00 for /opt/csw/var/spool/clientmqueue The first one (614) writes to sm-client.pid and the second one cannot. Now, /var/spool/clientmqueue (and mqueue) are symlinks pointing to /opt/csw/var/spool/clientmqueue (and /opt/csw/var/spool/mqueue), so there is no need for the second process 680, and I'm concerned that running these two processes could actually cause problems. When I check the services running, I see the following relating to sendmail: online 10:39:23 svc:/network/sendmail-client:default online 10:39:24 svc:/network/smtp:cswsendmail Alex Moore, the old sendmail maintainer is retired. Is anyone else managing this package or do you have any insights as to whether this situation represents a potential problem, and if so, where things got off track? Beyond noticing the above, the mail system seems to be working OK. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From phil at bolthole.com Sat Aug 14 01:24:34 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 13 Aug 2010 16:24:34 -0700 Subject: [csw-maintainers] Sendmail In-Reply-To: References: Message-ID: is the second one the sun one? On Friday, August 13, 2010, Jeffery Small wrote: > I have a question regarding the CSWsendmail package installed and running > on my Solaris 10 SPARC system. > > When I reboot, I see a new message that indicates that a process cannot > write to /opt/csw/var/spool/clientmqueue/sm-client.pid which is in use > by another process. ?When I check the processes running I see that in > addition to the standard sendmail process: > > ?root ?690 sendmail: accepting connections > > there are two queue runners: > > ?smmsp 614 sendmail: Queue runner at 00:15:00 for /var/spool/clientmqueue > ?smmsp 680 sendmail: Queue runner at 00:15:00 for /opt/csw/var/spool/clientmqueue > > The first one (614) writes to sm-client.pid and the second one cannot. > Now, /var/spool/clientmqueue (and mqueue) are symlinks pointing to > /opt/csw/var/spool/clientmqueue (and /opt/csw/var/spool/mqueue), so there > is no need for the second process 680, and I'm concerned that running these > two processes could actually cause problems. > > When I check the services running, I see the following relating to sendmail: > > ?online ? ? ? ? 10:39:23 svc:/network/sendmail-client:default > ?online ? ? ? ? 10:39:24 svc:/network/smtp:cswsendmail > > Alex Moore, the old sendmail maintainer is retired. ?Is anyone else > managing this package or do you have any insights as to whether this > situation represents a potential problem, and if so, where things got off > track? ?Beyond noticing the above, the mail system seems to be working OK. > > Regards, > -- > Jeff > > C. Jeffery Small ? ? ? ? ? CJSA LLC ? ? ? ? ? ? ? ? ? ? ? 206-232-3338 > jeff at cjsa.com ? ? ? ? ? ? ?7000 E Mercer Way, Mercer Island, WA ?98040 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From jeff at cjsa.com Sat Aug 14 08:47:32 2010 From: jeff at cjsa.com (Jeffery Small) Date: Sat, 14 Aug 2010 06:47:32 GMT Subject: [csw-maintainers] Sendmail References: Message-ID: Philip Brown writes: >is the second [instance of sendmail queue runner] the sun one? Phil: You are correct. The sun version of sendmail has been disabled for quite some time here since I started using the CSW package, but somehow it got re-enabled. There is a /etc/init.d/sendmail script which enables the network/smtp:sendmail and network/sendmail-client:default services. However, there is no link to this file in any of the /etc/rc*.d directoreies, so I am at a loss to understand how this was run. I ran /etc/init.d/sendmail stop and disabled the rogue services and now I have the standard single sendmail and queue runner processes with the single svc:/network/smtp:cswsendmail service enabled. I know there is some logical explanation for what actually happened, but sometimes it seems like a ghost is manipulating the system! :-) Maybe something happens during a Sun patch operation where the installed sendmail package is updated and the patch script restarts the services even though they are disabled. That's the only explanation I can think of. I'll watch more closely on the next reboot to see what happens. Thanks for being a sanity check on my thinking. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From skayser at opencsw.org Sat Aug 14 11:10:24 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Sat, 14 Aug 2010 11:10:24 +0200 Subject: [csw-maintainers] SummerCamp @ Paris: broadcasting on ustream.tv Message-ID: <4C665D80.9010209@opencsw.org> Hi fellow maintainers, Dago set up a live broadcast from the summer camp in Paris where everyone can tune in and attend remotely. http://www.ustream.tv/channel/opencswsummercamp-2010 They are on GMT+2. Broadcasting times may vary. Just tune in on the above URL and you will find out. Maybe someone of the attendees can simply ping the list when they go on-/offline. Sebastian From william at wbonnet.net Sat Aug 14 16:04:12 2010 From: william at wbonnet.net (William Bonnet) Date: Sat, 14 Aug 2010 16:04:12 +0200 Subject: [csw-maintainers] gar suggestion In-Reply-To: <1277770549-sup-3354@pinkfloyd.chass.utoronto.ca> References: <1277508911-sup-531@pinkfloyd.chass.utoronto.ca> <1277510745-sup-838@pinkfloyd.chass.utoronto.ca> <4C26505A.4060109@opencsw.org> <1277770549-sup-3354@pinkfloyd.chass.utoronto.ca> Message-ID: <9885B1C9-572D-4AE6-B3A2-49431A0F8E9F@wbonnet.net> Hi > Sebastian and I discussed this too but I decided against it. Here's > the reason: If you don't do the initial git snapshots at extract and > then patch time, you don't have a repo to work from. Would it be a good idea and possible to deactivate this featre from the .garrc file ? cheers W. From bwalton at opencsw.org Sat Aug 14 18:06:55 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 14 Aug 2010 12:06:55 -0400 Subject: [csw-maintainers] gar suggestion In-Reply-To: <9885B1C9-572D-4AE6-B3A2-49431A0F8E9F@wbonnet.net> References: <1277508911-sup-531@pinkfloyd.chass.utoronto.ca> <1277510745-sup-838@pinkfloyd.chass.utoronto.ca> <4C26505A.4060109@opencsw.org> <1277770549-sup-3354@pinkfloyd.chass.utoronto.ca> <9885B1C9-572D-4AE6-B3A2-49431A0F8E9F@wbonnet.net> Message-ID: <1281801855-sup-4518@pinkfloyd.chass.utoronto.ca> Excerpts from William Bonnet's message of Sat Aug 14 10:04:12 -0400 2010: Hi William, > > Sebastian and I discussed this too but I decided against it. > > Here's the reason: If you don't do the initial git snapshots at > > extract and then patch time, you don't have a repo to work from. > > Would it be a good idea and possible to deactivate this featre from > the .garrc file ? It's possible, but it's an all or nothing switch then. If you turn it off and then decide you want to make a patch, you need to redo the extract and patch steps to have the .git repo created and previous patches tracked. I'll implement this if desired, but support for it hasn't been there yet. What packages would you find this most useful in conjunction with? Are you paying the extract+patch price frequently (eg: lots of gmake spotless, etc)? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Aug 14 19:00:55 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 14 Aug 2010 13:00:55 -0400 Subject: [csw-maintainers] straw poll on git-patching Message-ID: <1281805187-sup-4641@pinkfloyd.chass.utoronto.ca> Ok, since the issue was re-raised, lets do a quick informal poll (GAR users only, please). Two questions: Would you like the option to turn off the git-patch support in GAR If yes, what do you feel the default should be. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From skayser at opencsw.org Sat Aug 14 19:10:56 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Sat, 14 Aug 2010 19:10:56 +0200 Subject: [csw-maintainers] SummerCamp @ Paris: broadcasting on ustream.tv In-Reply-To: <4C665D80.9010209@opencsw.org> References: <4C665D80.9010209@opencsw.org> Message-ID: <4C66CE20.7050506@opencsw.org> Sebastian Kayser wrote on 14.08.2010 11:10: > Dago set up a live broadcast from the summer camp in Paris where > everyone can tune in and attend remotely. > > http://www.ustream.tv/channel/opencswsummercamp-2010 > > They are on GMT+2. Broadcasting times may vary. Just tune in on the > above URL and you will find out. Maybe someone of the attendees can > simply ping the list when they go on-/offline. Broadcast is offline for today, will go online at approx 9.30am GMT+2 tomorrow again. There's also a Google Wave [1] with today's discussion minutes, which will be continued tomorrow. Enjoy! Thanks to Dago & Maciej for taking care of the broadcast and the minutes! Sebastian [1] http://bit.ly/bABhxG From dam at opencsw.org Sat Aug 14 20:21:50 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 14 Aug 2010 20:21:50 +0200 Subject: [csw-maintainers] straw poll on git-patching In-Reply-To: <1281805187-sup-4641@pinkfloyd.chass.utoronto.ca> References: <1281805187-sup-4641@pinkfloyd.chass.utoronto.ca> Message-ID: Hi Ben, Am 14.08.2010 um 19:00 schrieb Ben Walton: > Ok, since the issue was re-raised, lets do a quick informal poll (GAR > users only, please). > > Two questions: > > Would you like the option to turn off the git-patch support in GAR No, it's not worth the effort compared to the minimal gain. Best regards -- Dago From bonivart at opencsw.org Sat Aug 14 20:24:38 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Sat, 14 Aug 2010 20:24:38 +0200 Subject: [csw-maintainers] straw poll on git-patching In-Reply-To: <1281805187-sup-4641@pinkfloyd.chass.utoronto.ca> References: <1281805187-sup-4641@pinkfloyd.chass.utoronto.ca> Message-ID: On Sat, Aug 14, 2010 at 7:00 PM, Ben Walton wrote: > > Ok, since the issue was re-raised, lets do a quick informal poll (GAR > users only, please). > > Two questions: > > Would you like the option to turn off the git-patch support in GAR > If yes, what do you feel the default should be. I'm OK with it as it is. -- /peter From bwalton at opencsw.org Sun Aug 15 01:57:13 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 14 Aug 2010 19:57:13 -0400 Subject: [csw-maintainers] away all week Message-ID: <1281830161-sup-5231@pinkfloyd.chass.utoronto.ca> Hi All, Please be patient with any buildfarm requests this coming week. I'll be gone from early Monday morning until late next Sunday. If the weather is nice here tomorrow, I'll be leaving early on Sunday for a pre-vacation vacation. :) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From william at wbonnet.net Sun Aug 15 09:54:22 2010 From: william at wbonnet.net (William Bonnet) Date: Sun, 15 Aug 2010 09:54:22 +0200 Subject: [csw-maintainers] gar suggestion In-Reply-To: <1281801855-sup-4518@pinkfloyd.chass.utoronto.ca> References: <1277508911-sup-531@pinkfloyd.chass.utoronto.ca> <1277510745-sup-838@pinkfloyd.chass.utoronto.ca> <4C26505A.4060109@opencsw.org> <1277770549-sup-3354@pinkfloyd.chass.utoronto.ca> <9885B1C9-572D-4AE6-B3A2-49431A0F8E9F@wbonnet.net> <1281801855-sup-4518@pinkfloyd.chass.utoronto.ca> Message-ID: <8DAB0675-490D-4834-8646-EBA9F6141FC8@wbonnet.net> Hi > It's possible, but it's an all or nothing switch then. If you turn it > off and then decide you want to make a patch, you need to redo the > extract and patch steps to have the .git repo created and previous > patches tracked. That's what i was thinking of. It may allow to competly deactivate the git stuff for peple not willing to use it > Are you paying the extract+patch price frequently (eg: lots of > gmake spotless, etc)? To be honest i did not spend much time playing with gar over the last weeks :) So i have no god examples. In case of problem, I'll give you a feedback in the next days. I'm finally having some holidays :) cheers W. From maciej at opencsw.org Mon Aug 16 10:12:28 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 16 Aug 2010 09:12:28 +0100 Subject: [csw-maintainers] Preliminary package reviews Message-ID: It's quite common that one of maintainers sends e-mail to the mailing list asking others to review / test a package, but gets no feedback. I've got an idea that for preliminary reviews, a HTML or a text view of a package could be useful. It would show things like pkginfo and pkgmap, with the intention of reviewing the way one software project is split into subpackages, where and what are the binaries, etc. The idea is that it's much quicker to click a link and view a page than dissect a file in a terminal session. Some maintainers wouldn't have time to dissect packages by hand, but they could quickly review a HTML report and offer feedback. I've prepared a prototype view: http://bender.opencsw.org/~maciej/pkg-review-prototype.html Thoughts? Maciej From dam at opencsw.org Mon Aug 16 10:47:55 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 16 Aug 2010 10:47:55 +0200 Subject: [csw-maintainers] Preliminary package reviews In-Reply-To: References: Message-ID: <5F603545-B14D-4FC1-8D71-96944E4FB3A9@opencsw.org> Hi Maciej, Am 16.08.2010 um 10:12 schrieb Maciej (Matchek) Blizinski: > It's quite common that one of maintainers sends e-mail to the mailing > list asking others to review / test a package, but gets no feedback. > I've got an idea that for preliminary reviews, a HTML or a text view > of a package could be useful. It would show things like pkginfo and > pkgmap, with the intention of reviewing the way one software project > is split into subpackages, where and what are the binaries, etc. The > idea is that it's much quicker to click a link and view a page than > dissect a file in a terminal session. Some maintainers wouldn't have > time to dissect packages by hand, but they could quickly review a HTML > report and offer feedback. > > I've prepared a prototype view: > > http://bender.opencsw.org/~maciej/pkg-review-prototype.html > > Thoughts? This looks very useful. I'll prepare support for ~/public_html on the buildfarm to be accessed by http://buildfarm.opencsw.org/~ Some thoughts: - it would be nice if the package would be unpacked to the directory in addition to generating the html with the files in the package be linked from the package for direct browser inspection - it would be nice if the repository link from the pkginfo OPENCSW_REPOSITORY: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/mysql5/branches/mysql-5.1.x at 10727 would be a link also to directly jump to the GAR manifest - if this goes into production I would like to add this as automatic dissect when someone throws a package in experimental/ and the pages would be linked from the package list at experimental.html - why do you print "isalist"? This seems to be machine-local. This should better be taken once and hardcoded to allow dissecting any package on any platform. - I find the binaries_dump_info hard to check. Maybe a table is more intuitive with | runpath | sonames | /opt/csw... | .../64 | libz.so.1 | ... -------+-------------+--------+-----------+---- mysql | 1 | 2 | X | resolve| 1 | 2 | | X where the number would be the order. Just an idea, I don't have a feeling on how good it would be to grasp by a single view on the page. Best regards -- Dago From pfelecan at opencsw.org Mon Aug 16 10:48:10 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 16 Aug 2010 10:48:10 +0200 Subject: [csw-maintainers] Preliminary package reviews In-Reply-To: (Maciej Blizinski's message of "Mon, 16 Aug 2010 09:12:28 +0100") References: Message-ID: "Maciej (Matchek) Blizinski" writes: > It's quite common that one of maintainers sends e-mail to the mailing > list asking others to review / test a package, but gets no feedback. > I've got an idea that for preliminary reviews, a HTML or a text view > of a package could be useful. It would show things like pkginfo and > pkgmap, with the intention of reviewing the way one software project > is split into subpackages, where and what are the binaries, etc. The > idea is that it's much quicker to click a link and view a page than > dissect a file in a terminal session. Some maintainers wouldn't have > time to dissect packages by hand, but they could quickly review a HTML > report and offer feedback. > > I've prepared a prototype view: > > http://bender.opencsw.org/~maciej/pkg-review-prototype.html > > Thoughts? As said during the discussion of the subject at the summer camp, this could enhance the peer review of the packages when a maintainers submits voluntarily to QA. I have 2 suggestions: 1. get rid of the pytonish data representation in the output and choose a text formatting one (the reader is a human, not a machine), e.g.: binaries_dump_info * opt/csw/mysql51/bin/amd64/innochecksum o runpath: /opt/csw/lib/$ISALIST /opt/csw/lib/64 /opt/csw/mysql51/lib/$ISALIST /opt/csw/mysql51/lib/64 /opt/csw/mysql51/lib/64/$ISALIST/mysql o needed sonames: libz.so.1 libpthread.so.1 librt.so.1 libc.so.1 libsocket.so.1 libnsl.so.1 libm.so.2 libthread.so.1 It will make for a longer presentation but with a higher readability coefficient 2. a mechanism of submitting of the package to this presentation need to be defined, implemented and documented, viz. use case and walk-through. -- Peter From dam at opencsw.org Mon Aug 16 11:39:42 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 16 Aug 2010 11:39:42 +0200 Subject: [csw-maintainers] Preliminary package reviews In-Reply-To: <5F603545-B14D-4FC1-8D71-96944E4FB3A9@opencsw.org> References: <5F603545-B14D-4FC1-8D71-96944E4FB3A9@opencsw.org> Message-ID: <433348D5-5DC1-43BB-9878-98CAAFE7828C@opencsw.org> Hi Maciej, Am 16.08.2010 um 10:47 schrieb Dagobert Michelsen: > - it would be nice if the repository link from the pkginfo > OPENCSW_REPOSITORY: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/mysql5/branches/mysql-5.1.x at 10727 > would be a link also to directly jump to the GAR manifest This https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/mysql5/branches/mysql-5.1.x at 10727 would be need to be rewritten for browsing as http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/mysql5/branches/mysql-5.1.x?rev=10727 Best regards -- Dago From maciej at opencsw.org Mon Aug 16 13:07:23 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 16 Aug 2010 12:07:23 +0100 Subject: [csw-maintainers] Preliminary package reviews In-Reply-To: <433348D5-5DC1-43BB-9878-98CAAFE7828C@opencsw.org> References: <5F603545-B14D-4FC1-8D71-96944E4FB3A9@opencsw.org> <433348D5-5DC1-43BB-9878-98CAAFE7828C@opencsw.org> Message-ID: No dia 16 de Agosto de 2010 10:39, Dagobert Michelsen escreveu: > Hi Maciej, > > Am 16.08.2010 um 10:47 schrieb Dagobert Michelsen: >> >> - it would be nice if the repository link from the pkginfo >> ? OPENCSW_REPOSITORY: >> https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/mysql5/branches/mysql-5.1.x at 10727 >> ?would be a link also to directly jump to the GAR manifest > > This > ?https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/mysql5/branches/mysql-5.1.x at 10727 > would be need to be rewritten for browsing as > ?http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/mysql5/branches/mysql-5.1.x?rev=10727 Link to the repo: I find that talking directly to the subversion repository (gar.svn.sourceforge.net) is faster, for now I've linked to it. Readability of lists: I've addressed Peter's suggestion to expand the runpath and needed soname lists. Table view: I like Dago's idea to create a table with sonames and runpaths, but haven't implemented it yet. Mechanism of submission: For now, there's only the tool to generate the HTML code. I'm open to suggestions what the submission mechanism could look like. (A command-line tool? Something similar to submitpkg?) Keeping the unpacked files: Currently, the extracted package is deleted as soon as statistics are collected. I understand that you would like to open the files directly in the browser. I wouldn't like to keep the unpacked files around. If you would like to have a shortcut to jump into the files on a FS, maybe there's another way? There could be a separate mechanism to keep unpacked packages. Another idea is to provide a couple of copy/paste shell lines to help the reviewer get started with the unpacking: wget gunzip pktrans ./ all cd Where the , , and other bits would be pre-filled in the HTML. The updated report is now up. I've also added a couple links, for example from needed sonames to file search on the website, and from the 'depends' section to package pages on the website. Maciej From maciej at opencsw.org Mon Aug 16 13:42:24 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 16 Aug 2010 12:42:24 +0100 Subject: [csw-maintainers] Preliminary package reviews In-Reply-To: References: <5F603545-B14D-4FC1-8D71-96944E4FB3A9@opencsw.org> <433348D5-5DC1-43BB-9878-98CAAFE7828C@opencsw.org> Message-ID: Instructions how to generate HTML from your own packages: - check out the newest GAR source https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/v2/ - run v2/bin/checkpkg against your set of packages v2/bin/checkpkg ... - calculate md5 sums of your packages, you'll need to pass them as arguments to pkgdb - run pkgdb gen-html and redirect the output to a file: v2/bin/pkgdb gen-html ... > your-file.html If it fails, please send me the error message. Maciej From phil at bolthole.com Mon Aug 16 17:54:02 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 16 Aug 2010 08:54:02 -0700 Subject: [csw-maintainers] comments on camp "wave", solaris 9 vs 10, etc Message-ID: hi folks, I've been catching up on the "wave" based notes of the summer camp sessions @ https://wave.google.com/wave/waveref/googlewave.com/w+0tu9vv7tA (thanks for putting that up, guys!) I wanted to mention, that I had ALREADY suggested to William (months ago), that, given the extreme difficulty of building the latest firefox under solaris, I would be fine if he did just 3.0 for solaris 9 (since that is already "done"), and then 3.6+, for solaris 10. The only remaining request there being that he recompiles 3.0 against the new "sun x11" based gtk, etc. I am okay with this being a general principle also. If there is EXTREME effort required to get something compiled on sol9, but it's an easy compile on sol10, then the sol9 version can be somewhat orphaned. My sticking point, is that a maintainer should at least put in *some* effort to compile on sol9, and attempt some amount of patching. And if they get stuck or out of their depth, they should request help. "I cant get it to work" is not the same thing as "it cant be done"[without extreme effort]. Noone is an expert in everything. Let's work together! From maciej at opencsw.org Mon Aug 16 17:53:55 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 16 Aug 2010 16:53:55 +0100 Subject: [csw-maintainers] New package request : thrift In-Reply-To: <201008160704.o7G74M58027895@www.opencsw.org> References: <201008160704.o7G74M58027895@www.opencsw.org> Message-ID: No dia 16 de Agosto de 2010 08:04, escreveu: > Thrift is a software framework for scalable cross-language services development. It combines a software stack with a code generation engine to build services that work efficiently and seamlessly between C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk, and OCaml. I've looked at it, and started off by replacing two instances of stdint.h with sys/inttypes.h. I've commited it, the current problem is: "src/generate/t_cpp_generator.cc", line 249: Error: The function "MKDIR" must have a prototype. I'm leaving it for anybody who wants to pick it up. https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/thrift/ Maciej From pfelecan at opencsw.org Mon Aug 16 18:21:34 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 16 Aug 2010 18:21:34 +0200 Subject: [csw-maintainers] Preliminary package reviews In-Reply-To: (Maciej Blizinski's message of "Mon, 16 Aug 2010 12:07:23 +0100") References: <5F603545-B14D-4FC1-8D71-96944E4FB3A9@opencsw.org> <433348D5-5DC1-43BB-9878-98CAAFE7828C@opencsw.org> Message-ID: "Maciej (Matchek) Blizinski" writes: > No dia 16 de Agosto de 2010 10:39, Dagobert Michelsen > escreveu: >> Hi Maciej, >> >> Am 16.08.2010 um 10:47 schrieb Dagobert Michelsen: >>> >>> - it would be nice if the repository link from the pkginfo >>> ? OPENCSW_REPOSITORY: >>> https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/mysql5/branches/mysql-5.1.x at 10727 >>> ?would be a link also to directly jump to the GAR manifest >> >> This >> ?https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/mysql5/branches/mysql-5.1.x at 10727 >> would be need to be rewritten for browsing as >> ?http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/mysql5/branches/mysql-5.1.x?rev=10727 > > Link to the repo: > I find that talking directly to the subversion repository > (gar.svn.sourceforge.net) is faster, for now I've linked to it. > > Readability of lists: > I've addressed Peter's suggestion to expand the runpath and needed soname lists. Can you do the same for: parsed basename {'arch': 'i386', 'catalogname': 'mysql51', 'full_version_string': '5.1.49,REV=2010.08.12', 'osrel': 'SunOS5.9', 'revision_info': {'REV': '2010.08.12'}, 'vendortag': 'CSW', 'version': '5.1.49', 'version_info': {'major version': '5', 'minor version': '1', 'patchlevel': '49'}} isalist ('pentium_pro+mmx', 'pentium_pro', 'pentium+mmx', 'pentium', 'i486', 'i386', 'i86') Don't forget: when the human is the reader you need to pretty print... > Table view: > I like Dago's idea to create a table with sonames and runpaths, but > haven't implemented it yet. Frankly I didn't got Dago's request. An example could be helpful. > Mechanism of submission: > For now, there's only the tool to generate the HTML code. I'm open to > suggestions what the submission mechanism could look like. (A > command-line tool? Something similar to submitpkg?) command line is necessary and sufficient. > Keeping the unpacked files: > Currently, the extracted package is deleted as soon as statistics are > collected. I understand that you would like to open the files > directly in the browser. I wouldn't like to keep the unpacked files > around. If you would like to have a shortcut to jump into the files > on a FS, maybe there's another way? There could be a separate > mechanism to keep unpacked packages. Another idea is to provide a > couple of copy/paste shell lines to help the reviewer get started with > the unpacking: > > wget > gunzip > pktrans ./ all > cd Keeping the extracted package is a waste of space. I prefer that you just provide the instructions to do it as you show above. > Where the , , and other bits would be pre-filled in the HTML. > > The updated report is now up. I've also added a couple links, for > example from needed sonames to file search on the website, and from > the 'depends' section to package pages on the website. Nicer... -- Peter From phil at bolthole.com Mon Aug 16 18:28:50 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 16 Aug 2010 09:28:50 -0700 Subject: [csw-maintainers] [board] Result from ping to maintainers In-Reply-To: <7C272D2C-70FC-46F9-8C6A-1A58AD566BFF@opencsw.org> References: <7C272D2C-70FC-46F9-8C6A-1A58AD566BFF@opencsw.org> Message-ID: (replying to the thread by Peter B and Dagobert on potentialy retired maintainers) Peter, thanks for taking the initiative to try to ping inactive folks. Seems like Dago was indicating that there may be a problem or two with the method you used to collect the replies, though. Or sending targets, or something... (?). I retired the one person specifically targetted by Dago. (rmartin?) I've left the others alone for now, though, because its unclear to me who should "really" be marked as retired. If the two of you come up with a specific "these people are retired" list that you both agree on, I'll do the grungy backend stuff to officially mark them as retired. From dam at opencsw.org Mon Aug 16 18:45:44 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 16 Aug 2010 18:45:44 +0200 Subject: [csw-maintainers] Preliminary package reviews In-Reply-To: References: <5F603545-B14D-4FC1-8D71-96944E4FB3A9@opencsw.org> <433348D5-5DC1-43BB-9878-98CAAFE7828C@opencsw.org> Message-ID: Hi Maciej, Am 16.08.2010 um 13:07 schrieb Maciej (Matchek) Blizinski: > No dia 16 de Agosto de 2010 10:39, Dagobert Michelsen > escreveu: >> Hi Maciej, >> >> Am 16.08.2010 um 10:47 schrieb Dagobert Michelsen: >>> >>> - it would be nice if the repository link from the pkginfo >>> OPENCSW_REPOSITORY: >>> https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/mysql5/branches/mysql-5.1.x at 10727 >>> would be a link also to directly jump to the GAR manifest >> >> This >> https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/mysql5/branches/mysql-5.1.x at 10727 >> would be need to be rewritten for browsing as >> http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/mysql5/branches/mysql-5.1.x?rev=10727 > > Link to the repo: > I find that talking directly to the subversion repository > (gar.svn.sourceforge.net) is faster, for now I've linked to it. I have two issues with this: 1. The link to the repository is not fixated to the revision, so if the file in the repository received commits after the packaging you browse the current version and not the one the package was built from. 2. The Trac repository browser allows immediate history browsing and is nicely formatted So if you want to keep the direct link to the repository I would like to have an additional link ("Tracbrowser"?) with the rewritten URL to give the user the choice which one to use. > Readability of lists: > I've addressed Peter's suggestion to expand the runpath and needed > soname lists. Cool > Table view: > I like Dago's idea to create a table with sonames and runpaths, but > haven't implemented it yet. Thanks! > Mechanism of submission: > For now, there's only the tool to generate the HTML code. I'm open to > suggestions what the submission mechanism could look like. (A > command-line tool? Something similar to submitpkg?) I would like to fully integrate this in the mechanism we have right now: - packages in experimental/ are directly made browsable by adding links after each package. All packages in each subdirectory of experimental/ are checked together. If you don't want that just make additional directories in experimental. - packages in current/ and stable/ are checked in full and are directly browsable from the package view on the website. > Keeping the unpacked files: > Currently, the extracted package is deleted as soon as statistics are > collected. I understand that you would like to open the files > directly in the browser. I wouldn't like to keep the unpacked files > around. Ok, what about if I already have an upacked version around and give an extra parameter to pkgdb like -d /home/pkgbrowser/pkgs/078cf1b32e084b140d17ae2e054f07d0 that it automatically adds links to the unpacked files in the given directory. There would also need to be a way to specify the URL prefix under which this directory is reachable. The directory would then look something like this: pkgbrowser |-- html | `-- 078cf1b32e084b140d17ae2e054f07d0.html `-- pkgs `-- 078cf1b32e084b140d17ae2e054f07d0 `-- CSWmemcached |-- install | |-- copyright | `-- depend |-- pkginfo |-- pkgmap `-- root `-- opt `-- csw |-- bin | |-- amd64 | | `-- memcached | `-- memcached |-- include | `-- memcached | `-- protocol_binary.h `-- share |-- doc | `-- memcached | `-- license `-- man `-- man1 `-- memcached.1 Best regards -- Dago From dam at opencsw.org Mon Aug 16 18:51:14 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 16 Aug 2010 18:51:14 +0200 Subject: [csw-maintainers] [board] Result from ping to maintainers In-Reply-To: References: <7C272D2C-70FC-46F9-8C6A-1A58AD566BFF@opencsw.org> Message-ID: Hi Peter, Am 16.08.2010 um 18:28 schrieb Philip Brown: > I retired the one person specifically targetted by Dago. (rmartin?) > I've left the others alone for now, though, because its unclear to me > who should "really" be marked as retired. > > If the two of you come up with a specific "these people are retired" > list that you both agree on, I'll do the grungy backend stuff to > officially mark them as retired. Peter just send his earlier versions where he didn't apply my ping result. Peter: would you mind adjusting the list? Best regards -- Dago From dam at opencsw.org Mon Aug 16 19:10:26 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 16 Aug 2010 19:10:26 +0200 Subject: [csw-maintainers] Preliminary package reviews In-Reply-To: References: <5F603545-B14D-4FC1-8D71-96944E4FB3A9@opencsw.org> <433348D5-5DC1-43BB-9878-98CAAFE7828C@opencsw.org> Message-ID: <38A6727B-595E-43A0-B4C1-763AC2898BC3@opencsw.org> Hi Peter, Am 16.08.2010 um 18:21 schrieb Peter FELECAN: >> Table view: >> I like Dago's idea to create a table with sonames and runpaths, but >> haven't implemented it yet. > > Frankly I didn't got Dago's request. An example could be helpful. Ah, now I got what you didn't got :-) I want a table with binaries and libraries in rows and runpathes and needed sonames in columns like this: | runpath | sonames | /opt/csw... | .../64 | libz.so.1 | ... -------+-------------+--------+-----------+---- mysql | 1 | 2 | X | resolve| 1 | 2 | | X The idea is that several libraries and binaries will have the same pathes and will need the same libraries. By just looking at the table it should be pretty easy to see if binaries use different pathes, like a "one watch" visual. Best regards -- Dago From pfelecan at opencsw.org Mon Aug 16 19:22:15 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 16 Aug 2010 19:22:15 +0200 Subject: [csw-maintainers] Preliminary package reviews In-Reply-To: <38A6727B-595E-43A0-B4C1-763AC2898BC3@opencsw.org> (Dagobert Michelsen's message of "Mon, 16 Aug 2010 19:10:26 +0200") References: <5F603545-B14D-4FC1-8D71-96944E4FB3A9@opencsw.org> <433348D5-5DC1-43BB-9878-98CAAFE7828C@opencsw.org> <38A6727B-595E-43A0-B4C1-763AC2898BC3@opencsw.org> Message-ID: Dagobert Michelsen writes: > Hi Peter, > > Am 16.08.2010 um 18:21 schrieb Peter FELECAN: >>> Table view: >>> I like Dago's idea to create a table with sonames and runpaths, but >>> haven't implemented it yet. >> >> Frankly I didn't got Dago's request. An example could be helpful. > > Ah, now I got what you didn't got :-) > > I want a table with binaries and libraries in rows and runpathes > and needed sonames in columns like this: > > | runpath | sonames > | /opt/csw... | .../64 | libz.so.1 | ... > -------+-------------+--------+-----------+---- > mysql | 1 | 2 | X | > resolve| 1 | 2 | | X > > The idea is that several libraries and binaries will have the same > pathes and > will need the same libraries. By just looking at the table it should > be pretty > easy to see if binaries use different pathes, like a "one watch" visual. Alright. Thank you. I will understand better when the prototype will evolve and I'll see a "real" example. -- Peter From maciej at opencsw.org Mon Aug 16 20:16:34 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 16 Aug 2010 19:16:34 +0100 Subject: [csw-maintainers] straw poll on git-patching In-Reply-To: <1281805187-sup-4641@pinkfloyd.chass.utoronto.ca> References: <1281805187-sup-4641@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 14 de Agosto de 2010 18:00, Ben Walton escreveu: > > Ok, since the issue was re-raised, lets do a quick informal poll (GAR > users only, please). > > Two questions: > > Would you like the option to turn off the git-patch support in GAR > If yes, what do you feel the default should be. Is it related to the sharutils problem? If some packages don't build in the presence of the .git directory, this option would be useful. From phil at bolthole.com Tue Aug 17 01:48:49 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 16 Aug 2010 16:48:49 -0700 Subject: [csw-maintainers] IPS gripes Message-ID: Side comment, and reason number [...] to dislike IPS: It doesnt do what it's told. http://opensolaris.org/jive/thread.jspa?messageID=496774 I really, really wish there was a nice simple equivalent to being able to manually grab a "NVDAgraphics.pkg" and install it by hand, right about now. "Simpler is Better". From phil at bolthole.com Tue Aug 17 02:20:05 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 16 Aug 2010 17:20:05 -0700 Subject: [csw-maintainers] NFS-style /opt/csw, and zfs root, beadm, Message-ID: Among the other things of interest I read from the summer camp minutes, I read with interest, the discussion on /opt/csw, and handling it in NFS-clean ways, etc. An additional point in its favour that I just discovered, relates to having a zfs root, and solaris's new, configurable "boot environments". (which work even in regular Solaris, since MU8 I think) Recap for those unfamiliar with it: Once you have a ZFS root filesystem, the "beadm" command lets you take "root" filesystem snapshots; presumably for pre-OS-patch purposes, so you have a quick-n-easy revert target if things go horribly wrong. For what it's worth, its relatively easy: the beadm command both sets up a named, snapshot, AND adds an additional labeled entry in the boot-time grub menu for you to select it if you wish. So, things get interesting when you decide that you do NOT wish to have /opt/csw as part of your "root filesystem", but have a separate one. (reasons on WHY you might do this later) If you have a separate filesystem, created as a zfs filesystem in your normal "pool", then /opt/csw will get nicely and automatically mounted,reguardless of which boot environment you start things up in. Hurray! ? BUT... if you are not booted from your original boot environment, or a derivative of it... you have now lost ALL your /etc/opt/csw files. You now see ONLY what is under /opt/csw Now the PS on why you may choose to do this separate /opt/csw approach? I can think of at least 2 reasons: 1. You plan on deliberately keeping multiple "Boot Environments" around, for testing purposes. Sure, you might choose to use virtual environments for that sort of thing, but this multiboot type approach is a more complete test. You could even switch between Solaris(FCS) and OpenSolaris [and possibly SolarisExpress(tm)(R)], I think. 2. You want to keep a backrevved version of your months-old boot environment handy, "Just in case".... but you dont want to throw away a couple of gigabytes in needless snapshot data of /opt/xyz as it changes over time, just to preserve your old *OS* information From maciej at opencsw.org Tue Aug 17 10:46:58 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 17 Aug 2010 09:46:58 +0100 Subject: [csw-maintainers] Spam from the pkgrequest form (was: Re: [csw-pkgrequests] New package request : Candace Kemp) Message-ID: How about adding a honeypot field? It's a text field that must remain empty for the form to be accepted. Bots usually try to fill all the fields in the hope that they will fill in all the mandatory fields. From pfelecan at opencsw.org Tue Aug 17 11:18:06 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 17 Aug 2010 11:18:06 +0200 Subject: [csw-maintainers] Spam from the pkgrequest form In-Reply-To: (Maciej Blizinski's message of "Tue, 17 Aug 2010 09:46:58 +0100") References: Message-ID: "Maciej (Matchek) Blizinski" writes: > How about adding a honeypot field? It's a text field that must remain > empty for the form to be accepted. Bots usually try to fill all the > fields in the hope that they will fill in all the mandatory fields. Is this efficient? How about a captcha? The same will apply for the new maintainer subscription, isn't it? -- Peter From maciej at opencsw.org Tue Aug 17 11:30:25 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 17 Aug 2010 10:30:25 +0100 Subject: [csw-maintainers] Spam from the pkgrequest form In-Reply-To: References: Message-ID: No dia 17 de Agosto de 2010 10:18, Peter FELECAN escreveu: > "Maciej (Matchek) Blizinski" writes: > >> How about adding a honeypot field? ?It's a text field that must remain >> empty for the form to be accepted. ?Bots usually try to fill all the >> fields in the hope that they will fill in all the mandatory fields. > > Is this efficient? How about a captcha? The same will apply for the new > maintainer subscription, isn't it? True, captchas are better. I was thinking that a honeypot field is easier to implement. From pfelecan at opencsw.org Tue Aug 17 11:39:24 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 17 Aug 2010 11:39:24 +0200 Subject: [csw-maintainers] Spam from the pkgrequest form In-Reply-To: (Maciej Blizinski's message of "Tue, 17 Aug 2010 10:30:25 +0100") References: Message-ID: "Maciej (Matchek) Blizinski" writes: > No dia 17 de Agosto de 2010 10:18, Peter FELECAN > escreveu: >> "Maciej (Matchek) Blizinski" writes: >> >>> How about adding a honeypot field? ?It's a text field that must remain >>> empty for the form to be accepted. ?Bots usually try to fill all the >>> fields in the hope that they will fill in all the mandatory fields. >> >> Is this efficient? How about a captcha? The same will apply for the new >> maintainer subscription, isn't it? > > True, captchas are better. I was thinking that a honeypot field is > easier to implement. The honeypot field is cheapo indeed. Who can do the modification and who has knowledge resources for captcha? -- Peter From william at wbonnet.net Tue Aug 17 12:22:25 2010 From: william at wbonnet.net (William Bonnet) Date: Tue, 17 Aug 2010 12:22:25 +0200 Subject: [csw-maintainers] Spam from the pkgrequest form In-Reply-To: References: Message-ID: <4C6A62E1.9050406@wbonnet.net> Hi >> How about adding a honeypot field? It's a text field that must remain >> empty for the form to be accepted. Bots usually try to fill all the >> fields in the hope that they will fill in all the mandatory fields. >> > Is this efficient? How about a captcha? The same will apply for the new > maintainer subscription, isn't it? > ThanksMeter and Maciej, this is a good idea. I'm giving a look to php and wordpress stuff for availables captcha libraries. This form was made quickly, i am adding a database storage for requested packages. This form will display the list of requested packages. cheers W. From maciej at opencsw.org Tue Aug 17 12:38:16 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 17 Aug 2010 11:38:16 +0100 Subject: [csw-maintainers] Preliminary package reviews In-Reply-To: References: <5F603545-B14D-4FC1-8D71-96944E4FB3A9@opencsw.org> <433348D5-5DC1-43BB-9878-98CAAFE7828C@opencsw.org> Message-ID: No dia 16 de Agosto de 2010 17:21, Peter FELECAN escreveu: >> Readability of lists: >> I've addressed Peter's suggestion to expand the runpath and needed soname lists. > > Can you do the same for: > > parsed basename > > {'arch': 'i386', > ?'catalogname': 'mysql51', > ?'full_version_string': '5.1.49,REV=2010.08.12', > ?'osrel': 'SunOS5.9', > ?'revision_info': {'REV': '2010.08.12'}, > ?'vendortag': 'CSW', > ?'version': '5.1.49', > ?'version_info': {'major version': '5', > ? ? ? ? ? ? ? ? ?'minor version': '1', > ? ? ? ? ? ? ? ? ?'patchlevel': '49'}} > > isalist > > ('pentium_pro+mmx', 'pentium_pro', 'pentium+mmx', 'pentium', 'i486', > 'i386', 'i86') > > Don't forget: when the human is the reader you need to pretty print... Yes, these are prettified as well now. I also added a table of contents, and updated the example to include more than one package: http://bender.opencsw.org/~maciej/pkg-review-prototype.html >> Table view: >> I like Dago's idea to create a table with sonames and runpaths, but >> haven't implemented it yet. > > Frankly I didn't got Dago's request. An example could be helpful. > >> Mechanism of submission: >> For now, there's only the tool to generate the HTML code. ?I'm open to >> suggestions what the submission mechanism could look like. ?(A >> command-line tool? ?Something similar to submitpkg?) > > command line is necessary and sufficient. Dago is already thinking of creating some kind of a pipeline: a set of packages is picked up (a command line tool, or dropping into a directory), then dissected by checkpkg. A HTML report is generated and the package gets also unpacked into a directory from which the contents is served over HTTP. I've also added a flag to specify the HTML template to use. Dago can now experiment with adding links, for instance. From pfelecan at opencsw.org Tue Aug 17 13:12:26 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 17 Aug 2010 13:12:26 +0200 Subject: [csw-maintainers] Preliminary package reviews In-Reply-To: (Maciej Blizinski's message of "Tue, 17 Aug 2010 11:38:16 +0100") References: <5F603545-B14D-4FC1-8D71-96944E4FB3A9@opencsw.org> <433348D5-5DC1-43BB-9878-98CAAFE7828C@opencsw.org> Message-ID: "Maciej (Matchek) Blizinski" writes: > No dia 16 de Agosto de 2010 17:21, Peter FELECAN > escreveu: >>> Readability of lists: >>> I've addressed Peter's suggestion to expand the runpath and needed soname lists. >> >> Can you do the same for: >> >> parsed basename >> >> {'arch': 'i386', >> ?'catalogname': 'mysql51', >> ?'full_version_string': '5.1.49,REV=2010.08.12', >> ?'osrel': 'SunOS5.9', >> ?'revision_info': {'REV': '2010.08.12'}, >> ?'vendortag': 'CSW', >> ?'version': '5.1.49', >> ?'version_info': {'major version': '5', >> ? ? ? ? ? ? ? ? ?'minor version': '1', >> ? ? ? ? ? ? ? ? ?'patchlevel': '49'}} >> >> isalist >> >> ('pentium_pro+mmx', 'pentium_pro', 'pentium+mmx', 'pentium', 'i486', >> 'i386', 'i86') >> >> Don't forget: when the human is the reader you need to pretty print... > > Yes, these are prettified as well now. I also added a table of > contents, and updated the example to include more than one package: > http://bender.opencsw.org/~maciej/pkg-review-prototype.html Nice and readable by the human that I am. Adding a TOC is also a good idea. Now, I hope that this is transformed in an available feature for everybody. -- Peter From dlaigle at opencsw.org Tue Aug 17 16:20:46 2010 From: dlaigle at opencsw.org (Dom) Date: Tue, 17 Aug 2010 16:20:46 +0200 Subject: [csw-maintainers] need of an additional directory tree under /opt/csw Message-ID: <55E6A7D0-F196-4A4A-ADBA-6552BB9EBE94@opencsw.org> Hi, To start a thread we didn't have time to talk about during the summer camp, I'd like to install some additional dependencies within the CSW tree. Indeed, I have to recompile the WxWidget package with g++ for at least TWO packages, and I think it'd be better to install it under something like -say - /opt/csw/extra-dependencies-gcc instead of embedding it twice into both packages. Any thoughts ? - Dominique From pfelecan at opencsw.org Tue Aug 17 17:15:12 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 17 Aug 2010 17:15:12 +0200 Subject: [csw-maintainers] need of an additional directory tree under /opt/csw In-Reply-To: <55E6A7D0-F196-4A4A-ADBA-6552BB9EBE94@opencsw.org> (Dom's message of "Tue, 17 Aug 2010 16:20:46 +0200") References: <55E6A7D0-F196-4A4A-ADBA-6552BB9EBE94@opencsw.org> Message-ID: Dom writes: > Hi, > > To start a thread we didn't have time to talk about during the summer > camp, I'd like to install some additional dependencies within the CSW > tree. Indeed, I have to recompile the WxWidget package with g++ for > at least TWO packages, and I think it'd be better to install it under > something like -say - /opt/csw/extra-dependencies-gcc instead of > embedding it twice into both packages. > > Any thoughts ? Dominique, You mentioned this but we didn't spent time on. Here are my 2 euro cents: - create a clearly identified package containing WxWidget compiled with g++ - depend on the previously created package your new packages The issue of where to install the dependency package is not clear for me but it seems to be to be similar to the alternatives approach, i.e., I have 2 similar packages and I choose on which to depend, both being installable simultaneously. -- Peter From phil at bolthole.com Tue Aug 17 17:56:30 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 17 Aug 2010 08:56:30 -0700 Subject: [csw-maintainers] need of an additional directory tree under /opt/csw In-Reply-To: <55E6A7D0-F196-4A4A-ADBA-6552BB9EBE94@opencsw.org> References: <55E6A7D0-F196-4A4A-ADBA-6552BB9EBE94@opencsw.org> Message-ID: On 8/17/10, Dom wrote: > Hi, > > To start a thread we didn't have time to talk about during the summer camp, > I'd like to install some additional dependencies within the CSW tree. > Indeed, I have to recompile the WxWidget package with g++ for at least TWO > packages, and I think it'd be better to install it under something like -say > - /opt/csw/extra-dependencies-gcc instead of embedding it twice into both > packages. > > Any thoughts ? > This is similar to the (admittedly now rather.. crusty) kde/qt issue. where we have sun-compiled qt in /opt/csw, but gcc-compiled qt in a subtree. there is a question of why the tree is neccessary. Then there is a secondary question, of how visible does it need to be? For the Qt case, there is an accepted need for multiple levels of dependancy and compilation. Package A, needs package B, which needs qt-gcc. Package B needs a "special" set of configuration files (a la pkgconfig) for gcc-compiled qt, for Package A to then compile properly. Are there multi-level compilation issues involved with wxwidgets also? If there are not, then even if wxwidgets itself provides "special" gcc-related flags, we may be better off keeping the gcc-tweaked stuff under /opt/csw/lib/wx-gcc-dev or something like that. And/Or, if there is a nice simple top-level "wx-compile-config" wrapper, providing "wx-compile-config-gcc". And/Or, The "simplest case" approach, would be if we could get away with providing just /opt/csw/lib/libwx-gcc Then adjusting gcc-needing dependants, to have -R,-L/opt/csw/lib/libwx-gcc at link time. So... how fussy/needy is the wxwidgets compile environment? From skayser at opencsw.org Tue Aug 17 18:36:32 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 17 Aug 2010 18:36:32 +0200 Subject: [csw-maintainers] Updated postfix packages (2.7.1) in experimental/, testing appreciated Message-ID: <20100817163631.GI31821@sebastiankayser.de> Hi, after ages(eseses) I finally tackled the postfix package upgrade and an updated package (2.7.1) is now available from experimental/. http://mirror.opencsw.org/experimental.html#skayser pkgutil -t http://mirror.opencsw.org/opencsw/experimental/skayser -i postfix Quite a few changes went into it, most notably, postfix doesn't touch the system sendmail binaries any more. It just installs alongside sendmail and it's up to the user to take further actions (README.CSW has details). Also the spool location has changed from /opt/csw/var to /var/opt/csw to make postfix zone-friendly. As the version bump is a bit substantial, I do appreciate any testing and feedback that you guys / postfix users out there can provide. I am planning to then publish a polished package during the next few days. The full list of changes: * Adopted and updated to 2.7.1. (Closes #3580, #3700, #3970) * Moved spool directory to /var/opt/csw/spool/postfix. (Closes #3946) * Added Cyrus SASL support. (Closes #2843) * Added hash table support via bdb. (Closes #2097) * Init / SMF handling now done with cswclassutils. (Closes #3946) * Now depends on pcre_rt instead of pcre. (Closes #3017) * Binaries in /opt/csw/libexec/postfix are now stripped. (Closes #3063) * Doesn't automatically substitute system sendmail binaries any more. Please refer to README.CSW instead. (Closes #1943, #2964, #3060) Sebastian From skayser at opencsw.org Tue Aug 17 18:49:59 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 17 Aug 2010 18:49:59 +0200 Subject: [csw-maintainers] Updated postfix packages (2.7.1) in experimental/, testing appreciated In-Reply-To: <20100817163631.GI31821@sebastiankayser.de> References: <20100817163631.GI31821@sebastiankayser.de> Message-ID: <20100817164959.GJ31821@sebastiankayser.de> * Sebastian Kayser wrote: > after ages(eseses) I finally tackled the postfix package upgrade and an > updated package (2.7.1) is now available from experimental/. A question regarding the package: currently it is the full featured postfix with all dependencies (ldap, kerberos, postgres, mysql). In addition to this package I would like to provide a postfix_simple package which is a feature-stripped version without a big dependency chain. Similar to what Ihsan provides on his own [1]. Are there any objections to or thoughts on this? The GAR recipe [2] already supports building this alternative package by setting 'BUILDTYPE=simple' on the commandline, so it's just a matter of running the build twice. Sebastian [1] http://ihsan.dogan.ch/postfix/ [2] https://gar.svn.sf.net/svnroot/gar/csw/mgar/pkg/postfix/branches/postfix-2.7/Makefile From phil at bolthole.com Tue Aug 17 18:57:38 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 17 Aug 2010 09:57:38 -0700 Subject: [csw-maintainers] Updated postfix packages (2.7.1) in experimental/, testing appreciated In-Reply-To: <20100817164959.GJ31821@sebastiankayser.de> References: <20100817163631.GI31821@sebastiankayser.de> <20100817164959.GJ31821@sebastiankayser.de> Message-ID: On 8/17/10, Sebastian Kayser wrote: > > In addition to this package I would like to provide a postfix_simple > package which is a feature-stripped version without a big dependency > chain. Similar to what Ihsan provides on his own [1]. > > Are there any objections to or thoughts on this? The GAR recipe [2] > already supports building this alternative package by setting > 'BUILDTYPE=simple' on the commandline, so it's just a matter of running > the build twice. > I think it's a great idea. Just please allow the two packages to co-exist, rather than conflicting with each other. There's more than one way to handle the layout thereof; completely separate trees, or "alternatives" based binary overlays, or possibly something else entirely. (lazyloading the libs, and not force-depending on them?) Please pick whatever method you find least offensive :-) From bonivart at opencsw.org Tue Aug 17 19:12:00 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 17 Aug 2010 19:12:00 +0200 Subject: [csw-maintainers] Updated postfix packages (2.7.1) in experimental/, testing appreciated In-Reply-To: <20100817164959.GJ31821@sebastiankayser.de> References: <20100817163631.GI31821@sebastiankayser.de> <20100817164959.GJ31821@sebastiankayser.de> Message-ID: On Tue, Aug 17, 2010 at 6:49 PM, Sebastian Kayser wrote: > * Sebastian Kayser wrote: >> after ages(eseses) I finally tackled the postfix package upgrade and an >> updated package (2.7.1) is now available from experimental/. > > A question regarding the package: currently it is the full featured > postfix with all dependencies (ldap, kerberos, postgres, mysql). > > In addition to this package I would like to provide a postfix_simple > package which is a feature-stripped version without a big dependency > chain. Similar to what Ihsan provides on his own [1]. > > Are there any objections to or thoughts on this? The GAR recipe [2] > already supports building this alternative package by setting > 'BUILDTYPE=simple' on the commandline, so it's just a matter of running > the build twice. Great work! Something similar needs to be done to Sendmail. I know Mike Watters worked on modernizing it, I'll take a look at what he did. Regarding the deps for postfix (looking at the one currently in the catalog), on Solaris 10/i386 it's a 31 MB download, not too extreme. Not all those deps are postfix's fault either, packages like sasl needs to be respun to loose the dep to full openssl for example. Sendmail, for comparison, is a 14 MB download, also hurt by sasl pulling in full openssl. We could save 4 MB by rebuilding sasl alone. -- /peter From skayser at opencsw.org Tue Aug 17 19:13:29 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 17 Aug 2010 19:13:29 +0200 Subject: [csw-maintainers] Updated postfix packages (2.7.1) in experimental/, testing appreciated In-Reply-To: References: <20100817163631.GI31821@sebastiankayser.de> <20100817164959.GJ31821@sebastiankayser.de> Message-ID: <20100817171329.GK31821@sebastiankayser.de> * Philip Brown wrote: > On 8/17/10, Sebastian Kayser wrote: > > > > In addition to this package I would like to provide a postfix_simple > > package which is a feature-stripped version without a big dependency > > chain. Similar to what Ihsan provides on his own [1]. > > > > Are there any objections to or thoughts on this? The GAR recipe [2] > > already supports building this alternative package by setting > > 'BUILDTYPE=simple' on the commandline, so it's just a matter of running > > the build twice. > > > > I think it's a great idea. Just please allow the two packages to > co-exist, rather than conflicting with each other. > There's more than one way to handle the layout thereof; completely > separate trees, or "alternatives" based binary overlays, or possibly > something else entirely. (lazyloading the libs, and not > force-depending on them?) > Please pick whatever method you find least offensive :-) Honestly, the postfix build recipe is already huge and if possible, I would like to refrain from introducing any additional complexity. What exactly are we trying to solve by not conflicting packages? Allowing to pkg-get -i all? If so, could this be rethought and tackled differently? Sebastian From bonivart at opencsw.org Tue Aug 17 19:17:28 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 17 Aug 2010 19:17:28 +0200 Subject: [csw-maintainers] Updated postfix packages (2.7.1) in experimental/, testing appreciated In-Reply-To: References: <20100817163631.GI31821@sebastiankayser.de> <20100817164959.GJ31821@sebastiankayser.de> Message-ID: On Tue, Aug 17, 2010 at 6:57 PM, Philip Brown wrote: > Just please allow the two packages to > co-exist, rather than conflicting with each other. What would be the purpose of installing both those packages on the same system? Who would want to do that? Just declare them incompatible with each other. -- /peter From dam at opencsw.org Tue Aug 17 22:21:17 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 17 Aug 2010 22:21:17 +0200 Subject: [csw-maintainers] Updated postfix packages (2.7.1) in experimental/, testing appreciated In-Reply-To: <20100817171329.GK31821@sebastiankayser.de> References: <20100817163631.GI31821@sebastiankayser.de> <20100817164959.GJ31821@sebastiankayser.de> <20100817171329.GK31821@sebastiankayser.de> Message-ID: <68329550-ACD6-44C8-A8BB-00392B47B6EB@opencsw.org> Hi Sebastian, Am 17.08.2010 um 19:13 schrieb Sebastian Kayser: > * Philip Brown wrote: >> On 8/17/10, Sebastian Kayser wrote: >>> >>> In addition to this package I would like to provide a postfix_simple >>> package which is a feature-stripped version without a big dependency >>> chain. Similar to what Ihsan provides on his own [1]. >>> >>> Are there any objections to or thoughts on this? The GAR recipe [2] >>> already supports building this alternative package by setting >>> 'BUILDTYPE=simple' on the commandline, so it's just a matter of running >>> the build twice. >> >> I think it's a great idea. Just please allow the two packages to >> co-exist, rather than conflicting with each other. >> There's more than one way to handle the layout thereof; completely >> separate trees, or "alternatives" based binary overlays, or possibly >> something else entirely. (lazyloading the libs, and not >> force-depending on them?) >> Please pick whatever method you find least offensive :-) > > Honestly, the postfix build recipe is already huge and if possible, I > would like to refrain from introducing any additional complexity. I don't think you see how easy this really is: You already did the hard work of adding a "switch": just add EXTRA_MODULATORS = BUILDTYPE MODULATIONS_BUILDTYPE = simple complex and do add a couple of lines for alternatives switching. It is really easy. I can do this if you want. It is even simpler than mutt, because mutt has two different flavors with B -> A and B' -> A whereas you would have CSWpostfix-full -> CSWpostfix with CSWpostfix containing everything and CSWpostfix-full just the enhanced binary and extra dependencies. You may want to look at mutt as reference, although your case is probably even simpler: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/mutt/trunk/Makefile > What exactly are we trying to solve by not conflicting packages? You can't know this - I plan to auto-install all generated packages into an extra experimental zone and conflicting packages would make this harder than necessary. Additionally, with the alternatives approach you could start with CSWpostfix and work with it. If you need more features you can just install CSWpostfix-feature and just use the new things without ugly deinstall - reinstall. Best regards -- Dago From dlaigle at opencsw.org Wed Aug 18 00:22:38 2010 From: dlaigle at opencsw.org (Dom) Date: Wed, 18 Aug 2010 00:22:38 +0200 Subject: [csw-maintainers] need of an additional directory tree under /opt/csw In-Reply-To: References: <55E6A7D0-F196-4A4A-ADBA-6552BB9EBE94@opencsw.org> Message-ID: Well, these are tough questions for me. As Peter mentioned, having well-identified packages would make life easier for other maintainers who have similar dependencies. To the question "why" I need gcc/g++ compiled libraries, I just can answer the following: more that 440 c++ source files to hack in order to be "Sun-Studio compliant" is a lot of too much work for me, just to have binaries available on Sun Solaris (yes: Sun Solaris, and not Oracle Solaris :-)). I had some cheat chat with the main developers of Kicad and they just answered to me: "we only support Gcc". And indeed: all the patches I submitted to them in order to have C++ code without any GCC specific extensions were refused ! I have no problem embedding specific dependencies within each packages, even if some of them have to be installed twice or more. It is just a question of "quality" for me... BTW: the incoming Kicad package I'll release will NOT include the "dev" version of WxWidget 2.8.11 I had to provide internally. So will it be for Erlang. Funny is that Kicad depends on Erlang, and both depend on WxWidgets. And I'll have the same case with "boost", unfortunatly. But this still remains subject to change... for the next versions ! - Dominique On Aug 17, 2010, at 17:08 PM, Philip Brown wrote: > On 8/17/10, Dom wrote: >> Hi, >> >> To start a thread we didn't have time to talk about during the summer camp, >> I'd like to install some additional dependencies within the CSW tree. >> Indeed, I have to recompile the WxWidget package with g++ for at least TWO >> packages, and I think it'd be better to install it under something like -say >> - /opt/csw/extra-dependencies-gcc instead of embedding it twice into both >> packages. >> >> Any thoughts ? >> > > This is similar to the (admittedly now rather.. crusty) kde/qt issue. > where we have sun-compiled qt in /opt/csw, but gcc-compiled qt in a > subtree. > > there is a question of why the tree is neccessary. Then there is a > secondary question, of how visible does it need to be? > > For the Qt case, there is an accepted need for multiple levels of > dependancy and compilation. > Package A, needs package B, which needs qt-gcc. > Package B needs a "special" set of configuration files (a la > pkgconfig) for gcc-compiled qt, for Package A to then compile > properly. > > Are there multi-level compilation issues involved with wxwidgets also? > If there are not, then even if wxwidgets itself provides "special" > gcc-related flags, we may be better off keeping the gcc-tweaked stuff > under /opt/csw/lib/wx-gcc-dev or something like that. > > And/Or, if there is a nice simple top-level "wx-compile-config" > wrapper, providing "wx-compile-config-gcc". > > And/Or, > The "simplest case" approach, would be if we could get away with providing just > /opt/csw/lib/libwx-gcc > Then adjusting gcc-needing dependants, to have > -R,-L/opt/csw/lib/libwx-gcc at link time. > > So... how fussy/needy is the wxwidgets compile environment? > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From ihsan at opencsw.org Wed Aug 18 12:07:59 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 18 Aug 2010 12:07:59 +0200 Subject: [csw-maintainers] Updating libfaad2 and mpeg4ip In-Reply-To: <4C6045E6.6080101@opencsw.org> References: <1280278827-sup-1945@pinkfloyd.chass.utoronto.ca> <4C6045E6.6080101@opencsw.org> Message-ID: <4C6BB0FF.5080701@opencsw.org> On 08/09/10 20:16, Ihsan Dogan wrote: >> xmms is ugly. and somewhat orphaned I heard. and there is xmms2. and... >> its messy. so anyone else is hereby cordially invited to take it over :-D > > But it's still one of the MP3 players for Unix. ^^^ the best -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Wed Aug 18 14:53:56 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 18 Aug 2010 14:53:56 +0200 Subject: [csw-maintainers] need of an additional directory tree under /opt/csw In-Reply-To: References: <55E6A7D0-F196-4A4A-ADBA-6552BB9EBE94@opencsw.org> Message-ID: <3954B48B-A6CF-4694-94E7-D890673CB596@opencsw.org> Hi Dominique, first, your GCCfss 4.3.2 and 4.3.3 have been installed on current9s and current10s. Am 18.08.2010 um 00:22 schrieb Dom: > these are tough questions for me. As Peter mentioned, having well- > identified packages would make life easier for other maintainers who > have similar dependencies. To the question "why" I need gcc/g++ > compiled libraries, I just can answer the following: more that 440 c+ > + source files to hack in order to be "Sun-Studio compliant" is a > lot of too much work for me, just to have binaries available on Sun > Solaris (yes: Sun Solaris, and not Oracle Solaris :-)). I had some > cheat chat with the main developers of Kicad and they just answered > to me: "we only support Gcc". And indeed: all the patches I > submitted to them in order to have C++ code without any GCC specific > extensions were refused ! > I have no problem embedding specific dependencies within each > packages, even if some of them have to be installed twice or more. > It is just a question of "quality" for me... > BTW: the incoming Kicad package I'll release will NOT include the > "dev" version of WxWidget 2.8.11 I had to provide internally. So > will it be for Erlang. Funny is that Kicad depends on Erlang, and > both depend on WxWidgets. And I'll have the same case with "boost", > unfortunatly. > > But this still remains subject to change... for the next versions ! I think it would be cleanest to have a convention for gcc-compiled c++ libs, like CSWlib is the Sun Studio version CSWlib-gcc is the gcc compiled version Then there should also be a standard place for these libs. I propose /opt/csw/lib/gcc/mylib.so /opt/csw/lib/gcc/amd64/mylib.so /opt/csw/lib/gcc/64 -> (amd64|sparcv9) These links should be delivered by CSWlibgcccommon. Thoughts? Best regards -- Dago From phil at bolthole.com Wed Aug 18 15:49:12 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 18 Aug 2010 06:49:12 -0700 Subject: [csw-maintainers] Updating libfaad2 and mpeg4ip In-Reply-To: <4C6BB0FF.5080701@opencsw.org> References: <1280278827-sup-1945@pinkfloyd.chass.utoronto.ca> <4C6045E6.6080101@opencsw.org> <4C6BB0FF.5080701@opencsw.org> Message-ID: please take it over then :-) On Wednesday, August 18, 2010, Ihsan Dogan wrote: > On 08/09/10 20:16, Ihsan Dogan wrote: > > > xmms is ugly. and somewhat orphaned I heard. and there is xmms2. and... > its messy. so anyone else is hereby cordially invited to take it over :-D > > > But it's still one of the MP3 players for Unix. > > ? ? ? ? ? ? ? ? ? ? ?^^^ > ? ? ? ? ? ? ? ? ? ?the best > > -- > ihsan at dogan.ch ? ? ? ? ? ? ? ?http://blog.dogan.ch/ > _______________________________________________ > 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 Wed Aug 18 15:54:59 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 18 Aug 2010 06:54:59 -0700 Subject: [csw-maintainers] need of an additional directory tree under /opt/csw In-Reply-To: References: <55E6A7D0-F196-4A4A-ADBA-6552BB9EBE94@opencsw.org> Message-ID: On Tuesday, August 17, 2010, Dom wrote: > Well, > > these are tough questions for me. As Peter mentioned, having well-identified packages would make life easier for other maintainers who have similar dependencies. To the question "why" I need gcc/g++ compiled libraries, ... actually, I for one, was not questioning "why" at all :-) I was asking what kind of mods to wxwidgets will be required. I like Dagobert's proposal in general. I'm just not sure whether it will meet your needs for wxwidgets_gcc ? From dam at opencsw.org Wed Aug 18 15:59:47 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 18 Aug 2010 15:59:47 +0200 Subject: [csw-maintainers] need of an additional directory tree under /opt/csw In-Reply-To: References: <55E6A7D0-F196-4A4A-ADBA-6552BB9EBE94@opencsw.org> Message-ID: Hi Phil, Am 18.08.2010 um 15:54 schrieb Philip Brown: > On Tuesday, August 17, 2010, Dom wrote: >> these are tough questions for me. As Peter mentioned, having well- >> identified packages would make life easier for other maintainers >> who have similar dependencies. To the question "why" I need gcc/g++ >> compiled libraries, ... > > actually, I for one, was not questioning "why" at all :-) > I was asking what kind of mods to wxwidgets will be required. The problem is not wxwidgets, the problem is that kicad needs to be compiled with gcc as it has many many gcc-isms and upstream supports gcc only and rejects fixes towards more compatibility, so patching is pretty fruitless. And as c++-mangling is different between gcc and Sun Studio you need to have all libs needed by kicad also as gcc-versions. This includes wxwidgets here. Best regards -- Dago From pfelecan at opencsw.org Wed Aug 18 16:16:15 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 18 Aug 2010 16:16:15 +0200 Subject: [csw-maintainers] need of an additional directory tree under /opt/csw In-Reply-To: <3954B48B-A6CF-4694-94E7-D890673CB596@opencsw.org> (Dagobert Michelsen's message of "Wed, 18 Aug 2010 14:53:56 +0200") References: <55E6A7D0-F196-4A4A-ADBA-6552BB9EBE94@opencsw.org> <3954B48B-A6CF-4694-94E7-D890673CB596@opencsw.org> Message-ID: Dagobert Michelsen writes: >> BTW: the incoming Kicad package I'll release will NOT include the >> "dev" version of WxWidget 2.8.11 I had to provide internally. So >> will it be for Erlang. Funny is that Kicad depends on Erlang, and >> both depend on WxWidgets. And I'll have the same case with "boost", >> unfortunatly. >> >> But this still remains subject to change... for the next versions ! > > I think it would be cleanest to have a convention for gcc-compiled c++ > libs, > like > CSWlib is the Sun Studio version > CSWlib-gcc is the gcc compiled version > Then there should also be a standard place for these libs. I propose > /opt/csw/lib/gcc/mylib.so > /opt/csw/lib/gcc/amd64/mylib.so > /opt/csw/lib/gcc/64 -> (amd64|sparcv9) > These links should be delivered by CSWlibgcccommon. > > Thoughts? +1 this is something that I yearn for since the inception of the project -- Peter From dam at opencsw.org Wed Aug 18 16:46:07 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 18 Aug 2010 16:46:07 +0200 Subject: [csw-maintainers] need of an additional directory tree under /opt/csw In-Reply-To: References: <55E6A7D0-F196-4A4A-ADBA-6552BB9EBE94@opencsw.org> <3954B48B-A6CF-4694-94E7-D890673CB596@opencsw.org> Message-ID: <7E2151E1-62A8-4327-9238-FFF2BABF6BB0@opencsw.org> Hi Peter, Am 18.08.2010 um 16:16 schrieb Peter FELECAN: > Dagobert Michelsen writes: > >>> BTW: the incoming Kicad package I'll release will NOT include the >>> "dev" version of WxWidget 2.8.11 I had to provide internally. So >>> will it be for Erlang. Funny is that Kicad depends on Erlang, and >>> both depend on WxWidgets. And I'll have the same case with "boost", >>> unfortunatly. >>> >>> But this still remains subject to change... for the next versions ! >> >> I think it would be cleanest to have a convention for gcc-compiled c >> ++ >> libs, >> like >> CSWlib is the Sun Studio version >> CSWlib-gcc is the gcc compiled version >> Then there should also be a standard place for these libs. I propose >> /opt/csw/lib/gcc/mylib.so >> /opt/csw/lib/gcc/amd64/mylib.so >> /opt/csw/lib/gcc/64 -> (amd64|sparcv9) >> These links should be delivered by CSWlibgcccommon. >> >> Thoughts? > > +1 this is something that I yearn for since the inception of the > project Ok then, but I would recommend adding gcc-compiled libraries just for stuff needed by other binaries and not start duplicating the whole c++ libstack for g++ unconditionally. Is the directory layout settled then? I would then add GAR support for it to automatically set all pathes right when compiling with g++. Best regards -- Dago From pfelecan at opencsw.org Wed Aug 18 19:37:21 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 18 Aug 2010 19:37:21 +0200 Subject: [csw-maintainers] need of an additional directory tree under /opt/csw In-Reply-To: <7E2151E1-62A8-4327-9238-FFF2BABF6BB0@opencsw.org> (Dagobert Michelsen's message of "Wed, 18 Aug 2010 16:46:07 +0200") References: <55E6A7D0-F196-4A4A-ADBA-6552BB9EBE94@opencsw.org> <3954B48B-A6CF-4694-94E7-D890673CB596@opencsw.org> <7E2151E1-62A8-4327-9238-FFF2BABF6BB0@opencsw.org> Message-ID: Dagobert Michelsen writes: > Ok then, but I would recommend adding gcc-compiled libraries just for > stuff needed by other binaries and not start duplicating the whole c++ > libstack for g++ unconditionally. Agreed. Only on a necessity basis. > Is the directory layout settled then? I would then add GAR support for > it to automatically set all pathes right when compiling with g++. For me it's settled. Thank you. -- Peter From dam at opencsw.org Wed Aug 18 22:42:10 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 18 Aug 2010 22:42:10 +0200 Subject: [csw-maintainers] public_html support on the buildfarm Message-ID: <02ED3340-BE85-488F-B899-A21751F7321E@opencsw.org> Hi, I just configured that /home//public_html/ is accessible via http://buildfarm.opencsw.org/~/ You can best use it to post material for upstream bug reports or to try out the new pkgbrowser from Maciej until it is fully integrated. Have fun! -- Dago From dam at opencsw.org Wed Aug 18 22:48:33 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 18 Aug 2010 22:48:33 +0200 Subject: [csw-maintainers] Preliminary package reviews In-Reply-To: References: <5F603545-B14D-4FC1-8D71-96944E4FB3A9@opencsw.org> <433348D5-5DC1-43BB-9878-98CAAFE7828C@opencsw.org> Message-ID: Hi Maciej, Am 16.08.2010 um 13:42 schrieb Maciej (Matchek) Blizinski: > Instructions how to generate HTML from your own packages: > > - check out the newest GAR source > https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/v2/ > > - run v2/bin/checkpkg against your set of packages > > v2/bin/checkpkg ... > > - calculate md5 sums of your packages, you'll need to pass them as > arguments to pkgdb > - run pkgdb gen-html and redirect the output to a file: > > v2/bin/pkgdb gen-html ... > your-file.html > > If it fails, please send me the error message. It looks mighty good. But I have a question: The checkpkg checks all the files at once. I suppose the output is cached in my home directory, so I must run pkgdb immediately after the checkpkg, right? This makes parallel execution from user "web" produce corrupt output, right? Best regards -- Dago From phil at bolthole.com Thu Aug 19 07:19:07 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 18 Aug 2010 22:19:07 -0700 Subject: [csw-maintainers] public_html support on the buildfarm In-Reply-To: <02ED3340-BE85-488F-B899-A21751F7321E@opencsw.org> References: <02ED3340-BE85-488F-B899-A21751F7321E@opencsw.org> Message-ID: why aren't we enabling this sort of thing on the main site, or using wiki ? buildfarm seems an odd place to me On Wednesday, August 18, 2010, Dagobert Michelsen wrote: > Hi, > > I just configured that > ?/home//public_html/ > is accessible via > ?http://buildfarm.opencsw.org/~/ > > You can best use it to post material for upstream bug reports or > to try out the new pkgbrowser from Maciej until it is fully > integrated. > > > Have fun! > > ?-- Dago > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From dam at opencsw.org Thu Aug 19 08:48:42 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 19 Aug 2010 08:48:42 +0200 Subject: [csw-maintainers] public_html support on the buildfarm In-Reply-To: References: <02ED3340-BE85-488F-B899-A21751F7321E@opencsw.org> Message-ID: <14741169-9CC1-4FE9-AC2E-0909D92C9AE1@opencsw.org> Hi Phil, Am 19.08.2010 um 07:19 schrieb Philip Brown: > why aren't we enabling this sort of thing on the main site, or using > wiki ? > buildfarm seems an odd place to me The motivation was to have a place to easily put html files generated by Maciejs pkgdb html checkpkg browser. But I also see use to provide larger files to aid bug reports or something. And the file reside on the buildfarm, so the location is quite natural. To have something like http://www.opencsw.org/~ with a personal page editable by the maintainer would of course also be useful, but is another feature with another usecase. William? Best regards -- Dago From dam at opencsw.org Thu Aug 19 13:04:48 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 19 Aug 2010 13:04:48 +0200 Subject: [csw-maintainers] Problem with the buildfarm disk array Message-ID: <73800BF9-DF88-45ED-9387-9DBC1FBD091E@opencsw.org> Hi, I am having a problem with the storage array connected to the buildfarm machine, which currently hangs the machine. I am working on it. Sorry for the inconvenience -- Dago From dam at opencsw.org Thu Aug 19 13:55:33 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 19 Aug 2010 13:55:33 +0200 Subject: [csw-maintainers] Update: Problem with the buildfarm disk array In-Reply-To: <73800BF9-DF88-45ED-9387-9DBC1FBD091E@opencsw.org> References: <73800BF9-DF88-45ED-9387-9DBC1FBD091E@opencsw.org> Message-ID: <8851E2B2-5CA1-4004-A1C3-A0471AF98A42@opencsw.org> Fellow maintainers, Am 19.08.2010 um 13:04 schrieb Dagobert Michelsen: > I am having a problem with the storage array connected to the > buildfarm machine, which currently hangs the machine. I am > working on it. The buildfarm should now be fully usable again (apart from the heavy disk usage due to resilvering of the replacement disks which may take a day). Please let me know if you see anything suspicous. Best regards -- Dago From dam at opencsw.org Thu Aug 19 15:15:40 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 19 Aug 2010 15:15:40 +0200 Subject: [csw-maintainers] comments on camp "wave", solaris 9 vs 10, etc In-Reply-To: References: Message-ID: Hi Phil, Am 16.08.2010 um 17:54 schrieb Philip Brown: > I've been catching up on the "wave" based notes of the summer camp > sessions @ > https://wave.google.com/wave/waveref/googlewave.com/w+0tu9vv7tA > (thanks for putting that up, guys!) > > I wanted to mention, that I had ALREADY suggested to William (months > ago), that, given the extreme difficulty of building the latest > firefox under solaris, I would be fine if he did just 3.0 for solaris > 9 (since that is already "done"), and then 3.6+, for solaris 10. > The only remaining request there being that he recompiles 3.0 against > the new "sun x11" based gtk, etc. This is good. I will write up the requests resulting from the discussion in the wave against the board soon. > I am okay with this being a general principle also. If there is > EXTREME effort required to get something compiled on sol9, but it's an > easy compile on sol10, then the sol9 version can be somewhat orphaned. > My sticking point, is that a maintainer should at least put in *some* > effort to compile on sol9, and attempt some amount of patching. And if > they get stuck or out of their depth, they should request help. > "I cant get it to work" is not the same thing as "it cant be > done"[without extreme effort]. Noone is an expert in everything. Let's > work together! Yes, that's the point. But: If they request help and nobody is interested in doing the extra work it should be ok to release the built packages. Best regards -- Dago From dam at opencsw.org Thu Aug 19 15:19:31 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 19 Aug 2010 15:19:31 +0200 Subject: [csw-maintainers] NFS-style /opt/csw, and zfs root, beadm, In-Reply-To: References: Message-ID: <7E97109C-4B5F-4D80-8BB2-B791EB4254C7@opencsw.org> Ho Phil, Am 17.08.2010 um 02:20 schrieb Philip Brown: > Among the other things of interest I read from the summer camp > minutes, I read with interest, the discussion on /opt/csw, and > handling it in NFS-clean ways, etc. > > An additional point in its favour that I just discovered, relates to > having a zfs root, and solaris's new, configurable "boot > environments". > (which work even in regular Solaris, since MU8 I think) This is different as configuration files from /etc are synchronized via the synclist during BE activation. The problem hence doesn't exist for BEs. Best regards -- Dago From pfelecan at opencsw.org Thu Aug 19 16:54:00 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 19 Aug 2010 16:54:00 +0200 Subject: [csw-maintainers] comments on camp "wave", solaris 9 vs 10, etc In-Reply-To: (Dagobert Michelsen's message of "Thu, 19 Aug 2010 15:15:40 +0200") References: Message-ID: Dagobert Michelsen writes: >> I am okay with this being a general principle also. If there is >> EXTREME effort required to get something compiled on sol9, but it's an >> easy compile on sol10, then the sol9 version can be somewhat orphaned. >> My sticking point, is that a maintainer should at least put in *some* >> effort to compile on sol9, and attempt some amount of patching. And if >> they get stuck or out of their depth, they should request help. >> "I cant get it to work" is not the same thing as "it cant be >> done"[without extreme effort]. Noone is an expert in everything. Let's >> work together! > > Yes, that's the point. But: If they request help and nobody is > interested in doing the extra work it should be ok to release > the built packages. The proposition made at the summer camp was: - to let the maintainer valuate the effort and decide if he has the resources to accomplish the packaging for Solaris 10 and/or Solaris 9; nobody else can judge his perception of difficulty and the availability of time for that. - if the maintainers *decides* that the effort is to important, he can orphan the package on Solaris 9; this bring us to a situation when somebody can take up the orphaned package and have 2 different maintainers -- Peter From phil at bolthole.com Thu Aug 19 17:27:30 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 19 Aug 2010 08:27:30 -0700 Subject: [csw-maintainers] NFS-style /opt/csw, and zfs root, beadm, In-Reply-To: <7E97109C-4B5F-4D80-8BB2-B791EB4254C7@opencsw.org> References: <7E97109C-4B5F-4D80-8BB2-B791EB4254C7@opencsw.org> Message-ID: On Thursday, August 19, 2010, Dagobert Michelsen wrote: > > > This is different as configuration files from /etc are synchronized > via the synclist during BE activation. synced at initial creation, yes however, after that point they stay separate. That is one of the primary purposes of BEs separation, after all :) changes in one /etc will not be duplicated in other current BEs. whether that change be done manually, or via postinstall of a new csw pkg. I have tested this From dam at opencsw.org Thu Aug 19 17:30:55 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 19 Aug 2010 17:30:55 +0200 Subject: [csw-maintainers] Final call: /home/testing is deprecated Message-ID: Hi, as we we have discussed in Paris /home/testing will go. Please use /home/experimental/ instead. If you need things from testing you can find them in the archive/ subdirectory. Write access to the directories have been removed. Best regards -- Dago From phil at bolthole.com Thu Aug 19 17:33:04 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 19 Aug 2010 08:33:04 -0700 Subject: [csw-maintainers] comments on camp "wave", solaris 9 vs 10, etc In-Reply-To: References: Message-ID: On Thursday, August 19, 2010, Peter FELECAN wrote: ... > - if the maintainers *decides* that the effort is to important, he can > ?orphan the package on Solaris 9; this bring us to a situation when > ?somebody can take up the orphaned package and have 2 different > ?maintainers > this would make sense in cases where the package has actual different functionality at runtime. however if there is no difference, seems to me the person willing to deal with the sol9 package is then producing a single package that works for both, and should then get to be the sole maintainer of the package From dam at opencsw.org Thu Aug 19 17:33:21 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 19 Aug 2010 17:33:21 +0200 Subject: [csw-maintainers] NFS-style /opt/csw, and zfs root, beadm, In-Reply-To: References: <7E97109C-4B5F-4D80-8BB2-B791EB4254C7@opencsw.org> Message-ID: <857603C7-4DD9-41EE-8375-668D8CFADCD3@opencsw.org> Hi Phil, Am 19.08.2010 um 17:27 schrieb Philip Brown: > On Thursday, August 19, 2010, Dagobert Michelsen > wrote: >> This is different as configuration files from /etc are synchronized >> via the synclist during BE activation. > > synced at initial creation, yes > however, after that point they stay separate. > That is one of the primary purposes of BEs separation, after all :) > changes in one /etc will not be duplicated in other current BEs. > whether that change be done manually, or via postinstall of a new csw > pkg. > > I have tested this. They will be synced on BE activation. You must adjust the synclist with your specific configuration files you want to have synced. This is the way it is intended by Sun. Adding a third way of syncing or moving configuration files is IMHO counterproductive. Best regards -- Dago From pfelecan at opencsw.org Thu Aug 19 20:18:52 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 19 Aug 2010 20:18:52 +0200 Subject: [csw-maintainers] comments on camp "wave", solaris 9 vs 10, etc In-Reply-To: (Philip Brown's message of "Thu, 19 Aug 2010 08:33:04 -0700") References: Message-ID: Philip Brown writes: > On Thursday, August 19, 2010, Peter FELECAN wrote: > ... > > >> - if the maintainers *decides* that the effort is to important, he can >> ?orphan the package on Solaris 9; this bring us to a situation when >> ?somebody can take up the orphaned package and have 2 different >> ?maintainers >> > > > this would make sense in cases where the package has actual different > functionality at runtime. however if there is no difference, seems to > me the person willing to deal with the sol9 package is then producing > a single package that works for both, and should then get to be the > sole maintainer of the package Not always. Take the example of Firefox, there is no functional identity for what can be packaged for 9 or 10. But you're right, if, for example, I cannot make work avidemux on Solaris 9, I decide to provide only a Solaris 10 package, however, if later somebody does package the same version and with the same features for Solaris 9 he can negotiate with me to take over, or to supply the patches for the changes. What we discussed is that the initial maintainer is the *only* person who can judge if he can or cannot deliver initially. If you're afraid of laziness, don't forget that what we are doing is always under the scrutiny of the the community, that serves as an informal peer review. -- Peter From william at wbonnet.net Fri Aug 20 02:16:41 2010 From: william at wbonnet.net (William Bonnet) Date: Fri, 20 Aug 2010 02:16:41 +0200 Subject: [csw-maintainers] Spam from the pkgrequest form In-Reply-To: <4C6A62E1.9050406@wbonnet.net> References: <4C6A62E1.9050406@wbonnet.net> Message-ID: <4C6DC969.7000908@wbonnet.net> Hi I have added a captcha check on the request package form. The form uses reCaptcha from code.google.com :) Feedbacks and comments are welcome. I'll improve slightly the look of "error" output on this page during the week end. Tomorrow i'll add the maintainer application form. cheers W. From phil at bolthole.com Fri Aug 20 19:57:06 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 20 Aug 2010 10:57:06 -0700 Subject: [csw-maintainers] NFS-style /opt/csw, and zfs root, beadm, In-Reply-To: <857603C7-4DD9-41EE-8375-668D8CFADCD3@opencsw.org> References: <7E97109C-4B5F-4D80-8BB2-B791EB4254C7@opencsw.org> <857603C7-4DD9-41EE-8375-668D8CFADCD3@opencsw.org> Message-ID: On 8/19/10, Dagobert Michelsen wrote: > Hi Phil, *wave* >... > They will be synced on BE activation. You must adjust the synclist with > your specific configuration files you want to have synced. This is the > way it is intended by Sun. Adding a third way of syncing or moving > configuration files is IMHO counterproductive. I think what you are saying is, "IF you go through some extra-special setup steps.. which we dont have documented for you... then your csw configs in /etc will be copied over between BE environments". I dont think thats very user-friendly :-/ And I actually think thats against the general principle of multiple BEs. In principle, BEs are supposed to keep separate /etc, to guard/test against messups in config files living in /etc! So, my original premise is still mostly true, with minor clarification. I'll resummarize it here, with the needed clarification in brackets: ======= [By default], if you install CSW packages in one BE, into a filesystem such as /opt or /opt/csw, which is mounted across multiple pre-existing BEs as-is, then the experienced behaviour for the new/updated CSW package in the "other BEs" will be close to identical to that of an NFS-mounted /opt/csw. There will be no automated update of /etc/opt, or pre/post scripts, or even class action scripts, run in the other BEs. ======== I will additionally point out, that, depending on how different the other BEs are, it could be a horrible mistake to just automatically copy script-generated /etc/opt files from one BE to another. They could potentially be as different as any two zones could be! One could be designated a "server" BE, and one could be a non-server BE, for example. From skayser at opencsw.org Sun Aug 22 22:26:31 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 22 Aug 2010 22:26:31 +0200 Subject: [csw-maintainers] CSW/GAR maintainer world map via Ohloh (once again) Message-ID: <4C7187F7.9010508@opencsw.org> Greetings, time has passed, people have joined from various places and I would like to take the opportunity to ask everyone who hasn't done so yet to register on Ohloh in order to populate the OpenCSW contributors world map. http://www.ohloh.net/p/opencsw/map This gives us and everyone who cares a heart warming overview on where from all over the globe people contribute to OpenCSW. In particular, I am going to give a talk about OpenCSW to our Munich OpenSolaris User Group this Thursday and it would be nice to see as many contributing faces as possible on the map. :) For instructions please see the forwarded email and don't hesitate to ask me in case of any troubles. Thanks for your time! Sebastian @board: Would you mind adding (optional) Ohloh signup instructions to the new maintainers welcome email. -------------- next part -------------- An embedded message was scrubbed... From: Sebastian Kayser Subject: [csw-maintainers] CSW/GAR maintainer world map via Ohloh Date: Thu, 27 Aug 2009 10:59:20 +0200 Size: 4152 URL: From phil at bolthole.com Mon Aug 23 06:10:41 2010 From: phil at bolthole.com (Philip Brown) Date: Sun, 22 Aug 2010 21:10:41 -0700 Subject: [csw-maintainers] feedback for csw script needed: updated cswpreserveconf Message-ID: hi folks, I'm planning to do a long planned, and also long overdue update to cswpreserveconf. I'd like it to support copying the sample conf files from (whereever they are) to (whatever dir is specified) at the moment, I'm liking the magic string "CSWDESTDIR=/path/here" if that kind of string is doing anywhere in the file to be copied, it will copy to that directory instead of the same directory the file is in. This allows for sample conf files to be shipped in /opt/csw/etc (or even elsewhere such as /opt/csw/share/doc/???) but then be deployed to /etc/opt/csw this would make the lives of admins easier in the situation of shared /opt/csw mentioned, yet still preserve the twofold nice handling of - automated removals of default files - automated preservation if the config files are altered by the site admin any comments or questions? From dam at opencsw.org Mon Aug 23 10:09:34 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 23 Aug 2010 10:09:34 +0200 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs rssh In-Reply-To: References: <201008211131.o7LBVwPn011081@login.bo.opencsw.org> Message-ID: <0F69B07E-59D3-41A5-B459-8F914AD80AAC@opencsw.org> Hi Phil, Am 23.08.2010 um 05:48 schrieb Philip Brown: > On Saturday, August 21, 2010, Dagobert Michelsen > wrote: >> Hi Phil, >> >> Am 20.08.2010 um 20:27 schrieb Philip Brown: >> >> Why did you change the existing configuration files from /opt/csw/etc >> to /etc/opt/csw? >> >> >> Umh, because it is the standard at the moment? > > (after doing some reading) > given that the configfile would appear to be purposes as a machine > specific file, I agree with the change in location from the prior > package. > however, it would be more friendly to assorted users to have some kind > of reference to it under /opt/csw. > > sorry for the delay in reply.. I had meant to provide an updated > version of cswpreserveconf, that would allow for copying from /opt to > /etc/opt instead of just the same dir, bit got sidetracked :-/ > would you be willing to wait a bit and use that? I should have it in a > few days max , after a bit of discussion on the maintainers list Sure, no problem. We have given this issue some more thought during the Summercamp, please see the wave day 1 "Supported Setups" for some discussion input on this. Some thoughts from me on this topic in general: - We may have the standard-template for configuration files in /opt/ csw/... which is then copied to /etc/opt/csw/ by cswpreserveconf CAS - The template file in /opt/csw should NOT be under /opt/csw/etc/ because it gives the impression it needs to be copied to the same directory. Maybe /opt/csw/etc/etc-opt-csw-templates ?? - It should still be possible to have both the template and the modified file in /etc/opt/csw for easy diff'ing. Best regards -- Dago From dam at opencsw.org Mon Aug 23 11:29:28 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 23 Aug 2010 11:29:28 +0200 Subject: [csw-maintainers] unixodbc-2.3.0 is available for testing In-Reply-To: References: Message-ID: Hi Maciej, Am 28.07.2010 um 00:50 schrieb Maciej (Matchek) Blizinski: > Are there any unixodbc users here? Version 2.3.0 (updated from > 2.2.14) is available for testing: > > http://mirror.opencsw.org/experimental.html#maciej I just installed it and have some notes: - The package provides isaexec-binaries for both 32/64 bit which is AFAIK not really necessary. - This is especially true for odbc_config, which now outputs always the 64 bit flags on a 64 bit system. GAR has special handling for *-config binaries to be never isaexec'ed, but here it call non-standard with an underscore instead of a hyphen so default handling doesn't work: gar.pkg.mk:_ISAEXEC_EXCLUDE_FILES = $(bindir)/%-config $(bindir)/%/ %-config - You could use MIGRATE_FILES = odbc.ini odbcinst.ini ODBCDataSources instead of use a hardwired cswmigrateconf from files/ - When using SAMPLECONF the renaming of * to *.CSW is done automatically, no need to do this manually in postinstall - The shipped .ini files are empty. It would be nice to keep the ones previously shipped with examples for all supported databases. APR-Util needs a working unixodbc for his tests, so I currently building sqliteodbc as simplest possible test. Best regards -- Dago From dam at opencsw.org Mon Aug 23 21:48:43 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 23 Aug 2010 21:48:43 +0200 Subject: [csw-maintainers] New feature: automatic checkpkg reports and browsable packages References: <3DCB6443-4E86-41D0-B7A7-D4E3E6384560@baltic-online.de> Message-ID: Hi, the first things we talked about in Paris come to life: Maciejs pkgdb checpkg HTML generator has been integrated into experimental. That means if you go to http://mirror.opencsw.org/experimental.html there is now a link "Browse the checkpkg results" with the relevant metadata for the packages in the experimental project. The reports are generated automatically on demand every 3 hours. In addition to Maciejs fabulous tool I added two minor features: 1. You can browse the Trac repository for a package immediately 2. You can browse into the files of each package immediately The files are linked verbatim at the moment, maybe someone has a nifty idea on how to view them on the web nicely formatted depending on mimetype? William: Would it be possible to add the Trac browser link on the package page on the website and also make the "view files" page per-file browsable as this page? Best regards -- Dago From dam at opencsw.org Mon Aug 23 21:49:50 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 23 Aug 2010 21:49:50 +0200 Subject: [csw-maintainers] RFC: idea to unify 32/64 bit headers References: Message-ID: <8DB9CB2C-0B8E-44B5-86F2-CE2568CA53CA@opencsw.org> Hi, sometime in the past we encountered that the includes for curl are dependent for 32/64 bit. The solution at that time was to insert a "branch-include" which basically took the 32- and 64-bit version, renamed them and conditionally included each one depending if __amd64 or __sparcv9 was set. Now Rupert had problems building apr/apr-util/apache with 32/64 bit and I had a look. apr also the issues with 32/64 dependent includes. As there were some other issues with the OpenCSW package I looked at the manifest from OSOL for inspiration and encountered something really cool. http://cvs.opensolaris.org/source/xref/sfw/usr/src/cmd/apr/apr-1.3/Makefile.sfw If you do diff -D __amd64 curlbuild-32.h curlbuild-64.h It will generate an include file where the differences only in the second file will be shielded by C preprocessor ifdefs with the string after the -D. I like this that much that I am really thinking of making this fully automatic: On merge GAR currently just copies over the default (32 bit) modulation. I could just merge over the diff'ed 32/64 between the default 32 bit ISA and 64 bit ISA easily making these special things obsolete. Thoughts? Best regard -- Dago From phil at bolthole.com Mon Aug 23 22:02:03 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 23 Aug 2010 13:02:03 -0700 Subject: [csw-maintainers] RFC: idea to unify 32/64 bit headers In-Reply-To: <8DB9CB2C-0B8E-44B5-86F2-CE2568CA53CA@opencsw.org> References: <8DB9CB2C-0B8E-44B5-86F2-CE2568CA53CA@opencsw.org> Message-ID: Sounds like a nice idea. On Mon, Aug 23, 2010 at 12:49 PM, Dagobert Michelsen wrote: > > If you do > ?diff -D __amd64 curlbuild-32.h curlbuild-64.h > It will generate an include file where the differences only in the second > file will be shielded by C preprocessor ifdefs with the string after the -D. > I like this that much that I am really thinking of making this fully > automatic: On merge GAR currently just copies over the default (32 bit) > modulation. I could just merge over the diff'ed 32/64 between the > default 32 bit ISA and 64 bit ISA easily making these special things > obsolete. > > Thoughts? > From phil at bolthole.com Tue Aug 24 00:43:47 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 23 Aug 2010 15:43:47 -0700 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs rssh In-Reply-To: <0F69B07E-59D3-41A5-B459-8F914AD80AAC@opencsw.org> References: <201008211131.o7LBVwPn011081@login.bo.opencsw.org> <0F69B07E-59D3-41A5-B459-8F914AD80AAC@opencsw.org> Message-ID: On Mon, Aug 23, 2010 at 1:09 AM, Dagobert Michelsen wrote: > >> >> sorry for the delay in reply.. I had meant to provide an updated >> version of cswpreserveconf, that would allow for copying from /opt to >> /etc/opt instead of just the same dir, bit got sidetracked :-/ >> would you be willing to wait a bit and use that? I should have it in a >> few days max , after a bit of discussion on the maintainers list > > Sure, no problem. We have given this issue some more thought during the > Summercamp, please see the wave day 1 "Supported Setups" for some > discussion input on this. I already read through it, and agreed with most of what was said. Incidentally, I tested and committed the changes into gar trunk for cswclassutils, and was going to put a test package out for folks... but now it's whining about stuff and I have no idea how to fix it. Oddly, it was perfectly happy to create "UNCOMMITTED" packages. but when I committed my changes, THEN it started to whine and blow up. So I give up. From bwalton at opencsw.org Tue Aug 24 02:07:00 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 23 Aug 2010 20:07:00 -0400 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs rssh In-Reply-To: References: <201008211131.o7LBVwPn011081@login.bo.opencsw.org> <0F69B07E-59D3-41A5-B459-8F914AD80AAC@opencsw.org> Message-ID: <1282608236-sup-5899@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Aug 23 18:43:47 -0400 2010: > Incidentally, I tested and committed the changes into gar trunk for > cswclassutils, and was going to put a test package out for folks... > but now it's whining about stuff and I have no idea how to fix it. gmake makesums; svn ci -m 'cswclassutils blah blah' It was the makesums bit that stopped things from working[1]. It may have worked prior to your commit if you hadn't done a `gmake clean|spotless` in the meantime (eg: the cookie was already cached for the makesums step). We had previously decided to split this package into per-classutil packages with classutils itself depending on all the sub-packages...I guess now is the time to do that? HTH. -Ben [1] I was going to rip the makesums stuff out, but it proved to be a much more invasive change to GAR than I'd expected and testing it stalled. -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Tue Aug 24 03:45:47 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 23 Aug 2010 18:45:47 -0700 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs rssh In-Reply-To: <1282608236-sup-5899@pinkfloyd.chass.utoronto.ca> References: <201008211131.o7LBVwPn011081@login.bo.opencsw.org> <0F69B07E-59D3-41A5-B459-8F914AD80AAC@opencsw.org> <1282608236-sup-5899@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Aug 23, 2010 at 5:07 PM, Ben Walton wrote: > Excerpts from Philip Brown's message of Mon Aug 23 18:43:47 -0400 2010: > >> Incidentally, I tested and committed the changes into gar trunk for >> cswclassutils, and was going to put a test package out for folks... >> but now it's whining about stuff and I have no idea how to fix it. > > gmake makesums; > > svn ci -m 'cswclassutils blah blah' > > It was the makesums bit that stopped things from working[1]. well, it initially whined about that. then I did the make makesums. then it built the package.. but it was UNCOMMITTED... then I tried the build again... then it blew up, with some very unhelpful messages. > ?It may > have worked prior to your commit if you hadn't done a `gmake > clean|spotless` in the meantime i did not do that. > We had previously decided to split this package into per-classutil > packages with classutils itself depending on all the sub-packages...I > guess now is the time to do that? possibly. there may be a little bit of clumping granularity that makes sense, but I'm not entirely sure. Maybe *conf* stuff.. and then *etc* stuff, and then misc? I didnt realize we had quite so many scripts (12!) when I first suggested the split. Do we really want a separate package per script? (maybe we do, I dunno) > [1] I was going to rip the makesums stuff out, but it proved to be a > ? ?much more invasive change to GAR than I'd expected and testing it > ? ?stalled. Nuts. I was wondering why it was still there even after I did an update of gar tree. How about just changing the "verify checksums" bit to always return true, for now? From dam at opencsw.org Tue Aug 24 11:16:48 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 24 Aug 2010 11:16:48 +0200 Subject: [csw-maintainers] GAR and checksums In-Reply-To: <1282608236-sup-5899@pinkfloyd.chass.utoronto.ca> References: <201008211131.o7LBVwPn011081@login.bo.opencsw.org> <0F69B07E-59D3-41A5-B459-8F914AD80AAC@opencsw.org> <1282608236-sup-5899@pinkfloyd.chass.utoronto.ca> Message-ID: <0DE2B0F0-7B96-43E1-B0E4-B89039235771@opencsw.org> Hi Ben, Am 24.08.2010 um 02:07 schrieb Ben Walton: > [1] I was going to rip the makesums stuff out, but it proved to be a > much more invasive change to GAR than I'd expected and testing it > stalled. Please stand by. I have changed my mind about taking checksums out: there are a couple of packages which rely on upstream packages without version number. To ensure that the file which goes into the package is the right one the checksum is the only check available. I suggest adding a more meaningful error message like The checksum of the file abc-1.2.tar.gz does not match the checksum in the repository. Please verify the correctness of the download or update the checksum file with gmake makesums Best regards -- Dago From phil at bolthole.com Tue Aug 24 15:09:18 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 24 Aug 2010 06:09:18 -0700 Subject: [csw-maintainers] GAR and checksums In-Reply-To: <0DE2B0F0-7B96-43E1-B0E4-B89039235771@opencsw.org> References: <201008211131.o7LBVwPn011081@login.bo.opencsw.org> <0F69B07E-59D3-41A5-B459-8F914AD80AAC@opencsw.org> <1282608236-sup-5899@pinkfloyd.chass.utoronto.ca> <0DE2B0F0-7B96-43E1-B0E4-B89039235771@opencsw.org> Message-ID: On Tuesday, August 24, 2010, Dagobert Michelsen wrote: > Hi Ben, > > > Please stand by. I have changed my mind about taking checksums out: > there are a couple of packages which rely on upstream packages > without version number. To ensure that the file which goes into > the package is the right one the checksum is the only check > available. thats fine an all, for "external" files... but at the same time, it doesn't make much sense to be running checksums on files which are kept in our subversion repository From bwalton at opencsw.org Tue Aug 24 15:19:58 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 24 Aug 2010 09:19:58 -0400 Subject: [csw-maintainers] GAR and checksums In-Reply-To: References: <201008211131.o7LBVwPn011081@login.bo.opencsw.org> <0F69B07E-59D3-41A5-B459-8F914AD80AAC@opencsw.org> <1282608236-sup-5899@pinkfloyd.chass.utoronto.ca> <0DE2B0F0-7B96-43E1-B0E4-B89039235771@opencsw.org> Message-ID: <1282655950-sup-9209@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue Aug 24 09:09:18 -0400 2010: > thats fine an all, for "external" files... but at the same time, it > doesn't make much sense to be running checksums on files which are > kept in our subversion repository This would be an easy fix, as we'd simply drop $(PATCHFILES) from the $(CHECKSUMFILES) variable, leaving only the tarballs/source files... Dago? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Tue Aug 24 15:31:05 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 24 Aug 2010 15:31:05 +0200 Subject: [csw-maintainers] GAR and checksums In-Reply-To: <1282655950-sup-9209@pinkfloyd.chass.utoronto.ca> References: <201008211131.o7LBVwPn011081@login.bo.opencsw.org> <0F69B07E-59D3-41A5-B459-8F914AD80AAC@opencsw.org> <1282608236-sup-5899@pinkfloyd.chass.utoronto.ca> <0DE2B0F0-7B96-43E1-B0E4-B89039235771@opencsw.org> <1282655950-sup-9209@pinkfloyd.chass.utoronto.ca> Message-ID: <03D3F858-50B4-4736-9115-3CA014BEF9FD@opencsw.org> Hi Ben, Am 24.08.2010 um 15:19 schrieb Ben Walton: > Excerpts from Philip Brown's message of Tue Aug 24 09:09:18 -0400 > 2010: >> thats fine an all, for "external" files... but at the same time, it >> doesn't make much sense to be running checksums on files which are >> kept in our subversion repository > > This would be an easy fix, as we'd simply drop $(PATCHFILES) from the > $(CHECKSUMFILES) variable, leaving only the tarballs/source files... > > Dago? That would mean two changes: 1. Adjust CHECKSUM_TARGETS to no longer contain PATCHFILES in gar.mk:CHECKSUM_TARGETS = $(addprefix checksum-,$(filter-out $ (_NOCHECKSUM) $(NOCHECKSUM),$(ALLFILES))) 2. Change the fetching of PATCHFILES to no longer look in MASTER_SITES. This is important to look only in files/. This could be done together with the long-awaited possibility to specify multiple MASTER_SITES together with DISTFILES. Some packages like the SGML packages grab lots of files from lots of MASTER_SITES. Instead of trying n x n it could be optimized to have a 1 : n relationship. Best regards -- Dago From skayser at opencsw.org Tue Aug 24 15:46:24 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 24 Aug 2010 15:46:24 +0200 Subject: [csw-maintainers] Updated postfix packages (2.7.1) in experimental/, testing appreciated In-Reply-To: <68329550-ACD6-44C8-A8BB-00392B47B6EB@opencsw.org> References: <20100817163631.GI31821@sebastiankayser.de> <20100817164959.GJ31821@sebastiankayser.de> <20100817171329.GK31821@sebastiankayser.de> <68329550-ACD6-44C8-A8BB-00392B47B6EB@opencsw.org> Message-ID: <20100824134624.GL31821@sebastiankayser.de> * Dagobert Michelsen wrote: > Am 17.08.2010 um 19:13 schrieb Sebastian Kayser: > > * Philip Brown wrote: > >> On 8/17/10, Sebastian Kayser wrote: > >>> > >>> In addition to this package I would like to provide a postfix_simple > >>> package which is a feature-stripped version without a big dependency > >>> chain. Similar to what Ihsan provides on his own [1]. > >>> > >>> Are there any objections to or thoughts on this? The GAR recipe [2] > >>> already supports building this alternative package by setting > >>> 'BUILDTYPE=simple' on the commandline, so it's just a matter of running > >>> the build twice. > >> > >> I think it's a great idea. Just please allow the two packages to > >> co-exist, rather than conflicting with each other. > >> There's more than one way to handle the layout thereof; completely > >> separate trees, or "alternatives" based binary overlays, or possibly > >> something else entirely. (lazyloading the libs, and not > >> force-depending on them?) > >> Please pick whatever method you find least offensive :-) > > > > Honestly, the postfix build recipe is already huge and if possible, I > > would like to refrain from introducing any additional complexity. > > I don't think you see how easy this really is: You already did the > hard work of adding a "switch": just add > EXTRA_MODULATORS = BUILDTYPE > MODULATIONS_BUILDTYPE = simple complex > and do add a couple of lines for alternatives switching. It is really > easy. I can do this if you want. It is even simpler than mutt, because > mutt has two different flavors with B -> A and B' -> A whereas you would > have CSWpostfix-full -> CSWpostfix with CSWpostfix containing everything > and CSWpostfix-full just the enhanced binary and extra dependencies. > > You may want to look at mutt as reference, although your case is probably > even simpler: > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/mutt/trunk/Makefile > > > What exactly are we trying to solve by not conflicting packages? > > You can't know this - I plan to auto-install all generated packages > into an extra experimental zone and conflicting packages would make > this harder than necessary. > > Additionally, with the alternatives approach you could start with > CSWpostfix and work with it. If you need more features you can > just install CSWpostfix-feature and just use the new things > without ugly deinstall - reinstall. Thanks for the input. For now, I will aim to release the package as is, i.e. no simplified package. Further down the road, making CSWpostfix a reduced package might cause hickups. What about the ppl who expect CSWpostfix to be the full featured package?. I rather thought about making the CSWpostfix the full package, and CSWpostfix-simple the reduced one. But from what I understand that shouldn't make much of a difference. Sebastian From dam at opencsw.org Tue Aug 24 15:51:14 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 24 Aug 2010 15:51:14 +0200 Subject: [csw-maintainers] Updated postfix packages (2.7.1) in experimental/, testing appreciated In-Reply-To: <20100824134624.GL31821@sebastiankayser.de> References: <20100817163631.GI31821@sebastiankayser.de> <20100817164959.GJ31821@sebastiankayser.de> <20100817171329.GK31821@sebastiankayser.de> <68329550-ACD6-44C8-A8BB-00392B47B6EB@opencsw.org> <20100824134624.GL31821@sebastiankayser.de> Message-ID: <27DCF3A4-EFE1-415D-ACC9-DD8592FA8E70@opencsw.org> Hi Sebastian, Am 24.08.2010 um 15:46 schrieb Sebastian Kayser: > Thanks for the input. For now, I will aim to release the package as > is, > i.e. no simplified package. Ok. > Further down the road, making CSWpostfix a reduced package might cause > hickups. What about the ppl who expect CSWpostfix to be the full > featured package?. I rather thought about making the CSWpostfix the > full > package, and CSWpostfix-simple the reduced one. But from what I > understand that shouldn't make much of a difference. Not really, just a thing of consistency. Best regards -- Dago From phil at bolthole.com Tue Aug 24 17:34:59 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 24 Aug 2010 08:34:59 -0700 Subject: [csw-maintainers] GAR and checksums In-Reply-To: <1282655950-sup-9209@pinkfloyd.chass.utoronto.ca> References: <201008211131.o7LBVwPn011081@login.bo.opencsw.org> <0F69B07E-59D3-41A5-B459-8F914AD80AAC@opencsw.org> <1282608236-sup-5899@pinkfloyd.chass.utoronto.ca> <0DE2B0F0-7B96-43E1-B0E4-B89039235771@opencsw.org> <1282655950-sup-9209@pinkfloyd.chass.utoronto.ca> Message-ID: On Tue, Aug 24, 2010 at 6:19 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Tue Aug 24 09:09:18 -0400 2010: > >> thats fine an all, for "external" files... but at the same time, it >> doesn't make much sense to be running checksums on files which are >> kept in our subversion repository > > This would be an easy fix, as we'd simply drop $(PATCHFILES) from the > $(CHECKSUMFILES) variable, leaving only the tarballs/source files... > Would that catch (or rather , skip!) things such as the cswclassutils files.. which are not strictly "patches", yet are not downloaded either? From bonivart at opencsw.org Wed Aug 25 09:52:46 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 25 Aug 2010 09:52:46 +0200 Subject: [csw-maintainers] Mirror signup page missing Message-ID: I'm trying to get us another Swedish mirror since the current one is run by people who don't know what they are doing. In the process I noticed that our mirror signup page mentioned on the mirror page is missing. (http://www.opencsw.org/mirror-signup mentioned on http://www.opencsw.org/get-it/mirrors) -- /peter From dam at opencsw.org Wed Aug 25 14:50:32 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 25 Aug 2010 14:50:32 +0200 Subject: [csw-maintainers] Reorganiation of webpage References: Message-ID: <2110D505-8C36-47B9-BDB6-4369CC6F4F02@opencsw.org> Hi, I gave the website some more thought. Personally I find the "Latest News" section not really useful as I have to click on it. The news should be relocated/merged with "Latest Announcements". The "Download" box occupies a lot of valuable space not used often. I recommend removing the box and renaming "Get it" to the more catchy "Download". Further I would think "Feeds" as second item in the top-bar should be moved to the right as it will be used only sporadically. One more thing: On http://www.opencsw.org/support/ the link in "If you want to immediately use our software, you can go through the quickstart documentation page" to quickstart is broken. Feedback welcome! Best regards -- Dago From bonivart at opencsw.org Wed Aug 25 15:07:37 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 25 Aug 2010 15:07:37 +0200 Subject: [csw-maintainers] Reorganiation of webpage In-Reply-To: <2110D505-8C36-47B9-BDB6-4369CC6F4F02@opencsw.org> References: <2110D505-8C36-47B9-BDB6-4369CC6F4F02@opencsw.org> Message-ID: On Wed, Aug 25, 2010 at 2:50 PM, Dagobert Michelsen wrote: > Hi, > > I gave the website some more thought. Personally I find the "Latest News" > section > not really useful as I have to click on it. The news should be > relocated/merged > with "Latest Announcements". > > The "Download" box occupies a lot of valuable space not used often. I > recommend > removing the box and renaming "Get it" to the more catchy "Download". > > Further I would think "Feeds" as second item in the top-bar should be moved > to the > right as it will be used only sporadically. > > One more thing: On http://www.opencsw.org/support/ the link in > "If you want to immediately use our software, you can go through the > quickstart > documentation page" to quickstart is broken. > > Feedback welcome! I agree with everything and want to add that the mirror signup page is missing. Maybe it would be easiest to just have a mail address there like you mentioned on IRC, e.g. mirror at opencsw.org, delivered to at least two people. -- /peter From jgoerzen at opencsw.org Thu Aug 26 00:01:46 2010 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Wed, 25 Aug 2010 15:01:46 -0700 Subject: [csw-maintainers] Updating libfaad2 and mpeg4ip In-Reply-To: References: <1280278827-sup-1945@pinkfloyd.chass.utoronto.ca> <4C6045E6.6080101@opencsw.org> <4C6BB0FF.5080701@opencsw.org> Message-ID: Hello, I took a look at xmms. I updated the GAR recipe and rebuilt new packages The packages are available in experimental/x11-reloaded: xmms-1.2.11,REV=2010.08.25-SunOS5.9-i386-CSW.pkg.gz xmms-1.2.11,REV=2010.08.25-SunOS5.9-sparc-CSW.pkg.gz The program runs except there is a problem with the opengl plugin eg: bash-3.00$ xmms ld.so.1: xmms: fatal: relocation error: file /opt/csw/lib/xmms/Visualization/libogl_spectrum.so: symbol sunOglCurrentContext: referenced symbol not found I'm not sure what is going wrong since the ./configure and build process seemed to find the right system X11 headers and libraries. And libogl_spectrum.so is finding the libraries needed during runtime: bash-3.00$ ldd /opt/csw/lib/xmms/Visualization/libogl_spectrum.so libgtk-1.2.so.0 => /opt/csw/lib/sparcv8/libgtk-1.2.so.0 libgdk-1.2.so.0 => /opt/csw/lib/sparcv8/libgdk-1.2.so.0 libgmodule-1.2.so.0 => /opt/csw/lib/sparcv8/libgmodule-1.2.so.0 libgthread-1.2.so.0 => /opt/csw/lib/sparcv8/libgthread-1.2.so.0 libglib-1.2.so.0 => /opt/csw/lib/sparcv8/libglib-1.2.so.0 libthread.so.1 => /lib/libthread.so.1 libdl.so.1 => /lib/libdl.so.1 libXi.so.5 => /usr/lib/libXi.so.5 libXext.so.0 => /usr/lib/libXext.so.0 libX11.so.4 => /usr/lib/libX11.so.4 libsocket.so.1 => /lib/libsocket.so.1 libnsl.so.1 => /lib/libnsl.so.1 libm.so.1 => /lib/libm.so.1 libGL.so.1 => /opt/csw/lib/sparcv8/libGL.so.1 libc.so.1 => /lib/libc.so.1 libmp.so.2 => /lib/libmp.so.2 libmd.so.1 => /lib/libmd.so.1 libscf.so.1 => /lib/libscf.so.1 libpthread.so.1 => /lib/libpthread.so.1 libdoor.so.1 => /lib/libdoor.so.1 libuutil.so.1 => /lib/libuutil.so.1 libgen.so.1 => /lib/libgen.so.1 libm.so.2 => /lib/libm.so.2 /usr/lib/libGL.so libXmu.so.4 => /usr/openwin/lib/libXmu.so.4 libdga.so.1 => /usr/openwin/lib/libdga.so.1 libXt.so.4 => /usr/openwin/lib/libXt.so.4 libSM.so.6 => /usr/openwin/lib/libSM.so.6 libICE.so.6 => /usr/openwin/lib/libICE.so.6 /platform/SUNW,UltraAX-i2/lib/libc_psr.so.1 /platform/SUNW,UltraAX-i2/lib/libmd_psr.so.1 Thanks, Jake From maciej at opencsw.org Thu Aug 26 08:23:05 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 26 Aug 2010 07:23:05 +0100 Subject: [csw-maintainers] Preliminary package reviews In-Reply-To: References: <5F603545-B14D-4FC1-8D71-96944E4FB3A9@opencsw.org> <433348D5-5DC1-43BB-9878-98CAAFE7828C@opencsw.org> Message-ID: No dia 18 de Agosto de 2010 21:48, Dagobert Michelsen escreveu: > It looks mighty good. But I have a question: The checkpkg checks all > the files at once. I suppose the output is cached in my home directory, > so I must run pkgdb immediately after the checkpkg, right? Not immediately, the only requirement is to run checkpkg prior to running pkgdb. The reason is that pkgdb lacks at the moment the ability to unpack files and relies on the data already being there in the database. > This makes parallel execution from user "web" produce corrupt > output, right? Once the data is in the database, there are no restrictions on parallel runs. pkgdb only reads the data, no potential for corruption there. I could imagine some form of race condition if one process was inserting thedata into the database, and the other would try to read not-yet-complete records, I haven't armored the system against it. Do I need to? Maciej From dam at opencsw.org Thu Aug 26 10:15:28 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 26 Aug 2010 10:15:28 +0200 Subject: [csw-maintainers] Preliminary package reviews In-Reply-To: References: <5F603545-B14D-4FC1-8D71-96944E4FB3A9@opencsw.org> <433348D5-5DC1-43BB-9878-98CAAFE7828C@opencsw.org> Message-ID: <34798C62-73BC-4C95-B938-D18815DDF003@opencsw.org> Hi Maciej, Am 26.08.2010 um 08:23 schrieb Maciej (Matchek) Blizinski: > No dia 18 de Agosto de 2010 21:48, Dagobert Michelsen > escreveu: >> It looks mighty good. But I have a question: The checkpkg checks all >> the files at once. I suppose the output is cached in my home >> directory, >> so I must run pkgdb immediately after the checkpkg, right? > > Not immediately, the only requirement is to run checkpkg prior to > running pkgdb. The reason is that pkgdb lacks at the moment the > ability to unpack files and relies on the data already being there in > the database. But as checkpkg locks the database I guess the packages must be tasted sequentially, right? >> This makes parallel execution from user "web" produce corrupt >> output, right? > > Once the data is in the database, there are no restrictions on > parallel runs. pkgdb only reads the data, no potential for corruption > there. I could imagine some form of race condition if one process was > inserting thedata into the database, and the other would try to read > not-yet-complete records, I haven't armored the system against it. Do > I need to? I don't think so. My current usecases look like this: - Run checkpkg against each set of packages in subdirs from experimental - run pkgdb against each checkpkg run to produce html for each experimental catalog. This is done every 3 hours on demand ATM. - next: run checkpkg against each catalog on the mirror (stable, testing, unstable, experimental on mirror/opencsw-future) http://mirror.opencsw.org/opencsw-future/ I expect these do be done daily. Best regards -- Dago From maciej at opencsw.org Thu Aug 26 10:40:38 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 26 Aug 2010 09:40:38 +0100 Subject: [csw-maintainers] Preliminary package reviews In-Reply-To: <34798C62-73BC-4C95-B938-D18815DDF003@opencsw.org> References: <5F603545-B14D-4FC1-8D71-96944E4FB3A9@opencsw.org> <433348D5-5DC1-43BB-9878-98CAAFE7828C@opencsw.org> <34798C62-73BC-4C95-B938-D18815DDF003@opencsw.org> Message-ID: No dia 26 de Agosto de 2010 09:15, Dagobert Michelsen escreveu: > Hi Maciej, > > Am 26.08.2010 um 08:23 schrieb Maciej (Matchek) Blizinski: >> Not immediately, the only requirement is to run checkpkg prior to >> running pkgdb. ?The reason is that pkgdb lacks at the moment the >> ability to unpack files and relies on the data already being there in >> the database. > > But as checkpkg locks the database I guess the packages must be > tasted sequentially, right? SQLite supports parallel reads from a database, locking occurs only you're writing to the database. I'm not sure what you mean by sequential testing -- there are some operations that must be sequential, but there are many places where parallel processing can be used. >>> This makes parallel execution from user "web" produce corrupt >>> output, right? >> >> Once the data is in the database, there are no restrictions on >> parallel runs. ?pkgdb only reads the data, no potential for corruption >> there. ?I could imagine some form of race condition if one process was >> inserting thedata into the database, and the other would try to read >> not-yet-complete records, I haven't armored the system against it. ?Do >> I need to? > > I don't think so. My current usecases look like this: > - Run checkpkg against each set of packages in subdirs from experimental > - run pkgdb against each checkpkg run to produce html for each experimental > ?catalog. This is done every 3 hours on demand ATM. > - next: run checkpkg against each catalog on the mirror (stable, testing, > ?unstable, experimental on mirror/opencsw-future) > ? ?http://mirror.opencsw.org/opencsw-future/ > ?I expect these do be done daily. You can speed up the catalog runs by saving on disk I/O and md5 calculation time by providing checkpkg with md5 sums. Here's how I'm running checkpkg against the whole catalog: d=$(date +%Y-%m-%d) c=/export/mirror/opencsw/unstable/sparc/5.9 time bin/checkpkg -s \ -M ${c}/catalog \ -d \ -o ${HOME}/current-${d}-error-tags.txt \ ${c}/*pkg* The -M flag tells checkpkg to use the information from the file named 'catalog' instead of reading the contents of the files and calculating the md5 sums. The same can be done for the experimental catalogs. From bonivart at opencsw.org Thu Aug 26 14:25:39 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 26 Aug 2010 14:25:39 +0200 Subject: [csw-maintainers] Please update pkgutil on mirror roots Message-ID: The version there now is 1.7 and there's been quite some changes since then so I would like a refresh to the packages from current (2.1). Thank you. -- /peter From william at wbonnet.net Thu Aug 26 14:38:41 2010 From: william at wbonnet.net (William Bonnet) Date: Thu, 26 Aug 2010 14:38:41 +0200 Subject: [csw-maintainers] Mirror signup page missing In-Reply-To: References: Message-ID: <4C766051.6030401@wbonnet.net> Hi Peter > I'm trying to get us another Swedish mirror since the current one is > run by people who don't know what they are doing. In the process I > noticed that our mirror signup page mentioned on the mirror page is > missing. Thanks for reporting this. I'm adding the form to the mockup cheers W. From maciej at opencsw.org Thu Aug 26 16:43:57 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 26 Aug 2010 15:43:57 +0100 Subject: [csw-maintainers] Spam from the pkgrequest form In-Reply-To: <4C6DC969.7000908@wbonnet.net> References: <4C6A62E1.9050406@wbonnet.net> <4C6DC969.7000908@wbonnet.net> Message-ID: No dia 20 de Agosto de 2010 01:16, William Bonnet escreveu: > I have added a captcha check on the request package form. The form uses > reCaptcha from code.google.com :) > > Feedbacks and comments are welcome. I'll improve slightly the look of > "error" output on this page during the week end. Tomorrow i'll add the > maintainer application form. Cool, there will be less spam now, thanks! From gmarler at opencsw.org Thu Aug 26 19:07:36 2010 From: gmarler at opencsw.org (Gordon Marler) Date: Thu, 26 Aug 2010 13:07:36 -0400 Subject: [csw-maintainers] Updated findutils package (4.4.2) in experimental/, please test Message-ID: <4C769F58.7060902@opencsw.org> findutils 4.4.2 is now being packaged under GAR, instead of manually as it was before. http://mirror.opencsw.org/experimental.html#gmarler pkgutil -thttp://mirror.opencsw.org/opencsw/experimental/gmarler -i findutils At present, testing is disabled, since 12 tests in the findutils suite, and it appears that they were never successful in the manually built package either. The failed tests are explicitly documented in the Makefile, if they are deemed important enough to fix. At least 4 of them appear to be simple permissioning errors in the testing area setup by findutils own scripts. The remaining failures have to do with the iregex routines pulled in from the built-in regex library apparently extracted from some release of GNU libc. The following minor changes were made: - Binaries are still 32-bit, but generated for extra ISAs sparcv8plus+vis and pentium_pro - Testing is currently disabled, but majority of tests pass Any testing would be appreciated. Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Thu Aug 26 19:28:12 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 26 Aug 2010 13:28:12 -0400 Subject: [csw-maintainers] Updated findutils package (4.4.2) in experimental/, please test In-Reply-To: <4C769F58.7060902@opencsw.org> References: <4C769F58.7060902@opencsw.org> Message-ID: <1282843036-sup-4811@pinkfloyd.chass.utoronto.ca> Excerpts from Gordon Marler's message of Thu Aug 26 13:07:36 -0400 2010: Hi Gordon, > The failed tests are explicitly documented in the Makefile, if they > are deemed important enough to fix. At least 4 of them appear to be If any of the errors are surrounding ACL (permission denied stuff), you may want to look at the patch I carry (for now, it's in upstream) with coreutils. It's a gnulib fix that handles an extra error condition with the permission setting routines. I _think_ that findutils is also using gnulib and if it's not a current enough import there, it likely suffers from the same error that coreutils did. Other than that, nice to see an update to this. Will you be providing your own /opt/csw/gnu links? I'd appreciate you adding them so that I can drop those links from the CSWgnulinks package. HTH. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Thu Aug 26 20:55:55 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 26 Aug 2010 20:55:55 +0200 Subject: [csw-maintainers] Updating libfaad2 and mpeg4ip In-Reply-To: References: <1280278827-sup-1945@pinkfloyd.chass.utoronto.ca> <4C6045E6.6080101@opencsw.org> <4C6BB0FF.5080701@opencsw.org> Message-ID: <3345BA90-0DC9-4506-9316-C5CAAB41D4BD@opencsw.org> Hi Jake, Am 26.08.2010 um 00:01 schrieb Jake Goerzen: > I took a look at xmms. I updated the GAR recipe and rebuilt new > packages The packages are available in experimental/x11-reloaded: > > xmms-1.2.11,REV=2010.08.25-SunOS5.9-i386-CSW.pkg.gz > xmms-1.2.11,REV=2010.08.25-SunOS5.9-sparc-CSW.pkg.gz Cool. > The program runs except there is a problem with the opengl plugin eg: > > bash-3.00$ xmms > ld.so.1: xmms: fatal: relocation error: file > /opt/csw/lib/xmms/Visualization/libogl_spectrum.so: symbol > sunOglCurrentContext: referenced symbol not found > > I'm not sure what is going wrong since the ./configure and build > process seemed to find the right system X11 headers and libraries. > And libogl_spectrum.so is finding the libraries needed during runtime: > > bash-3.00$ ldd /opt/csw/lib/xmms/Visualization/libogl_spectrum.so Try "ldd -r" and you see the error: > root at testing9s :/root > ldd -r /opt/csw/lib/xmms/Visualization/ > libogl_spectrum.so > ... > symbol not found: sunOglCurrentContext (/opt/csw/ > lib/xmms/Visualization/libogl_spectrum.so) > symbol not found: sunOglCurPrimTablePtr (/opt/csw/ > lib/xmms/Visualization/libogl_spectrum.so) A brief search gave http://www.nvnews.net/vbulletin/showthread.php?t=149650 and http://www.mail-archive.com/osg-users at lists.openscenegraph.org/msg08023.html From there I would recommend to try EXTRA_CPPFLAGS = -DSUN_OGL_NO_VERTEX_MACROS (or extra CFLAGS) I would love to hear what James says to this, but he is on vacation for a couple of weeks :-/ Best regards -- Dago From dam at opencsw.org Thu Aug 26 21:21:19 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 26 Aug 2010 21:21:19 +0200 Subject: [csw-maintainers] Updated findutils package (4.4.2) in experimental/, please test In-Reply-To: <4C769F58.7060902@opencsw.org> References: <4C769F58.7060902@opencsw.org> Message-ID: <9232CECA-9815-467A-9B19-B449E6E15FD5@opencsw.org> Hi Gordon, Am 26.08.2010 um 19:07 schrieb Gordon Marler: > findutils 4.4.2 is now being packaged under GAR, instead of manually > as it was before. > > http://mirror.opencsw.org/experimental.html#gmarler > pkgutil -t http://mirror.opencsw.org/opencsw/experimental/gmarler -i > findutils Great! > At present, testing is disabled, since 12 tests in the findutils > suite, and it appears that they were never successful in the > manually built package either. > > The failed tests are explicitly documented in the Makefile, if they > are deemed important enough to fix. At least 4 of them appear to be > simple permissioning errors in the testing area setup by findutils > own scripts. The remaining failures have to do with the iregex > routines pulled in from the built-in regex library apparently > extracted from some release of GNU libc. The recommended cause of action is: 1. File a bug upstream 2. Put a comment about the failing tests before "SKIPTEST ?= 1" together with a link to the upstream bug with something like "Tests are disabled until these bugs are fixed: " > The following minor changes were made: > - Binaries are still 32-bit, but generated for extra ISAs sparcv8plus > +vis and pentium_pro Do these really provide any advantage? Adding an extra ISA is recommended only if benchmarking showed any difference. > - Testing is currently disabled, but majority of tests pass > > Any testing would be appreciated. I suppose your email in your .garrc is wrong: gmarelr at opencsw.org I have two more issues about the postinstall: 1. You should use the cswcrontab CAS instead of rolling your own http://wiki.opencsw.org/cswclassutils-package#toc23 2. It should honour autoenable_daemons in csw.conf (same document) If it is not set IMHO there should be no crontab entry. Best regards -- Dago From jgoerzen at opencsw.org Thu Aug 26 23:27:17 2010 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Thu, 26 Aug 2010 14:27:17 -0700 Subject: [csw-maintainers] Updating libfaad2 and mpeg4ip In-Reply-To: <3345BA90-0DC9-4506-9316-C5CAAB41D4BD@opencsw.org> References: <1280278827-sup-1945@pinkfloyd.chass.utoronto.ca> <4C6045E6.6080101@opencsw.org> <4C6BB0FF.5080701@opencsw.org> <3345BA90-0DC9-4506-9316-C5CAAB41D4BD@opencsw.org> Message-ID: On Thu, Aug 26, 2010 at 11:55 AM, Dagobert Michelsen wrote: > Hi Jake, > > Am 26.08.2010 um 00:01 schrieb Jake Goerzen: >> >> ?I took a look at xmms. ?I updated the GAR recipe and rebuilt new >> packages ?The packages are available in experimental/x11-reloaded: >> >> xmms-1.2.11,REV=2010.08.25-SunOS5.9-i386-CSW.pkg.gz >> xmms-1.2.11,REV=2010.08.25-SunOS5.9-sparc-CSW.pkg.gz > > Cool. > >> The program runs except there is a problem with the opengl plugin eg: >> >> bash-3.00$ xmms >> ld.so.1: xmms: fatal: relocation error: file >> /opt/csw/lib/xmms/Visualization/libogl_spectrum.so: symbol >> sunOglCurrentContext: referenced symbol not found >> >> I'm not sure what is going wrong since the ./configure and build >> process seemed to find the right system X11 headers and libraries. >> And libogl_spectrum.so is finding the libraries needed during runtime: >> >> bash-3.00$ ldd /opt/csw/lib/xmms/Visualization/libogl_spectrum.so > > Try "ldd -r" and you see the error: > >> root at testing9s :/root > ldd -r >> /opt/csw/lib/xmms/Visualization/libogl_spectrum.so >> ... >> ? ? ? ?symbol not found: sunOglCurrentContext >> ?(/opt/csw/lib/xmms/Visualization/libogl_spectrum.so) >> ? ? ? ?symbol not found: sunOglCurPrimTablePtr >> (/opt/csw/lib/xmms/Visualization/libogl_spectrum.so) > > A brief search gave > ?http://www.nvnews.net/vbulletin/showthread.php?t=149650 > and > ?http://www.mail-archive.com/osg-users at lists.openscenegraph.org/msg08023.html > > From there I would recommend to try > ?EXTRA_CPPFLAGS = -DSUN_OGL_NO_VERTEX_MACROS > (or extra CFLAGS) Thanks you are awesome! problem resolved. Updated xmms packages are now available in experimental/x11-reloaded/ xmms-1.2.11,REV=2010.08.26-SunOS5.9-i386-CSW.pkg.gz xmms-1.2.11,REV=2010.08.26-SunOS5.9-sparc-CSW.pkg.gz > I would love to hear what James says to this, but he is on vacation for a > couple of weeks :-/ Yes I'm interested in hearing too. Thanks, Jake From dam at opencsw.org Fri Aug 27 14:14:43 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 27 Aug 2010 14:14:43 +0200 Subject: [csw-maintainers] Reorganiation of webpage In-Reply-To: References: <2110D505-8C36-47B9-BDB6-4369CC6F4F02@opencsw.org> Message-ID: <2032234F-F126-4392-9B73-6D4327E30EBA@opencsw.org> Hi, Am 25.08.2010 um 15:07 schrieb Peter Bonivart: > On Wed, Aug 25, 2010 at 2:50 PM, Dagobert Michelsen > wrote: >> I gave the website some more thought. Personally I find the "Latest >> News" >> section >> not really useful as I have to click on it. The news should be >> relocated/merged >> with "Latest Announcements". >> >> The "Download" box occupies a lot of valuable space not used often. I >> recommend >> removing the box and renaming "Get it" to the more catchy "Download". >> >> Further I would think "Feeds" as second item in the top-bar should >> be moved >> to the >> right as it will be used only sporadically. >> >> One more thing: On http://www.opencsw.org/support/ the link in >> "If you want to immediately use our software, you can go through the >> quickstart >> documentation page" to quickstart is broken. >> >> Feedback welcome! > > I agree with everything Ok then, more feedback? If not I would like to ask William :-) about doing the change of the frontpage. > and want to add that the mirror signup page is > missing. Maybe it would be easiest to just have a mail address there > like you mentioned on IRC, e.g. mirror at opencsw.org, delivered to at > least two people. This is in the works. There will be an alias mirror at opencsw.org for downstream communication and mirror-announce at list.opencsw.org where notifications can be sent to the mirrors. Best regards -- Dago From gmarler at opencsw.org Sun Aug 29 02:09:01 2010 From: gmarler at opencsw.org (Gordon Marler) Date: Sat, 28 Aug 2010 20:09:01 -0400 Subject: [csw-maintainers] Updated findutils package (4.4.2) in experimental/, please test In-Reply-To: <1282843036-sup-4811@pinkfloyd.chass.utoronto.ca> References: <4C769F58.7060902@opencsw.org> <1282843036-sup-4811@pinkfloyd.chass.utoronto.ca> Message-ID: <4C79A51D.7020102@opencsw.org> On 08/26/10 01:28 PM, Ben Walton wrote: > Excerpts from Gordon Marler's message of Thu Aug 26 13:07:36 -0400 2010: > > Hi Gordon, > > >> The failed tests are explicitly documented in the Makefile, if they >> are deemed important enough to fix. At least 4 of them appear to be >> > If any of the errors are surrounding ACL (permission denied stuff), > you may want to look at the patch I carry (for now, it's in upstream) > with coreutils. It's a gnulib fix that handles an extra error > condition with the permission setting routines. I _think_ that > findutils is also using gnulib and if it's not a current enough import > there, it likely suffers from the same error that coreutils did. > Thanks for the tip Ben, will check that out. > Other than that, nice to see an update to this. Will you be providing > your own /opt/csw/gnu links? I'd appreciate you adding them so that I > can drop those links from the CSWgnulinks package. > > Will do that too. > HTH. > -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 dam at baltic-online.de Tue Aug 10 10:03:20 2010 From: dam at baltic-online.de (Dagobert Michelsen) Date: Tue, 10 Aug 2010 08:03:20 -0000 Subject: [csw-maintainers] The released packages feed is back! Message-ID: <16239981-EC73-4FCB-82EA-E15347C5FC1E@baltic-online.de> Hi, FYI: the released packages feed is back at http://www.opencsw.org/cgi-feed/releasedpkgs.atom Best regards -- Dago From dam at opencsw.org Tue Aug 10 20:32:00 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 10 Aug 2010 18:32:00 -0000 Subject: [csw-maintainers] [buildfarm-announce] Updating Sun Studio compilers Message-ID: <4AC09BB7-9799-4FC9-926F-BDCB6411C268@opencsw.org> Hi, I will be updating the Sun Studio 12 compiler on the OpenCSW buildfarm. If you see errors on compilation please stay calm and retry in a few hours. Sorry for the inconvenience -- Dago _______________________________________________ buildfarm-announce mailing list buildfarm-announce at opencsw.org https://lists.opencsw.org/mailman/listinfo/buildfarm-announce From gmarler at gmarler.com Tue Aug 24 04:36:32 2010 From: gmarler at gmarler.com (Gordon Marler) Date: Mon, 23 Aug 2010 22:36:32 -0400 Subject: [csw-maintainers] Failing tests for CSWfindutils Message-ID: <4C733030.2030405@gmarler.com> While working to update the CSWfindutils GAR recipe, I'm running into a problem with a few of the tests. My latest attempt has been checked into the SVN repo, and the failures are documented there. These break down into two categories: 1. Those that depend on the regex library delivered with the findutils source, as it's expecting to find the one provided by GNU libc, and Solaris doesn't provide it. As far as I can tell, we're forced to either rely on the regex provided with the source, or statically build/link against some recent GNU libc.: 2. Some permissioning problems that prevent 4 of the tests from running. Can't find the source of these issues so far. Gordon From gmarler at gmarler.com Sun Aug 29 02:08:54 2010 From: gmarler at gmarler.com (Gordon Marler) Date: Sat, 28 Aug 2010 20:08:54 -0400 Subject: [csw-maintainers] Updated findutils package (4.4.2) in experimental/, please test In-Reply-To: <1282843036-sup-4811@pinkfloyd.chass.utoronto.ca> References: <4C769F58.7060902@opencsw.org> <1282843036-sup-4811@pinkfloyd.chass.utoronto.ca> Message-ID: <4C79A516.3050602@gmarler.com> On 08/26/10 01:28 PM, Ben Walton wrote: > Excerpts from Gordon Marler's message of Thu Aug 26 13:07:36 -0400 2010: > > Hi Gordon, > > >> The failed tests are explicitly documented in the Makefile, if they >> are deemed important enough to fix. At least 4 of them appear to be >> > If any of the errors are surrounding ACL (permission denied stuff), > you may want to look at the patch I carry (for now, it's in upstream) > with coreutils. It's a gnulib fix that handles an extra error > condition with the permission setting routines. I _think_ that > findutils is also using gnulib and if it's not a current enough import > there, it likely suffers from the same error that coreutils did. > Thanks for the tip Ben, will check that out. > Other than that, nice to see an update to this. Will you be providing > your own /opt/csw/gnu links? I'd appreciate you adding them so that I > can drop those links from the CSWgnulinks package. > > Will do that too. > HTH. > -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 dam at opencsw.org Sun Aug 29 16:19:35 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 29 Aug 2010 16:19:35 +0200 Subject: [csw-maintainers] Fwd: [csw-devel] SF.net SVN: gar:[10832] csw/mgar/pkg/gettext/trunk/Makefile References: Message-ID: <5CA35573-EE71-416F-B496-17C4E83FA79C@opencsw.org> Hi Ben, I don't think factoring out .el-packages is a good thing. Having .el files around without emacs doesn't have any negative effects, the files are very small in space and the extra package makes it difficult to pick up all .els for the installed packages. I would suggest just overwriting the checkpkg warning in this specific case. I would even go so far as to ask Maciej to disable this warning as in most cases splitting of the .el is not what you want. Toughts? Best regards -- Dago Anfang der weitergeleiteten E-Mail: > Von: bdwalton at users.sourceforge.net > Datum: 28. August 2010 20:29:19 MESZ > An: devel at lists.opencsw.org > Betreff: [csw-devel] SF.net SVN: gar:[10832] csw/mgar/pkg/gettext/trunk/Makefile > Antwort an: Broadcasts commit logs for build descriptions and GAR > > Revision: 10832 > http://gar.svn.sourceforge.net/gar/?rev=10832&view=rev > Author: bdwalton > Date: 2010-08-28 18:29:18 +0000 (Sat, 28 Aug 2010) > > Log Message: > ----------- > gettext: correct name of _el package; set _el package to ARCHALL > > Modified Paths: > -------------- > csw/mgar/pkg/gettext/trunk/Makefile > > Modified: csw/mgar/pkg/gettext/trunk/Makefile > =================================================================== > --- csw/mgar/pkg/gettext/trunk/Makefile 2010-08-28 12:34:04 UTC (rev 10831) > +++ csw/mgar/pkg/gettext/trunk/Makefile 2010-08-28 18:29:18 UTC (rev 10832) > @@ -7,15 +7,18 @@ > GNU gettext utilities are a set of tools that provides a framework to help other GNU packages produce multi-lingual messages > endef > > -PACKAGES = CSWggettextrt CSWggettextdoc CSWggettext CSWggettext_el > +PACKAGES = CSWggettextrt CSWggettextdoc CSWggettext CSWggettextel > + > +ARCHALL_CSWggettextel = 1 > + > CATALOGNAME_CSWggettext = ggettext > CATALOGNAME_CSWggettextdoc = ggettextdoc > CATALOGNAME_CSWggettextrt = ggettextrt > -CATALOGNAME_CSWggettextel = ggettext_el > +CATALOGNAME_CSWggettextel = ggettextel > SPKG_DESC_CSWggettext = GNU locale utilities and development headers > SPKG_DESC_CSWggettextdoc = GNU locale documentation > SPKG_DESC_CSWggettextrt = GNU locale runtime > -SPKG_DESC_CSWggettextel = Emacs support for po file editting > +SPKG_DESC_CSWggettextel = Emacs support for gettext po file editting > ARCHALL_CSWggettextdoc = 1 > > COMPILE_ELISP = 1 > > > This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. > _______________________________________________ > devel mailing list > devel at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/devel From dam at opencsw.org Sun Aug 29 16:21:09 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 29 Aug 2010 16:21:09 +0200 Subject: [csw-maintainers] Failing tests for CSWfindutils In-Reply-To: <4C733030.2030405@gmarler.com> References: <4C733030.2030405@gmarler.com> Message-ID: <683DBBED-43DB-487B-AEF4-227D39306C89@opencsw.org> Hi Gordon, Am 24.08.2010 um 04:36 schrieb Gordon Marler: > While working to update the CSWfindutils GAR recipe, I'm running into a problem with a few of the tests. My latest attempt has been checked into the SVN repo, and the failures are documented there. > > These break down into two categories: > > 1. Those that depend on the regex library delivered with the findutils source, as it's expecting to find the one provided by GNU libc, and Solaris doesn't provide it. As far as I can tell, we're forced to either rely on the regex provided with the source, This sounds reasonable to me. > or statically build/link against some recent GNU libc.: > > 2. Some permissioning problems that prevent 4 of the tests from running. Can't find the source of these issues so far. This may have something to do with the NFS mounted homedirectory you are testing on. Are the tests failing on Sparc also as these are lofs? Best regards -- Dago From phil at bolthole.com Mon Aug 30 18:52:41 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 30 Aug 2010 09:52:41 -0700 Subject: [csw-maintainers] Fwd: [csw-devel] SF.net SVN: gar:[10832] csw/mgar/pkg/gettext/trunk/Makefile In-Reply-To: <5CA35573-EE71-416F-B496-17C4E83FA79C@opencsw.org> References: <5CA35573-EE71-416F-B496-17C4E83FA79C@opencsw.org> Message-ID: On Sun, Aug 29, 2010 at 7:19 AM, Dagobert Michelsen wrote: > Hi Ben, > > I don't think factoring out .el-packages is a good thing. Having .el files around > without emacs doesn't have any negative effects, the files are very small in space and > the extra package makes it difficult to pick up all .els for the installed packages. > I would suggest just overwriting the checkpkg warning in this specific case. I would > even go so far as to ask Maciej to disable this warning as in most cases splitting > of the .el is not what you want. > > Toughts? > I think this is somewhat similar to including texinfo files, without actually depending on texinfo. ie: reasonable to do. So, I personally agree, that for simplicity's sake, just disabling warning(globally) is the most maintainer-friendly thing to do. From skayser at opencsw.org Mon Aug 30 19:54:11 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 30 Aug 2010 19:54:11 +0200 Subject: [csw-maintainers] Work for prospective maintainers: Weighted Buglisting. Orphaned packages? Message-ID: <4C7BF043.1040002@opencsw.org> Hi, there's a prospective maintainer whom I would like to present with a list of possible packages which are up for adoption or worth working on. The weighted buglisting still seems to be online [1], any chance to have it integrated into the new website (include + a bit of CSS)? Further, is the list of orphaned packages ("no maintainer") still available somewhere? Wasn't able to find it just now. Sebastian [1]http://www.opencsw.org/buglist/buglist.cgi From phil at bolthole.com Mon Aug 30 22:36:35 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 30 Aug 2010 13:36:35 -0700 Subject: [csw-maintainers] Work for prospective maintainers: Weighted Buglisting. Orphaned packages? In-Reply-To: <4C7BF043.1040002@opencsw.org> References: <4C7BF043.1040002@opencsw.org> Message-ID: On Mon, Aug 30, 2010 at 10:54 AM, Sebastian Kayser wrote: > Hi, > > there's a prospective maintainer whom I would like to present with a > list of possible packages which are up for adoption or worth working on. > > The weighted buglisting still seems to be online [1], any chance to have > it integrated into the new website (include + a bit of CSS)? Further, is > the list of orphaned packages ("no maintainer") still available > somewhere? Wasn't able to find it just now. > There is a difference between completely "orphaned" and "maintainer has retired". The list of truly "orphaned" packages is very short: ntop and libnet http://www.opencsw.org/maintainers/orphaned/ The list of "packages last touched by a retired maintainer" is considerably longer. Much, Much, longer :( The "biggies", are kerberos php samba kde qt gcc4 gnome sasl zope squid xfce (not "officially" orphaned, but hasnt seen an update in 4 years) plus a bunch of miscellaneous packages, and 120 random perl modules (pm_xxxxx) From dam at opencsw.org Tue Aug 31 08:48:10 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 31 Aug 2010 08:48:10 +0200 Subject: [csw-maintainers] Work for prospective maintainers: Weighted Buglisting. Orphaned packages? In-Reply-To: References: <4C7BF043.1040002@opencsw.org> Message-ID: <7DE02DD6-B63A-460E-A38E-FC37A604E381@opencsw.org> Hi Phil, Am 30.08.2010 um 22:36 schrieb Philip Brown: > On Mon, Aug 30, 2010 at 10:54 AM, Sebastian Kayser > wrote: >> there's a prospective maintainer whom I would like to present with a >> list of possible packages which are up for adoption or worth >> working on. >> >> The weighted buglisting still seems to be online [1], any chance to >> have >> it integrated into the new website (include + a bit of CSS)? >> Further, is >> the list of orphaned packages ("no maintainer") still available >> somewhere? Wasn't able to find it just now. >> > > There is a difference between completely "orphaned" and "maintainer > has retired". > The list of truly "orphaned" packages is very short: ntop and libnet > > http://www.opencsw.org/maintainers/orphaned/ There must be some mistake, the list always contained around 30 packages. William: Could you please verify the list against the database state? > The list of "packages last touched by a retired maintainer" is > considerably longer. > > Much, Much, longer :( > > The "biggies", are > > kerberos 90% done, some tests still failing, help needed for integration. > php > samba > kde > qt > gcc4 Peter Felecan offered to work on it. > gnome > sasl Also 90% done, also help needed. > zope > squid Updated in GAR, some testing needed. > xfce (not "officially" orphaned, but hasnt seen an update in 4 years) Umh, AFAIK William had an update with a minor problem concering dual head on Sparc, wasn't it? ;-) > plus a bunch of miscellaneous packages, and 120 random perl modules > (pm_xxxxx) Fair enough, we can bump them fast. Do you have a list? The Perl team wants to squash them in no time! Best regards -- Dago From maciej at opencsw.org Tue Aug 31 12:17:17 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 31 Aug 2010 11:17:17 +0100 Subject: [csw-maintainers] Board election method Message-ID: We need elect a new board. Previously, the election has been done in person, but this time it needs to be done remotely, which will require a new voting method. We need to choose a method of voting then, which begs a question: What voting method will we use to decide on the voting method? We could use the Concordet voting system. We could also use an external site, such as [2]. I've also created a package with debian-vote, an implementation of the Concordet system, the package is available from experimental[3]. Thoughts? [1] http://en.wikipedia.org/wiki/Condorcet_method [2] http://www.cs.cornell.edu/andru/civs.html [3] http://mirror.opencsw.org/experimental.html#maciej From pfelecan at opencsw.org Tue Aug 31 14:06:55 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 31 Aug 2010 14:06:55 +0200 Subject: [csw-maintainers] Board election method In-Reply-To: (Maciej Blizinski's message of "Tue, 31 Aug 2010 11:17:17 +0100") References: Message-ID: "Maciej (Matchek) Blizinski" writes: > We need elect a new board. Previously, the election has been done in > person, but this time it needs to be done remotely, which will require > a new voting method. We need to choose a method of voting then, which > begs a question: What voting method will we use to decide on the > voting method? The board should announce the date of the election. > We could use the Concordet voting system. We could also use an > external site, such as [2]. I've also created a package with > debian-vote, an implementation of the Concordet system, the package is > available from experimental[3]. > > Thoughts? As a French, by election, I like the Condorcet system, however abstruse/abscons. As for the tool to use I think that CIVS, private, is a good and quick compromise. For the debian-voting, the interest is that it can be hosted on our system and only people having the right to connect to the build farm can vote. However, being hosted on a system on which there are many administrators being part of the process is not as fair as it seems. Consequently, my preference goes to CIVS. -- Peter From phil at bolthole.com Tue Aug 31 18:24:59 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 31 Aug 2010 09:24:59 -0700 Subject: [csw-maintainers] Work for prospective maintainers: Weighted Buglisting. Orphaned packages? In-Reply-To: <7DE02DD6-B63A-460E-A38E-FC37A604E381@opencsw.org> References: <4C7BF043.1040002@opencsw.org> <7DE02DD6-B63A-460E-A38E-FC37A604E381@opencsw.org> Message-ID: On Mon, Aug 30, 2010 at 11:48 PM, Dagobert Michelsen wrote: > Hi Phil, *wave* > >> kerberos > > 90% done, some tests still failing, help needed for integration. >... >> gcc4 > > Peter Felecan offered to work on it. > ... >> sasl > > Also 90% done, also help needed. >... >> squid > > Updated in GAR, some testing needed. A note of general principle to everyone: All of the above have not been updated for "a very long time". If someone is interested in any of the above, whether a new maintainer or old, they should just dive in. if the "new" person can do in a few days, what a prior "potentially working on it" person has not completed in many months, then the new person is clearly the best maintainer for the software. So, once again: if you are interested in any of the above, please put together a package and submit it. Similar to the patent office --when it comes to orphaned/retired status packages, "first to file" wins ;-) From phil at bolthole.com Tue Aug 31 18:27:47 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 31 Aug 2010 09:27:47 -0700 Subject: [csw-maintainers] For "the Perl team" Message-ID: On Mon, Aug 30, 2010 at 11:48 PM, Dagobert Michelsen wrote: > ... >> plus a bunch of miscellaneous packages, and 120 random perl modules >> (pm_xxxxx) > > Fair enough, we can bump them fast. Do you have a list? The Perl team wants > to squash them in no time! > > pm_configinifil a module for reading .ini-style configuration files. pm_iosocketssl Perl extension for using OpenSSL pm_wwwmechanize Handy web browsing in a Perl object pm_mailimapclie Perl IMAP Client API pm_mailsendmail Mail::Sendmail pm_geocountries 2-letter, 3-letter, and numerical codes for countries pm_netcidrlite Perl extension for merging IPv4 or IPv6 CIDR addresses pm_syshostnamel Try every conceivable way to get full hostname pm_ipcountry Fast lookup of country codes from IP address pm_mailspfqry query Sender Policy Framework for an IP,email,helo pm_htmlscrubber Perl extension for scrubbing/sanitizing html pm_lclemktxtlex Use other catalog formats in Maketext pm_testinline Inlining your tests next to the code being tested. pm_texttemplate Expand template text with embedded Perl pm_dbixsrchbuil Encapsulate SQL queries and rows in perl objects pm_podescapes for resolving Pod E<..> sequences pm_textwrap Word wrapping routine pm_timemods Time parsing modules pm_lclemktxtfuz Maketext from already interpolated strings pm_modversrpt Report versions of all modules in memory pm_txtautofmt Automatic text wrapping and reformatting pm_clsdtainheri Inheritable, overridable class data pm_tstmanif Interact with a t/test_manifest file pm_apachetst Test pm wrapper with helpers for testing Apache with modp pm_testpod Check for POD errors in files pm_txtquoted Extract the structure of a quoted mail message pm_treesimple A simple tree object pm_exceptcls Allows declaration of Perl exception classes pm_apachesess A persistence framework for session data pm_fontafm Interface to Adobe Font Metrics files pm_regexpcom Provide commonly requested regular expressions pm_apachedbi Initiate a persistent database connection (for Apache) pm_htmlfmt Format HTML as plaintext, PostScript or RTF pm_xmlnssupp Simple generic namespace support class pm_speedycgi Speed up perl scripts by running them persistently (mod_s pm_gdgraph Graph plotting module for use with GD pm_gdgraph3d 3d extensions module for GD::Graph pm_htmltemplate HTML::Template, a module for using HTML Templates with Pe pm_convertbinhe Perl module to extract data from Macintosh BinHex files pm_converttnef Perl module to read TNEF files pm_timeperiod Time::Period (Period), perl module to deal with time peri pm_httpsvrsimp Simple standalone HTTP daemon pm_hooklexwrap Lexically scoped subroutine wrappers pm_testlongstr Tests strings for equality, with more helpful failure pm_modrefresh Refresh %INC files when updated on disk pm_httpsvrmason Abstract baseclass for a standalone mason server pm_testwwwmech Testing-specific WWW::Mechanize subclass pm_iosocketinet Object interface for AF_INET|AF_INET6 domain sockets pm_gimp Perl extension to the Gimp pm_frontierrpc XML-RPC client interface pm_textwikifmt Translate Wiki formatted text into other formats pm_dbixdbschema Database-independent schema objects pm_cachememcach client library for memcached pm_cache new cache interface. pm_clsautouse Run-time class loading on first method call pm_extutxsbld parse C header files and create XS glue code pm_filechdir a more sensible way to change directories pm_filenfslock Perl module to do NFS (or not) locking pm_filetype determine file type using magic pm_heap extensions for keeping data partially sortedpm_patchreader Utilities to read and pm_clsaccessorc Perl extension to make chained accessors pmtools Tools for managing installed Perl modules. pm_calendarsimp Perl extension to create simple calendars pm_datashowtbl Routines to display tabular data in several format pm_expectsimp Perl wrapper around the Expect module pm_testexpect Automated driving and testing of terminal-based programs pm_expect Perl modules for automating interactive applications pm_speedycgiper Speed up perl scripts by running them persistently - pure pm_templategd GD plugins for the Template Toolkit pm_mailbox manage a mailbox, a folder with messages pm_mailsender module for sending mails with attachments through an SMTP pm_archiveextra A generic archive extracting mechanism pm_cpanplus API and CLI access to the CPAN mirrors pm_extutautoins Automatic install of dependencies via CPAN pm_extutilsmft Utilities to write and check a MANIFEST file pm_filefetch A generic file fetching mechanism pm_ipccmd Finding and running system commands made easy pm_logmessage Generic message storage mechanism. pm_logmsgsimple Standardized logging facilities using the Log::Message mo pm_modloaded Mark modules as loaded or unloaded pm_prmscheck A generic input parsing/checking mechanism. pm_sortversions a module for sorting of revision-like numbers. pm_termui Term::ReadLine UI made easy pm_podreadme Perl extension to convert POD to README file pm_csssquish Perl module to compact many CSS files into one big file pm_filefindrule Alternative interface to File::Find pm_nbrcompare Numeric comparisons pm_podtests Extracts embedded tests and code examples from POD pm_testscript Cross-platform basic tests for scripts pm_textglob Match globbing patterns against text pm_iodigest calculate digests while reapm_netdnsreslvp Programmable DNS resolver class for From dam at opencsw.org Tue Aug 31 18:31:03 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 31 Aug 2010 18:31:03 +0200 Subject: [csw-maintainers] Work for prospective maintainers: Weighted Buglisting. Orphaned packages? In-Reply-To: References: <4C7BF043.1040002@opencsw.org> <7DE02DD6-B63A-460E-A38E-FC37A604E381@opencsw.org> Message-ID: <1C573D73-4D6C-44E2-B965-F7A70E2E5EF3@opencsw.org> Hi Phil, Am 31.08.2010 um 18:24 schrieb Philip Brown: >>> kerberos >> >> 90% done, some tests still failing, help needed for integration. >> ... >>> gcc4 >> >> Peter Felecan offered to work on it. >> > ... >>> sasl >> >> Also 90% done, also help needed. >> ... >>> squid >> >> Updated in GAR, some testing needed. > > A note of general principle to everyone: > All of the above have not been updated for "a very long time". > If someone is interested in any of the above, whether a new maintainer > or old, they should just dive in. > if the "new" person can do in a few days, what a prior "potentially > working on it" person has not completed in many months, then the new > person is clearly the best maintainer for the software. > > So, once again: if you are interested in any of the above, please put > together a package and submit it. > Similar to the patent office --when it comes to orphaned/retired > status packages, "first to file" wins ;-) My comments were not meant as "these are mine", but more like "there is probably not much missing if you want to take it over". Best regards -- Dago From rupert at opencsw.org Tue Aug 31 18:31:12 2010 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 31 Aug 2010 18:31:12 +0200 Subject: [csw-maintainers] unixodbc-2.3.0 is available for testing In-Reply-To: References: Message-ID: hi, it seems odbc is found correctly but apr-util gives the following while the tests are run: Loaded odbc driver OK. [Tue Aug 31 11:14:26 2010] [dbd_odbc] SQLConnect returned SQL_ERROR (-1) at dbd/apr_dbd_odbc.c:1076 [unixODBC][Driver Manager]Data source name not found, and no default driver specified IM002 Failed to open odbc[] Programs failed: testall gmake[4]: *** [check] Error 137 gmake[4]: Leaving directory `/home/rupert/mgar/pkg/apr-util/trunk/work/solaris9-sparc/build-isa-sparcv8/apr-util-1.3.9/test' gmake[3]: *** [check] Error 2 gmake[3]: Leaving directory `/home/rupert/mgar/pkg/apr-util/trunk/work/solaris9-sparc/build-isa-sparcv8/apr-util-1.3.9' gmake[2]: *** [test-work/solaris9-sparc/build-isa-sparcv8/apr-util-1.3.9/Makefile] Error 2 gmake[2]: Leaving directory `/home/rupert/mgar/pkg/apr-util/trunk' gmake[1]: *** [merge-isa-sparcv8] Error 2 gmake[1]: Leaving directory `/home/rupert/mgar/pkg/apr-util/trunk' gmake: *** [platforms] Error 2 it currently links to CSWsqlite3rt, and i hoped thats enough. i removed the dependency to odbc now and built --without-odbc. rupert On Mon, Aug 23, 2010 at 11:29, Dagobert Michelsen wrote: > Hi Maciej, > > Am 28.07.2010 um 00:50 schrieb Maciej (Matchek) Blizinski: >> >> Are there any unixodbc users here? ?Version 2.3.0 (updated from >> 2.2.14) is available for testing: >> >> http://mirror.opencsw.org/experimental.html#maciej > > I just installed it and have some notes: > - The package provides isaexec-binaries for both 32/64 bit which is > AFAIK not really necessary. > - This is especially true for odbc_config, which now outputs always the > 64 bit flags on a 64 bit system. GAR has special handling for *-config > binaries to be never isaexec'ed, but here it call non-standard with > an underscore instead of a hyphen so default handling doesn't work: > ?gar.pkg.mk:_ISAEXEC_EXCLUDE_FILES = $(bindir)/%-config $(bindir)/%/%-config > - You could use > ? ?MIGRATE_FILES = odbc.ini odbcinst.ini ODBCDataSources > instead of use a hardwired cswmigrateconf from files/ > - When using SAMPLECONF the renaming of * to *.CSW is done automatically, > no need to do this manually in postinstall > - The shipped .ini files are empty. It would be nice to keep the ones > previously shipped with examples for all supported databases. > > APR-Util needs a working unixodbc for his tests, so I currently > building sqliteodbc as simplest possible test. > > > 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 skayser at opencsw.org Tue Aug 31 18:41:33 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 31 Aug 2010 18:41:33 +0200 Subject: [csw-maintainers] Work for prospective maintainers: Weighted Buglisting. Orphaned packages? In-Reply-To: References: <4C7BF043.1040002@opencsw.org> Message-ID: <20100831164133.GN31821@sebastiankayser.de> * Philip Brown wrote: > On Mon, Aug 30, 2010 at 10:54 AM, Sebastian Kayser wrote: > > there's a prospective maintainer whom I would like to present with a > > list of possible packages which are up for adoption or worth working on. > > > > The weighted buglisting still seems to be online [1], any chance to have > > it integrated into the new website (include + a bit of CSS)? Further, is > > the list of orphaned packages ("no maintainer") still available > > somewhere? Wasn't able to find it just now. > > > > There is a difference between completely "orphaned" and "maintainer > has retired". > The list of truly "orphaned" packages is very short: ntop and libnet > > http://www.opencsw.org/maintainers/orphaned/ > > The list of "packages last touched by a retired maintainer" is > considerably longer. Shouldn't these kind of packages be listed as orphaned too? At least there's no one explicitly taking care of them. Sebastian From skayser at opencsw.org Tue Aug 31 18:44:42 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 31 Aug 2010 18:44:42 +0200 Subject: [csw-maintainers] Work for prospective maintainers: Weighted Buglisting. Orphaned packages? In-Reply-To: <20100831164133.GN31821@sebastiankayser.de> References: <4C7BF043.1040002@opencsw.org> <20100831164133.GN31821@sebastiankayser.de> Message-ID: <20100831164442.GO31821@sebastiankayser.de> * Sebastian Kayser wrote: > * Philip Brown wrote: > > On Mon, Aug 30, 2010 at 10:54 AM, Sebastian Kayser wrote: > > > there's a prospective maintainer whom I would like to present with a > > > list of possible packages which are up for adoption or worth working on. > > > > > > The weighted buglisting still seems to be online [1], any chance to have > > > it integrated into the new website (include + a bit of CSS)? Further, is > > > the list of orphaned packages ("no maintainer") still available > > > somewhere? Wasn't able to find it just now. > > > > > > > There is a difference between completely "orphaned" and "maintainer > > has retired". > > The list of truly "orphaned" packages is very short: ntop and libnet > > > > http://www.opencsw.org/maintainers/orphaned/ > > > > The list of "packages last touched by a retired maintainer" is > > considerably longer. > > Shouldn't these kind of packages be listed as orphaned too? At least > there's no one explicitly taking care of them. Totally forgot, thanks for the manually assembled list! If there was an official way to get to such a list even better. Sebastian From dam at opencsw.org Tue Aug 31 18:49:01 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 31 Aug 2010 18:49:01 +0200 Subject: [csw-maintainers] For "the Perl team" In-Reply-To: References: Message-ID: <4D0F4CC6-554C-4283-B448-9DAE4495D536@opencsw.org> Hi all, Am 31.08.2010 um 18:27 schrieb Philip Brown: > On Mon, Aug 30, 2010 at 11:48 PM, Dagobert Michelsen > wrote: >> ... >>> plus a bunch of miscellaneous packages, and 120 random perl modules >>> (pm_xxxxx) >> >> Fair enough, we can bump them fast. Do you have a list? The Perl >> team wants >> to squash them in no time! > > pm_configinifil a module for reading .ini-style configuration files. > pm_iosocketssl Perl extension for using OpenSSL > ... I put the list at the end of http://wiki.opencsw.org/project-perl Please make a note if you grab something. Best regards -- Dago From phil at bolthole.com Tue Aug 31 18:54:55 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 31 Aug 2010 09:54:55 -0700 Subject: [csw-maintainers] Work for prospective maintainers: Weighted Buglisting. Orphaned packages? In-Reply-To: <20100831164442.GO31821@sebastiankayser.de> References: <4C7BF043.1040002@opencsw.org> <20100831164133.GN31821@sebastiankayser.de> <20100831164442.GO31821@sebastiankayser.de> Message-ID: On Tue, Aug 31, 2010 at 9:44 AM, Sebastian Kayser wrote: > >> Shouldn't these kind of packages be listed as orphaned too? At least >> there's no one explicitly taking care of them. The purpose behind "orphaned" vs "retired", is that if someone attempts to take on the package, but then hits problems with it, they know that at least there's potentially someone they can ask questions about it. > Totally forgot, thanks for the manually assembled list! If there was an > official way to get to such a list even better. I thought there was, so I'm not attempting to put something automated up that is potentially redundant. But the "good" news is, I now have a canned SQL query to generate a list at any time.