From dam at opencsw.org Mon Mar 1 09:55:54 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 1 Mar 2010 09:55:54 +0100 Subject: [csw-maintainers] CSWoldap In-Reply-To: <20100226090812.41300@gmx.net> References: <7E966BC5-D968-4A0B-B273-D491E8E2CDF2@opencsw.org><1265829205-sup-527@ntdws12.chass.utoronto.ca><73AFD8F7-3500-482B-B57B-BE2B114137E0@opencsw.org><1265889472-sup-3249@ntdws12.chass.utoronto.ca><679A617A-8081-4AE4-BFBB-BE8ACEEA68C1@opencsw.org><940F857E6596B84BAFD05DBA869276E234B3225C7C@CON-EX-001.connectis.local><317CA910-083A-48E2-83A8-012B4BB857CE@opencsw.org><6af4271002151043j334d92bck1ae23553f2f4b078@mail.gmail.com> <0BF86C7C-7726-41EE-B847-F378B7B03EA7@opencsw.org> <940F857E6596B84BAFD05DBA869276E23504F1148A@CON-EX-001.connectis.local> <20100226090812.41300@gmx.net> Message-ID: Hi David, Am 26.02.2010 um 10:08 schrieb David Mantock: > I am testing the package on Solaris 10 SMF doesn't work because in > the start script is the following: > > # Make sure required vars are set. Actually these are the compiled > defaults DEF_SLAPD_CONFIG_FILE=/opt/csw/etc/openldap/slapd.conf > DEF_SLAPD_CONFIG_DIR=/opt/csw/etc/openldap/slapd.d > > There is a test if the files and directories exist and they don't. > They are really here: > > DEF_SLAPD_CONFIG_FILE=/etc/opt/csw/openldap/slapd.conf > DEF_SLAPD_CONFIG_DIR=/etc/opt/csw/openldap > > What is the correct standard? I will have to build the package > again, but please let me know the correct paths are. The pathes for configuration files have been changed from /opt/csw/etc to /etc/opt/csw to be useful in sparse root environments with shared /opt. There is a special script available for moving files from the old to the new location: The same goes for /opt/csw/var -> /var/opt/csw for the same reason. > Small point but there is also a reference to Blastwave in the > script:-( Please adjust the comments accordingly to OpenCSW. Best regards -- Dago From phil at bolthole.com Mon Mar 1 19:18:38 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 1 Mar 2010 10:18:38 -0800 Subject: [csw-maintainers] Duplicate package xextproto/x11_xextproto In-Reply-To: <4B888CE9.40406@opencsw.org> References: <4B888CE9.40406@opencsw.org> Message-ID: On Fri, Feb 26, 2010 at 7:09 PM, Roger H?kansson wrote: > Which package is "the real stuff", xextproto or x11_xextproto? > They both seem to have the exact same content. > whuups. thanks for noticing that. it got left behind after a standardization rename. Since it has nothing depending on it, I'll remove the older xextproto From dam at opencsw.org Tue Mar 2 09:09:25 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 2 Mar 2010 09:09:25 +0100 Subject: [csw-maintainers] Changing the package description for Perl modules Message-ID: Hi, I just noticed that the description for the Perl modules is almost useless as it doesn't contain the module name. I suggest changing the description for Perl packages to - (existing description) by changing the Perl category, so a simple rebuild will suffice. We have the module name anyway available in GAR. Thoughts? Best regards -- Dago From benny at opencsw.org Tue Mar 2 12:24:24 2010 From: benny at opencsw.org (Benjamin von Mossner) Date: Tue, 2 Mar 2010 12:24:24 +0100 Subject: [csw-maintainers] Changing the package description for Perl modules In-Reply-To: References: Message-ID: <20100302112424.GA24153@vonmossner.de> hey, >I suggest changing the description for Perl packages to > - (existing description) > by changing the Perl category, so a simple rebuild will suffice. i like the idea, +1 from my side. benny -- /"\ ASCII RIBBON CAMPAIGN | Benjamin von Mossner \ / AGAINST HTML MAIL | benny at vonmossner.de X / \ multiple exclamation marks are a sure sign of a diseased mind From bonivart at opencsw.org Tue Mar 2 13:38:04 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 2 Mar 2010 13:38:04 +0100 Subject: [csw-maintainers] Changing the package description for Perl modules In-Reply-To: <20100302112424.GA24153@vonmossner.de> References: <20100302112424.GA24153@vonmossner.de> Message-ID: <625385e31003020438n35f99c4fw109c6d8dcf10c133@mail.gmail.com> On Tue, Mar 2, 2010 at 12:24 PM, Benjamin von Mossner wrote: > hey, > >>I suggest changing the description for Perl packages to >> ? - (existing description) >> by changing the Perl category, so a simple rebuild will suffice. > i like the idea, +1 from my side. I also think it would be helpful. Could something similar be done for php and python? -- /peter From maciej at opencsw.org Tue Mar 2 14:49:10 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 2 Mar 2010 13:49:10 +0000 Subject: [csw-maintainers] Changing the package description for Perl modules In-Reply-To: <625385e31003020438n35f99c4fw109c6d8dcf10c133@mail.gmail.com> References: <20100302112424.GA24153@vonmossner.de> <625385e31003020438n35f99c4fw109c6d8dcf10c133@mail.gmail.com> Message-ID: On Tue, Mar 2, 2010 at 12:38 PM, Peter Bonivart wrote: > On Tue, Mar 2, 2010 at 12:24 PM, Benjamin von Mossner wrote: >> hey, >> >>>I suggest changing the description for Perl packages to >>> ? - (existing description) >>> by changing the Perl category, so a simple rebuild will suffice. >> i like the idea, +1 from my side. > > I also think it would be helpful. > > Could something similar be done for php and python? Yes, but I don't know if the description is the best place to put such information. In the case of Python modules it's possible that one package provides more than one module, it would need to be a list. What are the specific use cases that you had in mind Dago? From dam at opencsw.org Tue Mar 2 15:05:10 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 2 Mar 2010 15:05:10 +0100 Subject: [csw-maintainers] Changing the package description for Perl modules In-Reply-To: References: <20100302112424.GA24153@vonmossner.de> <625385e31003020438n35f99c4fw109c6d8dcf10c133@mail.gmail.com> Message-ID: <1E50EA7C-CAB8-41C0-A710-83E010F4F62A@opencsw.org> Hi Maciej, Am 02.03.2010 um 14:49 schrieb Maciej (Matchek) Blizinski: > On Tue, Mar 2, 2010 at 12:38 PM, Peter Bonivart > wrote: >> On Tue, Mar 2, 2010 at 12:24 PM, Benjamin von Mossner > > wrote: >>> hey, >>> >>>> I suggest changing the description for Perl packages to >>>> - (existing description) >>>> by changing the Perl category, so a simple rebuild will suffice. >>> i like the idea, +1 from my side. >> >> I also think it would be helpful. >> >> Could something similar be done for php and python? > > Yes, but I don't know if the description is the best place to put such > information. In the case of Python modules it's possible that one > package provides more than one module, it would need to be a list. > > What are the specific use cases that you had in mind Dago? If I want to install a Perl module I have to look up which package it is in. That means I know it is Config::Augeas on CPAN. This may or may nor translate to CSWpmconfigaugeas, CSWpmcfgaugeas or CSWpmcfgaug. We could also have special variables in the pkginfo which must then find their way to the package database somehow, like PERL_MODULE_NAME=Config::Augeas That's why the description seemsed easiest. Best regards -- Dago From phil at bolthole.com Tue Mar 2 19:14:57 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 2 Mar 2010 10:14:57 -0800 Subject: [csw-maintainers] Changing the package description for Perl modules In-Reply-To: <1E50EA7C-CAB8-41C0-A710-83E010F4F62A@opencsw.org> References: <20100302112424.GA24153@vonmossner.de> <625385e31003020438n35f99c4fw109c6d8dcf10c133@mail.gmail.com> <1E50EA7C-CAB8-41C0-A710-83E010F4F62A@opencsw.org> Message-ID: On Tue, Mar 2, 2010 at 6:05 AM, Dagobert Michelsen wrote: > > If I want to install a Perl module I have to look up which package > it is in. That means I know it is Config::Augeas on CPAN. This may > or may nor translate to CSWpmconfigaugeas, CSWpmcfgaugeas or > CSWpmcfgaug. We could also have special variables in the pkginfo > which must then find their way to the package database somehow, like > ?PERL_MODULE_NAME=Config::Augeas > That's why the description seemsed easiest. > I think that the special variable may be the best approach; some of those CPAN paths are ludicrously long, and would then obscure a meaningful description field. From dam at opencsw.org Tue Mar 2 21:52:38 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 2 Mar 2010 21:52:38 +0100 Subject: [csw-maintainers] Changing the package description for Perl modules In-Reply-To: References: <20100302112424.GA24153@vonmossner.de> <625385e31003020438n35f99c4fw109c6d8dcf10c133@mail.gmail.com> <1E50EA7C-CAB8-41C0-A710-83E010F4F62A@opencsw.org> Message-ID: <77E167FF-6AAB-4CA5-BFA1-8A5214F72160@opencsw.org> Hi Phil, Am 02.03.2010 um 19:14 schrieb Philip Brown: > On Tue, Mar 2, 2010 at 6:05 AM, Dagobert Michelsen > wrote: >> >> If I want to install a Perl module I have to look up which package >> it is in. That means I know it is Config::Augeas on CPAN. This may >> or may nor translate to CSWpmconfigaugeas, CSWpmcfgaugeas or >> CSWpmcfgaug. We could also have special variables in the pkginfo >> which must then find their way to the package database somehow, like >> PERL_MODULE_NAME=Config::Augeas >> That's why the description seemsed easiest. > > I think that the special variable may be the best approach; some of > those CPAN paths are ludicrously long, and would then obscure a > meaningful description field. Ok then. The "upstream name" will then become field no. 9 in the catalog (that's what I meant with package database). It is imperative to have this information available easily on package installation. Best regards -- Dago From skayser at opencsw.org Tue Mar 2 23:19:41 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 02 Mar 2010 23:19:41 +0100 Subject: [csw-maintainers] maintainers email addrs on packages In-Reply-To: References: <4B5796E4.6010701@opencsw.org> <4B60DA3B.4000403@opencsw.org> Message-ID: <4B8D8EFD.1070300@opencsw.org> Philip Brown wrote on 28.01.2010 18:37: > On Wed, Jan 27, 2010 at 4:28 PM, Roger H?kansson wrote: >> Is the mapping based on who's "manager" for a package? >> Then it wouldn't be a problem to give all maintainers "developer "privileges >> to all projects in Mantis, right? > > yes, and yes. > > Excellent idea, thank you. I leave it to our "mantis administrator" to > handle the details. :) > > Although I would appreciate an offlist mention to me, of what the sql > level change is, so that I can update our "new maintainer" proceedures > to give them developer privs on signup. The Mantis administrator is coming a bit late to the party, sorry. First of all thanks for pointing it out Roger! Will coordinate the change with Phil over the next couple of days. Sebastian From maciej at opencsw.org Wed Mar 3 12:22:00 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 3 Mar 2010 11:22:00 +0000 Subject: [csw-maintainers] [GAR] RFD: Custom assertions for packages Message-ID: There are certain packages which are susceptible for certain kind of problems. For instance, we might make sure that isaexec is not used, or that a /opt/csw/bin/sparcv9/foo binary is not present, or that a /opt/csw/lib/libfoo.so library is present in a certain package, or that file foo is present in CSWfoo_devel and not CSWfoo. Such issues could be checked either during build, a part of GAR-driven build process, or later on by checkpkg. Since the tests I'm thinking about are package-specific, it's not possible to write generic checkpkg rules for them. One kind of checks I can think of is about testing the prototype. The GAR interface could look something like this: ASSERT_PROTOTYPE_CONTAINS_CSWfoo = $(bindir)/foo ASSERT_PROTOTYPE_ABSENT_CSWfoo = $(bindir)/sparcv9/foo ASSERT_PROTOTYPE_ABSENT_CSWfoo-devel = .*\.py ASSERT_PROTOTYPE_CONTAINS_CSWpy-foo = .*\.py The idea is that the algorithm/code is the same, you only change the parameters such as package and file names. I can see two general potential solutions for this kind of checks: - it gets checked by GAR right after the application of the PKGFILES_* rules (good because it catches errors early) - information gets packaged up in the package and then is later used by checkpkg (good because it's done together with all the other checks, the flip side is that it requires an additional communication layer which is itself prone to errors and must be tested) Here are some questions: - Which solution looks better to you and why? How would you implement it? - What kind of package-specific checks can you think of? Maciej From dam at opencsw.org Wed Mar 3 15:08:05 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 3 Mar 2010 15:08:05 +0100 Subject: [csw-maintainers] [GAR] RFD: Custom assertions for packages In-Reply-To: References: Message-ID: <96DD19CC-E71A-47C7-8CC5-02188ADABECB@opencsw.org> Hi Maciej, Am 03.03.2010 um 12:22 schrieb Maciej (Matchek) Blizinski: > There are certain packages which are susceptible for certain kind of > problems. For instance, we might make sure that isaexec is not used, > or that a /opt/csw/bin/sparcv9/foo binary is not present, or that a > /opt/csw/lib/libfoo.so library is present in a certain package, or > that file foo is present in CSWfoo_devel and not CSWfoo. > > Such issues could be checked either during build, a part of GAR-driven > build process, or later on by checkpkg. Since the tests I'm thinking > about are package-specific, it's not possible to write generic > checkpkg rules for them. > > One kind of checks I can think of is about testing the prototype. The > GAR interface could look something like this: > > ASSERT_PROTOTYPE_CONTAINS_CSWfoo = $(bindir)/foo > ASSERT_PROTOTYPE_ABSENT_CSWfoo = $(bindir)/sparcv9/foo > ASSERT_PROTOTYPE_ABSENT_CSWfoo-devel = .*\.py > ASSERT_PROTOTYPE_CONTAINS_CSWpy-foo = .*\.py > > The idea is that the algorithm/code is the same, you only change the > parameters such as package and file names. > > I can see two general potential solutions for this kind of checks: > > - it gets checked by GAR right after the application of the PKGFILES_* > rules (good because it catches errors early) > - information gets packaged up in the package and then is later used > by checkpkg (good because it's done together with all the other > checks, the flip side is that it requires an additional communication > layer which is itself prone to errors and must be tested) > > Here are some questions: > - Which solution looks better to you and why? How would you > implement it? > - What kind of package-specific checks can you think of? I prefer checking it in GAR after prototype creation. There should be assertions available to all subsystems generated, similar to PROTOTYPE_MODIFIERS. For now I have put the information at for further work. Best regards -- Dago From phil at bolthole.com Wed Mar 3 18:39:19 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 3 Mar 2010 09:39:19 -0800 Subject: [csw-maintainers] [GAR] RFD: Custom assertions for packages In-Reply-To: References: Message-ID: Sounds interesting. I have no technical implementation suggestions; only a minor quibble about naming: On Wed, Mar 3, 2010 at 3:22 AM, Maciej (Matchek) Blizinski wrote: > > One kind of checks I can think of is about testing the prototype. ?The > GAR interface could look something like this: > > ASSERT_PROTOTYPE_CONTAINS_CSWfoo = $(bindir)/foo > ASSERT_PROTOTYPE_ABSENT_CSWfoo = $(bindir)/sparcv9/foo > ASSERT_PROTOTYPE_ABSENT_CSWfoo-devel = .*\.py > ASSERT_PROTOTYPE_CONTAINS_CSWpy-foo = .*\.py > given the wider intended scope for this, perhaps you might want to call it "ASSERT_PKG_xxxx" rather than "ASSERT_PROTOTYPE_xxx" From maciej at opencsw.org Wed Mar 3 20:16:30 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 3 Mar 2010 19:16:30 +0000 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs gflags, protobuf, protobuf_devel, pro(...) In-Reply-To: References: <201003031806.o23I6Ot4023836@login.bo.opencsw.org> Message-ID: On Wed, Mar 3, 2010 at 6:41 PM, Philip Brown wrote: >> Here's a new package, Google command line option parsing for C++ and Python. >> >> * gflags: new package >> ?+ gflags-1.3,REV=2010.03.03-SunOS5.8-i386-CSW.pkg.gz >> ?+ gflags-1.3,REV=2010.03.03-SunOS5.8-sparc-CSW.pkg.gz > > > Ah... this seems to be another isaexec GAR malfunction :( > > 1 l none /opt/csw/bin/gflags_completions.sh=/opt/csw/bin/isaexec > 1 f none /opt/csw/bin/sparcv8/gflags_completions.sh 0755 root bin 5268 44497 126 > 6668632 > 1 f none /opt/csw/bin/sparcv9/gflags_completions.sh 0755 root bin 5268 44497 126 > 6668663 > > > we need isaexec, on a shellscript? seriously? > Well I suppose there is some theoretical possibility... However, the > two files are identical. Dago, what do you think about this issue? I think I could work around it by excluding $(bindir) from the merging phase. However, in the general case it could be possible that there are some binaries that you want to be handled by isaexec, plus a shellscript which doesn't need it. From dam at opencsw.org Wed Mar 3 21:12:41 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 3 Mar 2010 21:12:41 +0100 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs gflags, protobuf, protobuf_devel, pro(...) In-Reply-To: References: <201003031806.o23I6Ot4023836@login.bo.opencsw.org> Message-ID: Hi Maciej, Am 03.03.2010 um 20:16 schrieb Maciej (Matchek) Blizinski: > On Wed, Mar 3, 2010 at 6:41 PM, Philip Brown wrote: >>> Here's a new package, Google command line option parsing for C++ >>> and Python. >>> >>> * gflags: new package >>> + gflags-1.3,REV=2010.03.03-SunOS5.8-i386-CSW.pkg.gz >>> + gflags-1.3,REV=2010.03.03-SunOS5.8-sparc-CSW.pkg.gz >> >> >> Ah... this seems to be another isaexec GAR malfunction :( >> >> 1 l none /opt/csw/bin/gflags_completions.sh =/opt/csw/bin/isaexec >> 1 f none /opt/csw/bin/sparcv8/gflags_completions.sh 0755 root bin >> 5268 44497 126 >> 6668632 >> 1 f none /opt/csw/bin/sparcv9/gflags_completions.sh 0755 root bin >> 5268 44497 126 >> 6668663 >> >> we need isaexec, on a shellscript? seriously? >> Well I suppose there is some theoretical possibility... However, the >> two files are identical. > > Dago, what do you think about this issue? I think I could work around > it by excluding $(bindir) from the merging phase. However, in the > general case it could be possible that there are some binaries that > you want to be handled by isaexec, plus a shellscript which doesn't > need it. There are two possibilities: 1. You can set ISAEXEC_FILES manually. It default to all files in $(bindir), $(sbindir) and $(libexecdir) 2. You can set ISAEXEC_EXCLUDE_FILES to $(bindir)/ gflags_completions.sh or even %.sh Note the Makefile-wildcard here! On reading this it may be more consistent to use general regexes here. Additionally, I now really think we should change the default to merge only $(libdir) from additional isas and only isaexec on request. Best regards -- Dago From phil at bolthole.com Wed Mar 3 23:44:24 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 3 Mar 2010 14:44:24 -0800 Subject: [csw-maintainers] Changing the package description for Perl modules In-Reply-To: <77E167FF-6AAB-4CA5-BFA1-8A5214F72160@opencsw.org> References: <20100302112424.GA24153@vonmossner.de> <625385e31003020438n35f99c4fw109c6d8dcf10c133@mail.gmail.com> <1E50EA7C-CAB8-41C0-A710-83E010F4F62A@opencsw.org> <77E167FF-6AAB-4CA5-BFA1-8A5214F72160@opencsw.org> Message-ID: On Tue, Mar 2, 2010 at 12:52 PM, Dagobert Michelsen wrote: > We could also have special variables in the pkginfo >>> which must then find their way to the package database somehow, like >>> ?PERL_MODULE_NAME=Config::Augeas >>> That's why the description seemsed easiest. >> >> I think that the special variable may be the best approach; some of >> those CPAN paths are ludicrously long, and would then obscure a >> meaningful description field. > > Ok then. The "upstream name" will then become field no. 9 in the catalog > (that's what I meant with package database). It is imperative to have this > information available easily on package installation. Err, what? WHY?? seems to me it is mostly only important at package creation time. catalog is only for "binary package install" purposes. From bonivart at opencsw.org Thu Mar 4 00:30:09 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 4 Mar 2010 00:30:09 +0100 Subject: [csw-maintainers] Changing the package description for Perl modules In-Reply-To: References: <20100302112424.GA24153@vonmossner.de> <625385e31003020438n35f99c4fw109c6d8dcf10c133@mail.gmail.com> <1E50EA7C-CAB8-41C0-A710-83E010F4F62A@opencsw.org> <77E167FF-6AAB-4CA5-BFA1-8A5214F72160@opencsw.org> Message-ID: <625385e31003031530w29739035r78e3e45e4aa0066e@mail.gmail.com> On Wed, Mar 3, 2010 at 11:44 PM, Philip Brown wrote: > seems to me it is mostly only important at package creation time. > catalog is only for "binary package install" purposes. No, this is not for maintainers, it's for users. When you want to install something, perl modules in this case, you search for what you know, in this case the modules name. It doesn't always match well with our package/catalog names. I think it should go into the package description as originally suggested, then it ends up into the descriptions file and is searchable for users in an easy way. Most module names are 10 chars or less so it shouldn't be a big problem. And the 9th field of the catalog is already taken, right? ;-) -- /peter From hson at opencsw.org Thu Mar 4 03:27:57 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Thu, 04 Mar 2010 03:27:57 +0100 Subject: [csw-maintainers] [csw-devel] SF.net SVN: gar:[8215] csw/mgar/gar/v2 In-Reply-To: References: <4B630AED.7040806@opencsw.org> Message-ID: <4B8F1AAD.8030804@opencsw.org> On 2010-01-29 17:29, Philip Brown wrote: > On Fri, Jan 29, 2010 at 8:21 AM, Roger H?kansson wrote: >> >> >> >> First, ${NAME_MAX_LENGTH} should probably be in the output as well... >> >> When I noticed this I started wondering about the length of the package >> name. >> pkginfo(4) on Solaris 8 states that the maxlength is 9 chars and on Solaris >> 9 it is 32. >> Since we have packages with longer names than 9 chars and they install just >> fine on Solaris 8 I suspect that Sun raised the limit in some patch but >> never fixed the man page. >> But the question is have they raised it to 32 or something else. Does anyone >> know? >> > > It's something like 32, yah. However, that being said, having > super-long package names looks very ugly in system level outputs (eg: > pkginfo), so we discourage it :) the "software name" is supposed to be > the informative one anyway. (Follow-up on a old topic due to the fact that I ran into problem today relating to it) Given that, is there any reason why "software name" also is restricted to 20 chars? From maciej at opencsw.org Thu Mar 4 10:14:57 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 4 Mar 2010 09:14:57 +0000 Subject: [csw-maintainers] rsync-3.0.7 in experimental Message-ID: I've put newly garified rsync-3.0.7 into experimental. It works for me, but I would like to hear from other people before I send it for release. http://mirror.opencsw.org/experimental.html#maciej From bonivart at opencsw.org Thu Mar 4 15:17:05 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 4 Mar 2010 15:17:05 +0100 Subject: [csw-maintainers] rsync-3.0.7 in experimental In-Reply-To: References: Message-ID: <625385e31003040617n614b9302i9b076f0dc6ca2f8f@mail.gmail.com> On Thu, Mar 4, 2010 at 10:14 AM, Maciej (Matchek) Blizinski wrote: > I've put newly garified rsync-3.0.7 into experimental. ?It works for > me, but I would like to hear from other people before I send it for > release. > > http://mirror.opencsw.org/experimental.html#maciej I upgraded on a server where I have a backup script using rsync and it worked just like with 3.0.2 which was what I had before. Not an exhaustive test though. -- /peter From phil at bolthole.com Thu Mar 4 18:48:50 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 4 Mar 2010 09:48:50 -0800 Subject: [csw-maintainers] [csw-devel] SF.net SVN: gar:[8215] csw/mgar/gar/v2 In-Reply-To: <4B8F1AAD.8030804@opencsw.org> References: <4B630AED.7040806@opencsw.org> <4B8F1AAD.8030804@opencsw.org> Message-ID: On Wed, Mar 3, 2010 at 6:27 PM, Roger H?kansson wrote: > On 2010-01-29 17:29, Philip Brown wrote: >> >> It's something like 32, yah. However, that being said, having >> super-long package names looks very ugly in system level outputs (eg: >> pkginfo), so we discourage it :) the "software name" is supposed to be >> the informative one anyway. > > (Follow-up on a old topic due to the fact that I ran into problem today > relating to it) > Given that, is there any reason why "software name" also is restricted to 20 > chars? same reason. for sanity reasons, we need to have a limit somewhere. so both pkgname and software name are limited in the same way. From phil at bolthole.com Thu Mar 4 18:58:19 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 4 Mar 2010 09:58:19 -0800 Subject: [csw-maintainers] Changing the package description for Perl modules In-Reply-To: <625385e31003031530w29739035r78e3e45e4aa0066e@mail.gmail.com> References: <20100302112424.GA24153@vonmossner.de> <625385e31003020438n35f99c4fw109c6d8dcf10c133@mail.gmail.com> <1E50EA7C-CAB8-41C0-A710-83E010F4F62A@opencsw.org> <77E167FF-6AAB-4CA5-BFA1-8A5214F72160@opencsw.org> <625385e31003031530w29739035r78e3e45e4aa0066e@mail.gmail.com> Message-ID: On Wed, Mar 3, 2010 at 3:30 PM, Peter Bonivart wrote: > On Wed, Mar 3, 2010 at 11:44 PM, Philip Brown wrote: >> seems to me it is mostly only important at package creation time. >> catalog is only for "binary package install" purposes. > > No, this is not for maintainers, it's for users. When you want to > install something, perl modules in this case, you search for what you > know, in this case the modules name. It doesn't always match well with > our package/catalog names. Going with the "its for users" argument, can get way out of hand. You have to put a reasonably tight limit on it somewhere, or else you end up with 10 megabyte catalog files, which is just silly. That being said... > I think it should go into the package description as originally > suggested, then it ends up into the descriptions file and is > searchable for users in an easy way. Most module names are 10 chars or > less so it shouldn't be a big problem. I agree, with the following clarification: I/we were being rather loose with the use of "package description". i was shortcutting it and referring to it implicitly as "the 2nd half of the NAME field", ie: NAME=softname - description here Given that that shows up in regular "/usr/bin/pkginfo" output, i was being a little protective of it :-) But if the argument is, "lets put it in the existing DESC field", so that it goes in the descriptions file, and is thus still searchable client-side relatively easily... then thats ok by me. A reminder to folks who are not aware: What goes in the "descriptions" file, is the second half of the NAME field.... *unless* DESC is present, in which case, that takes precedence. > And the 9th field of the catalog is already taken, right? ;-) right :) Although the docs need to be updated. if you remind me where our docs on catalog format are, I'll update it, if need be. From hson at opencsw.org Thu Mar 4 19:45:20 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Thu, 04 Mar 2010 19:45:20 +0100 Subject: [csw-maintainers] pkgname/catalogname length (was [csw-devel] SF.net SVN: gar:[8215] csw/mgar/gar/v2) In-Reply-To: References: <4B630AED.7040806@opencsw.org> <4B8F1AAD.8030804@opencsw.org> Message-ID: <4B8FFFC0.4050901@opencsw.org> On 2010-03-04 18:48, Philip Brown wrote: > On Wed, Mar 3, 2010 at 6:27 PM, Roger H?kansson wrote: >> On 2010-01-29 17:29, Philip Brown wrote: >>> >>> It's something like 32, yah. However, that being said, having >>> super-long package names looks very ugly in system level outputs (eg: >>> pkginfo), so we discourage it :) the "software name" is supposed to be >>> the informative one anyway. >> >> (Follow-up on a old topic due to the fact that I ran into problem today >> relating to it) >> Given that, is there any reason why "software name" also is restricted to 20 >> chars? > > same reason. for sanity reasons, we need to have a limit somewhere. so > both pkgname and software name are limited in the same way. > But if pkgname is restricted to 20 chars and software name is "the informative one anyway", how informative can you be if you have to cut down the upstream name to something that no other dist uses? I can somewhat agree that having a limit less than 22 for pkgname is right (otherwise output from pkginfo looks a bit funky), but then at least software name should be able to be longer. If you are a Solaris-only shop, you might not care what the software name is as long as the description is informative about what the package does. But if you're using a mixed environment or used to Linux/BSD and starts using Solaris, its gonna be harder to find the right package if its called something else than what you're used to (and specially something else than upstream calls it...) For example, mobile-broadband-provider-info would be hard to cut down to something that is even close to its original... From phil at bolthole.com Thu Mar 4 20:19:08 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 4 Mar 2010 11:19:08 -0800 Subject: [csw-maintainers] pkgname/catalogname length (was [csw-devel] SF.net SVN: gar:[8215] csw/mgar/gar/v2) In-Reply-To: <4B8FFFC0.4050901@opencsw.org> References: <4B630AED.7040806@opencsw.org> <4B8F1AAD.8030804@opencsw.org> <4B8FFFC0.4050901@opencsw.org> Message-ID: On Thu, Mar 4, 2010 at 10:45 AM, Roger H?kansson wrote: > > But if pkgname is restricted to 20 chars and software name is "the > informative one anyway", how informative can you be if you have to cut down > the upstream name to something that no other dist uses? "informative" is used loosely :) there are very few software packages that have names even long than 10 chars. all the important ones are under 10, in fact. mozilla firefox bind gnome and so on and so forth. The long package names, tend to be components of larger things. To use the nasty examples of sun package names: SUNWgnome-img-editor-devel-share I would suggest that they arent really that important. They're not suposed to be out-and-out 50 char descriptions. that's what the DESC field is for, after all :) A reminder why they're short: So displays of things like "show software name, pkg name, and revision" fit nicely in a text window. Given that our revision fields can get disgustingly long these days, we need to be relatively conservative about the other fields. Also, having software name get ludicrously long, becomes redundant to the description field eventually. > But if you're using a mixed environment or used to Linux/BSD and starts > using Solaris, its gonna be harder to find the right package if its called > something else than what you're used to (and specially something else than > upstream calls it...) > > For example, mobile-broadband-provider-info would be hard to cut down to > something that is even close to its original... I think that sounds like this is a perfect example of what I'm talking about. That sounds like it belongs as part of a more comprehensive set of packages. Wouldnt most people just be interested in installing "mobile-support", or "mobile-info" or whatever, rather than individually hunting down "mobile-broadband-provider-info" ? The sub-package names are not that important. Particularly when you can have pkg-get -D mobile easily pull up mobile_Whatever - mobile broadband provider info xml tables and info From bonivart at opencsw.org Thu Mar 4 20:49:23 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 4 Mar 2010 20:49:23 +0100 Subject: [csw-maintainers] Changing the package description for Perl modules In-Reply-To: References: <20100302112424.GA24153@vonmossner.de> <625385e31003020438n35f99c4fw109c6d8dcf10c133@mail.gmail.com> <1E50EA7C-CAB8-41C0-A710-83E010F4F62A@opencsw.org> <77E167FF-6AAB-4CA5-BFA1-8A5214F72160@opencsw.org> <625385e31003031530w29739035r78e3e45e4aa0066e@mail.gmail.com> Message-ID: <625385e31003041149g1b549a4chcf920aa4685a6ca6@mail.gmail.com> On Thu, Mar 4, 2010 at 6:58 PM, Philip Brown wrote: > But if the argument is, "lets put it in the existing DESC field", so > that it goes in the descriptions file, and is thus still searchable > client-side relatively easily... then thats ok by me. That's what I meant and I think that's what Dago meant as well. Sample: pm_netdns - Net::DNS. Interface to the DNS resolver -- /peter From maciej at opencsw.org Thu Mar 4 21:13:40 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 4 Mar 2010 20:13:40 +0000 Subject: [csw-maintainers] Evince build issue: can't read /opt/csw/lib/libxml2.la Message-ID: Evince fails with: /opt/csw/bin/gsed: can't read /opt/csw/lib/libxml2.la: No such file or directory The complete error message: http://dpaste.com/167951/ Is it a typical failure mode with a known fix? Maciej From dam at opencsw.org Thu Mar 4 21:41:08 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 4 Mar 2010 21:41:08 +0100 Subject: [csw-maintainers] Changing the package description for Perl modules In-Reply-To: <625385e31003041149g1b549a4chcf920aa4685a6ca6@mail.gmail.com> References: <20100302112424.GA24153@vonmossner.de> <625385e31003020438n35f99c4fw109c6d8dcf10c133@mail.gmail.com> <1E50EA7C-CAB8-41C0-A710-83E010F4F62A@opencsw.org> <77E167FF-6AAB-4CA5-BFA1-8A5214F72160@opencsw.org> <625385e31003031530w29739035r78e3e45e4aa0066e@mail.gmail.com> <625385e31003041149g1b549a4chcf920aa4685a6ca6@mail.gmail.com> Message-ID: Hi Peter, Am 04.03.2010 um 20:49 schrieb Peter Bonivart: > On Thu, Mar 4, 2010 at 6:58 PM, Philip Brown > wrote: >> But if the argument is, "lets put it in the existing DESC field", so >> that it goes in the descriptions file, and is thus still searchable >> client-side relatively easily... then thats ok by me. > > That's what I meant and I think that's what Dago meant as well. > > Sample: > > pm_netdns - Net::DNS. Interface to the DNS resolver This is exactly what I head in mind. In GAR there is the name in the syntax Net-DNS which can be subst of '-' to '::'. The description put into DESC would be "Interface to the DNS resolver" and dynamically appended. Best regards -- Dago From phil at bolthole.com Thu Mar 4 22:14:12 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 4 Mar 2010 13:14:12 -0800 Subject: [csw-maintainers] Changing the package description for Perl modules In-Reply-To: <625385e31003041149g1b549a4chcf920aa4685a6ca6@mail.gmail.com> References: <625385e31003020438n35f99c4fw109c6d8dcf10c133@mail.gmail.com> <1E50EA7C-CAB8-41C0-A710-83E010F4F62A@opencsw.org> <77E167FF-6AAB-4CA5-BFA1-8A5214F72160@opencsw.org> <625385e31003031530w29739035r78e3e45e4aa0066e@mail.gmail.com> <625385e31003041149g1b549a4chcf920aa4685a6ca6@mail.gmail.com> Message-ID: On Thu, Mar 4, 2010 at 11:49 AM, Peter Bonivart wrote: > On Thu, Mar 4, 2010 at 6:58 PM, Philip Brown wrote: >> But if the argument is, "lets put it in the existing DESC field", so >> that it goes in the descriptions file, and is thus still searchable >> client-side relatively easily... then thats ok by me. > > That's what I meant and I think that's what Dago meant as well. > > Sample: > > pm_netdns - Net::DNS. Interface to the DNS resolver > I think we would be better served having it postpended, rather than prepended. Well, i guess it all depends whether people who may view truncated descriptions of our packaged perl modules, would benefit more from english description, or CPAN description. I cant honestly say I know; we might actually need to do a user survey of this. Personally, I think that CPAN ::-:: notation is primarily useful only when you are actually using CPAN. and if you are using CPAN, then you have no need of our description anyway :-} From maciej at opencsw.org Fri Mar 5 09:54:35 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 5 Mar 2010 08:54:35 +0000 Subject: [csw-maintainers] Porting FAQ Message-ID: I've recently had an awesome Solaris porting session with William. Thanks to him I managed to work around things much quicker than it would take me if I had to work out each thing by myself. For instance, when stdint.h was missing, William had an instant answer: use sys/inttypes.h instead. I've started a stub wiki page for these kinds of porting tips. There's also a section with useful links related to Sun Studio and Solaris porting in general. There's also a section about how to quickly create a patch and integrate it with GAR. http://wiki.opencsw.org/porting-faq Whenever you solve a porting issue that looks like a typical problem, please update the wiki to make the world a better place. Maciej From skayser at opencsw.org Fri Mar 5 10:06:59 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 5 Mar 2010 10:06:59 +0100 Subject: [csw-maintainers] Porting FAQ In-Reply-To: References: Message-ID: <20100305090659.GE7613@sebastiankayser.de> * Maciej (Matchek) Blizinski wrote: > I've recently had an awesome Solaris porting session with William. > Thanks to him I managed to work around things much quicker than it > would take me if I had to work out each thing by myself. For > instance, when stdint.h was missing, William had an instant answer: > use sys/inttypes.h instead. > > I've started a stub wiki page for these kinds of porting tips. > There's also a section with useful links related to Sun Studio and > Solaris porting in general. There's also a section about how to > quickly create a patch and integrate it with GAR. > > http://wiki.opencsw.org/porting-faq > > Whenever you solve a porting issue that looks like a typical problem, > please update the wiki to make the world a better place. Very cool! A plea to everyone who adds stuff: please when possible not only add your solutions, but also the rationale behind them, ideally with some references. That way people running into the same issue can not only copy and paste, but also try to understand what is going on and learn at the same time. Sebastian From bwalton at opencsw.org Fri Mar 5 14:12:04 2010 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 05 Mar 2010 08:12:04 -0500 Subject: [csw-maintainers] Porting FAQ In-Reply-To: References: Message-ID: <1267794601-sup-3846@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Fri Mar 05 03:54:35 -0500 2010: > Whenever you solve a porting issue that looks like a typical problem, > please update the wiki to make the world a better place. Sebastian and I have been working on tmpwatch which required adding gnulib support, which in turn meant porting the build system to autoconf/automake. I'll be documenting both of these processes in the wiki and will link them from this page. I think they'll both be long enough to warrant separate entries. Thanks for getting the ball rolling. -Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Fri Mar 5 18:56:49 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 5 Mar 2010 09:56:49 -0800 Subject: [csw-maintainers] Porting FAQ In-Reply-To: References: Message-ID: On Fri, Mar 5, 2010 at 12:54 AM, Maciej (Matchek) Blizinski wrote: > I've recently had an awesome Solaris porting session with William. > Thanks to him I managed to work around things much quicker than it > would take me if I had to work out each thing by myself. ?For > instance, when stdint.h was missing, William had an instant answer: > use sys/inttypes.h instead. > > I've started a stub wiki page for these kinds of porting tips. > There's also a section with useful links related to Sun Studio and > Solaris porting in general. ?There's also a section about how to > quickly create a patch and integrate it with GAR. > > http://wiki.opencsw.org/porting-faq > very cool! thanks for starting this. I see you've referenced one, somewhat modern, [open]solaris porting FAQs out there . You may want to hunt for some of the older ones as well. After all, people have been porting stuff to Solaris for a long time,and there are a few nice old-time ones out there (although its been some time since I've looked one up myself) From dam at opencsw.org Fri Mar 5 19:32:30 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 5 Mar 2010 19:32:30 +0100 Subject: [csw-maintainers] Which x11 library to choose? In-Reply-To: References: <201003040902.o2492h10003745@login.bo.opencsw.org> Message-ID: <6F149BCB-3BDE-4482-9ABB-C6BF036760FA@opencsw.org> Hi, Am 04.03.2010 um 22:08 schrieb Philip Brown: > On Thu, Mar 4, 2010 at 11:30 AM, Maciej (Matchek) Blizinski > wrote: >> On Thu, Mar 4, 2010 at 6:42 PM, Philip Brown >> wrote: >>> On Thu, Mar 4, 2010 at 1:02 AM, Maciej Blizinski >>> wrote: >>>> * roxfiler: minor version upgrade >>>> .. >>> >>> Should this not also depend on CSWlibice? >>> and CSWlibsm? >> >> Exactly, it shouldn't. If you look at the RPATHs of the binaries, it >> uses libraries from Sun. > > Which, for the record, and other people's benefits, is not exactly a > bad thing in and of itself.. it's just bad if it also attempts to use > our new gtk, which needs our newer, non-sun X libs. Exactly. A package should be linked OpenCSW X11 exactly when: - it relies on features only available in OpenCSW X11 or - it is linked together with a binary that is linked against OpenCSW X11 That means if it is standalone application which doesn't require OpenCSW X11 it is good practice to bind against Sun X11. Best regrads -- Dago From dam at opencsw.org Fri Mar 5 19:36:12 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 5 Mar 2010 19:36:12 +0100 Subject: [csw-maintainers] Changing the package description for Perl modules In-Reply-To: References: <625385e31003020438n35f99c4fw109c6d8dcf10c133@mail.gmail.com> <1E50EA7C-CAB8-41C0-A710-83E010F4F62A@opencsw.org> <77E167FF-6AAB-4CA5-BFA1-8A5214F72160@opencsw.org> <625385e31003031530w29739035r78e3e45e4aa0066e@mail.gmail.com> <625385e31003041149g1b549a4chcf920aa4685a6ca6@mail.gmail.com> Message-ID: <8D07C5A4-E6EC-42CF-849A-E48EC8A27237@opencsw.org> Hi Phil, Am 04.03.2010 um 22:14 schrieb Philip Brown: > On Thu, Mar 4, 2010 at 11:49 AM, Peter Bonivart > wrote: >> On Thu, Mar 4, 2010 at 6:58 PM, Philip Brown >> wrote: >>> But if the argument is, "lets put it in the existing DESC field", so >>> that it goes in the descriptions file, and is thus still searchable >>> client-side relatively easily... then thats ok by me. >> >> That's what I meant and I think that's what Dago meant as well. >> >> Sample: >> >> pm_netdns - Net::DNS. Interface to the DNS resolver > > I think we would be better served having it postpended, rather than > prepended. > > Well, i guess it all depends whether people who may view truncated > descriptions of our packaged perl modules, would benefit more from > english description, or CPAN description. > I cant honestly say I know; we might actually need to do a user > survey of this. > > Personally, I think that CPAN ::-:: notation is primarily useful only > when you are actually using CPAN. and if you are using CPAN, then you > have no need of our description anyway :-} My typical usecase it that I know the module name and want to find the matching package/catalog name to install it. Currently the only possibility is to guess the path (like /Net/DNS.pm for the above example) and search in "view package files" page. So I think putting it first would be best like in the example.- Best regards -- Dago From phil at bolthole.com Fri Mar 5 20:43:42 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 5 Mar 2010 11:43:42 -0800 Subject: [csw-maintainers] Changing the package description for Perl modules In-Reply-To: <8D07C5A4-E6EC-42CF-849A-E48EC8A27237@opencsw.org> References: <1E50EA7C-CAB8-41C0-A710-83E010F4F62A@opencsw.org> <77E167FF-6AAB-4CA5-BFA1-8A5214F72160@opencsw.org> <625385e31003031530w29739035r78e3e45e4aa0066e@mail.gmail.com> <625385e31003041149g1b549a4chcf920aa4685a6ca6@mail.gmail.com> <8D07C5A4-E6EC-42CF-849A-E48EC8A27237@opencsw.org> Message-ID: On Fri, Mar 5, 2010 at 10:36 AM, Dagobert Michelsen wrote: > Hi Phil, > *wave* > Am 04.03.2010 um 22:14 schrieb Philip Brown: >.... >> Well, i guess it all depends whether people who may view truncated >> descriptions of our packaged perl modules, would benefit more from >> english description, or CPAN description. >> I cant honestly say I know; we might actually need to do a user survey of >> this. >> > > My typical usecase it that I know the module name and want to > find the matching package/catalog name to install it. > Currently the only possibility is to guess the path (like > /Net/DNS.pm for the above example) and search in "view > package files" page. So I think putting it first would > be best like in the example.- I'm confused... You wrote that you do a search on the package files database. How does that translate to "putting it first in the description would be best"? When you are searching for something based on description in our packages, why would you not use pkg-get -D what-you-what or pkgutil (whatever the syntax is) ? and in that case, as I have mentioned, why would it matter whether the string you want is first, or last? From dam at opencsw.org Fri Mar 5 21:00:27 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 5 Mar 2010 21:00:27 +0100 Subject: [csw-maintainers] Changing the package description for Perl modules In-Reply-To: References: <1E50EA7C-CAB8-41C0-A710-83E010F4F62A@opencsw.org> <77E167FF-6AAB-4CA5-BFA1-8A5214F72160@opencsw.org> <625385e31003031530w29739035r78e3e45e4aa0066e@mail.gmail.com> <625385e31003041149g1b549a4chcf920aa4685a6ca6@mail.gmail.com> <8D07C5A4-E6EC-42CF-849A-E48EC8A27237@opencsw.org> Message-ID: <3BE71627-E29E-41F8-9DE0-1FFDEF68591F@opencsw.org> Hi Phil, Am 05.03.2010 um 20:43 schrieb Philip Brown: >> Am 04.03.2010 um 22:14 schrieb Philip Brown: >> .... >>> Well, i guess it all depends whether people who may view truncated >>> descriptions of our packaged perl modules, would benefit more from >>> english description, or CPAN description. >>> I cant honestly say I know; we might actually need to do a user >>> survey of >>> this. >>> >> >> My typical usecase it that I know the module name and want to >> find the matching package/catalog name to install it. >> Currently the only possibility is to guess the path (like >> /Net/DNS.pm for the above example) and search in "view >> package files" page. So I think putting it first would >> be best like in the example.- > > I'm confused... You wrote that you do a search on the package files > database. > How does that translate to "putting it first in the description > would be best"? > > When you are searching for something based on description in our > packages, why would you not use > > pkg-get -D what-you-what > or pkgutil (whatever the syntax is) > ? There is a mapping in Perl between the module name and the path the module is in. The module Sub::SubSub::Pack is in .../Sub/SubSub/Pack.pm and the module is in the file Sub-SubSub-Pack-.tar.gz As we don't have the module name anywhere now I search for the file instead, but that needs going to a webpage. Having the module name in the description would allow finding it from the catalog. > and in that case, as I have mentioned, why would it matter whether the > string you want is first, or last? It does not. But for me it is more important to have the module name. Best regards -- Dago From hson at opencsw.org Sat Mar 6 12:40:09 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Sat, 06 Mar 2010 12:40:09 +0100 Subject: [csw-maintainers] Which x11 library to choose? In-Reply-To: <6F149BCB-3BDE-4482-9ABB-C6BF036760FA@opencsw.org> References: <201003040902.o2492h10003745@login.bo.opencsw.org> <6F149BCB-3BDE-4482-9ABB-C6BF036760FA@opencsw.org> Message-ID: <4B923F19.6060106@opencsw.org> On 2010-03-05 19:32, Dagobert Michelsen wrote: > > Exactly. A package should be linked OpenCSW X11 exactly when: > - it relies on features only available in OpenCSW X11 > or > - it is linked together with a binary that is linked against > OpenCSW X11 > - And doesn't contain any libraries someone might link with creating other packages. Otherwise we end up with the same problem as we have right now, some packages are linked with Sun X11 and some with OpenCSW X11 and when creating a package which is linked to libraries from both categories we get into trouble. From maciej at opencsw.org Sat Mar 6 12:47:55 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 6 Mar 2010 11:47:55 +0000 Subject: [csw-maintainers] Which x11 library to choose? In-Reply-To: <4B923F19.6060106@opencsw.org> References: <201003040902.o2492h10003745@login.bo.opencsw.org> <6F149BCB-3BDE-4482-9ABB-C6BF036760FA@opencsw.org> <4B923F19.6060106@opencsw.org> Message-ID: On Sat, Mar 6, 2010 at 11:40 AM, Roger H?kansson wrote: > On 2010-03-05 19:32, Dagobert Michelsen wrote: >> >> Exactly. A package should be linked OpenCSW X11 exactly when: >> - it relies on features only available in OpenCSW X11 >> or >> - it is linked together with a binary that is linked against >> OpenCSW X11 >> > > - And doesn't contain any libraries someone might link with creating other > packages. > > > Otherwise we end up with the same problem as we have right now, some > packages are linked with Sun X11 and some with OpenCSW X11 and when creating > a package which is linked to libraries from both categories we get into > trouble. Is it possible to assess how often there are libraries that are not likely to be linked against? I'm asking, because I'm thinking that it might be a good candidate for an automated check. It would go something like this: - if it's a binary, it's OK if it links against Sun X11 - if it's a library which links against Sun X11, throw an error (which may of course be overridden) From maciej at opencsw.org Sat Mar 6 14:23:34 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 6 Mar 2010 13:23:34 +0000 Subject: [csw-maintainers] Adapting /home/testing cleaner to /home/experimental In-Reply-To: <363EBF47-92FA-419B-A66E-9241B409D995@opencsw.org> References: <5122D55F-CFD7-478C-9AD3-0A0BA316590B@opencsw.org> <363EBF47-92FA-419B-A66E-9241B409D995@opencsw.org> Message-ID: On Sat, Feb 27, 2010 at 9:49 PM, Dagobert Michelsen wrote: three days ago[1], and it hasn't been removed from my experimental[2]. [1] http://www.opencsw.org/packages/roxfiler [2] http://mirror.opencsw.org/experimental.html#maciej From maciej at opencsw.org Sun Mar 7 22:25:34 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 7 Mar 2010 21:25:34 +0000 Subject: [csw-maintainers] Porting FAQ In-Reply-To: References: Message-ID: On Fri, Mar 5, 2010 at 5:56 PM, Philip Brown wrote: > You may want to hunt for some of the older ones as well. After all, > people have been porting stuff to Solaris for a long time,and there > are a few nice old-time ones out there (although its been some time > since I've looked one up myself) I did some searching, and added a bunch of links. One of the documents is quite old (1996), it might be one of the ones you had in mind. From dam at opencsw.org Sun Mar 7 22:29:25 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 7 Mar 2010 22:29:25 +0100 Subject: [csw-maintainers] [csw-pkgsubmissions] Subject: newpkgs mercurial In-Reply-To: <6af4271003071322j4c49ecb4l2b556e5f865a5ab2@mail.gmail.com> References: <6af4271003070318r4289f673y95dfedb2994c872b@mail.gmail.com> <6af4271003071322j4c49ecb4l2b556e5f865a5ab2@mail.gmail.com> Message-ID: Hi Rupert, Am 07.03.2010 um 22:22 schrieb rupert THURNER: > i let it run now with "screen" instead of nohup. > > and, i get testing failures - but as these tests take forever i am > not sure if anybody did run them before: > > Running all tests in getopt_tests.py [30/71]...success > Running all tests in basic_tests.py [31/71]...FAILURE > Running all tests in checkout_tests.py [32/71]...success > Running all tests in commit_tests.py [33/71]...FAILURE > Running all tests in update_tests.py [34/71]... On which machine did you try that? Were you using the updated Perl with the patched proposed by Mads? Best regards -- Dago From dam at opencsw.org Sun Mar 7 22:30:44 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 7 Mar 2010 22:30:44 +0100 Subject: [csw-maintainers] Fwd: [csw-buildfarm] mercurial 1.5 testing - locale setting References: <6af4271003071324i547ea2cew1a152f47df1172d0@mail.gmail.com> Message-ID: <4934D136-2E49-4A07-BF5A-155F4869AA9D@opencsw.org> (Fwd'ing maintainers@) Anfang der weitergeleiteten E-Mail: > Von: rupert THURNER > Datum: 7. M?rz 2010 22:24:51 MEZ > An: buildfarm at opencsw.org > Betreff: [csw-buildfarm] mercurial 1.5 testing - locale setting > > is the following mercurial hg-1.5 test a pointless test case or it > says something about our platform as well: > > $ ./run-tests.py test-gendoc > > ERROR: /home/rupert/mgar/pkg/mercurial/trunk/work/solaris8-sparc/ > build-isa-sparcv8/mercurial-1.5/tests/test-gendoc output changed and > returned error code 1 > --- /home/rupert/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build- > isa-sparcv8/mercurial-1.5/tests/test-gendoc.out > +++ /home/rupert/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build- > isa-sparcv8/mercurial-1.5/tests/test-gendoc.err > @@ -1,33 +1,55 @@ > +sh: rst2html: not found > > % extracting documentation from C > checking for parse errors with rst2html > +/home/rupert/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build-isa- > sparcv8/mercurial-1.5/tests/test-gendoc: no: not found > > % extracting documentation from da > +couldn't set locale correctly > checking for parse errors with rst2html > +/home/rupert/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build-isa- > sparcv8/mercurial-1.5/tests/test-gendoc: no: not found > > % extracting documentation from de > +couldn't set locale correctly > checking for parse errors with rst2html > +/home/rupert/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build-isa- > sparcv8/mercurial-1.5/tests/test-gendoc: no: not found > > % extracting documentation from el > +couldn't set locale correctly > checking for parse errors with rst2html > +/home/rupert/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build-isa- > sparcv8/mercurial-1.5/tests/test-gendoc: no: not found > > % extracting documentation from fr > +couldn't set locale correctly > checking for parse errors with rst2html > +/home/rupert/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build-isa- > sparcv8/mercurial-1.5/tests/test-gendoc: no: not found > > % extracting documentation from it > +couldn't set locale correctly > checking for parse errors with rst2html > +/home/rupert/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build-isa- > sparcv8/mercurial-1.5/tests/test-gendoc: no: not found > > % extracting documentation from ja > +couldn't set locale correctly > checking for parse errors with rst2html > +/home/rupert/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build-isa- > sparcv8/mercurial-1.5/tests/test-gendoc: no: not found > > % extracting documentation from pt_BR > +couldn't set locale correctly > checking for parse errors with rst2html > +/home/rupert/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build-isa- > sparcv8/mercurial-1.5/tests/test-gendoc: no: not found > > % extracting documentation from sv > +couldn't set locale correctly > checking for parse errors with rst2html > +/home/rupert/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build-isa- > sparcv8/mercurial-1.5/tests/test-gendoc: no: not found > > % extracting documentation from zh_CN > +couldn't set locale correctly > checking for parse errors with rst2html > +/home/rupert/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build-isa- > sparcv8/mercurial-1.5/tests/test-gendoc: no: not found > > % extracting documentation from zh_TW > +couldn't set locale correctly > checking for parse errors with rst2html > +/home/rupert/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build-isa- > sparcv8/mercurial-1.5/tests/test-gendoc: no: not found > ! > Failed test-gendoc: output changed and returned error code 1 > # Ran 1 tests, 0 skipped, 1 failed. > > _______________________________________________ > buildfarm mailing list > buildfarm at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/buildfarm -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sun Mar 7 23:01:39 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 7 Mar 2010 22:01:39 +0000 Subject: [csw-maintainers] gcc doesn't display any error and yet fails to build a binary Message-ID: I'm building a piece of software with gcc and it's displaying strange behavior: the compilation succeeds, but linking fails. Interestingly, it doesn't show any error message. It just fails to produce a binary and returns a non-zero exit code. maciej at netra ~/src/opencsw/pkg/awesome/trunk $ (cd /home/maciej/src/opencsw/pkg/awesome/trunk/work/build-isa-sparcv8/awesome-3.4.4/.build-netra.chopin.edu.pl-sparc-sun-solaris2.8-4.3.3; /opt/csw/gcc4/bin/gcc -O2 -pipe -mcpu=v8 -O3 -DNDEBUG -L/opt/csw/gcc4/lib/. -mcpu=v8 -L/opt/csw/lib -export-dynamic CMakeFiles/awesome.dir/awesome.c.o CMakeFiles/awesome.dir/client.c.o CMakeFiles/awesome.dir/strut.c.o CMakeFiles/awesome.dir/dbus.c.o CMakeFiles/awesome.dir/root.c.o CMakeFiles/awesome.dir/event.c.o CMakeFiles/awesome.dir/property.c.o CMakeFiles/awesome.dir/ewmh.c.o CMakeFiles/awesome.dir/key.c.o CMakeFiles/awesome.dir/keygrabber.c.o CMakeFiles/awesome.dir/mousegrabber.c.o CMakeFiles/awesome.dir/banning.c.o CMakeFiles/awesome.dir/luaa.c.o CMakeFiles/awesome.dir/spawn.c.o CMakeFiles/awesome.dir/hooks.c.o CMakeFiles/awesome.dir/mouse.c.o CMakeFiles/awesome.dir/button.c.o CMakeFiles/awesome.dir/screen.c.o CMakeFiles/awesome.dir/stack.c.o CMakeFiles/awesome.dir/selection.c.o CMakeFiles/awesome.dir/wibox.c.o CMakeFiles/awesome.dir/systray.c.o CMakeFiles/awesome.dir/tag.c.o CMakeFiles/awesome.dir/titlebar.c.o CMakeFiles/awesome.dir/widget.c.o CMakeFiles/awesome.dir/window.c.o CMakeFiles/awesome.dir/image.c.o CMakeFiles/awesome.dir/draw.c.o CMakeFiles/awesome.dir/font.c.o CMakeFiles/awesome.dir/color.c.o CMakeFiles/awesome.dir/timer.c.o CMakeFiles/awesome.dir/common/buffer.c.o CMakeFiles/awesome.dir/common/atoms.c.o CMakeFiles/awesome.dir/common/util.c.o CMakeFiles/awesome.dir/common/version.c.o CMakeFiles/awesome.dir/common/xembed.c.o CMakeFiles/awesome.dir/common/xutil.c.o CMakeFiles/awesome.dir/common/xcursor.c.o CMakeFiles/awesome.dir/common/backtrace.c.o CMakeFiles/awesome.dir/common/luaobject.c.o CMakeFiles/awesome.dir/common/luaclass.c.o CMakeFiles/awesome.dir/widgets/graph.c.o CMakeFiles/awesome.dir/widgets/progressbar.c.o CMakeFiles/awesome.dir/widgets/textbox.c.o CMakeFiles/awesome.dir/widgets/systray.c.o CMakeFiles/awesome.dir/widgets/imagebox.c.o CMakeFiles/awesome.dir/common/tokenize.c.o -o awesome -L/usr/local/lib -lxcb -L/opt/csw/X11/lib -lxcb -lX11 -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -lxcb-randr -lxcb-xtest -lxcb-xinerama -lxcb-shape -lxcb-aux -lxcb-keysyms -lxcb-icccm -lxcb-atom -lxcb-image -lxcb-shm -lxcb-property -lxcb-event -lcairo -lxcb-render-util -lxcb-render -lxcb -lstartup-notification-1 -lImlib2 -lxdg-basedir /opt/csw/lib/libev.so /opt/csw/lib/liblua.so -lm -L/opt/csw/lib -ldbus-1 -lxcb -lX11 -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -lxcb-randr -lxcb-xtest -lxcb-xinerama -lxcb-shape -lxcb-aux -lxcb-keysyms -lxcb-icccm -lxcb-atom -lxcb-image -lxcb-shm -lxcb-property -lxcb-event -lcairo -lxcb-render-util -lxcb-render -lstartup-notification-1 -lImlib2 -lxdg-basedir -lm -ldbus-1 -Wl,-R/usr/local/lib:/opt/csw/lib: -liconv) maciej at netra ~/src/opencsw/pkg/awesome/trunk $ echo $? 1 Any ideas what is going on in here? Why is there no error message? Maciej From rupert at opencsw.org Sun Mar 7 23:45:20 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 7 Mar 2010 23:45:20 +0100 Subject: [csw-maintainers] [csw-pkgsubmissions] Subject: newpkgs mercurial In-Reply-To: References: <6af4271003070318r4289f673y95dfedb2994c872b@mail.gmail.com> <6af4271003071322j4c49ecb4l2b556e5f865a5ab2@mail.gmail.com> Message-ID: <6af4271003071445g6a124611vbe4a96cbc9a71b22@mail.gmail.com> On Sun, Mar 7, 2010 at 22:29, Dagobert Michelsen wrote: > Hi Rupert, > > Am 07.03.2010 um 22:22 schrieb rupert THURNER: > > i let it run now with "screen" instead of nohup. >> >> and, i get testing failures - but as these tests take forever i am not >> sure if anybody did run them before: >> >> Running all tests in getopt_tests.py [30/71]...success >> Running all tests in basic_tests.py [31/71]...FAILURE >> Running all tests in checkout_tests.py [32/71]...success >> Running all tests in commit_tests.py [33/71]...FAILURE >> Running all tests in update_tests.py [34/71]... >> > > On which machine did you try that? Were you using the updated Perl with > the patched proposed by Mads? > > > on build8s, in fact a high percentage of the tests fail. see here: http://svn.pastebin.com/egK3PZjZ for details. rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Mon Mar 8 01:56:13 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 07 Mar 2010 19:56:13 -0500 Subject: [csw-maintainers] gnulib how to Message-ID: <1268009672-sup-6203@apps.cquest.utoronto.ca> Hi All, I've finished the first draft of the 'how to integrate gnulib' wiki page. If anyone is interested in reading it, I'd be interested in feedback on unclear wording, topics that need more depth, etc. http://wiki.opencsw.org/adding-gnulib I'll work on the autoconf/automake how to in the next few days. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Mon Mar 8 07:30:44 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 8 Mar 2010 07:30:44 +0100 Subject: [csw-maintainers] [csw-pkgsubmissions] Subject: newpkgs mercurial In-Reply-To: <6af4271003071445g6a124611vbe4a96cbc9a71b22@mail.gmail.com> References: <6af4271003070318r4289f673y95dfedb2994c872b@mail.gmail.com> <6af4271003071322j4c49ecb4l2b556e5f865a5ab2@mail.gmail.com> <6af4271003071445g6a124611vbe4a96cbc9a71b22@mail.gmail.com> Message-ID: <68B9B53D-16E2-4B30-A03D-E3CFDD731F2E@opencsw.org> Hi Rupert, Am 07.03.2010 um 23:45 schrieb rupert THURNER: > On Sun, Mar 7, 2010 at 22:29, Dagobert Michelsen > wrote: > Hi Rupert, > > Am 07.03.2010 um 22:22 schrieb rupert THURNER: > > i let it run now with "screen" instead of nohup. > > and, i get testing failures - but as these tests take forever i am > not sure if anybody did run them before: > > Running all tests in getopt_tests.py [30/71]...success > Running all tests in basic_tests.py [31/71]...FAILURE > Running all tests in checkout_tests.py [32/71]...success > Running all tests in commit_tests.py [33/71]...FAILURE > Running all tests in update_tests.py [34/71]... > > On which machine did you try that? Were you using the updated Perl > with > the patched proposed by Mads? > > on build8s, in fact a high percentage of the tests fail. see here: http://svn.pastebin.com/egK3PZjZ > for details. I updated all build machines with a current Python, please retry the tests (possibly with a slightly lower parallelism ;-) Best regards -- Dago From maciej at opencsw.org Mon Mar 8 11:50:24 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 8 Mar 2010 10:50:24 +0000 Subject: [csw-maintainers] Detecting the dependency on CSWdbus (was: Re: evince-2.24.2 in experimental) Message-ID: On Mon, Mar 8, 2010 at 7:30 AM, gerard wrote: > hello, > it fails for me, on sparc solaris 10: > mombasa-henry% /opt/csw/bin/evince > > ** (evince:1643): WARNING **: Error connecting to D-Bus: Failed to connect > to socket /tmp/dbus-3zKwnd1mUE: No such file or directory > > ** (evince:1643): WARNING **: Service registration failed. > > ** (evince:1643): WARNING **: Failed to connect to socket > /tmp/dbus-3zKwnd1mUE: No such file or directory > Segmentation fault (core dumped) The shared library linking check detected that evince needs to depend on CSWlibdbus, but evince needs the dbus daemon running in order to work. Every time this kind of a problem occurs, I'm thinking hard how to write an automated check for it, or find another way to make sure that the issue doesn't happen again. One idea would be to assume that whatever needs CSWlibdbus also needs CSWdbus. A version of that is what I did with the CSWpython-rt package - just get rid of it, because it's unhelpful anyway. There's an easy way to falsify this theory: find an example of a package that needs libdbus but doesn't need a running daemon. Another way would be to detect whether the application makes actual calls to the dbus API, and therefore needs the daemon to run. Thoughts? Maciej From bonivart at opencsw.org Mon Mar 8 13:33:17 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 8 Mar 2010 13:33:17 +0100 Subject: [csw-maintainers] pkgutil 1.10 beta 1: testing needed Message-ID: <625385e31003080433s1439954er11ca573c18f390da@mail.gmail.com> I have packaged a beta of pkgutil 1.10 here: http://mirror.opencsw.org/experimental.html#bonivart I would appreciate it if a few of you could try it, you don't have to commit to any deep testing, all I'm asking for is some everyday use to see if it blows up. :-) I've used it myself for a while and my goal is to release it within a few days if nothing surfaces. Take a look at the pkgutil wiki if you want to know more, http://pkgutil.wikidot.com/, see the release history for details about what's new. Thank you. -- /peter From dlm at opencsw.org Mon Mar 8 15:42:12 2010 From: dlm at opencsw.org (david) Date: Mon, 08 Mar 2010 15:42:12 +0100 Subject: [csw-maintainers] CSWoldap In-Reply-To: <625385e31003080433s1439954er11ca573c18f390da@mail.gmail.com> References: <625385e31003080433s1439954er11ca573c18f390da@mail.gmail.com> Message-ID: <4B950CC4.9030000@opencsw.org> I am progressing slowly with the testing I have updated the paths in the start script and SMF is almost OK. The problem that I have now is that the manifest that I have in my trunk/files is not being used. I can manually import it and it works fine. The manifest file is in trunk/files and is openldap.xml, after install this file should end up here: /var/opt/csw/method/manifest/network Then it would be imported into SMF by the postinstall. The file doesn't seem to end as part of the package even though it is in the Makefile: DISTFILES += cswopenldap openldap.xml svc-openldap The manifest ends up being this one here which does not work, any suggestions are much appreciated: From bonivart at opencsw.org Mon Mar 8 15:55:02 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 8 Mar 2010 15:55:02 +0100 Subject: [csw-maintainers] CSWoldap In-Reply-To: <4B950CC4.9030000@opencsw.org> References: <625385e31003080433s1439954er11ca573c18f390da@mail.gmail.com> <4B950CC4.9030000@opencsw.org> Message-ID: <625385e31003080655p3047defdma39a6cbd0f76dded@mail.gmail.com> On Mon, Mar 8, 2010 at 3:42 PM, david wrote: > I am progressing slowly with the testing I have updated the paths in the > start script and SMF is almost OK. The problem that I have now is that the > manifest that I have in my trunk/files is not being used. I can manually > import it and it works fine. The manifest file is in trunk/files and is > openldap.xml, after install this file should end up here: > > /var/opt/csw/method/manifest/network > > Then it would be imported into SMF by the postinstall. > > The file doesn't seem to end as part of the package even though it is in the > Makefile: > > DISTFILES += cswopenldap openldap.xml svc-openldap > > The manifest ends up being this one here which does not work, any > suggestions are much appreciated: > > > '/usr/share/lib/xml/dtd/service_bundle.dtd.1'> > This is the standard manifest autogenerated when you use the initsmf class. I'm interested in why it doesn't work but you're free to use a custom manifest instead. Just use a magic comment in your start script and point it to your own manifest and it will be used. You should not try to mess with this in postinstall. #MANIFEST /absolute/path/to/manifest # If set, use this manifest instead See http://wiki.opencsw.org/cswclassutils-package#toc7. -- /peter From dlm at opencsw.org Mon Mar 8 16:25:23 2010 From: dlm at opencsw.org (david) Date: Mon, 08 Mar 2010 16:25:23 +0100 Subject: [csw-maintainers] CSWoldap In-Reply-To: <625385e31003080655p3047defdma39a6cbd0f76dded@mail.gmail.com> References: <625385e31003080433s1439954er11ca573c18f390da@mail.gmail.com> <4B950CC4.9030000@opencsw.org> <625385e31003080655p3047defdma39a6cbd0f76dded@mail.gmail.com> Message-ID: <4B9516E3.2080403@opencsw.org> OK thanks Peter Bonivart wrote: > On Mon, Mar 8, 2010 at 3:42 PM, david wrote: > >> I am progressing slowly with the testing I have updated the paths in the >> start script and SMF is almost OK. The problem that I have now is that the >> manifest that I have in my trunk/files is not being used. I can manually >> import it and it works fine. The manifest file is in trunk/files and is >> openldap.xml, after install this file should end up here: >> >> /var/opt/csw/method/manifest/network >> >> Then it would be imported into SMF by the postinstall. >> >> The file doesn't seem to end as part of the package even though it is in the >> Makefile: >> >> DISTFILES += cswopenldap openldap.xml svc-openldap >> >> The manifest ends up being this one here which does not work, any >> suggestions are much appreciated: >> >> >> > '/usr/share/lib/xml/dtd/service_bundle.dtd.1'> >> >> > > This is the standard manifest autogenerated when you use the initsmf > class. I'm interested in why it doesn't work but you're free to use a > custom manifest instead. Just use a magic comment in your start script > and point it to your own manifest and it will be used. You should not > try to mess with this in postinstall. > > #MANIFEST /absolute/path/to/manifest # If set, use this manifest instead > > See http://wiki.opencsw.org/cswclassutils-package#toc7. > > From phil at bolthole.com Mon Mar 8 18:50:45 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 8 Mar 2010 09:50:45 -0800 Subject: [csw-maintainers] Detecting the dependency on CSWdbus (was: Re: evince-2.24.2 in experimental) In-Reply-To: References: Message-ID: On Mon, Mar 8, 2010 at 2:50 AM, Maciej (Matchek) Blizinski wrote: > > The shared library linking check detected that evince needs to depend > on CSWlibdbus, but evince needs the dbus daemon running in order to > work. ?Every time this kind of a problem occurs, I'm thinking hard how > to write an automated check for it, or find another way to make sure > that the issue doesn't happen again. > If you can solidly prove (to yourself, no formal writeup needed) that libdbus is useless without dbus, then you may be best off merging. Contrariwise, there is still probably a concept of "required runtime" vs "other". So maybe the "rt" package needs both the lib and the demon, but the top level gets "devel" stuff? Hrrm. there's already a dbus_devel. maybe dbus_rt should just become a stub after all. comparing... debian packages that seem of interest would be: libdbus, dbus-x11, dbus-utils, and plain ol' "dbus". there's a bit of a mixup.. the description of "dbus" claims, "This package contains the D-Bus daemon and related utilities. " if so, why is there aa separate dbus-1-utils package I wonder. oh, its only a virtual package, in recent releases. It DOES sound like a nice idea to have a separate splitoff for x11. But you'd have to do some research on how exactly that happens. Possibly our dbus_glib is effectively the same thing. > Another way would be to detect whether the application makes actual > calls to the dbus API, and therefore needs the daemon to run. contrariwise, look at the api, and see if there is any use whatsoever in any of the API calls if there is no demon running. From skayser at opencsw.org Mon Mar 8 19:03:05 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 8 Mar 2010 19:03:05 +0100 Subject: [csw-maintainers] librsync 0.9.7 uploaded to testing In-Reply-To: <20090920221939.GA25482@vm-1.bch.net> References: <20090920221939.GA25482@vm-1.bch.net> Message-ID: <20100308180305.GB26602@sebastiankayser.de> Hi Brian, * Brian Hill wrote: > I have uploaded librsync for testing. It isn't all that useful > by itself, but it is needed for rdiff-backup, which is coming soon. > > Does the descriptions file update at regular intervals or is it > done by hand? A pkg-get of librsync from testing doesn't work yet. just wondering: was there any follow-up action on librsync? Just wanted to package csync2 which relies on librsync, i.e. I really could use librsync now. Are you still interested in publishing this package? Would be great! Otherwise, did you build it locally or is there a build recipe in GAR (couldn't find one)? Sebastian From phil at bolthole.com Mon Mar 8 19:10:23 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 8 Mar 2010 10:10:23 -0800 Subject: [csw-maintainers] Which x11 library to choose? In-Reply-To: References: <201003040902.o2492h10003745@login.bo.opencsw.org> <6F149BCB-3BDE-4482-9ABB-C6BF036760FA@opencsw.org> <4B923F19.6060106@opencsw.org> Message-ID: On Sat, Mar 6, 2010 at 3:47 AM, Maciej (Matchek) Blizinski wrote: > >> Otherwise we end up with the same problem as we have right now, some >> packages are linked with Sun X11 and some with OpenCSW X11 and when creating >> a package which is linked to libraries from both categories we get into >> trouble. > > Is it possible to assess how often there are libraries that are not > likely to be linked against? > > I'm asking, because I'm thinking that it might be a good candidate for > an automated check. I dont think its possible to make an automated check. Because it mostly boils down to you having to "magically know", if the library you are packaging, will ever be needed/wanted by a program that uses GNOME/gtk. Thus, the default presumtion these days, is "it needs CSW x11 libs, unless know know it wont". This is the core around my original reticence for us to embark upon our own set of X11 libs (a year ago or more?) which I emailed to the list at the time; once we start using them in core stuff; from then on, almost all our X11 related programs will then have to use them also. But we decided the benefit was better than the alternative...so now, most stuff must use our X11 libs. From maciej at opencsw.org Mon Mar 8 19:16:03 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 8 Mar 2010 18:16:03 +0000 Subject: [csw-maintainers] Which x11 library to choose? In-Reply-To: References: <201003040902.o2492h10003745@login.bo.opencsw.org> <6F149BCB-3BDE-4482-9ABB-C6BF036760FA@opencsw.org> <4B923F19.6060106@opencsw.org> Message-ID: On Mon, Mar 8, 2010 at 6:10 PM, Philip Brown wrote: > On Sat, Mar 6, 2010 at 3:47 AM, Maciej (Matchek) Blizinski > wrote: >> >>> Otherwise we end up with the same problem as we have right now, some >>> packages are linked with Sun X11 and some with OpenCSW X11 and when creating >>> a package which is linked to libraries from both categories we get into >>> trouble. >> >> Is it possible to assess how often there are libraries that are not >> likely to be linked against? >> >> I'm asking, because I'm thinking that it might be a good candidate for >> an automated check. > > I dont think its possible to make an automated check. Because it > mostly boils down to you having to "magically know", if the library > you are packaging, will ever be needed/wanted by a program that uses > GNOME/gtk. > > Thus, the default presumtion these days, is "it needs CSW x11 libs, > unless know know it wont". The automated check could work as follows: - if it's a binary, it's okay if it links against the Sun X11. - if it's a library, throw an error if it links against the Sun X11. If the maintainer knows it doesn't need to use X11 libs, the error tag can be overriden. Would such check make our packages better? From bchill at opencsw.org Mon Mar 8 19:31:57 2010 From: bchill at opencsw.org (Brian Hill) Date: Mon, 08 Mar 2010 10:31:57 -0800 Subject: [csw-maintainers] librsync 0.9.7 uploaded to testing In-Reply-To: <20100308180305.GB26602@sebastiankayser.de> References: <20090920221939.GA25482@vm-1.bch.net> <20100308180305.GB26602@sebastiankayser.de> Message-ID: <4B95429D.2070502@opencsw.org> Hi Sebastian, I did the original testing build on my SunOS 5.8 SPARC. I have been intending to migrate it to GAR, but GAR seemed like a moving target for a while. I have been reading as much of the GAR-related email as I could keep up with, but... Is there an up-to-date GAR how-to? If so, I'll get both packages (librsync and rdiff-backup) up there today or tomorrow. There are others I'd like to do as well. Brian On 3/8/10 10:03 AM, Sebastian Kayser wrote: > Hi Brian, > > * Brian Hill wrote: > >> I have uploaded librsync for testing. It isn't all that useful >> by itself, but it is needed for rdiff-backup, which is coming soon. >> >> Does the descriptions file update at regular intervals or is it >> done by hand? A pkg-get of librsync from testing doesn't work yet. >> > just wondering: was there any follow-up action on librsync? Just wanted > to package csync2 which relies on librsync, i.e. I really could use > librsync now. Are you still interested in publishing this package? Would > be great! Otherwise, did you build it locally or is there a build recipe > in GAR (couldn't find one)? > > Sebastian > From phil at bolthole.com Mon Mar 8 19:36:17 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 8 Mar 2010 10:36:17 -0800 Subject: [csw-maintainers] Which x11 library to choose? In-Reply-To: References: <201003040902.o2492h10003745@login.bo.opencsw.org> <6F149BCB-3BDE-4482-9ABB-C6BF036760FA@opencsw.org> <4B923F19.6060106@opencsw.org> Message-ID: On Mon, Mar 8, 2010 at 10:16 AM, Maciej (Matchek) Blizinski wrote: > > The automated check could work as follows: > > - if it's a binary, it's okay if it links against the Sun X11. if and only iff nothing in its depency chain uses CSW libs, or has /opt/csw/X11/lib in its path. you would have to recursively parse the entire tree. App libOne.so libTwo.so libThree.so libFour.so libFive.so libSix.so libSeven.so ALL dynamic objects above, would have to be parsed, for "App". > - if it's a library, throw an error if it links against the Sun X11. > > If the maintainer knows it doesn't need to use X11 libs, the error tag > can be overriden. > > Would such check make our packages better? Possibly. It would be good if the error message explicitly explained how to override it, and also an explaination of when it is appropriate vs not appropriate. From maciej at opencsw.org Mon Mar 8 19:46:09 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 8 Mar 2010 18:46:09 +0000 Subject: [csw-maintainers] librsync 0.9.7 uploaded to testing In-Reply-To: <4B95429D.2070502@opencsw.org> References: <20090920221939.GA25482@vm-1.bch.net> <20100308180305.GB26602@sebastiankayser.de> <4B95429D.2070502@opencsw.org> Message-ID: On Mon, Mar 8, 2010 at 6:31 PM, Brian Hill wrote: > Hi Sebastian, > > I did the original testing build on my SunOS 5.8 SPARC. I have been > intending to migrate it to GAR, but GAR seemed like a moving target for a > while. > > I have been reading as much of the GAR-related email as I could keep up > with, but... > > Is there an up-to-date GAR how-to? The basics of GAR haven't changed in quite a long time. There are some new features when it comes to 64-bit builds and merges on x86 (gmake platforms). The basic tutorial is here: https://sourceforge.net/apps/trac/gar/wiki/ExplainedGperf -- It looks up-to-date enough at the first glance. Do you have to build separately for Solaris 9 or 10? Do you need to compile and merge multiple versions of your software? Do you need different patches for different versions of the software? If the answer to any of these questions is "yes", you'll need something beyond the basic tutorial. As far as patches are concerned, http://wiki.opencsw.org/porting-faq#toc5 has a copy&paste example how to create a patch in GAR. Maciej From bwalton at opencsw.org Mon Mar 8 19:52:59 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 08 Mar 2010 13:52:59 -0500 Subject: [csw-maintainers] Which x11 library to choose? In-Reply-To: References: <201003040902.o2492h10003745@login.bo.opencsw.org> <6F149BCB-3BDE-4482-9ABB-C6BF036760FA@opencsw.org> <4B923F19.6060106@opencsw.org> Message-ID: <1268074332-sup-620@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Mar 08 13:36:17 -0500 2010: > if and only iff nothing in its depency chain uses CSW libs, or has Great typo! :) /sent from the dept of redundancy dept! -Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From roger.hakansson at gmail.com Mon Mar 8 21:55:23 2010 From: roger.hakansson at gmail.com (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Mon, 08 Mar 2010 21:55:23 +0100 Subject: [csw-maintainers] Detecting the dependency on CSWdbus (was: Re: evince-2.24.2 in experimental) In-Reply-To: References: Message-ID: <4B95643B.3020302@gmail.com> Maciej (Matchek) Blizinski wrote: > One idea would be to assume that whatever needs CSWlibdbus also needs > CSWdbus. A version of that is what I did with the CSWpython-rt > package - just get rid of it, because it's unhelpful anyway. There's > an easy way to falsify this theory: find an example of a package that > needs libdbus but doesn't need a running daemon. imagemagick depends on librsvg, which depends on gnomevfs2, which depends on libdbus and dbus (currently, however thre are no actual dependency other than). But imagemagick can use librsvg for reading and creating SVG files without having dbus running. From phil at bolthole.com Mon Mar 8 22:26:05 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 8 Mar 2010 13:26:05 -0800 Subject: [csw-maintainers] Detecting the dependency on CSWdbus (was: Re: evince-2.24.2 in experimental) In-Reply-To: <4B95643B.3020302@gmail.com> References: <4B95643B.3020302@gmail.com> Message-ID: On Mon, Mar 8, 2010 at 12:55 PM, Roger H?kansson wrote: > Maciej (Matchek) Blizinski wrote: >> >> One idea would be to assume that whatever needs CSWlibdbus also needs >> CSWdbus. ?A version of that is what I did with the CSWpython-rt >> package - just get rid of it, because it's unhelpful anyway. ?There's >> an easy way to falsify this theory: find an example of a package that >> needs libdbus but doesn't need a running daemon. > > imagemagick depends on librsvg, which depends on gnomevfs2 ... the question there is; why does an IMAGE LIBRARY, depend on a FILESYSTEM library?!! we should do all we can, to cut that dependency. From phil at bolthole.com Mon Mar 8 22:32:08 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 8 Mar 2010 13:32:08 -0800 Subject: [csw-maintainers] Detecting the dependency on CSWdbus (was: Re: evince-2.24.2 in experimental) In-Reply-To: References: <4B95643B.3020302@gmail.com> Message-ID: On Mon, Mar 8, 2010 at 1:26 PM, Philip Brown wrote: .... > the question there is; why does an IMAGE LIBRARY, depend on a > FILESYSTEM library?!! > > we should do all we can, to cut that dependency. > looking at http://packages.debian.org/sid/librsvg2-2 one might guess the culprit is that we havent split off the stuff in bin. "That other project" has librsvg2-bin. >From which we might instead have "librsvg2_utils" or something, to match our existing defacto naming with other packages. From skayser at opencsw.org Mon Mar 8 19:51:43 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 8 Mar 2010 19:51:43 +0100 Subject: [csw-maintainers] librsync 0.9.7 uploaded to testing In-Reply-To: <4B95429D.2070502@opencsw.org> References: <20090920221939.GA25482@vm-1.bch.net> <20100308180305.GB26602@sebastiankayser.de> <4B95429D.2070502@opencsw.org> Message-ID: <20100308185143.GC26602@sebastiankayser.de> * Brian Hill wrote: > I did the original testing build on my SunOS 5.8 SPARC. I have been > intending to migrate it to GAR, but GAR seemed like a moving target for > a while. > > I have been reading as much of the GAR-related email as I could keep up > with, but... > > Is there an up-to-date GAR how-to? > > If so, I'll get both packages (librsync and rdiff-backup) up there today > or tomorrow. There are others I'd like to do as well. That was quick, good to hear from you! Regarding GAR, there are a couple of pages on http://gar.opencsw.org (redirects to sf.net) which are good for a start: The packaging tutorial which goes through the general process for two packages [1] and the GAR variable reference which describes GAR variables and their purpose [2]. You don't need to understand everything to get started, most things are for special cases and can easily be learnt later. After getting the basic understanding of GAR, you can re-build an existing package from the repository just to see an example build from start to end. Then, the easiest way IMHO is to have a look at some build description from very active maintainers (e.g. Dago, Maciej) and see how they do things with GAR (have the GAR reference ready). I took the liberty to commit an example build description for librsync which works for me [3]. You can just take that and adapt it to your needs. In case you have questions, just ask on maintainers, pop my on #opencsw on freenode [4], or drop me an email. The first two options will likely get you more timely replies :) HTH and thanks for helping out Sebastian [1]http://sourceforge.net/apps/trac/gar/wiki/GarPackagingTutorial [2]http://sourceforge.net/apps/trac/gar/wiki/GAR%20Variable%20Reference [3]https://gar.svn.sf.net/svnroot/gar/csw/mgar/pkg/librsync/trunk/Makefile [4]http://webchat.freenode.net/?channels=opencsw From hson at opencsw.org Mon Mar 8 22:48:13 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Mon, 08 Mar 2010 22:48:13 +0100 Subject: [csw-maintainers] Detecting the dependency on CSWdbus (was: Re: evince-2.24.2 in experimental) In-Reply-To: References: <4B95643B.3020302@gmail.com> Message-ID: <4B95709D.4070508@opencsw.org> On 2010-03-08 22:26, Philip Brown wrote: > On Mon, Mar 8, 2010 at 12:55 PM, Roger H?kansson > wrote: >> Maciej (Matchek) Blizinski wrote: >>> >>> One idea would be to assume that whatever needs CSWlibdbus also needs >>> CSWdbus. A version of that is what I did with the CSWpython-rt >>> package - just get rid of it, because it's unhelpful anyway. There's >>> an easy way to falsify this theory: find an example of a package that >>> needs libdbus but doesn't need a running daemon. >> >> imagemagick depends on librsvg, which depends on gnomevfs2 ... > > > the question there is; why does an IMAGE LIBRARY, depend on a > FILESYSTEM library?!! Because it includes /opt/csw/lib/gtk-2.0/2.10.0/loaders/svg_loader.so and /opt/csw/lib/gtk-2.0/2.10.0/engines/libsvg.so (which I intend to put in a separate package when I repackage next time) From phil at bolthole.com Mon Mar 8 23:02:32 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 8 Mar 2010 14:02:32 -0800 Subject: [csw-maintainers] Detecting the dependency on CSWdbus (was: Re: evince-2.24.2 in experimental) In-Reply-To: References: <4B95643B.3020302@gmail.com> Message-ID: On Mon, Mar 8, 2010 at 1:32 PM, Philip Brown wrote: > On Mon, Mar 8, 2010 at 1:26 PM, Philip Brown wrote: > .... >> the question there is; why does an IMAGE LIBRARY, depend on a >> FILESYSTEM library?!! >> >> we should do all we can, to cut that dependency. >> > Hmm. actually, digging a little deeper, (in addition to your later message, Roger), it would seem that only the backwards compat version directly needs gnomevfs librsvg-2.so.2.15.90 From jgoerzen at opencsw.org Tue Mar 9 00:40:31 2010 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Mon, 8 Mar 2010 15:40:31 -0800 Subject: [csw-maintainers] Error: Ambiguous "?:" expression Message-ID: <315c02ae1003081540y4d9aeb73j861c8ea323d096a4@mail.gmail.com> Hello, Would some one with C++ knowledge help me out? I've run into an error compiling wesnoth version 1.6.5 using Sun Studio 11. The relevant compiler error message: "marked-up_text.cpp", line 222: Error: Ambiguous "?:" expression, second operand of type "surface" and third operand of type "int" can be converted to one another. the relevant part of marked-up_text.cpp (line 222) contains: return draw_text(gui != NULL ? gui->getSurface() : NULL, area, size, colour, txt, x, y, use_tooltips, style); Is there some syntax I can add/modify to this statement that will clear up the ambiguity the compiler is complaining about? Thanks, Jake From phil at bolthole.com Tue Mar 9 01:24:24 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 8 Mar 2010 16:24:24 -0800 Subject: [csw-maintainers] Error: Ambiguous "?:" expression In-Reply-To: <315c02ae1003081540y4d9aeb73j861c8ea323d096a4@mail.gmail.com> References: <315c02ae1003081540y4d9aeb73j861c8ea323d096a4@mail.gmail.com> Message-ID: On Mon, Mar 8, 2010 at 3:40 PM, Jake Goerzen wrote: > "marked-up_text.cpp", line 222: Error: Ambiguous "?:" expression, > second operand of type "surface" and third operand of type "int" can > be converted to one another. > > the relevant part of marked-up_text.cpp (line 222) contains: > > ? ? ? ?return draw_text(gui != NULL ? gui->getSurface() : NULL, area, > size, colour, txt, x, y, use_tooltips, style); > > > Is there some syntax I can add/modify to this statement that will > clear up the ambiguity the compiler is complaining about? > its a matter of guessing parenthesis.sss..sss depending on how many args draw_text usually takes, I guess you want.. erm.. well, the simple way would be return draw_text( (gui != NULL ? gui->getSurface() : NULL) , area, size, colour, txt, x, y, use_tooltips, style); I would guess. this is actually a C question, not a C++ question, but the overloading possibilities in C++ just make it more potentially confusing to figure out the "correct" answer. From hson at opencsw.org Tue Mar 9 03:12:30 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Tue, 09 Mar 2010 03:12:30 +0100 Subject: [csw-maintainers] Error: Ambiguous "?:" expression In-Reply-To: <315c02ae1003081540y4d9aeb73j861c8ea323d096a4@mail.gmail.com> References: <315c02ae1003081540y4d9aeb73j861c8ea323d096a4@mail.gmail.com> Message-ID: <4B95AE8E.7060301@opencsw.org> On 2010-03-09 00:40, Jake Goerzen wrote: > "marked-up_text.cpp", line 222: Error: Ambiguous "?:" expression, > second operand of type "surface" and third operand of type "int" can > be converted to one another. > > the relevant part of marked-up_text.cpp (line 222) contains: > > return draw_text(gui != NULL ? gui->getSurface() : NULL, area, > size, colour, txt, x, y, use_tooltips, style); > > > Is there some syntax I can add/modify to this statement that will > clear up the ambiguity the compiler is complaining about? > My interpretation is that the problem is that the surface class have operators both for converting a surface object to an int as well as converting a int to a surface object and that code is not clear on what's the desired way. I had a quick look at the code in your homedir and draw_text is defined in font.cpp and takes a surface object as first parameter so you probably want to change that line to: return draw_text((gui != NULL ? gui->getSurface() : (surface)NULL), area, size, colour, txt, x, y, use_tooltips, style); From jgoerzen at opencsw.org Tue Mar 9 05:23:51 2010 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Mon, 8 Mar 2010 20:23:51 -0800 Subject: [csw-maintainers] Error: Ambiguous "?:" expression In-Reply-To: <4B95AE8E.7060301@opencsw.org> References: <315c02ae1003081540y4d9aeb73j861c8ea323d096a4@mail.gmail.com> <4B95AE8E.7060301@opencsw.org> Message-ID: <315c02ae1003082023m54d4543ud64b1ba0217843ba@mail.gmail.com> On Mon, Mar 8, 2010 at 6:12 PM, Roger H?kansson wrote: > On 2010-03-09 00:40, Jake Goerzen wrote: >> >> "marked-up_text.cpp", line 222: Error: Ambiguous "?:" expression, >> second operand of type "surface" and third operand of type "int" can >> be converted to one another. >> >> the relevant part of marked-up_text.cpp (line 222) contains: >> >> ? ? ? ? return draw_text(gui != NULL ? gui->getSurface() : NULL, area, >> size, colour, txt, x, y, use_tooltips, style); >> >> >> Is there some syntax I can add/modify to this statement that will >> clear up the ambiguity the compiler is complaining about? >> > > My interpretation is that the problem is that the surface class have > operators both for converting a surface object to an int as well as > converting a int to a surface object and that code is not clear on what's > the desired way. > > I had a quick look at the code in your homedir and draw_text is defined in > font.cpp and takes a surface object as first parameter so you probably want > to change that line to: > > return draw_text((gui != NULL ? gui->getSurface() : (surface)NULL), area, > size, colour, txt, x, y, use_tooltips, style); > > _______________________________________________ Thank you. I made this change and compiling continued for a long time then stopped... "./gui/widgets/generator.hpp", line 303: Warning: gui2::tgenerator_::find_widget Hides the virtual function gui2::twidget::find_widget(const std::string &, const bool) const in a virtual base. "./gui/widgets/generator.hpp", line 303: Warning: gui2::tgenerator_::find_widget Hides the virtual function gui2::twidget::find_widget(const std::string &, const bool) in a virtual base. "./gui/widgets/generator_private.hpp", line 76: Warning: gui2::policy::minimum_selection::tone::create_item Hides the virtual function gui2::tgenerator_::create_item(const int, boost::intrusive_ptr, const std::map&, void(*)(gui2::twidget*)) in a virtual base. "./gui/widgets/generator_private.hpp", line 76: Warning: gui2::policy::minimum_selection::tone::create_item Hides the virtual function gui2::tgenerator_::create_item(const int, boost::intrusive_ptr, const std::map >&, void(*)(gui2::twidget*)) in a virtual base. "./gui/widgets/generator_private.hpp", line 100: Warning: gui2::policy::minimum_selection::tnone::create_item Hides the virtual function gui2::tgenerator_::create_item(const int, boost::intrusive_ptr, const std::map&, void(*)(gui2::twidget*)) in a virtual base."./gui/widgets/generator_private.hpp", line 100: Warning: gui2::policy::minimum_selection::tnone::create_item Hides the virtual function gui2::tgenerator_::create_item(const int, boost::intrusive_ptr, const std::map >&, void(*)(gui2::twidget*)) in a virtual base. "./gui/widgets/generator_private.hpp", line 131: Warning: gui2::policy::maximum_selection::tone::select_item Hides the virtual function gui2::tgenerator_::select_item(const unsigned, const bool) in a virtual base. "./gui/widgets/generator_private.hpp", line 141: Warning: gui2::policy::maximum_selection::tinfinite::select_item Hides the virtual function gui2::tgenerator_::select_item(const unsigned, const bool) in a virtual base. "./gui/widgets/generator_private.hpp", line 173: Error: "gui2::policy::placement::thorizontal_list::calculate_best_size() const" is expected to return a value. "./gui/widgets/generator_private.hpp", line 201: Error: "gui2::policy::placement::thorizontal_list::find_widget(const gui2::tpoint&, const bool)" is expected to return a value. "./gui/widgets/generator_private.hpp", line 205: Error: "gui2::policy::placement::thorizontal_list::find_widget(const gui2::tpoint&, const bool) const" is expected to return a value. "./gui/widgets/generator_private.hpp", line 224: Warning: gui2::policy::placement::thorizontal_list::create_item Hides the virtual function gui2::tgenerator_::create_item(const int, boost::intrusive_ptr, const std::map&, void(*)(gui2::twidget*)) in a virtual base. "./gui/widgets/generator_private.hpp", line 224: Warning: gui2::policy::placement::thorizontal_list::create_item Hides the virtual function gui2::tgenerator_::create_item(const int, boost::intrusive_ptr, const std::map >&, void(*)(gui2::twidget*)) in a virtual base. "./gui/widgets/generator_private.hpp", line 284: Warning: gui2::policy::placement::tvertical_list::create_item Hides the virtual function gui2::tgenerator_::create_item(const int, boost::intrusive_ptr, const std::map&, void(*)(gui2::twidget*)) in a virtual base. "./gui/widgets/generator_private.hpp", line 284: Warning: gui2::policy::placement::tvertical_list::create_item Hides the virtual function gui2::tgenerator_::create_item(const int, boost::intrusive_ptr, const std::map >&, void(*)(gui2::twidget*)) in a virtual base. "./gui/widgets/generator_private.hpp", line 302: Error: "gui2::policy::placement::tmatrix::calculate_best_size() const" is expected to return a value. "./gui/widgets/generator_private.hpp", line 317: Error: "gui2::policy::placement::tmatrix::find_widget(const gui2::tpoint&, const bool)" is expected to return a value. "./gui/widgets/generator_private.hpp", line 321: Error: "gui2::policy::placement::tmatrix::find_widget(const gui2::tpoint&, const bool) const" is expected to return a value. "./gui/widgets/generator_private.hpp", line 340: Warning: gui2::policy::placement::tmatrix::create_item Hides the virtual function gui2::tgenerator_::create_item(const int, boost::intrusive_ptr, const std::map&, void(*)(gui2::twidget*)) in a virtual base. "./gui/widgets/generator_private.hpp", line 340: Warning: gui2::policy::placement::tmatrix::create_item Hides the virtual function gui2::tgenerator_::create_item(const int, boost::intrusive_ptr, const std::map >&, void(*)(gui2::twidget*)) in a virtual base. "./gui/widgets/generator_private.hpp", line 357: Error: "gui2::policy::placement::tindependant::calculate_best_size() const" is expected to return a value."./gui/widgets/generator_private.hpp", line 372: Error: "gui2::policy::placement::tindependant::find_widget(const gui2::tpoint&, const bool)" is expected to return a value. "./gui/widgets/generator_private.hpp", line 376: Error: "gui2::policy::placement::tindependant::find_widget(const gui2::tpoint&, const bool) const" is expected to return a value. "./gui/widgets/generator_private.hpp", line 395: Warning: gui2::policy::placement::tindependant::create_item Hides the virtual function gui2::tgenerator_::create_item(const int, boost::intrusive_ptr, const std::map&, void(*)(gui2::twidget*)) in a virtual base. "./gui/widgets/generator_private.hpp", line 395: Warning: gui2::policy::placement::tindependant::create_item Hides the virtual function gui2::tgenerator_::create_item(const int, boost::intrusive_ptr, const std::map >&, void(*)(gui2::twidget*)) in a virtual base. "gui/widgets/generator.cpp", line 95: Warning: grid hides gui2::tgenerator_::grid. "gui/widgets/generator.cpp", line 122: Warning: grid hides gui2::tgenerator_::grid. "gui/widgets/generator.cpp", line 142: Warning: grid hides gui2::tgenerator_::grid. "gui/widgets/generator.cpp", line 159: Warning: grid hides gui2::tgenerator_::grid. "gui/widgets/generator.cpp", line 172: Warning: grid hides gui2::tgenerator_::grid. "gui/widgets/generator.cpp", line 192: Warning: grid hides gui2::tgenerator_::grid. "gui/widgets/generator.cpp", line 253: Warning: grid hides gui2::tgenerator_::grid. 9 Error(s) and 23 Warning(s) detected. gmake[4]: *** [gui/widgets/generator.o] Error 9 gmake[4]: Leaving directory `/home/jgoerzen/mgar/wesnoth/trunk/work/solaris8-sparc/build-isa-sparcv8/wesnoth-1.6.5/src' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/home/jgoerzen/mgar/wesnoth/trunk/work/solaris8-sparc/build-isa-sparcv8/wesnoth-1.6.5' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/jgoerzen/mgar/wesnoth/trunk/work/solaris8-sparc/build-isa-sparcv8/wesnoth-1.6.5' gmake[1]: *** [build-work/solaris8-sparc/build-isa-sparcv8/wesnoth-1.6.5/Makefile] Error 2 gmake[1]: Leaving directory `/home/jgoerzen/mgar/wesnoth/trunk' gmake: *** [build-isa-sparcv8] Error 2 From maciej at opencsw.org Tue Mar 9 09:09:34 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 9 Mar 2010 08:09:34 +0000 Subject: [csw-maintainers] update-mime-database said: Note that '/opt/csw/share' is not in the search path Message-ID: I had a problem in which evince didn't look for the right MIME database when I asked it to display a PDF file. Running update-mime-database showed: netra ~ # update-mime-database /opt/csw/share/mime Note that '/opt/csw/share' is not in the search path set by the XDG_DATA_HOME and XDG_DATA_DIRS environment variables, so applications may not be able to find it until you set them. The directories currently searched are: - /root/.local/share - /usr/local/share/ - /usr/share/ After setting XDG_DATA_DIRS to /opt/csw/share, evince started showing PDF documents. What is our way of handling it? Have the users configure the XDG_DATA_DIRS variable for themselves? Embed this setting in each application? Any other way? Maciej From maciej at opencsw.org Tue Mar 9 09:16:29 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 9 Mar 2010 08:16:29 +0000 Subject: [csw-maintainers] gnulib how to In-Reply-To: <1268009672-sup-6203@apps.cquest.utoronto.ca> References: <1268009672-sup-6203@apps.cquest.utoronto.ca> Message-ID: On Mon, Mar 8, 2010 at 12:56 AM, Ben Walton wrote: > > Hi All, > > I've finished the first draft of the 'how to integrate gnulib' wiki > page. ?If anyone is interested in reading it, I'd be interested in > feedback on unclear wording, topics that need more depth, etc. > > http://wiki.opencsw.org/adding-gnulib This howto tells about gnulib in general. How about making it more GAR-specific? There are lots of detail to how to integrate the merging of gnulib into gar. For example: - first, you need to gmake extract - initialize a git repository in work/.../foo-1.2.3 - then gmake patch (if any patches are there already) - submit the patches to git - do some stuff - submit to git - do more stuff - submit to git again (to separate from the previous stuff) - use git-format-patch etc. There can be also the step of adding a pre-configure target (autoreconf?) to the Makefile. What do you think? Maciej From dam at opencsw.org Tue Mar 9 09:45:02 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 9 Mar 2010 09:45:02 +0100 Subject: [csw-maintainers] gnulib how to In-Reply-To: References: <1268009672-sup-6203@apps.cquest.utoronto.ca> Message-ID: <9986B3FA-C634-4DC6-8E11-E1E7142C7694@opencsw.org> Hi Maciej, Am 09.03.2010 um 09:16 schrieb Maciej (Matchek) Blizinski: > On Mon, Mar 8, 2010 at 12:56 AM, Ben Walton > wrote: >> I've finished the first draft of the 'how to integrate gnulib' wiki >> page. If anyone is interested in reading it, I'd be interested in >> feedback on unclear wording, topics that need more depth, etc. >> >> http://wiki.opencsw.org/adding-gnulib > > This howto tells about gnulib in general. How about making it more > GAR-specific? There are lots of detail to how to integrate the > merging of gnulib into gar. > > For example: > > - first, you need to gmake extract > - initialize a git repository in work/.../foo-1.2.3 > - then gmake patch (if any patches are there already) > - submit the patches to git > - do some stuff > - submit to git > - do more stuff > - submit to git again (to separate from the previous stuff) > - use git-format-patch > > etc. > > There can be also the step of adding a pre-configure target > (autoreconf?) to the Makefile. > > What do you think? Good idea. Additionally, you have made some work towards git-patching in GAR. What is missing there for release? It would make things easier. Especially the patch-rebuild-update the patch-cycle. Best regards -- Dago From hson at opencsw.org Tue Mar 9 09:56:18 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Tue, 09 Mar 2010 09:56:18 +0100 Subject: [csw-maintainers] Error: Ambiguous "?:" expression In-Reply-To: <315c02ae1003082023m54d4543ud64b1ba0217843ba@mail.gmail.com> References: <315c02ae1003081540y4d9aeb73j861c8ea323d096a4@mail.gmail.com> <4B95AE8E.7060301@opencsw.org> <315c02ae1003082023m54d4543ud64b1ba0217843ba@mail.gmail.com> Message-ID: <4B960D32.40105@opencsw.org> On 2010-03-09 05:23, Jake Goerzen wrote: > > Thank you. I made this change and compiling continued for a long time > then stopped... > Report to upstream, I'm no C++ guru, but in my mind that seems like code that isn't really following the standard. Sun Studio 11 isn't really that perfect either, but even 12 U1 doesn't compile that code so I would say that they use some kind of gcc-ism... From maciej at opencsw.org Tue Mar 9 11:00:03 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 9 Mar 2010 10:00:03 +0000 Subject: [csw-maintainers] gnulib how to In-Reply-To: <9986B3FA-C634-4DC6-8E11-E1E7142C7694@opencsw.org> References: <1268009672-sup-6203@apps.cquest.utoronto.ca> <9986B3FA-C634-4DC6-8E11-E1E7142C7694@opencsw.org> Message-ID: On Tue, Mar 9, 2010 at 8:45 AM, Dagobert Michelsen wrote: > Good idea. Additionally, you have made some work towards git-patching > in GAR. What is missing there for release? It would make things easier. > Especially the patch-rebuild-update the patch-cycle. I couldn't get it to work cleanly. The idea was that you could do gmake clean and gar would restore the git repository from a copy in another directory. But perhaps it's not worth the hassle, and I should make a simple case to work first, and merge it back to v2. From bonivart at opencsw.org Tue Mar 9 13:26:42 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 9 Mar 2010 13:26:42 +0100 Subject: [csw-maintainers] Help wanted with testing Perl 5.10.1 and associated packages Message-ID: <625385e31003090426k71920690sd7cbed6a17a42e34@mail.gmail.com> After building a huge number of packages, especially Dagobert and Benjamin did many of the hard ones, we're now ready to test Perl 5.10.1 in a more integrated way. About 80 modules containing shared libraries had to be rebuilt against the new 5.10.1. It also affected about 10 other packages that had to be rebuilt. Also four (module) packages were identified as having been integrated into newer Perl so we have no need for them, they have been emptied (to avoid file collisions) and one will be dropped (nothing depends on it). You can see more details on our project page on the wiki: http://wiki.opencsw.org/project-perl Please see if you use any of the packages listed, or just Perl itself, and install it from the experimental branch. Give us feedback regardless if it works or not, both are interesting to us. http://mirror.opencsw.org/experimental.html#perl -- /peter From bwalton at opencsw.org Tue Mar 9 15:27:31 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 09 Mar 2010 09:27:31 -0500 Subject: [csw-maintainers] update-mime-database said: Note that '/opt/csw/share' is not in the search path In-Reply-To: References: Message-ID: <1268144811-sup-1542@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Tue Mar 09 03:09:34 -0500 2010: > After setting XDG_DATA_DIRS to /opt/csw/share, evince started showing > PDF documents. What is our way of handling it? Have the users > configure the XDG_DATA_DIRS variable for themselves? Embed this > setting in each application? Any other way? Does evince offer a configure option to specify the default search path? That's how much of the xml stuff works. -Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bwalton at opencsw.org Tue Mar 9 15:22:17 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 09 Mar 2010 09:22:17 -0500 Subject: [csw-maintainers] gnulib how to In-Reply-To: References: <1268009672-sup-6203@apps.cquest.utoronto.ca> Message-ID: <1268144306-sup-7390@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Tue Mar 09 03:16:29 -0500 2010: > What do you think? I think that's great feedback. I'll look at adding that info tonight. As for git-patch integration in GAR, I haven't seen a way to do it both cleanly and in a way that is the same or less work than the existing method (which is currently broken, I believe). I still find it easier to extract the source externally from GAR and do the git + patch creation there, which is already documented...This is somewhat more flexible, as I can go back to the local git repo later and modify, recreate, extend, remove, etc, patches. For true, easy GAR integration, we might want to look at making the 'garchive' target turn whatever the upstream source is into a git repo...this is no easy feat though. Thanks -Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Tue Mar 9 16:28:24 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 9 Mar 2010 15:28:24 +0000 Subject: [csw-maintainers] update-mime-database said: Note that '/opt/csw/share' is not in the search path In-Reply-To: <1268144811-sup-1542@pinkfloyd.chass.utoronto.ca> References: <1268144811-sup-1542@pinkfloyd.chass.utoronto.ca> Message-ID: On Tue, Mar 9, 2010 at 2:27 PM, Ben Walton wrote: > Excerpts from Maciej (Matchek) Blizinski's message of Tue Mar 09 03:09:34 -0500 2010: > >> After setting XDG_DATA_DIRS to /opt/csw/share, evince started showing >> PDF documents. ?What is our way of handling it? ?Have the users >> configure the XDG_DATA_DIRS variable for themselves? ?Embed this >> setting in each application? ?Any other way? > > Does evince offer a configure option to specify the default search > path? ?That's how much of the xml stuff works. I've checked for that and haven't found such option. I've found /usr/local/share paths hardcoded in update-mime-database.c, but I'm not sure whether changing it there would affect the place where evince looks for data. The base problem is that I don't know how exactly this resolution is working in evince. I've read the basedir spec[1], but it was somewhat unsatisfactory. It mentioned the default /etc/xdg and /usr/share, and mentioned the environment variables, but it didn't say anything about other means of supplying the information, nor did say that other ways do not or should not exist. [1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html From phil at bolthole.com Tue Mar 9 17:27:17 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 9 Mar 2010 08:27:17 -0800 Subject: [csw-maintainers] Error: Ambiguous "?:" expression In-Reply-To: <4B960D32.40105@opencsw.org> References: <315c02ae1003081540y4d9aeb73j861c8ea323d096a4@mail.gmail.com> <4B95AE8E.7060301@opencsw.org> <315c02ae1003082023m54d4543ud64b1ba0217843ba@mail.gmail.com> <4B960D32.40105@opencsw.org> Message-ID: On Tue, Mar 9, 2010 at 12:56 AM, Roger H?kansson wrote: > > Report to upstream, I'm no C++ guru, but in my mind that seems like code > that isn't really following the standard. > Sun Studio 11 isn't really that perfect either, but even 12 U1 doesn't > compile that code so I would say that they use some kind of gcc-ism... > in some cases, its not so much that they use a feature of gcc,but that they rely on default behaviour of it. That being said... I vaguely recall that, back in the day, there are warning flags in gcc you can turn on, that make it (almost) as cautious about these things as sun studio. So, an even better thing for you to look into, would be to see if you can find the g++ flag that triggers a warning on the original code, then suggest to upstream, "please compile with these flags from now on". From phil at bolthole.com Tue Mar 9 17:30:13 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 9 Mar 2010 08:30:13 -0800 Subject: [csw-maintainers] update-mime-database said: Note that '/opt/csw/share' is not in the search path In-Reply-To: References: Message-ID: On Tue, Mar 9, 2010 at 12:09 AM, Maciej (Matchek) Blizinski wrote: > I had a problem in which evince didn't look for the right MIME > database when I asked it to display a PDF file. ?Running > update-mime-database showed: > > netra ~ # update-mime-database /opt/csw/share/mime > > Note that '/opt/csw/share' is not in the search path > set by the XDG_DATA_HOME and XDG_DATA_DIRS > environment variables, so applications may not > be able to find it until you set them. The > directories currently searched are: > > > - /root/.local/share > - /usr/local/share/ > - /usr/share/ Where do those defaults come from? > > > After setting XDG_DATA_DIRS to /opt/csw/share, evince started showing > PDF documents. ?What is our way of handling it? ?Have the users > configure the XDG_DATA_DIRS variable for themselves? ?Embed this > setting in each application? ?Any other way? ideally, we find an underlying core related library that has the defaults compiled in, and patch it. >The base problem is that I don't know how exactly >this resolution is working in evince. GDB is your friend? :-} From maciej at opencsw.org Tue Mar 9 17:43:34 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 9 Mar 2010 16:43:34 +0000 Subject: [csw-maintainers] update-mime-database said: Note that '/opt/csw/share' is not in the search path In-Reply-To: References: Message-ID: On Tue, Mar 9, 2010 at 4:30 PM, Philip Brown wrote: > On Tue, Mar 9, 2010 at 12:09 AM, Maciej (Matchek) Blizinski > wrote: >> I had a problem in which evince didn't look for the right MIME >> database when I asked it to display a PDF file. ?Running >> update-mime-database showed: >> >> netra ~ # update-mime-database /opt/csw/share/mime >> >> Note that '/opt/csw/share' is not in the search path >> set by the XDG_DATA_HOME and XDG_DATA_DIRS >> environment variables, so applications may not >> be able to find it until you set them. The >> directories currently searched are: >> >> >> - /root/.local/share >> - /usr/local/share/ >> - /usr/share/ > > Where do those defaults come from? Hardcoded in update-mime-database.c. maciej at build8s [build8s]:~/src/opencsw/pkg/shared-mime-info/trunk > ggrep -A3 -B3 -r usr/local work/solaris8-sparc/build-isa-sparcv8/shared-mime-info-0.71/update-mime-database.c env = getenv("XDG_DATA_DIRS"); if (!env) env = "/usr/local/share/"PATH_SEPARATOR"/usr/share/"; dirs = g_strsplit(env, PATH_SEPARATOR, 0); g_return_if_fail(dirs != NULL); for (n = 0; dirs[n]; n++) I don't think that the values hardcoded in update-mime-database.d are propagated to client applications. >> >> >> After setting XDG_DATA_DIRS to /opt/csw/share, evince started showing >> PDF documents. ?What is our way of handling it? ?Have the users >> configure the XDG_DATA_DIRS variable for themselves? ?Embed this >> setting in each application? ?Any other way? > > > ideally, we find an underlying core related library that has the > defaults compiled in, and patch it. That was what I was thinking too. The question is which library that is. libxdg_basedir? Sounds plausible, but evince doesn't use it. >>The base problem is that I don't know how exactly >>this resolution is working in evince. > > GDB is your friend? ?:-} Did you mean: xdb? ;-) From maciej at opencsw.org Tue Mar 9 17:45:33 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 9 Mar 2010 16:45:33 +0000 Subject: [csw-maintainers] update-mime-database said: Note that '/opt/csw/share' is not in the search path In-Reply-To: References: Message-ID: On Tue, Mar 9, 2010 at 4:43 PM, Maciej (Matchek) Blizinski wrote: >> GDB is your friend? ?:-} > > Did you mean: xdb? ;-) I think I meant dbx. In either case, I'd like to avoid spending too much time on it. The alternative is replugging the monitor cable... From bwalton at opencsw.org Tue Mar 9 17:52:40 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 09 Mar 2010 11:52:40 -0500 Subject: [csw-maintainers] update-mime-database said: Note that '/opt/csw/share' is not in the search path In-Reply-To: References: Message-ID: <1268153476-sup-9269@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Tue Mar 09 11:43:34 -0500 2010: > Hardcoded in update-mime-database.c. > env = "/usr/local/share/"PATH_SEPARATOR"/usr/share/"; If the project is using autoconf, this could be quickly patched to use $(datadir):/usr/local/share...I'd patch that for you if you don't like mucking with autoconf. Thanks -Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phil at bolthole.com Tue Mar 9 18:12:17 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 9 Mar 2010 09:12:17 -0800 Subject: [csw-maintainers] update-mime-database said: Note that '/opt/csw/share' is not in the search path In-Reply-To: <1268153476-sup-9269@pinkfloyd.chass.utoronto.ca> References: <1268153476-sup-9269@pinkfloyd.chass.utoronto.ca> Message-ID: On Tue, Mar 9, 2010 at 8:52 AM, Ben Walton wrote: > Excerpts from Maciej (Matchek) Blizinski's message of Tue Mar 09 11:43:34 -0500 2010: > >> Hardcoded in update-mime-database.c. >> ? ? ? ? ? ? ? ? env = "/usr/local/share/"PATH_SEPARATOR"/usr/share/"; > > If the project is using autoconf, this could be quickly patched to use > $(datadir):/usr/local/share...I'd patch that for you if you don't like > mucking with autoconf. > well, however it happens, we should patch update-mime-database to not look under /usr/local - that's just a bad idea all 'round. From bwalton at opencsw.org Tue Mar 9 18:27:34 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 09 Mar 2010 12:27:34 -0500 Subject: [csw-maintainers] update-mime-database said: Note that '/opt/csw/share' is not in the search path In-Reply-To: References: <1268153476-sup-9269@pinkfloyd.chass.utoronto.ca> Message-ID: <1268155536-sup-5726@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue Mar 09 12:12:17 -0500 2010: > well, however it happens, we should patch update-mime-database to not > look under /usr/local - that's just a bad idea all 'round. Bad if --prefix, etc are used in the build. Good otherwise, as a 'stab in the dark' default. I guess the autoconfing of this file would only need to make $(datadir) the default though, as that covers the lack of --prefix situation too. -Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Tue Mar 9 18:27:44 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 9 Mar 2010 17:27:44 +0000 Subject: [csw-maintainers] update-mime-database said: Note that '/opt/csw/share' is not in the search path In-Reply-To: References: <1268153476-sup-9269@pinkfloyd.chass.utoronto.ca> Message-ID: On Tue, Mar 9, 2010 at 5:12 PM, Philip Brown wrote: > On Tue, Mar 9, 2010 at 8:52 AM, Ben Walton wrote: >> Excerpts from Maciej (Matchek) Blizinski's message of Tue Mar 09 11:43:34 -0500 2010: >> >>> Hardcoded in update-mime-database.c. >>> ? ? ? ? ? ? ? ? env = "/usr/local/share/"PATH_SEPARATOR"/usr/share/"; >> >> If the project is using autoconf, this could be quickly patched to use >> $(datadir):/usr/local/share...I'd patch that for you if you don't like >> mucking with autoconf. >> > > well, however it happens, ?we should patch update-mime-database to not > look under /usr/local - that's just a bad idea all 'round. There's also the question whether patching update-mime-database.c will have any effect on the client applications. Chances are, there will be none. From phil at bolthole.com Tue Mar 9 18:29:49 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 9 Mar 2010 09:29:49 -0800 Subject: [csw-maintainers] update-mime-database said: Note that '/opt/csw/share' is not in the search path In-Reply-To: References: <1268153476-sup-9269@pinkfloyd.chass.utoronto.ca> Message-ID: On Tue, Mar 9, 2010 at 9:27 AM, Maciej (Matchek) Blizinski wrote: >>... >> well, however it happens, ?we should patch update-mime-database to not >> look under /usr/local - that's just a bad idea all 'round. > > There's also the question whether patching update-mime-database.c will > have any effect on the client applications. ?Chances are, there will > be none. > true. but its still a bug that needs to be fixed. From jgoerzen at opencsw.org Tue Mar 9 18:28:35 2010 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Tue, 9 Mar 2010 09:28:35 -0800 Subject: [csw-maintainers] Error: Ambiguous "?:" expression In-Reply-To: References: <315c02ae1003081540y4d9aeb73j861c8ea323d096a4@mail.gmail.com> <4B95AE8E.7060301@opencsw.org> <315c02ae1003082023m54d4543ud64b1ba0217843ba@mail.gmail.com> <4B960D32.40105@opencsw.org> Message-ID: <315c02ae1003090928y37604112tf2140406b1032da6@mail.gmail.com> On Tue, Mar 9, 2010 at 8:27 AM, Philip Brown wrote: > On Tue, Mar 9, 2010 at 12:56 AM, Roger H?kansson wrote: >> >> Report to upstream, I'm no C++ guru, but in my mind that seems like code >> that isn't really following the standard. >> Sun Studio 11 isn't really that perfect either, but even 12 U1 doesn't >> compile that code so I would say that they use some kind of gcc-ism... >> > > in some cases, its not so much that they use a feature of gcc,but that > they rely on default behaviour of it. That being said... I vaguely > recall that, back in the day, there are warning flags in gcc you can > turn on, that make it (almost) as cautious about these things as sun > studio. > > So, an even better thing for you to look into, would be to see if you > can find the g++ flag that triggers a warning on the original code, > then suggest to upstream, "please compile with these flags from now > on". This would cause them to have to fix their code right? I would guess this would be either -Wall or -Wextra? I know that -Wall is already there because I've had to take it out so SunCC would compile it. Looking closer at the 9 errors that stopped the compile I notice they are all complaining about const expected to return a value: "./gui/widgets/generator_private.hpp", line 173: Error: "gui2::policy::placement::thorizontal_list::calculate_best_size() const" is expected to return a value. Approximately line 173 generator_private.hpp: tpoint calculate_best_size() const { ERROR_LOG(false); } If anyone would take a closer look and help me I will gather up all these fixes and then submit an upstream patch. Thanks! Jake From phil at bolthole.com Tue Mar 9 18:34:47 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 9 Mar 2010 09:34:47 -0800 Subject: [csw-maintainers] Error: Ambiguous "?:" expression In-Reply-To: <315c02ae1003090928y37604112tf2140406b1032da6@mail.gmail.com> References: <315c02ae1003081540y4d9aeb73j861c8ea323d096a4@mail.gmail.com> <4B95AE8E.7060301@opencsw.org> <315c02ae1003082023m54d4543ud64b1ba0217843ba@mail.gmail.com> <4B960D32.40105@opencsw.org> <315c02ae1003090928y37604112tf2140406b1032da6@mail.gmail.com> Message-ID: On Tue, Mar 9, 2010 at 9:28 AM, Jake Goerzen wrote: > > "./gui/widgets/generator_private.hpp", line 173: Error: > "gui2::policy::placement::thorizontal_list::calculate_best_size() > const" is expected to return a value. > > > Approximately line 173 generator_private.hpp: > > ? ? ? ?tpoint calculate_best_size() const > ? ? ? ? ? ? ? ?{ ERROR_LOG(false); } > that's.... a wierd definition. methinks its using gnuism of defaulting to "return null" or something, and you will need to do the return explicitly? From maciej at opencsw.org Tue Mar 9 18:34:56 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 9 Mar 2010 17:34:56 +0000 Subject: [csw-maintainers] update-mime-database said: Note that '/opt/csw/share' is not in the search path In-Reply-To: References: <1268153476-sup-9269@pinkfloyd.chass.utoronto.ca> Message-ID: On Tue, Mar 9, 2010 at 5:29 PM, Philip Brown wrote: > On Tue, Mar 9, 2010 at 9:27 AM, Maciej (Matchek) Blizinski > wrote: >>>... >>> well, however it happens, ?we should patch update-mime-database to not >>> look under /usr/local - that's just a bad idea all 'round. >> >> There's also the question whether patching update-mime-database.c will >> have any effect on the client applications. ?Chances are, there will >> be none. >> > > true. but its still a bug that needs to be fixed. Yes. I think the /usr/local value hardcoded in update-mime-database.c only affects the warning message displayed to the screen; it's good to patch it so it's in sync with what the applications are doing. From hson at opencsw.org Tue Mar 9 23:33:49 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Tue, 09 Mar 2010 23:33:49 +0100 Subject: [csw-maintainers] Error: Ambiguous "?:" expression In-Reply-To: References: <315c02ae1003081540y4d9aeb73j861c8ea323d096a4@mail.gmail.com> <4B95AE8E.7060301@opencsw.org> <315c02ae1003082023m54d4543ud64b1ba0217843ba@mail.gmail.com> <4B960D32.40105@opencsw.org> <315c02ae1003090928y37604112tf2140406b1032da6@mail.gmail.com> Message-ID: <4B96CCCD.1070109@opencsw.org> On 2010-03-09 18:34, Philip Brown wrote: > On Tue, Mar 9, 2010 at 9:28 AM, Jake Goerzen wrote: >> >> "./gui/widgets/generator_private.hpp", line 173: Error: >> "gui2::policy::placement::thorizontal_list::calculate_best_size() >> const" is expected to return a value. >> >> >> Approximately line 173 generator_private.hpp: >> >> tpoint calculate_best_size() const >> { ERROR_LOG(false); } >> > > > that's.... a wierd definition. > methinks its using gnuism of defaulting to "return null" or something, > and you will need to do the return explicitly? ERROR_LOG is defined as: if(true) { \ std::cerr << __FILE__ << ":" << __LINE__ << " ASSSERTION FAILED: " << a << std::endl; \ abort(); \ } else (void)0 Anyway, I've created a patchfile (/home/hson/generator_private.hpp.diff on buildfarm) which at least makes generator.cpp compile, but I can't assure for functionality. Basically I've added "return tpoint(0,0)" for those functions returning tpoint and "return NULL" for those returning twidget. From daniel at opencsw.org Wed Mar 10 12:21:54 2010 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 10 Mar 2010 11:21:54 +0000 Subject: [csw-maintainers] gmake extract is failing Message-ID: <4B9780D2.1090708@opencsw.org> Hi, I've just tried adapting the Makefile for Ganglia to use the 3.1.7 tarball. Now I notice `gmake extract' is failing. Has anyone seen anything like this before? I'm doing this on build8s. If I try to work with my ganglia-3.1.6-rc branch, it is fine. Regards, Daniel bash-2.03$ gmake extract [===== NOW BUILDING: ganglia-3.1.7 =====] [prerequisite] complete for ganglia. [fetch] complete for ganglia. [checksum] complete for ganglia. [checksum-global] complete for ganglia. [checksum-modulated] complete for ganglia. [===== NOW BUILDING: ganglia-3.1.7 MODULATION global: ISA= =====] [extract-modulated] complete for ganglia. gmake[1]: Entering directory `/home/daniel/ws/ganglia/branches/ganglia-3.1.7' [===== NOW BUILDING: ganglia-3.1.7 MODULATION isa-sparcv8: ISA=sparcv8 =====] ==> Extracting work/solaris8-sparc/download/ganglia-3.1.7.tar.gz gtar: Archive is compressed. Use -z option gtar: Error is not recoverable: exiting now gmake[1]: *** [tar-gz-extract-ganglia-3.1.7.tar.gz] Error 2 gmake[1]: Leaving directory `/home/daniel/ws/ganglia/branches/ganglia-3.1.7' gmake: *** [extract-isa-sparcv8] Error 2 bash-2.03$ bash-2.03$ svn info Path: . URL: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/ganglia/branches/ganglia-3.1.7 Repository Root: https://gar.svn.sourceforge.net/svnroot/gar Repository UUID: d3b55034-1cff-0310-a425-aefe953e1e90 Revision: 9067 Node Kind: directory Schedule: normal Last Changed Author: d_pocock Last Changed Rev: 9060 Last Changed Date: 2010-03-09 14:58:27 +0100 (Tue, 09 Mar 2010) From maciej at opencsw.org Wed Mar 10 13:22:17 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 10 Mar 2010 12:22:17 +0000 Subject: [csw-maintainers] gmake extract is failing In-Reply-To: <4B9780D2.1090708@opencsw.org> References: <4B9780D2.1090708@opencsw.org> Message-ID: On Wed, Mar 10, 2010 at 11:21 AM, Daniel Pocock wrote: > bash-2.03$ gmake extract > [===== NOW BUILDING: ganglia-3.1.7 =====] > ? ? ? ?[prerequisite] complete for ganglia. > ? ? ? ?[fetch] complete for ganglia. > ? ? ? ?[checksum] complete for ganglia. > ? ? ? ?[checksum-global] complete for ganglia. > ? ? ? ?[checksum-modulated] complete for ganglia. > [===== NOW BUILDING: ganglia-3.1.7 MODULATION global: ISA= =====] > ? ? ? ?[extract-modulated] complete for ganglia. > gmake[1]: Entering directory > `/home/daniel/ws/ganglia/branches/ganglia-3.1.7' > [===== NOW BUILDING: ganglia-3.1.7 MODULATION isa-sparcv8: ISA=sparcv8 > =====] > ?==> Extracting work/solaris8-sparc/download/ganglia-3.1.7.tar.gz > gtar: Archive is compressed. Use -z option > gtar: Error is not recoverable: exiting now What does "file work/solaris8-sparc/download/ganglia-3.1.7.tar.gz" say? From hson at opencsw.org Wed Mar 10 14:08:51 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Wed, 10 Mar 2010 14:08:51 +0100 Subject: [csw-maintainers] Please repackage ghostcript and tiff Message-ID: <4B9799E3.7050106@opencsw.org> James, could you repackage ghostscript and tiff so that they get linked to libjpeg.so.7 instead of libjpeg.so.62. Currently this is holding back the release of several packages (djvulibre, lcms, imagemagick) where imagemagick is the most crucial one since we have a problem which relates to this specific problem. I've garified both packages (3.9.2 for tiff, but you could change version number in the Makefile to 3.8.2 and it will build just as easily) and you should only have to checkout and then do "gmake package" to build them. From daniel at opencsw.org Wed Mar 10 14:26:28 2010 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 10 Mar 2010 13:26:28 +0000 Subject: [csw-maintainers] gmake extract is failing In-Reply-To: References: <4B9780D2.1090708@opencsw.org> Message-ID: <4B979E04.1050103@opencsw.org> Maciej (Matchek) Blizinski wrote: > On Wed, Mar 10, 2010 at 11:21 AM, Daniel Pocock > wrote: > > bash-2.03$ gmake extract > > [===== NOW BUILDING: ganglia-3.1.7 =====] > > [prerequisite] complete for ganglia. > > [fetch] complete for ganglia. > > [checksum] complete for ganglia. > > [checksum-global] complete for ganglia. > > [checksum-modulated] complete for ganglia. > > [===== NOW BUILDING: ganglia-3.1.7 MODULATION global: ISA= =====] > > [extract-modulated] complete for ganglia. > > gmake[1]: Entering directory > > `/home/daniel/ws/ganglia/branches/ganglia-3.1.7' > > [===== NOW BUILDING: ganglia-3.1.7 MODULATION isa-sparcv8: ISA=sparcv8 > > =====] > > ==> Extracting work/solaris8-sparc/download/ganglia-3.1.7.tar.gz > > gtar: Archive is compressed. Use -z option > > gtar: Error is not recoverable: exiting now > > What does "file work/solaris8-sparc/download/ganglia-3.1.7.tar.gz" say? bash-2.03$ file work/solaris8-sparc/download/ganglia-3.1.7.tar.gz work/solaris8-sparc/download/ganglia-3.1.7.tar.gz: gzip compressed data - deflate method , max compression I get the same output for the 3.1.6 tarball which does work. The only changes in the Makefile are these: Index: checksums =================================================================== --- checksums (revision 9060) +++ checksums (working copy) @@ -2,5 +2,5 @@ c4c333a46db391464e372ad8ede4993c CSWgangliaweb.preremove 25d302948e25837bf17757d5e23e4955 cswgmetad c6bb96c949dbb989d06ebb36b6af885d cswgmond -39134ccba646fce6979958bf9c0fc8d7 ganglia-3.1.6.tar.gz +d9f9bf5d9f8ba4880e9969407a63f819 ganglia-3.1.7.tar.gz 2ff504ecb546aca2cdd6ee09af9a417e httpd-ganglia.conf.CSW Index: Makefile =================================================================== --- Makefile (revision 9060) +++ Makefile (working copy) @@ -1,5 +1,5 @@ GARNAME = ganglia -GARVERSION = 3.1.6 +GARVERSION = 3.1.7 CATEGORIES = utils # How should we set this? @@ -109,6 +109,9 @@ ifeq ($(GARVERSION),3.1.6) TEST_SCRIPTS = endif +ifeq ($(GARVERSION),3.1.7) +TEST_SCRIPTS = +endif INSTALL_SCRIPTS = $(WORKSRC)/Makefile custom From dam at opencsw.org Wed Mar 10 14:47:34 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 10 Mar 2010 14:47:34 +0100 Subject: [csw-maintainers] gmake extract is failing In-Reply-To: <4B979E04.1050103@opencsw.org> References: <4B9780D2.1090708@opencsw.org> <4B979E04.1050103@opencsw.org> Message-ID: Hi Daniel, Am 10.03.2010 um 14:26 schrieb Daniel Pocock: > I get the same output for the 3.1.6 tarball which does work. The file is compressed *twice* with gzip, so the .tar-file is really a .tar.gz, or more verbally, the file should have been named ganglia-3.1.7.tar.gz.gz > build8s% gunzip ganglia-3.1.7.tar.gz > build8s% file ganglia-3.1.7.tar > ganglia-3.1.7.tar: gzip compressed data - deflate method , max > compression > build8s% mv ganglia-3.1.7.tar ganglia-3.1.7.tar.gz > build8s% gunzip ganglia-3.1.7.tar.gz > build8s% file ganglia-3.1.7.tar > ganglia-3.1.7.tar: ascii text Best regards -- Dago From bonivart at opencsw.org Wed Mar 10 16:39:47 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 10 Mar 2010 16:39:47 +0100 Subject: [csw-maintainers] Catch 22: CSWgzip gzipped Message-ID: <625385e31003100739u20830a72g8874eea3cf0cb85f@mail.gmail.com> The latest 1.4 CSWgzip is again gzipped in the catalog which is a problem if no gzip is already on the system. gzip-1.3.5,REV=2006.09.19-SunOS5.8-i386-CSW.pkg.gz 20-Sep-2006 21:26 68K gzip-1.3.12,REV=2007.12.10-SunOS5.8-i386-CSW.pkg 24-Dec-2007 23:58 333K gzip-1.3.12,REV=2008.01.03-SunOS5.8-i386-CSW.pkg 21-Oct-2008 17:08 224K gzip-1.3.13,REV=2009.11.16-SunOS5.8-i386-CSW.pkg 16-Nov-2009 20:26 336K gzip-1.4,REV=2010.01.28-SunOS5.8-i386-CSW.pkg.gz 29-Jan-2010 00:42 69K Can someone (Phil?) fix this now and someone else (Dago?) fix it in GAR so the next version is not compressed again? :-) CSWcommon and CSWgzip needs to be uncompressed. -- /peter From dam at opencsw.org Wed Mar 10 16:53:40 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 10 Mar 2010 16:53:40 +0100 Subject: [csw-maintainers] Catch 22: CSWgzip gzipped In-Reply-To: <625385e31003100739u20830a72g8874eea3cf0cb85f@mail.gmail.com> References: <625385e31003100739u20830a72g8874eea3cf0cb85f@mail.gmail.com> Message-ID: <2BE6753B-4417-48C1-8C05-EC29B1BB136E@opencsw.org> Hi Peter, Am 10.03.2010 um 16:39 schrieb Peter Bonivart: > The latest 1.4 CSWgzip is again gzipped in the catalog which is a > problem if no gzip is already on the system. > > gzip-1.3.5,REV=2006.09.19-SunOS5.8-i386-CSW.pkg.gz > 20-Sep-2006 21:26 68K > gzip-1.3.12,REV=2007.12.10-SunOS5.8-i386-CSW.pkg > 24-Dec-2007 23:58 333K > gzip-1.3.12,REV=2008.01.03-SunOS5.8-i386-CSW.pkg > 21-Oct-2008 17:08 224K > gzip-1.3.13,REV=2009.11.16-SunOS5.8-i386-CSW.pkg > 16-Nov-2009 20:26 336K > gzip-1.4,REV=2010.01.28-SunOS5.8-i386-CSW.pkg.gz > 29-Jan-2010 00:42 69K > > Can someone (Phil?) fix this now and someone else (Dago?) fix it in > GAR so the next version is not compressed again? :-) > > CSWcommon and CSWgzip needs to be uncompressed. Ugh, sorry. Phil: Please gunzip yourself on the mirror and update the catalogs. I'll add a flag to GAR. Best regards -- Dago From daniel at opencsw.org Wed Mar 10 17:00:38 2010 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 10 Mar 2010 16:00:38 +0000 Subject: [csw-maintainers] gmake extract is failing In-Reply-To: References: <4B9780D2.1090708@opencsw.org> <4B979E04.1050103@opencsw.org> Message-ID: <4B97C226.8040501@opencsw.org> Dagobert Michelsen wrote: > Hi Daniel, > > Am 10.03.2010 um 14:26 schrieb Daniel Pocock: > > I get the same output for the 3.1.6 tarball which does work. > > The file is compressed *twice* with gzip, so the .tar-file is really > a .tar.gz, or more verbally, the file should have been named > ganglia-3.1.7.tar.gz.gz You are quite right - fortunately I recorded the correct md5sum in the release announcement, I'm not sure how this double-gzipped file came to be on Sourceforge, but it is not the same as what I distributed through http://ganglia.info/testing/ The nested gzip file does have the correct md5sum though, so I will put that up on Sourceforge again Does Sourceforge try to compress things on the fly or something and could that lead to a problem like this? From daniel at opencsw.org Wed Mar 10 17:01:07 2010 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 10 Mar 2010 16:01:07 +0000 Subject: [csw-maintainers] gmake extract is failing In-Reply-To: References: <4B9780D2.1090708@opencsw.org> <4B979E04.1050103@opencsw.org> Message-ID: <4B97C243.3050900@opencsw.org> Dagobert Michelsen wrote: > Hi Daniel, > > Am 10.03.2010 um 14:26 schrieb Daniel Pocock: > > I get the same output for the 3.1.6 tarball which does work. > > The file is compressed *twice* with gzip, so the .tar-file is really > a .tar.gz, or more verbally, the file should have been named > ganglia-3.1.7.tar.gz.gz You are quite right - fortunately I recorded the correct md5sum in the release announcement, I'm not sure how this double-gzipped file came to be on Sourceforge, but it is not the same as what I distributed through http://ganglia.info/testing/ The nested gzip file does have the correct md5sum though, so I will put that up on Sourceforge again Does Sourceforge try to compress things on the fly or something and could that lead to a problem like this? From phil at bolthole.com Wed Mar 10 18:22:36 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 10 Mar 2010 09:22:36 -0800 Subject: [csw-maintainers] Error: Ambiguous "?:" expression In-Reply-To: <4B96CCCD.1070109@opencsw.org> References: <315c02ae1003081540y4d9aeb73j861c8ea323d096a4@mail.gmail.com> <4B95AE8E.7060301@opencsw.org> <315c02ae1003082023m54d4543ud64b1ba0217843ba@mail.gmail.com> <4B960D32.40105@opencsw.org> <315c02ae1003090928y37604112tf2140406b1032da6@mail.gmail.com> <4B96CCCD.1070109@opencsw.org> Message-ID: On Tue, Mar 9, 2010 at 2:33 PM, Roger H?kansson wrote: > >> >> that's.... a wierd definition. >> methinks its using gnuism of defaulting to "return null" or something, >> and you will need to do the return explicitly? > > ERROR_LOG is defined as: > ?if(true) { \ > ?std::cerr << __FILE__ << ":" << __LINE__ << " ASSSERTION FAILED: " << a << > std::endl; \ > ?abort(); \ > ?} else (void)0 "else 0" ??? that's just freakin wierd. perhaps if you changed that to else return(NULL) or something, it might be the simplest one-spot patch. or manage the cast to void somehow. Dunno if c++ allows return(void) :-} contrariwise, since the "else" clause should NEVER BE CALLED, just remove it entirely, and see if that makes things happy? > Anyway, I've created a patchfile (/home/hson/generator_private.hpp.diff on > buildfarm) which at least makes generator.cpp compile, but I can't assure > for functionality. > Basically I've added "return tpoint(0,0)" for those functions returning > tpoint and "return NULL" for those returning twidget. > From phil at bolthole.com Wed Mar 10 18:24:50 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 10 Mar 2010 09:24:50 -0800 Subject: [csw-maintainers] Catch 22: CSWgzip gzipped In-Reply-To: <2BE6753B-4417-48C1-8C05-EC29B1BB136E@opencsw.org> References: <625385e31003100739u20830a72g8874eea3cf0cb85f@mail.gmail.com> <2BE6753B-4417-48C1-8C05-EC29B1BB136E@opencsw.org> Message-ID: On Wed, Mar 10, 2010 at 7:53 AM, Dagobert Michelsen wrote: > > Ugh, sorry. > Phil: Please gunzip yourself on the mirror and update the catalogs. > will be in next batch From hson at opencsw.org Wed Mar 10 21:55:55 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Wed, 10 Mar 2010 21:55:55 +0100 Subject: [csw-maintainers] Error: Ambiguous "?:" expression In-Reply-To: References: <315c02ae1003081540y4d9aeb73j861c8ea323d096a4@mail.gmail.com> <4B95AE8E.7060301@opencsw.org> <315c02ae1003082023m54d4543ud64b1ba0217843ba@mail.gmail.com> <4B960D32.40105@opencsw.org> <315c02ae1003090928y37604112tf2140406b1032da6@mail.gmail.com> <4B96CCCD.1070109@opencsw.org> Message-ID: <4B98075B.8080308@opencsw.org> On 2010-03-10 18:22, Philip Brown wrote: > > "else 0" ??? that's just freakin wierd. Tell me about it... > perhaps if you changed that to > > else return(NULL) Nope, won't work, then CC complains that "int can't be cast to tpoint". That's why I added "return tpoint(0,0)", tpoint(0,0) is what the constructor for tpoint class returns. From jgoerzen at opencsw.org Wed Mar 10 23:24:04 2010 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Wed, 10 Mar 2010 14:24:04 -0800 Subject: [csw-maintainers] Error: Ambiguous "?:" expression In-Reply-To: <4B98075B.8080308@opencsw.org> References: <315c02ae1003081540y4d9aeb73j861c8ea323d096a4@mail.gmail.com> <4B95AE8E.7060301@opencsw.org> <315c02ae1003082023m54d4543ud64b1ba0217843ba@mail.gmail.com> <4B960D32.40105@opencsw.org> <315c02ae1003090928y37604112tf2140406b1032da6@mail.gmail.com> <4B96CCCD.1070109@opencsw.org> <4B98075B.8080308@opencsw.org> Message-ID: <315c02ae1003101424k7f29d570k717e3b78a8359f2d@mail.gmail.com> I applied your patch (generator_private.hpp.diff) and continued compiling, then ran into a problem in gui/widgets/image.cpp: "gui/widgets/image.cpp", line 25: Error: get_image is not defined. "gui/widgets/image.cpp", line 29: Error: Pointer type needed instead of surface(*)(). "gui/widgets/image.cpp", line 29: Error: Pointer type needed instead of surface(*)(). 3 Error(s) detected. The contents of file gui/widgets/image.cpp: /* $Id: image.cpp 37939 2009-08-18 19:47:08Z mordante $ */ /* copyright (C) 2008 - 2009 by mark de wever part of the battle for wesnoth project http://www.wesnoth.org/ this program is free software; you can redistribute it and/or modify it under the terms of the gnu general public license version 2 or at your option any later version. this program is distributed in the hope that it will be useful, but without any warranty. see the copying file for more details. */ #define GETTEXT_DOMAIN "wesnoth-lib" #include "gui/widgets/image.hpp" #include "../../image.hpp" namespace gui2 { tpoint timage::calculate_best_size() const { surface image(get_image(image::locator(label()))); tpoint result(0, 0); if(image) { result = tpoint(image->w, image->h); } DBG_G_L << "timage " << __func__ << ":" << " empty image " << !image << " result " << result << ".\n"; return result; } const std::string& timage::get_control_type() const { static const std::string type = "image"; return type; } } // namespace gui2 From hson at opencsw.org Thu Mar 11 02:20:24 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Thu, 11 Mar 2010 02:20:24 +0100 Subject: [csw-maintainers] Error: Ambiguous "?:" expression In-Reply-To: <315c02ae1003101424k7f29d570k717e3b78a8359f2d@mail.gmail.com> References: <315c02ae1003081540y4d9aeb73j861c8ea323d096a4@mail.gmail.com> <4B95AE8E.7060301@opencsw.org> <315c02ae1003082023m54d4543ud64b1ba0217843ba@mail.gmail.com> <4B960D32.40105@opencsw.org> <315c02ae1003090928y37604112tf2140406b1032da6@mail.gmail.com> <4B96CCCD.1070109@opencsw.org> <4B98075B.8080308@opencsw.org> <315c02ae1003101424k7f29d570k717e3b78a8359f2d@mail.gmail.com> Message-ID: <4B984558.8030401@opencsw.org> On 2010-03-10 23:24, Jake Goerzen wrote: > I applied your patch (generator_private.hpp.diff) and continued > compiling, then ran into a problem in gui/widgets/image.cpp: > > "gui/widgets/image.cpp", line 25: Error: get_image is not defined. > "gui/widgets/image.cpp", line 29: Error: Pointer type needed instead > of surface(*)(). > "gui/widgets/image.cpp", line 29: Error: Pointer type needed instead > of surface(*)(). > 3 Error(s) detected. > surface image(get_image(image::locator(label()))); > > tpoint result(0, 0); > if(image) { > result = tpoint(image->w, image->h); > } Change surface image(get_image(image::locator(label()))); to surface image(image::get_image(image::locator(label()))); From maciej at opencsw.org Thu Mar 11 09:21:38 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 11 Mar 2010 08:21:38 +0000 Subject: [csw-maintainers] cstdlib vs stdlib.h in Sun Studio 11 Message-ID: I've had a problem while compiling poppler: the #include line was present, but functions such as malloc() were missing. The compiler was CC, not cc. Changing the include line to #include allowed to compile poppler. ...but #include is the C++ standard, isn't it? Why is Sun Studio 11 C++ compiler doing this and how to make it stop? From hson at opencsw.org Thu Mar 11 08:33:30 2010 From: hson at opencsw.org (=?UTF-8?B?Um9nZXIgSMOla2Fuc3Nvbg==?=) Date: Thu, 11 Mar 2010 08:33:30 +0100 Subject: [csw-maintainers] [csw-users] evince-2.24.2 in experimental In-Reply-To: References: <4B94C353.2010805@cmi.univ-mrs.fr> <4B94D755.1010103@cmi.univ-mrs.fr> <4B9614B0.7030503@cmi.univ-mrs.fr> Message-ID: <4B989CCA.2060409@opencsw.org> On 2010-03-11 08:56, Maciej (Matchek) Blizinski wrote: > On Thu, Mar 11, 2010 at 7:45 AM, Maciej (Matchek) Blizinski > wrote: >> I see poppler functions just above the the evince functions on the >> stack. Our poppler package is two years old. I think that it's a >> good idea to update it, link evince against it, and try again. > > Poppler will require some work. > If you're going to 0.12, yes, but I'll release 0.10.6. They just recently switched to 0.12 as their stable branch, 0.10 was the previous one. From hson at opencsw.org Thu Mar 11 09:43:47 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Thu, 11 Mar 2010 09:43:47 +0100 Subject: [csw-maintainers] cstdlib vs stdlib.h in Sun Studio 11 In-Reply-To: References: Message-ID: <4B98AD43.6060208@opencsw.org> On 2010-03-11 09:21, Maciej (Matchek) Blizinski wrote: > I've had a problem while compiling poppler: the #include > line was present, but functions such as malloc() were missing. The > compiler was CC, not cc. Changing the include line to #include > allowed to compile poppler. > > ...but #include is the C++ standard, isn't it? Why is Sun > Studio 11 C++ compiler doing this and how to make it stop? This might give you some insight into what is happening. http://docs.sun.com/source/819-3689/Ch4.Libs.html#pgfId-9101 From maciej at opencsw.org Thu Mar 11 09:46:51 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 11 Mar 2010 08:46:51 +0000 Subject: [csw-maintainers] [csw-users] evince-2.24.2 in experimental In-Reply-To: <4B989CCA.2060409@opencsw.org> References: <4B94D755.1010103@cmi.univ-mrs.fr> <4B9614B0.7030503@cmi.univ-mrs.fr> <4B989CCA.2060409@opencsw.org> Message-ID: On Thu, Mar 11, 2010 at 7:33 AM, Roger H?kansson wrote: > On 2010-03-11 08:56, Maciej (Matchek) Blizinski wrote: >> >> On Thu, Mar 11, 2010 at 7:45 AM, Maciej (Matchek) Blizinski >> ?wrote: >>> >>> I see poppler functions just above the the evince functions on the >>> stack. ?Our poppler package is two years old. ?I think that it's a >>> good idea to update it, link evince against it, and try again. >> >> Poppler will require some work. >> > > If you're going to 0.12, yes, but I'll release 0.10.6. > They just recently switched to 0.12 as their stable branch, 0.10 was the > previous one. I was thinking of 0.12, but we can try evince with 0.10.x too. The problem with poppler 0.12 is that it requires lcms, which needs to be released in 64-bit, but lcms depends on Python, which is not, and will not, in the nearest future, be available in 64-bit. Perhaps we can drop the dependency on Python for the 64-bit version of lcms? Maciej From hson at opencsw.org Thu Mar 11 10:00:41 2010 From: hson at opencsw.org (=?UTF-8?B?Um9nZXIgSMOla2Fuc3Nvbg==?=) Date: Thu, 11 Mar 2010 10:00:41 +0100 Subject: [csw-maintainers] [csw-users] evince-2.24.2 in experimental In-Reply-To: References: <4B94D755.1010103@cmi.univ-mrs.fr> <4B9614B0.7030503@cmi.univ-mrs.fr> <4B989CCA.2060409@opencsw.org> Message-ID: <4B98B139.8020001@opencsw.org> On 2010-03-11 09:46, Maciej (Matchek) Blizinski wrote: > I was thinking of 0.12, but we can try evince with 0.10.x too. > > The problem with poppler 0.12 is that it requires lcms, which needs to > be released in 64-bit, but lcms depends on Python, which is not, and > will not, in the nearest future, be available in 64-bit. Why not? > Perhaps we > can drop the dependency on Python for the 64-bit version of lcms? Since I'm going to split out the python module in a separate package it will be 32-bit only. But I'm waiting on a new tiff release before I can release lcms. From maciej at opencsw.org Thu Mar 11 10:07:34 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 11 Mar 2010 09:07:34 +0000 Subject: [csw-maintainers] [csw-users] evince-2.24.2 in experimental In-Reply-To: <4B98B139.8020001@opencsw.org> References: <4B9614B0.7030503@cmi.univ-mrs.fr> <4B989CCA.2060409@opencsw.org> <4B98B139.8020001@opencsw.org> Message-ID: On Thu, Mar 11, 2010 at 9:00 AM, Roger H?kansson wrote: > On 2010-03-11 09:46, Maciej (Matchek) Blizinski wrote: >> >> I was thinking of 0.12, but we can try evince with 0.10.x too. >> >> The problem with poppler 0.12 is that it requires lcms, which needs to >> be released in 64-bit, but lcms depends on Python, which is not, and >> will not, in the nearest future, be available in 64-bit. > > Why not? I've looked at it once. Python headers do checks on certain 64-bit related constants, which AFAIK are set by the compiler; the assertions in the Python code are failing. "/opt/csw/include/python2.6/pyport.h", line 680: Error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?).". >> Perhaps we >> can drop the dependency on Python for the 64-bit version of lcms? > > Since I'm going to split out the python module in a separate package it will > be 32-bit only. > > But I'm waiting on a new tiff release before I can release lcms. I see. In the meantime, I added a setting to the lcms Makefile to disable Python for the 64-bit modulation. From hson at opencsw.org Thu Mar 11 20:32:06 2010 From: hson at opencsw.org (=?UTF-8?B?Um9nZXIgSMOla2Fuc3Nvbg==?=) Date: Thu, 11 Mar 2010 20:32:06 +0100 Subject: [csw-maintainers] [csw-users] evince-2.24.2 in experimental In-Reply-To: References: <4B9614B0.7030503@cmi.univ-mrs.fr> <4B989CCA.2060409@opencsw.org> <4B98B139.8020001@opencsw.org> Message-ID: <4B994536.2010304@opencsw.org> On 2010-03-11 10:07, Maciej (Matchek) Blizinski wrote: >> But I'm waiting on a new tiff release before I can release lcms. > > I see. In the meantime, I added a setting to the lcms Makefile to > disable Python for the 64-bit modulation. May I ask why you removed all thoose OVERRIDES? > -CHECKPKG_OVERRIDES_CSWlcms += symbol-not-found|icclink > -CHECKPKG_OVERRIDES_CSWlcms += symbol-not-found|tiffdiff > -CHECKPKG_OVERRIDES_CSWlcms += symbol-not-found|icc2ps > -CHECKPKG_OVERRIDES_CSWlcms += symbol-not-found|tifficc > -CHECKPKG_OVERRIDES_CSWlcms += symbol-not-found|wtpt > -CHECKPKG_OVERRIDES_CSWlcms += symbol-not-found|jpegicc > -CHECKPKG_OVERRIDES_CSWlcms += symbol-not-found|icctrans > CHECKPKG_OVERRIDES_CSWlcmsdevel += missing-dependency|CSWlcms > -CHECKPKG_OVERRIDES_CSWpy-lcms += symbol-not-found|_lcms.so From phil at bolthole.com Thu Mar 11 20:53:02 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 11 Mar 2010 11:53:02 -0800 Subject: [csw-maintainers] Error: Ambiguous "?:" expression In-Reply-To: <4B98075B.8080308@opencsw.org> References: <315c02ae1003081540y4d9aeb73j861c8ea323d096a4@mail.gmail.com> <4B95AE8E.7060301@opencsw.org> <315c02ae1003082023m54d4543ud64b1ba0217843ba@mail.gmail.com> <4B960D32.40105@opencsw.org> <315c02ae1003090928y37604112tf2140406b1032da6@mail.gmail.com> <4B96CCCD.1070109@opencsw.org> <4B98075B.8080308@opencsw.org> Message-ID: On Wed, Mar 10, 2010 at 12:55 PM, Roger H?kansson wrote: > On 2010-03-10 18:22, Philip Brown wrote: >> >> "else 0" ??? ?that's just freakin wierd. > > Tell me about it... > > >> perhaps if you changed that to >> >> else return(NULL) > > Nope, won't work, then CC complains that "int can't be cast to tpoint". > That's why I added "return tpoint(0,0)", tpoint(0,0) is what the constructor > for tpoint class returns. > well, another solution, may be to replace the braindead hacked #define, to be a *real* function, or in this case, two functions, and you use the appropriate one, in the appropriate place. (hmm. could actually keep it as a #define if you had two separate ones) cant you cast to (void) or something though, and that fits everything? Another "simple" road, if even possible, though, would be to find in the C++ spec some simple generic language trick that allows exit from a constructor generically, even if unhappily. Maybe you have to do it with a throws clause, rather than a return. or heck, forget the return, and just do exit(1). and/or use special defines/comments that make the compiler shut up. used to be, /* ARGSUSED */ was a nice little magic thing,, for lint at least. From maciej at opencsw.org Fri Mar 12 07:53:26 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 12 Mar 2010 06:53:26 +0000 Subject: [csw-maintainers] [csw-users] evince-2.24.2 in experimental In-Reply-To: <4B994536.2010304@opencsw.org> References: <4B9614B0.7030503@cmi.univ-mrs.fr> <4B989CCA.2060409@opencsw.org> <4B98B139.8020001@opencsw.org> <4B994536.2010304@opencsw.org> Message-ID: On Thu, Mar 11, 2010 at 7:32 PM, Roger H?kansson wrote: > On 2010-03-11 10:07, Maciej (Matchek) Blizinski wrote: > >>> But I'm waiting on a new tiff release before I can release lcms. >> >> I see. ?In the meantime, I added a setting to the lcms Makefile to >> disable Python for the 64-bit modulation. > > May I ask why you removed all thoose OVERRIDES? Checkpkg no longer checks for symbols, these overrides were unused: All modular tests completed. Analyzing the reports. WARNING: Some overrides did not match any errors. They can be removed, as they don't take any effect anyway. If you're getting errors at the same time, maybe you didn't specify the overrides correctly. * Unused Override('CSWlcms', 'symbol-not-found', 'wtpt') * Unused Override('CSWpy-lcms', 'symbol-not-found', '_lcms.so') * Unused Override('CSWlcms', 'symbol-not-found', 'jpegicc') * Unused Override('CSWlcms', 'symbol-not-found', 'icctrans') * Unused Override('CSWlcms', 'symbol-not-found', 'tiffdiff') * Unused Override('CSWpy-lcms', 'symbol-not-found', '_lcms.so') * Unused Override('CSWlcms', 'symbol-not-found', 'icclink') * Unused Override('CSWlcmsdevel', 'missing-dependency', 'CSWlcms') * Unused Override('CSWlcms', 'symbol-not-found', 'icc2ps') * Unused Override('CSWlcms', 'symbol-not-found', 'tifficc') All modular tests were successful. From hson at opencsw.org Fri Mar 12 09:53:02 2010 From: hson at opencsw.org (=?UTF-8?B?Um9nZXIgSMOla2Fuc3Nvbg==?=) Date: Fri, 12 Mar 2010 09:53:02 +0100 Subject: [csw-maintainers] [csw-users] evince-2.24.2 in experimental In-Reply-To: References: <4B9614B0.7030503@cmi.univ-mrs.fr> <4B989CCA.2060409@opencsw.org> <4B98B139.8020001@opencsw.org> <4B994536.2010304@opencsw.org> Message-ID: <4B9A00EE.9060200@opencsw.org> On 2010-03-12 07:53, Maciej (Matchek) Blizinski wrote: > On Thu, Mar 11, 2010 at 7:32 PM, Roger H?kansson wrote: >> On 2010-03-11 10:07, Maciej (Matchek) Blizinski wrote: >> >>>> But I'm waiting on a new tiff release before I can release lcms. >>> >>> I see. In the meantime, I added a setting to the lcms Makefile to >>> disable Python for the 64-bit modulation. >> >> May I ask why you removed all thoose OVERRIDES? > > Checkpkg no longer checks for symbols, these overrides were unused: > Aha, I've missed that this change have been introduced. Nice, now I can remove the 230 lines in the makefile for imagemagick... From maciej at opencsw.org Fri Mar 12 11:07:12 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 12 Mar 2010 10:07:12 +0000 Subject: [csw-maintainers] Which x11 library to choose? In-Reply-To: <4B923F19.6060106@opencsw.org> References: <201003040902.o2492h10003745@login.bo.opencsw.org> <6F149BCB-3BDE-4482-9ABB-C6BF036760FA@opencsw.org> <4B923F19.6060106@opencsw.org> Message-ID: On Sat, Mar 6, 2010 at 11:40 AM, Roger H?kansson wrote: > On 2010-03-05 19:32, Dagobert Michelsen wrote: >> >> Exactly. A package should be linked OpenCSW X11 exactly when: >> - it relies on features only available in OpenCSW X11 >> or >> - it is linked together with a binary that is linked against >> OpenCSW X11 >> > > - And doesn't contain any libraries someone might link with creating other > packages. > > > Otherwise we end up with the same problem as we have right now, some > packages are linked with Sun X11 and some with OpenCSW X11 and when creating > a package which is linked to libraries from both categories we get into > trouble. Is this an example of what you were talking about? $ ldd -r /opt/csw/bin/awesome | grep libX11 libX11.so.6 => /opt/csw/X11/lib/libX11.so.6 libX11.so.4 => /usr/lib/libX11.so.4 Perhaps we should have checkpkg throw an error when this happens? (...and potentially offer a useful suggestion) From maciej at opencsw.org Fri Mar 12 11:09:50 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 12 Mar 2010 10:09:50 +0000 Subject: [csw-maintainers] CSWimlib2 vs libX11 Message-ID: On Fri, Mar 12, 2010 at 10:07 AM, Maciej (Matchek) Blizinski wrote: > $ ldd -r /opt/csw/bin/awesome | grep libX11 > ? ? ? ?libX11.so.6 => ? /opt/csw/X11/lib/libX11.so.6 > ? ? ? ?libX11.so.4 => ? /usr/lib/libX11.so.4 I've built awesome, and tried to run it, but it wouldn't draw anything on the screen. Perhaps this was the cause? Examining the binary... blizinski at cabbage ~ $ /usr/ccs/bin/dump -Lv /opt/csw/bin/awesome | grep libX11 [2] NEEDED libX11.so.6 The binary itself only links against libX11.so.6. One of the dependencies must be pulling libX11.so.4 in. $ for l in $(ldd -r /opt/csw/bin/awesome | awk '{print $3}'); do if [ "$(ldd -r $l | grep libX11.so.4)" ]; then echo $l ; fi; done /opt/csw/lib/libImlib2.so.1 /usr/lib/libXext.so.0 libImlib2.so.1 belongs to CSWimlib2. And libXext... $ for l in $(ldd -r /opt/csw/bin/awesome | awk '{print $3}'); do if [ "$(ldd -r $l | grep libXext)" ]; then echo $l ; fi; done /opt/csw/lib/libImlib2.so.1 /usr/lib/libX11.so.4 ...is also needed by CSWimlib2. It seems like liking CSWimlib2 against CSW X11 would remove the linking against two versions of libX11. Looking at the build description: #EXTRA_INC = $(prefix)/X11/include #EXTRA_LIB = $(prefix)/X11/lib #EXTRA_PKG_CONFIG_DIRS = $(prefix)/X11/lib BUILD64 = 1 CONFIGURE_ARGS = $(DIRPATHS) #CONFIGURE_ARGS += --x-include=$(prefix)/X11/include #CONFIGURE_ARGS += --x-libraries=$(abspath $(prefix)/X11/lib/$(MM_LIBDIR)) Dago, it seems like you've explored this before. Was there a problem with linking imlib2 against CSW X11? Maciej From hson at opencsw.org Fri Mar 12 12:49:52 2010 From: hson at opencsw.org (=?UTF-8?B?Um9nZXIgSMOla2Fuc3Nvbg==?=) Date: Fri, 12 Mar 2010 12:49:52 +0100 Subject: [csw-maintainers] Which x11 library to choose? In-Reply-To: References: <201003040902.o2492h10003745@login.bo.opencsw.org> <6F149BCB-3BDE-4482-9ABB-C6BF036760FA@opencsw.org> <4B923F19.6060106@opencsw.org> Message-ID: <4B9A2A60.9040205@opencsw.org> On 2010-03-12 11:07, Maciej (Matchek) Blizinski wrote: >> >> Otherwise we end up with the same problem as we have right now, some >> packages are linked with Sun X11 and some with OpenCSW X11 and when creating >> a package which is linked to libraries from both categories we get into >> trouble. > > Is this an example of what you were talking about? > > $ ldd -r /opt/csw/bin/awesome | grep libX11 > libX11.so.6 => /opt/csw/X11/lib/libX11.so.6 > libX11.so.4 => /usr/lib/libX11.so.4 What I meant was that it takes a lot of time for the maintainers to try to work around the various link-errors you get. But also, such a binary isn't guaranteed to work at all. From dam at opencsw.org Fri Mar 12 14:04:15 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 12 Mar 2010 14:04:15 +0100 Subject: [csw-maintainers] Which x11 library to choose? In-Reply-To: <4B9A2A60.9040205@opencsw.org> References: <201003040902.o2492h10003745@login.bo.opencsw.org> <6F149BCB-3BDE-4482-9ABB-C6BF036760FA@opencsw.org> <4B923F19.6060106@opencsw.org> <4B9A2A60.9040205@opencsw.org> Message-ID: Hi Roger, Am 12.03.2010 um 12:49 schrieb Roger H?kansson: > On 2010-03-12 11:07, Maciej (Matchek) Blizinski wrote: >>> >>> Otherwise we end up with the same problem as we have right now, some >>> packages are linked with Sun X11 and some with OpenCSW X11 and >>> when creating >>> a package which is linked to libraries from both categories we get >>> into >>> trouble. >> >> Is this an example of what you were talking about? >> >> $ ldd -r /opt/csw/bin/awesome | grep libX11 >> libX11.so.6 => /opt/csw/X11/lib/libX11.so.6 >> libX11.so.4 => /usr/lib/libX11.so.4 > > What I meant was that it takes a lot of time for the maintainers to > try to work around the various link-errors you get. > But also, such a binary isn't guaranteed to work at all. Ok, that means we should identify the libraries linked to Sun X11 and rebuild them instead of working around anything, right? Best regards -- Dago From hson at opencsw.org Fri Mar 12 15:22:34 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 12 Mar 2010 15:22:34 +0100 Subject: [csw-maintainers] Which x11 library to choose? In-Reply-To: References: <201003040902.o2492h10003745@login.bo.opencsw.org> <6F149BCB-3BDE-4482-9ABB-C6BF036760FA@opencsw.org> <4B923F19.6060106@opencsw.org> <4B9A2A60.9040205@opencsw.org> Message-ID: <4B9A4E2A.4040408@opencsw.org> Dagobert Michelsen wrote: > Hi Roger, > > Am 12.03.2010 um 12:49 schrieb Roger H?kansson: >> On 2010-03-12 11:07, Maciej (Matchek) Blizinski wrote: >>>> >>>> Otherwise we end up with the same problem as we have right now, some >>>> packages are linked with Sun X11 and some with OpenCSW X11 and when >>>> creating >>>> a package which is linked to libraries from both categories we get into >>>> trouble. >>> >>> Is this an example of what you were talking about? >>> >>> $ ldd -r /opt/csw/bin/awesome | grep libX11 >>> libX11.so.6 => /opt/csw/X11/lib/libX11.so.6 >>> libX11.so.4 => /usr/lib/libX11.so.4 >> >> What I meant was that it takes a lot of time for the maintainers to >> try to work around the various link-errors you get. >> But also, such a binary isn't guaranteed to work at all. > > Ok, that means we should identify the libraries linked to Sun X11 and > rebuild them instead of working around anything, right? > That's my recommendation, yes From dam at opencsw.org Fri Mar 12 15:31:19 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 12 Mar 2010 15:31:19 +0100 Subject: [csw-maintainers] Which x11 library to choose? In-Reply-To: <4B9A4E2A.4040408@opencsw.org> References: <201003040902.o2492h10003745@login.bo.opencsw.org> <6F149BCB-3BDE-4482-9ABB-C6BF036760FA@opencsw.org> <4B923F19.6060106@opencsw.org> <4B9A2A60.9040205@opencsw.org> <4B9A4E2A.4040408@opencsw.org> Message-ID: <6125466C-6186-44DE-95C9-B5F08481EE02@opencsw.org> Hi Roger, Am 12.03.2010 um 15:22 schrieb Roger H?kansson: > Dagobert Michelsen wrote: >> Hi Roger, >> Am 12.03.2010 um 12:49 schrieb Roger H?kansson: >>> On 2010-03-12 11:07, Maciej (Matchek) Blizinski wrote: >>>>> >>>>> Otherwise we end up with the same problem as we have right now, >>>>> some >>>>> packages are linked with Sun X11 and some with OpenCSW X11 and >>>>> when creating >>>>> a package which is linked to libraries from both categories we >>>>> get into >>>>> trouble. >>>> >>>> Is this an example of what you were talking about? >>>> >>>> $ ldd -r /opt/csw/bin/awesome | grep libX11 >>>> libX11.so.6 => /opt/csw/X11/lib/libX11.so.6 >>>> libX11.so.4 => /usr/lib/libX11.so.4 >>> >>> What I meant was that it takes a lot of time for the maintainers >>> to try to work around the various link-errors you get. >>> But also, such a binary isn't guaranteed to work at all. >> Ok, that means we should identify the libraries linked to Sun X11 and >> rebuild them instead of working around anything, right? > > That's my recommendation, yes I set up a project page to track progress: Please add what you see fit. Best regards -- Dago From maciej at opencsw.org Fri Mar 12 15:35:45 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 12 Mar 2010 14:35:45 +0000 Subject: [csw-maintainers] emacs_nox depends on CSWx11 and friends Message-ID: I've been recently asked to ask emacs_nox on some machines. I examined the dependencies that were missing: CSWbash-4.0.35,REV=2009.12.23 CSWcommon-1.4.7,REV=2009.09.20 CSWcswclassutils-1.30,REV=2009.11.21 CSWexpat-2.0.1,REV=2009.01.22 CSWfconfig-2.6.0,REV=2009.04.24 CSWftype2-2.3.9,REV=2009.09.11 CSWgcc3corert-3.4.6,REV=2009.06.25 CSWggettextrt-0.17,REV=2009.02.13 CSWgsed-4.2.1,REV=2009.07.14 CSWiconv-1.13.1,REV=2009.07.31 CSWisaexec-0.2,REV=2009.03.26 CSWjpeg-7,REV=2009.08.17 CSWlibx11-1.2.2,REV=2009.07.12 CSWlibxau-1.0.4,REV=2009.06.04 CSWlibxcb-1.3,REV=2009.06.07 CSWlibxml2-2.7.6,REV=2009.12.17 CSWncurses-5.7,REV=2009.04.06 CSWpng-1.2.41,REV=2009.12.05 CSWtexinfo-4.13a,REV=2009.12.28 CSWx11common-1.0,REV=2009.05.24 CSWzlib-1.2.3,REV=2009.11.26 It seems to depend on CSWfconfig, CSWftype2, CSWlibx11, etc. How hard would be to eliminate these dependencies? From hson at opencsw.org Fri Mar 12 16:59:00 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 12 Mar 2010 16:59:00 +0100 Subject: [csw-maintainers] Which x11 library to choose? In-Reply-To: <6125466C-6186-44DE-95C9-B5F08481EE02@opencsw.org> References: <201003040902.o2492h10003745@login.bo.opencsw.org> <6F149BCB-3BDE-4482-9ABB-C6BF036760FA@opencsw.org> <4B923F19.6060106@opencsw.org> <4B9A2A60.9040205@opencsw.org> <4B9A4E2A.4040408@opencsw.org> <6125466C-6186-44DE-95C9-B5F08481EE02@opencsw.org> Message-ID: <4B9A64C4.7040704@opencsw.org> Dagobert Michelsen wrote: > Hi Roger, > > Am 12.03.2010 um 15:22 schrieb Roger H?kansson: >> Dagobert Michelsen wrote: >>> Hi Roger, >>> Am 12.03.2010 um 12:49 schrieb Roger H?kansson: >>>> On 2010-03-12 11:07, Maciej (Matchek) Blizinski wrote: >>>>>> >>>>>> Otherwise we end up with the same problem as we have right now, some >>>>>> packages are linked with Sun X11 and some with OpenCSW X11 and >>>>>> when creating >>>>>> a package which is linked to libraries from both categories we get >>>>>> into >>>>>> trouble. >>>>> >>>>> Is this an example of what you were talking about? >>>>> >>>>> $ ldd -r /opt/csw/bin/awesome | grep libX11 >>>>> libX11.so.6 => /opt/csw/X11/lib/libX11.so.6 >>>>> libX11.so.4 => /usr/lib/libX11.so.4 >>>> >>>> What I meant was that it takes a lot of time for the maintainers to >>>> try to work around the various link-errors you get. >>>> But also, such a binary isn't guaranteed to work at all. >>> Ok, that means we should identify the libraries linked to Sun X11 and >>> rebuild them instead of working around anything, right? >> >> That's my recommendation, yes > > I set up a project page to track progress: > > Please add what you see fit. I've added the stuff that I could find on the buildfarm using nm and dump. But since the buildfarm doesn't have all packages installed I guess there might be some that are missing since the list you get when searching for libX11.so.4 on www.opencsw.org is a lot larger... From maciej at opencsw.org Fri Mar 12 17:10:42 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 12 Mar 2010 16:10:42 +0000 Subject: [csw-maintainers] Which x11 library to choose? In-Reply-To: <4B9A64C4.7040704@opencsw.org> References: <201003040902.o2492h10003745@login.bo.opencsw.org> <6F149BCB-3BDE-4482-9ABB-C6BF036760FA@opencsw.org> <4B923F19.6060106@opencsw.org> <4B9A2A60.9040205@opencsw.org> <4B9A4E2A.4040408@opencsw.org> <6125466C-6186-44DE-95C9-B5F08481EE02@opencsw.org> <4B9A64C4.7040704@opencsw.org> Message-ID: On Fri, Mar 12, 2010 at 3:59 PM, Roger H?kansson wrote: > I've added the stuff that I could find on the buildfarm using nm and dump. > But since the buildfarm doesn't have all packages installed I guess there > might be some that are missing since the list you get when searching for > libX11.so.4 on www.opencsw.org is a lot larger... Is there an available catalog in a filesystem somewhere on the buildfarm? I could collect stats from all the packages and then analyze the data. (It's not a bad idea to do that anyway.) Maciej From phil at bolthole.com Fri Mar 12 17:46:57 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 12 Mar 2010 08:46:57 -0800 Subject: [csw-maintainers] emacs_nox depends on CSWx11 and friends In-Reply-To: References: Message-ID: On Fri, Mar 12, 2010 at 6:35 AM, Maciej (Matchek) Blizinski wrote: > I've been recently asked to ask emacs_nox on some machines. .... >... > It seems to depend on CSWfconfig, CSWftype2, CSWlibx11, etc. ?How hard > would be to eliminate these dependencies? > I'm not an emacs person, but just a thought: while I'd guess x11 should be removed... perhaps the other stuff is in there to allow for full TeX and/or fancy printing support. That being said.. it doesnt look like our CSWemacsnox package "directly" uses any of those libraries,so perhaps they are spurious dependencies after all? From phil at bolthole.com Fri Mar 12 17:48:55 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 12 Mar 2010 08:48:55 -0800 Subject: [csw-maintainers] CSWimlib2 vs libX11 In-Reply-To: References: Message-ID: On Fri, Mar 12, 2010 at 2:09 AM, Maciej (Matchek) Blizinski wrote: >... > > Dago, it seems like you've explored this before. ?Was there a problem > with linking imlib2 against CSW X11? > side note: looks like fluxbox would have to be recompiled also, but that's about it. From phil at bolthole.com Fri Mar 12 17:52:12 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 12 Mar 2010 08:52:12 -0800 Subject: [csw-maintainers] Which x11 library to choose? In-Reply-To: References: <201003040902.o2492h10003745@login.bo.opencsw.org> <6F149BCB-3BDE-4482-9ABB-C6BF036760FA@opencsw.org> <4B923F19.6060106@opencsw.org> Message-ID: On Fri, Mar 12, 2010 at 2:07 AM, Maciej (Matchek) Blizinski wrote: > >> >> Otherwise we end up with the same problem as we have right now, some >> packages are linked with Sun X11 and some with OpenCSW X11 and when creating >> a package which is linked to libraries from both categories we get into >> trouble. > > Is this an example of what you were talking about? > > $ ldd -r /opt/csw/bin/awesome | grep libX11 > ? ? ? ?libX11.so.6 => ? /opt/csw/X11/lib/libX11.so.6 > ? ? ? ?libX11.so.4 => ? /usr/lib/libX11.so.4 > Yeppers. > Perhaps we should have checkpkg throw an error when this happens? > (...and potentially offer a useful suggestion) would be good. > (Dagobert also writes) > Ok, that means we should identify the libraries linked to Sun X11 and > rebuild them instead of working around anything, right? If we're talking globally... yes, but ONLY for those libraries, that are expected to be used with other libraries/programs that interact with our "fancy" X11 libs. which is most of them. but still, just being pedantic here. that's my job, after all ;-) From pfelecan at opencsw.org Fri Mar 12 19:01:55 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 12 Mar 2010 19:01:55 +0100 Subject: [csw-maintainers] emacs_nox depends on CSWx11 and friends In-Reply-To: (Philip Brown's message of "Fri, 12 Mar 2010 08:46:57 -0800") References: Message-ID: Philip Brown writes: > On Fri, Mar 12, 2010 at 6:35 AM, Maciej (Matchek) Blizinski > wrote: >> I've been recently asked to ask emacs_nox on some machines. .... >>... >> It seems to depend on CSWfconfig, CSWftype2, CSWlibx11, etc. ?How hard >> would be to eliminate these dependencies? >> > > I'm not an emacs person, but just a thought: > while I'd guess x11 should be removed... perhaps the other stuff is in > there to allow for full TeX and/or fancy printing support. > > That being said.. it doesnt look like our CSWemacsnox package > "directly" uses any of those libraries,so perhaps they are spurious > dependencies after all? More or less spurious they are. In the current version of Emacs autotooling it's a real PITA to obtain a "pure" nox; I tried but no more. When I'll use the alternative system that we have at last, looking in this mess again I'll try. -- Peter From phil at bolthole.com Fri Mar 12 19:11:07 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 12 Mar 2010 10:11:07 -0800 Subject: [csw-maintainers] emacs_nox depends on CSWx11 and friends In-Reply-To: References: Message-ID: On Fri, Mar 12, 2010 at 10:01 AM, Peter FELECAN wrote: > > > More or less spurious they are. In the current version of Emacs > autotooling it's a real PITA to obtain a "pure" nox; I tried but no > more. > > When I'll use the alternative system that we have at last, looking in > this mess again I'll try. > [Since you're in that language mode already, it had to be said...] OoAwwrrrhhhhh... "Do. Or do not. there is no Try" :-D From phil at bolthole.com Fri Mar 12 19:20:08 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 12 Mar 2010 10:20:08 -0800 Subject: [csw-maintainers] anyone for OpenNMS? Message-ID: Just a random ping, to see if anyone wanted to package up OpenNMS http://www.opennms.org It's kindasorta like nagios, but aimed at "enterprise level, GUI driven" people. So its a bit of a hog. (java based, AND database driven). but certainly a lot prettier. and has integrated historial stuff, etc, etc. Would be nice if we offered it. Got a few missing prereqs, though. Would be quite a coup if we offered it: the guide for installing on solaris, references sunfreeware for SOME of the bits, but even they dont have a full package of it. From pfelecan at opencsw.org Fri Mar 12 19:45:21 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 12 Mar 2010 19:45:21 +0100 Subject: [csw-maintainers] anyone for OpenNMS? In-Reply-To: (Philip Brown's message of "Fri, 12 Mar 2010 10:20:08 -0800") References: Message-ID: Philip Brown writes: > Just a random ping, to see if anyone wanted to package up OpenNMS > http://www.opennms.org Not me. > It's kindasorta like nagios, but aimed at "enterprise level, GUI driven" people. > So its a bit of a hog. (java based, AND database driven). but > certainly a lot prettier. > and has integrated historial stuff, etc, etc. > Would be nice if we offered it. > Got a few missing prereqs, though. Yeah, the project for which you need to pronounce your wows of celibacy before taking up the maintainship; not for young people as to enjoy a little bit the world, and not for the old people who won't give up the world's pleasures for this kind of activity. > Would be quite a coup if we offered it: the guide for installing on > solaris, references sunfreeware for SOME of the bits, but even they > dont have a full package of it. Vanitas vanitatum omnia vanitas -- Peter From jgoerzen at opencsw.org Fri Mar 12 22:51:25 2010 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Fri, 12 Mar 2010 13:51:25 -0800 Subject: [csw-maintainers] Error: Ambiguous "?:" expression In-Reply-To: References: <315c02ae1003081540y4d9aeb73j861c8ea323d096a4@mail.gmail.com> <315c02ae1003082023m54d4543ud64b1ba0217843ba@mail.gmail.com> <4B960D32.40105@opencsw.org> <315c02ae1003090928y37604112tf2140406b1032da6@mail.gmail.com> <4B96CCCD.1070109@opencsw.org> <4B98075B.8080308@opencsw.org> Message-ID: <315c02ae1003121351o247132b9r7d63685a8389d458@mail.gmail.com> On Thu, Mar 11, 2010 at 11:53 AM, Philip Brown wrote: > On Wed, Mar 10, 2010 at 12:55 PM, Roger H?kansson wrote: >> On 2010-03-10 18:22, Philip Brown wrote: >>> >>> "else 0" ??? ?that's just freakin wierd. >> >> Tell me about it... >> >> >>> perhaps if you changed that to >>> >>> else return(NULL) >> >> Nope, won't work, then CC complains that "int can't be cast to tpoint". >> That's why I added "return tpoint(0,0)", tpoint(0,0) is what the constructor >> for tpoint class returns. >> > > well, another solution, may be to replace the braindead hacked > #define, to be a *real* function, or in this case, two functions, and > you use the appropriate one, in the appropriate place. (hmm. could > actually keep it as a #define if you had two separate ones) > > cant you cast to ?(void) or something though, and that fits everything? > > > > Another "simple" road, if even ?possible, though, would be to find in > the C++ spec some simple generic language trick that allows exit from > a constructor generically, even if unhappily. > > Maybe you have to do it with a throws clause, rather than a return. > > or heck, forget the return, and just do exit(1). and/or use special > defines/comments that make the compiler shut up. > > used to be, /* ARGSUSED */ was a nice little magic thing,, for lint at least. > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > Thank you Phil and Roger for helping me with the code fixes. ;-) I have commited Revision: 9117 which contains all the patches and work we have done so far. At the moment the GAR recipe will almost finish building but there is at least one more problem to fix but we are very close to getting this thing wrapped up. At the moment compiling stops at time.cpp: /opt/studio/SOS11/SUNWspro/bin/CC -DHAVE_CONFIG_H -I. -I.. -I/opt/csw/include -I/opt/csw/include -I/opt/csw/include/pango-1.0 -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -I/opt/csw/include/cairo -I/opt/csw/include -DHAVE_REVISION -I../intl -I../intl -I/opt/csw/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DWESNOTH_PATH=\"/opt/csw/share/wesnoth\" -DLOCALEDIR=\"translations\" -DHAS_RELATIVE_LOCALEDIR=1 -DFIFODIR=\"/var/opt/csw/run\" -DWESNOTH_PREFIX=\"/opt/csw\" -features=extensions -library=stlport4 -DDISABLE_POOL_ALLOC -I/opt/csw/include -c -o time.o time.cpp "time.hpp", line 29: Error: Type name expected instead of "size_t". "time.hpp", line 30: Error: Type name expected instead of "size_t". "time.hpp", line 31: Error: Type name expected instead of "size_t". "time.hpp", line 45: Error: Type name expected instead of "size_t". "time.hpp", line 45: Error: Identifier expected instead of "const". "time.hpp", line 45: Error: Use ";" to terminate declarations. "time.hpp", line 46: Error: Use ";" to terminate declarations. "time.hpp", line 46: Error: ")" expected instead of "fps". "time.hpp", line 46: Error: ) is not defined. "time.hpp", line 47: Error: ")" expected instead of "ms". "time.hpp", line 47: Error: ) is not defined. "time.hpp", line 49: Error: Type name expected instead of "size_t". "time.hpp", line 49: Error: Identifier expected instead of "const". "time.hpp", line 49: Error: Multiple declaration for const. "time.hpp", line 49: Error: Use ";" to terminate declarations. "time.hpp", line 51: Error: Use ";" to terminate declarations. "time.cpp", line 30: Error: time_ is not defined. "time.cpp", line 40: Error: start_frame(const bool) is not a member of ntime::source. "time.cpp", line 55: Error: time_ is not defined. "time.cpp", line 64: Error: time_ is not defined. "time.cpp", line 71: Error: time_ is not defined. "time.cpp", line 85: Error: set_frame_rate(const unsigned) is not a member of ntime::source. "time.cpp", line 90: Error: set_frame_time(const unsigned) is not a member of ntime::source. "time.cpp", line 95: Error: get_time() is not a member of ntime::source. 24 Error(s) detected. gmake[4]: *** [time.o] Error 24 gmake[4]: Leaving directory `/home/jgoerzen/mgar/wesnoth/trunk/work/solaris8-i386/build-isa-i386/wesnoth-1.6.5/src From phil at bolthole.com Fri Mar 12 23:12:08 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 12 Mar 2010 14:12:08 -0800 Subject: [csw-maintainers] Error: Ambiguous "?:" expression In-Reply-To: <315c02ae1003121351o247132b9r7d63685a8389d458@mail.gmail.com> References: <315c02ae1003081540y4d9aeb73j861c8ea323d096a4@mail.gmail.com> <4B960D32.40105@opencsw.org> <315c02ae1003090928y37604112tf2140406b1032da6@mail.gmail.com> <4B96CCCD.1070109@opencsw.org> <4B98075B.8080308@opencsw.org> <315c02ae1003121351o247132b9r7d63685a8389d458@mail.gmail.com> Message-ID: On Fri, Mar 12, 2010 at 1:51 PM, Jake Goerzen wrote: >?At the moment the GAR recipe will almost finish > building but there is at least one more problem to fix but we are very > close to getting this thing wrapped up. ?At the moment compiling stops > at time.cpp: >.... > "time.hpp", line 29: Error: Type name expected instead of "size_t". That looks like a pretty standard, "you need to add an #include foo.h in Solaris, even though you dont in linux" type error. i've seen those a lot :) Often fixed by looking at older versions of the file in question, noticing, "oh, they removed [xxxx]types.h!", putting it back, and emailing the developers, "hey bozos, put that back in the source!" This can often be solidified a bit more permenantly, by providng a patch such as #ifdef __sun # include neededthinhere #endif However, the PROPER way to fix this, if they are using autoconf, is for them to put in the appropriate "NEEDS_fooo_H" check in. and/or, sometimes they were silly enough to forget to do #include "../config.h" in that particular file, when the needed include is already defined in the auto-generated config.h file. From rupert at opencsw.org Sat Mar 13 12:16:29 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 13 Mar 2010 12:16:29 +0100 Subject: [csw-maintainers] gmake platforms for platform independent packages ... Message-ID: <6af4271003130316x6119e23ahd4fc72c772f8fc2@mail.gmail.com> i guess this is only a cosmetic issue, but when building trac-0.11.7 with "gmake platforms" it exits with: Copying Trac.egg-info to /home/rupert/mgar/pkg/trac/trunk/work/solaris8-i386/install-isa-i 386/opt/csw/lib/python/site-packages/Trac-0.11.7-py2.6.egg-info running install_scripts Installing trac-admin script to /home/rupert/mgar/pkg/trac/trunk/work/solaris8-i386/instal l-isa-i386/opt/csw/bin Installing tracd script to /home/rupert/mgar/pkg/trac/trunk/work/solaris8-i386/install-isa -i386/opt/csw/bin ==> fixconfig: /home/rupert/mgar/pkg/trac/trunk/work/solaris8-i386/install-isa-i386/opt/ csw/lib ==> fixconfig: /home/rupert/mgar/pkg/trac/trunk/work/solaris8-i386/install-isa-i386/opt/ csw/bin gmake[1]: Leaving directory `/home/rupert/mgar/pkg/trac/trunk' [merge] complete for Trac. ERROR: /home/rupert/pkgs/13.Mar.2010/trac-0.11.7,REV=2010.03.13-SunOS5.8-i386-CSW.pkg.gz d oes not exist gmake: *** [pkgcheck] Error 2 gmake: Leaving directory `/home/rupert/mgar/pkg/trac/trunk' Connection to build8x closed. gmake: *** [platforms] Error 2 it would be more beautiful if this would also be aware of platform independence. rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert at opencsw.org Sat Mar 13 12:31:53 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 13 Mar 2010 12:31:53 +0100 Subject: [csw-maintainers] anyone for OpenNMS? In-Reply-To: References: Message-ID: <6af4271003130331n3199176iab9950b0f9e4d424@mail.gmail.com> On Fri, Mar 12, 2010 at 19:20, Philip Brown wrote: > Just a random ping, to see if anyone wanted to package up OpenNMS http://www.opennms.org > > It's kindasorta like nagios, but aimed at "enterprise level, GUI driven" > people. > So its a bit of a hog. (java based, AND database driven). but > certainly a lot prettier. > and has integrated historial stuff, etc, etc. > Would be nice if we offered it. > Got a few missing prereqs, though. > as little bricks make a house i started with checking in a first makefile, only for opennms. does java packaging work similar to python? rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hson at opencsw.org Sat Mar 13 14:40:03 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Sat, 13 Mar 2010 14:40:03 +0100 Subject: [csw-maintainers] pstamp check Message-ID: <4B9B95B3.1040106@opencsw.org> After updating gar on my "buildfarm" I got some new errors from checkpkg. After some investigation it seems that some old checkpkg tests have been backported to python, but the check for pstamp doesn't seem to have a flaw in it. If the hostname have a '-' in it the check fails. I've worked around it using "CHECKPKG_OVERRIDES += pkginfo-pstamp-in-wrong-format" in my .garrc, but someone else might benefit from a bug fix... Output: ------------------------------- There were errors reported. If you know they are false positives, you can override them: CHECKPKG_OVERRIDES_CSWlibrsvgmozilla += pkginfo-pstamp-in-wrong-format|hson at solaris9s-csw-20100313144445 CHECKPKG_OVERRIDES_CSWlibrsvggnome += pkginfo-pstamp-in-wrong-format|hson at solaris9s-csw-20100313144437 CHECKPKG_OVERRIDES_CSWlibrsvg += pkginfo-pstamp-in-wrong-format|hson at solaris9s-csw-20100313144412 CHECKPKG_OVERRIDES_CSWlibrsvgdevel += pkginfo-pstamp-in-wrong-format|hson at solaris9s-csw-20100313144421 CHECKPKG_OVERRIDES_CSWrsvg += pkginfo-pstamp-in-wrong-format|hson at solaris9s-csw-20100313144453 CHECKPKG_OVERRIDES_CSWlibrsvgdoc += pkginfo-pstamp-in-wrong-format|hson at solaris9s-csw-20100313144429 ------------------------------- From maciej at opencsw.org Sat Mar 13 18:40:42 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 13 Mar 2010 17:40:42 +0000 Subject: [csw-maintainers] pstamp check In-Reply-To: <4B9B95B3.1040106@opencsw.org> References: <4B9B95B3.1040106@opencsw.org> Message-ID: On Sat, Mar 13, 2010 at 1:40 PM, Roger H?kansson wrote: > After updating gar on my "buildfarm" I got some new errors from checkpkg. > After some investigation it seems that some old checkpkg tests have been > backported to python, but the check for pstamp doesn't seem to have a flaw > in it. > If the hostname have a '-' in it the check fails. > I've worked around it using "CHECKPKG_OVERRIDES += > pkginfo-pstamp-in-wrong-format" in my .garrc, but someone else might benefit > from a bug fix... > > Output: > ------------------------------- > There were errors reported. > If you know they are false positives, you can override them: > CHECKPKG_OVERRIDES_CSWlibrsvgmozilla += > pkginfo-pstamp-in-wrong-format|hson at solaris9s-csw-20100313144445 > CHECKPKG_OVERRIDES_CSWlibrsvggnome += > pkginfo-pstamp-in-wrong-format|hson at solaris9s-csw-20100313144437 > CHECKPKG_OVERRIDES_CSWlibrsvg += > pkginfo-pstamp-in-wrong-format|hson at solaris9s-csw-20100313144412 > CHECKPKG_OVERRIDES_CSWlibrsvgdevel += > pkginfo-pstamp-in-wrong-format|hson at solaris9s-csw-20100313144421 > CHECKPKG_OVERRIDES_CSWrsvg += > pkginfo-pstamp-in-wrong-format|hson at solaris9s-csw-20100313144453 > CHECKPKG_OVERRIDES_CSWlibrsvgdoc += > pkginfo-pstamp-in-wrong-format|hson at solaris9s-csw-20100313144429 For these to work, you would need to remove the parameter and leave only: CHECKPKG_OVERRIDES_CSWlibrsvgdoc += pkginfo-pstamp-in-wrong-format (etc.) The reason is that at every package creation the pstamp is updated to a new value, and the old override wouldn't match the new pstamp. But the real fix is to allow the minus sign in the host name. While writing a unit test for it, I also discovered a bug in the regex. r9141 fixes both issues: https://sourceforge.net/apps/trac/gar/changeset/9141 Thanks for the report, Roger! Maciej From maciej at opencsw.org Sat Mar 13 18:45:14 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 13 Mar 2010 17:45:14 +0000 Subject: [csw-maintainers] anyone for OpenNMS? In-Reply-To: <6af4271003130331n3199176iab9950b0f9e4d424@mail.gmail.com> References: <6af4271003130331n3199176iab9950b0f9e4d424@mail.gmail.com> Message-ID: On Sat, Mar 13, 2010 at 11:31 AM, rupert THURNER wrote: > as little bricks make a house i started with checking in a first makefile, > only for opennms. does java packaging work similar to python? I myself don't know, but I would like to. If you figure that out make sure to share it on the list! From hson at opencsw.org Sat Mar 13 19:12:10 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Sat, 13 Mar 2010 19:12:10 +0100 Subject: [csw-maintainers] checkpkg error Message-ID: <4B9BD57A.6090903@opencsw.org> After updating gar today (last update was two weeks ago), I get some python-error when building imagemagick. But I've successfully built other packages so there must be something special with these packages. Running modular tests in gar/bin/../lib/checkpkg.d actionclasses [Done] archall [Done] auto [ERROR] basic [Done] license [Done] obsolete-deps [Done] you-can-write-your-own [Done] printing /var/tmp/dissect.29837/checkpkg-archall.py.log... Package CSWimagemagickdev does not contain any binaries. Consider making it ARCHALL = 1 instead of i386: ARCHALL_CSWimagemagickdev = 1 However, be aware that there might be other reasons to keep it architecture-specific. printing /var/tmp/dissect.29837/checkpkg-auto.py.log... # CSWimagemagickrt: # The following dependencies might be unnecessary: # ? CSWlcmsrt # ? CSWtiffrt # CSWimagemagick: # The following dependencies might be unnecessary: # ? CSWdjvulibrert # ? CSWgraphviz # ? CSWlcmsrt # ? CSWlibcairo # ? CSWperl # ? CSWtiffrt # CSWimagemagickdev: # SUGGESTION: you may want to add some or all of the following as depends: # (Feel free to ignore SUNW or SPRO packages) RUNTIME_DEP_PKGS_CSWimagemagickdev += CSWimagemagick Traceback (most recent call last): File "gar/bin/../lib/checkpkg.d/checkpkg-auto.py", line 48, in main() File "gar/bin/../lib/checkpkg.d/checkpkg-auto.py", line 39, in main exit_code, screen_report, tags_report = check_manager.Run() File "gar/bin/../lib/checkpkg.d/../../lib/python/checkpkg.py", line 913, in Run return super(CheckpkgManager2, self).Run() File "gar/bin/../lib/checkpkg.d/../../lib/python/checkpkg.py", line 759, in Run errors = self.GetAllTags(packages_data) File "gar/bin/../lib/checkpkg.d/../../lib/python/checkpkg.py", line 908, in GetAllTags errors = self.SetErrorsToDict(check_interface.errors, errors) AttributeError: 'CheckpkgManager2' object has no attribute 'SetErrorsToDict' ERROR: One or more modular tests have finished with an error. To run checkpkg in the debug mode, add the '-d' flag, for example: gar/bin/checkpkg -d /home/hson/newpkgs/imagemagick-6.6.0,REV=2010.03.13_rev=5-SunOS5.8-i386-UNCOMMITTED.pkg.gz /home/hson/newpkgs/imagemagick_devel-6.6.0,REV=2010.03.13_rev=5-SunOS5.8-i386-UNCOMMITTED.pkg.gz /home/hson/newpkgs/imagemagick_doc-6.6.0,REV=2010.03.13_rev=5-SunOS5.8-all-UNCOMMITTED.pkg.gz /home/hson/newpkgs/imagemagick_rt-6.6.0,REV=2010.03.13_rev=5-SunOS5.8-i386-UNCOMMITTED.pkg.gz /home/hson/newpkgs/pm_imagemagick-6.6.0,REV=2010.03.13_rev=5-SunOS5.8-i386-UNCOMMITTED.pkg.gz From maciej at opencsw.org Sat Mar 13 20:21:26 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 13 Mar 2010 19:21:26 +0000 Subject: [csw-maintainers] checkpkg error In-Reply-To: <4B9BD57A.6090903@opencsw.org> References: <4B9BD57A.6090903@opencsw.org> Message-ID: On Sat, Mar 13, 2010 at 6:12 PM, Roger H?kansson wrote: > After updating gar today (last update was two weeks ago), I get some > python-error when building imagemagick. But I've successfully built other > packages so there must be something special with these packages. I'm currently working on it, so it's probably related to the latest changes. I'm on it right now. From maciej at opencsw.org Sat Mar 13 20:31:31 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 13 Mar 2010 19:31:31 +0000 Subject: [csw-maintainers] checkpkg error In-Reply-To: References: <4B9BD57A.6090903@opencsw.org> Message-ID: On Sat, Mar 13, 2010 at 7:21 PM, Maciej (Matchek) Blizinski wrote: > On Sat, Mar 13, 2010 at 6:12 PM, Roger H?kansson wrote: >> After updating gar today (last update was two weeks ago), I get some >> python-error when building imagemagick. But I've successfully built other >> packages so there must be something special with these packages. > > I'm currently working on it, so it's probably related to the latest > changes. ?I'm on it right now. Fixed in r9144. Sorry for the inconvenience. From yann at pleiades.fr.eu.org Sat Mar 13 21:18:14 2010 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sat, 13 Mar 2010 21:18:14 +0100 Subject: [csw-maintainers] openssh and openssh in experimental Message-ID: <4B9BF306.80202@pleiades.fr.eu.org> Hi all, I have put openssh 5.4p1 and openssl 0.9.8m in experimental: http://mirror.opencsw.org/experimental.html#yann Testing and feedbacks are welcome before I push them in unstable. Yann From william at wbonnet.net Sat Mar 13 22:28:38 2010 From: william at wbonnet.net (William Bonnet) Date: Sat, 13 Mar 2010 22:28:38 +0100 Subject: [csw-maintainers] anyone for OpenNMS? In-Reply-To: References: <6af4271003130331n3199176iab9950b0f9e4d424@mail.gmail.com> Message-ID: <4B9C0386.8060000@wbonnet.net> Hi >> as little bricks make a house i started with checking in a first makefile, >> only for opennms. does java packaging work similar to python? >> > > I myself don't know, but I would like to. If you figure that out make > sure to share it on the list! > I don't know about python packaging, but i made a few java packages. May i help you ? cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From bwalton at opencsw.org Sat Mar 13 22:34:49 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 13 Mar 2010 16:34:49 -0500 Subject: [csw-maintainers] xproto vs x11xproto Message-ID: <1268515963-sup-2839@pinkfloyd.chass.utoronto.ca> It seems we've got packages that provide the same files and are depended on by different things. xproto vs x11xproto is an example I just found... HTH. -Ben From hson at opencsw.org Sat Mar 13 22:00:34 2010 From: hson at opencsw.org (=?UTF-8?B?Um9nZXIgSMOla2Fuc3Nvbg==?=) Date: Sat, 13 Mar 2010 22:00:34 +0100 Subject: [csw-maintainers] checkpkg error In-Reply-To: References: <4B9BD57A.6090903@opencsw.org> Message-ID: <4B9BFCF2.9080601@opencsw.org> On 2010-03-13 20:31, Maciej (Matchek) Blizinski wrote: > On Sat, Mar 13, 2010 at 7:21 PM, Maciej (Matchek) Blizinski > wrote: >> On Sat, Mar 13, 2010 at 6:12 PM, Roger H?kansson wrote: >>> After updating gar today (last update was two weeks ago), I get some >>> python-error when building imagemagick. But I've successfully built other >>> packages so there must be something special with these packages. >> >> I'm currently working on it, so it's probably related to the latest >> changes. I'm on it right now. > > Fixed in r9144. Sorry for the inconvenience. Works better, yes. Also noticed that the suggestion to have xxx as a dependency for xxxdev now is just a suggestion and not an error. Got a warning about an unused override. From maciej at opencsw.org Sat Mar 13 23:53:29 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 13 Mar 2010 22:53:29 +0000 Subject: [csw-maintainers] checkpkg error In-Reply-To: <4B9BFCF2.9080601@opencsw.org> References: <4B9BD57A.6090903@opencsw.org> <4B9BFCF2.9080601@opencsw.org> Message-ID: On Sat, Mar 13, 2010 at 9:00 PM, Roger H?kansson wrote: > On 2010-03-13 20:31, Maciej (Matchek) Blizinski wrote: >> >> On Sat, Mar 13, 2010 at 7:21 PM, Maciej (Matchek) Blizinski >> ?wrote: >>> >>> On Sat, Mar 13, 2010 at 6:12 PM, Roger H?kansson >>> ?wrote: >>>> >>>> After updating gar today (last update was two weeks ago), I get some >>>> python-error when building imagemagick. But I've successfully built >>>> other >>>> packages so there must be something special with these packages. >>> >>> I'm currently working on it, so it's probably related to the latest >>> changes. ?I'm on it right now. >> >> Fixed in r9144. ?Sorry for the inconvenience. > > Works better, yes. > Also noticed that the suggestion to have xxx as a dependency for xxxdev now > is just a suggestion and not an error. Got a warning about an unused > override. Yes, but it's unintended. I'm moving the libs checking code to the new API which makes it easier to write unit tests. There will be a little more turbulence in this area, so the dependency-related errors might be going on and off for a while, as I rework this area of checkpkg. From maciej at opencsw.org Sat Mar 13 23:59:47 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 13 Mar 2010 22:59:47 +0000 Subject: [csw-maintainers] Java packages Message-ID: On Sat, Mar 13, 2010 at 9:28 PM, William Bonnet wrote: > I don't know about python packaging, but i made a few java packages. May i > help you ? For Python, you put files into /opt/csw/lib/python/site-packages, and they are made available through the import statement. For Java, you also need to put the files somewhere, but I'm sure there are some standard directories, and ways to make the java compiler aware of the locations of libraries you intend to import. There's also the ant build system, and probably a lot of other Java specifics. Do you have an example of a Java package that I might look at? The package I would like to build is the Java version of protobuf. Maciej From bwalton at opencsw.org Sun Mar 14 01:17:07 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 13 Mar 2010 19:17:07 -0500 Subject: [csw-maintainers] gnulib how to In-Reply-To: References: <1268009672-sup-6203@apps.cquest.utoronto.ca> Message-ID: <1268525778-sup-2714@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Tue Mar 09 03:16:29 -0500 2010: > This howto tells about gnulib in general. How about making it more > GAR-specific? There are lots of detail to how to integrate the > merging of gnulib into gar. > > ...snip... > > There can be also the step of adding a pre-configure target > (autoreconf?) to the Makefile. Ok, I didn't get back to it as soon as planned, but I've added more info on these two topics. As always, feedback welcome. Thanks -Ben From hson at opencsw.org Sun Mar 14 05:32:35 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Sun, 14 Mar 2010 05:32:35 +0100 Subject: [csw-maintainers] Java packages In-Reply-To: References: Message-ID: <4B9C66E3.7020500@opencsw.org> On 2010-03-13 23:59, Maciej (Matchek) Blizinski wrote: > For Java, you > also need to put the files somewhere, but I'm sure there are some > standard directories, Not really. Well, you could put your stuff in $JAVA_HOME/lib, but that is certainly not standard > and ways to make the java compiler aware of the > locations of libraries you intend to import. You either set environment variable CLASSPATH or you add -classpath when running java. > There's also the ant > build system, and probably a lot of other Java specifics. ant is just a make for java > Do you have > an example of a Java package that I might look at? > > The package I would like to build is the Java version of protobuf. > I had a quick look at it and basically you'll do like this: 1. Build the C++ stuff so that you have protoc built 2. Run: src/protoc --java_out java/src/main/java -Isrc src/google/protobuf/descriptor.proto 3. cd java/src/main/java 4. javac com/google/protobuf/*.java 5. jar cf protobuf-java-2.3.0.jar com/google/protobuf/*.class (jar name derived from pom.xml) 6. cp protobuf-java-2.3.0.jar /whereever/you/want/your/jar From rupert at opencsw.org Sun Mar 14 15:48:39 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 14 Mar 2010 15:48:39 +0100 Subject: [csw-maintainers] anyone for OpenNMS? In-Reply-To: <4B9C0386.8060000@wbonnet.net> References: <6af4271003130331n3199176iab9950b0f9e4d424@mail.gmail.com> <4B9C0386.8060000@wbonnet.net> Message-ID: <6af4271003140748g564d86aekbfe01187667b067b@mail.gmail.com> On Sat, Mar 13, 2010 at 22:28, William Bonnet wrote: > Hi > > > as little bricks make a house i started with checking in a first makefile, >>> only for opennms. does java packaging work similar to python? >>> >>> >> >> I myself don't know, but I would like to. If you figure that out make >> sure to share it on the list! >> >> > I don't know about python packaging, but i made a few java packages. May i > help you ? > > i'd appreciate it a lot. the source (16 MB) is at http://sunet.dl.sourceforge.net/project/opennms/OpenNMS-Source/stable-1.6.10/opennms-source-1.6.10-1.tar.gz and a standalone installer (134 MB) is at http://garr.dl.sourceforge.net/project/opennms/OpenNMS/stable-1.6.10/standalone-opennms-installer-1.6.10.jar the package stub is called opennms in gar. it would already help to give a pointer to one example package. rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sun Mar 14 16:16:30 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 14 Mar 2010 15:16:30 +0000 Subject: [csw-maintainers] checkpkg updates Message-ID: I spent some more time on checkpkg today. I removed almost all the checks from the Korn code and ported them to Python. I also ported all the Python checks to the new API. All the checks are now in this file: https://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/python/package_checks.py The output will be now less verbose, and checkpkg will now run slightly faster. As always, please report any failures you might encounter. Maciej From rupert at opencsw.org Sun Mar 14 16:47:34 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 14 Mar 2010 16:47:34 +0100 Subject: [csw-maintainers] checkpkg updates In-Reply-To: References: Message-ID: <6af4271003140847x7814b1dav7e7d0db2ba92d48a@mail.gmail.com> On Sun, Mar 14, 2010 at 16:16, Maciej (Matchek) Blizinski < maciej at opencsw.org> wrote: > I spent some more time on checkpkg today. I removed almost all the > checks from the Korn code and ported them to Python. I also ported > all the Python checks to the new API. > > All the checks are now in this file: > > https://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/python/package_checks.py > > The output will be now less verbose, and checkpkg will now run slightly > faster. > > As always, please report any failures you might encounter. > > great! i was just wondering why you opted for cheetah, and not mako: http://makotemplates.org/ rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sun Mar 14 20:02:09 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 14 Mar 2010 19:02:09 +0000 Subject: [csw-maintainers] Which x11 library to choose? In-Reply-To: References: <201003040902.o2492h10003745@login.bo.opencsw.org> <6F149BCB-3BDE-4482-9ABB-C6BF036760FA@opencsw.org> <4B923F19.6060106@opencsw.org> Message-ID: On Fri, Mar 12, 2010 at 4:52 PM, Philip Brown wrote: > If we're talking globally... yes, but ONLY for those libraries, that > are expected to be used with other libraries/programs that interact > with our "fancy" X11 libs. To automatically discriminate between the ones that are expected and the ones that aren't, it would take an AI at least as powerful as Phil's... but: > which is most of them. but still, just being pedantic here. > that's my job, after all ;-) Right, so we can deploy a heuristic in which we assume that it's all of them; but it doesn't mean that checkpkg will never pass. The idea of overrides allows to deploy a heuristic which works in most cases, and apply overrides to false positives (which will be a minority). If the minority is significant enough, as it was the case with non-self-contained shared libraries, we can remove the check until we find a better solution. I've implemented it, the check is now live in r9169. From maciej at opencsw.org Sun Mar 14 23:36:14 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 14 Mar 2010 22:36:14 +0000 Subject: [csw-maintainers] checkpkg updates In-Reply-To: <6af4271003140847x7814b1dav7e7d0db2ba92d48a@mail.gmail.com> References: <6af4271003140847x7814b1dav7e7d0db2ba92d48a@mail.gmail.com> Message-ID: On Sun, Mar 14, 2010 at 3:47 PM, rupert THURNER wrote: > great! i was just wondering why you opted for cheetah, and not mako: > http://makotemplates.org/ It's the first time I hear about mako, I never did a comparison between the two. I've only worked with Cheetah before. Are there advantages that mako has over Cheetah? From bwalton at opencsw.org Mon Mar 15 01:54:40 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 14 Mar 2010 20:54:40 -0400 Subject: [csw-maintainers] [RFC] Upstream git handling change Message-ID: <1268614103-sup-5300@pinkfloyd.chass.utoronto.ca> Hi All, I'm considering a change to the way GAR handles upstream repos. This is a result of dealing with an upstream gitorious repo for the first time. It seems that the remote .git repo name is typically mainline.git. While they do offer $project.git too, they're not always identical. The change that I'm proposing is to always store the local copy of the repo as $(GARNAME).git instead of basically doing $(filename $(GITREPO)) (eg: git://github.org/someproj.git -> someproj.git). In my dealings, the url generally contains $(GARNAME).git already, which is why the code 'is the way it is' now. I don't think this will hurt anything, and it removes the conflict of names if multiple gitorious repos are tracked. The only possible downside I can think of is that more 'smarts' would be required in the case that a single GAR project tracks multiple sources, and more than one are git repos. Will this change negatively impact anyone else? Thanks -Ben From jgoerzen at opencsw.org Mon Mar 15 04:05:00 2010 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Sun, 14 Mar 2010 20:05:00 -0700 Subject: [csw-maintainers] Error: Ambiguous "?:" expression In-Reply-To: References: <315c02ae1003081540y4d9aeb73j861c8ea323d096a4@mail.gmail.com> <315c02ae1003090928y37604112tf2140406b1032da6@mail.gmail.com> <4B96CCCD.1070109@opencsw.org> <4B98075B.8080308@opencsw.org> <315c02ae1003121351o247132b9r7d63685a8389d458@mail.gmail.com> Message-ID: <315c02ae1003142005g19e0ac0fh7d732f255e5bce6@mail.gmail.com> On Fri, Mar 12, 2010 at 3:12 PM, Philip Brown wrote: > On Fri, Mar 12, 2010 at 1:51 PM, Jake Goerzen wrote: >>?At the moment the GAR recipe will almost finish >> building but there is at least one more problem to fix but we are very >> close to getting this thing wrapped up. ?At the moment compiling stops >> at time.cpp: >>.... >> "time.hpp", line 29: Error: Type name expected instead of "size_t". > > That looks like a pretty standard, > ?"you need to add an ? #include foo.h ? in Solaris, even though you > dont in linux" > type error. i've seen those a lot :) > > Often fixed by looking at older versions of the file in question, noticing, > "oh, they removed [xxxx]types.h!", putting it back, and emailing the > developers, "hey bozos, put that back in the source!" > > This can often be solidified a bit more permenantly, by providng a patch such as > > #ifdef __sun > # ?include neededthinhere > #endif >. Yep was missing so I've added to time.hpp: #if defined (__SVR4) && defined (__sun) #include #endif This work has been committed to GAR r9178 There are updated packages available in testing/ wesnoth-1.6.5,REV=2010.03.15-SunOS5.8-i386-CSW.pkg.gz wesnoth-1.6.5,REV=2010.03.15-SunOS5.8-sparc-CSW.pkg.gz Thanks, Jake From dam at opencsw.org Mon Mar 15 15:42:59 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 15 Mar 2010 15:42:59 +0100 Subject: [csw-maintainers] CSWimlib2 vs libX11 In-Reply-To: References: Message-ID: <80CCB10D-BC39-4636-9E8E-44881054FDFA@opencsw.org> Hi Maciej, Am 12.03.2010 um 11:09 schrieb Maciej (Matchek) Blizinski: > On Fri, Mar 12, 2010 at 10:07 AM, Maciej (Matchek) Blizinski > wrote: >> $ ldd -r /opt/csw/bin/awesome | grep libX11 >> libX11.so.6 => /opt/csw/X11/lib/libX11.so.6 >> libX11.so.4 => /usr/lib/libX11.so.4 > > I've built awesome, and tried to run it, but it wouldn't draw anything > on the screen. Perhaps this was the cause? > > Examining the binary... > > blizinski at cabbage ~ $ /usr/ccs/bin/dump -Lv /opt/csw/bin/awesome | > grep libX11 > [2] NEEDED libX11.so.6 > > The binary itself only links against libX11.so.6. One of the > dependencies must be pulling libX11.so.4 in. > > $ for l in $(ldd -r /opt/csw/bin/awesome | awk '{print $3}'); do if [ > "$(ldd -r $l | grep libX11.so.4)" ]; then echo $l ; fi; done > /opt/csw/lib/libImlib2.so.1 > /usr/lib/libXext.so.0 > > libImlib2.so.1 belongs to CSWimlib2. And libXext... > > $ for l in $(ldd -r /opt/csw/bin/awesome | awk '{print $3}'); do if [ > "$(ldd -r $l | grep libXext)" ]; then echo $l ; fi; done > /opt/csw/lib/libImlib2.so.1 > /usr/lib/libX11.so.4 > > ...is also needed by CSWimlib2. > > It seems like liking CSWimlib2 against CSW X11 would remove the > linking against two versions of libX11. > > Looking at the build description: > > #EXTRA_INC = $(prefix)/X11/include > #EXTRA_LIB = $(prefix)/X11/lib > #EXTRA_PKG_CONFIG_DIRS = $(prefix)/X11/lib > > BUILD64 = 1 > CONFIGURE_ARGS = $(DIRPATHS) > #CONFIGURE_ARGS += --x-include=$(prefix)/X11/include > #CONFIGURE_ARGS += --x-libraries=$(abspath $(prefix)/X11/lib/$ > (MM_LIBDIR)) > > Dago, it seems like you've explored this before. Was there a problem > with linking imlib2 against CSW X11? I am now redoing giflib and imlib2 with csw x11, which will solve your problem after they have been released. Please stand by. Best regards -- Dago From phil at bolthole.com Mon Mar 15 18:41:52 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 15 Mar 2010 10:41:52 -0700 Subject: [csw-maintainers] Java packages In-Reply-To: <4B9C66E3.7020500@opencsw.org> References: <4B9C66E3.7020500@opencsw.org> Message-ID: On Sat, Mar 13, 2010 at 9:32 PM, Roger H?kansson wrote: > On 2010-03-13 23:59, Maciej (Matchek) Blizinski wrote: >> >> For Java, you >> also need to put the files somewhere, but I'm sure there are some >> standard directories, > > Not really. > Well, you could put your stuff in $JAVA_HOME/lib, but that is certainly not > standard Nooonononono...we have existing, albeit rarely used, standards already. (because we dont package much java stuff) /opt/csw/share/java is where we put random lib-like java .jar files. This IS actually documented in http://www.opencsw.org/standards/layout From william at wbonnet.net Mon Mar 15 21:24:06 2010 From: william at wbonnet.net (William Bonnet) Date: Mon, 15 Mar 2010 21:24:06 +0100 Subject: [csw-maintainers] New web site schedule Message-ID: <4B9E9766.40703@wbonnet.net> Hi all, The work on the new web site made some progress over the last weeks, and we are now close to reach the first version. I have updated what has still to be done on the current site ( http://wiki.opencsw.org/new-website-comments ). Please tell me if you disagree with the answers i made to your comments, or if there are some unknown issues. If no more issues are discovered, i propose to switch to the new web site at the end of the month, on the 1st of April. Please let me know you feelings about this. If we agree on this date, several people will have to coordinate their effort to do the switch. cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From phil at bolthole.com Mon Mar 15 21:32:58 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 15 Mar 2010 13:32:58 -0700 Subject: [csw-maintainers] New web site schedule In-Reply-To: <4B9E9766.40703@wbonnet.net> References: <4B9E9766.40703@wbonnet.net> Message-ID: On Mon, Mar 15, 2010 at 1:24 PM, William Bonnet wrote: > Hi all, > > The work on the new web site made some progress over the last weeks, and we > are now close to reach the first version. > > I have updated what has still to be done on the current site ( > http://wiki.opencsw.org/new-website-comments ). Please tell me if you > disagree with the answers i made to your comments, or if there are some > unknown issues. > prior comments about it being significantly slower than current site, seem to have been either erased, or diluted, with no trace that I can see as to why? I will also make the general comment, that in my opinion, speed issues need to be addressed BEFORE release. Software is usually the fastest when it is first deployed/released. Over time and use, it usually gets slower. So we had better START with "fast" :-) From william at wbonnet.net Mon Mar 15 22:15:36 2010 From: william at wbonnet.net (William Bonnet) Date: Mon, 15 Mar 2010 22:15:36 +0100 Subject: [csw-maintainers] New web site schedule In-Reply-To: References: <4B9E9766.40703@wbonnet.net> Message-ID: <4B9EA378.7030805@wbonnet.net> Hi > prior comments about it being significantly slower than current site, > seem to have been either erased, or diluted, with no trace that I can > see as to why? > I'am adding it to the wiki > Software is usually the fastest when it is first deployed/released. > Over time and use, it usually gets slower. So we had better START with > "fast" :-) > Oh don't worry, it's no going to run on Windows ;) cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From hson at opencsw.org Mon Mar 15 22:24:51 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Mon, 15 Mar 2010 22:24:51 +0100 Subject: [csw-maintainers] Java packages In-Reply-To: References: <4B9C66E3.7020500@opencsw.org> Message-ID: <4B9EA5A3.3080308@opencsw.org> On 2010-03-15 18:41, Philip Brown wrote: > On Sat, Mar 13, 2010 at 9:32 PM, Roger H?kansson wrote: >> On 2010-03-13 23:59, Maciej (Matchek) Blizinski wrote: >>> >>> For Java, you >>> also need to put the files somewhere, but I'm sure there are some >>> standard directories, >> >> Not really. >> Well, you could put your stuff in $JAVA_HOME/lib, but that is certainly not >> standard > > Nooonononono...we have existing, albeit rarely used, standards already. > (because we dont package much java stuff) > > /opt/csw/share/java > > is where we put random lib-like java .jar files. > > This IS actually documented in > > http://www.opencsw.org/standards/layout I was trying to point out the fact that the only place jvm will look for classes is in its own installdir and speaking in general terms, not opencsw-specific. It will not find the stuff in /opt/csw/share/java unless you set the classpath (either through environment variable or by option when invoking java/javac). There is nothing like LD_OPTIONS/LD_LIBRARY_PATH/RUNPATH when it comes to java. From phil at bolthole.com Mon Mar 15 23:30:47 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 15 Mar 2010 15:30:47 -0700 Subject: [csw-maintainers] Java packages In-Reply-To: <4B9EA5A3.3080308@opencsw.org> References: <4B9C66E3.7020500@opencsw.org> <4B9EA5A3.3080308@opencsw.org> Message-ID: On Mon, Mar 15, 2010 at 2:24 PM, Roger H?kansson wrote: > > I was trying to point out the fact that the only place jvm will look for > classes is in its own installdir and speaking in general terms, not > opencsw-specific. > It will not find the stuff in /opt/csw/share/java unless you set the > classpath (either through environment variable or by option when invoking > java/javac). > There is nothing like LD_OPTIONS/LD_LIBRARY_PATH/RUNPATH when it comes to > java. > sure there is. CLASSPATH. erm.. and you just acknowleged that, above? so, I'm a little confused? :-} (and technically, I think that, while there isnt a "standard" compiled-in thing like RPATH, I believe that java programs can programatically alter their own CLASSPATH if they choose. (so, technically, you CAN "compile in" a CLASSPATH, of sorts) But its been a long time since I dabbled in java, so i could be misremembering. From hson at opencsw.org Mon Mar 15 23:08:04 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Mon, 15 Mar 2010 23:08:04 +0100 Subject: [csw-maintainers] Java packages In-Reply-To: References: <4B9C66E3.7020500@opencsw.org> <4B9EA5A3.3080308@opencsw.org> Message-ID: <4B9EAFC4.1090506@opencsw.org> On 2010-03-15 23:30, Philip Brown wrote: > erm.. and you just acknowleged that, above? so, I'm a little confused? :-} You cut out that portion of my mail... > (and technically, I think that, while there isnt a "standard" > compiled-in thing like RPATH, I believe that java programs can > programatically alter their own CLASSPATH if they choose. > (so, technically, you CAN "compile in" a CLASSPATH, of sorts) Not that I can think of, possibly you could load your classes manually, but thats more like dlopen.. From phil at bolthole.com Tue Mar 16 00:28:25 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 15 Mar 2010 16:28:25 -0700 Subject: [csw-maintainers] Java packages In-Reply-To: <4B9EAFC4.1090506@opencsw.org> References: <4B9C66E3.7020500@opencsw.org> <4B9EA5A3.3080308@opencsw.org> <4B9EAFC4.1090506@opencsw.org> Message-ID: On Mon, Mar 15, 2010 at 3:08 PM, Roger H?kansson wrote: > On 2010-03-15 23:30, Philip Brown wrote: >> (and technically, I think that, while there isnt a "standard" >> compiled-in thing like RPATH, I believe that java programs can >> programatically alter their own CLASSPATH if they choose. >> (so, technically, you CAN "compile in" a CLASSPATH, of sorts) > > Not that I can think of, possibly you could load your classes manually, but > thats more like dlopen.. > (dug into things from the past...) oh. that's right, there isnt a nice,simple, CLEAN way to do it. You have to do interesting things like override the system ClassLoader with your own custom one. heh heh heh... From rupert at opencsw.org Tue Mar 16 00:58:27 2010 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 16 Mar 2010 00:58:27 +0100 Subject: [csw-maintainers] Java packages In-Reply-To: References: <4B9C66E3.7020500@opencsw.org> <4B9EA5A3.3080308@opencsw.org> <4B9EAFC4.1090506@opencsw.org> Message-ID: <6af4271003151658j6b307639l54005cf0d6aa4eb9@mail.gmail.com> On Tue, Mar 16, 2010 at 00:28, Philip Brown wrote: > On Mon, Mar 15, 2010 at 3:08 PM, Roger H?kansson wrote: > > On 2010-03-15 23:30, Philip Brown wrote: > > >> (and technically, I think that, while there isnt a "standard" > >> compiled-in thing like RPATH, I believe that java programs can > >> programatically alter their own CLASSPATH if they choose. > >> (so, technically, you CAN "compile in" a CLASSPATH, of sorts) > > > > Not that I can think of, possibly you could load your classes manually, > but > > thats more like dlopen.. > > > > > (dug into things from the past...) > > oh. that's right, there isnt a nice,simple, CLEAN way to do it. > You have to do interesting things like override the system ClassLoader > with your own custom one. heh heh heh... > > > setting the path in the manifest of the jar file which contains the main would be possible: * http://en.wikipedia.org/wiki/Classpath_%28Java%29#Setting_the_path_in_a_Manifest_file * http://stackoverflow.com/questions/858766/generate-manifest-class-path-from-classpath-in-ant which is kind of compiled in. rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at bolthole.com Tue Mar 16 01:40:04 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 15 Mar 2010 17:40:04 -0700 Subject: [csw-maintainers] Java packages In-Reply-To: <6af4271003151658j6b307639l54005cf0d6aa4eb9@mail.gmail.com> References: <4B9C66E3.7020500@opencsw.org> <4B9EA5A3.3080308@opencsw.org> <4B9EAFC4.1090506@opencsw.org> <6af4271003151658j6b307639l54005cf0d6aa4eb9@mail.gmail.com> Message-ID: On Mon, Mar 15, 2010 at 4:58 PM, rupert THURNER wrote: > > setting the path in the manifest of the jar file which contains the main > would be possible: > > * > http://en.wikipedia.org/wiki/Classpath_%28Java%29#Setting_the_path_in_a_Manifest_file > * > http://stackoverflow.com/questions/858766/generate-manifest-class-path-from-classpath-in-ant > > which is kind of compiled in. > oh hey yeah i forgot about that! That would make sense for us, methinks. For those apps that do get delivered as jars, and/or java libs of ours, that depend on OTHER java libs of ours. From dam at opencsw.org Tue Mar 16 11:17:53 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 16 Mar 2010 11:17:53 +0100 Subject: [csw-maintainers] Updating all buildservers now Message-ID: Hi, I am updating all servers to current now, please stand by. Best regards -- Dago From dam at opencsw.org Tue Mar 16 12:59:29 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 16 Mar 2010 12:59:29 +0100 Subject: [csw-maintainers] Another cycle in the catalog Message-ID: <72ED1CCB-55BD-4169-BF5E-10415D474BC5@opencsw.org> Hi, there is another cycle in the catalog: > root at login [login]:/root > chkcat -e /export/mirror/opencsw/current/ > sparc/5.8/catalog > > ERROR! Cyclic dependency detected in package CSWlibpoppler. > > ERROR! Cyclic dependency detected in package CSWpoppler. Phil, could you please check this before pushing the catalog? Best regards -- Dago From dam at opencsw.org Tue Mar 16 15:49:38 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 16 Mar 2010 15:49:38 +0100 Subject: [csw-maintainers] Please repackage ghostcript and tiff In-Reply-To: <4B9799E3.7050106@opencsw.org> References: <4B9799E3.7050106@opencsw.org> Message-ID: <0B27F6DF-1112-463F-8BE3-506CDC56179E@opencsw.org> Hi James, Am 10.03.2010 um 14:08 schrieb Roger H?kansson: > James, could you repackage ghostscript and tiff so that they get > linked to libjpeg.so.7 instead of libjpeg.so.62. > > Currently this is holding back the release of several packages > (djvulibre, lcms, imagemagick) where imagemagick is the most crucial > one since we have a problem which relates to this specific problem. > > I've garified both packages (3.9.2 for tiff, but you could change > version number in the Makefile to 3.8.2 and it will build just as > easily) and you should only have to checkout and then do "gmake > package" to build them. Do you have a timeframe when you will get to updating these? I now you are reluctant to use GAR, but as they are already in there is should be worth your effort to learn how to respin stuff. Best regards -- Dago From hson at opencsw.org Tue Mar 16 16:23:26 2010 From: hson at opencsw.org (=?UTF-8?B?Um9nZXIgSMOla2Fuc3Nvbg==?=) Date: Tue, 16 Mar 2010 16:23:26 +0100 Subject: [csw-maintainers] [csw-users] evince-2.24.2 in experimental In-Reply-To: References: <4B9614B0.7030503@cmi.univ-mrs.fr> <4B989CCA.2060409@opencsw.org> <4B98B139.8020001@opencsw.org> Message-ID: <4B9FA26E.3020103@opencsw.org> Maciej (Matchek) Blizinski wrote: > On Thu, Mar 11, 2010 at 9:00 AM, Roger H?kansson wrote: >> On 2010-03-11 09:46, Maciej (Matchek) Blizinski wrote: >>> I was thinking of 0.12, but we can try evince with 0.10.x too. >>> >>> The problem with poppler 0.12 is that it requires lcms, which needs to >>> be released in 64-bit, but lcms depends on Python, which is not, and >>> will not, in the nearest future, be available in 64-bit. >> Why not? > > I've looked at it once. Python headers do checks on certain 64-bit > related constants, which AFAIK are set by the compiler; the assertions > in the Python code are failing. > > "/opt/csw/include/python2.6/pyport.h", line 680: Error: #error > "LONG_BIT definition appears wrong for platform (bad gcc/glibc > config?).". > Well, I've somewhat (comment below) successfully built a 64-bit python on my own buildfarm (needed for dependencies for the 64-bit imagemagick). And it seems to be working just fine for my needs (libpython.so) The problems I've had relates to the binaries (python, python2.6...) there seems like there is some problem during merge. Also, the _curses module fails due to some link error. However, in order to successfully build a 64-bit python, you need a 64-bit libffi which requires the SOS12-compiler (currently not available on Solaris8 on the buildfarm, but seems to be working just fine for me), which needs a 64-bit expect, which need 64-bit tcl/tk... From dam at opencsw.org Tue Mar 16 16:33:26 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 16 Mar 2010 16:33:26 +0100 Subject: [csw-maintainers] [csw-users] evince-2.24.2 in experimental In-Reply-To: <4B9FA26E.3020103@opencsw.org> References: <4B9614B0.7030503@cmi.univ-mrs.fr> <4B989CCA.2060409@opencsw.org> <4B98B139.8020001@opencsw.org> <4B9FA26E.3020103@opencsw.org> Message-ID: <4C3E101E-01A6-465F-8693-57EA5816DB1C@opencsw.org> Hi Roger, Am 16.03.2010 um 16:23 schrieb Roger H?kansson: > Maciej (Matchek) Blizinski wrote: >> On Thu, Mar 11, 2010 at 9:00 AM, Roger H?kansson >> wrote: >>> On 2010-03-11 09:46, Maciej (Matchek) Blizinski wrote: >>>> I was thinking of 0.12, but we can try evince with 0.10.x too. >>>> >>>> The problem with poppler 0.12 is that it requires lcms, which >>>> needs to >>>> be released in 64-bit, but lcms depends on Python, which is not, >>>> and >>>> will not, in the nearest future, be available in 64-bit. >>> Why not? >> I've looked at it once. Python headers do checks on certain 64-bit >> related constants, which AFAIK are set by the compiler; the >> assertions >> in the Python code are failing. >> "/opt/csw/include/python2.6/pyport.h", line 680: Error: #error >> "LONG_BIT definition appears wrong for platform (bad gcc/glibc >> config?).". > > Well, I've somewhat (comment below) successfully built a 64-bit > python on my own buildfarm (needed for dependencies for the 64-bit > imagemagick). > > And it seems to be working just fine for my needs (libpython.so) > > The problems I've had relates to the binaries (python, python2.6...) > there seems like there is some problem during merge. If you have merge-specific problems just let me know. > Also, the _curses module fails due to some link error. > > However, in order to successfully build a 64-bit python, you need a > 64-bit libffi which requires the SOS12-compiler (currently not > available on Solaris8 on the buildfarm, but seems to be working just > fine for me), It works if you have SOS12 installed. AFAIK the problem is that the libc doesn't contain specific parts which are also in the compiler-shipped version. So without the compiler they will fail. Additionally, SOS12 is compiled starting from Solaris 9, but as we don't have Solaris 8 mandatory any more just start with SOS12 on Solaris 9. > which needs a 64-bit expect, which need 64-bit tcl/tk... We both do work on this, so we? ;-) Best regards -- Dago From dam at opencsw.org Tue Mar 16 16:50:01 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 16 Mar 2010 16:50:01 +0100 Subject: [csw-maintainers] Completely drop Solaris8? Message-ID: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> Hi, I am currently working on an updated glib and have the behavious that on Solaris 8 i386 a couple of tests fail, most certainly due to threading issues. As glib is quite fundamental and the issues are related to the operating system and we have already voted to support Solaris 8 on a best effort basis it may really be time now to completely drop it. Thoughts? Best regards -- Dago From ellson at opencsw.org Tue Mar 16 17:03:40 2010 From: ellson at opencsw.org (John Ellson) Date: Tue, 16 Mar 2010 12:03:40 -0400 Subject: [csw-maintainers] Please repackage ghostcript and tiff In-Reply-To: <0B27F6DF-1112-463F-8BE3-506CDC56179E@opencsw.org> References: <4B9799E3.7050106@opencsw.org> <0B27F6DF-1112-463F-8BE3-506CDC56179E@opencsw.org> Message-ID: <4B9FABDC.2040906@opencsw.org> James, When repackaging ghostscript, please also use the opencsw version of X11. This is currently holding back a plugin for graphviz. Thanks. (There is a bug report for this. Just taking the opportunity to bundle with these other requests.) John On 03/16/10 10:49, Dagobert Michelsen wrote: > Hi James, > > Am 10.03.2010 um 14:08 schrieb Roger H?kansson: >> James, could you repackage ghostscript and tiff so that they get >> linked to libjpeg.so.7 instead of libjpeg.so.62. >> >> Currently this is holding back the release of several packages >> (djvulibre, lcms, imagemagick) where imagemagick is the most crucial >> one since we have a problem which relates to this specific problem. >> >> I've garified both packages (3.9.2 for tiff, but you could change >> version number in the Makefile to 3.8.2 and it will build just as >> easily) and you should only have to checkout and then do "gmake >> package" to build them. > > Do you have a timeframe when you will get to updating these? I now you > are reluctant to use GAR, but as they are already in there is should be > worth your effort to learn how to respin stuff. > > > 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 hson at opencsw.org Tue Mar 16 17:05:24 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Tue, 16 Mar 2010 17:05:24 +0100 Subject: [csw-maintainers] Please repackage ghostcript and tiff In-Reply-To: <4B9FABDC.2040906@opencsw.org> References: <4B9799E3.7050106@opencsw.org> <0B27F6DF-1112-463F-8BE3-506CDC56179E@opencsw.org> <4B9FABDC.2040906@opencsw.org> Message-ID: <4B9FAC44.9040900@opencsw.org> On 2010-03-16 17:03, John Ellson wrote: > James, > > When repackaging ghostscript, please also use the opencsw version of > X11. This is currently holding back a plugin for graphviz. Thanks. > (There is a bug report for this. Just taking the opportunity to bundle > with these other requests.) I've already fixed that in the GAR recipe. From ellson at opencsw.org Tue Mar 16 17:06:30 2010 From: ellson at opencsw.org (John Ellson) Date: Tue, 16 Mar 2010 12:06:30 -0400 Subject: [csw-maintainers] Please repackage ghostcript and tiff In-Reply-To: <4B9FAC44.9040900@opencsw.org> References: <4B9799E3.7050106@opencsw.org> <0B27F6DF-1112-463F-8BE3-506CDC56179E@opencsw.org> <4B9FABDC.2040906@opencsw.org> <4B9FAC44.9040900@opencsw.org> Message-ID: <4B9FAC86.9040905@opencsw.org> On 03/16/10 12:05, Roger H?kansson wrote: > On 2010-03-16 17:03, John Ellson wrote: >> James, >> >> When repackaging ghostscript, please also use the opencsw version of >> X11. This is currently holding back a plugin for graphviz. Thanks. >> (There is a bug report for this. Just taking the opportunity to bundle >> with these other requests.) > > I've already fixed that in the GAR recipe. Good news. Thanks. John From bwalton at opencsw.org Tue Mar 16 17:07:24 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 16 Mar 2010 12:07:24 -0400 Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> Message-ID: <1268755526-sup-8828@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Tue Mar 16 11:50:01 -0400 2010: > completely drop it. Thoughts? If Sun^H^H^HOracle doesn't support it why should we? I think it made sense originally to support it for a final release, but we've a year+ out from the EOL date with no stable release on the horizon. More and more things require extra effort to support on 8, so what's the actual benefit? +1 for dropping it. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From hson at opencsw.org Tue Mar 16 17:09:15 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Tue, 16 Mar 2010 17:09:15 +0100 Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> Message-ID: <4B9FAD2B.10902@opencsw.org> On 2010-03-16 16:50, Dagobert Michelsen wrote: > Hi, > > I am currently working on an updated glib and have the > behavious that on Solaris 8 i386 a couple of tests fail, > most certainly due to threading issues. As glib is quite > fundamental and the issues are related to the operating > system and we have already voted to support Solaris 8 > on a best effort basis it may really be time now to > completely drop it. Thoughts? > The number of people running Solaris 8 should be few today. The only reason for running Solaris 8 is if you have a sun4d machine or have some driver or application that doesn't work on Solaris 9. If you are running x86, I haven't yet found any machine that can run Solaris 8 but not Solaris 10. Also, working as a consultant, the only ones running something older than Solaris 9 I've come across the past two years, have either been sent to the grave or are actually running something older than Solaris 8 (one is running 2.6 due to a driver issue). Jumping to Solaris 9 will let us use SOS12 in a supported way (even though Sun might consider SOS12 unsupported, haven't taken a look at that), which will make life a lot easier for us since SOS12 have a lot of new functionality which makes porting code from GCC/Linux easier (a lot less ifdefs needed). My take on it is: lets freeze the Solaris 8 trail, but keep it as a legacy trail for those still running Solaris 8. Bug fixes to that trail is only done if the maintainer chooses so. From bonivart at opencsw.org Tue Mar 16 17:27:16 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 16 Mar 2010 17:27:16 +0100 Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: <4B9FAD2B.10902@opencsw.org> References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> <4B9FAD2B.10902@opencsw.org> Message-ID: <625385e31003160927u74363513h67f63b62a3f8d1ff@mail.gmail.com> On Tue, Mar 16, 2010 at 5:09 PM, Roger H?kansson wrote: > My take on it is: lets freeze the Solaris 8 trail, but keep it as a legacy > trail for those still running Solaris 8. Bug fixes to that trail is only > done if the maintainer chooses so. +1 -- /peter From benny at opencsw.org Tue Mar 16 17:32:23 2010 From: benny at opencsw.org (Benjamin von Mossner) Date: Tue, 16 Mar 2010 17:32:23 +0100 Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: <625385e31003160927u74363513h67f63b62a3f8d1ff@mail.gmail.com> References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> <4B9FAD2B.10902@opencsw.org> <625385e31003160927u74363513h67f63b62a3f8d1ff@mail.gmail.com> Message-ID: <20100316163223.GB12186@vonmossner.de> On Tue, Mar 16, 2010 at 05:27:16PM +0100, Peter Bonivart wrote: > On Tue, Mar 16, 2010 at 5:09 PM, Roger H?kansson wrote: > > My take on it is: lets freeze the Solaris 8 trail, but keep it as a legacy > > trail for those still running Solaris 8. Bug fixes to that trail is only > > done if the maintainer chooses so. > +1 another +1 cheers, benny -- /"\ ASCII RIBBON CAMPAIGN | Benjamin von Mossner \ / AGAINST HTML MAIL | benny at vonmossner.de X / \ multiple exclamation marks are a sure sign of a diseased mind From hson at opencsw.org Tue Mar 16 17:48:40 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Tue, 16 Mar 2010 17:48:40 +0100 Subject: [csw-maintainers] [csw-users] evince-2.24.2 in experimental In-Reply-To: <4C3E101E-01A6-465F-8693-57EA5816DB1C@opencsw.org> References: <4B9614B0.7030503@cmi.univ-mrs.fr> <4B989CCA.2060409@opencsw.org> <4B98B139.8020001@opencsw.org> <4B9FA26E.3020103@opencsw.org> <4C3E101E-01A6-465F-8693-57EA5816DB1C@opencsw.org> Message-ID: <4B9FB668.20001@opencsw.org> On 2010-03-16 16:33, Dagobert Michelsen wrote: >> The problems I've had relates to the binaries (python, python2.6...) >> there seems like there is some problem during merge. > > If you have merge-specific problems just let me know. > I'll repackage using the latest GAR release and get back to you if needed... >> However, in order to successfully build a 64-bit python, you need a >> 64-bit libffi which requires the SOS12-compiler (currently not >> available on Solaris8 on the buildfarm, but seems to be working just >> fine for me), > > It works if you have SOS12 installed. AFAIK the problem is that the libc > doesn't > contain specific parts which are also in the compiler-shipped version. > So without > the compiler they will fail. Additionally, SOS12 is compiled starting > from Solaris 9, > but as we don't have Solaris 8 mandatory any more just start with SOS12 > on Solaris 9. Well, I haven't tested my libffi on any other machine yet, so you might be right. However, from what I've been reading, the only problem with SOS12 on Solaris8 is that dbx isn't that stable. The implications of using Solaris9 for libffi is larger than just imagemagick. libffi is a requirement for gobject-introspection (new package), which is a requirement for polkit (new package), which is a requirement for gconf2 (old package). This means that building 64-bit packages that depend on gconf2 will only be possible on Solaris9, and there are a ton of packages depending on gconf2... >> which needs a 64-bit expect, which need 64-bit tcl/tk... > > We both do work on this, so we? ;-) > Nah, I've built one version which I have installed on my buildfarm and are waiting for you to finish your work. Unless you need some help... From william at wbonnet.net Tue Mar 16 18:13:06 2010 From: william at wbonnet.net (William Bonnet) Date: Tue, 16 Mar 2010 18:13:06 +0100 Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: <20100316163223.GB12186@vonmossner.de> References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> <4B9FAD2B.10902@opencsw.org> <625385e31003160927u74363513h67f63b62a3f8d1ff@mail.gmail.com> <20100316163223.GB12186@vonmossner.de> Message-ID: <4B9FBC22.1050800@wbonnet.net> Hi >>> My take on it is: lets freeze the Solaris 8 trail, but keep it as a legacy >>> trail for those still running Solaris 8. Bug fixes to that trail is only >>> done if the maintainer chooses so. >>> >> +1 >> > > another +1 > We actually have a loooootttt of software which are available on Solaris 8 and not yet released as stable. So I would say, let's do one last "stable" supporting Solaris 8, then freeze it. After this freeze, if people need Solaris 8 packages, i would support the idea to provide missing GAR description instead of providing packages for this legacy version. What i mean is that our policy might be the following If you need a package update for Solaris 8, please use GAR and rebuilt it by your self If it is not in GAR, then we will add build description, but not provide package. Thoughts about this ? cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From james at opencsw.org Tue Mar 16 18:17:43 2010 From: james at opencsw.org (James Lee) Date: Tue, 16 Mar 2010 17:17:43 GMT Subject: [csw-maintainers] Please repackage ghostcript and tiff In-Reply-To: <0B27F6DF-1112-463F-8BE3-506CDC56179E@opencsw.org> References: <4B9799E3.7050106@opencsw.org> <0B27F6DF-1112-463F-8BE3-506CDC56179E@opencsw.org> Message-ID: <20100316.17174300.3368812714@gyor.oxdrove.co.uk> On 16/03/10, 14:49:38, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Please repackage ghostcript and tiff: > Am 10.03.2010 um 14:08 schrieb Roger H?kansson: > > James, could you repackage ghostscript and tiff so that they get > > linked to libjpeg.so.7 instead of libjpeg.so.62. > Do you have a timeframe when you will get to updating these? The observant will have noticed tiff released yesterday. I was working on Ghostscript 8.71 over the weekend and have been half of today. James. From pfelecan at opencsw.org Tue Mar 16 18:17:52 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 16 Mar 2010 18:17:52 +0100 Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: <20100316163223.GB12186@vonmossner.de> (Benjamin von Mossner's message of "Tue, 16 Mar 2010 17:32:23 +0100") References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> <4B9FAD2B.10902@opencsw.org> <625385e31003160927u74363513h67f63b62a3f8d1ff@mail.gmail.com> <20100316163223.GB12186@vonmossner.de> Message-ID: Benjamin von Mossner writes: > On Tue, Mar 16, 2010 at 05:27:16PM +0100, Peter Bonivart wrote: >> On Tue, Mar 16, 2010 at 5:09 PM, Roger H?kansson wrote: >> > My take on it is: lets freeze the Solaris 8 trail, but keep it as a legacy >> > trail for those still running Solaris 8. Bug fixes to that trail is only >> > done if the maintainer chooses so. >> +1 > > another +1 I'm even for dropping Solaris 9 (who gives a Greek drachma on so old versions?) but all that voting was never taken into account; better to howl into the wind. -- Peter From dam at opencsw.org Tue Mar 16 18:19:31 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 16 Mar 2010 18:19:31 +0100 Subject: [csw-maintainers] Please repackage ghostcript and tiff In-Reply-To: <20100316.17174300.3368812714@gyor.oxdrove.co.uk> References: <4B9799E3.7050106@opencsw.org> <0B27F6DF-1112-463F-8BE3-506CDC56179E@opencsw.org> <20100316.17174300.3368812714@gyor.oxdrove.co.uk> Message-ID: <12672E86-395C-405C-AEA2-7FDB5B8C3963@opencsw.org> Hi James, Am 16.03.2010 um 18:17 schrieb James Lee: > On 16/03/10, 14:49:38, Dagobert Michelsen wrote > regarding > Re: [csw-maintainers] Please repackage ghostcript and tiff: > >> Am 10.03.2010 um 14:08 schrieb Roger H?kansson: >>> James, could you repackage ghostscript and tiff so that they get >>> linked to libjpeg.so.7 instead of libjpeg.so.62. > >> Do you have a timeframe when you will get to updating these? > > The observant will have noticed tiff released yesterday. I did now. It would be nice if you would also post to pkgsubmissions@ if you release packages. > I was > working on Ghostscript 8.71 over the weekend and have been half > of today. Thank you :-) Best regards -- Dago From james at opencsw.org Tue Mar 16 18:34:19 2010 From: james at opencsw.org (James Lee) Date: Tue, 16 Mar 2010 17:34:19 GMT Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: <4B9FBC22.1050800@wbonnet.net> References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> <4B9FAD2B.10902@opencsw.org> <625385e31003160927u74363513h67f63b62a3f8d1ff@mail.gmail.com> <20100316163223.GB12186@vonmossner.de> <4B9FBC22.1050800@wbonnet.net> Message-ID: <20100316.17341900.1565549244@gyor.oxdrove.co.uk> On 16/03/10, 17:13:06, William Bonnet wrote regarding Re: [csw-maintainers] Completely drop Solaris8?: > We actually have a loooootttt of software which are available on Solaris > 8 and not yet released as stable. So I would say, let's do one last > "stable" supporting Solaris 8, then freeze it. This was the plan as I saw it. Statement on stable: I've been doing a lot of work on testing the integrity of the current unstable with a view to putting forward a stable release candidate. The problem is it fails badly and fundamentally because of the use of CSW X11. I will add more in another thread later. James. From hson at opencsw.org Tue Mar 16 18:56:39 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Tue, 16 Mar 2010 18:56:39 +0100 Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> <4B9FAD2B.10902@opencsw.org> <625385e31003160927u74363513h67f63b62a3f8d1ff@mail.gmail.com> <20100316163223.GB12186@vonmossner.de> Message-ID: <4B9FC657.8080502@opencsw.org> On 2010-03-16 18:17, Peter FELECAN wrote: > > I'm even for dropping Solaris 9 (who gives a Greek drachma on so old > versions?) Well, there still are a lot of people running Solaris 9. Its not uncommon that companies doesn't upgrade OS during the lifetime of the HW. And even though the "financial liftime" (for accounting purposes) here in Sweden is 3 years, many use their systems longer than that. Also many times you can't use the latest release for some reason (proprietory software not supported on newer OS yet) so even though at install time you had something newer to choose from, you got something older. And then you have the usual "hmm, let someone else be the guinea pig and discover all the bugs in either SW or OS or a combo" which makes people wait a while until they start using the latest. If you put all of that together, I know of a lot of companies having systems with Solaris 9 with varying reasons why they run Solaris 9 and not 10. Most of those systems are being planned to be replaced, but I would say that its not until late next year they will have replaced most of them. ( One customer of mine shut down their last E450 with Solaris 2.6 last year... ) But I would say that in general there should not be any reason for us supporting anything but releases in GA or "Retired Phase 1" and Solaris 9 will end up in "Retired Phase 2" in october 2011. From william at wbonnet.net Tue Mar 16 20:17:19 2010 From: william at wbonnet.net (William Bonnet) Date: Tue, 16 Mar 2010 20:17:19 +0100 Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> <4B9FAD2B.10902@opencsw.org> <625385e31003160927u74363513h67f63b62a3f8d1ff@mail.gmail.com> <20100316163223.GB12186@vonmossner.de> Message-ID: <4B9FD93F.6000806@wbonnet.net> Hi > I'm even for dropping Solaris 9 (who gives a Greek drachma on so old > versions?) but all that voting was never taken into account; better to > howl into the wind. > Dropping Solaris 9 would be the real change. IMHO dropping only solaris 8 won't change things that much. Since we do almost have no specific Solaris 9 packages, switching to Solaris 9 would be in most of cases, just "please wait until something happens". And what would happen would be recompile existing packages to Solaris 9 next time they are updated. If we consider : . the number of outdated packages, and . the fact that we do not release "versions" in the debian way (i mean we are not going to recompile everything under solaris 9 at once) Nothing would change at short term, or at least not significantly before Solaris 9 EOL (which does not mean i'm against the idea of dropping Solaris 9). If we decide to do such a drop (solaris 8 or both 8 and 9), i'm wondering several things. Especially : . should we do or not do a kind "rebuild world" . should we do a mass update at the same time ? Otherwise i'm afraid that just announcing "we drop Solaris 8" won't change anything before months since users will still see several hundreds of Solaris 8 packages in the catalog. cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From dam at opencsw.org Tue Mar 16 20:44:02 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 16 Mar 2010 20:44:02 +0100 Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: <20100316.17341900.1565549244@gyor.oxdrove.co.uk> References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> <4B9FAD2B.10902@opencsw.org> <625385e31003160927u74363513h67f63b62a3f8d1ff@mail.gmail.com> <20100316163223.GB12186@vonmossner.de> <4B9FBC22.1050800@wbonnet.net> <20100316.17341900.1565549244@gyor.oxdrove.co.uk> Message-ID: Hi James, Am 16.03.2010 um 18:34 schrieb James Lee: > On 16/03/10, 17:13:06, William Bonnet wrote > regarding > Re: [csw-maintainers] Completely drop Solaris8?: > >> We actually have a loooootttt of software which are available on >> Solaris >> 8 and not yet released as stable. So I would say, let's do one last >> "stable" supporting Solaris 8, then freeze it. > > This was the plan as I saw it. > > Statement on stable: I've been doing a lot of work on testing the > integrity of the current unstable with a view to putting forward > a stable release candidate. Thanks for your effort, I really appreciate it. > The problem is it fails badly and > fundamentally because of the use of CSW X11. Ok, so there will be some massive rebuilds needed. I already set up a wiki page with all known defects to publicly track progress: > I will add more in another thread later. Great! I would need next a rebuild of your CSWmesa for freeglut, which is ready to the point where I just need to rebuild. Best regards -- Dago From phil at bolthole.com Tue Mar 16 21:17:47 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 16 Mar 2010 13:17:47 -0700 Subject: [csw-maintainers] performance co-pilot Message-ID: Turns out that someone has done a fair amount of work in providing a port of "performance co-pilot" to solaris, in the actual upstream source tree. They've even gone so far as to work on SMF integration!! $ more postinstall #!/bin/sh # Import PCP services into SMF but do not start them - let admin do it # when and it she's ready. svccfg import /var/svc/manifest/application/pcp.xml Would anyone be interested in packaging this up? http://oss.sgi.com/projects/pcp/ From dam at opencsw.org Wed Mar 17 09:06:13 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 17 Mar 2010 09:06:13 +0100 Subject: [csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw Message-ID: <740D4C44-60A7-4734-9180-C4F3FBECAD3B@opencsw.org> Hi, could someone who advocates shared NFS please suggest something on the user of alternatives in such an environment? Best regards -- Dago From dam at opencsw.org Wed Mar 17 13:47:01 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 17 Mar 2010 13:47:01 +0100 Subject: [csw-maintainers] [csw-users] evince-2.24.2 in experimental In-Reply-To: <4B9FB668.20001@opencsw.org> References: <4B9614B0.7030503@cmi.univ-mrs.fr> <4B989CCA.2060409@opencsw.org> <4B98B139.8020001@opencsw.org> <4B9FA26E.3020103@opencsw.org> <4C3E101E-01A6-465F-8693-57EA5816DB1C@opencsw.org> <4B9FB668.20001@opencsw.org> Message-ID: <7EEE8AE8-661C-439F-9D76-D07494B016AB@opencsw.org> Hi Roger, Am 16.03.2010 um 17:48 schrieb Roger H?kansson: >>> which needs a 64-bit expect, which need 64-bit tcl/tk... >> >> We both do work on this, so we? ;-) > > Nah, I've built one version which I have installed on my buildfarm > and are waiting for you to finish your work. > Unless you need some help... I am a bit overworked lately and would really appreciate if you could give me a hand on tk/expect. Hopefully I have outlined a way to go with GAR. Everything I have committed is in GAR. Best regards -- Dago From phil at bolthole.com Wed Mar 17 18:00:07 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 17 Mar 2010 10:00:07 -0700 Subject: [csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw In-Reply-To: <740D4C44-60A7-4734-9180-C4F3FBECAD3B@opencsw.org> References: <740D4C44-60A7-4734-9180-C4F3FBECAD3B@opencsw.org> Message-ID: On Wed, Mar 17, 2010 at 1:06 AM, Dagobert Michelsen wrote: > Hi, > > could someone who advocates shared NFS please suggest something on the > user of alternatives in such an environment? > ? > I'd like to, but I dont fully understand what "alternatives" is doing. you sort of half-explain it, in the ticket. Cold you please give a more concise definition of what exactly the alternatives stuff is doing with /etc directories? And why things are breaking, with shared /opt/csw? I will preemptively note that, while we previously have advocated "use /etc/opt/csw for local overrides and configs", it has always been an OPTIONAL override mechanism. If the stuff in /etc does not exist, the package should usually still continue to work in some default fashion. So at first blush, it would seem that our "alternatives" system needs some tweaking, to be more globally friendly, in the manner that our other stuff is already. From rupert at opencsw.org Wed Mar 17 18:03:54 2010 From: rupert at opencsw.org (rupert THURNER) Date: Wed, 17 Mar 2010 18:03:54 +0100 Subject: [csw-maintainers] checkpkg updates In-Reply-To: References: <6af4271003140847x7814b1dav7e7d0db2ba92d48a@mail.gmail.com> Message-ID: <6af4271003171003m70cf615bg9c6ff01ca8dee1e6@mail.gmail.com> On Sun, Mar 14, 2010 at 23:36, Maciej (Matchek) Blizinski < maciej at opencsw.org> wrote: > On Sun, Mar 14, 2010 at 3:47 PM, rupert THURNER > wrote: > > great! i was just wondering why you opted for cheetah, and not mako: > > http://makotemplates.org/ > > It's the first time I hear about mako, I never did a comparison > between the two. I've only worked with Cheetah before. Are there > advantages that mako has over Cheetah? > > not really, except that cheetah's developer is now using mako :) see here: http://groups.google.com/group/mako-discuss/browse_thread/thread/d54af08d79d0cf15 rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at bolthole.com Wed Mar 17 18:41:05 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 17 Mar 2010 10:41:05 -0700 Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: <4B9FD93F.6000806@wbonnet.net> References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> <4B9FAD2B.10902@opencsw.org> <625385e31003160927u74363513h67f63b62a3f8d1ff@mail.gmail.com> <20100316163223.GB12186@vonmossner.de> <4B9FD93F.6000806@wbonnet.net> Message-ID: On Tue, Mar 16, 2010 at 12:17 PM, William Bonnet wrote: > > > IMHO dropping only solaris 8 won't change things that much. weelll... not "much".. but it at least lets us use the sun "SO12" compiler cleanly, which is a nice win in some cases. From james at opencsw.org Wed Mar 17 19:12:03 2010 From: james at opencsw.org (James Lee) Date: Wed, 17 Mar 2010 18:12:03 GMT Subject: [csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw In-Reply-To: References: <740D4C44-60A7-4734-9180-C4F3FBECAD3B@opencsw.org> Message-ID: <20100317.18120300.680051978@gyor.oxdrove.co.uk> On 17/03/10, 17:00:07, Philip Brown wrote regarding Re: [csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw: > > could someone who advocates shared NFS please suggest something on the > > user of alternatives in such an environment? > > ? > > > I'd like to, but I dont fully understand what "alternatives" is doing. > you sort of half-explain it, in the ticket. Would neon would be better served by an auxiliary flag (see ld(1)). Eg: Compiled neon (minimal) with: cc -G -o libneon.so.0.29.3 -Wl,-f,/opt/csw/lib/libneon-full.so ... each lib needs linking with its own flag. Compile libneon-full.so as normal. Package both to install both in /opt/csw/lib Make CSWneon the default depend choice. Users get CSWneon on install via depends but can add CSWneonfull manually. This has the effect that when anything looks for libneon.so it will get libneon-full.so if it exists otherwise just it gets libneon.so I don't see neon full as an alternative, if you've got it use it. Neon full is surely an extension, alternatives are when there is a choice between two files that are both installed. (Correct me if I've misunderstood neon full.) James From phil at bolthole.com Wed Mar 17 19:48:32 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 17 Mar 2010 11:48:32 -0700 Subject: [csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw In-Reply-To: <20100317.18120300.680051978@gyor.oxdrove.co.uk> References: <740D4C44-60A7-4734-9180-C4F3FBECAD3B@opencsw.org> <20100317.18120300.680051978@gyor.oxdrove.co.uk> Message-ID: On Wed, Mar 17, 2010 at 11:12 AM, James Lee wrote: > > > Would neon would be better served by an auxiliary flag (see ld(1)). >[...] > > > This has the effect that when anything looks for libneon.so it will > get libneon-full.so if it exists otherwise just it gets libneon.so > > James makes an interesting point, both for neon specifically, but for "alternatives" in general. There are multiple cases where we are proposing using the "alternatives" set of utils for packages: 1. Where there is truely different functionality available, and user has to choose either/or. Examples: tcpwrappers libs, and the "ncurses or slang back end" for mutt. 2. Where there is optionally "enhanced" functionality. In which case, we allow for "alternatives", mostly to save on download footprint, and dependancy footprint. [are there any other cases?] For categories that fit #2, if there is a clean "use libxxxx-full if installed" option, it seems like the auxiliary linking flag is probably the better way to go in most cases. As such, perhaps we should both update the neon package like that, and also update our "alternatives" documentation, to explicitly redirect the maintainer to this path when it is appropriate? From bonivart at opencsw.org Thu Mar 18 15:56:11 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 18 Mar 2010 15:56:11 +0100 Subject: [csw-maintainers] Perl package maintainers Message-ID: <625385e31003180756wcadeb09se6c514e6b32abd9c@mail.gmail.com> The Perl 5.10.1 project is almost complete and we are about to release around 100 packages at once. We filed bugs against many modules that needed to be rebuilt but not every maintainer answered so we had to rebuild some of your packages too so the stack would be complete. That means our names are on these packages instead of yours. What you need to do is to take a look at our project page and see if one of your packages is listed there, also check Mantis for all your reported bugs. If you want to keep "ownership" of those packages you need to check them out from GAR and rebuild them, then put them in experimental/perl to replace the ones we built. Please rush this since we can't keep waiting for this. http://wiki.opencsw.org/project-perl http://mirror.opencsw.org/experimental.html#perl -- /peter From pfelecan at opencsw.org Thu Mar 18 18:02:43 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 18 Mar 2010 18:02:43 +0100 Subject: [csw-maintainers] Perl package maintainers In-Reply-To: <625385e31003180756wcadeb09se6c514e6b32abd9c@mail.gmail.com> (Peter Bonivart's message of "Thu, 18 Mar 2010 15:56:11 +0100") References: <625385e31003180756wcadeb09se6c514e6b32abd9c@mail.gmail.com> Message-ID: Peter Bonivart writes: > The Perl 5.10.1 project is almost complete and we are about to release > around 100 packages at once. We filed bugs against many modules that > needed to be rebuilt but not every maintainer answered so we had to > rebuild some of your packages too so the stack would be complete. That > means our names are on these packages instead of yours. > > What you need to do is to take a look at our project page and see if > one of your packages is listed there, also check Mantis for all your > reported bugs. If you want to keep "ownership" of those packages you > need to check them out from GAR and rebuild them, then put them in > experimental/perl to replace the ones we built. > > Please rush this since we can't keep waiting for this. Well, I can understood your strategy but is not a little bit abusive? Especially that I cannot remember a prior discussion. Just wondering. -- Peter From bonivart at opencsw.org Thu Mar 18 18:59:04 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 18 Mar 2010 18:59:04 +0100 Subject: [csw-maintainers] Perl package maintainers In-Reply-To: References: <625385e31003180756wcadeb09se6c514e6b32abd9c@mail.gmail.com> Message-ID: <625385e31003181059x2c4b0875mc852745d54d081b4@mail.gmail.com> On Thu, Mar 18, 2010 at 6:02 PM, Peter FELECAN wrote: > Well, I can understood your strategy but is not a little bit abusive? > Especially that I cannot remember a prior discussion. Just wondering. What exactly is abusive? I would like you to be more specific before I answer. -- /peter From pfelecan at opencsw.org Thu Mar 18 19:31:46 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 18 Mar 2010 19:31:46 +0100 Subject: [csw-maintainers] Perl package maintainers In-Reply-To: <625385e31003181059x2c4b0875mc852745d54d081b4@mail.gmail.com> (Peter Bonivart's message of "Thu, 18 Mar 2010 18:59:04 +0100") References: <625385e31003180756wcadeb09se6c514e6b32abd9c@mail.gmail.com> <625385e31003181059x2c4b0875mc852745d54d081b4@mail.gmail.com> Message-ID: Peter Bonivart writes: > On Thu, Mar 18, 2010 at 6:02 PM, Peter FELECAN wrote: >> Well, I can understood your strategy but is not a little bit abusive? >> Especially that I cannot remember a prior discussion. Just wondering. > > What exactly is abusive? I would like you to be more specific before I answer. Maybe "abusive" is a little bit brutal. In fact the word is exactly that: "brutal"; brutal to take ownership of other maintainers packages (this is what you wrote), to convert them to gar (why?) and to say that now they can take them back, and that without me remembering any prior discussion. If I'm wrong I'll be corrected. -- Peter From hson at opencsw.org Thu Mar 18 19:06:50 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Thu, 18 Mar 2010 19:06:50 +0100 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs libpaper In-Reply-To: References: <4BA0DE78.9070403@opencsw.org> <4BA16126.9010903@opencsw.org> <4BA25BA4.40709@opencsw.org> Message-ID: <4BA26BBA.5070201@opencsw.org> On 2010-03-18 19:00, Philip Brown wrote: > On Thu, Mar 18, 2010 at 9:58 AM, Roger H?kansson wrote: >> >>> Hmm.. actually, seems like the whole thing is a debian-ism. it doesnt >>> have a proper 3rd-party home site?Ugh, i hate those kinds of things... >>> >>> perhaps you should bug them to "encourage" they migrate it to >>> sourceforge. >> ... >> They explicitly say that the debian site is the home for this package. >> Which isn't that strange since the original author seemed to be involved >> with debian for a long time. > > Did you actually request it though? > Not myself, no, but I did see something similar (don't remember where) and the idea wasn't a success... > What I am suggesting, is that since this has clearly become a "greater > than debian" project, Well, I think its the opposite, libpaper has been around since pre-96 (1.0.4 was released 1996) and somewhere along the way the original author switched his primary email to a debian.org and when he left the debian guys probably took over the development. > and in order to foster even more widespread adoption, > it would probably benefit both them and others, to put it up > on sourceforge (or somewhere similar. savanna.gnu.org or whatever, if > they prefer?) Well, I can guess their answer: Why should they move? All major distribs already use it and what's the difference if its hosted by sourceforge, wikidot, google or debian when it's something that is pretty stable (been around for at least 14 years) and has very little development (the only thing that has happened in the last three years is debian-specific translations). For the current developers, its just a lot of work for no gain. I know that if I were the developers I would just laugh at anyone masking such a request. > > Nothing is lost by asking, hmm? > Well, the biggest issue is whom I should ask. There isn't any mailing-list and the current maintainer seems to have vanished (which is why nmu1 and nmu2 were created, it was the debian i18n team that created those releases) From bonivart at opencsw.org Thu Mar 18 20:10:10 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 18 Mar 2010 20:10:10 +0100 Subject: [csw-maintainers] Perl package maintainers In-Reply-To: References: <625385e31003180756wcadeb09se6c514e6b32abd9c@mail.gmail.com> <625385e31003181059x2c4b0875mc852745d54d081b4@mail.gmail.com> Message-ID: <625385e31003181210n7a7e4117rc69e9a79fdf69315@mail.gmail.com> On Thu, Mar 18, 2010 at 7:31 PM, Peter FELECAN wrote: > Maybe "abusive" is a little bit brutal. In fact the word is exactly > that: "brutal"; brutal to take ownership of other maintainers packages > (this is what you wrote), to convert them to gar (why?) and to say that > now they can take them back, and that without me remembering any prior > discussion. If I'm wrong I'll be corrected. They haven't answered bugs filed January 31st, how long do you think it is appropriate to wait before taking over a package? This is a big project, it's hard enough to finish as it is. It wasn't exactly our choice to do those packages since it involved more work for us. I'm sure most of the maintainers who didn't answer the bug reports are retired even though they may be listed as active. So, to sum up, we contacted everyone in an official way and we're offering everyone to keep ownership of their packages. Note that we have not "taken" ownership of anything since nothing has been released yet. It's to avoid "taking" ownership from maintainers who are active and want to keep their packages I'm trying to contact them this way too. -- /peter From phil at bolthole.com Thu Mar 18 20:15:09 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 18 Mar 2010 12:15:09 -0700 Subject: [csw-maintainers] Perl package maintainers In-Reply-To: <625385e31003181210n7a7e4117rc69e9a79fdf69315@mail.gmail.com> References: <625385e31003180756wcadeb09se6c514e6b32abd9c@mail.gmail.com> <625385e31003181059x2c4b0875mc852745d54d081b4@mail.gmail.com> <625385e31003181210n7a7e4117rc69e9a79fdf69315@mail.gmail.com> Message-ID: On Thu, Mar 18, 2010 at 12:10 PM, Peter Bonivart wrote: > On Thu, Mar 18, 2010 at 7:31 PM, Peter FELECAN wrote: >> Maybe "abusive" is a little bit brutal. In fact the word is exactly >> that: "brutal"; brutal to take ownership of other maintainers packages >> (this is what you wrote), to convert them to gar (why?) and to say that >> now they can take them back, and that without me remembering any prior >> discussion. If I'm wrong I'll be corrected. > > They haven't answered bugs filed January 31st, how long do you think > it is appropriate to wait before taking over a package? Them not having answered bugs on the bugtracking list, does not make it okay to skip attempting to contact them directly. > So, to sum up, we contacted everyone in an official way and we're > offering everyone to keep ownership of their packages. It does not sound like you have fully "contacted everyone". Peter F would seem to be proof of that. > Note that we > have not "taken" ownership of anything since nothing has been released > yet. It's to avoid "taking" ownership from maintainers who are active > and want to keep their packages I'm trying to contact them this way > too. When you wish to take over a package, emailing the general maintainers list, is not an acceptible as "attempting to contact the maintainer" either. It's fine as a first attempt, for a multi-package effort. But it does not count as, "well i attempted to contact them and didnt get a reply". From bonivart at opencsw.org Thu Mar 18 20:29:50 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 18 Mar 2010 20:29:50 +0100 Subject: [csw-maintainers] Perl package maintainers In-Reply-To: References: <625385e31003180756wcadeb09se6c514e6b32abd9c@mail.gmail.com> <625385e31003181059x2c4b0875mc852745d54d081b4@mail.gmail.com> <625385e31003181210n7a7e4117rc69e9a79fdf69315@mail.gmail.com> Message-ID: <625385e31003181229n25b76069u8ced47950300863c@mail.gmail.com> On Thu, Mar 18, 2010 at 8:15 PM, Philip Brown wrote: > Them not having answered bugs on the bugtracking list, does not make > it okay to skip attempting to contact them directly. What's considered directly then? I don't know maintainers e-mail addresses and I assume the contact form on their package pages goes to the same address as listed for Mantis? Or doesn't it? > It does not sound like you have fully "contacted everyone". Peter F > would seem to be proof of that. Peter is not owner of any of the packages in the Perl project. > When you wish to take over a package, emailing the general maintainers > list, is not an acceptible as "attempting to contact the maintainer" > either. > > It's fine as a first attempt, for a multi-package effort. But it does > not count as, "well i attempted to contact them and didnt get a > reply". Again, we didn't want to take over any packages, we filed bugs against them because we wanted help doing them. Not receiving that we did the work to be able to finish the project. -- /peter From bwalton at opencsw.org Thu Mar 18 20:31:27 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 18 Mar 2010 15:31:27 -0400 Subject: [csw-maintainers] Perl package maintainers In-Reply-To: References: <625385e31003180756wcadeb09se6c514e6b32abd9c@mail.gmail.com> <625385e31003181059x2c4b0875mc852745d54d081b4@mail.gmail.com> <625385e31003181210n7a7e4117rc69e9a79fdf69315@mail.gmail.com> Message-ID: <1268940026-sup-845@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Mar 18 15:15:09 -0400 2010: > > They haven't answered bugs filed January 31st, how long do you think > > it is appropriate to wait before taking over a package? > > Them not having answered bugs on the bugtracking list, does not make > it okay to skip attempting to contact them directly. Why not? If they're not responding to bug reports, why would you have better luck contacting them directly? Responding to bug reports is, in my opinion, a primary responsibility, so failing to do so is tantamount to being AWoL. Also, In many cases, I only know and @opencsw address for a maintainer, so mantis or direct is the same thing to me. Personally, I think the approach that's been taken is pretty decent, given the size of the project and the lack of response to bug reports. [Not meant to be snippy in any way if that's how it comes off, it's a legit question.] Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From ihsan at opencsw.org Thu Mar 18 20:52:09 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Thu, 18 Mar 2010 20:52:09 +0100 Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: <1268755526-sup-8828@pinkfloyd.chass.utoronto.ca> References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> <1268755526-sup-8828@pinkfloyd.chass.utoronto.ca> Message-ID: <4BA28469.1090206@opencsw.org> Am 16.03.10 17:07, schrieb Ben Walton: >> completely drop it. Thoughts? > > If Sun^H^H^HOracle doesn't support it why should we? I think it made > sense originally to support it for a final release, but we've a year+ > out from the EOL date with no stable release on the horizon. > > More and more things require extra effort to support on 8, so what's > the actual benefit? > > +1 for dropping it. +1 Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Thu Mar 18 20:55:26 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Thu, 18 Mar 2010 20:55:26 +0100 Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> <4B9FAD2B.10902@opencsw.org> <625385e31003160927u74363513h67f63b62a3f8d1ff@mail.gmail.com> <20100316163223.GB12186@vonmossner.de> Message-ID: <4BA2852E.8070304@opencsw.org> Am 16.03.10 18:17, schrieb Peter FELECAN: >>>> My take on it is: lets freeze the Solaris 8 trail, but keep it as a legacy >>>> trail for those still running Solaris 8. Bug fixes to that trail is only >>>> done if the maintainer chooses so. >>> +1 >> >> another +1 > > I'm even for dropping Solaris 9 (who gives a Greek drachma on so old > versions?) but all that voting was never taken into account; better to > howl into the wind. I thought we support the current Solaris version -2. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From phil at bolthole.com Thu Mar 18 21:29:13 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 18 Mar 2010 13:29:13 -0700 Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: <4BA2852E.8070304@opencsw.org> References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> <4B9FAD2B.10902@opencsw.org> <625385e31003160927u74363513h67f63b62a3f8d1ff@mail.gmail.com> <20100316163223.GB12186@vonmossner.de> <4BA2852E.8070304@opencsw.org> Message-ID: On Thu, Mar 18, 2010 at 12:55 PM, Ihsan Dogan wrote: > > > I thought we support the current Solaris version -2. > It's more that we support "currently fully supported versions of Solaris". From phil at bolthole.com Thu Mar 18 21:34:51 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 18 Mar 2010 13:34:51 -0700 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs libpaper In-Reply-To: <4BA26BBA.5070201@opencsw.org> References: <4BA0DE78.9070403@opencsw.org> <4BA16126.9010903@opencsw.org> <4BA25BA4.40709@opencsw.org> <4BA26BBA.5070201@opencsw.org> Message-ID: On Thu, Mar 18, 2010 at 11:06 AM, Roger H?kansson wrote: > >> Nothing is lost by asking, hmm? >> > > Well, the biggest issue is whom I should ask. > There isn't any mailing-list and the current maintainer seems to have > vanished (which is why nmu1 and nmu2 were created, it was the debian i18n > team that created those releases) > that's a good question. I think the relevant issues are: 1. who or what entities "own" the code (or perhaps in this case, the "name", since it is GPL) 2. who "cares" the most. For #1, i would almost say its sort of a "community ownership" For #2, I would say, "the people who did nmu1 and nmu2" :-) And also possibly the freebsd ports maintainer of it, if you want extra help. >From a semi-legal standpoint, I would suggest that if "the current debian maintainer" says "hey its all right to move it to sourceforge", then things are clear to do so. And if the prior, "official" maintainer is non-responsive, then either of the prior nmu contributors, can submit through normal debian channels, to become the new official maintainer. (technically, ANY debian maintainer could. heck, I could. lol. It's mostly just a matter of who cares enough, and has enough time to do so) From phil at bolthole.com Thu Mar 18 21:38:07 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 18 Mar 2010 13:38:07 -0700 Subject: [csw-maintainers] Perl package maintainers In-Reply-To: <625385e31003181229n25b76069u8ced47950300863c@mail.gmail.com> References: <625385e31003180756wcadeb09se6c514e6b32abd9c@mail.gmail.com> <625385e31003181059x2c4b0875mc852745d54d081b4@mail.gmail.com> <625385e31003181210n7a7e4117rc69e9a79fdf69315@mail.gmail.com> <625385e31003181229n25b76069u8ced47950300863c@mail.gmail.com> Message-ID: On Thu, Mar 18, 2010 at 12:29 PM, Peter Bonivart wrote: > On Thu, Mar 18, 2010 at 8:15 PM, Philip Brown wrote: >> Them not having answered bugs on the bugtracking list, does not make >> it okay to skip attempting to contact them directly. > > What's considered directly then? I don't know maintainers e-mail > addresses and I assume the contact form on their package pages goes to > the same address as listed for Mantis? Or doesn't it? it might, it might not. there is nothing forcing them to be in sync. and there's always the possibility that the person may have "accidentally" created a mail filter that drops mantis bug reports :-} I would say that emailing their @opencsw.org email directly, is sufficient. >> It does not sound like you have fully "contacted everyone". Peter F >> would seem to be proof of that. > > Peter is not owner of any of the packages in the Perl project. > Again, we didn't want to take over any packages, we filed bugs against > them because we wanted help doing them. Not receiving that we did the > work to be able to finish the project. Thanks for making that clear. Might be useful for you to put together a more public, explicit list of package maintainer that you are having non-response problems with. From ihsan at opencsw.org Thu Mar 18 21:44:26 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Thu, 18 Mar 2010 21:44:26 +0100 Subject: [csw-maintainers] Perl package maintainers In-Reply-To: <625385e31003180756wcadeb09se6c514e6b32abd9c@mail.gmail.com> References: <625385e31003180756wcadeb09se6c514e6b32abd9c@mail.gmail.com> Message-ID: <4BA290AA.9040602@opencsw.org> Am 18.03.10 15:56, schrieb Peter Bonivart: > The Perl 5.10.1 project is almost complete and we are about to release > around 100 packages at once. We filed bugs against many modules that > needed to be rebuilt but not every maintainer answered so we had to > rebuild some of your packages too so the stack would be complete. That > means our names are on these packages instead of yours. I'm almost done with updating my packages - only rrdtool and Mail-DKIM left. There are still a few packaging issues with these packages. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From william at wbonnet.net Thu Mar 18 22:10:59 2010 From: william at wbonnet.net (William Bonnet) Date: Thu, 18 Mar 2010 22:10:59 +0100 Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> <4B9FAD2B.10902@opencsw.org> <625385e31003160927u74363513h67f63b62a3f8d1ff@mail.gmail.com> <20100316163223.GB12186@vonmossner.de> <4B9FD93F.6000806@wbonnet.net> Message-ID: <4BA296E3.80507@wbonnet.net> Hi Phil > weelll... not "much".. but it at least lets us use the sun "SO12" > compiler cleanly, which is a nice win in some cases. > sure, but 12u1 would be a real win, not only a nice win ;) I'm especially thinking about a very specific bug about templates... cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From bonivart at opencsw.org Thu Mar 18 23:14:34 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 18 Mar 2010 23:14:34 +0100 Subject: [csw-maintainers] Perl package maintainers In-Reply-To: References: <625385e31003180756wcadeb09se6c514e6b32abd9c@mail.gmail.com> <625385e31003181059x2c4b0875mc852745d54d081b4@mail.gmail.com> <625385e31003181210n7a7e4117rc69e9a79fdf69315@mail.gmail.com> <625385e31003181229n25b76069u8ced47950300863c@mail.gmail.com> Message-ID: <625385e31003181514o5482a8a5geea69e8d5a447bf5@mail.gmail.com> On Thu, Mar 18, 2010 at 9:38 PM, Philip Brown wrote: > Might be useful for you to put together a more public, explicit list of > > package ? ?maintainer > > > that you are having non-response problems with. I can only identify Yann, Ihsan and Rupert and we have addressed them directly before (without a problem). This was more a general call, like asking for testing previously, to see if we missed someone. I think that the large part of the affected packages were already owned by us in the project or by officially retired maintainers like Alex Moore and Cory Ormand. What would be interesting, generally speaking, is to search for Mantis bugs with no one assigned. Those maintainers we should try to contact directly and if they don't respond we should list them as retired and try to fix the bugs they have accumulated. We owe the users that. -- /peter From phil at bolthole.com Fri Mar 19 00:00:38 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 18 Mar 2010 16:00:38 -0700 Subject: [csw-maintainers] Perl package maintainers In-Reply-To: <625385e31003181514o5482a8a5geea69e8d5a447bf5@mail.gmail.com> References: <625385e31003180756wcadeb09se6c514e6b32abd9c@mail.gmail.com> <625385e31003181059x2c4b0875mc852745d54d081b4@mail.gmail.com> <625385e31003181210n7a7e4117rc69e9a79fdf69315@mail.gmail.com> <625385e31003181229n25b76069u8ced47950300863c@mail.gmail.com> <625385e31003181514o5482a8a5geea69e8d5a447bf5@mail.gmail.com> Message-ID: On Thu, Mar 18, 2010 at 3:14 PM, Peter Bonivart wrote: > > > What would be interesting, generally speaking, is to search for Mantis > bugs with no one assigned. Those maintainers we should try to contact > directly and if they don't respond we should list them as retired and > try to fix the bugs they have accumulated. We owe the users that. > an interesting idea. How about turning "we", into "you"? :-) I would be happy to nominate you as our official "laggy maintainer sweeper", if you'd like to step up to the office? :-D From hson at opencsw.org Thu Mar 18 23:07:03 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Thu, 18 Mar 2010 23:07:03 +0100 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs libpaper In-Reply-To: References: <4BA0DE78.9070403@opencsw.org> <4BA16126.9010903@opencsw.org> <4BA25BA4.40709@opencsw.org> <4BA26BBA.5070201@opencsw.org> Message-ID: <4BA2A407.9000307@opencsw.org> On 2010-03-18 21:34, Philip Brown wrote: > On Thu, Mar 18, 2010 at 11:06 AM, Roger H?kansson wrote: >> >>> Nothing is lost by asking, hmm? >>> >> >> Well, the biggest issue is whom I should ask. >> There isn't any mailing-list and the current maintainer seems to have >> vanished (which is why nmu1 and nmu2 were created, it was the debian i18n >> team that created those releases) >> > > that's a good question. > Well, whatever, I have more urgent stuff to do than to track down people and convince them to move their stuff to sourceforge. Specially since in my world isn't a problem to start with... From hson at opencsw.org Thu Mar 18 23:13:43 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Thu, 18 Mar 2010 23:13:43 +0100 Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: <4BA2852E.8070304@opencsw.org> References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> <4B9FAD2B.10902@opencsw.org> <625385e31003160927u74363513h67f63b62a3f8d1ff@mail.gmail.com> <20100316163223.GB12186@vonmossner.de> <4BA2852E.8070304@opencsw.org> Message-ID: <4BA2A597.2090805@opencsw.org> On 2010-03-18 20:55, Ihsan Dogan wrote: > > I thought we support the current Solaris version -2. > If Sun had followed their old release scheme with a release every year or not more than two apart, that generic statement would have been fine. But now Solaris 10 have been out for 5 years without 11 even having a public release date yet. Speculation says around summer this year, but given that it has been "on the way" for tree years now I wouldn't take that seriously until I start seeing some traces in Sunsolve just like ahead of prior releases. The big "mistake" (depends on how you look at it) Sun did was to release u6 instead of calling it Solaris 11 (but thats because of their new release schedule which states that a release should be in GA at least for 4 years and 6 months). So now you have a ton of proprietary software officially supporting Solaris 10, but when you check, you really need Solaris 10 u6 or higher and to get there you can't just patch your way up, you need to do an upgrade. For us, it means that we have to support a OS that is 10 years old, which doesn't have C99 support and so on. My view is that we should follow the official support schedule and support a OS release until end of "Phase 1 retirement" (which means full support, but no sales) which is two years after last ship date. When a relase ends up in "Phase 2" you can no longer get any patches only support to solve problems. Right now Solaris 8 have been in Phase 2 since beginning of April last year and Solaris 9 Phase 1 ends October 2011. By that time every company will have upgraded almost every system and the only ones lagging behind are systems that run some funky SW or have old HW-drivers. Such systems rarely change and don't think any of them are running pkgutil/pkg-get to update their SW. When it comes to people running Solaris at home, if they haven't moved from Solaris 9 by that time, its because of old HW and they can't be many that still are running SS4/5/20 when there have been plenty of U5/U10 in dumpsters for years now... What we should do is set a date when we drop Solaris 8 (and another for Solaris 9, no reason for not doing so right now) which shouldn't be too far into the future (I would say before the summer). And regarding "first getting a stable out", I can't see why the two issues should have anything to do with each other. Getting a stable out is a high priority, but that's for people running current OS releases wishing to have a little less moving target when it comes to updates and inter-package problems. The eventual drop of support for Solaris 8 will mean that the current stable is the last stable for Solaris 8 and thats it. If they wish to keep running such old OS, they will have to cope with the fact that the SW also will be old. I fear that if we are to wait for a stable then we might still be having this conversation in a year... From phil at bolthole.com Fri Mar 19 01:00:13 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 18 Mar 2010 17:00:13 -0700 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs libpaper In-Reply-To: <4BA2A407.9000307@opencsw.org> References: <4BA0DE78.9070403@opencsw.org> <4BA16126.9010903@opencsw.org> <4BA25BA4.40709@opencsw.org> <4BA26BBA.5070201@opencsw.org> <4BA2A407.9000307@opencsw.org> Message-ID: On Thu, Mar 18, 2010 at 3:07 PM, Roger H?kansson wrote: > > Well, whatever, I have more urgent stuff to do than to track down people and > convince them to move their stuff to sourceforge. Specially since in my > world isn't a problem to start with... > fair enough... however, the nmu2 version, is still potentially at issue here. the changelog describes it as [some debian-specific junk, and] Fix pending l10n issues. Debconf translations: - Slovak (Ivan Mas?r). Closes: #534463 Having the improved set of translations, sounds like a non-debian-specific improvement. So how about bumping to the nmu2 version? From hson at opencsw.org Fri Mar 19 00:03:06 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 19 Mar 2010 00:03:06 +0100 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs libpaper In-Reply-To: References: <4BA0DE78.9070403@opencsw.org> <4BA16126.9010903@opencsw.org> <4BA25BA4.40709@opencsw.org> <4BA26BBA.5070201@opencsw.org> <4BA2A407.9000307@opencsw.org> Message-ID: <4BA2B12A.8050506@opencsw.org> On 2010-03-19 01:00, Philip Brown wrote: > On Thu, Mar 18, 2010 at 3:07 PM, Roger H?kansson wrote: > >> >> Well, whatever, I have more urgent stuff to do than to track down people and >> convince them to move their stuff to sourceforge. Specially since in my >> world isn't a problem to start with... >> > > fair enough... however, the nmu2 version, is still potentially at issue here. > the changelog describes it as > [some debian-specific junk, and] > Fix pending l10n issues. Debconf translations: > - Slovak (Ivan Mas?r). Closes: #534463 > > Having the improved set of translations, sounds like a > non-debian-specific improvement. > So how about bumping to the nmu2 version? The translations are for debconf, which is debian specific. From phil at bolthole.com Fri Mar 19 01:09:46 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 18 Mar 2010 17:09:46 -0700 Subject: [csw-maintainers] [csw-pkgsubmissions] newpkgs libpaper In-Reply-To: <4BA2B12A.8050506@opencsw.org> References: <4BA0DE78.9070403@opencsw.org> <4BA16126.9010903@opencsw.org> <4BA25BA4.40709@opencsw.org> <4BA26BBA.5070201@opencsw.org> <4BA2A407.9000307@opencsw.org> <4BA2B12A.8050506@opencsw.org> Message-ID: On Thu, Mar 18, 2010 at 4:03 PM, Roger H?kansson wrote: > On 2010-03-19 01:00, Philip Brown wrote: >> Having the improved set of translations, sounds like a >> non-debian-specific improvement. >> So how about bumping to the nmu2 version? > > The translations are for debconf, which is debian specific. ah okay then. batching. From bonivart at opencsw.org Fri Mar 19 09:51:07 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 19 Mar 2010 09:51:07 +0100 Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: <4BA2A597.2090805@opencsw.org> References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> <4B9FAD2B.10902@opencsw.org> <625385e31003160927u74363513h67f63b62a3f8d1ff@mail.gmail.com> <20100316163223.GB12186@vonmossner.de> <4BA2852E.8070304@opencsw.org> <4BA2A597.2090805@opencsw.org> Message-ID: <625385e31003190151qe6dbc14jc777905b0d17d040@mail.gmail.com> On Thu, Mar 18, 2010 at 11:13 PM, Roger H?kansson wrote: > I fear that if we are to wait for a stable then we might still be having > this conversation in a year... +1 -- /peter From bonivart at opencsw.org Fri Mar 19 09:54:06 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 19 Mar 2010 09:54:06 +0100 Subject: [csw-maintainers] Perl package maintainers In-Reply-To: References: <625385e31003180756wcadeb09se6c514e6b32abd9c@mail.gmail.com> <625385e31003181059x2c4b0875mc852745d54d081b4@mail.gmail.com> <625385e31003181210n7a7e4117rc69e9a79fdf69315@mail.gmail.com> <625385e31003181229n25b76069u8ced47950300863c@mail.gmail.com> <625385e31003181514o5482a8a5geea69e8d5a447bf5@mail.gmail.com> Message-ID: <625385e31003190154s7735d0e6k5aacbb1f2444ea98@mail.gmail.com> On Fri, Mar 19, 2010 at 12:00 AM, Philip Brown wrote: > an interesting idea. > How about turning "we", into "you"? :-) > I would be happy to nominate you as our official "laggy maintainer > sweeper", if you'd like to step up to the office? :-D The key to that is to pull data from Mantis and I can't do that. I'll see if I can get Sebastian to do that step for me and we go from there. -- /peter From dam at opencsw.org Fri Mar 19 10:04:45 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 19 Mar 2010 10:04:45 +0100 Subject: [csw-maintainers] Perl package maintainers In-Reply-To: <625385e31003190154s7735d0e6k5aacbb1f2444ea98@mail.gmail.com> References: <625385e31003180756wcadeb09se6c514e6b32abd9c@mail.gmail.com> <625385e31003181059x2c4b0875mc852745d54d081b4@mail.gmail.com> <625385e31003181210n7a7e4117rc69e9a79fdf69315@mail.gmail.com> <625385e31003181229n25b76069u8ced47950300863c@mail.gmail.com> <625385e31003181514o5482a8a5geea69e8d5a447bf5@mail.gmail.com> <625385e31003190154s7735d0e6k5aacbb1f2444ea98@mail.gmail.com> Message-ID: Hi, Am 19.03.2010 um 09:54 schrieb Peter Bonivart: > On Fri, Mar 19, 2010 at 12:00 AM, Philip Brown > wrote: >> an interesting idea. >> How about turning "we", into "you"? :-) >> I would be happy to nominate you as our official "laggy maintainer >> sweeper", if you'd like to step up to the office? :-D > > The key to that is to pull data from Mantis and I can't do that. I'll > see if I can get Sebastian to do that step for me and we go from > there. Just as a reminder: There is already an easy-to-grasp list of bugs per maintainer including status: Best regards -- Dago From pfelecan at opencsw.org Fri Mar 19 10:09:33 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 19 Mar 2010 10:09:33 +0100 Subject: [csw-maintainers] Perl package maintainers In-Reply-To: <625385e31003181229n25b76069u8ced47950300863c@mail.gmail.com> (Peter Bonivart's message of "Thu, 18 Mar 2010 20:29:50 +0100") References: <625385e31003180756wcadeb09se6c514e6b32abd9c@mail.gmail.com> <625385e31003181059x2c4b0875mc852745d54d081b4@mail.gmail.com> <625385e31003181210n7a7e4117rc69e9a79fdf69315@mail.gmail.com> <625385e31003181229n25b76069u8ced47950300863c@mail.gmail.com> Message-ID: Peter Bonivart writes: >> It does not sound like you have fully "contacted everyone". Peter F >> would seem to be proof of that. > > Peter is not owner of any of the packages in the Perl project. That's very true. My remark was a principle oriented one. -- Peter From bonivart at opencsw.org Fri Mar 19 10:19:15 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 19 Mar 2010 10:19:15 +0100 Subject: [csw-maintainers] Perl package maintainers In-Reply-To: References: <625385e31003180756wcadeb09se6c514e6b32abd9c@mail.gmail.com> <625385e31003181210n7a7e4117rc69e9a79fdf69315@mail.gmail.com> <625385e31003181229n25b76069u8ced47950300863c@mail.gmail.com> <625385e31003181514o5482a8a5geea69e8d5a447bf5@mail.gmail.com> <625385e31003190154s7735d0e6k5aacbb1f2444ea98@mail.gmail.com> Message-ID: <625385e31003190219o7970aac9p6b6f1e8aef4b7334@mail.gmail.com> On Fri, Mar 19, 2010 at 10:04 AM, Dagobert Michelsen wrote: > Just as a reminder: There is already an easy-to-grasp list > of bugs per maintainer including status: > ? I guess I could look there for relatively old bugs in "new" state where the maintainer is listed as active, I think we have a rather large hidden problem there. -- /peter From dam at opencsw.org Fri Mar 19 10:26:35 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 19 Mar 2010 10:26:35 +0100 Subject: [csw-maintainers] Perl package maintainers In-Reply-To: <625385e31003190219o7970aac9p6b6f1e8aef4b7334@mail.gmail.com> References: <625385e31003180756wcadeb09se6c514e6b32abd9c@mail.gmail.com> <625385e31003181210n7a7e4117rc69e9a79fdf69315@mail.gmail.com> <625385e31003181229n25b76069u8ced47950300863c@mail.gmail.com> <625385e31003181514o5482a8a5geea69e8d5a447bf5@mail.gmail.com> <625385e31003190154s7735d0e6k5aacbb1f2444ea98@mail.gmail.com> <625385e31003190219o7970aac9p6b6f1e8aef4b7334@mail.gmail.com> Message-ID: <9553546B-9E04-42A5-87BB-9464B6C0BBAA@opencsw.org> Hi Peter, Am 19.03.2010 um 10:19 schrieb Peter Bonivart: > On Fri, Mar 19, 2010 at 10:04 AM, Dagobert Michelsen > wrote: >> Just as a reminder: There is already an easy-to-grasp list >> of bugs per maintainer including status: >> > > I guess I could look there for relatively old bugs in "new" state > where the maintainer is listed as active, I think we have a rather > large hidden problem there. Probably yes. Most of these bombs are really broken and complex builds like ximian_connector and multisync. If you think another sorting would be more helpful just let me know. Best regards -- Dago From bonivart at opencsw.org Fri Mar 19 10:53:09 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 19 Mar 2010 10:53:09 +0100 Subject: [csw-maintainers] Maintainers suspected not to be active though listed as such Message-ID: <625385e31003190253v5301b9eau9ee9ac96e82c38b5@mail.gmail.com> I quickly looked at http://www.opencsw.org/buglist/buglist.cgi with a relatively loose criteria of: 1. The maintainer should be listed as active 2. There should be bugs several months old still in the state of "new" (no response at all) 3. There should be no other more recent sign of work on other bugs 4. Some people fit the above listed criteria but I still know they are active (list postings and such) Here's the list I came up with: http://www.opencsw.org/buglist/maintainer.cgi?maintainer=ja http://www.opencsw.org/buglist/maintainer.cgi?maintainer=mike http://www.opencsw.org/buglist/maintainer.cgi?maintainer=mburki http://www.opencsw.org/buglist/maintainer.cgi?maintainer=sdean http://www.opencsw.org/buglist/maintainer.cgi?maintainer=debertin http://www.opencsw.org/buglist/maintainer.cgi?maintainer=drio http://www.opencsw.org/buglist/maintainer.cgi?maintainer=michael http://www.opencsw.org/buglist/maintainer.cgi?maintainer=harpchad http://www.opencsw.org/buglist/maintainer.cgi?maintainer=mph http://www.opencsw.org/buglist/maintainer.cgi?maintainer=opk http://www.opencsw.org/buglist/maintainer.cgi?maintainer=korpela http://www.opencsw.org/buglist/maintainer.cgi?maintainer=dlaigle http://www.opencsw.org/buglist/maintainer.cgi?maintainer=aubrey http://www.opencsw.org/buglist/maintainer.cgi?maintainer=rmartin http://www.opencsw.org/buglist/maintainer.cgi?maintainer=mmayer http://www.opencsw.org/buglist/maintainer.cgi?maintainer=mueller http://www.opencsw.org/buglist/maintainer.cgi?maintainer=darin http://www.opencsw.org/buglist/maintainer.cgi?maintainer=wpool http://www.opencsw.org/buglist/maintainer.cgi?maintainer=angelo http://www.opencsw.org/buglist/maintainer.cgi?maintainer=car http://www.opencsw.org/buglist/maintainer.cgi?maintainer=joerg http://www.opencsw.org/buglist/maintainer.cgi?maintainer=ryan http://www.opencsw.org/buglist/maintainer.cgi?maintainer=fred I think many of the above maintainers should really be listed as retired. I can try to contact them directly and would like some help with that. 1. Is it correct that I can construct e-mail addresses from the above maintainer name, e.g. ja at opencsw.org? 2. Any suggestions on the e-mail content? "We think you may be retired, reply if not"... 3. How long to wait for a reply before changing their status? I see it as a benefit to list them properly as retired if they in deed are so. I know it may look bad with many retired maintainers but what really is bad is that many packages are orphaned and we don't handle it. Changing their status is the first step to fix bugs and upgrade packages. -- /peter From bonivart at opencsw.org Fri Mar 19 10:57:40 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 19 Mar 2010 10:57:40 +0100 Subject: [csw-maintainers] Perl package maintainers In-Reply-To: <9553546B-9E04-42A5-87BB-9464B6C0BBAA@opencsw.org> References: <625385e31003180756wcadeb09se6c514e6b32abd9c@mail.gmail.com> <625385e31003181229n25b76069u8ced47950300863c@mail.gmail.com> <625385e31003181514o5482a8a5geea69e8d5a447bf5@mail.gmail.com> <625385e31003190154s7735d0e6k5aacbb1f2444ea98@mail.gmail.com> <625385e31003190219o7970aac9p6b6f1e8aef4b7334@mail.gmail.com> <9553546B-9E04-42A5-87BB-9464B6C0BBAA@opencsw.org> Message-ID: <625385e31003190257l633b56e6xd53f96ae2664a383@mail.gmail.com> On Fri, Mar 19, 2010 at 10:26 AM, Dagobert Michelsen wrote: >>> Just as a reminder: There is already an easy-to-grasp list >>> of bugs per maintainer including status: >>> ? >> >> I guess I could look there for relatively old bugs in "new" state >> where the maintainer is listed as active, I think we have a rather >> large hidden problem there. > > Probably yes. Most of these bombs are really broken and complex builds > like ximian_connector and multisync. > > If you think another sorting would be more helpful just let me know. Thank you Dago, I have started another thread about this. -- /peter From pfelecan at opencsw.org Fri Mar 19 11:22:05 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 19 Mar 2010 11:22:05 +0100 Subject: [csw-maintainers] Maintainers suspected not to be active though listed as such In-Reply-To: <625385e31003190253v5301b9eau9ee9ac96e82c38b5@mail.gmail.com> (Peter Bonivart's message of "Fri, 19 Mar 2010 10:53:09 +0100") References: <625385e31003190253v5301b9eau9ee9ac96e82c38b5@mail.gmail.com> Message-ID: Peter Bonivart writes: > 3. How long to wait for a reply before changing their status? 45 days > I see it as a benefit to list them properly as retired if they in deed > are so. I know it may look bad with many retired maintainers but what > really is bad is that many packages are orphaned and we don't handle > it. Changing their status is the first step to fix bugs and upgrade > packages. It's a very useful action. One of the reason of my previous reaction was just that: to use a "formal" retirement principle. Thank you to act upon it. -- Peter From dam at opencsw.org Fri Mar 19 11:49:35 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 19 Mar 2010 11:49:35 +0100 Subject: [csw-maintainers] Maintainers suspected not to be active though listed as such In-Reply-To: <625385e31003190253v5301b9eau9ee9ac96e82c38b5@mail.gmail.com> References: <625385e31003190253v5301b9eau9ee9ac96e82c38b5@mail.gmail.com> Message-ID: Hi Peter, first thanks for going through all this :-) Am 19.03.2010 um 10:53 schrieb Peter Bonivart: > I quickly looked at http://www.opencsw.org/buglist/buglist.cgi with a > relatively loose criteria of: > > 1. The maintainer should be listed as active > 2. There should be bugs several months old still in the state of "new" > (no response at all) > 3. There should be no other more recent sign of work on other bugs > 4. Some people fit the above listed criteria but I still know they are > active (list postings and such) > > Here's the list I came up with: > > 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) > I think many of the above maintainers should really be listed as > retired. I can try to contact them directly and would like some help > with that. > > 1. Is it correct that I can construct e-mail addresses from the above > maintainer name, e.g. ja at opencsw.org? Yes. > 2. Any suggestions on the e-mail content? "We think you may be > retired, reply if not"... Maybe a bit more friendly. I usually write > Hi , > > I noticed that you have been inactive since the fork. As there > have been some bugs reported for your packages it would be nice > if you could take a look: > > > If you don't have time to do so or don't want to join back in for > other reasons please let me know also. > 3. How long to wait for a reply before changing their status? I would say 1-2 weeks. > I see it as a benefit to list them properly as retired if they in deed > are so. I know it may look bad with many retired maintainers but what > really is bad is that many packages are orphaned and we don't handle > it. Changing their status is the first step to fix bugs and upgrade > packages. Thanks for your effort! -- Dago From phil at bolthole.com Fri Mar 19 18:16:48 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 19 Mar 2010 10:16:48 -0700 Subject: [csw-maintainers] Maintainers suspected not to be active though listed as such In-Reply-To: <625385e31003190253v5301b9eau9ee9ac96e82c38b5@mail.gmail.com> References: <625385e31003190253v5301b9eau9ee9ac96e82c38b5@mail.gmail.com> Message-ID: On Fri, Mar 19, 2010 at 2:53 AM, Peter Bonivart wrote: > > > 1. Is it correct that I can construct e-mail addresses from the above > maintainer name, e.g. ja at opencsw.org? Yup. While the choice of mantis contact email is up to the individual, the one "MUST MATCH"' rule about mantis, is that the maintainer's mantis username, must be the same as their opencsw "username". > 3. How long to wait for a reply before changing their status? I think that 2 weeks is too short. 30-45 days seems appropriate to me. 3 weeks at the shortest. From phil at bolthole.com Fri Mar 19 19:20:52 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 19 Mar 2010 11:20:52 -0700 Subject: [csw-maintainers] bad news on the CSW X11 front Message-ID: Soooo.. James uncovered some bad news on the CSW X11 front. Graphically speaking, we have been integrating with sun's OpenGL library, libGL.so, for hardware-accelerated graphics. Trouble is... Sun's libGL.so, requires "libX11.so.4". even in solaris 10. Whereas our newer libX11, is libX11.so.6. That means, stuff that we compile against the nice new shiney X11, cannot use (sun provided) hardware 3d accel . The good news is, there are precious few packages that truely *need* 3d accel. The bad news is, its still going to be "less shiney" in some areas. ones that would directly benefit from hardware 3d in common usage (I may have missed some but these are bad enough): xscreensaver xlockmore flightgear bzflag quake2 neverball (radiance?) criticalmass armagetron tuxkart rsxs stellarium kicad gl117 #The following are "only" 3d libraries/toolkits fox plib freeglut kdegraphics_gcc wxwidgets_gtk2 More "good" news, is that many of them dont need the new CSW X11, so there is no direct conflict. But those ones that use gtk, either directly, or INDIRECTLY, potentially have a problem. xscreensaver mplayer From maciej at opencsw.org Fri Mar 19 19:39:58 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 19 Mar 2010 18:39:58 +0000 Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: References: Message-ID: 2010/3/19 Philip Brown : > That means, stuff that we compile against the nice new shiney X11, > cannot use (sun provided) hardware 3d accel . > > The good news is, there are precious few packages that truely *need* 3d accel. > > The bad news is, its still going to be "less shiney" in some areas. > > ones that would directly benefit from hardware 3d in common usage (I > may have missed some but these are bad enough): > > wxwidgets_gtk2 I think that this one needs CSW X11, because it links against gtk, which links against CSW X11. Is there a need for wxwidgets to have 3d acceleration? From phil at bolthole.com Fri Mar 19 21:12:51 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 19 Mar 2010 13:12:51 -0700 Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: References: Message-ID: On Fri, Mar 19, 2010 at 11:39 AM, Maciej (Matchek) Blizinski wrote: > 2010/3/19 Philip Brown : >> That means, stuff that we compile against the nice new shiney X11, >> cannot use (sun provided) hardware 3d accel . >> >> The good news is, there are precious few packages that truely *need* 3d accel. >> >> The bad news is, its still going to be "less shiney" in some areas. >> >> ones that would directly benefit from hardware 3d in common usage (I >> may have missed some but these are bad enough): >> >> wxwidgets_gtk2 > > I think that this one needs CSW X11, because it links against gtk, > which links against CSW X11. ?Is there a need for wxwidgets to have 3d > acceleration? > well, "need" is relative. apparently it offers some 3d api, that some programs may take advantage of? kicad uses wxwidgets. and wxwidgets DOES have a "direct" dependancy on mesalibs. From dam at opencsw.org Sat Mar 20 08:26:06 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 20 Mar 2010 08:26:06 +0100 Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: References: Message-ID: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> Hi Phil, Am 19.03.2010 um 19:20 schrieb Philip Brown: > Soooo.. James uncovered some bad news on the CSW X11 front. > > Graphically speaking, we have been integrating with sun's OpenGL > library, libGL.so, for hardware-accelerated graphics. > > Trouble is... Sun's libGL.so, requires "libX11.so.4". even in > solaris 10. > > Whereas our newer libX11, is libX11.so.6. > > That means, stuff that we compile against the nice new shiney X11, > cannot use (sun provided) hardware 3d accel . > > The good news is, there are precious few packages that truely *need* > 3d accel. > > The bad news is, its still going to be "less shiney" in some areas. > > ones that would directly benefit from hardware 3d in common usage (I > may have missed some but these are bad enough): > > xscreensaver > xlockmore > flightgear > bzflag > quake2 > neverball > (radiance?) > criticalmass > armagetron > tuxkart > rsxs > stellarium > kicad > gl117 > #The following are "only" 3d libraries/toolkits > fox > plib > freeglut > kdegraphics_gcc > wxwidgets_gtk2 > > More "good" news, is that many of them dont need the new CSW X11, so > there is no direct conflict. But those ones that use gtk, either > directly, or INDIRECTLY, potentially have a problem. Ugh. Does that mean we need double libraries: one in lib/ bound against Sun X11 and one in X11/lib bound against CSW X11 and the apps go to decide? Best regards -- Dago From dam at opencsw.org Sat Mar 20 14:28:06 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 20 Mar 2010 14:28:06 +0100 Subject: [csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw In-Reply-To: <20100317.18120300.680051978@gyor.oxdrove.co.uk> References: <740D4C44-60A7-4734-9180-C4F3FBECAD3B@opencsw.org> <20100317.18120300.680051978@gyor.oxdrove.co.uk> Message-ID: <0EF99799-85D0-4B1C-9A8A-6523AE1D73CC@opencsw.org> Hi James, Am 17.03.2010 um 19:12 schrieb James Lee: > On 17/03/10, 17:00:07, Philip Brown wrote regarding Re: > [csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw: > >>> could someone who advocates shared NFS please suggest something on >>> the >>> user of alternatives in such an environment? >>> >>> > >> I'd like to, but I dont fully understand what "alternatives" is >> doing. >> you sort of half-explain it, in the ticket. > > Would neon would be better served by an auxiliary flag (see ld(1)). > Eg: > > Compiled neon (minimal) with: > cc -G -o libneon.so.0.29.3 -Wl,-f,/opt/csw/lib/libneon-full.so ... > each lib needs linking with its own flag. > Compile libneon-full.so as normal. > Package both to install both in /opt/csw/lib > Make CSWneon the default depend choice. > Users get CSWneon on install via depends but can add CSWneonfull > manually. I just read through and it sounds indeed pretty much of what is needed here. In the case of curl and neon it should work pretty well as there is only one library produced. In the general case this may be tedious as it requires specific options per library. > This has the effect that when anything looks for libneon.so it will > get libneon-full.so if it exists otherwise just it gets libneon.so > > I don't see neon full as an alternative, if you've got it use it. > Neon full is surely an extension, alternatives are when there is a > choice between two files that are both installed. (Correct me if > I've misunderstood neon full.) The only mechanism used here from alternatives is the automatic precedence of higher prioritized files, in this case the more-featurefull library. I'll see how I can get this integrated. Best regards -- Dago From dam at opencsw.org Sat Mar 20 22:09:25 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 20 Mar 2010 22:09:25 +0100 Subject: [csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw In-Reply-To: References: <740D4C44-60A7-4734-9180-C4F3FBECAD3B@opencsw.org> <20100317.18120300.680051978@gyor.oxdrove.co.uk> Message-ID: Hi, Am 17.03.2010 um 19:48 schrieb Philip Brown: > On Wed, Mar 17, 2010 at 11:12 AM, James Lee wrote: >> >> Would neon would be better served by an auxiliary flag (see ld(1)). >> [...] >> >> This has the effect that when anything looks for libneon.so it will >> get libneon-full.so if it exists otherwise just it gets libneon.so I have made some tests and it looks like just the right solution for the feature-library problem. > There are multiple cases where we are proposing using the > "alternatives" set of utils for packages: > > 1. Where there is truely different functionality available, and user > has to choose either/or. > Examples: tcpwrappers libs, and the "ncurses or slang back end" for > mutt. > > 2. Where there is optionally "enhanced" functionality. In which case, > we allow for "alternatives", mostly to save on download footprint, and > dependancy footprint. > > [are there any other cases?] > > For categories that fit #2, if there is a clean "use libxxxx-full if > installed" option, it seems like the auxiliary linking flag is > probably the better way to go in most cases. Some 32 bit/64 bit apps may fall in the same category if they operate on the same data and when 64 bit is considered better, then isaexec is the tool of choice. But this just as a sidenote... > As such, perhaps we should both update the neon package like that, and > also update our "alternatives" documentation, to explicitly redirect > the maintainer to this path when it is appropriate? I'll do some GAR integration to make this as straight-forward as alternatives. However, all this doesn't bring us close to NFS-sharing when alternatives are used. Suggestions, gentlemen? Best regards -- Dago From bwalton at opencsw.org Sun Mar 21 16:03:58 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 21 Mar 2010 11:03:58 -0400 Subject: [csw-maintainers] help testing libxml2 update Message-ID: <1269183803-sup-1215@pinkfloyd.chass.utoronto.ca> Hi All, I've placed updated libxml2, libxml2_devel and py_libxml2 package in the experimental/bwalton catalog. Any help testing these is appreciated. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From car at opencsw.org Sun Mar 21 20:03:52 2010 From: car at opencsw.org (Chris Reece) Date: Mon, 22 Mar 2010 08:03:52 +1300 Subject: [csw-maintainers] Maintainers suspected not to be active though listed as such In-Reply-To: <625385e31003190253v5301b9eau9ee9ac96e82c38b5@mail.gmail.com> References: <625385e31003190253v5301b9eau9ee9ac96e82c38b5@mail.gmail.com> Message-ID: On 19/03/2010, at 10:53 PM, Peter Bonivart wrote: > http://www.opencsw.org/buglist/maintainer.cgi?maintainer=car > I think many of the above maintainers should really be listed as > retired. I can try to contact them directly and would like some help > with that. I think that's a fair assessment. No matter how many times I tell myself I'll get round to this, the truth is that in my present position, I haven't touched a Solaris box in ten months, and that's a situation I dearly hope will continue. Sorry for letting it drag on, please feel free to mark me as retired. Good luck in your continuing efforts. Chris. From ihsan at opencsw.org Sun Mar 21 22:15:36 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 21 Mar 2010 22:15:36 +0100 Subject: [csw-maintainers] rrdtool for Perl 5.10 Message-ID: <4BA68C78.4060208@opencsw.org> Hello, rrdtool 1.4.2 for Perl 5.10 is finally done and it's available from http://mirror.opencsw.org/experimental.html#perl . rrdtool-1.4.2,REV=2010.03.21-SunOS5.8-i386-CSW.pkg.gz rrdtool-1.4.2,REV=2010.03.21-SunOS5.8-sparc-CSW.pkg.gz This package passed my tests and should work fine. Benny, thank you very much for helping me on that. I appreciated it very much. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Sun Mar 21 22:24:10 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 21 Mar 2010 22:24:10 +0100 Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> Message-ID: <4BA68E7A.9000605@opencsw.org> Am 16.03.10 16:50, schrieb Dagobert Michelsen: > I am currently working on an updated glib and have the > behavious that on Solaris 8 i386 a couple of tests fail, > most certainly due to threading issues. As glib is quite > fundamental and the issues are related to the operating > system and we have already voted to support Solaris 8 > on a best effort basis it may really be time now to > completely drop it. Thoughts? Ok, so what is our decision now? To drop Solaris 8 support? Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From bwalton at opencsw.org Sun Mar 21 22:34:41 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 21 Mar 2010 17:34:41 -0400 Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: <4BA68E7A.9000605@opencsw.org> References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> <4BA68E7A.9000605@opencsw.org> Message-ID: <1269207173-sup-988@pinkfloyd.chass.utoronto.ca> Excerpts from Ihsan Dogan's message of Sun Mar 21 17:24:10 -0400 2010: > Ok, so what is our decision now? To drop Solaris 8 support? I haven't seen any -1's for that and again, I say YES! I also think Roger's suggestion of announcing a cut-off date for 9 _now_ is great. (Personally, I'd be ok with dropping 9 now too, but that's based solely on not having it deployed here at all.) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From hson at opencsw.org Mon Mar 22 14:58:57 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Mon, 22 Mar 2010 14:58:57 +0100 Subject: [csw-maintainers] [csw-pkgsubmissions] Preparing for release of perl 5.10.1 with another 80-90 packages In-Reply-To: <625385e31003150631w3315d094rf3f724ba1730283b@mail.gmail.com> References: <625385e31003150631w3315d094rf3f724ba1730283b@mail.gmail.com> Message-ID: <4BA777A1.3090606@opencsw.org> On 2010-03-15 14:31, Peter Bonivart wrote: > The Perl project is coming to an end, is there anything special > regarding the release when there are so many packages that need to be > released together? > > http://wiki.opencsw.org/project-perl > One thing I'm wondering is if the non-pure-perl packages built on build8st/build8xt is really ready for release since build8st/build8xt have many packages with older versions than on build8s/build8x. In some cases, packages installed on build8s/8x isn't installed on 8st/8xt which might give resulting packages without functionality which the current package has if the maintainer (new maintainer) hasn't been keeping a extra watchful eye on the build output. From maciej at opencsw.org Mon Mar 22 16:49:33 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 22 Mar 2010 15:49:33 +0000 Subject: [csw-maintainers] A problem with subversion client Message-ID: My Subversion client seems to be generated patches with wrong numbers on the buildfarm. When I create a patch with 'svn diff', it should apply back with no offsets, right? Please look at this: maciej at login [login]:~/src/opencsw/pkg/ncurses/trunk > svn revert Makefile cp Makefile.mod Makefile svn diff Makefile > 1.patch svn revert Makefile gpatch -p0 -i 1.patch Reverted 'Makefile' patching file Makefile Hunk #2 succeeded at 6 (offset 2 lines). Hunk #3 succeeded at 18 (offset -2 lines). Hunk #4 succeeded at 75 (offset 2 lines). From maciej at opencsw.org Mon Mar 22 16:56:57 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 22 Mar 2010 15:56:57 +0000 Subject: [csw-maintainers] A problem with subversion client In-Reply-To: References: Message-ID: 2010/3/22 Maciej (Matchek) Blizinski : > My Subversion client seems to be generated patches with wrong numbers Looks like I couldn't decide which grammatical form to use. Patches generated with 'svn diff' appear to have been generated against different base files than the actual files in the repository; or there is a problem with the numbering. Also, the number of context lines around changes is not always the default three. Interestingly, the same thing happens with fresh checkouts. Can other people reproduce it? Maciej From bwalton at opencsw.org Mon Mar 22 17:06:29 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 22 Mar 2010 12:06:29 -0400 Subject: [csw-maintainers] A problem with subversion client In-Reply-To: References: Message-ID: <1269273912-sup-1866@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Mon Mar 22 11:56:57 -0400 2010: > Can other people reproduce it? I haven't tried this, but I did see some 'wonkiness' with `svn log` over the weekend. Things that I knew were committed weren't in the log and running `svn update` seemed to fix it for me. At the time I didn't spend time investigating, but maybe I will now that you've raised this other concern. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From hson at opencsw.org Mon Mar 22 17:12:00 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Mon, 22 Mar 2010 17:12:00 +0100 Subject: [csw-maintainers] merge issue with 64-bit builds (was [csw-pkgsubmissions] newpkgs libproxy) In-Reply-To: References: <4BA64225.9040909@opencsw.org> Message-ID: <4BA796D0.2050901@opencsw.org> On 2010-03-22 16:37, Philip Brown wrote: > problem with dependancies: uses isaexec in ALL packages. not appropriate. Hmm, well, I have no idea how to fix that, the isaexec-part is added by GAR. Any suggestions Dago? > For that matter, why is there even a 64bit binary at all? > (/opt/csw/bin/sparcv9/libproxy) ? Same thing here, by default when building 64-bit, and as far as I know, there isn't any way to tell GAR to merge only libraries not binaries when building 64-bit. The only variables I know of is, BUILD64 and NOISAEXEC, and when setting NOISAEXEC, you still get a 64-bit binary in the package, but without the isaexec link. From maciej at opencsw.org Mon Mar 22 18:16:39 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 22 Mar 2010 17:16:39 +0000 Subject: [csw-maintainers] merge issue with 64-bit builds (was [csw-pkgsubmissions] newpkgs libproxy) In-Reply-To: <4BA796D0.2050901@opencsw.org> References: <4BA64225.9040909@opencsw.org> <4BA796D0.2050901@opencsw.org> Message-ID: 2010/3/22 Roger H?kansson : > there isn't any way to tell GAR to merge only libraries not binaries when > building 64-bit. There is, here's the idiom: MERGE_DIRS_isa-extra = $(libdir) It's literally 'extra', a shorthand for: MERGE_DIRS_isa-sparcv9 = $(libdir) MERGE_DIRS_isa-amd64 = $(libdir) From phil at bolthole.com Mon Mar 22 19:36:38 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 22 Mar 2010 11:36:38 -0700 Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> Message-ID: On Sat, Mar 20, 2010 at 12:26 AM, Dagobert Michelsen wrote: > >> More "good" news, is that many of them dont need the new CSW X11, so >> there is no direct conflict. But those ones that use gtk, either >> directly, or INDIRECTLY, potentially have a problem. > > Ugh. Does that mean we need double libraries: one in lib/ bound > against Sun X11 and one in X11/lib bound against CSW X11 and the > apps go to decide? > For some libraries... such as gtk.... yup looks like it. The "good" news is, we can probably just keep the legacy gtk libraries for those purposes. the matching bad news is, that still means, "no 3d hardware accel, for newer-fancier-gtk programs". Because as we previously found out.. some things just wont work with Sun X11, period. Even "newer" versions. All because of *#@$@ gtk "improvements". I dont remmeber the exact reasons, though; William's the expert on that. Maybe there's some kind of hack possible, but I'm scheptical about it. From phil at bolthole.com Mon Mar 22 19:40:58 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 22 Mar 2010 11:40:58 -0700 Subject: [csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw In-Reply-To: References: <740D4C44-60A7-4734-9180-C4F3FBECAD3B@opencsw.org> <20100317.18120300.680051978@gyor.oxdrove.co.uk> Message-ID: On Sat, Mar 20, 2010 at 2:09 PM, Dagobert Michelsen wrote: >... > > I'll do some GAR integration to make this as straight-forward as > alternatives. Great! thanks. > However, all this doesn't bring us close to NFS-sharing when > alternatives are used. Suggestions, gentlemen? I will repeat my question/request, that before people can make suggestiions for solutions, they first need to be better informed on exactly what our "alternatives" system does in /etc/opt. With a reminder that the "best behaviour" would presumably be to use /etc/opt as an *optional*, but not *required*, enhancement. ie: If /etc/opt was normally used to preserve user choices across upgrades... but without it, some kind of sane "default" was made visible... then in the NFS shared /opt/csw situation, it would be acceptible to lose the "preserve choices", as long as it just went with the default behaviour, rather than "I'm not going to work now". From hson at opencsw.org Mon Mar 22 19:42:22 2010 From: hson at opencsw.org (=?UTF-8?B?Um9nZXIgSMOla2Fuc3Nvbg==?=) Date: Mon, 22 Mar 2010 19:42:22 +0100 Subject: [csw-maintainers] merge issue with 64-bit builds (was [csw-pkgsubmissions] newpkgs libproxy) In-Reply-To: References: <4BA64225.9040909@opencsw.org> <4BA796D0.2050901@opencsw.org> Message-ID: <4BA7BA0E.6090101@opencsw.org> On 2010-03-22 18:16, Maciej (Matchek) Blizinski wrote: > 2010/3/22 Roger H?kansson: >> there isn't any way to tell GAR to merge only libraries not binaries when >> building 64-bit. > > There is, here's the idiom: > > MERGE_DIRS_isa-extra = $(libdir) > > It's literally 'extra', a shorthand for: > > MERGE_DIRS_isa-sparcv9 = $(libdir) > MERGE_DIRS_isa-amd64 = $(libdir) In this case (libproxy), that would do the trick. But in some cases one might want to skip merging binaries into the "base" package, but have "runnable scripts" in the development package (i.e where you have a xxx-config which gives pkg-config-like functionality). How would you do that then? From phil at bolthole.com Mon Mar 22 19:50:05 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 22 Mar 2010 11:50:05 -0700 Subject: [csw-maintainers] merge issue with 64-bit builds (was [csw-pkgsubmissions] newpkgs libproxy) In-Reply-To: <4BA7BA0E.6090101@opencsw.org> References: <4BA64225.9040909@opencsw.org> <4BA796D0.2050901@opencsw.org> <4BA7BA0E.6090101@opencsw.org> Message-ID: On Mon, Mar 22, 2010 at 11:42 AM, Roger H?kansson wrote: > In this case (libproxy), that would do the trick. > But in some cases one might want to skip merging binaries into the "base" > package, but have "runnable scripts" in the development package (i.e where > you have a xxx-config which gives pkg-config-like functionality). How would > you do that then? > that sort of thing sounds like it belongs more in a _devel package, btw. From hson at opencsw.org Mon Mar 22 19:53:18 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Mon, 22 Mar 2010 19:53:18 +0100 Subject: [csw-maintainers] merge issue with 64-bit builds (was [csw-pkgsubmissions] newpkgs libproxy) In-Reply-To: References: <4BA64225.9040909@opencsw.org> <4BA796D0.2050901@opencsw.org> <4BA7BA0E.6090101@opencsw.org> Message-ID: <4BA7BC9E.2010302@opencsw.org> On 2010-03-22 19:50, Philip Brown wrote: > On Mon, Mar 22, 2010 at 11:42 AM, Roger H?kansson wrote: > >> In this case (libproxy), that would do the trick. >> But in some cases one might want to skip merging binaries into the "base" >> package, but have "runnable scripts" in the development package (i.e where >> you have a xxx-config which gives pkg-config-like functionality). How would >> you do that then? >> > > that sort of thing sounds like it belongs more in a _devel package, btw. Exactly, but how do you get it into the _devel package if you don't merge the bindir? Maciej's solution makes sure that only libdir is merged for 64-bit modulations. From maciej at opencsw.org Mon Mar 22 19:53:00 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 22 Mar 2010 18:53:00 +0000 Subject: [csw-maintainers] merge issue with 64-bit builds (was [csw-pkgsubmissions] newpkgs libproxy) In-Reply-To: <4BA7BA0E.6090101@opencsw.org> References: <4BA64225.9040909@opencsw.org> <4BA796D0.2050901@opencsw.org> <4BA7BA0E.6090101@opencsw.org> Message-ID: 2010/3/22 Roger H?kansson : > On 2010-03-22 18:16, Maciej (Matchek) Blizinski wrote: >> >> 2010/3/22 Roger H?kansson: >>> >>> there isn't any way to tell GAR to merge only libraries not binaries when >>> building 64-bit. >> >> There is, here's the idiom: >> >> MERGE_DIRS_isa-extra = $(libdir) >> >> It's literally 'extra', a shorthand for: >> >> MERGE_DIRS_isa-sparcv9 = $(libdir) >> MERGE_DIRS_isa-amd64 ? = $(libdir) > > In this case (libproxy), that would do the trick. > But in some cases one might want to skip merging binaries into the "base" > package, but have "runnable scripts" in the development package (i.e where > you have a xxx-config which gives pkg-config-like functionality). How would > you do that then? Specific tools aside, this is a question for release managers: is it worth the trouble to cherry-pick binaries like this, risking an error? If so, how do we ensure that errors don't happen? (think: automated checks) Otherwise, maybe there's less overall risk in just including the 64-bit binaries, even though they might run slightly slower? * It might be a negligible difference. From phil at bolthole.com Mon Mar 22 20:01:22 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 22 Mar 2010 12:01:22 -0700 Subject: [csw-maintainers] merge issue with 64-bit builds (was [csw-pkgsubmissions] newpkgs libproxy) In-Reply-To: References: <4BA64225.9040909@opencsw.org> <4BA796D0.2050901@opencsw.org> <4BA7BA0E.6090101@opencsw.org> Message-ID: On Mon, Mar 22, 2010 at 11:53 AM, Maciej (Matchek) Blizinski wrote: > > Specific tools aside, this is a question for release managers: is it > worth the trouble to cherry-pick binaries like this, risking an error? > ?If so, how do we ensure that errors don't happen? ?(think: automated > checks) ?Otherwise, maybe there's less overall risk in just including > the 64-bit binaries, even though they might run slightly slower? short answer: I thought Dagobert already announced a few weeks ago, that he was going to change GAR to default to ONLY building/adding in libraries for 64bit, unless explicitly told to do otherwise? longer answer: This isnt a problem without GAR. GAR should be fixed so it doesnt introduce problems, rather than approaching things from the backward approach of "this is difficult to do in GAR, so we should make GAR happy" :-/ "This is difficult to do in GAR" should not ever be a rationale for packaging a certain way. Policy choices should be based on what the user sees. From dam at opencsw.org Mon Mar 22 20:56:51 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 22 Mar 2010 20:56:51 +0100 Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: <1269207173-sup-988@pinkfloyd.chass.utoronto.ca> References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> <4BA68E7A.9000605@opencsw.org> <1269207173-sup-988@pinkfloyd.chass.utoronto.ca> Message-ID: <04879D62-7F0F-4781-A6EA-7D0AD27091BB@opencsw.org> Hi Ben, Am 21.03.2010 um 22:34 schrieb Ben Walton: > Excerpts from Ihsan Dogan's message of Sun Mar 21 17:24:10 -0400 2010: >> Ok, so what is our decision now? To drop Solaris 8 support? > > I haven't seen any -1's for that and again, I say YES! Ok the,if there are no further posts I'll raise the default GAR build hosts to build9s and build9x. The Solaris 8 hosts will of course stay in place, just in case. > I also think > Roger's suggestion of announcing a cut-off date for 9 _now_ is great. > (Personally, I'd be ok with dropping 9 now too, but that's based > solely on not having it deployed here at all.) IMHO we should support Solaris 9 as long as it is supported by Sun, that means it has not entered Vintage Phase II. This is 30. October 2011. OTOH there are virtually no downloads for Solaris 9 any more if you look at the download stats. Best regards -- Dago From dam at opencsw.org Mon Mar 22 20:59:34 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 22 Mar 2010 20:59:34 +0100 Subject: [csw-maintainers] [csw-pkgsubmissions] Preparing for release of perl 5.10.1 with another 80-90 packages In-Reply-To: <4BA777A1.3090606@opencsw.org> References: <625385e31003150631w3315d094rf3f724ba1730283b@mail.gmail.com> <4BA777A1.3090606@opencsw.org> Message-ID: Hi Roger, Am 22.03.2010 um 14:58 schrieb Roger H?kansson: > On 2010-03-15 14:31, Peter Bonivart wrote: >> The Perl project is coming to an end, is there anything special >> regarding the release when there are so many packages that need to be >> released together? >> >> http://wiki.opencsw.org/project-perl > > One thing I'm wondering is if the non-pure-perl packages built on > build8st/build8xt is really ready for release since build8st/ > build8xt have many packages with older versions than on build8s/ > build8x. What do you mean by non-pure-perl packages? Those with binary libs? Exactly those have been rebuild. > In some cases, packages installed on build8s/8x isn't installed on > 8st/8xt which might give resulting packages without functionality > which the current package has if the maintainer (new maintainer) > hasn't been keeping a extra watchful eye on the build output. Hopefully we have taken care of this :-) Best regards -- Dago From maciej at opencsw.org Mon Mar 22 21:00:06 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 22 Mar 2010 20:00:06 +0000 Subject: [csw-maintainers] merge issue with 64-bit builds (was [csw-pkgsubmissions] newpkgs libproxy) In-Reply-To: References: <4BA64225.9040909@opencsw.org> <4BA796D0.2050901@opencsw.org> <4BA7BA0E.6090101@opencsw.org> Message-ID: 2010/3/22 Philip Brown : > On Mon, Mar 22, 2010 at 11:53 AM, Maciej (Matchek) Blizinski > wrote: >> >> Specific tools aside, this is a question for release managers: is it >> worth the trouble to cherry-pick binaries like this, risking an error? >> ?If so, how do we ensure that errors don't happen? ?(think: automated >> checks) ?Otherwise, maybe there's less overall risk in just including >> the 64-bit binaries, even though they might run slightly slower? > > > short answer: > I thought Dagobert already announced a few weeks ago, that he was > going to change GAR to default to ONLY building/adding in libraries > for 64bit, unless explicitly told to do otherwise? > > longer answer: > > This isnt a problem without GAR. > GAR should be fixed so it doesnt introduce problems, rather than > approaching things from the backward approach of "this is difficult to > do in GAR, so we should make GAR happy" > :-/ > > "This is difficult to do in GAR" should not ever be a rationale for > packaging a certain way. Policy choices should be based on what the > user sees. Are you obsessed with this one tool? I have specifically asked to set any specific tools aside for the purposes of this conversation. I'll rephrase the question: Suppose you're building 32-bit and 64-bit versions of a piece of software, which includes executable architecture-dependent scripts, binaries, and shared libraries. I understand that the policy would be to: - install shared libraries for both architectures - install executable scripts for both architectures - install binaries for one architecture There are two kinds of error you can make: include a file that shouldn't be included, or fail to include a file that should have been. The latter error has more profound effect, since if it happens in the dev package, and it's a *-config script, it can screw up the compilation of dependent packages. How do you go about discriminating between the executables (scripts or binaries) to be or not to be included in the resulting package? A method invulnerable to human-error would be preferred. From dam at opencsw.org Mon Mar 22 21:06:44 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 22 Mar 2010 21:06:44 +0100 Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> Message-ID: Hi Phil, Am 22.03.2010 um 19:36 schrieb Philip Brown: > On Sat, Mar 20, 2010 at 12:26 AM, Dagobert Michelsen > wrote: >> >>> More "good" news, is that many of them dont need the new CSW X11, so >>> there is no direct conflict. But those ones that use gtk, either >>> directly, or INDIRECTLY, potentially have a problem. >> >> Ugh. Does that mean we need double libraries: one in lib/ bound >> against Sun X11 and one in X11/lib bound against CSW X11 and the >> apps go to decide? > > For some libraries... such as gtk.... yup looks like it. > > The "good" news is, we can probably just keep the legacy gtk libraries > for those purposes. So we don't provide newer versions which allow 3d acceleration? > the matching bad news is, that still means, "no 3d hardware accel, for > newer-fancier-gtk programs". > > Because as we previously found out.. some things just wont work with > Sun X11, period. > Even "newer" versions. > All because of *#@$@ gtk "improvements". > > I dont remmeber the exact reasons, though; William's the expert on > that. Maybe there's > some kind of hack possible, but I'm scheptical about it. William? Ping-ping-ping... :) Best regards -- Dago From dam at opencsw.org Mon Mar 22 21:10:29 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 22 Mar 2010 21:10:29 +0100 Subject: [csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw In-Reply-To: References: <740D4C44-60A7-4734-9180-C4F3FBECAD3B@opencsw.org> <20100317.18120300.680051978@gyor.oxdrove.co.uk> Message-ID: Hi Phil, Am 22.03.2010 um 19:40 schrieb Philip Brown: > On Sat, Mar 20, 2010 at 2:09 PM, Dagobert Michelsen > wrote: >> ... >> >> I'll do some GAR integration to make this as straight-forward as >> alternatives. > > Great! thanks. > >> However, all this doesn't bring us close to NFS-sharing when >> alternatives are used. Suggestions, gentlemen? > > I will repeat my question/request, that before people can make > suggestiions for solutions, they first need to be better informed on > exactly what our "alternatives" system does in /etc/opt. > > With a reminder that the "best behaviour" would presumably be to > use /etc/opt as > an *optional*, but not *required*, enhancement. > > ie: If /etc/opt was normally used to preserve user choices across > upgrades... but without it, some kind of sane "default" was made > visible... then in the NFS shared /opt/csw situation, it would be > acceptible to lose the "preserve choices", as long as it just went > with the default behaviour, rather than "I'm not going to work now". Alternatives makes a link from the thing to choose to /etc/opt/csw/ alternatives/. There is another link to the final file which is automacially handled by alternatives. If on the source location the link is not pointing to /etc/opt/csw/... the alternatives system doesn't touch it as the link probably has been done manually. In general it is possible to hardwire it to minimal with a specific class. The idea would be to have a cas script that reads the csw.conf if it is NFS shared or not and when in NFS-share-mode it makes one static link without alternatives. I could add this to the existing alternatives CAS. Comments? Best regards -- Dago From phil at bolthole.com Mon Mar 22 21:12:52 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 22 Mar 2010 13:12:52 -0700 Subject: [csw-maintainers] merge issue with 64-bit builds (was [csw-pkgsubmissions] newpkgs libproxy) In-Reply-To: References: <4BA64225.9040909@opencsw.org> <4BA796D0.2050901@opencsw.org> <4BA7BA0E.6090101@opencsw.org> Message-ID: On Mon, Mar 22, 2010 at 1:00 PM, Maciej (Matchek) Blizinski wrote: > How do you go about discriminating between the executables (scripts or > binaries) to be or not to be included in the resulting package? Any automated method of doing this, is guaranteed to occasionsally be flawed. To just take the example of "devel" packages: Sometimes, if a devel package is pure text, you might assume that it's arch independant. Except when it has v9 or other 64bit flags in configs. Or, perhaps it has size-of-int tricks and assumptions Or, .... It basically comes down to human judgement eventually. So you might just choose to make it easier for humans to quickly and efficiently divide the files as appropriately. From dam at opencsw.org Mon Mar 22 21:12:58 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 22 Mar 2010 21:12:58 +0100 Subject: [csw-maintainers] merge issue with 64-bit builds (was [csw-pkgsubmissions] newpkgs libproxy) In-Reply-To: <4BA7BA0E.6090101@opencsw.org> References: <4BA64225.9040909@opencsw.org> <4BA796D0.2050901@opencsw.org> <4BA7BA0E.6090101@opencsw.org> Message-ID: Hi Roger, Am 22.03.2010 um 19:42 schrieb Roger H?kansson: > On 2010-03-22 18:16, Maciej (Matchek) Blizinski wrote: >> 2010/3/22 Roger H?kansson: >>> there isn't any way to tell GAR to merge only libraries not >>> binaries when >>> building 64-bit. >> >> There is, here's the idiom: >> >> MERGE_DIRS_isa-extra = $(libdir) >> >> It's literally 'extra', a shorthand for: >> >> MERGE_DIRS_isa-sparcv9 = $(libdir) >> MERGE_DIRS_isa-amd64 = $(libdir) > > In this case (libproxy), that would do the trick. > But in some cases one might want to skip merging binaries into the > "base" package, but have "runnable scripts" in the development > package (i.e where you have a xxx-config which gives pkg-config-like > functionality). How would you do that then? Smart question :-) I needed to fail first to become aware of it. The solution is that there is a specific merge-rule that just copies the *-config files which you can add to the merge-scripts for the modulation: MERGE_SCRIPTS_isa-extra = copy-relocated-only copy-config-only MERGE_DIRS_isa-extra = $(libdir) I have used this e.g. at ncurses and pcre if you want to see a real-life example. Best regards -- Dago From dam at opencsw.org Mon Mar 22 21:13:46 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 22 Mar 2010 21:13:46 +0100 Subject: [csw-maintainers] merge issue with 64-bit builds (was [csw-pkgsubmissions] newpkgs libproxy) In-Reply-To: References: <4BA64225.9040909@opencsw.org> <4BA796D0.2050901@opencsw.org> <4BA7BA0E.6090101@opencsw.org> Message-ID: <5EF321CF-8F37-463D-AB08-A2940D2C0FF5@opencsw.org> Hi Phil, Am 22.03.2010 um 19:50 schrieb Philip Brown: > On Mon, Mar 22, 2010 at 11:42 AM, Roger H?kansson > wrote: >> In this case (libproxy), that would do the trick. >> But in some cases one might want to skip merging binaries into the >> "base" >> package, but have "runnable scripts" in the development package >> (i.e where >> you have a xxx-config which gives pkg-config-like functionality). >> How would >> you do that then? > > that sort of thing sounds like it belongs more in a _devel package, > btw. If you say PKGFILES_ = $(PKGFILES_DEVEL) it is already in the default rules. As are .3 manpages :-) Best regards -- Dago From dam at opencsw.org Mon Mar 22 21:14:55 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 22 Mar 2010 21:14:55 +0100 Subject: [csw-maintainers] merge issue with 64-bit builds (was [csw-pkgsubmissions] newpkgs libproxy) In-Reply-To: References: <4BA64225.9040909@opencsw.org> <4BA796D0.2050901@opencsw.org> <4BA7BA0E.6090101@opencsw.org> Message-ID: <4BC27C08-DA11-4671-B452-C87B43BC8DF3@opencsw.org> Hi Maciej, Am 22.03.2010 um 19:53 schrieb Maciej (Matchek) Blizinski: > Specific tools aside, this is a question for release managers: is it > worth the trouble to cherry-pick binaries like this, risking an error? > If so, how do we ensure that errors don't happen? (think: automated > checks) Otherwise, maybe there's less overall risk in just including > the 64-bit binaries, even though they might run slightly slower? The problem is if you don't have 64/*-config you probably can't use the library as dependency when you build other things. So it is definitely needed. Best regards -- Dago From jgoerzen at opencsw.org Mon Mar 22 21:26:14 2010 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Mon, 22 Mar 2010 13:26:14 -0700 Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: <04879D62-7F0F-4781-A6EA-7D0AD27091BB@opencsw.org> References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> <4BA68E7A.9000605@opencsw.org> <1269207173-sup-988@pinkfloyd.chass.utoronto.ca> <04879D62-7F0F-4781-A6EA-7D0AD27091BB@opencsw.org> Message-ID: <315c02ae1003221326s6696d45td157c2e993d86901@mail.gmail.com> >>> Ok, so what is our decision now? To drop Solaris 8 support? >> >> I haven't seen any -1's for that and again, I say YES! +1 for dropping solaris 8 support (personally i'm okay with dropping 9 also). Jake From phil at bolthole.com Mon Mar 22 21:35:43 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 22 Mar 2010 13:35:43 -0700 Subject: [csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw In-Reply-To: References: <740D4C44-60A7-4734-9180-C4F3FBECAD3B@opencsw.org> <20100317.18120300.680051978@gyor.oxdrove.co.uk> Message-ID: On Mon, Mar 22, 2010 at 1:10 PM, Dagobert Michelsen wrote: > Hi Phil, > *wave* > Am 22.03.2010 um 19:40 schrieb Philip Brown: >> >> I will repeat my question/request, that before people can make >> suggestiions for solutions, they first need to be better informed on >> exactly what our "alternatives" system does in /etc/opt. >> > > Alternatives makes a link from the thing to choose to > /etc/opt/csw/alternatives/. > There is another link to the final file which is automacially handled by > alternatives. HHMMM... this is surprising to me. If I am reading this correctly, it seems like you are saying something like; ls -l /opt/csw/bin/alternative-switched-prog -> /etc/opt/csw/alternatives/[PKG]/alternative-switch-prog ls -l /etc/opt/csw/alternatives/[PKG]/alternative-switch-prog -> /opt/csw/bin/real-location-prog Does that basically summarize it? I am surprised because I thought it would be more like ls -l /opt/csw/bin/alternative-switched-prog -> real-location-prog /etc/opt/csw/alternatives/[PKG]/alternative-switch-prog [is a file, describing "preferred" destination of symlink] > The idea would be to have a cas script that reads the csw.conf if it > is NFS shared or not and when in NFS-share-mode it makes one static link > without > alternatives. I could add this to the existing alternatives CAS. Comments? that may be one way to do it. However, It "feels" to me, to be better to be more consistent about the user-touching implementation. By that I mean, it might be nice if possible to consistently have the symlink be 'directly' to the target, whether NFS shared or otherwise. That has the additional benefit that you do not have to do any "special configuration" if you want to do mixed modes. That is to say, you could have a completely locally installed, "regular" CSW package installation on one machine, and then use rsync -a /opt/csw/. nfs-master:/opt/csw (or to any other machine, maybe just a "client" instead of nfs server!) and have it "work right" after copying. From dam at opencsw.org Mon Mar 22 21:47:58 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 22 Mar 2010 21:47:58 +0100 Subject: [csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw In-Reply-To: References: <740D4C44-60A7-4734-9180-C4F3FBECAD3B@opencsw.org> <20100317.18120300.680051978@gyor.oxdrove.co.uk> Message-ID: Hi Phil, Am 22.03.2010 um 21:35 schrieb Philip Brown: > On Mon, Mar 22, 2010 at 1:10 PM, Dagobert Michelsen > wrote: >> Am 22.03.2010 um 19:40 schrieb Philip Brown: >>> I will repeat my question/request, that before people can make >>> suggestiions for solutions, they first need to be better informed on >>> exactly what our "alternatives" system does in /etc/opt. >> >> >> Alternatives makes a link from the thing to choose to >> /etc/opt/csw/alternatives/. >> There is another link to the final file which is automacially >> handled by >> alternatives. > > HHMMM... this is surprising to me. If I am reading this correctly, it > seems like you are saying something like; > > ls -l /opt/csw/bin/alternative-switched-prog -> > /etc/opt/csw/alternatives/[PKG]/alternative-switch-prog > > ls -l /etc/opt/csw/alternatives/[PKG]/alternative-switch-prog -> > /opt/csw/bin/real-location-prog Yes. > I am surprised because I thought it would be more like > > ls -l /opt/csw/bin/alternative-switched-prog -> > real-location-prog If you do this manually it is the indication for alternatives that it shouldn't interfere. That's why it does this differently. > > /etc/opt/csw/alternatives/[PKG]/alternative-switch-prog > [is a file, describing "preferred" destination of symlink] Nope, that is at /opt/csw/share/alternatives/ and is only used in the CAS. >> The idea would be to have a cas script that reads the csw.conf if it >> is NFS shared or not and when in NFS-share-mode it makes one static >> link >> without >> alternatives. I could add this to the existing alternatives CAS. >> Comments? > > that may be one way to do it. However, It "feels" to me, to be better > to be more consistent about the user-touching implementation. > By that I mean, it might be nice if possible to consistently have the > symlink be 'directly' to the target, whether NFS shared or otherwise. Alternatives just doesn't work this way and I don't have time to modify the behaviour correctly in the code. > That has the additional benefit that you do not have to do any > "special configuration" if you want to do mixed modes. > That is to say, you could have a completely locally installed, > "regular" CSW package installation on one machine, and then use > > rsync -a /opt/csw/. nfs-master:/opt/csw > (or to any other machine, maybe just a "client" instead of nfs > server!) > > and have it "work right" after copying. This sucks as it is in direct opposition to sparse zones. We get in so much trouble with this that I am constantly asking myself if it is worth it. Best regards -- Dago From phil at bolthole.com Mon Mar 22 22:20:59 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 22 Mar 2010 14:20:59 -0700 Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> Message-ID: On Mon, Mar 22, 2010 at 1:06 PM, Dagobert Michelsen wrote: > >> >> The "good" news is, we can probably just keep the legacy gtk libraries >> for those purposes. > > So we don't provide newer versions which allow 3d acceleration? > well, the question is.. HOW do we do that? Dago, you are the person who provided our current gtk2 libs. Do you wish to go back,and redo it, and all its dependencies, to see if it can be made to work on sun X11 after all? :-} From phil at bolthole.com Mon Mar 22 22:23:22 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 22 Mar 2010 14:23:22 -0700 Subject: [csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw In-Reply-To: References: <740D4C44-60A7-4734-9180-C4F3FBECAD3B@opencsw.org> <20100317.18120300.680051978@gyor.oxdrove.co.uk> Message-ID: On Mon, Mar 22, 2010 at 1:47 PM, Dagobert Michelsen wrote: .... >> that may be one way to do it. However, It "feels" to me, to be better >> to be more consistent about the user-touching implementation. >> By that I mean, it might be nice if possible to consistently have the >> symlink be 'directly' to the target, whether NFS shared or otherwise. >... > >> That has the additional benefit that you do not have to do any >> "special configuration" if you want to do mixed modes. >> ... >> >> rsync -a /opt/csw/. ? nfs-master:/opt/csw >> ?(or to any other machine, maybe just a "client" instead of nfs server!) >> >> and have it "work right" after copying. > > This sucks as it is in direct opposition to sparse zones. Could you remind us as to how, please? > We get > in so much trouble with this that I am constantly asking myself > if it is worth it. By "this", do you mean "alternatives"? From phil at bolthole.com Mon Mar 22 23:18:54 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 22 Mar 2010 15:18:54 -0700 Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: <315c02ae1003221326s6696d45td157c2e993d86901@mail.gmail.com> References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> <4BA68E7A.9000605@opencsw.org> <1269207173-sup-988@pinkfloyd.chass.utoronto.ca> <04879D62-7F0F-4781-A6EA-7D0AD27091BB@opencsw.org> <315c02ae1003221326s6696d45td157c2e993d86901@mail.gmail.com> Message-ID: On Mon, Mar 22, 2010 at 1:26 PM, Jake Goerzen wrote: >>>> Ok, so what is our decision now? To drop Solaris 8 support? >>> >>> I haven't seen any -1's for that and again, I say YES! > > +1 for dropping solaris 8 support (personally i'm okay with dropping 9 also). > Hmmm.. well, quasi-officially, we have already dropped it. it's no longer "required" for packages, for many months now. it has just remained the default build env. but I guess no longer now... From phil at bolthole.com Mon Mar 22 23:20:19 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 22 Mar 2010 15:20:19 -0700 Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: <04879D62-7F0F-4781-A6EA-7D0AD27091BB@opencsw.org> References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> <4BA68E7A.9000605@opencsw.org> <1269207173-sup-988@pinkfloyd.chass.utoronto.ca> <04879D62-7F0F-4781-A6EA-7D0AD27091BB@opencsw.org> Message-ID: On Mon, Mar 22, 2010 at 12:56 PM, Dagobert Michelsen wrote: > > > Ok the,if there are no further posts I'll raise the default GAR build hosts > to build9s and build9x. The Solaris 8 hosts will of course stay in place, > just in case. > if you are going to do that, then please also tweak the login/motd/something upon sshing in. in really ugly, cannot-miss-it fashion. Just to remind people who go there by habit, to now go to the sol9 ones instead. From jgoerzen at opencsw.org Tue Mar 23 00:11:42 2010 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Mon, 22 Mar 2010 16:11:42 -0700 Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> Message-ID: <315c02ae1003221611n762bd9c3tea9742d53a8d67ab@mail.gmail.com> On Mon, Mar 22, 2010 at 2:20 PM, Philip Brown wrote: > On Mon, Mar 22, 2010 at 1:06 PM, Dagobert Michelsen wrote: >> >>> >>> The "good" news is, we can probably just keep the legacy gtk libraries >>> for those purposes. >> >> So we don't provide newer versions which allow 3d acceleration? >> > > > well, the question is.. HOW do we do that? > > Dago, you are the person who provided our current gtk2 libs. > > Do you wish to go back,and redo it, and all its dependencies, to see > if it can be made to work on sun X11 after all? :-} Phil was right to express reluctance to releasing X11 packages. IMHO we should roll back to before the CSW X11 packages recently released. Then make that our stable release. Then move on to Solaris 10. The reason I say this is because it seems like we have been trying to sort of "back port" newer features that are in Solaris 10 into Solaris 8 packages so that we can build on Solaris 8 and then run on Solaris 10. For example the CSWlibxv package was originally created by me way back before the blastwave split. I packaged it because Solaris 8 didn't have libxv but Sol 10 does. This enabled me to compile and link ogle against libxv on Solaris 8 but that didn't mean Xv extension was available on solaris 8! Thanks, Jake From maciej at opencsw.org Tue Mar 23 01:28:31 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 23 Mar 2010 00:28:31 +0000 Subject: [csw-maintainers] How does libstdc++.so.6 find libgcc_s.so.1 Message-ID: While reworking library checking (again!) in checkpkg, I encountered an interesting case: gcc. I've examined libstdc++.so.6: maciej at build8s [build8s]:~/src/opencsw/gar/v2 > /usr/ccs/bin/dump -Lv /opt/csw/gcc4/lib/libstdc++.so.6.0.10 | ghead -n 11 /opt/csw/gcc4/lib/libstdc++.so.6.0.10: **** DYNAMIC SECTION INFORMATION **** .dynamic: [INDEX] Tag Value [1] NEEDED libm.so.1 [2] NEEDED libgcc_s.so.1 [3] INIT 0x5c0f0 [4] FINI 0x5c10c [5] SONAME libstdc++.so.6 (...) It needs libgcc_s.so.1 and has no RPATH section. libgcc_s.so.1 is in the same directory, but since $ORIGIN is not present in RPATH, the library should not be found. Running ldd: maciej at build8s [build8s]:~/src/opencsw/gar/v2 > ldd /opt/csw/gcc4/lib/libstdc++.so.6.0.10 libm.so.1 => /usr/lib/libm.so.1 libgcc_s.so.1 => (file not found) libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 /usr/platform/SUNW,SPARC-Enterprise-T5220/lib/libc_psr.so.1 ...it indeed is not found. But we know from elsewhere that programs linked against libstdc++.so.6 do work. How? All programs linking against libstdc++.so.6 also happen to be linked against libgcc_s.so.1 so the problem never surfaces? Is it a bug or a feature? From phil at bolthole.com Tue Mar 23 02:20:21 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 22 Mar 2010 18:20:21 -0700 Subject: [csw-maintainers] How does libstdc++.so.6 find libgcc_s.so.1 In-Reply-To: References: Message-ID: On Mon, Mar 22, 2010 at 5:28 PM, Maciej (Matchek) Blizinski wrote: > .... > ...it indeed is not found. ?But we know from elsewhere that programs > linked against libstdc++.so.6 do work. ?How? ?All programs linking > against libstdc++.so.6 also happen to be linked against libgcc_s.so.1 > so the problem never surfaces? Yup. and/or linked against other things in /opt/csw/lib. From dam at opencsw.org Tue Mar 23 10:05:24 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 23 Mar 2010 10:05:24 +0100 Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> Message-ID: <908A3B6E-FCB1-452F-9C9D-2C1D8F4DA904@opencsw.org> Hi Phil, Am 22.03.2010 um 22:20 schrieb Philip Brown: > On Mon, Mar 22, 2010 at 1:06 PM, Dagobert Michelsen > wrote: >>> The "good" news is, we can probably just keep the legacy gtk >>> libraries >>> for those purposes. >> >> So we don't provide newer versions which allow 3d acceleration? > > well, the question is.. HOW do we do that? > > Dago, you are the person who provided our current gtk2 libs. > > Do you wish to go back,and redo it, and all its dependencies, to see > if it can be made to work on sun X11 after all? :-} I'm pretty sure it can. However, before doing so I would like to hear some feedback from William what he thinks about it. Best regards -- Dago From dam at opencsw.org Tue Mar 23 10:07:10 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 23 Mar 2010 10:07:10 +0100 Subject: [csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw In-Reply-To: References: <740D4C44-60A7-4734-9180-C4F3FBECAD3B@opencsw.org> <20100317.18120300.680051978@gyor.oxdrove.co.uk> Message-ID: <7DCB4CDC-B479-413D-A506-CF6974CF7161@opencsw.org> Hi Phil, Am 22.03.2010 um 22:23 schrieb Philip Brown: > On Mon, Mar 22, 2010 at 1:47 PM, Dagobert Michelsen > wrote: >> This sucks as it is in direct opposition to sparse zones. > > Could you remind us as to how, please? Sparse-Zones: Must keep configuration in /etc/opt/csw, must not modify /opt/csw/etc NFS-Shared: Must keep configuration in /opt/csw/etc, /etc/opt/csw ingored >> We get >> in so much trouble with this that I am constantly asking myself >> if it is worth it. > > By "this", do you mean "alternatives"? I mean NFS-shared /opt/csw. Alternatives works perfectly nice in all configurations except NFS-shared /opt/csw. Best regards -- Dago From dam at opencsw.org Tue Mar 23 10:10:19 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 23 Mar 2010 10:10:19 +0100 Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: <315c02ae1003221611n762bd9c3tea9742d53a8d67ab@mail.gmail.com> References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> <315c02ae1003221611n762bd9c3tea9742d53a8d67ab@mail.gmail.com> Message-ID: <28ABC7A1-BD48-4C09-B582-A3EE77A2FB93@opencsw.org> Hi Jake, Am 23.03.2010 um 00:11 schrieb Jake Goerzen: > On Mon, Mar 22, 2010 at 2:20 PM, Philip Brown > wrote: >> On Mon, Mar 22, 2010 at 1:06 PM, Dagobert Michelsen >> wrote: >>> >>>> >>>> The "good" news is, we can probably just keep the legacy gtk >>>> libraries >>>> for those purposes. >>> >>> So we don't provide newer versions which allow 3d acceleration? >> >> well, the question is.. HOW do we do that? >> >> Dago, you are the person who provided our current gtk2 libs. >> >> Do you wish to go back,and redo it, and all its dependencies, to see >> if it can be made to work on sun X11 after all? :-} > > Phil was right to express reluctance to releasing X11 packages. > IMHO we should roll back to before the CSW X11 packages recently > released. Then make that our stable release. Then move on to Solaris > 10. Interesting move. You suggest "Let's do one last stable with Solaris 8 and then drop Solaris 8 and 9". Sounds also not too bad for me. And by end of 2011 we may have a stable when Solaris 9 eosl ends ;-) Best regards -- Dago From pfelecan at opencsw.org Tue Mar 23 10:25:43 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 23 Mar 2010 10:25:43 +0100 Subject: [csw-maintainers] How does libstdc++.so.6 find libgcc_s.so.1 In-Reply-To: (Maciej Blizinski's message of "Tue, 23 Mar 2010 00:28:31 +0000") References: Message-ID: "Maciej (Matchek) Blizinski" writes: > But we know from elsewhere that programs > linked against libstdc++.so.6 do work. How? All programs linking > against libstdc++.so.6 also happen to be linked against libgcc_s.so.1 > so the problem never surfaces? Is it a bug or a feature? Both. The bug is minor *and* the feature major. -- Peter From maciej at opencsw.org Tue Mar 23 13:20:01 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 23 Mar 2010 12:20:01 +0000 Subject: [csw-maintainers] How does libstdc++.so.6 find libgcc_s.so.1 In-Reply-To: References: Message-ID: 2010/3/23 Philip Brown : > On Mon, Mar 22, 2010 at 5:28 PM, Maciej (Matchek) Blizinski > wrote: >> .... >> ...it indeed is not found. ?But we know from elsewhere that programs >> linked against libstdc++.so.6 do work. ?How? ?All programs linking >> against libstdc++.so.6 also happen to be linked against libgcc_s.so.1 >> so the problem never surfaces? > > Yup. > and/or linked against other things in /opt/csw/lib. Any ideas how to tell a legitimate case such as this one from a buggy case? Please note that a bug might occur due to changes in other packages, if the soname is from another package. I see three things I could do here: 1. Throw an error ("missing-soname"), and let maintainers add overrides 2. Add a heuristic: "if the same package provides a soname equal to the missing one, don't throw an error". This would be only a heuristic, since there will be no check whether the soname is actually used at runtime. 3. Do a hybrid approach: if the same package provides the soname which appears to be missing, throw a different error tag, so that the maintainers will be able to add an override from one tag, but not the other. For example: "missing-soname-from-own-package". Thoughts? From maciej at opencsw.org Tue Mar 23 13:33:01 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 23 Mar 2010 12:33:01 +0000 Subject: [csw-maintainers] merge issue with 64-bit builds (was [csw-pkgsubmissions] newpkgs libproxy) In-Reply-To: References: <4BA64225.9040909@opencsw.org> <4BA796D0.2050901@opencsw.org> <4BA7BA0E.6090101@opencsw.org> Message-ID: 2010/3/22 Philip Brown : > On Mon, Mar 22, 2010 at 1:00 PM, Maciej (Matchek) Blizinski > wrote: > >> How do you go about discriminating between the executables (scripts or >> binaries) to be or not to be included in the resulting package? > > Any automated method of doing this, is guaranteed to occasionsally be flawed. > To just take the example of "devel" packages: > Sometimes, if a devel package is pure text, you might assume that it's > arch independant. > > Except when it has v9 or other 64bit flags in configs. Yes, and it's easy to detect these cases. > Or, perhaps it has size-of-int tricks and assumptions These might be harder to detect. > Or, .... > > It basically comes down to human judgement eventually. > > So you might just choose to make it easier for humans to quickly and > efficiently divide the files as appropriately. Do I read you correctly that you're questioning the feasibility of automation in this area by arguing that "it might fail"? From william at wbonnet.net Tue Mar 23 15:16:13 2010 From: william at wbonnet.net (William Bonnet) Date: Tue, 23 Mar 2010 15:16:13 +0100 Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: <908A3B6E-FCB1-452F-9C9D-2C1D8F4DA904@opencsw.org> References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> <908A3B6E-FCB1-452F-9C9D-2C1D8F4DA904@opencsw.org> Message-ID: Hi Sorry i was pretty busy at office these days... i'll take some time t answer late emails tonight cheers W. Le 23 mars 2010 ? 10:05, Dagobert Michelsen a ?crit : > Hi Phil, > > Am 22.03.2010 um 22:20 schrieb Philip Brown: >> On Mon, Mar 22, 2010 at 1:06 PM, Dagobert Michelsen wrote: >>>> The "good" news is, we can probably just keep the legacy gtk libraries >>>> for those purposes. >>> >>> So we don't provide newer versions which allow 3d acceleration? >> >> well, the question is.. HOW do we do that? >> >> Dago, you are the person who provided our current gtk2 libs. >> >> Do you wish to go back,and redo it, and all its dependencies, to see >> if it can be made to work on sun X11 after all? :-} > > I'm pretty sure it can. However, before doing so I would like to hear some > feedback from William what he thinks about it. > > > Best regards > > -- Dago From hson at opencsw.org Tue Mar 23 15:51:38 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Tue, 23 Mar 2010 15:51:38 +0100 Subject: [csw-maintainers] Update of tcl/tk/expect on build8st, build8xt, testing10x Message-ID: <4BA8D57A.4030702@opencsw.org> Now when the perl-project is coming to an end its time for the next one. Me and Dagobert have been working on updating tcl/tk/expect, both for getting a newer version (tcl/tk 8.4 is really old, 8.5 have been out there for over two years now) but also for getting 64-bit packages which is a requirement for some other 64-bit builds. However, since tcl, tk and expect are so tightly bound together, they must be released as a collection. This also means that I need to first package tcl, install it, package tk, install it and then package expect. I've successfully built the packages on my own buildfarm but now its time to do a official release. So on Saturday I will start with this project which means that for a minimum of 4 hours, tcl, tk and expect will probably not work as expected on build8st, build8xt and testing10x. My plan is to have everything finished the same day, but... Anyway, I will send out another mail when I start the upgrade of tcl as a reminder. From phil at bolthole.com Tue Mar 23 16:38:22 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 23 Mar 2010 08:38:22 -0700 Subject: [csw-maintainers] merge issue with 64-bit builds (was [csw-pkgsubmissions] newpkgs libproxy) In-Reply-To: References: <4BA64225.9040909@opencsw.org> <4BA796D0.2050901@opencsw.org> <4BA7BA0E.6090101@opencsw.org> Message-ID: On Tue, Mar 23, 2010 at 5:33 AM, Maciej (Matchek) Blizinski wrote: > 2010/3/22 Philip Brown : >> So you might just choose to make it easier for humans to quickly and >> efficiently divide the files as appropriately. > > Do I read you correctly that you're questioning the feasibility of > automation in this area by arguing that "it might fail"? > Well, that's a short way to put it. A longer, more accurate way would be: This should be a relatively rare occurrence (doing custom "wierd" splits). If you focus on making it easy to do the split manually, one time per package, you will probably eliminate much of a call for automation. In other words, since you KNOW there will be some cases where doing it manually will be *required*... I would suggest that you first focus your efforts on making that bit as painless as possible.. and then after that is done, reevaluate, "is it worth extra time to attempt additional automation in this area, particularly when I know it wont always work?" From dam at opencsw.org Tue Mar 23 16:50:25 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 23 Mar 2010 16:50:25 +0100 Subject: [csw-maintainers] merge issue with 64-bit builds (was [csw-pkgsubmissions] newpkgs libproxy) In-Reply-To: References: <4BA64225.9040909@opencsw.org> <4BA796D0.2050901@opencsw.org> <4BA7BA0E.6090101@opencsw.org> Message-ID: Hi Phil, Am 23.03.2010 um 16:38 schrieb Philip Brown: > If you focus on making it easy to do the split manually, one time per > package, you will probably eliminate much of a call for automation. With Dynamic Prototypes this is already as easy as possible: Best regards -- Dago From phil at bolthole.com Tue Mar 23 16:52:43 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 23 Mar 2010 08:52:43 -0700 Subject: [csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw In-Reply-To: <7DCB4CDC-B479-413D-A506-CF6974CF7161@opencsw.org> References: <740D4C44-60A7-4734-9180-C4F3FBECAD3B@opencsw.org> <20100317.18120300.680051978@gyor.oxdrove.co.uk> <7DCB4CDC-B479-413D-A506-CF6974CF7161@opencsw.org> Message-ID: On Tue, Mar 23, 2010 at 2:07 AM, Dagobert Michelsen wrote: > Hi Phil, > > Am 22.03.2010 um 22:23 schrieb Philip Brown: >> >> On Mon, Mar 22, 2010 at 1:47 PM, Dagobert Michelsen >> wrote: >>> >>> This sucks as it is in direct opposition to sparse zones. >> >> Could you remind us as to how, please? > > Sparse-Zones: Must keep configuration in /etc/opt/csw, must not modify > /opt/csw/etc > NFS-Shared: Must keep configuration in /opt/csw/etc, /etc/opt/csw ingored I think you both overstate, and understate, in BOTH cases. For example, BOTH installation types technically have the "must not modify /opt/csw/etc" restriction to the same degree. Yet both have essentially the same leewway, in that usually global admin can in each case, tweak a config file in /opt/csw/etc, either on "the NFS server", or "the global zone". Additionally, there are sub-cases for "sparse zones", and configuration preferences for an admin will be different across these cases. Perhaps for future reference, you might put the section I am about to write, in a wiki page somewhere, and expand on it as needed: NFS-shared: Can have "global" configuration in /opt/csw/etc. MAY pay attention to /etc/opt/csw, for machine-local override configuration Sparse zones: case 1: Multiple quasi-identical zones on a machine, where zones are separated solely for purposes of resource management. All packages added at global zone only. sparse "root", and sparse "/opt/csw" Admins will prefer to do all configuration on the global zone. configuration then PREFERRED to be "global" in /opt/csw/etc, as per NFS-shared. case 2: sparse "root", but local /opt/csw. Zones can be considered as almost completely separate hosts for our purposes, with the one exception of /usr/sadm/install/scripts. Doesnt matter whether config is in either directory in theory. case 3: similar to case 2, but administrator is only a "child zone" administrator, and has little to no control over the global zone. case 4: similar to #1: sparse root AND sparse /opt/csw, but each zone may or may not have individual per-zone tweaks to config, in which case, /etc/opt/csw will be used heavily. How about (as Secretary of the organization :) you start a poll to ask people who used zones, which configuration they tend to use? Without that data, I dont think we can accurately make assumptions about "(This) is more useful to our customers than (that)" From phil at bolthole.com Tue Mar 23 16:56:36 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 23 Mar 2010 08:56:36 -0700 Subject: [csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw In-Reply-To: References: <740D4C44-60A7-4734-9180-C4F3FBECAD3B@opencsw.org> <20100317.18120300.680051978@gyor.oxdrove.co.uk> Message-ID: An additional after-thought: On Mon, Mar 22, 2010 at 1:47 PM, Dagobert Michelsen wrote: > >> that may be one way to do it. However, It "feels" to me, to be better >> to be more consistent about the user-touching implementation. >> By that I mean, it might be nice if possible to consistently have the >> symlink be 'directly' to the target, whether NFS shared or otherwise. > > Alternatives just doesn't work this way and I don't have time to > modify the behaviour correctly in the code. > Ya know... this is supposed to be an "Open" organization.... How about you refer our customer to the code, reference my email suggestions here, and say to him, "sorry I dont have much time, but if you would like to fix the code so that it works this other way instead, that would be acceptible". From dam at opencsw.org Tue Mar 23 17:06:00 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 23 Mar 2010 17:06:00 +0100 Subject: [csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw In-Reply-To: References: <740D4C44-60A7-4734-9180-C4F3FBECAD3B@opencsw.org> <20100317.18120300.680051978@gyor.oxdrove.co.uk> Message-ID: <220FC52D-E6E6-4913-B777-DFA612C06124@opencsw.org> Hi Phil, Am 23.03.2010 um 16:56 schrieb Philip Brown: > How about you refer our customer to the code, reference my email > suggestions here, and say to him, "sorry I dont have much time, but if > you would like to fix the code so that it works this other way > instead, that would be acceptible". I did exactly that: No feedback yet. Best regards -- Dago From bwalton at opencsw.org Tue Mar 23 17:11:54 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 23 Mar 2010 12:11:54 -0400 Subject: [csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw In-Reply-To: References: <740D4C44-60A7-4734-9180-C4F3FBECAD3B@opencsw.org> <20100317.18120300.680051978@gyor.oxdrove.co.uk> Message-ID: <1269360409-sup-6150@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue Mar 23 11:56:36 -0400 2010: > How about you refer our customer to the code, reference my email > suggestions here, and say to him, "sorry I dont have much time, but > if you would like to fix the code so that it works this other way > instead, that would be acceptible". Indicating that, of course, patches would need to be accepted upstream so they're not a constant burden on us going forward? I also don't think the current implementation is actually broken, btw. It may be broken wrt to running it in conjunction with NFS shared directories and zones, but in Linux-land (where it originated), this isn't a problem. (I've yet to see shared binaries on NFS in Linux...could happen, obviously, but I don't think it's common.) Having everything 'bounced' through a single alternatives/ directory gives a nice place to see where _all_ alternatives are pointing. HTH -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Tue Mar 23 17:33:22 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 23 Mar 2010 09:33:22 -0700 Subject: [csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw In-Reply-To: <1269360409-sup-6150@pinkfloyd.chass.utoronto.ca> References: <740D4C44-60A7-4734-9180-C4F3FBECAD3B@opencsw.org> <20100317.18120300.680051978@gyor.oxdrove.co.uk> <1269360409-sup-6150@pinkfloyd.chass.utoronto.ca> Message-ID: On Tue, Mar 23, 2010 at 9:11 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Tue Mar 23 11:56:36 -0400 2010: > >> How about you refer our customer to the code, reference my email >> suggestions here, and say to him, "sorry I dont have much time, but >> if you would like to fix the code so that it works this other way >> instead, that would be acceptible". > > Indicating that, of course, patches would need to be accepted upstream > so they're not a constant burden on us going forward? Why would we need to ever "upgrade" from upstream? We grabbed the code because the current code, meets our current needs. We do not have a need to "track upstream" with it. (just as we grabbed GAR. we dont "track upstream" with that. just the opposite) We have what we need. We can consider what we have a "fork", if we wish. There is no "going forward" burden. > I also don't think the current implementation is actually broken, > btw. ?It may be broken wrt to running it in conjunction with NFS > shared directories and zones,... What you seem to be saying is, "well, it works for my purposes, so I reject your notion of a bug, even though I know exactly what you're saying and can reproduce the problem. I Just Dont Care. ". This is canonical "bad software writer behaviour", btw. It is clearly possible to fix this. It's just a matter of who is willing to spend the time to do so. Unfortunately, I do not have the time either :( To say "no time", is one thing. But to claim "not broken", is just not appropriate. > but in Linux-land (where it originated), > this isn't a problem. ?(I've yet to see shared binaries on NFS in > Linux...could happen, obviously, but I don't think it's common.) yeah, 'cause NFS on linux sux :) (or at least, it's legendary for it) > Having everything 'bounced' through a single alternatives/ directory > gives a nice place to see where _all_ alternatives are pointing. You still get that "feature", if you simply save the information in another form there. Heck, I woiuld guess you could save it in the SAME form! Keep the links in /etc/opt/csw/blah exactly the way they are now. but link the actual usable path to the same place. ie: ln -s /opt/csw/bin/myfave /etc/opt/csw/alternatives/whatever/opt/csw/bin/editor ln -s /opt/csw/bin/myfave /opt/csw/bin/editor From bwalton at opencsw.org Tue Mar 23 19:17:03 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 23 Mar 2010 14:17:03 -0400 Subject: [csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw In-Reply-To: References: <740D4C44-60A7-4734-9180-C4F3FBECAD3B@opencsw.org> <20100317.18120300.680051978@gyor.oxdrove.co.uk> <1269360409-sup-6150@pinkfloyd.chass.utoronto.ca> Message-ID: <1269367768-sup-3364@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue Mar 23 12:33:22 -0400 2010: > Why would we need to ever "upgrade" from upstream? We grabbed the > code because the current code, meets our current needs. We do not > have a need to "track upstream" with it. (just as we grabbed > GAR. we dont "track upstream" with that. just the opposite) If it's a globally useful feature addition, we'd be "jerks" for not sharing it back. If the addition of this support wouldn't negatively impact the original design environment, then I don't see a reason not to give back[1]. Since it's code taken from a GPL project, any published changes would need to be made available in source form. It would be _less_ burden on us to have it rolled in upstream, since they're already shouldering that load. ... I guess in my OP, I used the wrong wording. I was simply trying to state that in the environment for which the system was designed, the current implementation makes sense. It simply lacks support for working cleanly in this new environment where things happen that were never part of the original design spec. It a lacking feature, not a bug. -Ben [1] Speaking as if I were implementing the changes, which I'm in no way volunteering to do. -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Tue Mar 23 20:59:33 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 23 Mar 2010 12:59:33 -0700 Subject: [csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw In-Reply-To: <1269367768-sup-3364@pinkfloyd.chass.utoronto.ca> References: <740D4C44-60A7-4734-9180-C4F3FBECAD3B@opencsw.org> <1269360409-sup-6150@pinkfloyd.chass.utoronto.ca> <1269367768-sup-3364@pinkfloyd.chass.utoronto.ca> Message-ID: On Tue, Mar 23, 2010 at 11:17 AM, Ben Walton wrote: > Excerpts from Philip Brown's message of Tue Mar 23 12:33:22 -0400 2010: > >> Why would we need to ever "upgrade" from upstream? We grabbed the >> code because the current code, meets our current needs. We do not >> have a need to "track upstream" with it. ?(just as we grabbed >> GAR. we dont "track upstream" with that. just the opposite) > > If it's a globally useful feature addition, we'd be "jerks" for not > sharing it back. ?If the addition of this support wouldn't negatively > impact the original design environment, then I don't see a reason not > to give back[1]. oh sure, me neither. I'm only differing on whether we care if they update THEIR end or not :) > Since it's code taken from a GPL project, any published changes would > need to be made available in source form. ?It would be _less_ burden > on us to have it rolled in upstream, since they're already shouldering > that load. Although really, it seems like such a relatively small set of functionality that we actually care about, that we'd probably be better just tossing it and doing our own implementation in a system-normal-shell script. already, a good chunk of what we care about in it, is in "our own code", by virtue of the class action script wrappers. What is most useful to us, would be that we match the common user interface api, rather than copying the backend implementation. From maciej at opencsw.org Tue Mar 23 21:27:42 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 23 Mar 2010 20:27:42 +0000 Subject: [csw-maintainers] Runpath menagerie for review Message-ID: I've collected all the runpath entries from all the binaries from all the packages. Here's a list. I'm guessing that at least some of the runpath entries are incorrect. For instance, /opt/csw/lib/mysql. Binaries should never look there, because there is no "the" mysql. I would like to kindly ask the Elders to review the list below and identify rpath entries that are erroneous, so I can create a check detecting them. set(['', '$ORIGIN', '$ORIGIN/..', '$ORIGIN/../../../usr/lib/v9', '$ORIGIN/../../usr/lib', '$ORIGIN/../lib', '$ORIGIN/../ure-link/lib', '../../../../../dist/bin', '../../../../dist/bin', '../../../dist/bin', '../../dist/bin', '/bin', '/export/home/buysse/build/expect-5.42.1/cswstage/opt/csw/lib', '/export/home/phil/build/gettext-0.14.1/gettext-tools/intl/.libs', '/export/medusa/kenmays/build/qt-x11-free-3.3.3/lib', '/export/medusa/kenmays/build/s_qt/qt-x11-free-3.3.3/lib', '/export/medusa/kenmays/build/sparc_qt/qt-x11-free-3.3.4/lib', '/export/medusa/kenmays/build/sparc_qt/qt-x11-free-3.3.4/plugins/designer', '/export/medusa/kenmays/build/sparc_qt/qt-x11-free-3.3.4/plugins/sqldrivers', '/home/harpchad/local/sparc/lib', '/lib', '/lib/sparcv9', '/opt/SUNWcluster/lib', '/opt/SUNWmlib/lib', '/opt/SUNWspro/lib', '/opt/SUNWspro/lib/rw7', '/opt/SUNWspro/lib/stlport4', '/opt/SUNWspro/lib/v8', '/opt/SUNWspro/lib/v8plus', '/opt/SUNWspro/lib/v8plusa', '/opt/SUNWspro/lib/v8plusb', '/opt/SUNWspro/lib/v9', '/opt/build/michael/synce-0.8.9-buildroot/opt/csw/lib', '/opt/csw/$ISALIST', '/opt/csw//lib', '/opt/csw/X11/lib', '/opt/csw/X11/lib/', '/opt/csw/X11/lib/$ISALIST', '/opt/csw/X11/lib/64', '/opt/csw/apache2/lib', '/opt/csw/apache2/lib/$ISALIST', '/opt/csw/bdb33/lib', '/opt/csw/bdb33/lib/$ISALIST', '/opt/csw/bdb4/lib', '/opt/csw/bdb4/lib/', '/opt/csw/bdb4/lib/$ISALIST', '/opt/csw/bdb42/lib', '/opt/csw/bdb42/lib/$ISALIST', '/opt/csw/bdb42/lib/64', '/opt/csw/bdb43/lib', '/opt/csw/bdb43/lib/$ISALIST', '/opt/csw/bdb43/lib/64', '/opt/csw/bdb44/lib', '/opt/csw/bdb44/lib/$ISALIST', '/opt/csw/bdb44/lib/64', '/opt/csw/bdb47/lib', '/opt/csw/bdb47/lib/$ISALIST', '/opt/csw/bdb47/lib/64', '/opt/csw/bdb48/lib', '/opt/csw/bdb48/lib/$ISALIST', '/opt/csw/bdb48/lib/64', '/opt/csw/gcc3/lib', '/opt/csw/gcc3/lib/$ISALIST', '/opt/csw/gcc3/lib/.', '/opt/csw/gcc3/lib/sparcv9', '/opt/csw/gcc4/lib', '/opt/csw/gcc4/lib/$ISALIST', '/opt/csw/gcc4/lib/64', '/opt/csw/gcc4/lib/gcj-4.3.3-9', '/opt/csw/gcc4/lib/sparcv9', '/opt/csw/kde-gcc/lib', '/opt/csw/kde-gcc/lib/kde3', '/opt/csw/kde/lib', '/opt/csw/lib', '/opt/csw/lib/', '/opt/csw/lib/$', '/opt/csw/lib/$$ISALIST', '/opt/csw/lib/$ISALIST', '/opt/csw/lib/$ISALIST/ogle', '/opt/csw/lib/-R/opt/csw/lib', '/opt/csw/lib/.', '/opt/csw/lib/32', '/opt/csw/lib/64', '/opt/csw/lib/SALIST', '/opt/csw/lib/X11', '/opt/csw/lib/\\$ISALIST', '/opt/csw/lib/\\SALIST', '/opt/csw/lib/amanda', '/opt/csw/lib/courier-authlib', '/opt/csw/lib/dia', '/opt/csw/lib/evolution/1.4', '/opt/csw/lib/evolution/2.2', '/opt/csw/lib/evolution/2.6', '/opt/csw/lib/evolution/2.8', '/opt/csw/lib/evolution/2.8/components', '/opt/csw/lib/evolution/nss/lib', '/opt/csw/lib/gnopernicus-1.0', '/opt/csw/lib/gnucash', '/opt/csw/lib/graphviz', '/opt/csw/lib/htdig', '/opt/csw/lib/htdig_db', '/opt/csw/lib/lib', '/opt/csw/lib/libsunmath.so', '/opt/csw/lib/mozilla', '/opt/csw/lib/mysql', '/opt/csw/lib/octave-3.0.0', '/opt/csw/lib/ogle', '/opt/csw/lib/perl/5.8.8/CORE', '/opt/csw/lib/purple-2', '/opt/csw/lib/sasl2', '/opt/csw/lib/sparcv8', '/opt/csw/lib/sparcv8plus', '/opt/csw/lib/sparcv8plus+vis', '/opt/csw/lib/sparcv9', '/opt/csw/lib/svn', '/opt/csw/lib/xfce4/modules', '/opt/csw/libexec/firefox/lib/firefox-1.5.0.6', '/opt/csw/libexec/firefox/lib/firefox-1.5.0.7', '/opt/csw/mozilla/firefox/lib', '/opt/csw/mozilla/thunderbird/lib', '/opt/csw/mysql4//lib/mysql', '/opt/csw/mysql4/lib/mysql', '/opt/csw/mysql4/lib/mysql/$ISALIST', '/opt/csw/mysql4/lib/mysql/sparcv9', '/opt/csw/mysql5/lib', '/opt/csw/mysql5/lib/$ISALIST', '/opt/csw/mysql5/lib/$ISALIST/mysql', '/opt/csw/mysql5/lib/64', '/opt/csw/mysql5/lib/64/$ISALIST/mysql', '/opt/csw/mysql5/lib/64/mysql', '/opt/csw/mysql5/lib/mysql', '/opt/csw/mysql5/lib/mysql/$ISALIST', '/opt/csw/nagios/lib', '/opt/csw/nagios/lib/\\$ISALIST', '/opt/csw/openoffice.org/basis3.1/program', '/opt/csw/openoffice.org/ure/lib', '/opt/csw/postgresql/lib', '/opt/csw/postgresql/lib/$ISALIST', '/opt/csw/postgresql/lib/sparcv9', '/opt/csw/ssl/lib', '/opt/cw/gcc3/lib', '/opt/forte8/SUNWspro/lib', '/opt/forte8/SUNWspro/lib/rw7', '/opt/forte8/SUNWspro/lib/rw7/v9', '/opt/forte8/SUNWspro/lib/v8', '/opt/forte8/SUNWspro/lib/v9', '/opt/schily/lib', '/opt/sfw/lib', '/opt/studio/SOS10/SUNWspro/lib', '/opt/studio/SOS10/SUNWspro/lib/rw7', '/opt/studio/SOS10/SUNWspro/lib/v8', '/opt/studio/SOS10/SUNWspro/lib/v8plus', '/opt/studio/SOS11/SUNWspro/lib', '/opt/studio/SOS11/SUNWspro/lib/rw7', '/opt/studio/SOS11/SUNWspro/lib/rw7/v9', '/opt/studio/SOS11/SUNWspro/lib/stlport4', '/opt/studio/SOS11/SUNWspro/lib/stlport4/v9', '/opt/studio/SOS11/SUNWspro/lib/v8', '/opt/studio/SOS11/SUNWspro/lib/v8plus', '/opt/studio/SOS11/SUNWspro/lib/v9', '/opt/studio/SOS8/SUNWspro/lib', '/opt/studio/SOS8/SUNWspro/lib/rw7', '/opt/studio/SOS8/SUNWspro/lib/rw7/v9', '/opt/studio/SOS8/SUNWspro/lib/v8', '/opt/studio/SOS8/SUNWspro/lib/v8plusa', '/opt/studio/SOS8/SUNWspro/lib/v9', '/opt/studio10/SUNWspro/lib', '/opt/studio10/SUNWspro/lib/rw7', '/opt/studio10/SUNWspro/lib/rw7/v9', '/opt/studio10/SUNWspro/lib/stlport4', '/opt/studio10/SUNWspro/lib/stlport4/v9', '/opt/studio10/SUNWspro/lib/v8', '/opt/studio10/SUNWspro/lib/v9', '/oracle/product/9.2.0/lib32', '/usr/X/lib', '/usr/ccs/lib', '/usr/ccs/lib/sparcv9', '/usr/dt/lib', '/usr/lib', '/usr/lib/sparcv9', '/usr/local/lib', '/usr/local/openldap-2.3/lib', '/usr/openwin/lib', '/usr/sfw/lib', '/usr/ucblib', '/usr/xpg4/lib', 'RIGIN/../lib']) From bonivart at opencsw.org Tue Mar 23 22:14:38 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 23 Mar 2010 22:14:38 +0100 Subject: [csw-maintainers] Runpath menagerie for review In-Reply-To: References: Message-ID: <625385e31003231414v7ff483c0x499814bb6e84ca3f@mail.gmail.com> On Tue, Mar 23, 2010 at 9:27 PM, Maciej (Matchek) Blizinski wrote: > '/export/home/buysse/build/expect-5.42.1/cswstage/opt/csw/lib', > ? ? '/export/home/phil/build/gettext-0.14.1/gettext-tools/intl/.libs', > ? ? '/export/medusa/kenmays/build/qt-x11-free-3.3.3/lib', > ? ? '/export/medusa/kenmays/build/s_qt/qt-x11-free-3.3.3/lib', > ? ? '/export/medusa/kenmays/build/sparc_qt/qt-x11-free-3.3.4/lib', > ? ? '/export/medusa/kenmays/build/sparc_qt/qt-x11-free-3.3.4/plugins/designer', > ? ? '/export/medusa/kenmays/build/sparc_qt/qt-x11-free-3.3.4/plugins/sqldrivers', > ? ? '/home/harpchad/local/sparc/lib', This was previously caught as "build machine paths" or something similar. -- /peter From william at wbonnet.net Tue Mar 23 22:25:31 2010 From: william at wbonnet.net (William Bonnet) Date: Tue, 23 Mar 2010 22:25:31 +0100 Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: <908A3B6E-FCB1-452F-9C9D-2C1D8F4DA904@opencsw.org> References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> <908A3B6E-FCB1-452F-9C9D-2C1D8F4DA904@opencsw.org> Message-ID: <4BA931CB.4050000@wbonnet.net> Hi First of all sorry for being offline a few days when this topic was hot... >>> So we don't provide newer versions which allow 3d acceleration? >> >> well, the question is.. HOW do we do that? >> >> Dago, you are the person who provided our current gtk2 libs. >> >> Do you wish to go back,and redo it, and all its dependencies, to see >> if it can be made to work on sun X11 after all? :-} > > I'm pretty sure it can. However, before doing so I would like to hear > some > feedback from William what he thinks about it. Well i don't really define myself as a X11 expert ;) but i have to say that i am one of the very first to have pushed for a X11 update. This choice was motivated by the fact that most of the recent applications ( like FF3 and newer 3.5 3.6, of TB 3, etc.) do not compile against older version of X11. I do fully agree that pushing this out was maybe done too fast, and this is my fault. It also lights out that we should really set up non regression test, to prevent from this kind of situation. Today my mind is really shared. I'm afraid that we have to face a situation which is choosing between two answers : A. Stick to current X11 version, and accept to stick to old versions of software B. Upgrade to latest X11, got up to date versions of software and definitely drop older version of Solaris OS This is a binary decision, but unfortunately this is the real situation. I spent so many hours trying to make FF and TB working on solaris 8 that i should speak of days or weeks instead of hours... IMHO, Solaris 10 is no longer the future. It is today. And soon it will be the past... I see no real reason to stick to older version if being compliant to this version are blocking us. cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From phil at bolthole.com Tue Mar 23 22:25:49 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 23 Mar 2010 14:25:49 -0700 Subject: [csw-maintainers] Runpath menagerie for review In-Reply-To: References: Message-ID: On Tue, Mar 23, 2010 at 1:27 PM, Maciej (Matchek) Blizinski wrote: > I would like to kindly ask the Elders to review the list below and > identify rpath entries that are erroneous, so I can create a check > detecting them. most of them are wrong :) anything with "dist", "home", /usr/sfw, /usr/local, is wrong stuff starting with /optcsw is mostly acceptible. /opt/studio and/opt/forte are artifacts of old environment. they "shouldnt" really be there. /opt/SUNWspro is sortof forgivable, since its the "proper" location, but we should probably really be using -xnorunpath to avoid that sort of stuffs and of course "RGIN/blah", is an artifact of bad quoting. ie: "wrong" :-} From maciej at opencsw.org Wed Mar 24 00:03:42 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 23 Mar 2010 23:03:42 +0000 Subject: [csw-maintainers] checkpkg update: new shared library checking code Message-ID: I've recently discovered a small glitch in the shared library checking code, started fixing it, and eventually realized that this part of code needs to be rewritten from scratch, so I rewrote it, reductive style. Change r9343 removes more code than it adds, it makes checkpkg run faster, and also use less memory. I'll post more details later. Notable improvements: checkpkg now tells, _why_ it suggests each dependency. For example: # CSWpysvn: # SUGGESTION: you may want to add some or all of the following as dependencies: # CSWgcc4corert, reasons: # - provides /opt/csw/gcc4/lib/libgcc_s.so.1 needed by opt/csw/lib/python/site-packages/pysvn/_pysvn_2_6.so RUNTIME_DEP_PKGS_CSWpysvn += CSWgcc4corert # CSWpython, reasons: # - found file(s) matching .*\.py$, e.g. '/opt/csw/lib/python/site-packages/pysvn/__init__.py' RUNTIME_DEP_PKGS_CSWpysvn += CSWpython # CSWsvn, reasons: # - provides /opt/csw/lib/svn/libsvn_client-1.so.0 needed by opt/csw/lib/python/site-packages/pysvn/_pysvn_2_6.so # - provides /opt/csw/lib/svn/libsvn_repos-1.so.0 needed by opt/csw/lib/python/site-packages/pysvn/_pysvn_2_6.so # - provides /opt/csw/lib/svn/libsvn_diff-1.so.0 needed by opt/csw/lib/python/site-packages/pysvn/_pysvn_2_6.so RUNTIME_DEP_PKGS_CSWpysvn += CSWsvn Now, if you read the output, you'll learn that checkpkg thinks that CSWpython should be added as a dependency, because a .py file has been found. I hope that the improved diagnostics will make it easier for you to manage dependencies. As always, please contact me in case of any problems with checkpkg. From bwalton at opencsw.org Wed Mar 24 00:45:54 2010 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 23 Mar 2010 19:45:54 -0400 Subject: [csw-maintainers] A problem with subversion client In-Reply-To: References: Message-ID: <1269387817-sup-5898@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Mon Mar 22 11:49:33 -0400 2010: > My Subversion client seems to be generated patches with wrong numbers > on the buildfarm. When I create a patch with 'svn diff', it should > apply back with no offsets, right? Please look at this: I'm seeing the log oddities again. Working on the buildfarm (build9*) last night, I commited r9329 and r9330 to ruby19. svn log today doesn't show that history although the working tree does represent the correct state. svn status shows a clean working tree. Next, I ran svn update. It pulled in several of Maciej's GAR changes, but didn't do anything to 'my' working files. The log history is now correct again. Boo svn. Something is definitely wonky here. Anyone else seeing this or have ideas? -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From hson at opencsw.org Wed Mar 24 05:18:48 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Wed, 24 Mar 2010 05:18:48 +0100 Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: <04879D62-7F0F-4781-A6EA-7D0AD27091BB@opencsw.org> References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> <4BA68E7A.9000605@opencsw.org> <1269207173-sup-988@pinkfloyd.chass.utoronto.ca> <04879D62-7F0F-4781-A6EA-7D0AD27091BB@opencsw.org> Message-ID: <4BA992A8.902@opencsw.org> On 2010-03-22 20:56, Dagobert Michelsen wrote: > IMHO we should support Solaris 9 as long as it is supported by Sun, > that means it has not entered Vintage Phase II. This is 30. October 2011. Exactly, but we should announce it so our users know it since we have been supporting Solaris 8 much longer than its Phase 2 date, so they don't expect us to do the same for Solaris 9 > OTOH there are virtually no downloads for Solaris 9 any more if you look > at the download stats. URL? From pfelecan at opencsw.org Wed Mar 24 10:26:19 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 24 Mar 2010 10:26:19 +0100 Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: <4BA931CB.4050000@wbonnet.net> (William Bonnet's message of "Tue, 23 Mar 2010 22:25:31 +0100") References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> <908A3B6E-FCB1-452F-9C9D-2C1D8F4DA904@opencsw.org> <4BA931CB.4050000@wbonnet.net> Message-ID: William Bonnet writes: > Hi > > First of all sorry for being offline a few days when this topic was hot... >>>> So we don't provide newer versions which allow 3d acceleration? >>> >>> well, the question is.. HOW do we do that? >>> >>> Dago, you are the person who provided our current gtk2 libs. >>> >>> Do you wish to go back,and redo it, and all its dependencies, to see >>> if it can be made to work on sun X11 after all? :-} >> >> I'm pretty sure it can. However, before doing so I would like to >> hear some >> feedback from William what he thinks about it. > > Well i don't really define myself as a X11 expert ;) but i have to say > that i am one of the very first to have pushed for a X11 update. This > choice was motivated by the fact that most of the recent applications > ( like FF3 and newer 3.5 3.6, of TB 3, etc.) do not compile against > older version of X11. > > I do fully agree that pushing this out was maybe done too fast, and > this is my fault. It also lights out that we should really set up non > regression test, to prevent from this kind of situation. > > Today my mind is really shared. I'm afraid that we have to face a > situation which is choosing between two answers : > > A. Stick to current X11 version, and accept to stick to old versions > of software > B. Upgrade to latest X11, got up to date versions of software and > definitely drop older version of Solaris OS > > This is a binary decision, but unfortunately this is the real > situation. I spent so many hours trying to make FF and TB working on > solaris 8 that i should speak of days or weeks instead of hours... > > IMHO, Solaris 10 is no longer the future. It is today. And soon it > will be the past... I see no real reason to stick to older version if > being compliant to this version are blocking us. Well, this bring us to the same decision, discussed in another thread: to abandon Solaris 8 and, if it seems that the X11 version supplied with it is not satisfactory, abandon Solaris 9 also. When will the board organize a real vote on this? Or are we a bunch of masochists? Procrastinating on this issue is not to the benefit of our project. And, please, please, don't bring up, again, the theme of an hypothetical stable release! I'm not anymore an agnostic but an unbeliever of this myth. -- Peter From dam at opencsw.org Wed Mar 24 10:31:44 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 24 Mar 2010 10:31:44 +0100 Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: <4BA992A8.902@opencsw.org> References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> <4BA68E7A.9000605@opencsw.org> <1269207173-sup-988@pinkfloyd.chass.utoronto.ca> <04879D62-7F0F-4781-A6EA-7D0AD27091BB@opencsw.org> <4BA992A8.902@opencsw.org> Message-ID: <80A9955A-93E2-4997-8EC1-B598B783C6F9@opencsw.org> Hi Roger, Am 24.03.2010 um 05:18 schrieb Roger H?kansson: > On 2010-03-22 20:56, Dagobert Michelsen wrote: >> IMHO we should support Solaris 9 as long as it is supported by Sun, >> that means it has not entered Vintage Phase II. This is 30. October >> 2011. > > Exactly, but we should announce it so our users know it since we > have been supporting Solaris 8 much longer than its Phase 2 date, so > they don't expect us to do the same for Solaris 9 > >> OTOH there are virtually no downloads for Solaris 9 any more if you >> look >> at the download stats. > > URL? Last I looked they were at the location described here: under "Download Statistics", but obivously they are now somewhere else as OpenCSW has been moved from www.* to mirror.* Phil: Do you know where the current stats are? Best regards -- Dago From dam at opencsw.org Wed Mar 24 10:51:32 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 24 Mar 2010 10:51:32 +0100 Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: <4BA931CB.4050000@wbonnet.net> References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> <908A3B6E-FCB1-452F-9C9D-2C1D8F4DA904@opencsw.org> <4BA931CB.4050000@wbonnet.net> Message-ID: <50A2EF97-1EFD-421B-AA37-11A36814649B@opencsw.org> Hi William, Am 23.03.2010 um 22:25 schrieb William Bonnet: > Today my mind is really shared. I'm afraid that we have to face a > situation which is choosing between two answers : > > A. Stick to current X11 version, and accept to stick to old versions > of software > B. Upgrade to latest X11, got up to date versions of software and > definitely drop older version of Solaris OS > > This is a binary decision, but unfortunately this is the real > situation. I spent so many hours trying to make FF and TB working on > solaris 8 that i should speak of days or weeks instead of hours... > > IMHO, Solaris 10 is no longer the future. It is today. And soon it > will be the past... I see no real reason to stick to older version > if being compliant to this version are blocking us. As I understand it that means also (A) get 3D acceleration (B) stick with software rendering so the price for being current would be quite high. Do you see a way of updating to current X11 with 3d acceleration? Best regards -- Dago From dam at opencsw.org Wed Mar 24 11:00:52 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 24 Mar 2010 11:00:52 +0100 Subject: [csw-maintainers] Runpath menagerie for review In-Reply-To: References: Message-ID: <75B65782-98D3-4669-9992-39C0F041921B@opencsw.org> Hi, Am 23.03.2010 um 22:25 schrieb Philip Brown: > On Tue, Mar 23, 2010 at 1:27 PM, Maciej (Matchek) Blizinski > wrote: > >> I would like to kindly ask the Elders to review the list below and >> identify rpath entries that are erroneous, so I can create a check >> detecting them. > > most of them are wrong :) Yes. I suggest using a whitelist of allowed pathes, which can then be extended if necessary. > /opt/studio and/opt/forte are artifacts of old environment. they > "shouldnt" really be there. > /opt/SUNWspro is sortof forgivable, since its the "proper" location, > but we should probably really be using -xnorunpath to avoid that sort > of stuffs This is for SOS12u1 only, earlier versions don't have that and in most cases it should not be necessary: > Normally cc does not pass any -R path to the linker. > There are a few options that do pass -R path to the > linker such as -xliclib=sunperf and -xopenmp. The > -xnorunpath option can be used to prevent this. Best regards -- Dago From bwalton at opencsw.org Wed Mar 24 14:56:07 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 24 Mar 2010 09:56:07 -0400 Subject: [csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw In-Reply-To: References: <740D4C44-60A7-4734-9180-C4F3FBECAD3B@opencsw.org> <1269360409-sup-6150@pinkfloyd.chass.utoronto.ca> <1269367768-sup-3364@pinkfloyd.chass.utoronto.ca> Message-ID: <1269438807-sup-5650@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Tue Mar 23 15:59:33 -0400 2010: > oh sure, me neither. I'm only differing on whether we care if they > update THEIR end or not :) Well, we should care, I think, since if not we're responsible for ensuring the modified source remains available...this could be offloaded to sourceforge, etc, but I'm not sure we want a _real_ fork. It's convoluted due to the fact that the upstream package is chkconfig which includes other tools for RHEL-based distros in addition to the alternatives bit. > Although really, it seems like such a relatively small set of > functionality that we actually care about, that we'd probably be > better just tossing it and doing our own implementation in a > system-normal-shell script. already, a good chunk of what we care > about in it, is in "our own code", by virtue of the class action > script wrappers. While that may be, somebody still has to actually care enough to do it. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Wed Mar 24 15:14:51 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 24 Mar 2010 15:14:51 +0100 Subject: [csw-maintainers] Raised default build of GAR to Solaris 9 Message-ID: <16FE28C4-590F-44DE-9B94-00D327DE5381@opencsw.org> Hi, the default build hosts have been changed in GAR and the default Sun compiler have been adjusted in gar.conf.mk to Default build hosts: Solaris 9 Default Sun compiler: Sun Studio 12 Please update your repository accordingly. Best regards -- Dago From skayser at opencsw.org Wed Mar 24 16:03:27 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 24 Mar 2010 16:03:27 +0100 Subject: [csw-maintainers] Inconsistencies between /packages DB and catalog contents? Message-ID: <20100324150327.GK27943@sebastiankayser.de> Hi, just wondering: what is the current procedure for releasing packages WRT to our mirrors? pidgin 2.6.6 was registered with our packages database yesterday. I happily saw this and wanted to update it today, but my catalog still carries the old version (2.5.8). How can one verify whether there's a problem on our side or on the mirrors? The mirror status page [1] tells me, my mirror is up to date, but gives a date of 2010-03-22 23:27. Is this for the catalog? Does this mean new packages like pidgin were registered in our DB, were announced via our new packages feed, but somehow weren't registered in the catalog and/or pushed to the mirrors? What's our master mirror btw.? Enlightenment appreciated Sebastian From dam at opencsw.org Wed Mar 24 16:05:23 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 24 Mar 2010 16:05:23 +0100 Subject: [csw-maintainers] General buildfarm update References: <6DA53F54-076E-4C2C-B36B-252B3C678AEE@opencsw.org> Message-ID: Hi, as OpenCSW has officially decomissioned Solaris 8 I have changed the general machine layout. There are now two sets of machines: * current These servers run the current/ stack from OpenCSW and are suited to build releasable packages. The existing servers build8x, build9x and build10x have been replaced by VMs, whereas the most noticable difference is that current8x had only one vCPU, whereas build8x had two CPUs. Available servers are - current8s, current8x - current9s, current9x - current10s, current10x - Soon: currentosols, currentosolx * testing These servers run various experimental packages from experimental and are used either for testing/ or project-related releases. If releasable packages are to be produced extra care must be taken to stay in sync with current/. Available servers are - testing8s, testing8x - testing9s, testing9x - testing10s, testing10x - Soon: testingosols, testingosolx Please let me know at buildfarm at opencsw.org if you encounter anything strange. Best regards -- Dago From skayser at opencsw.org Wed Mar 24 16:06:47 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 24 Mar 2010 16:06:47 +0100 Subject: [csw-maintainers] Inconsistencies between /packages DB and catalog contents? In-Reply-To: <20100324150327.GK27943@sebastiankayser.de> References: <20100324150327.GK27943@sebastiankayser.de> Message-ID: <20100324150647.GL27943@sebastiankayser.de> * Sebastian Kayser wrote: > just wondering: what is the current procedure for releasing packages WRT > to our mirrors? pidgin 2.6.6 was registered with our packages database > yesterday. I happily saw this and wanted to update it today, but my > catalog still carries the old version (2.5.8). > > How can one verify whether there's a problem on our side or on the > mirrors? The mirror status page [1] tells me, my mirror is up to date, > but gives a date of 2010-03-22 23:27. Is this for the catalog? Does this > mean new packages like pidgin were registered in our DB, were announced > via our new packages feed, but somehow weren't registered in the catalog > and/or pushed to the mirrors? What's our master mirror btw.? > > Enlightenment appreciated Adding the missing mirror status URL to the thread. Sebastian [1] http://www.canoedissent.org.uk/mirror/status/ From dam at opencsw.org Wed Mar 24 16:18:07 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 24 Mar 2010 16:18:07 +0100 Subject: [csw-maintainers] Inconsistencies between /packages DB and catalog contents? In-Reply-To: <20100324150647.GL27943@sebastiankayser.de> References: <20100324150327.GK27943@sebastiankayser.de> <20100324150647.GL27943@sebastiankayser.de> Message-ID: <4DB2F02E-F523-4A41-9266-27C806337599@opencsw.org> Hi Sebastian, Am 24.03.2010 um 16:06 schrieb Sebastian Kayser: > * Sebastian Kayser wrote: >> just wondering: what is the current procedure for releasing >> packages WRT >> to our mirrors? pidgin 2.6.6 was registered with our packages >> database >> yesterday. I happily saw this and wanted to update it today, but my >> catalog still carries the old version (2.5.8). >> >> How can one verify whether there's a problem on our side or on the >> mirrors? The mirror status page [1] tells me, my mirror is up to >> date, >> but gives a date of 2010-03-22 23:27. Is this for the catalog? Does >> this >> mean new packages like pidgin were registered in our DB, were >> announced >> via our new packages feed, but somehow weren't registered in the >> catalog >> and/or pushed to the mirrors? What's our master mirror btw.? >> >> Enlightenment appreciated This is due to the method Phil uses for registering packages. It is not atomic. It can take multiple days between Mantis and mirror sync. Best regards -- Dago From phil at bolthole.com Wed Mar 24 18:11:05 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 24 Mar 2010 10:11:05 -0700 Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: <4BA931CB.4050000@wbonnet.net> References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> <908A3B6E-FCB1-452F-9C9D-2C1D8F4DA904@opencsw.org> <4BA931CB.4050000@wbonnet.net> Message-ID: On Tue, Mar 23, 2010 at 2:25 PM, William Bonnet wrote: > Hi > > First of all sorry for being offline a few days when this topic was hot... > > Today my mind is really shared. I'm afraid that we have to face a situation > which is choosing between two answers : > > A. Stick to current X11 version, and accept to stick to old versions of > software > B. Upgrade to latest X11, got up to date versions of software and definitely > drop older version of Solaris OS > > This is a binary decision, but unfortunately this is the real situation. There is an apparent 3rd choice: back rev our gtk "half way", to 2.14, instead of the more ancient 2.12. This should let us compile firefox3 against it. > IMHO, Solaris 10 is no longer the future. It is today. I dont see how "Solaris 10" is relevant to the question of "what do we do about X11 libs?" The X11 lib questions and problems still remain, even if we change to only use solaris 10. In the interest of not drowning under a deluge of emails on this list, I would thus request that we attempt to focus on one issue at a time, and the most PRESSING one, is the X11 one. >From my understanding, moving to gtk2.14, gets us the best of all worlds: 1. reasonably modern gtk support, which means we should be able to compile most other recent apps too. (I THINK so, at any rate. but if you have hard proof to the contrary, please elucidate) 2. we still get to use sun's libX11.so.4 with it. Which means we'll still get hardware acceleration. Comments? From phil at bolthole.com Wed Mar 24 18:33:36 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 24 Mar 2010 10:33:36 -0700 Subject: [csw-maintainers] Runpath menagerie for review In-Reply-To: <75B65782-98D3-4669-9992-39C0F041921B@opencsw.org> References: <75B65782-98D3-4669-9992-39C0F041921B@opencsw.org> Message-ID: On Wed, Mar 24, 2010 at 3:00 AM, Dagobert Michelsen wrote: > Hi, >> but we should probably really be using -xnorunpath to avoid that sort >> of stuffs > > This is for SOS12u1 only, earlier versions don't have that err, what? yes they do. it's a longstanding "feature" of sun compilers. At least, the C++ compiler. Sometimes, the C compiler does too. all the way back since studio 7 or whatever. basically, if it decides to kick in the optimized math libs, is the common case. From phil at bolthole.com Wed Mar 24 18:34:55 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 24 Mar 2010 10:34:55 -0700 Subject: [csw-maintainers] Completely drop Solaris8? In-Reply-To: <80A9955A-93E2-4997-8EC1-B598B783C6F9@opencsw.org> References: <974B2D66-5D3B-4D5F-BD15-D1BA889EE1EF@opencsw.org> <4BA68E7A.9000605@opencsw.org> <1269207173-sup-988@pinkfloyd.chass.utoronto.ca> <04879D62-7F0F-4781-A6EA-7D0AD27091BB@opencsw.org> <4BA992A8.902@opencsw.org> <80A9955A-93E2-4997-8EC1-B598B783C6F9@opencsw.org> Message-ID: On Wed, Mar 24, 2010 at 2:31 AM, Dagobert Michelsen wrote: > > Last I looked they were at the location described here: > ? > under "Download Statistics", but obivously they are now somewhere else as > OpenCSW has been moved from www.* to mirror.* > > Phil: Do you know where the current stats are? > nope sorry From phil at bolthole.com Wed Mar 24 18:38:04 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 24 Mar 2010 10:38:04 -0700 Subject: [csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw In-Reply-To: <1269438807-sup-5650@pinkfloyd.chass.utoronto.ca> References: <740D4C44-60A7-4734-9180-C4F3FBECAD3B@opencsw.org> <1269360409-sup-6150@pinkfloyd.chass.utoronto.ca> <1269367768-sup-3364@pinkfloyd.chass.utoronto.ca> <1269438807-sup-5650@pinkfloyd.chass.utoronto.ca> Message-ID: On Wed, Mar 24, 2010 at 6:56 AM, Ben Walton wrote: > > It's convoluted due to the fact that the upstream package is chkconfig > which includes other tools for RHEL-based distros in addition to the > alternatives bit. > i'm not surprised. which is why I reiterate my suggestion that we should merely duplicate the user-level interface (and only the bits we actually care about), and thus avoid extra baggage. >> Although really, it seems like such a relatively small set of >> functionality that we actually care about, that we'd probably be >> better just tossing it and doing our own implementation in a >> system-normal-shell script. already, a good chunk of what we care >> about in it, is in "our own code", by virtue of the class action >> script wrappers. > > While that may be, somebody still has to actually care enough to do > it. > yah. and while I CARE about it, I dont have enough TIME to do it :( From bwalton at opencsw.org Wed Mar 24 18:44:22 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 24 Mar 2010 13:44:22 -0400 Subject: [csw-maintainers] Bugreport on alternatives with NFS-shared /opt/csw In-Reply-To: References: <740D4C44-60A7-4734-9180-C4F3FBECAD3B@opencsw.org> <1269360409-sup-6150@pinkfloyd.chass.utoronto.ca> <1269367768-sup-3364@pinkfloyd.chass.utoronto.ca> <1269438807-sup-5650@pinkfloyd.chass.utoronto.ca> Message-ID: <1269452532-sup-9950@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Wed Mar 24 13:38:04 -0400 2010: > i'm not surprised. which is why I reiterate my suggestion that we > should merely duplicate the user-level interface (and only the bits > we actually care about), and thus avoid extra baggage. But why reinvent the wheel? The wheel is already round and mostly works. With some tweaks, that as you say, should be acceptable upstream since they wouldn't harm the original environment, it'd be perfectly round for us too. NIH sucks...*I'm looking at you logadm* Anyway. Since I'm not going to do the work in either scenario, I'll be quiet now. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From james at opencsw.org Wed Mar 24 18:55:35 2010 From: james at opencsw.org (James Lee) Date: Wed, 24 Mar 2010 17:55:35 GMT Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: <4BA931CB.4050000@wbonnet.net> References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> <908A3B6E-FCB1-452F-9C9D-2C1D8F4DA904@opencsw.org> <4BA931CB.4050000@wbonnet.net> Message-ID: <20100324.17553500.1029190164@gyor.oxdrove.co.uk> On 23/03/10, 21:25:31, William Bonnet wrote regarding Re: [csw-maintainers] bad news on the CSW X11 front: > Today my mind is really shared. I'm afraid that we have to face a > situation which is choosing between two answers : > A. Stick to current X11 version, and accept to stick to old versions of > software > B. Upgrade to latest X11, got up to date versions of software and > definitely drop older version of Solaris OS The OS is another question. > This is a binary decision, but unfortunately this is the real situation. It's not binary: C. Provide X11R7 where needed. This is also (as well as OpenGL) important if we care that the state is broken during X11 updates. James. From james at opencsw.org Wed Mar 24 18:55:36 2010 From: james at opencsw.org (James Lee) Date: Wed, 24 Mar 2010 17:55:36 GMT Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> <908A3B6E-FCB1-452F-9C9D-2C1D8F4DA904@opencsw.org> <4BA931CB.4050000@wbonnet.net> Message-ID: <20100324.17553600.1947673963@gyor.oxdrove.co.uk> On 24/03/10, 09:26:19, Peter FELECAN wrote regarding Re: [csw-maintainers] bad news on the CSW X11 front: > Well, this bring us to the same decision, discussed in another thread: > to abandon Solaris 8 and, if it seems that the X11 version supplied with > it is not satisfactory, abandon Solaris 9 also. Not so fast, this topic (OpenGL) affects Solaris 10 too. > Procrastinating on this issue is not to the benefit of our project. And, > please, please, don't bring up, again, the theme of an hypothetical > stable release! I'm not anymore an agnostic but an unbeliever of this > myth. The irony of this is that it is stable and the desire to leave a Solaris 8 collection in a usable state that is being blocked by X11, so preventing moving on with grace. James. From dam at opencsw.org Wed Mar 24 11:52:58 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 24 Mar 2010 11:52:58 +0100 Subject: [csw-maintainers] [buildfarm-announce] Changes on login.opencsw.org References: Message-ID: <4827EAB2-A074-48CF-B345-2DEBFEC4929B@opencsw.org> Hi, first welcome to the OpenCSW buildfarm list! You have been automatically subscribed as you are a user of the OpenCSW buildfarm. This will be a low-volume list to announce changes, updates and downtimes at the OpenCSW buildfarm. The access via Sun Secure Global Desktop (X11 over Web) has been changed to another hostname/ip and ssh access has been enhanced to run also on port 443 to allow direct access via proxy tunneling. There is now the following configuration: login.opencsw.org Port 22 SSH login.opencsw.org Port 443 SSH sgd.opencsw.org Port 80 HTTP for SGD sgd.opencsw.org Port 443 HTTPS for SGD Access to SGD is not enabled by default. If you want to use it please contact buildfarm at opencsw.org Best regards -- Dago _______________________________________________ Buildfarm-announce mailing list Buildfarm-announce at opencsw.org http://lists.opencsw.org/mailman/listinfo/buildfarm-announce From dam at opencsw.org Wed Mar 24 16:02:56 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 24 Mar 2010 16:02:56 +0100 Subject: [csw-maintainers] [buildfarm-announce] General buildfarm update Message-ID: <6DA53F54-076E-4C2C-B36B-252B3C678AEE@opencsw.org> Hi, as OpenCSW has officially decomissioned Solaris 8 I have changed the general machine layout. There are now two sets of machines: * current These servers run the current/ stack from OpenCSW and are suited to build releasable packages. The existing servers build8x, build9x and build10x have been replaced by VMs, whereas the most noticable difference is that current8x had only one vCPU, whereas build8x had two CPUs. Available servers are - current8s, current8x - current9s, current9x - current10s, current10x - Soon: currentosols, currentosolx * testing These servers run various experimental packages from experimental and are used either for testing/ or project-related releases. If releasable packages are to be produced extra care must be taken to stay in sync with current/. Available servers are - testing8s, testing8x - testing9s, testing9x - testing10s, testing10x - Soon: testingosols, testingosolx Please let me know at buildfarm at opencsw.org if you encounter anything strange. Best regards -- Dago _______________________________________________ Buildfarm-announce mailing list Buildfarm-announce at opencsw.org http://lists.opencsw.org/mailman/listinfo/buildfarm-announce From dam at opencsw.org Wed Mar 24 21:50:05 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 24 Mar 2010 21:50:05 +0100 Subject: [csw-maintainers] Updating buildfarm now with Perl 5.10.1 Message-ID: <06B118F8-1E3E-4612-811C-2CF35881B9FE@opencsw.org> Hi, I am updating the Buildfarm now with Perl 5.10.1 and all corresponding modules :-D Please stand by! Best regards -- Dago From ihsan at opencsw.org Wed Mar 24 21:55:08 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 24 Mar 2010 21:55:08 +0100 Subject: [csw-maintainers] General buildfarm update In-Reply-To: References: <6DA53F54-076E-4C2C-B36B-252B3C678AEE@opencsw.org> Message-ID: <4BAA7C2C.4000501@opencsw.org> Am 24.03.10 16:05, schrieb Dagobert Michelsen: > as OpenCSW has officially decomissioned Solaris 8 I have changed > the general machine layout. There are now two sets of machines: We should announce this on the announce and users list. As well on twitter. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From pfelecan at opencsw.org Thu Mar 25 10:15:51 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 25 Mar 2010 10:15:51 +0100 Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: <20100324.17553600.1947673963@gyor.oxdrove.co.uk> (James Lee's message of "Wed, 24 Mar 2010 17:55:36 GMT") References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> <908A3B6E-FCB1-452F-9C9D-2C1D8F4DA904@opencsw.org> <4BA931CB.4050000@wbonnet.net> <20100324.17553600.1947673963@gyor.oxdrove.co.uk> Message-ID: James Lee writes: > On 24/03/10, 09:26:19, Peter FELECAN wrote regarding > Re: [csw-maintainers] bad news on the CSW X11 front: > >> Well, this bring us to the same decision, discussed in another thread: >> to abandon Solaris 8 and, if it seems that the X11 version supplied with >> it is not satisfactory, abandon Solaris 9 also. > > Not so fast, this topic (OpenGL) affects Solaris 10 too. It does not if we don't use our brew of X11. >> Procrastinating on this issue is not to the benefit of our project. And, >> please, please, don't bring up, again, the theme of an hypothetical >> stable release! I'm not anymore an agnostic but an unbeliever of this >> myth. > > The irony of this is that it is stable and the desire to leave a Solaris > 8 collection in a usable state that is being blocked by X11, so > preventing moving on with grace. Ironic or not this is stagnating since more than a year, isn't it? All of the above shows the incapacity of our project to make a decision. Drop that clunkers! -- Peter From maciej at opencsw.org Thu Mar 25 11:09:34 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 25 Mar 2010 10:09:34 +0000 Subject: [csw-maintainers] Runpath menagerie for review In-Reply-To: References: Message-ID: 2010/3/23 Philip Brown : > stuff starting with /optcsw is mostly acceptible. What about rpath orthography? Would you like checkpkg to throw errors on the following ones? '/opt/csw/lib/.' (as opposed to '/opt/csw/lib') '/opt/csw/X11/lib/' (as opposed to '/opt/csw/X11/lib') Next question: specific architecture entries, for instance: '/opt/csw/postgresql/lib/sparcv9' Shouldn't this be '/opt/csw/postgresql/lib/$ISALIST' instead? Next question: What about $ORIGIN? In some cases it makes, sense, for instance if a 32-bit binary looks into '$ORIGIN/../lib', I guess that's fine. But if it's a 64-bit binary in /opt/csw/bin/sparcv9 and the corresponding library is in /opt/csw/lib/sparcv9, the '$ORIGIN/../lib' entry won't help much. Current regex looks like this: RPATH_PARTS = { 'prefix': r"(?P/opt/csw)", 'prefix_extra': r"(?P(/(?!lib)[\w-]+)*)", 'subdirs': r"(?P(/(?!-R)[\w\-\.]+)*)", 'isalist': r"(?P/(\$ISALIST|64))", 'subdir2': r"(?P/[\w\-\.]+)", } RPATH_WHITELIST = [ ("^" "%(prefix)s" "%(prefix_extra)s" "/(lib|libexec)" "%(subdirs)s" "%(isalist)s?" "%(subdir2)s?" "$") % RPATH_PARTS ] Below are the current list of bad and good RPATH entries, please comment if there are entries that are not classified correctly. Bad rpath: '$ORIGIN' Bad rpath: '$ORIGIN/..' Bad rpath: '$ORIGIN/../../../usr/lib/v9' Bad rpath: '$ORIGIN/../../usr/lib' Bad rpath: '$ORIGIN/../lib' Bad rpath: '$ORIGIN/../ure-link/lib' Bad rpath: '../../../../../dist/bin' Bad rpath: '../../../../dist/bin' Bad rpath: '../../../dist/bin' Bad rpath: '../../dist/bin' Bad rpath: '/bin' Bad rpath: '/export/home/buysse/build/expect-5.42.1/cswstage/opt/csw/lib' Bad rpath: '/export/home/phil/build/gettext-0.14.1/gettext-tools/intl/.libs' Bad rpath: '/export/medusa/kenmays/build/qt-x11-free-3.3.3/lib' Bad rpath: '/export/medusa/kenmays/build/s_qt/qt-x11-free-3.3.3/lib' Bad rpath: '/export/medusa/kenmays/build/sparc_qt/qt-x11-free-3.3.4/lib' Bad rpath: '/export/medusa/kenmays/build/sparc_qt/qt-x11-free-3.3.4/plugins/designer' Bad rpath: '/export/medusa/kenmays/build/sparc_qt/qt-x11-free-3.3.4/plugins/sqldrivers' Bad rpath: '/home/harpchad/local/sparc/lib' Bad rpath: '/lib' Bad rpath: '/lib/sparcv9' Bad rpath: '/opt/SUNWcluster/lib' Bad rpath: '/opt/SUNWmlib/lib' Bad rpath: '/opt/SUNWspro/lib' Bad rpath: '/opt/SUNWspro/lib/rw7' Bad rpath: '/opt/SUNWspro/lib/stlport4' Bad rpath: '/opt/SUNWspro/lib/v8' Bad rpath: '/opt/SUNWspro/lib/v8plus' Bad rpath: '/opt/SUNWspro/lib/v8plusa' Bad rpath: '/opt/SUNWspro/lib/v8plusb' Bad rpath: '/opt/SUNWspro/lib/v9' Bad rpath: '/opt/build/michael/synce-0.8.9-buildroot/opt/csw/lib' Bad rpath: '/opt/csw/$ISALIST' Bad rpath: '/opt/csw//lib' Bad rpath: '/opt/csw/X11/lib/' Bad rpath: '/opt/csw/bdb4/lib/' Bad rpath: '/opt/csw/lib/' Bad rpath: '/opt/csw/lib/$' Bad rpath: '/opt/csw/lib/$$ISALIST' Bad rpath: '/opt/csw/lib/-R/opt/csw/lib' Bad rpath: '/opt/csw/lib/\\$ISALIST' Bad rpath: '/opt/csw/lib/\\SALIST' Bad rpath: '/opt/csw/lib/sparcv8plus+vis' Bad rpath: '/opt/csw/mysql4//lib/mysql' Bad rpath: '/opt/csw/nagios/lib/\\$ISALIST' Bad rpath: '/opt/csw/openoffice.org/basis3.1/program' Bad rpath: '/opt/csw/openoffice.org/ure/lib' Bad rpath: '/opt/cw/gcc3/lib' Bad rpath: '/opt/forte8/SUNWspro/lib' Bad rpath: '/opt/forte8/SUNWspro/lib/rw7' Bad rpath: '/opt/forte8/SUNWspro/lib/rw7/v9' Bad rpath: '/opt/forte8/SUNWspro/lib/v8' Bad rpath: '/opt/forte8/SUNWspro/lib/v9' Bad rpath: '/opt/schily/lib' Bad rpath: '/opt/sfw/lib' Bad rpath: '/opt/studio/SOS10/SUNWspro/lib' Bad rpath: '/opt/studio/SOS10/SUNWspro/lib/rw7' Bad rpath: '/opt/studio/SOS10/SUNWspro/lib/v8' Bad rpath: '/opt/studio/SOS10/SUNWspro/lib/v8plus' Bad rpath: '/opt/studio/SOS11/SUNWspro/lib' Bad rpath: '/opt/studio/SOS11/SUNWspro/lib/rw7' Bad rpath: '/opt/studio/SOS11/SUNWspro/lib/rw7/v9' Bad rpath: '/opt/studio/SOS11/SUNWspro/lib/stlport4' Bad rpath: '/opt/studio/SOS11/SUNWspro/lib/stlport4/v9' Bad rpath: '/opt/studio/SOS11/SUNWspro/lib/v8' Bad rpath: '/opt/studio/SOS11/SUNWspro/lib/v8plus' Bad rpath: '/opt/studio/SOS11/SUNWspro/lib/v9' Bad rpath: '/opt/studio/SOS8/SUNWspro/lib' Bad rpath: '/opt/studio/SOS8/SUNWspro/lib/rw7' Bad rpath: '/opt/studio/SOS8/SUNWspro/lib/rw7/v9' Bad rpath: '/opt/studio/SOS8/SUNWspro/lib/v8' Bad rpath: '/opt/studio/SOS8/SUNWspro/lib/v8plusa' Bad rpath: '/opt/studio/SOS8/SUNWspro/lib/v9' Bad rpath: '/opt/studio10/SUNWspro/lib' Bad rpath: '/opt/studio10/SUNWspro/lib/rw7' Bad rpath: '/opt/studio10/SUNWspro/lib/rw7/v9' Bad rpath: '/opt/studio10/SUNWspro/lib/stlport4' Bad rpath: '/opt/studio10/SUNWspro/lib/stlport4/v9' Bad rpath: '/opt/studio10/SUNWspro/lib/v8' Bad rpath: '/opt/studio10/SUNWspro/lib/v9' Bad rpath: '/oracle/product/9.2.0/lib32' Bad rpath: '/usr/X/lib' Bad rpath: '/usr/ccs/lib' Bad rpath: '/usr/ccs/lib/sparcv9' Bad rpath: '/usr/dt/lib' Bad rpath: '/usr/lib' Bad rpath: '/usr/lib/sparcv9' Bad rpath: '/usr/local/lib' Bad rpath: '/usr/local/openldap-2.3/lib' Bad rpath: '/usr/openwin/lib' Bad rpath: '/usr/sfw/lib' Bad rpath: '/usr/ucblib' Bad rpath: '/usr/xpg4/lib' Bad rpath: 'RIGIN/../lib' And the less interesting list of good RPATHs, with parsed tokens: Good rpath: '/opt/csw/X11/lib' {'prefix': '/opt/csw', 'prefix_extra': '/X11', 'subdir2': None, 'subdirs': '', 'isalist': None} Good rpath: '/opt/csw/X11/lib/$ISALIST' {'prefix': '/opt/csw', 'prefix_extra': '/X11', 'subdir2': None, 'subdirs': '', 'isalist': '/$ISALIST'} Good rpath: '/opt/csw/X11/lib/64' {'prefix': '/opt/csw', 'prefix_extra': '/X11', 'subdir2': None, 'subdirs': '/64', 'isalist': None} Good rpath: '/opt/csw/apache2/lib' {'prefix': '/opt/csw', 'prefix_extra': '/apache2', 'subdir2': None, 'subdirs': '', 'isalist': None} Good rpath: '/opt/csw/apache2/lib/$ISALIST' {'prefix': '/opt/csw', 'prefix_extra': '/apache2', 'subdir2': None, 'subdirs': '', 'isalist': '/$ISALIST'} Good rpath: '/opt/csw/bdb33/lib' {'prefix': '/opt/csw', 'prefix_extra': '/bdb33', 'subdir2': None, 'subdirs': '', 'isalist': None} Good rpath: '/opt/csw/bdb33/lib/$ISALIST' {'prefix': '/opt/csw', 'prefix_extra': '/bdb33', 'subdir2': None, 'subdirs': '', 'isalist': '/$ISALIST'} Good rpath: '/opt/csw/bdb4/lib' {'prefix': '/opt/csw', 'prefix_extra': '/bdb4', 'subdir2': None, 'subdirs': '', 'isalist': None} Good rpath: '/opt/csw/bdb4/lib/$ISALIST' {'prefix': '/opt/csw', 'prefix_extra': '/bdb4', 'subdir2': None, 'subdirs': '', 'isalist': '/$ISALIST'} Good rpath: '/opt/csw/bdb42/lib' {'prefix': '/opt/csw', 'prefix_extra': '/bdb42', 'subdir2': None, 'subdirs': '', 'isalist': None} Good rpath: '/opt/csw/bdb42/lib/$ISALIST' {'prefix': '/opt/csw', 'prefix_extra': '/bdb42', 'subdir2': None, 'subdirs': '', 'isalist': '/$ISALIST'} Good rpath: '/opt/csw/bdb42/lib/64' {'prefix': '/opt/csw', 'prefix_extra': '/bdb42', 'subdir2': None, 'subdirs': '/64', 'isalist': None} Good rpath: '/opt/csw/bdb43/lib' {'prefix': '/opt/csw', 'prefix_extra': '/bdb43', 'subdir2': None, 'subdirs': '', 'isalist': None} Good rpath: '/opt/csw/bdb43/lib/$ISALIST' {'prefix': '/opt/csw', 'prefix_extra': '/bdb43', 'subdir2': None, 'subdirs': '', 'isalist': '/$ISALIST'} Good rpath: '/opt/csw/bdb43/lib/64' {'prefix': '/opt/csw', 'prefix_extra': '/bdb43', 'subdir2': None, 'subdirs': '/64', 'isalist': None} Good rpath: '/opt/csw/bdb44/lib' {'prefix': '/opt/csw', 'prefix_extra': '/bdb44', 'subdir2': None, 'subdirs': '', 'isalist': None} Good rpath: '/opt/csw/bdb44/lib/$ISALIST' {'prefix': '/opt/csw', 'prefix_extra': '/bdb44', 'subdir2': None, 'subdirs': '', 'isalist': '/$ISALIST'} Good rpath: '/opt/csw/bdb44/lib/64' {'prefix': '/opt/csw', 'prefix_extra': '/bdb44', 'subdir2': None, 'subdirs': '/64', 'isalist': None} Good rpath: '/opt/csw/bdb47/lib' {'prefix': '/opt/csw', 'prefix_extra': '/bdb47', 'subdir2': None, 'subdirs': '', 'isalist': None} Good rpath: '/opt/csw/bdb47/lib/$ISALIST' {'prefix': '/opt/csw', 'prefix_extra': '/bdb47', 'subdir2': None, 'subdirs': '', 'isalist': '/$ISALIST'} Good rpath: '/opt/csw/bdb47/lib/64' {'prefix': '/opt/csw', 'prefix_extra': '/bdb47', 'subdir2': None, 'subdirs': '/64', 'isalist': None} Good rpath: '/opt/csw/bdb48/lib' {'prefix': '/opt/csw', 'prefix_extra': '/bdb48', 'subdir2': None, 'subdirs': '', 'isalist': None} Good rpath: '/opt/csw/bdb48/lib/$ISALIST' {'prefix': '/opt/csw', 'prefix_extra': '/bdb48', 'subdir2': None, 'subdirs': '', 'isalist': '/$ISALIST'} Good rpath: '/opt/csw/bdb48/lib/64' {'prefix': '/opt/csw', 'prefix_extra': '/bdb48', 'subdir2': None, 'subdirs': '/64', 'isalist': None} Good rpath: '/opt/csw/gcc3/lib' {'prefix': '/opt/csw', 'prefix_extra': '/gcc3', 'subdir2': None, 'subdirs': '', 'isalist': None} Good rpath: '/opt/csw/gcc3/lib/$ISALIST' {'prefix': '/opt/csw', 'prefix_extra': '/gcc3', 'subdir2': None, 'subdirs': '', 'isalist': '/$ISALIST'} Good rpath: '/opt/csw/gcc3/lib/.' {'prefix': '/opt/csw', 'prefix_extra': '/gcc3', 'subdir2': None, 'subdirs': '/.', 'isalist': None} Good rpath: '/opt/csw/gcc3/lib/sparcv9' {'prefix': '/opt/csw', 'prefix_extra': '/gcc3', 'subdir2': None, 'subdirs': '/sparcv9', 'isalist': None} Good rpath: '/opt/csw/gcc4/lib' {'prefix': '/opt/csw', 'prefix_extra': '/gcc4', 'subdir2': None, 'subdirs': '', 'isalist': None} Good rpath: '/opt/csw/gcc4/lib/$ISALIST' {'prefix': '/opt/csw', 'prefix_extra': '/gcc4', 'subdir2': None, 'subdirs': '', 'isalist': '/$ISALIST'} Good rpath: '/opt/csw/gcc4/lib/64' {'prefix': '/opt/csw', 'prefix_extra': '/gcc4', 'subdir2': None, 'subdirs': '/64', 'isalist': None} Good rpath: '/opt/csw/gcc4/lib/gcj-4.3.3-9' {'prefix': '/opt/csw', 'prefix_extra': '/gcc4', 'subdir2': None, 'subdirs': '/gcj-4.3.3-9', 'isalist': None} Good rpath: '/opt/csw/gcc4/lib/sparcv9' {'prefix': '/opt/csw', 'prefix_extra': '/gcc4', 'subdir2': None, 'subdirs': '/sparcv9', 'isalist': None} Good rpath: '/opt/csw/kde-gcc/lib' {'prefix': '/opt/csw', 'prefix_extra': '/kde-gcc', 'subdir2': None, 'subdirs': '', 'isalist': None} Good rpath: '/opt/csw/kde-gcc/lib/kde3' {'prefix': '/opt/csw', 'prefix_extra': '/kde-gcc', 'subdir2': None, 'subdirs': '/kde3', 'isalist': None} Good rpath: '/opt/csw/kde/lib' {'prefix': '/opt/csw', 'prefix_extra': '/kde', 'subdir2': None, 'subdirs': '', 'isalist': None} Good rpath: '/opt/csw/lib' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '', 'isalist': None} Good rpath: '/opt/csw/lib/$ISALIST' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '', 'isalist': '/$ISALIST'} Good rpath: '/opt/csw/lib/$ISALIST/ogle' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': '/ogle', 'subdirs': '', 'isalist': '/$ISALIST'} Good rpath: '/opt/csw/lib/.' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/.', 'isalist': None} Good rpath: '/opt/csw/lib/32' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/32', 'isalist': None} Good rpath: '/opt/csw/lib/64' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/64', 'isalist': None} Good rpath: '/opt/csw/lib/SALIST' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/SALIST', 'isalist': None} Good rpath: '/opt/csw/lib/X11' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/X11', 'isalist': None} Good rpath: '/opt/csw/lib/amanda' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/amanda', 'isalist': None} Good rpath: '/opt/csw/lib/courier-authlib' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/courier-authlib', 'isalist': None} Good rpath: '/opt/csw/lib/dia' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/dia', 'isalist': None} Good rpath: '/opt/csw/lib/evolution/1.4' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/evolution/1.4', 'isalist': None} Good rpath: '/opt/csw/lib/evolution/2.2' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/evolution/2.2', 'isalist': None} Good rpath: '/opt/csw/lib/evolution/2.6' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/evolution/2.6', 'isalist': None} Good rpath: '/opt/csw/lib/evolution/2.8' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/evolution/2.8', 'isalist': None} Good rpath: '/opt/csw/lib/evolution/2.8/components' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/evolution/2.8/components', 'isalist': None} Good rpath: '/opt/csw/lib/evolution/nss/lib' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/evolution/nss/lib', 'isalist': None} Good rpath: '/opt/csw/lib/gnopernicus-1.0' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/gnopernicus-1.0', 'isalist': None} Good rpath: '/opt/csw/lib/gnucash' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/gnucash', 'isalist': None} Good rpath: '/opt/csw/lib/graphviz' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/graphviz', 'isalist': None} Good rpath: '/opt/csw/lib/htdig' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/htdig', 'isalist': None} Good rpath: '/opt/csw/lib/htdig_db' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/htdig_db', 'isalist': None} Good rpath: '/opt/csw/lib/lib' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/lib', 'isalist': None} Good rpath: '/opt/csw/lib/libsunmath.so' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/libsunmath.so', 'isalist': None} Good rpath: '/opt/csw/lib/mozilla' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/mozilla', 'isalist': None} Good rpath: '/opt/csw/lib/mysql' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/mysql', 'isalist': None} Good rpath: '/opt/csw/lib/octave-3.0.0' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/octave-3.0.0', 'isalist': None} Good rpath: '/opt/csw/lib/ogle' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/ogle', 'isalist': None} Good rpath: '/opt/csw/lib/perl/5.8.8/CORE' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/perl/5.8.8/CORE', 'isalist': None} Good rpath: '/opt/csw/lib/purple-2' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/purple-2', 'isalist': None} Good rpath: '/opt/csw/lib/sasl2' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/sasl2', 'isalist': None} Good rpath: '/opt/csw/lib/sparcv8' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/sparcv8', 'isalist': None} Good rpath: '/opt/csw/lib/sparcv8plus' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/sparcv8plus', 'isalist': None} Good rpath: '/opt/csw/lib/sparcv9' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/sparcv9', 'isalist': None} Good rpath: '/opt/csw/lib/svn' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/svn', 'isalist': None} Good rpath: '/opt/csw/lib/xfce4/modules' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/xfce4/modules', 'isalist': None} Good rpath: '/opt/csw/libexec/firefox/lib/firefox-1.5.0.6' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/firefox/lib/firefox-1.5.0.6', 'isalist': None} Good rpath: '/opt/csw/libexec/firefox/lib/firefox-1.5.0.7' {'prefix': '/opt/csw', 'prefix_extra': '', 'subdir2': None, 'subdirs': '/firefox/lib/firefox-1.5.0.7', 'isalist': None} Good rpath: '/opt/csw/mozilla/firefox/lib' {'prefix': '/opt/csw', 'prefix_extra': '/mozilla/firefox', 'subdir2': None, 'subdirs': '', 'isalist': None} Good rpath: '/opt/csw/mozilla/thunderbird/lib' {'prefix': '/opt/csw', 'prefix_extra': '/mozilla/thunderbird', 'subdir2': None, 'subdirs': '', 'isalist': None} Good rpath: '/opt/csw/mysql4/lib/mysql' {'prefix': '/opt/csw', 'prefix_extra': '/mysql4', 'subdir2': None, 'subdirs': '/mysql', 'isalist': None} Good rpath: '/opt/csw/mysql4/lib/mysql/$ISALIST' {'prefix': '/opt/csw', 'prefix_extra': '/mysql4', 'subdir2': None, 'subdirs': '/mysql', 'isalist': '/$ISALIST'} Good rpath: '/opt/csw/mysql4/lib/mysql/sparcv9' {'prefix': '/opt/csw', 'prefix_extra': '/mysql4', 'subdir2': None, 'subdirs': '/mysql/sparcv9', 'isalist': None} Good rpath: '/opt/csw/mysql5/lib' {'prefix': '/opt/csw', 'prefix_extra': '/mysql5', 'subdir2': None, 'subdirs': '', 'isalist': None} Good rpath: '/opt/csw/mysql5/lib/$ISALIST' {'prefix': '/opt/csw', 'prefix_extra': '/mysql5', 'subdir2': None, 'subdirs': '', 'isalist': '/$ISALIST'} Good rpath: '/opt/csw/mysql5/lib/$ISALIST/mysql' {'prefix': '/opt/csw', 'prefix_extra': '/mysql5', 'subdir2': '/mysql', 'subdirs': '', 'isalist': '/$ISALIST'} Good rpath: '/opt/csw/mysql5/lib/64' {'prefix': '/opt/csw', 'prefix_extra': '/mysql5', 'subdir2': None, 'subdirs': '/64', 'isalist': None} Good rpath: '/opt/csw/mysql5/lib/64/$ISALIST/mysql' {'prefix': '/opt/csw', 'prefix_extra': '/mysql5', 'subdir2': '/mysql', 'subdirs': '/64', 'isalist': '/$ISALIST'} Good rpath: '/opt/csw/mysql5/lib/64/mysql' {'prefix': '/opt/csw', 'prefix_extra': '/mysql5', 'subdir2': None, 'subdirs': '/64/mysql', 'isalist': None} Good rpath: '/opt/csw/mysql5/lib/mysql' {'prefix': '/opt/csw', 'prefix_extra': '/mysql5', 'subdir2': None, 'subdirs': '/mysql', 'isalist': None} Good rpath: '/opt/csw/mysql5/lib/mysql/$ISALIST' {'prefix': '/opt/csw', 'prefix_extra': '/mysql5', 'subdir2': None, 'subdirs': '/mysql', 'isalist': '/$ISALIST'} Good rpath: '/opt/csw/nagios/lib' {'prefix': '/opt/csw', 'prefix_extra': '/nagios', 'subdir2': None, 'subdirs': '', 'isalist': None} Good rpath: '/opt/csw/postgresql/lib' {'prefix': '/opt/csw', 'prefix_extra': '/postgresql', 'subdir2': None, 'subdirs': '', 'isalist': None} Good rpath: '/opt/csw/postgresql/lib/$ISALIST' {'prefix': '/opt/csw', 'prefix_extra': '/postgresql', 'subdir2': None, 'subdirs': '', 'isalist': '/$ISALIST'} Good rpath: '/opt/csw/postgresql/lib/sparcv9' {'prefix': '/opt/csw', 'prefix_extra': '/postgresql', 'subdir2': None, 'subdirs': '/sparcv9', 'isalist': None} Good rpath: '/opt/csw/ssl/lib' {'prefix': '/opt/csw', 'prefix_extra': '/ssl', 'subdir2': None, 'subdirs': '', 'isalist': None} From james at opencsw.org Thu Mar 25 13:41:16 2010 From: james at opencsw.org (James Lee) Date: Thu, 25 Mar 2010 12:41:16 GMT Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> <908A3B6E-FCB1-452F-9C9D-2C1D8F4DA904@opencsw.org> <4BA931CB.4050000@wbonnet.net> <20100324.17553600.1947673963@gyor.oxdrove.co.uk> Message-ID: <20100325.12411600.4100030085@gyor.oxdrove.co.uk> On 25/03/10, 09:15:51, Peter FELECAN wrote regarding Re: [csw-maintainers] bad news on the CSW X11 front: > >> Well, this bring us to the same decision, discussed in another thread: > >> to abandon Solaris 8 and, if it seems that the X11 version supplied with > >> it is not satisfactory, abandon Solaris 9 also. > > > > Not so fast, this topic (OpenGL) affects Solaris 10 too. > It does not if we don't use our brew of X11. QED. It's still not Solaris rev specific. > >> Procrastinating on this issue is not to the benefit of our project. And, > >> please, please, don't bring up, again, the theme of an hypothetical > >> stable release! I'm not anymore an agnostic but an unbeliever of this > >> myth. > > > > The irony of this is that it is stable and the desire to leave a Solaris > > 8 collection in a usable state that is being blocked by X11, so > > preventing moving on with grace. > Ironic or not this is stagnating since more than a year, isn't it? > All of the above shows the incapacity of our project to make a decision. Correct and the action depends on desire and opportunity. We can't decide to release stable if the opportunity is not there because it is not stable and there seems no desire to create the opportunity. This is unrelated to Solaris 8 as the packages are currently similar across revs. James. From dam at opencsw.org Thu Mar 25 14:20:10 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 25 Mar 2010 14:20:10 +0100 Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: <20100325.12411600.4100030085@gyor.oxdrove.co.uk> References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> <908A3B6E-FCB1-452F-9C9D-2C1D8F4DA904@opencsw.org> <4BA931CB.4050000@wbonnet.net> <20100324.17553600.1947673963@gyor.oxdrove.co.uk> <20100325.12411600.4100030085@gyor.oxdrove.co.uk> Message-ID: <47B8D9BD-13FE-495E-846F-CF1EED5A0239@opencsw.org> Hi James, Am 25.03.2010 um 13:41 schrieb James Lee: >>> The irony of this is that it is stable and the desire to leave a >>> Solaris >>> 8 collection in a usable state that is being blocked by X11, so >>> preventing moving on with grace. > >> Ironic or not this is stagnating since more than a year, isn't it? >> All of the above shows the incapacity of our project to make a >> decision. > > Correct and the action depends on desire and opportunity. We can't > decide to release stable if the opportunity is not there because it is > not stable and there seems no desire to create the opportunity. This > is unrelated to Solaris 8 as the packages are currently similar across > revs. There is desire. However, obviously no one has identified of what needs to be done. Ben offered to kick people to update their stuff and keep track of progress if anyone would identify it. Other than the general "X11 is broken here" was not identified. The approach by Maciej with generational releases has been torpedod, so there is no stable project right now. So it is more like a "I, James, am working on it and this is not the right time now and there is no way to help me and I don't want other people to work on it." This may or may not how it is intended but it feels like this for me. Best regards -- Dago From dam at opencsw.org Thu Mar 25 14:31:46 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 25 Mar 2010 14:31:46 +0100 Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: <20100325.12411600.4100030085@gyor.oxdrove.co.uk> References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> <908A3B6E-FCB1-452F-9C9D-2C1D8F4DA904@opencsw.org> <4BA931CB.4050000@wbonnet.net> <20100324.17553600.1947673963@gyor.oxdrove.co.uk> <20100325.12411600.4100030085@gyor.oxdrove.co.uk> Message-ID: <0F0E82EA-4586-488B-8977-FB69D9D32D62@opencsw.org> Hi James, Am 25.03.2010 um 13:41 schrieb James Lee: >>> The irony of this is that it is stable and the desire to leave a >>> Solaris >>> 8 collection in a usable state that is being blocked by X11, so >>> preventing moving on with grace. > >> Ironic or not this is stagnating since more than a year, isn't it? >> All of the above shows the incapacity of our project to make a >> decision. > > Correct and the action depends on desire and opportunity. We can't > decide to release stable if the opportunity is not there because it is > not stable and there seems no desire to create the opportunity. This > is unrelated to Solaris 8 as the packages are currently similar across > revs. There is desire. However, obviously no one has identified of what needs to be done. Ben offered to kick people to update their stuff and keep track of progress if anyone would identify it. Other than the general "X11 is broken here" was not identified. The approach by Maciej with generational releases has been torpedod, so there is no other stable project right now. So it is more like a "I, James, am working on it and this is not the right time now and there is no way to help me and I don't want other people to work on it." This may or may not how it is intended but it feels like this to me. Best regards -- Dago From pfelecan at opencsw.org Thu Mar 25 15:01:43 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 25 Mar 2010 15:01:43 +0100 Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: <20100325.12411600.4100030085@gyor.oxdrove.co.uk> (James Lee's message of "Thu, 25 Mar 2010 12:41:16 GMT") References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> <908A3B6E-FCB1-452F-9C9D-2C1D8F4DA904@opencsw.org> <4BA931CB.4050000@wbonnet.net> <20100324.17553600.1947673963@gyor.oxdrove.co.uk> <20100325.12411600.4100030085@gyor.oxdrove.co.uk> Message-ID: James Lee writes: > On 25/03/10, 09:15:51, Peter FELECAN wrote regarding > Re: [csw-maintainers] bad news on the CSW X11 front: > >> >> Well, this bring us to the same decision, discussed in another thread: >> >> to abandon Solaris 8 and, if it seems that the X11 version supplied with >> >> it is not satisfactory, abandon Solaris 9 also. >> > >> > Not so fast, this topic (OpenGL) affects Solaris 10 too. > >> It does not if we don't use our brew of X11. > > QED. It's still not Solaris rev specific. Just to paraphrase you: "Not so fast" to declare QED... We have this issue because the Solaris 8, and maybe 9, are old, 20th century clunkers which does not provide up to date X11. >> >> Procrastinating on this issue is not to the benefit of our project. And, >> >> please, please, don't bring up, again, the theme of an hypothetical >> >> stable release! I'm not anymore an agnostic but an unbeliever of this >> >> myth. >> > >> > The irony of this is that it is stable and the desire to leave a Solaris >> > 8 collection in a usable state that is being blocked by X11, so >> > preventing moving on with grace. > >> Ironic or not this is stagnating since more than a year, isn't it? > >> All of the above shows the incapacity of our project to make a decision. > > Correct and the action depends on desire and opportunity. We can't > decide to release stable if the opportunity is not there because it is > not stable and there seems no desire to create the opportunity. This > is unrelated to Solaris 8 as the packages are currently similar across > revs. I agree on this. However, I must observe that the same kind of discussions brought us to the split. Note that I'm not proposing a split. Evolve to Revolve -- Peter From james at opencsw.org Thu Mar 25 15:32:17 2010 From: james at opencsw.org (James Lee) Date: Thu, 25 Mar 2010 14:32:17 GMT Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: <0F0E82EA-4586-488B-8977-FB69D9D32D62@opencsw.org> References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> <908A3B6E-FCB1-452F-9C9D-2C1D8F4DA904@opencsw.org> <4BA931CB.4050000@wbonnet.net> <20100324.17553600.1947673963@gyor.oxdrove.co.uk> <20100325.12411600.4100030085@gyor.oxdrove.co.uk> <0F0E82EA-4586-488B-8977-FB69D9D32D62@opencsw.org> Message-ID: <20100325.14321700.1670691348@gyor.oxdrove.co.uk> On 25/03/10, 13:31:46, Dagobert Michelsen wrote regarding Re: [csw-maintainers] bad news on the CSW X11 front: > >>> The irony of this is that it is stable and the desire to leave a > >>> Solaris > >>> 8 collection in a usable state that is being blocked by X11, so > >>> preventing moving on with grace. > > > >> Ironic or not this is stagnating since more than a year, isn't it? > >> All of the above shows the incapacity of our project to make a > >> decision. > > > > Correct and the action depends on desire and opportunity. We can't > > decide to release stable if the opportunity is not there because it is > > not stable and there seems no desire to create the opportunity. This > > is unrelated to Solaris 8 as the packages are currently similar across > > revs. > There is desire. However, obviously no one has identified of what needs > to be done. Ben offered to kick people to update their stuff and keep > track of progress if anyone would identify it. Other than the general > "X11 is broken here" was not identified. It's not because it's a product of the investigation. > The approach by Maciej with generational releases has been torpedod, > so there is no other stable project right now. Not exactly but it should come against exactly the same problem, lack of integrity in the unstable release. If it didn't then it needs killing. My question was how would it be more likely to lead to a stable release? Simply declaring stuff stable because it's old is not the answer. > So it is more like a "I, James, am working on it and this is not the > right time now and there is no way to help me and I don't want other > people to work on it." This may or may not how it is intended but > it feels like this to me. I, James, have been working on this and my conclusion is it needs other people to work on X11 (and probably other packages pending the investigation) because the set won't pass as stable. James. From james at opencsw.org Thu Mar 25 15:40:57 2010 From: james at opencsw.org (James Lee) Date: Thu, 25 Mar 2010 14:40:57 GMT Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> <908A3B6E-FCB1-452F-9C9D-2C1D8F4DA904@opencsw.org> <4BA931CB.4050000@wbonnet.net> <20100324.17553600.1947673963@gyor.oxdrove.co.uk> <20100325.12411600.4100030085@gyor.oxdrove.co.uk> Message-ID: <20100325.14405700.2495142708@gyor.oxdrove.co.uk> On 25/03/10, 14:01:43, Peter FELECAN wrote regarding Re: [csw-maintainers] bad news on the CSW X11 front: > >> >> Well, this bring us to the same decision, discussed in another thread: > >> >> to abandon Solaris 8 and, if it seems that the X11 version supplied > >> >> with it is not satisfactory, abandon Solaris 9 also. > >> > > >> > Not so fast, this topic (OpenGL) affects Solaris 10 too. > > > >> It does not if we don't use our brew of X11. > > > > QED. It's still not Solaris rev specific. > Just to paraphrase you: "Not so fast" to declare QED... We have this > issue because the Solaris 8, and maybe 9, are old, 20th century clunkers > which does not provide up to date X11. We have this issue with OpenGL because *all* of Solaris 8, 9 and 10's hardware acceleration link to Solaris's X11. James. From phil at bolthole.com Thu Mar 25 17:09:11 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 25 Mar 2010 09:09:11 -0700 Subject: [csw-maintainers] Runpath menagerie for review In-Reply-To: References: Message-ID: On Thu, Mar 25, 2010 at 3:09 AM, Maciej (Matchek) Blizinski wrote: > 2010/3/23 Philip Brown : >> stuff starting with /optcsw is mostly acceptible. > > What about rpath orthography? ?Would you like checkpkg to throw errors > on the following ones? > > '/opt/csw/lib/.' ?(as opposed to '/opt/csw/lib') > '/opt/csw/X11/lib/' (as opposed to '/opt/csw/X11/lib') I'd say yes > > Next question: specific architecture entries, for instance: > > '/opt/csw/postgresql/lib/sparcv9' > > Shouldn't this be '/opt/csw/postgresql/lib/$ISALIST' instead? Hmmm... in the more general case, yes. however, since there is one and only one "64bit" arch for sparc... not really. > Next question: What about $ORIGIN? ?In some cases it makes, sense, for > instance if a 32-bit binary looks into '$ORIGIN/../lib', I guess > that's fine. ?But if it's a 64-bit binary in /opt/csw/bin/sparcv9 and > the corresponding library is in /opt/csw/lib/sparcv9, the > '$ORIGIN/../lib' entry won't help much. Oooh, good point. except what happens if it was an isaexec'd binary? that owuld be the only exception I might think of, and its probably an invalid exception. > > Bad rpath: '$ORIGIN' actualy that can be quite okay, if its an RPATH in a library. > Bad rpath: '/opt/csw/lib/sparcv8plus+vis' If it is in an executable specifically compiled for that, then it might not strictly speaking be "wrong". ie: if it was in /opt/csw/bin/sparcv8plus+vis/executable > Bad rpath: '/opt/csw/mysql4//lib/mysql' meh.. mysql is a very individual case, so that could be let slip. it will probably never be recopmiled anyway :) > Bad rpath: '/usr/ccs/lib' this is not bad. > Bad rpath: '/usr/ccs/lib/sparcv9' ditto. > Bad rpath: '/usr/dt/lib' not bad. > Bad rpath: '/usr/lib' > Bad rpath: '/usr/lib/sparcv9' ditto. > Bad rpath: '/usr/openwin/lib' not bad. From phil at bolthole.com Thu Mar 25 17:10:39 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 25 Mar 2010 09:10:39 -0700 Subject: [csw-maintainers] [buildfarm-announce] General buildfarm update In-Reply-To: <6DA53F54-076E-4C2C-B36B-252B3C678AEE@opencsw.org> References: <6DA53F54-076E-4C2C-B36B-252B3C678AEE@opencsw.org> Message-ID: erm.. it sounds like you are doing away with the "buildXX" naming. I think it would be nice to keep that. From phil at bolthole.com Thu Mar 25 17:12:58 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 25 Mar 2010 09:12:58 -0700 Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> <908A3B6E-FCB1-452F-9C9D-2C1D8F4DA904@opencsw.org> <4BA931CB.4050000@wbonnet.net> <20100324.17553600.1947673963@gyor.oxdrove.co.uk> Message-ID: On Thu, Mar 25, 2010 at 2:15 AM, Peter FELECAN wrote: > > Ironic or not this is stagnating since more than a year, isn't it? > > All of the above shows the incapacity of our project to make a decision. > incorrect. we did not have stable sooner, because this is a volunteer organization, and there has not previously been sufficient voluteered time/commitment to produce a "stable" stable. but this is irrelevant to the "what do we do about X11" question. From pfelecan at opencsw.org Thu Mar 25 17:32:04 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 25 Mar 2010 17:32:04 +0100 Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: <20100325.14405700.2495142708@gyor.oxdrove.co.uk> (James Lee's message of "Thu, 25 Mar 2010 14:40:57 GMT") References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> <908A3B6E-FCB1-452F-9C9D-2C1D8F4DA904@opencsw.org> <4BA931CB.4050000@wbonnet.net> <20100324.17553600.1947673963@gyor.oxdrove.co.uk> <20100325.12411600.4100030085@gyor.oxdrove.co.uk> <20100325.14405700.2495142708@gyor.oxdrove.co.uk> Message-ID: James Lee writes: > On 25/03/10, 14:01:43, Peter FELECAN wrote regarding > Re: [csw-maintainers] bad news on the CSW X11 front: > >> >> >> Well, this bring us to the same decision, discussed in another thread: >> >> >> to abandon Solaris 8 and, if it seems that the X11 version supplied >> >> >> with it is not satisfactory, abandon Solaris 9 also. >> >> > >> >> > Not so fast, this topic (OpenGL) affects Solaris 10 too. >> > >> >> It does not if we don't use our brew of X11. >> > >> > QED. It's still not Solaris rev specific. > >> Just to paraphrase you: "Not so fast" to declare QED... We have this >> issue because the Solaris 8, and maybe 9, are old, 20th century clunkers >> which does not provide up to date X11. > > We have this issue with OpenGL because *all* of Solaris 8, 9 and 10's > hardware acceleration link to Solaris's X11. Veil of opacity falls on my mind... Now, tell me: if I'm using the X11 provided with Solaris 10 have I a 3d acceleration on those graphic cards where that feature it's available? -- Peter From pfelecan at opencsw.org Thu Mar 25 17:39:52 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 25 Mar 2010 17:39:52 +0100 Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: (Philip Brown's message of "Thu, 25 Mar 2010 09:12:58 -0700") References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> <908A3B6E-FCB1-452F-9C9D-2C1D8F4DA904@opencsw.org> <4BA931CB.4050000@wbonnet.net> <20100324.17553600.1947673963@gyor.oxdrove.co.uk> Message-ID: Philip Brown writes: > On Thu, Mar 25, 2010 at 2:15 AM, Peter FELECAN wrote: >> >> Ironic or not this is stagnating since more than a year, isn't it? >> >> All of the above shows the incapacity of our project to make a decision. >> > > incorrect. we did not have stable sooner, because this is a volunteer > organization, and there has not previously been sufficient voluteered > time/commitment to produce a "stable" stable. It seems obvious that there is nobody volunteering to do the "stable" release from start to end in a reasonable span of time. Besides James, I was the only one participating in previous "stable" wise QA. Unfortunately, today I do not have anymore the SPARC servers to help, consequently I'm not volunteering. > but this is irrelevant to the "what do we do about X11" question. It is relevant as the following is a solution: 1. drop Solaris 8 and 9 2. use the SUN provided X11 with Solaris 10 and you have 3d acceleration on those hardware platforms where the feature is available. -- Peter From james at opencsw.org Thu Mar 25 17:48:03 2010 From: james at opencsw.org (James Lee) Date: Thu, 25 Mar 2010 16:48:03 GMT Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> <908A3B6E-FCB1-452F-9C9D-2C1D8F4DA904@opencsw.org> <4BA931CB.4050000@wbonnet.net> <20100324.17553600.1947673963@gyor.oxdrove.co.uk> <20100325.12411600.4100030085@gyor.oxdrove.co.uk> <20100325.14405700.2495142708@gyor.oxdrove.co.uk> Message-ID: <20100325.16480300.3470698382@gyor.oxdrove.co.uk> On 25/03/10, 16:32:04, Peter FELECAN wrote regarding Re: [csw-maintainers] bad news on the CSW X11 front: > > We have this issue with OpenGL because *all* of Solaris 8, 9 and 10's > > hardware acceleration link to Solaris's X11. > Veil of opacity falls on my mind... > Now, tell me: if I'm using the X11 provided with Solaris 10 have I a 3d > acceleration on those graphic cards where that feature it's available? $ cat /etc/release Solaris 10 10/09 s10x_u8wos_08a X86 Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 16 September 2009 $ dump -Lv /usr/lib/libGL.so | grep NEEDED [2] NEEDED libXext.so.0 [4] NEEDED libX11.so.4 [5] NEEDED libc.so.1 It's not libX11.so.6 as is CSW X11. James. From dam at opencsw.org Thu Mar 25 17:55:48 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 25 Mar 2010 17:55:48 +0100 Subject: [csw-maintainers] [buildfarm-announce] General buildfarm update In-Reply-To: References: <6DA53F54-076E-4C2C-B36B-252B3C678AEE@opencsw.org> Message-ID: <399967C2-0C8C-47A1-83C1-3240D24AB445@opencsw.org> Hi Phil, Am 25.03.2010 um 17:10 schrieb Philip Brown: > erm.. it sounds like you are doing away with the "buildXX" naming. > > I think it would be nice to keep that. They are now CNAMES. The machines are now renamed to conform to the catalog they run. This is at the moment currentXs Sparc currentXx x86 testingXs Sparc testingXx x86 with X = 8/9/10/osol. I planned to add experimentalX when we would go ahead with or projectXs projectXx which run current, but are updated with built packages for single- release projects like Perl. Best regards -- Dago From bwalton at opencsw.org Thu Mar 25 17:56:02 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 25 Mar 2010 12:56:02 -0400 Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: <20100325.16480300.3470698382@gyor.oxdrove.co.uk> References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> <908A3B6E-FCB1-452F-9C9D-2C1D8F4DA904@opencsw.org> <4BA931CB.4050000@wbonnet.net> <20100324.17553600.1947673963@gyor.oxdrove.co.uk> <20100325.12411600.4100030085@gyor.oxdrove.co.uk> <20100325.14405700.2495142708@gyor.oxdrove.co.uk> <20100325.16480300.3470698382@gyor.oxdrove.co.uk> Message-ID: <1269535979-sup-6280@pinkfloyd.chass.utoronto.ca> Excerpts from James Lee's message of Thu Mar 25 12:48:03 -0400 2010: > $ dump -Lv /usr/lib/libGL.so | grep NEEDED > [2] NEEDED libXext.so.0 > [4] NEEDED libX11.so.4 > [5] NEEDED libc.so.1 > > It's not libX11.so.6 as is CSW X11. Which means you get either 3D or modern gtk, et al. Phil's proposed solution of using an older gtk may work for the short term, but I think that's not necessarily a good long term solution. I don't play in this area much, and excuse me if it has already been stated, but: Can the CSW X11 link against /usr/lib/libGL.so, thus getting us the best of both worlds? (Presumably this would mean a 5.9 build and a 5.10 build.) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Thu Mar 25 18:39:30 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 25 Mar 2010 18:39:30 +0100 Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: <20100325.16480300.3470698382@gyor.oxdrove.co.uk> (James Lee's message of "Thu, 25 Mar 2010 16:48:03 GMT") References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> <908A3B6E-FCB1-452F-9C9D-2C1D8F4DA904@opencsw.org> <4BA931CB.4050000@wbonnet.net> <20100324.17553600.1947673963@gyor.oxdrove.co.uk> <20100325.12411600.4100030085@gyor.oxdrove.co.uk> <20100325.14405700.2495142708@gyor.oxdrove.co.uk> <20100325.16480300.3470698382@gyor.oxdrove.co.uk> Message-ID: James Lee writes: > On 25/03/10, 16:32:04, Peter FELECAN wrote regarding > Re: [csw-maintainers] bad news on the CSW X11 front: > >> > We have this issue with OpenGL because *all* of Solaris 8, 9 and 10's >> > hardware acceleration link to Solaris's X11. > >> Veil of opacity falls on my mind... > >> Now, tell me: if I'm using the X11 provided with Solaris 10 have I a 3d >> acceleration on those graphic cards where that feature it's available? > > $ cat /etc/release > Solaris 10 10/09 s10x_u8wos_08a X86 > Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. > Use is subject to license terms. > Assembled 16 September 2009 > > > $ dump -Lv /usr/lib/libGL.so | grep NEEDED > [2] NEEDED libXext.so.0 > [4] NEEDED libX11.so.4 > [5] NEEDED libc.so.1 > > > It's not libX11.so.6 as is CSW X11. That's not a yes or a no. You tell me something else but do not answer to my question: "if I'm using the X11 provided with Solaris 10 have I a 3d acceleration on those graphic cards where that feature it's available?" But maybe you're trying to say something that I do not get. -- Peter From phil at bolthole.com Thu Mar 25 19:38:11 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 25 Mar 2010 11:38:11 -0700 Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: References: <908A3B6E-FCB1-452F-9C9D-2C1D8F4DA904@opencsw.org> <4BA931CB.4050000@wbonnet.net> <20100324.17553600.1947673963@gyor.oxdrove.co.uk> <20100325.12411600.4100030085@gyor.oxdrove.co.uk> <20100325.14405700.2495142708@gyor.oxdrove.co.uk> Message-ID: To translate James's reply to Peter's question, below: On Thu, Mar 25, 2010 at 9:32 AM, Peter FELECAN wrote: > > > Now, tell me: if I'm using the X11 provided with Solaris 10 have I a 3d > acceleration on those graphic cards where that feature it's available? "yes". Presuming that you are using an application that also links to libGL, which is the library that provides the actual 3d acceleration. There is zero 3d acceleration, in any raw "libX11.so". from anywhere. You need a hardware-aware libGL.so, to get 3d acceleration, from any solaris app. We get hardware-accelerated libGL.so on solaris, from sun/nvidia. There is no other reasonably modern source for such a beast. That libGL.so requires "libX11.so.4". This is the fundamental problem. since our recent "new X11" stuff, generates a "libX11.so.6", not libX11.so.4. So, as mentioned before, our "new X11" stuff, is incompatible with 3d hardware acceleration on solaris. Please keep in mind that the primary reason we aimed for "new X11", was primarily to jump our GNOME stuff ahead, from 2.12, to 2.16. It's not that we really need "new X11" in and of itself. So us not having "new X11" isnt particularly bad, as long as we can have a "new ENOUGH" set of gnome libs. Yes, this wont hold us forever. but everything changes over time. While this wont be good enough in 2 years... what is provided by solaris itself will have changed in 2 years also, I wouuld guess. An intermediate "gnome 2.14" solution should serve us well for the next 12 months. After 12 months, we re-evaluate. From james at opencsw.org Thu Mar 25 20:01:32 2010 From: james at opencsw.org (James Lee) Date: Thu, 25 Mar 2010 19:01:32 GMT Subject: [csw-maintainers] bad news on the CSW X11 front In-Reply-To: References: <2DA7C960-B6E5-4B56-BB7D-C3FA8FAA3A5B@opencsw.org> <908A3B6E-FCB1-452F-9C9D-2C1D8F4DA904@opencsw.org> <4BA931CB.4050000@wbonnet.net> <20100324.17553600.1947673963@gyor.oxdrove.co.uk> <20100325.12411600.4100030085@gyor.oxdrove.co.uk> <20100325.14405700.2495142708@gyor.oxdrove.co.uk> <20100325.16480300.3470698382@gyor.oxdrove.co.uk> Message-ID: <20100325.19013200.1455635566@gyor.oxdrove.co.uk> On 25/03/10, 17:39:30, Peter FELECAN wrote regarding Re: [csw-maintainers] bad news on the CSW X11 front: > That's not a yes or a no. You tell me something else but do not answer > to my question: Sorry, the wording is vague and I guessed. > "if I'm using the X11 provided with Solaris 10 have I a 3d acceleration > on those graphic cards where that feature it's available?" Yes and no. If it's a Sun Sparc card (eg XVR-600, XVR-2500), yes. If it's by nvidia there is a selection, see list: ftp://download.nvidia.com/solaris/1.0-7664/README.txt Otherwise probably not. James. From bwalton at opencsw.org Thu Mar 25 20:38:12 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 25 Mar 2010 15:38:12 -0400 Subject: [csw-maintainers] catalogs not signed...? Message-ID: <1269545820-sup-8350@pinkfloyd.chass.utoronto.ca> I've poked at three mirrors now and the catalog isn't signed. An omission with the latest package batches? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Thu Mar 25 21:49:47 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 25 Mar 2010 13:49:47 -0700 Subject: [csw-maintainers] catalogs not signed...? In-Reply-To: <1269545820-sup-8350@pinkfloyd.chass.utoronto.ca> References: <1269545820-sup-8350@pinkfloyd.chass.utoronto.ca> Message-ID: On Thu, Mar 25, 2010 at 12:38 PM, Ben Walton wrote: > > I've poked at three mirrors now and the catalog isn't signed. > An omission with the latest package batches? > it was a temp glitch due to something new I was trying. issue was fixed and signed catalogs have been pushed out a few hours ago. From bwalton at opencsw.org Fri Mar 26 01:01:52 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 25 Mar 2010 20:01:52 -0400 Subject: [csw-maintainers] catalogs not signed...? In-Reply-To: References: <1269545820-sup-8350@pinkfloyd.chass.utoronto.ca> Message-ID: <1269561617-sup-9985@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Thu Mar 25 16:49:47 -0400 2010: > it was a temp glitch due to something new I was trying. > issue was fixed and signed catalogs have been pushed out a few hours ago. Might it be both wise _and_ useful for the other maintainers if changes to this type of stuff were discussed openly and _before_ changes are made? Given how complicated the process is, I think the more people that are looking at it the better. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Fri Mar 26 11:22:27 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 26 Mar 2010 10:22:27 +0000 Subject: [csw-maintainers] V8+ binaries from now on Message-ID: In the past, packages were getting rejected if they had V8+ binaries for SPARC. I vaguely recall this being related to Solaris 8. Now that we dropped it, is it okay to ship V8+ binaries? From hson at opencsw.org Fri Mar 26 11:29:36 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 26 Mar 2010 11:29:36 +0100 Subject: [csw-maintainers] V8+ binaries from now on In-Reply-To: References: Message-ID: <4BAC8C90.50203@opencsw.org> On 2010-03-26 11:22, Maciej (Matchek) Blizinski wrote: > In the past, packages were getting rejected if they had V8+ binaries > for SPARC. I vaguely recall this being related to Solaris 8. Now > that we dropped it, is it okay to ship V8+ binaries? V8+ was introduced with sun4u and unfortunately, Sun did only drop the support for sun4d (SS10) in Solaris 9, sun4m (SS5/5/20) was still supported. However, I would say that of the small percentage still running Solaris 9, I can't think that there are that many being sun4m. From dam at opencsw.org Fri Mar 26 11:32:15 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 26 Mar 2010 11:32:15 +0100 Subject: [csw-maintainers] V8+ binaries from now on In-Reply-To: <4BAC8C90.50203@opencsw.org> References: <4BAC8C90.50203@opencsw.org> Message-ID: <2768DBA1-B9ED-4DCD-8026-EBDED2C307A8@opencsw.org> Hi Roger, Am 26.03.2010 um 11:29 schrieb Roger H?kansson: > On 2010-03-26 11:22, Maciej (Matchek) Blizinski wrote: >> In the past, packages were getting rejected if they had V8+ binaries >> for SPARC. I vaguely recall this being related to Solaris 8. Now >> that we dropped it, is it okay to ship V8+ binaries? > > V8+ was introduced with sun4u and unfortunately, Sun did only drop > the support for sun4d (SS10) in Solaris 9, sun4m (SS5/5/20) was > still supported. > However, I would say that of the small percentage still running > Solaris 9, I can't think that there are that many being sun4m. But we should stick to sparcv8 then as before. Best regards -- Dago From pfelecan at opencsw.org Fri Mar 26 12:50:06 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 26 Mar 2010 12:50:06 +0100 Subject: [csw-maintainers] V8+ binaries from now on In-Reply-To: <2768DBA1-B9ED-4DCD-8026-EBDED2C307A8@opencsw.org> (Dagobert Michelsen's message of "Fri, 26 Mar 2010 11:32:15 +0100") References: <4BAC8C90.50203@opencsw.org> <2768DBA1-B9ED-4DCD-8026-EBDED2C307A8@opencsw.org> Message-ID: Dagobert Michelsen writes: > Hi Roger, > > Am 26.03.2010 um 11:29 schrieb Roger H?kansson: >> On 2010-03-26 11:22, Maciej (Matchek) Blizinski wrote: >>> In the past, packages were getting rejected if they had V8+ binaries >>> for SPARC. I vaguely recall this being related to Solaris 8. Now >>> that we dropped it, is it okay to ship V8+ binaries? >> >> V8+ was introduced with sun4u and unfortunately, Sun did only drop >> the support for sun4d (SS10) in Solaris 9, sun4m (SS5/5/20) was >> still supported. >> However, I would say that of the small percentage still running >> Solaris 9, I can't think that there are that many being sun4m. > > But we should stick to sparcv8 then as before. The Old Clunker Syndrome all over! Another constraint that we like to keep. Or maybe not? -- Peter From dam at opencsw.org Fri Mar 26 13:26:24 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 26 Mar 2010 13:26:24 +0100 Subject: [csw-maintainers] V8+ binaries from now on In-Reply-To: References: <4BAC8C90.50203@opencsw.org> <2768DBA1-B9ED-4DCD-8026-EBDED2C307A8@opencsw.org> Message-ID: <79AF6AB6-9ABD-4D51-A515-46F4741BE540@opencsw.org> Hi Peter, Am 26.03.2010 um 12:50 schrieb Peter FELECAN: > Dagobert Michelsen writes: >> Hi Roger, >> Am 26.03.2010 um 11:29 schrieb Roger H?kansson: >>> On 2010-03-26 11:22, Maciej (Matchek) Blizinski wrote: >>>> In the past, packages were getting rejected if they had V8+ >>>> binaries >>>> for SPARC. I vaguely recall this being related to Solaris 8. Now >>>> that we dropped it, is it okay to ship V8+ binaries? >>> >>> V8+ was introduced with sun4u and unfortunately, Sun did only drop >>> the support for sun4d (SS10) in Solaris 9, sun4m (SS5/5/20) was >>> still supported. >>> However, I would say that of the small percentage still running >>> Solaris 9, I can't think that there are that many being sun4m. >> >> But we should stick to sparcv8 then as before. > > The Old Clunker Syndrome all over! > > Another constraint that we like to keep. Or maybe not? If we support Solaris 9 we should support all platforms it runs on. Sticking to sparcv8 instead of sparcv8plus is one different argument in CFLAGS and changing it gains very little. Additional builds for both ISAs is one flag in GAR to add, so no problem. Best regards -- Dago From dam at opencsw.org Fri Mar 26 14:16:14 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 26 Mar 2010 14:16:14 +0100 Subject: [csw-maintainers] Updated Perl module handling in GAR References: <8943BB62-641D-4DBD-B62E-C68CE7B14317@baltic-online.de> Message-ID: <22C0619A-6C50-4459-BF90-9A22CC95B28F@opencsw.org> Hi, with r9382 the Perl module handling has beed modified as discussed. The description is now automatically set to - : e.g. pm_xmlparser - XML-Parser: A module for parsing XML documents Additionally, the pkginfo(4) has an additional field PERL_MODULE_NAME which holds same as above. This allows safe detection of packages containing Perl modules and associate them with their CPAN name. This field is not shown by default, but can be queried with pkgparam. Best regards -- Dago From hson at opencsw.org Fri Mar 26 16:16:35 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 26 Mar 2010 16:16:35 +0100 Subject: [csw-maintainers] Runpath menagerie for review In-Reply-To: References: <75B65782-98D3-4669-9992-39C0F041921B@opencsw.org> Message-ID: <4BACCFD3.7090906@opencsw.org> On 2010-03-24 18:33, Philip Brown wrote: > On Wed, Mar 24, 2010 at 3:00 AM, Dagobert Michelsen wrote: >> Hi, > >>> but we should probably really be using -xnorunpath to avoid that sort >>> of stuffs >> >> This is for SOS12u1 only, earlier versions don't have that > > err, what? yes they do. it's a longstanding "feature" of sun compilers. > > At least, the C++ compiler. The C compiler has -xnorunpath and the C++ compiler -norunpath From phil at bolthole.com Fri Mar 26 16:57:20 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 26 Mar 2010 08:57:20 -0700 Subject: [csw-maintainers] Runpath menagerie for review In-Reply-To: <4BACCFD3.7090906@opencsw.org> References: <75B65782-98D3-4669-9992-39C0F041921B@opencsw.org> <4BACCFD3.7090906@opencsw.org> Message-ID: On Fri, Mar 26, 2010 at 8:16 AM, Roger H?kansson wrote: > On 2010-03-24 18:33, Philip Brown wrote: >> >> On Wed, Mar 24, 2010 at 3:00 AM, Dagobert Michelsen >> ?wrote: >>> This is for SOS12u1 only, earlier versions don't have that >> >> err, what? yes they do. it's a longstanding "feature" of sun compilers. >> >> At least, the C++ compiler. > > The C compiler has -xnorunpath and the C++ compiler -norunpath > _ yah. bit of ambiguity about the meaning of "that", above :) So lets be explicit: both compilers tend to add RPATHs for /opt/SUNWxxxx, and both compilers have flags to disable this feature. From dam at opencsw.org Fri Mar 26 16:59:01 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 26 Mar 2010 16:59:01 +0100 Subject: [csw-maintainers] Runpath menagerie for review In-Reply-To: References: <75B65782-98D3-4669-9992-39C0F041921B@opencsw.org> <4BACCFD3.7090906@opencsw.org> Message-ID: <4C2F8AE1-FDFF-40E8-8125-7F8A01EFC37B@opencsw.org> Hi, Am 26.03.2010 um 16:57 schrieb Philip Brown: > On Fri, Mar 26, 2010 at 8:16 AM, Roger H?kansson > wrote: >> On 2010-03-24 18:33, Philip Brown wrote: >>> >>> On Wed, Mar 24, 2010 at 3:00 AM, Dagobert Michelsen >>> wrote: > >>>> This is for SOS12u1 only, earlier versions don't have that >>> >>> err, what? yes they do. it's a longstanding "feature" of sun >>> compilers. >>> >>> At least, the C++ compiler. >> >> The C compiler has -xnorunpath and the C++ compiler -norunpath >> _ > > yah. bit of ambiguity about the meaning of "that", above :) So lets > be explicit: > both compilers tend to add RPATHs for /opt/SUNWxxxx, and both > compilers have flags to disable this feature. Ok, GAR has been adjusted to use these flags now for cc/CC. SOS11 cc doesn't have it though. But it is no longer used anyway. Best regards -- Dago From hson at opencsw.org Fri Mar 26 16:59:52 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 26 Mar 2010 16:59:52 +0100 Subject: [csw-maintainers] V8+ binaries from now on In-Reply-To: References: <4BAC8C90.50203@opencsw.org> <2768DBA1-B9ED-4DCD-8026-EBDED2C307A8@opencsw.org> Message-ID: <4BACD9F8.7080104@opencsw.org> On 2010-03-26 12:50, Peter FELECAN wrote: >> But we should stick to sparcv8 then as before. > > The Old Clunker Syndrome all over! > > Another constraint that we like to keep. Or maybe not? I don't know if it's that big problem keeping with v8 instead of using v8+ as default, I have only found it being a limitation once (openmpi requires v8+ and its only optional when building boost). The 32-bit binaries shipped with Solaris 10 still isn't optimized for v8+ even though you can't run Solaris 10 on anything older. From hson at opencsw.org Fri Mar 26 17:06:19 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 26 Mar 2010 17:06:19 +0100 Subject: [csw-maintainers] Runpath menagerie for review In-Reply-To: <4C2F8AE1-FDFF-40E8-8125-7F8A01EFC37B@opencsw.org> References: <75B65782-98D3-4669-9992-39C0F041921B@opencsw.org> <4BACCFD3.7090906@opencsw.org> <4C2F8AE1-FDFF-40E8-8125-7F8A01EFC37B@opencsw.org> Message-ID: <4BACDB7B.6070609@opencsw.org> On 2010-03-26 16:59, Dagobert Michelsen wrote: > Ok, GAR has been adjusted to use these flags now for cc/CC. > SOS11 cc doesn't have it though. But it is no longer used anyway. Must have been introduced in a patch, because on my machines SOS11 have -xnorunpath (or at least 'cc -flags' report it) From dam at opencsw.org Fri Mar 26 17:11:59 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 26 Mar 2010 17:11:59 +0100 Subject: [csw-maintainers] Runpath menagerie for review In-Reply-To: <4BACDB7B.6070609@opencsw.org> References: <75B65782-98D3-4669-9992-39C0F041921B@opencsw.org> <4BACCFD3.7090906@opencsw.org> <4C2F8AE1-FDFF-40E8-8125-7F8A01EFC37B@opencsw.org> <4BACDB7B.6070609@opencsw.org> Message-ID: <76F3BD18-7BAB-4CF4-93EC-B9A63350DA4F@opencsw.org> Hi Roger, Am 26.03.2010 um 17:06 schrieb Roger H?kansson: > On 2010-03-26 16:59, Dagobert Michelsen wrote: >> Ok, GAR has been adjusted to use these flags now for cc/CC. >> SOS11 cc doesn't have it though. But it is no longer used anyway. > > Must have been introduced in a patch, because on my machines SOS11 > have -xnorunpath (or at least 'cc -flags' report it) It is not in the manpage, but I have added it now as the compiler states it knows the flag. Best regards -- Dago From hson at opencsw.org Fri Mar 26 17:31:24 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 26 Mar 2010 17:31:24 +0100 Subject: [csw-maintainers] [csw-users] evince seg fault In-Reply-To: <4BACDB18.1040400@opencsw.org> References: <4BACB0B8.3050408@cmi.univ-mrs.fr> <4BACDB18.1040400@opencsw.org> Message-ID: <4BACE15C.9040305@opencsw.org> On 2010-03-26 17:04, Roger H?kansson wrote: > On 2010-03-26 14:03, Gerard Henry wrote: >> evince comes from CSWevince, 2.22.2 >> >> A ldd on evince shows these strange messages: >> libXext.so.0 (SUNW_1.1) => (version not found) >> libz.so.1 (SUNW_1.1) => (version not found) > > This means that something in the chain was linked to Sun's version > of libXext.so.0 and libz.so.1 "something" is libgdk-x11-2.0.so (libXext) and libpng12.so (libz) From bwalton at opencsw.org Sat Mar 27 02:53:49 2010 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 26 Mar 2010 21:53:49 -0400 Subject: [csw-maintainers] svn release Message-ID: <1269654779-sup-1706@pinkfloyd.chass.utoronto.ca> Hi Guys, Can we get CSWsvn-1.6.6,REV=2010.01.19 out the door? I've been using it on a system here for a few weeks now and it seems good. I'm tired of svn behaving badly (worse than normal?) wrt disappearing logs. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sat Mar 27 03:29:33 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 27 Mar 2010 02:29:33 +0000 Subject: [csw-maintainers] Runpath menagerie for review In-Reply-To: References: Message-ID: 2010/3/25 Philip Brown : > On Thu, Mar 25, 2010 at 3:09 AM, Maciej (Matchek) Blizinski > wrote: >> 2010/3/23 Philip Brown : >>> stuff starting with /optcsw is mostly acceptible. >> >> What about rpath orthography? ?Would you like checkpkg to throw errors >> on the following ones? >> >> '/opt/csw/lib/.' ?(as opposed to '/opt/csw/lib') >> '/opt/csw/X11/lib/' (as opposed to '/opt/csw/X11/lib') > > I'd say yes Done. >> >> Next question: specific architecture entries, for instance: >> >> '/opt/csw/postgresql/lib/sparcv9' >> >> Shouldn't this be '/opt/csw/postgresql/lib/$ISALIST' instead? > > Hmmm... in the more general case, yes. however, since there is one and > only one "64bit" arch for sparc... not really. Hm... I still hesitate to add this special case... >> Next question: What about $ORIGIN? ?In some cases it makes, sense, for >> instance if a 32-bit binary looks into '$ORIGIN/../lib', I guess >> that's fine. ?But if it's a 64-bit binary in /opt/csw/bin/sparcv9 and >> the corresponding library is in /opt/csw/lib/sparcv9, the >> '$ORIGIN/../lib' entry won't help much. > > Oooh, good point. > except what happens if it was an isaexec'd binary? that owuld be the > only exception I might think of, and its probably an invalid > exception. > > >> >> Bad rpath: '$ORIGIN' > > actualy that can be quite okay, if its an RPATH in a library. Done. >> Bad rpath: '/opt/csw/lib/sparcv8plus+vis' > > If it is in an executable specifically compiled for that, then it > might not strictly speaking be "wrong". > > ie: if it was in /opt/csw/bin/sparcv8plus+vis/executable > > >> Bad rpath: '/opt/csw/mysql4//lib/mysql' > > meh.. mysql is a very individual case, so that could be let slip. it > will probably never be recopmiled anyway :) I think that this one didn't match because of the double slash. >> Bad rpath: '/usr/ccs/lib' > > this is not bad. > > >> Bad rpath: '/usr/ccs/lib/sparcv9' > > ditto. > > >> Bad rpath: '/usr/dt/lib' > > not bad. > > >> Bad rpath: '/usr/lib' >> Bad rpath: '/usr/lib/sparcv9' > > ditto. > >> Bad rpath: '/usr/openwin/lib' > > > not bad. All done. From phil at bolthole.com Sat Mar 27 05:45:19 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 26 Mar 2010 21:45:19 -0700 Subject: [csw-maintainers] Runpath menagerie for review In-Reply-To: References: Message-ID: Great! this sounds very useful. thanks for putting in the extra work From hson at opencsw.org Sat Mar 27 05:51:40 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Sat, 27 Mar 2010 05:51:40 +0100 Subject: [csw-maintainers] tcl/tk/expect on testing9s/9x/10x Message-ID: <4BAD8EDC.6090704@opencsw.org> This is a reminder that I'm starting my little project of updating tcl/tk/expect now, so for a while none of them might work as expected on testing9s/9x/10x. I'll let you know when I'm finished. From hson at opencsw.org Sat Mar 27 08:58:37 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Sat, 27 Mar 2010 08:58:37 +0100 Subject: [csw-maintainers] [csw-users] evince seg fault In-Reply-To: <1269608784-sup-4356@pinkfloyd.chass.utoronto.ca> References: <4BACB0B8.3050408@cmi.univ-mrs.fr> <1269608784-sup-4356@pinkfloyd.chass.utoronto.ca> Message-ID: <4BADBAAD.3020205@opencsw.org> On 2010-03-26 14:07, Ben Walton wrote: > Excerpts from Gerard Henry's message of Fri Mar 26 09:03:52 -0400 2010: > >> Unfortunately, CSWlibz is now 1.2.4, is it sufficient to crash >> evince? > > I've been looking at zlib as the cause of breakage in libxml2 as well, > so I suspect this is the issue. > And your suscpicion was correct, its related to the upgrade of zlib, however its libxml2 that needs fixing. From the release notes for libxml2-2.7.7 Bug Fixes: - libxml violates the zlib interface and crashes (Mark Adler) From bwalton at opencsw.org Sat Mar 27 12:32:31 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 27 Mar 2010 07:32:31 -0400 Subject: [csw-maintainers] [csw-users] evince seg fault In-Reply-To: <4BADBAAD.3020205@opencsw.org> References: <4BACB0B8.3050408@cmi.univ-mrs.fr> <1269608784-sup-4356@pinkfloyd.chass.utoronto.ca> <4BADBAAD.3020205@opencsw.org> Message-ID: <1269689478-sup-760@pinkfloyd.chass.utoronto.ca> Excerpts from Roger H?kansson's message of Sat Mar 27 03:58:37 -0400 2010: > Bug Fixes: > - libxml violates the zlib interface and crashes (Mark Adler) Perfect. The 2.7.7 release is just about ready for release. I'll probably push it tomorrow. Thanks for looking at that. I haven't had the time. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert at opencsw.org Sat Mar 27 23:36:57 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 27 Mar 2010 23:36:57 +0100 Subject: [csw-maintainers] svn release In-Reply-To: <1269654779-sup-1706@pinkfloyd.chass.utoronto.ca> References: <1269654779-sup-1706@pinkfloyd.chass.utoronto.ca> Message-ID: <6af4271003271536icfa03a4ya2e7e685a032e069@mail.gmail.com> could you give the 1.6.9 release in testing a try please? the releases before seem to be somehow broken wrt merge tracking, which then lead to quite a lot of releases, and then even to non-releases (1.6.7, 1.6.8). rupert On Sat, Mar 27, 2010 at 02:53, Ben Walton wrote: > > Hi Guys, > > Can we get CSWsvn-1.6.6,REV=2010.01.19 out the door? ?I've been using > it on a system here for a few weeks now and it seems good. ?I'm tired > of svn behaving badly (worse than normal?) wrt disappearing logs. > > Thanks > -Ben > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From bwalton at opencsw.org Sun Mar 28 04:01:24 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 27 Mar 2010 22:01:24 -0400 Subject: [csw-maintainers] svn release In-Reply-To: <6af4271003271536icfa03a4ya2e7e685a032e069@mail.gmail.com> References: <1269654779-sup-1706@pinkfloyd.chass.utoronto.ca> <6af4271003271536icfa03a4ya2e7e685a032e069@mail.gmail.com> Message-ID: <1269741185-sup-2947@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Sat Mar 27 18:36:57 -0400 2010: > could you give the 1.6.9 release in testing a try please? You've got it. I've just pushed the updated version onto the box that was running 1.6.2,REV=2010.01.19. I'll ping the user and have him ensure it's working for him. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From hson at opencsw.org Sun Mar 28 18:53:04 2010 From: hson at opencsw.org (=?UTF-8?B?Um9nZXIgSMOla2Fuc3Nvbg==?=) Date: Sun, 28 Mar 2010 18:53:04 +0200 Subject: [csw-maintainers] [csw-users] evince seg fault In-Reply-To: <1269689478-sup-760@pinkfloyd.chass.utoronto.ca> References: <4BACB0B8.3050408@cmi.univ-mrs.fr> <1269608784-sup-4356@pinkfloyd.chass.utoronto.ca> <4BADBAAD.3020205@opencsw.org> <1269689478-sup-760@pinkfloyd.chass.utoronto.ca> Message-ID: <4BAF8970.1010002@opencsw.org> On 2010-03-27 12:32, Ben Walton wrote: > Excerpts from Roger H?kansson's message of Sat Mar 27 03:58:37 -0400 2010: > >> Bug Fixes: >> - libxml violates the zlib interface and crashes (Mark Adler) > > Perfect. The 2.7.7 release is just about ready for release. I'll > probably push it tomorrow. > > Thanks for looking at that. I haven't had the time. I've verified that libxm2-2.7.7 doesn't crash evince (however, for me it crashed later on since I haven't got a working dbus) From hson at opencsw.org Sun Mar 28 21:58:36 2010 From: hson at opencsw.org (=?UTF-8?B?Um9nZXIgSMOla2Fuc3Nvbg==?=) Date: Sun, 28 Mar 2010 21:58:36 +0200 Subject: [csw-maintainers] Runpath menagerie for review In-Reply-To: References: Message-ID: <4BAFB4EC.9000800@opencsw.org> On 2010-03-27 03:29, Maciej (Matchek) Blizinski wrote: > > All done. > I found a little problem with the new checks. First a legacy file had an error. -------------------------- There were errors reported. If you know they are false positives, you can override them: CHECKPKG_OVERRIDES_CSWtcl += file-with-bad-content|/export/medusa|root/opt/csw/lib/libtclstub8.4.a -------------------------- Ok, so I added that override, however now checkpkg complains about the override file -------------------------- There were errors reported. If you know they are false positives, you can override them: CHECKPKG_OVERRIDES_CSWtcl += file-with-bad-content|/export/medusa|root/opt/csw/share/checkpkg/overrides/tcl -------------------------- Ok, that override works, but it seems like you could skip checking the override files... From hson at opencsw.org Sun Mar 28 23:25:46 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Sun, 28 Mar 2010 23:25:46 +0200 Subject: [csw-maintainers] tcl/tk 8.5.8 and expect 5.43 Message-ID: <4BAFC95A.7000405@opencsw.org> I have built and installed tcl/tk 8.5.8 and expect 5.43 on testing9s/9x/10x and would appreciate if those of you who know that you are using packages which use tcl/tk or expect, could test them to verify that they are working properly. The packages are downloadable from http://mirror.opencsw.org/experimental.html#hson Please report any problem you encounter. From maciej at opencsw.org Mon Mar 29 01:58:23 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 29 Mar 2010 00:58:23 +0100 Subject: [csw-maintainers] Overriding the file-with-bad-content tag Message-ID: 2010/3/28 Roger H?kansson : > Ok, so I added that override, however now checkpkg complains about the > override file > -------------------------- > There were errors reported. > If you know they are false positives, you can override them: > CHECKPKG_OVERRIDES_CSWtcl += > file-with-bad-content|/export/medusa|root/opt/csw/share/checkpkg/overrides/tcl > -------------------------- > > Ok, that override works, but it seems like you could skip checking the > override files... You're right, the override file should be exempt from this particular check. From bwalton at opencsw.org Mon Mar 29 02:17:32 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 28 Mar 2010 20:17:32 -0400 Subject: [csw-maintainers] [csw-users] evince seg fault In-Reply-To: <4BAF8970.1010002@opencsw.org> References: <4BACB0B8.3050408@cmi.univ-mrs.fr> <1269608784-sup-4356@pinkfloyd.chass.utoronto.ca> <4BADBAAD.3020205@opencsw.org> <1269689478-sup-760@pinkfloyd.chass.utoronto.ca> <4BAF8970.1010002@opencsw.org> Message-ID: <1269821793-sup-1573@pinkfloyd.chass.utoronto.ca> Excerpts from Roger H?kansson's message of Sun Mar 28 12:53:04 -0400 2010: > I've verified that libxm2-2.7.7 doesn't crash evince (however, for me it > crashed later on since I haven't got a working dbus) Ok. I'm re-rolling the release build with SOS12 for sol9. Will hit testing later tonight. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Mon Mar 29 18:23:13 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 29 Mar 2010 09:23:13 -0700 Subject: [csw-maintainers] [csw-users] evince seg fault In-Reply-To: <4BACE15C.9040305@opencsw.org> References: <4BACB0B8.3050408@cmi.univ-mrs.fr> <4BACDB18.1040400@opencsw.org> <4BACE15C.9040305@opencsw.org> Message-ID: On Fri, Mar 26, 2010 at 9:31 AM, Roger H?kansson wrote: > On 2010-03-26 17:04, Roger H?kansson wrote: >> >> On 2010-03-26 14:03, Gerard Henry wrote: >>> >>> evince comes from CSWevince, 2.22.2 >>> >>> A ldd on evince shows these strange messages: >>> libXext.so.0 (SUNW_1.1) => (version not found) >>> libz.so.1 (SUNW_1.1) => (version not found) >> >> This means that something in the chain was linked to Sun's version >> of libXext.so.0 and libz.so.1 > > "something" is libgdk-x11-2.0.so (libXext) and libpng12.so (libz) > when and if someone rebuilds these... I would like to request that, if possible, you provide two versions of it. one linked against sun libs and shipped in /opt/csw/lib. the other linked against CSW libs, and shipped in /opt/csw/X11/lib From dam at opencsw.org Mon Mar 29 21:01:21 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 29 Mar 2010 21:01:21 +0200 Subject: [csw-maintainers] [csw-users] evince seg fault In-Reply-To: References: <4BACB0B8.3050408@cmi.univ-mrs.fr> <4BACDB18.1040400@opencsw.org> <4BACE15C.9040305@opencsw.org> Message-ID: <9D51BC30-8CEB-4320-A8AE-F02953651B6E@opencsw.org> Hi Phil, Am 29.03.2010 um 18:23 schrieb Philip Brown: > On Fri, Mar 26, 2010 at 9:31 AM, Roger H?kansson > wrote: >> On 2010-03-26 17:04, Roger H?kansson wrote: >>> >>> On 2010-03-26 14:03, Gerard Henry wrote: >>>> >>>> evince comes from CSWevince, 2.22.2 >>>> >>>> A ldd on evince shows these strange messages: >>>> libXext.so.0 (SUNW_1.1) => (version not found) >>>> libz.so.1 (SUNW_1.1) => (version not found) >>> >>> This means that something in the chain was linked to Sun's version >>> of libXext.so.0 and libz.so.1 >> >> "something" is libgdk-x11-2.0.so (libXext) and libpng12.so (libz) > > when and if someone rebuilds these... I would like to request that, if > possible, you provide two versions of it. > one linked against sun libs and shipped in /opt/csw/lib. > the other linked against CSW libs, and shipped in /opt/csw/X11/lib It is already on my todo list... Best regards -- Dago From bwalton at opencsw.org Tue Mar 30 02:20:55 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 29 Mar 2010 20:20:55 -0400 Subject: [csw-maintainers] ibiblio catalog not signed Message-ID: <1269908435-sup-1535@pinkfloyd.chass.utoronto.ca> Seems we've had another glitch. Phil? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From phil at bolthole.com Tue Mar 30 02:49:44 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 29 Mar 2010 17:49:44 -0700 Subject: [csw-maintainers] ibiblio catalog not signed In-Reply-To: <1269908435-sup-1535@pinkfloyd.chass.utoronto.ca> References: <1269908435-sup-1535@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Mar 29, 2010 at 5:20 PM, Ben Walton wrote: > > Seems we've had another glitch. ?Phil? > odd. where are you looking? our master catalogs appear to all be signed to me, going by visual inspection. From bwalton at opencsw.org Tue Mar 30 03:27:42 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 29 Mar 2010 21:27:42 -0400 Subject: [csw-maintainers] ibiblio catalog not signed In-Reply-To: References: <1269908435-sup-1535@pinkfloyd.chass.utoronto.ca> Message-ID: <1269912402-sup-9225@pinkfloyd.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Mar 29 20:49:44 -0400 2010: > odd. > where are you looking? User error. I was pulling in the updated testing catalog and thought I'd also grabbed a fresh copy of the current catalog. I was using a stale current catalog. Sorry for the noise. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From hson at opencsw.org Tue Mar 30 06:26:14 2010 From: hson at opencsw.org (=?UTF-8?B?Um9nZXIgSMOla2Fuc3Nvbg==?=) Date: Tue, 30 Mar 2010 06:26:14 +0200 Subject: [csw-maintainers] Undefined symbol __sync_fetch_and_add_4. In-Reply-To: References: <4AF6F0A4.60205@opencsw.org> Message-ID: <4BB17D66.4050804@opencsw.org> On 2009-12-22 11:25, Maciej (Matchek) Blizinski wrote: > 2009/11/8 Trygve Laugst?l: >> I'm trying to build freehdl on build8s, but when it's linking the final >> binary I'm getting an error about a missing symbol "__sync_fetch_and_add_4" >> >> This seems to be a function that use atomic instructions that's not on i386 >> and sparc 8 so i686 has to be used. I assume the problem is similar on >> sparc, but I have no idea which flags to use. Does anyone know? >> >> http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Atomic-Builtins.html#Atomic-Builtins > > I just saw the same problem: > ... > Undefined first referenced > symbol in file > __sync_fetch_and_add_4 > /home/maciej/src/opencsw/pkg/googletest/trunk/work/build-isa-sparcv8/gtest-1.4.0/lib/.libs/libgtest.so I've stumbled upon the same problem, but also found the way to solve it. Instead of having -mcpu=v8 as a compiler option, replacing it with -m32 will solve it. From dam at opencsw.org Tue Mar 30 07:25:30 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 30 Mar 2010 07:25:30 +0200 Subject: [csw-maintainers] Undefined symbol __sync_fetch_and_add_4. In-Reply-To: <4BB17D66.4050804@opencsw.org> References: <4AF6F0A4.60205@opencsw.org> <4BB17D66.4050804@opencsw.org> Message-ID: <56F45D6F-8753-4194-951D-7395134E03EF@opencsw.org> Hi Roger, Am 30.03.2010 um 06:26 schrieb Roger H?kansson: > On 2009-12-22 11:25, Maciej (Matchek) Blizinski wrote: >> 2009/11/8 Trygve Laugst?l: >>> I'm trying to build freehdl on build8s, but when it's linking the >>> final >>> binary I'm getting an error about a missing symbol >>> "__sync_fetch_and_add_4" >>> >>> This seems to be a function that use atomic instructions that's >>> not on i386 >>> and sparc 8 so i686 has to be used. I assume the problem is >>> similar on >>> sparc, but I have no idea which flags to use. Does anyone know? >>> >>> http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Atomic-Builtins.html#Atomic-Builtins >> >> I just saw the same problem: >> > ... >> Undefined first referenced >> symbol in file >> __sync_fetch_and_add_4 >> /home/maciej/src/opencsw/pkg/googletest/trunk/work/build-isa- >> sparcv8/gtest-1.4.0/lib/.libs/libgtest.so > > I've stumbled upon the same problem, but also found the way to solve > it. > > Instead of having -mcpu=v8 as a compiler option, replacing it with - > m32 will solve it. Was this with GAR? Then I would suggest we change the default to the most sane value giving the least troubles. Best regards -- Dago From hson at opencsw.org Tue Mar 30 08:07:06 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Tue, 30 Mar 2010 08:07:06 +0200 Subject: [csw-maintainers] Undefined symbol __sync_fetch_and_add_4. In-Reply-To: <56F45D6F-8753-4194-951D-7395134E03EF@opencsw.org> References: <4AF6F0A4.60205@opencsw.org> <4BB17D66.4050804@opencsw.org> <56F45D6F-8753-4194-951D-7395134E03EF@opencsw.org> Message-ID: <4BB1950A.9060204@opencsw.org> On 2010-03-30 07:25, Dagobert Michelsen wrote: >> I've stumbled upon the same problem, but also found the way to solve it. >> >> Instead of having -mcpu=v8 as a compiler option, replacing it with >> -m32 will solve it. > > Was this with GAR? Yup. > Then I would suggest we change the default to the most > sane value giving the least troubles. Well, I don't know if this change have any other implications, but it might be worth checking. From dam at opencsw.org Wed Mar 31 16:19:31 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 31 Mar 2010 16:19:31 +0200 Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 - Intel In-Reply-To: References: <4BB3247C.8040104@clamav.net> <4BB3423C.3050401@clamav.net> Message-ID: Hi Peter, Am 31.03.2010 um 16:15 schrieb Peter Bonivart: > 2010/3/31 T?r?k Edwin : >> I thought you were, sorry for the confusion. Can you forward my >> mail to >> the gcc4 maintainer? > > Our gcc4 maintainer is on sabbatical, I'll try to contact him or > someone else will have a go at fixing this. Thanks a lot for your > efforts. I already bumped gcc4 to the latest versions and it compiles (although it takes a day or so), merging is tbd. There is at least one other problem with gcc4: The current implementation uses isaexec to decide Solaris 8 vs. 10. If Solaris 10 x86 is run under 32 bit kernel this model doesn't work and I don't know enough of gcc technics to resolve this. I committed everything I did. Best regards -- Dago From bonivart at opencsw.org Wed Mar 31 16:20:13 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 31 Mar 2010 16:20:13 +0200 Subject: [csw-maintainers] Fwd: ClamAV 0.96 on Solaris9/10 - Intel In-Reply-To: <4BB3247C.8040104@clamav.net> References: <4BB3247C.8040104@clamav.net> Message-ID: The below forwarded message was sent from a Clam Antivirus developer that uses our build farm to test their Solaris builds. I contacted him about difficulties building the latest 0.96rc2 on Solaris 9 i386 and this is what he found. Peter Felecan added this about differences between the gcc3 and gcc4 packages: > The lesson from your diagnosis is that an includes fixing must be done at > install time of the gcc4 package; if that's not the case, the fixing can > be called on the system on which the package is installed. > > As I'm not the maintainer of the gcc4 packages, the only thing for which > I can help is to say that for gcc3 the includes fixing is done at > installation time. Are you Mike willing to take a look at it or should someone else try to fix it? /peter ---------- Forwarded message ---------- From: T?r?k Edwin Date: 2010/3/31 Subject: ClamAV 0.96 on Solaris9/10 - Intel To: Peter Bonivart Cc: Peter FELECAN , buildfarm at opencsw.org Hi Peter, First of all I found the problem with the broken gcc4 on Solaris9 on the buildfarm: you have a gcc4 built on Solaris8, and it has fix-includes from Solaris8 headers! $ cat >x.c #include #include If I include it is missing upad128_t needed by signal.h: $ /opt/csw/gcc4/bin/g++ -E x.c | grep upad128 ?upad128_t fx_xmm[8]; ?upad128_t __fx_ign2[14]; ? upad128_t xmm[8]; However the type is there: $ /opt/csw/gcc4/bin/g++ -E /usr/include/sys/types.h|grep upad128 } upad128_t; Then I found that on Solaris9 (current9x) you are using the Solaris8 headers: /opt/csw/gcc4/lib/gcc/i386-pc-solaris2.8/4.3.3/include-fixed/sys/types.h /opt/csw/gcc4/bin/gcc -v Using built-in specs. Target: i386-pc-solaris2.8 So when you built GCC4 on Solaris8, it has run fix-includes on sys/types.h, and it is using that instead of system's sys/types.h. That works fine on Solaris8 (I assume), however is wrong for Solaris9 (which has a different sys/types.h header). Although the gcc4 from Solaris8 is probably binary compatible with Solaris9, using a header from Solaris8 on Solaris9 is certainly not compatible. So you need to build GCC4 on Solaris9, so that it runs fix-includes on the Solaris9 header. Once you have a GCC4 built on Solaris9 you should be able to use that to build ClamAV. For reference here is the error you get with gcc4 on Solaris9 $ /opt/csw/gcc4/bin/g++ x.c In file included from /opt/csw/gcc4/lib/gcc/i386-pc-solaris2.8/4.3.3/include-fixed/sys/reg.h:22, ? ? ? ? ? ? ? ? from /usr/include/sys/regset.h:24, ? ? ? ? ? ? ? ? from /usr/include/sys/ucontext.h:21, ? ? ? ? ? ? ? ? from /opt/csw/gcc4/lib/gcc/i386-pc-solaris2.8/4.3.3/include-fixed/sys/signal.h:252, ? ? ? ? ? ? ? ? from /opt/csw/gcc4/lib/gcc/i386-pc-solaris2.8/4.3.3/include-fixed/signal.h:36, ? ? ? ? ? ? ? ? from x.c:2: /usr/include/ia32/sys/reg.h:300: error: 'upad128_t' does not name a type /usr/include/ia32/sys/reg.h:301: error: 'upad128_t' does not name a type /usr/include/ia32/sys/reg.h:331: error: 'upad128_t' does not name a type BTW everything is fine when building on Solaris10/Intel (and everything is fine on Solaris8,9,10/Sparc): I tested this: http://git.clamav.net/gitweb?p=clamav-devel.git;a=snapshot;h=c5fb062ec3a22b2e35fca555cb59d4a5646fef2e;sf=tgz Solaris10/Intel: $ export PATH=/usr/bin:/usr/ccs/bin:/opt/csw/bin $ export LD_LIBRARY_PATH=/opt/csw/gcc4/lib $ ./configure CC=/opt/csw/gcc4/bin/gcc CXX=/opt/csw/gcc4/bin/g++ --disable-clamav --enable-llvm --enable-check --with-libcheck-prefix=/home/edwin/checkx $ gmake -j2 $ gmake check -j2 .... PASS: llvmcheck.sh ================== All 6 tests passed ================== .... PASS: check_freshclam.sh PASS: check_sigtool.sh SKIP: check_unit_vg.sh PASS: check1_clamscan.sh PASS: check_clamav PASS: check2_clamd.sh PASS: check3_clamd.sh SKIP: check5_clamd_vg.sh SKIP: check6_clamd_vg.sh SKIP: check7_clamd_hg.sh SKIP: check8_clamd_hg.sh PASS: check4_clamd.sh ====================== All 7 tests passed (5 tests were not run) ====================== Best regards, --Edwin -- /peter From hson at opencsw.org Wed Mar 31 16:36:28 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Wed, 31 Mar 2010 16:36:28 +0200 Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 - Intel In-Reply-To: References: <4BB3247C.8040104@clamav.net> <4BB3423C.3050401@clamav.net> Message-ID: <4BB35DEC.4020805@opencsw.org> On 2010-03-31 16:19, Dagobert Michelsen wrote: > There is at least one other problem with gcc4: The current > implementation uses isaexec to decide Solaris 8 vs. 10. > If Solaris 10 x86 is run under 32 bit kernel this model > doesn't work and I don't know enough of gcc technics to > resolve this. I committed everything I did. Since gcc/g++ is so OS bound, isn't it best to simply do one package for each OS version? And also only include what is supported on that OS (i.e no 64-bit on Solaris 8 x86 using binaries from Solaris 10) From dam at opencsw.org Wed Mar 31 16:46:37 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 31 Mar 2010 16:46:37 +0200 Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 - Intel In-Reply-To: <4BB35DEC.4020805@opencsw.org> References: <4BB3247C.8040104@clamav.net> <4BB3423C.3050401@clamav.net> <4BB35DEC.4020805@opencsw.org> Message-ID: Hi Roger, Am 31.03.2010 um 16:36 schrieb Roger H?kansson: > On 2010-03-31 16:19, Dagobert Michelsen wrote: >> There is at least one other problem with gcc4: The current >> implementation uses isaexec to decide Solaris 8 vs. 10. >> If Solaris 10 x86 is run under 32 bit kernel this model >> doesn't work and I don't know enough of gcc technics to >> resolve this. I committed everything I did. > > Since gcc/g++ is so OS bound, isn't it best to simply do one package > for each OS version? And also only include what is supported on that > OS (i.e no 64-bit on Solaris 8 x86 using binaries from Solaris 10) +1 from me. But it breaks the long-hated NFS-for-all. Best regards -- Dago From hson at opencsw.org Wed Mar 31 16:54:03 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Wed, 31 Mar 2010 16:54:03 +0200 Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 - Intel In-Reply-To: References: <4BB3247C.8040104@clamav.net> <4BB3423C.3050401@clamav.net> <4BB35DEC.4020805@opencsw.org> Message-ID: <4BB3620B.9090105@opencsw.org> On 2010-03-31 16:46, Dagobert Michelsen wrote: >> Since gcc/g++ is so OS bound, isn't it best to simply do one package >> for each OS version? And also only include what is supported on that >> OS (i.e no 64-bit on Solaris 8 x86 using binaries from Solaris 10) > > +1 from me. But it breaks the long-hated NFS-for-all. Anyone sharing software between OS releases over NFS is asking for trouble. I've always shared /opt (in general, not only /opt/csw) over NFS, but always had one share for each OS release and one "package master" (host which pkgrm/pkgadd and patching is run on), and I have neved heard anyone even try such a setup... If we're not able to push OS-specific releases, why is there even a separation on the mirrors and support for it in pkg-get/pkgutil? From pfelecan at opencsw.org Wed Mar 31 18:28:29 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 31 Mar 2010 18:28:29 +0200 Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 - Intel In-Reply-To: <4BB35DEC.4020805@opencsw.org> ("Roger =?iso-8859-1?Q?H=E5kan?= =?iso-8859-1?Q?sson=22's?= message of "Wed, 31 Mar 2010 16:36:28 +0200") References: <4BB3247C.8040104@clamav.net> <4BB3423C.3050401@clamav.net> <4BB35DEC.4020805@opencsw.org> Message-ID: Roger H?kansson writes: > On 2010-03-31 16:19, Dagobert Michelsen wrote: >> There is at least one other problem with gcc4: The current >> implementation uses isaexec to decide Solaris 8 vs. 10. >> If Solaris 10 x86 is run under 32 bit kernel this model >> doesn't work and I don't know enough of gcc technics to >> resolve this. I committed everything I did. > > Since gcc/g++ is so OS bound, isn't it best to simply do one package > for each OS version? And also only include what is supported on that > OS (i.e no 64-bit on Solaris 8 x86 using binaries from Solaris 10) gcc is not so OS bound (if you have specifics I'm eager to know them). I allways succeeded to release a unique package, OS release wise, for gcc2, gcc3 and gcc4. You can isolate quite easily the release dependencies. Anyhow, given that we do not support anymore Solaris 8 and quite soon Solaris 9 why bother. -- Peter From hson at opencsw.org Wed Mar 31 18:41:09 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Wed, 31 Mar 2010 18:41:09 +0200 Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 - Intel In-Reply-To: References: <4BB3247C.8040104@clamav.net> <4BB3423C.3050401@clamav.net> <4BB35DEC.4020805@opencsw.org> Message-ID: <4BB37B25.2050306@opencsw.org> On 2010-03-31 18:28, Peter FELECAN wrote: >> Since gcc/g++ is so OS bound, isn't it best to simply do one package >> for each OS version? And also only include what is supported on that >> OS (i.e no 64-bit on Solaris 8 x86 using binaries from Solaris 10) > > gcc is not so OS bound (if you have specifics I'm eager to know them). Well, they have target-OS compiled into the binaries, i.e 'gcc -v' gives 'Target: i386-pc-solaris2.8' (on x86) regardless of actual OS >I > allways succeeded to release a unique package, OS release wise, for > gcc2, gcc3 and gcc4. You can isolate quite easily the release > dependencies. Anyhow, given that we do not support anymore Solaris 8 and > quite soon Solaris 9 why bother. Releasing separate packages should be easier than fixing the broken ones... From pfelecan at opencsw.org Wed Mar 31 19:16:53 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 31 Mar 2010 19:16:53 +0200 Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 - Intel In-Reply-To: <4BB37B25.2050306@opencsw.org> ("Roger =?iso-8859-1?Q?H=E5kan?= =?iso-8859-1?Q?sson=22's?= message of "Wed, 31 Mar 2010 18:41:09 +0200") References: <4BB3247C.8040104@clamav.net> <4BB3423C.3050401@clamav.net> <4BB35DEC.4020805@opencsw.org> <4BB37B25.2050306@opencsw.org> Message-ID: Roger H?kansson writes: > On 2010-03-31 18:28, Peter FELECAN wrote: >>> Since gcc/g++ is so OS bound, isn't it best to simply do one package >>> for each OS version? And also only include what is supported on that >>> OS (i.e no 64-bit on Solaris 8 x86 using binaries from Solaris 10) >> >> gcc is not so OS bound (if you have specifics I'm eager to know them). > > Well, they have target-OS compiled into the binaries, i.e 'gcc -v' > gives 'Target: i386-pc-solaris2.8' (on x86) regardless of actual OS That only a epiphenomena and doesn't imply a misfeature. >>I >> allways succeeded to release a unique package, OS release wise, for >> gcc2, gcc3 and gcc4. You can isolate quite easily the release >> dependencies. Anyhow, given that we do not support anymore Solaris 8 and >> quite soon Solaris 9 why bother. > > Releasing separate packages should be easier than fixing the broken ones... The issue is only with fixing the includes and it can be done manually; BTW, it *must* be done manually when you upgrade your system's headers. Consequently, I don't see how releasing separate packages give a better solution. Going back to the initial issue, that of Clamav compilation, fix the includes on the build systems and everything will work, hopefully, well. -- Peter From hson at opencsw.org Wed Mar 31 20:19:25 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Wed, 31 Mar 2010 20:19:25 +0200 Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 - Intel In-Reply-To: References: <4BB3247C.8040104@clamav.net> <4BB3423C.3050401@clamav.net> <4BB35DEC.4020805@opencsw.org> <4BB37B25.2050306@opencsw.org> Message-ID: <4BB3922D.3010407@opencsw.org> On 2010-03-31 19:16, Peter FELECAN wrote: >>> gcc is not so OS bound (if you have specifics I'm eager to know them). >> >> Well, they have target-OS compiled into the binaries, i.e 'gcc -v' >> gives 'Target: i386-pc-solaris2.8' (on x86) regardless of actual OS > > That only a epiphenomena and doesn't imply a misfeature. Not in it self, no, but when others start using that as basis for optimizing/configuring their software things can go seriously wrong. I've seen several packages where they use the output from gcc to figure out which OS they are running and what features they can use. >> Releasing separate packages should be easier than fixing the broken ones... > > The issue is only with fixing the includes and it can be done manually; > BTW, it *must* be done manually when you upgrade your system's > headers. Consequently, I don't see how releasing separate packages give a > better solution. Yes, fixing the includes should always be done regardless of whether its a multi-OS release or not. But I still argue that gcc is one of the packages where we should ship separate packages for each release. From pfelecan at opencsw.org Wed Mar 31 20:26:33 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 31 Mar 2010 20:26:33 +0200 Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 - Intel In-Reply-To: <4BB3922D.3010407@opencsw.org> ("Roger =?iso-8859-1?Q?H=E5kan?= =?iso-8859-1?Q?sson=22's?= message of "Wed, 31 Mar 2010 20:19:25 +0200") References: <4BB3247C.8040104@clamav.net> <4BB3423C.3050401@clamav.net> <4BB35DEC.4020805@opencsw.org> <4BB37B25.2050306@opencsw.org> <4BB3922D.3010407@opencsw.org> Message-ID: Roger H?kansson writes: > On 2010-03-31 19:16, Peter FELECAN wrote: >>>> gcc is not so OS bound (if you have specifics I'm eager to know them). >>> >>> Well, they have target-OS compiled into the binaries, i.e 'gcc -v' >>> gives 'Target: i386-pc-solaris2.8' (on x86) regardless of actual OS >> >> That only a epiphenomena and doesn't imply a misfeature. > > Not in it self, no, but when others start using that as basis for > optimizing/configuring their software things can go seriously > wrong. I've seen several packages where they use the output from gcc > to figure out which OS they are running and what features they can > use. Can you give one or more examples? >>> Releasing separate packages should be easier than fixing the broken ones... >> >> The issue is only with fixing the includes and it can be done manually; >> BTW, it *must* be done manually when you upgrade your system's >> headers. Consequently, I don't see how releasing separate packages give a >> better solution. > > Yes, fixing the includes should always be done regardless of whether > its a multi-OS release or not. But I still argue that gcc is one of > the packages where we should ship separate packages for each release. What will solve that? Why? Arguments of the arguing, please. -- Peter From hson at opencsw.org Wed Mar 31 20:31:26 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Wed, 31 Mar 2010 20:31:26 +0200 Subject: [csw-maintainers] [csw-buildfarm] ClamAV 0.96 on Solaris9/10 - Intel In-Reply-To: References: <4BB3247C.8040104@clamav.net> <4BB3423C.3050401@clamav.net> <4BB35DEC.4020805@opencsw.org> <4BB37B25.2050306@opencsw.org> <4BB3922D.3010407@opencsw.org> Message-ID: <4BB394FE.7070003@opencsw.org> On 2010-03-31 20:26, Peter FELECAN wrote: >> Not in it self, no, but when others start using that as basis for >> optimizing/configuring their software things can go seriously >> wrong. I've seen several packages where they use the output from gcc >> to figure out which OS they are running and what features they can >> use. > > Can you give one or more examples? Nah, I tend to forget the names of software faster than you can say... > What will solve that? Why? Arguments of the arguing, please. You have already gotten some, seems enough for me. From dam at baltic-online.de Fri Mar 26 14:13:56 2010 From: dam at baltic-online.de (Dagobert Michelsen) Date: Fri, 26 Mar 2010 14:13:56 +0100 Subject: [csw-maintainers] Updated Perl module handling in GAR Message-ID: <8943BB62-641D-4DBD-B62E-C68CE7B14317@baltic-online.de> Hi, with r9382 the Perl module handling has beed modified as discussed. The description is now automatically set to - : e.g. pm_xmlparser - XML-Parser: A module for parsing XML documents Additionally, the pkginfo(4) has an additional field PERL_MODULE_NAME which holds same as above. This allows safe detection of packages containing Perl modules and associate them with their CPAN name. This field is not shown by default, but can be queried with pkgparam. Best regards -- Dago