From maciej at opencsw.org Mon Feb 1 16:22:32 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 1 Feb 2010 15:22:32 +0000 Subject: [csw-maintainers] An overrides file inside a package Message-ID: I'm meditating over the overrides mechanism for checkpkg. Since checkpkg examines a ready .pkg file, the overrides list should be included inside it. Where should it go? Trygve has suggested using the same mechanism in which postinstall / preinstall etc. files are handled. The main requirement is that when the package gets transformed into the directory format, the file needs to be easily findable, in the same manner the depends file is. How would you do this? Maciej From dam at opencsw.org Mon Feb 1 16:31:27 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 1 Feb 2010 16:31:27 +0100 Subject: [csw-maintainers] An overrides file inside a package In-Reply-To: References: Message-ID: <39CD7248-E712-43A2-A85C-DE01D748E1ED@opencsw.org> Hi Maciej, Am 01.02.2010 um 16:22 schrieb Maciej (Matchek) Blizinski: > I'm meditating over the overrides mechanism for checkpkg. Since > checkpkg examines a ready .pkg file, the overrides list should be > included inside it. Where should it go? Trygve has suggested using > the same mechanism in which postinstall / preinstall etc. files are > handled. The main requirement is that when the package gets > transformed into the directory format, the file needs to be easily > findable, in the same manner the depends file is. How would you do > this? Does the information really belong *inside* the package to mark the expected "flaws"? If yes install/ is a good place, otherwise we could add this as GAR variable and pass it as argument to the checkpkg invocation. Best regards -- Dago From maciej at opencsw.org Mon Feb 1 16:37:10 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 1 Feb 2010 15:37:10 +0000 Subject: [csw-maintainers] An overrides file inside a package In-Reply-To: <39CD7248-E712-43A2-A85C-DE01D748E1ED@opencsw.org> References: <39CD7248-E712-43A2-A85C-DE01D748E1ED@opencsw.org> Message-ID: On Mon, Feb 1, 2010 at 3:31 PM, Dagobert Michelsen wrote: > Does the information really belong *inside* the package to mark > the expected "flaws"? If it's not hard to stick it in, I don't see why not. > If yes install/ is a good place, otherwise > we could add this as GAR variable and pass it as argument to the > checkpkg invocation. This would work well for an invocation from GAR, but it would mean that you have to also pass it when running checkpkg by hand. Having the overrides file inside the package seems better to me. - easy to run checkpkg by hand - binds certain version of the overrides file with the package. If the overrides file was external, it could be out of sync with the package, so the maintainer wouldn't know whether it failed because there's an actual error, or a wrong version of the overrides file was used at this particular run of checkpkg. From dam at opencsw.org Mon Feb 1 17:58:13 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 1 Feb 2010 17:58:13 +0100 Subject: [csw-maintainers] Now active: project-specific experimental catalog Message-ID: Hi folks, the first version of the experimental catalog is there made from the packages in /home/experimental/ Locally the catalogs are /export/mirror/opencsw/experimental/ For starters I have made a project for each maintainer and copied his packages from /home/testing into it. The catalogs are an overlay over current, so the ugly install-stuff should be much smoother now. The webpage can be accessed at The catalog generation still runs, please make sure the catalog you are looking for has been generated: Feedback as always welcome! Best regards -- Dago From phil at bolthole.com Mon Feb 1 18:09:50 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 1 Feb 2010 09:09:50 -0800 Subject: [csw-maintainers] Now active: project-specific experimental catalog In-Reply-To: References: Message-ID: On Mon, Feb 1, 2010 at 8:58 AM, Dagobert Michelsen wrote: > Hi folks, > > the first version of the experimental catalog is there made from > the packages in > ?/home/experimental/ nice! From ellson at opencsw.org Mon Feb 1 19:33:42 2010 From: ellson at opencsw.org (John Ellson) Date: Mon, 01 Feb 2010 13:33:42 -0500 Subject: [csw-maintainers] Wrong Maintainer: Fwd: [svn] GraphViz upstream update notification Message-ID: <4B671E86.5050802@opencsw.org> I have received this message in error, and I'm not sure who to contact? I am the maintainer of "graphviz", but I am not the maintainer of this "GraphViz" perl extension. I'm guessing this problem has to do with not recognizing the case differences? Would whoever fixes this please also add a: "In case of problems, contact: real_person at opencsw.org" message to the robot email, please? John -------- Original Message -------- Subject: [svn] GraphViz upstream update notification Date: Mon, 1 Feb 2010 11:59:41 +0100 (CET) From: Upstream Package Watch To: ellson at opencsw.org Hello dear GraphViz maintainer, The upstream notification job has detected the availability of new files for GraphViz. The following upstream file(s): GraphViz-2.04.tar.gz is/are available at the following url(s): http://search.cpan.org/CPAN/authors/id/L/LB/LBROCARD/ ftp://ftp.nrc.ca/pub/CPAN/authors/id/L/LB/LBROCARD/ ftp://ftp.nas.nasa.gov/pub/perl/CPAN/authors/id/L/LB/LBROCARD/ http://mirrors.ibiblio.org/pub/mirrors/CPAN/authors/id/L/LB/LBROCARD/ ftp://cpan.pair.com/pub/CPAN/authors/id/L/LB/LBROCARD/ http://mirrors.kernel.org/cpan/authors/id/L/LB/LBROCARD/ Please consider updating your package. -- Kindest regards upstream notification job -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at bolthole.com Mon Feb 1 21:31:18 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 1 Feb 2010 12:31:18 -0800 Subject: [csw-maintainers] cswclassutils: location of template init scripts Message-ID: Revisiting a topic that has come up a few times, but I think people have more awareness of now: currently, our wiki for cswclassutils suggests the initial location for the init script should be INITSMF = /etc/opt/csw/init.d/cswfoo I think it would be better for our users, if we standardize on a location under /opt/csw For example, /opt/csw/etc/init.d This would be beneficial in multiple ways: 1. It makes it a teenie bit easier to support NFS-shared /opt/csw 2. It makes it possible to support sparse zones, where /opt/csw is "sparse" in addition to /usr, etc. I dont see any drawbacks. Additionally, I think we should write up that the location is presumed to be READ-ONLY, and that any tweaking that needs to be done, should be facilitated by referencing some other configuration script, either directly, or indirectly. (An example of the "indirect" case, would be when the program it calls, already references some config file that covers all startup options) Comments, please? From william at wbonnet.net Mon Feb 1 22:26:40 2010 From: william at wbonnet.net (William Bonnet) Date: Mon, 01 Feb 2010 22:26:40 +0100 Subject: [csw-maintainers] Wrong Maintainer: Fwd: [svn] GraphViz upstream update notification In-Reply-To: <4B671E86.5050802@opencsw.org> References: <4B671E86.5050802@opencsw.org> Message-ID: <4B674710.1090500@wbonnet.net> Hi > I have received this message in error, and I'm not sure who to contact? You did the right thing to do. Contact the maintainer list. > I am the maintainer of "graphviz", but I am not the maintainer of this > "GraphViz" perl extension. > I'm guessing this problem has to do with not recognizing the case > differences? Both packages have the same GARNAME. This should not happen... the bot had no way to retrieve the correct package from the package list :( It will be modified soon... but i still need a few weeks before i release the fix. First i have to finalize a few things on the web site. Here are the details of the problem : [william at cyaegha:~/community/opencsw/mgar/pkg]$ grep ^GARNAME graphviz/trunk/Makefile GARNAME = graphviz [william at cyaegha:~/community/opencsw/mgar/pkg]$ grep ^GARNAME cpan/GraphViz/trunk/Makefile GARNAME = GraphViz The tests in the bot are not case sensitives. > Would whoever fixes this please also add a: "In case of problems, > contact: real_person at opencsw.org" > message to the robot email, please? good suggestion i add it now. BTW, most of you should have received today one or several notification email. I did a reset of the status of notification, and triggered all notification (because some svn updates were stuck on the bot side). If you have any question, problem, error report, RFE or what ever, please ask on the maintainer list. I'm the cause of all this problems :) Private email are welcomed, but emails on the list are prefered since if you have a question, you are certainly not the only one, and it's better to share the answers. 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 Feb 2 09:37:28 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 2 Feb 2010 09:37:28 +0100 Subject: [csw-maintainers] new mailing list? In-Reply-To: References: <1263428843-sup-9577@ntdws12.chass.utoronto.ca> <1263562770-sup-2674@ntdws12.chass.utoronto.ca> <4B54D11F.3000608@opencsw.org> <1263850046-sup-8178@ntdws12.chass.utoronto.ca> <4B5CA417.5060708@opencsw.org> Message-ID: <737E0339-BF62-417C-8E3C-46AF1B808FF5@opencsw.org> Hi, Am 27.01.2010 um 18:51 schrieb Philip Brown: > On Wed, Jan 27, 2010 at 6:55 AM, Maciej (Matchek) Blizinski > wrote: >> On Mon, Jan 25, 2010 at 6:25 PM, Philip Brown >> wrote: >>> We can rename the "newpkgs" directory to something,and then create a >>> new mailing list with the same name? >> >> Looks good to me. >> >> The new name could be pkgsubmissions, which is somewhat long, but >> descriptive. Are people OK with this solution? > > The only remaining issue about the name I can think of, is that when > and if we get back to doing regular "stable freeze" type things, it > might be nice to have separate lists for freeze/stable type updates. > In which case, we might keep that in mind when choosing names for > things. Ok, so no problem there as Maciej explained. Ihsan: Do you mind setting up pkgsubmissions@ with the people subscribed who showed interest? Best regards -- Dago From maciej at opencsw.org Tue Feb 2 17:26:45 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 2 Feb 2010 16:26:45 +0000 Subject: [csw-maintainers] RFD: Releases and staging proposal Message-ID: One of the larger topics during the Wintercamp in Zurich was the release schedule: how do we get a new stable? Last weekend, I sat down and wrote up a document describing the release proposal. It describes the initial problem, the target mirror layout and the release process. It also has a plan of how do we get there. Here's the link: http://wiki.opencsw.org/releases-and-staging I'd like to thank all the people who helped by discussing, copy-editing and reviewing the document. What do people think about this design? Should we modify it? Should we implement it? Please discuss. Maciej From phil at bolthole.com Tue Feb 2 17:53:42 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 2 Feb 2010 08:53:42 -0800 Subject: [csw-maintainers] RFD: Releases and staging proposal In-Reply-To: References: Message-ID: On Tue, Feb 2, 2010 at 8:26 AM, Maciej (Matchek) Blizinski wrote: > > http://wiki.opencsw.org/releases-and-staging > > I'd like to thank all the people who helped by discussing, > copy-editing and reviewing the document. > > What do people think about this design? ?Should we modify it? ?Should > we implement it? ?Please discuss. > There is somewhat of an overstatement in the document: >Where do we want to be >The release branch naming and meaning shall be modeled on Debian's: experimental, unstable, >testing and stable. Claiming where "we want to be", is a very strongly worded statement. I think it is inappropriate to make such a statement of "what we want", until a majority of "members" have actually voted that to be so. While I recognize that a nice chunk of folks discussed it at the Wintercamp (and I regret that due to financial reasons and scheduling I could not make it), that group of people did not constitute a voting majority, as far as I am aware. From rupert at opencsw.org Tue Feb 2 22:44:08 2010 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 2 Feb 2010 22:44:08 +0100 Subject: [csw-maintainers] mercurial hg-1.4.3, trac-0.11.6 in testing Message-ID: <6af4271002021344w42c64060o43f158a17e73114a@mail.gmail.com> the mercurial maintenance release hg-1.4.3 is now in testing. thanks to maciej, we also have trac-0.11.6 built again, which is also in testing now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert at opencsw.org Tue Feb 2 23:23:51 2010 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 2 Feb 2010 23:23:51 +0100 Subject: [csw-maintainers] [csw-buildfarm] what is different on buildfarm? mercurial tests take long - or fail In-Reply-To: References: <6af4271001020318k5f9fe830gd5378c9bf96e267b@mail.gmail.com> <841FE230-13C7-4CEC-9202-B01167FE8730@opencsw.org> <6af4271001041148x907e364ha7d09da31400df6b@mail.gmail.com> <0DEA3BF3-1EC8-42F7-A160-1CC681304F3F@opencsw.org> <6af4271001041457h4535abdar558fdb87b70cf151@mail.gmail.com> Message-ID: <6af4271002021423h161e8e80p2e9eb25be71ab2e6@mail.gmail.com> i tried again with hg-1.4.3 on build8s - same hanging ..... in one terminal the test is running: rupert at build8s :~/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build-isa-sparcv8/mercurial-1.4.3/tests $ ./run-tests.py -j32 and in the other i did a truss as maciej suggested. rupert at build8s:~ $ ps -ef | grep ruper | grep pytho rupert 23907 17788 0 16:05:22 ? 0:00 /opt/csw/bin/python /tmp/hgtests.EsEYZq/install/bin/hg serve -p 20137 -d --pid- rupert 22422 21173 0 16:18:17 pts/2 0:00 grep pytho rupert 24158 24157 0 16:05:27 pts/92 0:01 /opt/csw/bin/python /tmp/hgtests.EsEYZq/install/bin/hg --cwd ../test2 push http rupert 13873 8465 0 16:01:26 pts/92 0:01 /opt/csw/bin/python ./run-tests.py --jobs=1 --port=20059 --with-hg=/tmp/hgtests rupert 8465 20659 0 16:00:16 pts/92 0:01 python ./run-tests.py -j32 rupert at build8s:~ $ truss -p 23907 lwp_park(0x00000000, 0) (sleeping...) $ truss -p 24158 recv(4, 0x0024F734, 1, 0) (sleeping...) $ truss -p 13873 waitid(P_PID, 21911, 0xFFBFE458, WEXITED|WTRAPPED) (sleeping...) $ truss -p 8465 wait() (sleeping...) On Tue, Jan 5, 2010 at 09:53, Maciej (Matchek) Blizinski wrote: > On Mon, Jan 4, 2010 at 10:57 PM, rupert THURNER > wrote: > > then i upgraded the dependencies as well. but the result did not > > change, the test just hang. > > My mantra is: what does truss say? > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert at opencsw.org Tue Feb 2 23:41:29 2010 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 2 Feb 2010 23:41:29 +0100 Subject: [csw-maintainers] [csw-buildfarm] what is different on buildfarm? mercurial tests take long - or fail In-Reply-To: <6af4271002021423h161e8e80p2e9eb25be71ab2e6@mail.gmail.com> References: <6af4271001020318k5f9fe830gd5378c9bf96e267b@mail.gmail.com> <841FE230-13C7-4CEC-9202-B01167FE8730@opencsw.org> <6af4271001041148x907e364ha7d09da31400df6b@mail.gmail.com> <0DEA3BF3-1EC8-42F7-A160-1CC681304F3F@opencsw.org> <6af4271001041457h4535abdar558fdb87b70cf151@mail.gmail.com> <6af4271002021423h161e8e80p2e9eb25be71ab2e6@mail.gmail.com> Message-ID: <6af4271002021441i785c0191rcdb2498bf129ed67@mail.gmail.com> then i tried the test which seems to hang: ****************** TERMINAL 1 ************************ rupert at build8s:~ $ ps -ef | grep python | grep rupert rupert 15100 22045 0 16:35:14 pts/102 0:00 grep python rupert 10980 10979 0 16:31:41 pts/92 0:01 /opt/csw/bin/python /tmp/hgtests.qcvU3E/install/bin/hg --cwd ../test2 push http rupert 10950 17788 0 16:31:39 ? 0:00 /opt/csw/bin/python /tmp/hgtests.qcvU3E/install/bin/hg serve -p 20059 -d --pid- rupert 10471 20659 0 16:31:00 pts/92 0:00 python ./run-tests.py test-push-http rupert at build8s:~ $ truss -p 10980 recv(4, 0x0024F734, 1, 0) (sleeping...) ^C rupert at build8s:~ $ truss -p 10950 lwp_park(0x00000000, 0) (sleeping...) ^C rupert at build8s:~ $ truss -p 10471 waitid(P_PID, 10834, 0xFFBFE7E0, WEXITED|WTRAPPED) (sleeping...) ^C ****************** TERMINAL 2 ************************ on the other window, where i started the test, i had to kill -9 the process: rupert at build8s :~/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build-isa-sparcv8/mercurial-1.4.3/tests $ ./run-tests.py test-push-http ^C interrupted! rupert at build8s :~/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build-isa-sparcv8/mercurial-1.4.3/tests $ ps -ef | grep python | grep rup rupert 15164 20659 0 16:38:33 pts/92 0:00 grep python rupert 10950 17788 0 16:31:39 ? 0:00 /opt/csw/bin/python /tmp/hgtests.qcvU3E/install/bin/hg serve -p 20059 -d --pid- rupert at build8s :~/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build-isa-sparcv8/mercurial-1.4.3/tests $ kill 10950 rupert at build8s :~/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build-isa-sparcv8/mercurial-1.4.3/tests $ ps -ef | grep python | grep rup rupert 15179 20659 0 16:38:51 pts/92 0:00 grep python rupert 10950 17788 0 16:31:39 ? 0:00 /opt/csw/bin/python /tmp/hgtests.qcvU3E/install/bin/hg serve -p 20059 -d --pid- rupert at build8s :~/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build-isa-sparcv8/mercurial-1.4.3/tests $ kill -9 10950 rupert at build8s :~/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build-isa-sparcv8/mercurial-1.4.3/tests $ ps -ef | grep python | grep rup rupert 15189 20659 0 16:39:00 pts/92 0:00 grep python On Tue, Feb 2, 2010 at 23:23, rupert THURNER wrote: > i tried again with hg-1.4.3 on build8s - same hanging ..... > > in one terminal the test is running: > rupert at build8s > :~/mgar/pkg/mercurial/trunk/work/solaris8-sparc/build-isa-sparcv8/mercurial-1.4.3/tests > $ ./run-tests.py -j32 > > > and in the other i did a truss as maciej suggested. > > rupert at build8s:~ > $ ps -ef | grep ruper | grep pytho > rupert 23907 17788 0 16:05:22 ? 0:00 /opt/csw/bin/python > /tmp/hgtests.EsEYZq/install/bin/hg serve -p 20137 -d --pid- > rupert 22422 21173 0 16:18:17 pts/2 0:00 grep pytho > rupert 24158 24157 0 16:05:27 pts/92 0:01 /opt/csw/bin/python > /tmp/hgtests.EsEYZq/install/bin/hg --cwd ../test2 push http > rupert 13873 8465 0 16:01:26 pts/92 0:01 /opt/csw/bin/python > ./run-tests.py --jobs=1 --port=20059 --with-hg=/tmp/hgtests > rupert 8465 20659 0 16:00:16 pts/92 0:01 python ./run-tests.py -j32 > > > > rupert at build8s:~ > $ truss -p 23907 > lwp_park(0x00000000, 0) (sleeping...) > > $ truss -p 24158 > recv(4, 0x0024F734, 1, 0) (sleeping...) > > $ truss -p 13873 > waitid(P_PID, 21911, 0xFFBFE458, WEXITED|WTRAPPED) (sleeping...) > > $ truss -p 8465 > wait() (sleeping...) > > > > > > > > > > On Tue, Jan 5, 2010 at 09:53, Maciej (Matchek) Blizinski < > maciej at opencsw.org> wrote: > >> On Mon, Jan 4, 2010 at 10:57 PM, rupert THURNER >> wrote: >> > then i upgraded the dependencies as well. but the result did not >> > change, the test just hang. >> >> My mantra is: what does truss say? >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers >> .:: This mailing list's archive is public. ::. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From glaw at opencsw.org Wed Feb 3 07:28:30 2010 From: glaw at opencsw.org (Gary Law) Date: Wed, 3 Feb 2010 06:28:30 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: <4B28150D.4040506@opencsw.org> Message-ID: On 29 January 2010 14:19, Maciej (Matchek) Blizinski wrote: > The sudo_ldap non-fix was a test. ?Phil could have said: "fair enough, > you fix one thing, the other thing at least doesn't get any worse, > perhaps you can do it at later time". ?If he did, I'd be quite likely > to go back to sudo_ldap after the alternatives issue gets resolved > (because it's a dependency). ?But instead he said "Fix this now or > else!" Can we put this to a vote? I say release now. Phil, you've already voted against, Maciej in favour. Any other votes? -- glaw at opencsw.org From dam at opencsw.org Wed Feb 3 10:02:48 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 3 Feb 2010 10:02:48 +0100 Subject: [csw-maintainers] [csw-buildfarm] what is different on buildfarm? mercurial tests take long - or fail In-Reply-To: <6af4271002021423h161e8e80p2e9eb25be71ab2e6@mail.gmail.com> References: <6af4271001020318k5f9fe830gd5378c9bf96e267b@mail.gmail.com> <841FE230-13C7-4CEC-9202-B01167FE8730@opencsw.org> <6af4271001041148x907e364ha7d09da31400df6b@mail.gmail.com> <0DEA3BF3-1EC8-42F7-A160-1CC681304F3F@opencsw.org> <6af4271001041457h4535abdar558fdb87b70cf151@mail.gmail.com> <6af4271002021423h161e8e80p2e9eb25be71ab2e6@mail.gmail.com> Message-ID: <0615A50C-6FDA-439D-A6A5-06A77DDA6E4F@opencsw.org> Hi Rupert, Am 02.02.2010 um 23:23 schrieb rupert THURNER: > i tried again with hg-1.4.3 on build8s - same hanging ..... I suggest taking Mads into the boat - he works on Mercurial upstream and has an account on the buildfarm. Mads: It would be great if you could take a look at Ruperts failing test. Best regards -- Dago From dam at opencsw.org Wed Feb 3 10:07:02 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 3 Feb 2010 10:07:02 +0100 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: <4B28150D.4040506@opencsw.org> Message-ID: <7D6F09A4-6453-4924-B68A-B56F1E7EE210@opencsw.org> Hi, Am 03.02.2010 um 07:28 schrieb Gary Law: > On 29 January 2010 14:19, Maciej (Matchek) Blizinski > wrote: >> The sudo_ldap non-fix was a test. Phil could have said: "fair >> enough, >> you fix one thing, the other thing at least doesn't get any worse, >> perhaps you can do it at later time". If he did, I'd be quite likely >> to go back to sudo_ldap after the alternatives issue gets resolved >> (because it's a dependency). But instead he said "Fix this now or >> else!" > > Can we put this to a vote? I say release now. Phil, you've already > voted against, Maciej in favour. Any other votes? Come on guys, Maciej didn't fix it as test, and now as it surved its purpose there is no point in knowingly releasing a package with a flaw which takes a minute to fix. We still do want to deliver high-quality packages instead of putting oil in the fire of personal animosities, do we? Best regards -- Dago From maciej at opencsw.org Wed Feb 3 10:53:11 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 3 Feb 2010 09:53:11 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: <7D6F09A4-6453-4924-B68A-B56F1E7EE210@opencsw.org> References: <4B28150D.4040506@opencsw.org> <7D6F09A4-6453-4924-B68A-B56F1E7EE210@opencsw.org> Message-ID: On Wed, Feb 3, 2010 at 9:07 AM, Dagobert Michelsen wrote: > Hi, > > Am 03.02.2010 um 07:28 schrieb Gary Law: >> >> On 29 January 2010 14:19, Maciej (Matchek) Blizinski >> wrote: >>> >>> The sudo_ldap non-fix was a test. ?Phil could have said: "fair enough, >>> you fix one thing, the other thing at least doesn't get any worse, >>> perhaps you can do it at later time". ?If he did, I'd be quite likely >>> to go back to sudo_ldap after the alternatives issue gets resolved >>> (because it's a dependency). ?But instead he said "Fix this now or >>> else!" >> >> Can we put this to a vote? I say release now. Phil, you've already >> voted against, Maciej in favour. Any other votes? > > Come on guys, Maciej didn't fix it as test, and now as it surved > its purpose there is no point in knowingly releasing a package > with a flaw which takes a minute to fix. We still do want to > deliver high-quality packages instead of putting oil in the fire > of personal animosities, do we? We don't, but these are intertwined issues: in order to deliver high quality packages you need people to be able to communicate and coordinate. There's also the issue of the cost. I love to deliver high quality packages and fix bugs, but not at any cost. I'm not going to die trying. There's more work to be done in order for sudo_ldap to be a high-quality solution. The permission problem is one thing, but the other is that there's no mechanism to switch the sudo versions; the /opt/csw/bin/sudo path will always point at sudo.minimal (non-ldap one). I don't like the idea of our packages trying to cope with custom modifications of any paths controlled by them. I've committed all my work back to the source code repository, if anyone wants to continue the work, the build descriptions are up for grabs. Maciej From maciej at opencsw.org Wed Feb 3 10:53:22 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 3 Feb 2010 09:53:22 +0000 Subject: [csw-maintainers] RFD: Releases and staging proposal In-Reply-To: References: Message-ID: On Tue, Feb 2, 2010 at 4:53 PM, Philip Brown wrote: > Claiming where "we want to be", is a very strongly worded statement. I > think it is inappropriate to make such a statement of "what we want", > until a majority of "members" have actually voted that to be so. > > While I recognize that a nice chunk of folks discussed it at the > Wintercamp (and I regret that due to financial reasons and scheduling > I could not make it), that group of people did not constitute a voting > majority, as far as I am aware. We're at an earlier step right now. The document is yet to be discussed, that's why it has been sent here. It's a result of work of a number of people, now put up for discussion in the larger circles. I think it's silly to write "Where we would want to be if we have already voted" and then change it back after the voting. Also, "where we want to be" is just an expression. It could have been "the target state" or any other expression meaning roughly the same thing. If you would like to suggest a better wording, please go ahead. I can understand the financial and scheduling reasons, if the meeting was on the other side of Atlantic, I don't know if I could make it either. It's a pity, everybody on the Wintercamp would have loved if you were coming over to Munich. We've actually discussed options for meeting in which both sides of Atlantic could participate. I don't think it's realistic to plan regular transatlantic flights for OpenCSW camps. Instead, we could think of booking some time together and meeting over a VC link. Back to the document, perhaps I didn't make it clear that it's a draft. I've added a note on top of the page. I assume it will be now understood that all the "X is Y" or "X will be Y" expressions mean "X will be Y once the document is approved". Maciej From dam at opencsw.org Wed Feb 3 10:58:35 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 3 Feb 2010 10:58:35 +0100 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: <4B28150D.4040506@opencsw.org> <7D6F09A4-6453-4924-B68A-B56F1E7EE210@opencsw.org> Message-ID: <7B06664C-6CBE-4D31-AFF1-EE630ABA6E78@opencsw.org> Hi Maciej, Am 03.02.2010 um 10:53 schrieb Maciej (Matchek) Blizinski: > On Wed, Feb 3, 2010 at 9:07 AM, Dagobert Michelsen > wrote: >> Am 03.02.2010 um 07:28 schrieb Gary Law: >>> >>> On 29 January 2010 14:19, Maciej (Matchek) Blizinski >> > >>> wrote: >>>> >>>> The sudo_ldap non-fix was a test. Phil could have said: "fair >>>> enough, >>>> you fix one thing, the other thing at least doesn't get any worse, >>>> perhaps you can do it at later time". If he did, I'd be quite >>>> likely >>>> to go back to sudo_ldap after the alternatives issue gets resolved >>>> (because it's a dependency). But instead he said "Fix this now or >>>> else!" >>> >>> Can we put this to a vote? I say release now. Phil, you've already >>> voted against, Maciej in favour. Any other votes? >> >> Come on guys, Maciej didn't fix it as test, and now as it surved >> its purpose there is no point in knowingly releasing a package >> with a flaw which takes a minute to fix. We still do want to >> deliver high-quality packages instead of putting oil in the fire >> of personal animosities, do we? > > We don't, but these are intertwined issues: in order to deliver high > quality packages you need people to be able to communicate and > coordinate. > > There's also the issue of the cost. I love to deliver high quality > packages and fix bugs, but not at any cost. I'm not going to die > trying. > > There's more work to be done in order for sudo_ldap to be a > high-quality solution. The permission problem is one thing, but the > other is that there's no mechanism to switch the sudo versions; the > /opt/csw/bin/sudo path will always point at sudo.minimal (non-ldap > one). I don't like the idea of our packages trying to cope with > custom modifications of any paths controlled by them. Ok, does that mean "alternatives" first? I know you packaged up Debians and looked at RedHats (?) but that was difficult to compile. What needs to be done to finish it? Best regards -- Dago From rupert at opencsw.org Wed Feb 3 11:07:01 2010 From: rupert at opencsw.org (rupert THURNER) Date: Wed, 3 Feb 2010 11:07:01 +0100 Subject: [csw-maintainers] building netscape security services, nss Message-ID: <6af4271002030207y1e952cdfycbbb1554d7eb548f@mail.gmail.com> hi, to connect to an ldap server via the ldaps protocol, one would need to have nss. i found it in the subversion repository, and tried to compile it, the result is: (cd work/solaris8-sparc/build-isa-sparcv8/nss-3.12.4/mozilla/security/dbm \ && \ CPPFLAGS='-I/opt/csw/include -I/opt/csw/include/nss' LD_OPTIONS='-R/opt/csw/lib/\$ISALIST -R/opt/csw/lib' \ gmake -j1) gmake[2]: Entering directory `/home/rupert/mgar/pkg/nss/trunk/work/solaris8-sparc/build-isa-sparcv8/nss-3.12.4/mozilla/security/dbm' cd include; gmake export gmake[3]: Entering directory `/home/rupert/mgar/pkg/nss/trunk/work/solaris8-sparc/build-isa-sparcv8/nss-3.12.4/mozilla/security/dbm/include' Creating ../../../dist/public/dbm /bin/sh: ../../coreconf/nsinstall/SunOS5.8_OPT.OBJ/nsinstall: not found gmake[3]: *** [../../../dist/public/dbm] Error 1 gmake[3]: Leaving directory `/home/rupert/mgar/pkg/nss/trunk/work/solaris8-sparc/build-isa-sparcv8/nss-3.12.4/mozilla/security/dbm/include' gmake[2]: *** [export] Error 2 gmake[2]: Leaving directory `/home/rupert/mgar/pkg/nss/trunk/work/solaris8-sparc/build-isa-sparcv8/nss-3.12.4/mozilla/security/dbm' gmake[1]: *** [build-dbm] Error 2 gmake[1]: Leaving directory `/home/rupert/mgar/pkg/nss/trunk' gmake: *** [merge-isa-sparcv8] Error 2 rupert at build8s:~/mgar/pkg/nss/trunk $ does somebody of you have experience how to compile this? maybe the one who did the firefox package ? kr, rupert -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Wed Feb 3 11:14:30 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 3 Feb 2010 10:14:30 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: <7B06664C-6CBE-4D31-AFF1-EE630ABA6E78@opencsw.org> References: <4B28150D.4040506@opencsw.org> <7D6F09A4-6453-4924-B68A-B56F1E7EE210@opencsw.org> <7B06664C-6CBE-4D31-AFF1-EE630ABA6E78@opencsw.org> Message-ID: On Wed, Feb 3, 2010 at 9:58 AM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 03.02.2010 um 10:53 schrieb Maciej (Matchek) Blizinski: >> There's more work to be done in order for sudo_ldap to be a >> high-quality solution. ?The permission problem is one thing, but the >> other is that there's no mechanism to switch the sudo versions; the >> /opt/csw/bin/sudo path will always point at sudo.minimal (non-ldap >> one). ?I don't like the idea of our packages trying to cope with >> custom modifications of any paths controlled by them. > > Ok, does that mean "alternatives" first? I know you packaged up > Debians and looked at RedHats (?) but that was difficult to > compile. What needs to be done to finish it? Yes, alternatives need to go first. The RedHat thing is hidden inside the chkconfig package. I've started writing the build description, everything I've done is in the repo. https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/chkconfig/trunk/Makefile It needs to be patched to use /opt/csw/... paths, and there's a compilation error as well: source='alternatives.c' object='alternatives.o' libtool=no \ DEPDIR=.deps depmode=none /bin/bash ./depcomp \ /opt/studio/SOS11/SUNWspro/bin/cc -DLOCALEDIR=\"/opt/csw/share/locale\" -DRCDIR=\"/etc\" -DINITDIR=\"/etc/init.d\" -DXINETDDIR=\"/etc/xinetd.d\" -DMAXLEVEL=3 -DMAXPRI=99 -DPRIREGEX=\"[SK][0-9][0-9]\" -DALTLINKSDIR=\"/etc/alternatives\" -DALTADMINDIR=\"/var/lib/alternatives\" -DSBINDIR=\"@SBINDIR@\" -DHAVE_CONFIG_H -I. -I./intl -I. -I/opt/csw/include -D_REENTRANT -xO3 -xarch=v8 -c alternatives.c "leveldb.c", line 153: syntax error before or at: : "leveldb.c", line 242: cannot recover from previous errors cc: acomp failed for leveldb.c gmake[4]: *** [leveldb.o] Error 2 gmake[4]: *** Waiting for unfinished jobs.... "chkconfig.c", line 384: warning: implicit function declaration: alloca "chkconfig.c", line 384: warning: improper pointer/integer combination: op "=" "chkconfig.c", line 566: warning: argument #3 is incompatible with prototype: prototype: pointer to pointer to const char : "/opt/csw/include/popt.h", line 259 argument : pointer to pointer to char "chkconfig.c", line 636: warning: implicit function declaration: basename "chkconfig.c", line 636: warning: improper pointer/integer combination: op "=" "chkconfig.c", line 644: warning: improper pointer/integer combination: op "=" gmake[4]: Leaving directory `/home/maciej/src/opencsw/pkg/chkconfig/trunk/work/solaris8-sparc/build-isa-sparcv8/chkconfig-1.3.30c' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/home/maciej/src/opencsw/pkg/chkconfig/trunk/work/solaris8-sparc/build-isa-sparcv8/chkconfig-1.3.30c' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/maciej/src/opencsw/pkg/chkconfig/trunk/work/solaris8-sparc/build-isa-sparcv8/chkconfig-1.3.30c' gmake[1]: *** [build-work/solaris8-sparc/build-isa-sparcv8/chkconfig-1.3.30c/Makefile] Error 2 gmake[1]: Leaving directory `/home/maciej/src/opencsw/pkg/chkconfig/trunk' gmake: *** [merge-isa-sparcv8] Error 2 gmake: Leaving directory `/home/maciej/src/opencsw/pkg/chkconfig/trunk' From maciej at opencsw.org Wed Feb 3 11:17:27 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 3 Feb 2010 10:17:27 +0000 Subject: [csw-maintainers] building netscape security services, nss In-Reply-To: <6af4271002030207y1e952cdfycbbb1554d7eb548f@mail.gmail.com> References: <6af4271002030207y1e952cdfycbbb1554d7eb548f@mail.gmail.com> Message-ID: On Wed, Feb 3, 2010 at 10:07 AM, rupert THURNER wrote: > does somebody of you have experience how to compile this? maybe the one who > did the firefox package ? > kr, rupert Firefox was done by William. I was working on NSS, and it even compiles on Solaris 10, but not Solaris 8, but the reason is unclear. The main problem is that NSS uses a custom build system. I've started pulling it apart to understand what the problem is; the NSS build system uses the PLATFORM variable interchangeably with another variable, which most of the time has the same value, but not always. So sometimes it looks into ./../coreconf/nsinstall/$(PLATFORM)/nsinstall and sometimes into ./../coreconf/nsinstall/$(SOMETHING_ELSE)/nsinstall. The fix that Dago suggested was to prevent the PLATFORM variable from leaking from GAR into the NSS build system. I haven't spend any time one it since, but I can return to it, especially that there's a need for this library. If you feel like it, you can try to debug it too. Maciej From glaw at opencsw.org Wed Feb 3 11:35:52 2010 From: glaw at opencsw.org (Gary Law) Date: Wed, 3 Feb 2010 10:35:52 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: <7D6F09A4-6453-4924-B68A-B56F1E7EE210@opencsw.org> References: <4B28150D.4040506@opencsw.org> <7D6F09A4-6453-4924-B68A-B56F1E7EE210@opencsw.org> Message-ID: On 3 February 2010 09:07, Dagobert Michelsen wrote: > We still do want to > deliver high-quality packages instead of putting oil in the fire > of personal animosities, do we? !? I've not got any animosity with anyone. I haven't detected any in what Maciej has said either. I'd like to see this package out the door, now, given is it of unquestionably higher quality than the one we ship. No brainer. Why can't we have a vote on this? Gary -- glaw at opencsw.org From dam at opencsw.org Wed Feb 3 13:04:49 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 3 Feb 2010 13:04:49 +0100 Subject: [csw-maintainers] (now about sudo) In-Reply-To: References: <4B28150D.4040506@opencsw.org> <7D6F09A4-6453-4924-B68A-B56F1E7EE210@opencsw.org> Message-ID: <377E399F-13DC-4AFB-8825-412033199755@opencsw.org> Hi Gary, Am 03.02.2010 um 11:35 schrieb Gary Law: > I'd like to see this package out the door, now, given is it of > unquestionably higher quality than the one we ship. No brainer. > > Why can't we have a vote on this? Of course we can. With the previous work of Maciej I just finished CSWalternatives and created a new "sudo" project in experimental: http://mirror.opencsw.org/experimental.html#sudo The sudo packages will hopefully follow soon, so no need to put the old packages I think :-) Best regards -- Dago From maciej at opencsw.org Wed Feb 3 16:18:36 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 3 Feb 2010 15:18:36 +0000 Subject: [csw-maintainers] (now about sudo) In-Reply-To: <377E399F-13DC-4AFB-8825-412033199755@opencsw.org> References: <4B28150D.4040506@opencsw.org> <7D6F09A4-6453-4924-B68A-B56F1E7EE210@opencsw.org> <377E399F-13DC-4AFB-8825-412033199755@opencsw.org> Message-ID: On Wed, Feb 3, 2010 at 12:04 PM, Dagobert Michelsen wrote: > Hi Gary, > > Am 03.02.2010 um 11:35 schrieb Gary Law: >> >> I'd like to see this package out the door, now, given is it of >> unquestionably higher quality than the one we ship. No brainer. >> >> Why can't we have a vote on this? > > Of course we can. With the previous work of Maciej I just finished > CSWalternatives and created a new "sudo" project in experimental: > ?http://mirror.opencsw.org/experimental.html#sudo Cool! I think you need to patch Red Hat alternatives to use CSW prefixes: /opt/csw, /etc/opt/csw and /var/opt/csw. From phil at bolthole.com Wed Feb 3 19:14:52 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 3 Feb 2010 10:14:52 -0800 Subject: [csw-maintainers] building netscape security services, nss In-Reply-To: References: <6af4271002030207y1e952cdfycbbb1554d7eb548f@mail.gmail.com> Message-ID: On Wed, Feb 3, 2010 at 2:17 AM, Maciej (Matchek) Blizinski wrote: > > Firefox was done by William. ?I was working on NSS, and it even > compiles on Solaris 10, but not Solaris 8, but the reason is unclear. I vaguely recall, that netscape for some unfathomable reason, took a very different approach to security and nss, between [sol8 and sol 10?] One of them attempts to compile, and does actually deliver in the package, a completely separate [lib*nss*solaris*security*] or something, and one does not. It gets dynamically linked in to the "main" nss lib, and is a critical dependancy, if i recall correctly. From maciej at opencsw.org Wed Feb 3 19:54:05 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 3 Feb 2010 18:54:05 +0000 Subject: [csw-maintainers] GAR: New variable names (dependencies and noisaexec) Message-ID: If you don't use GAR, you can stop reading now. As discussed in Munich[1], the "required" and "prerequisite" variables have been changed to more meaningful names: runtime and build dependencies. REQUIRED_PKGS becomes RUNTIME_DEP_PKGS PREREQUISITE_PKGS becomes BUILD_DEP_PKGS NO_ISAEXEC becomes NOISAEXEC (for the sake of consistency) The change has been pushed in r8335[2]. Since all sources have been edited, including GAR, everything should Just Work(tm). If you run into any problems, please let know Dago or me. Maciej [1] http://wiki.opencsw.org/wintercamp-2009-minutes [2] https://sourceforge.net/apps/trac/gar/changeset/8335 From maciej at opencsw.org Wed Feb 3 20:24:03 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 3 Feb 2010 19:24:03 +0000 Subject: [csw-maintainers] GAR: New variable names (dependencies and noisaexec) In-Reply-To: References: Message-ID: On Wed, Feb 3, 2010 at 6:54 PM, Maciej (Matchek) Blizinski wrote: > The change has been pushed in r8335[2]. ?Since all sources have been > edited, including GAR, everything should Just Work(tm). ...except for cases where you have local modifications touching the sections with changed variables. If that happens, the general strategy is: you can do the substitutions mentioned in the previous e-mail in the file affected by code conflict; then you can throw out the incoming change. Then verify that the old variables don't lurk in your code anywhere. For instance, in the face of the following conflict... <<<<<<< .mine REQUIRED_PKGS_CSWsqlite3 = CSWsqlite3rt CSWpython-rt REQUIRED_PKGS_CSWsqlite3 += CSWreadline REQUIRED_PKGS_CSWsqlite3 += CSWncurses REQUIRED_PKGS_CSWsqlite3devel = CSWsqlite3 ======= RUNTIME_DEP_PKGS_CSWsqlite3 = CSWsqlite3rt RUNTIME_DEP_PKGS_CSWsqlite3 += CSWreadline RUNTIME_DEP_PKGS_CSWsqlite3 += CSWncurses RUNTIME_DEP_PKGS_CSWsqlite3devel = CSWsqlite3 >>>>>>> .r8335 ...the actions would be: substitution... <<<<<<< .mine RUNTIME_DEP_PKGS_CSWsqlite3 = CSWsqlite3rt CSWpython-rt RUNTIME_DEP_PKGS_CSWsqlite3 += CSWreadline RUNTIME_DEP_PKGS_CSWsqlite3 += CSWncurses RUNTIME_DEP_PKGS_CSWsqlite3devel = CSWsqlite3 ======= RUNTIME_DEP_PKGS_CSWsqlite3 = CSWsqlite3rt RUNTIME_DEP_PKGS_CSWsqlite3 += CSWreadline RUNTIME_DEP_PKGS_CSWsqlite3 += CSWncurses RUNTIME_DEP_PKGS_CSWsqlite3devel = CSWsqlite3 >>>>>>> .r8335 ...and deletion of everything between ======= and >>>>>>> .r8335. Maciej From maciej at opencsw.org Thu Feb 4 03:20:02 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 4 Feb 2010 02:20:02 +0000 Subject: [csw-maintainers] GAR: archall - a new checkpkg module Message-ID: I wrote a new check for GAR. It throws an error when a package is marked ARCHALL = 1 and contains any binaries. Conversely, when a package is not ARCHALL = 1 and does not contain any binaries, a suggestion to make it architecture-independent, is printed to screen. It's only a suggestion though, since there might be other reasons to make a package architecture-dependent. I spoke about this today with Phil on IRC, there may be devel packages with architecture related settings. I need to hunt down some of them and build checks based on some examples. Here's one: > cat /opt/csw/lib/pkgconfig/libclamav.pc (...) Cflags: -I${includedir} -xO2 -xarch=v8 -I/opt/csw/include More examples of any autodetectible reasons why a binary-free package might be architecture-dependent, would be appreciated. Maciej From maciej at opencsw.org Thu Feb 4 13:06:47 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 4 Feb 2010 12:06:47 +0000 Subject: [csw-maintainers] cswclassutils: location of template init scripts In-Reply-To: References: Message-ID: On Mon, Feb 1, 2010 at 8:31 PM, Philip Brown wrote: > Revisiting a topic that has come up a few times, but I think people > have more awareness of now: > > currently, our wiki for cswclassutils suggests the initial location > for the init script should be > > INITSMF = /etc/opt/csw/init.d/cswfoo > > I think it would be better for our users, if we standardize on a > location under /opt/csw > For example, /opt/csw/etc/init.d > > This would be beneficial in multiple ways: > > 1. It makes it a teenie bit easier to support NFS-shared /opt/csw > 2. It makes it possible to support sparse zones, where /opt/csw is > "sparse" in addition to /usr, etc. > > I dont see any drawbacks. > > Additionally, I think we should write up that the location is presumed > to be READ-ONLY, and that any tweaking that needs to be done, should > be facilitated by referencing some other configuration script, either > directly, or indirectly. > > (An example of the "indirect" case, would be when the program it > calls, already references some config file that covers all startup > options) > > Comments, please? There's a drawback I can see: it goes against the unification of $(sysconfdir) (in our case: /etc$(prefix)). It is true that the init files, since they're owned by packages, are read-only, and they could live in $(prefix)/etc instead of /etc$(prefix). This basically means that some parts of $(sysconfdir) are read-only and some are read-write, but I don't think that it's enough a reason to split them into separate directories. ad 1.: I understand that your argument is that moving the read-only bits to a shared read-only directory might make it easier to maintain, but I don't see how it makes it easier: These files are only installed by packages, and cannot (must not) be modified by users: each package upgrade will revert any changes. Therefore it makes no difference whether it's in a read-only directory or not: either way, the init file is and remains what pkgadd has installed there. Correct me if I'm wrong. ad 2.: sparse zones with shared /opt/csw are currently supported fine with /etc$(prefix). Maciej From benny at opencsw.org Thu Feb 4 13:27:15 2010 From: benny at opencsw.org (Benjamin von Mossner) Date: Thu, 4 Feb 2010 13:27:15 +0100 Subject: [csw-maintainers] GAR: New variable names (dependencies and noisaexec) In-Reply-To: References: Message-ID: <20100204122714.GB20333@vonmossner.de> Hi, > > The change has been pushed in r8335[2]. ?Since all sources have been > > edited, including GAR, everything should Just Work(tm). wow, good work. How about a warning or error if someone still uses the old syntax? Something like.. [snip] REQUIRED_PKGS is deprecated in favour of RUNTIME_DEP_PKGS [snap] Cheers, benny > > ...except for cases where you have local modifications touching the > sections with changed variables. If that happens, the general > strategy is: you can do the substitutions mentioned in the previous > e-mail in the file affected by code conflict; then you can throw out > the incoming change. Then verify that the old variables don't lurk in > your code anywhere. > > For instance, in the face of the following conflict... > > <<<<<<< .mine > REQUIRED_PKGS_CSWsqlite3 = CSWsqlite3rt CSWpython-rt > REQUIRED_PKGS_CSWsqlite3 += CSWreadline > REQUIRED_PKGS_CSWsqlite3 += CSWncurses > REQUIRED_PKGS_CSWsqlite3devel = CSWsqlite3 > ======= > RUNTIME_DEP_PKGS_CSWsqlite3 = CSWsqlite3rt > RUNTIME_DEP_PKGS_CSWsqlite3 += CSWreadline > RUNTIME_DEP_PKGS_CSWsqlite3 += CSWncurses > RUNTIME_DEP_PKGS_CSWsqlite3devel = CSWsqlite3 > >>>>>>> .r8335 > > ...the actions would be: substitution... > > <<<<<<< .mine > RUNTIME_DEP_PKGS_CSWsqlite3 = CSWsqlite3rt CSWpython-rt > RUNTIME_DEP_PKGS_CSWsqlite3 += CSWreadline > RUNTIME_DEP_PKGS_CSWsqlite3 += CSWncurses > RUNTIME_DEP_PKGS_CSWsqlite3devel = CSWsqlite3 > ======= > RUNTIME_DEP_PKGS_CSWsqlite3 = CSWsqlite3rt > RUNTIME_DEP_PKGS_CSWsqlite3 += CSWreadline > RUNTIME_DEP_PKGS_CSWsqlite3 += CSWncurses > RUNTIME_DEP_PKGS_CSWsqlite3devel = CSWsqlite3 > >>>>>>> .r8335 > > ...and deletion of everything between ======= and >>>>>>> .r8335. > > Maciej > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -- /"\ 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 phil at bolthole.com Thu Feb 4 18:17:13 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 4 Feb 2010 09:17:13 -0800 Subject: [csw-maintainers] GAR: archall - a new checkpkg module In-Reply-To: References: Message-ID: On Wed, Feb 3, 2010 at 6:20 PM, Maciej (Matchek) Blizinski wrote: > ?I need to hunt down some of them and build checks based on > some examples. ?Here's one: > >> cat /opt/csw/lib/pkgconfig/libclamav.pc > (...) > Cflags: -I${includedir} -xO2 -xarch=v8 -I/opt/csw/include > Hmm.. that brings up a side issue. Anyone know if pkg-config can handle #includes? Seems like we could benefit if the core arch-specific pkg-config package, would have a central shared "arch flags" type include. Then that line above could instead be Cflags: -I${includedir} -xO2 ${archflags} -I/opt/csw/include or something? It would be a double-win: first, we could make more things arch neutral. Secondly, it makes things much easier if someone wants to make highly-arch-tuned compilations of things. From maciej at opencsw.org Thu Feb 4 19:08:08 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 4 Feb 2010 18:08:08 +0000 Subject: [csw-maintainers] GAR: New variable names (dependencies and noisaexec) In-Reply-To: <20100204122714.GB20333@vonmossner.de> References: <20100204122714.GB20333@vonmossner.de> Message-ID: On Thu, Feb 4, 2010 at 12:27 PM, Benjamin von Mossner wrote: > Hi, > >> > The change has been pushed in r8335[2]. ?Since all sources have been >> > edited, including GAR, everything should Just Work(tm). > wow, good work. > How about a warning or error if someone still uses the old syntax? > Something like.. > [snip] > REQUIRED_PKGS is deprecated in favour of RUNTIME_DEP_PKGS > [snap] Yes, it would be useful. I guess Dago would have the best idea about how to implement this check and where to put it. From phil at bolthole.com Thu Feb 4 19:30:37 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 4 Feb 2010 10:30:37 -0800 Subject: [csw-maintainers] cswclassutils: location of template init scripts In-Reply-To: References: Message-ID: On Thu, Feb 4, 2010 at 4:06 AM, Maciej (Matchek) Blizinski wrote: > >> I think it would be better for our users, if we standardize on a >> location under /opt/csw >> For example, /opt/csw/etc/init.d >>... >> I dont see any drawbacks. >>.. >> Comments, please? > > There's a drawback I can see: it goes against the unification of > $(sysconfdir) (in our case: /etc$(prefix)). It is true that the init > files, since they're owned by packages, are read-only, and they could > live in $(prefix)/etc instead of /etc$(prefix). ?This basically means > that some parts of $(sysconfdir) are read-only and some are > read-write, but I don't think that it's enough a reason to split them > into separate directories. The question in my mind is, "what exactly are we trying to unify under /etc?" I would think the most precise answer is, "machine local config files". However, Init scripts, are not config files. Yes, traditionally, init scripts have "lived" in /etc. but they really dont "belong" there. Additionally, the object we are talking about, is even further removed from that: it is only a *template* for an init script, used by the cswinitsmf CAS. The actual "live" version, gets copied from the template, into /etc/init.d (and usually only on sol 8 or 9 machines - by default, on sol10 machines, it gets absorbed into the SMF framework) Having the template also live in /etc is not useful, in my opinion. if you dont like the existance of "/opt/csw/etc/init.d", I think it would be just as fine somewhere else, perhaps "/opt/csw/libexec/init.d", if you prefer ? > ad 2.: sparse zones with shared /opt/csw are currently supported fine > with /etc$(prefix). I had forgotten about that; While my initial unspoken premise that it does not get "shared read only from global zone" is true, it still gets "supported" via the pkg system making individual copies to each individual child zone's /etc. Personally, I think that is hideous :-} and is better avoided. From dam at opencsw.org Thu Feb 4 19:55:41 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 4 Feb 2010 19:55:41 +0100 Subject: [csw-maintainers] GAR: archall - a new checkpkg module In-Reply-To: References: Message-ID: <32004CA3-018E-4176-8788-BBFAED880FA2@opencsw.org> Hi, Am 04.02.2010 um 18:17 schrieb Philip Brown: > On Wed, Feb 3, 2010 at 6:20 PM, Maciej (Matchek) Blizinski > wrote: >> I need to hunt down some of them and build checks based on >> some examples. Here's one: >> >>> cat /opt/csw/lib/pkgconfig/libclamav.pc >> >> (...) >> Cflags: -I${includedir} -xO2 -xarch=v8 -I/opt/csw/include > > Hmm.. that brings up a side issue. > Anyone know if pkg-config can handle #includes? > > Seems like we could benefit if the core arch-specific pkg-config > package, would have a central shared "arch flags" type include. Then > that line above could instead be > > Cflags: -I${includedir} -xO2 ${archflags} -I/opt/csw/include > > or something? > It would be a double-win: > first, we could make more things arch neutral. > Secondly, it makes things much easier if someone wants to make > highly-arch-tuned compilations of things. The problem is that a derived library or application may require different optimizations to work, so I would prefer to leave the selection of the optimization level to the outer library/application and include only the absolutely necessary (read: 32/64 selection) flags in there. It it even more strange: Some apps require higher optimization levels (-xO4 for mutt) and some lower optimization levels (-xO1 for libmhash) to successfully compile and pass the testsuite. Mostly this is due to compiler bugs or badly code written code which does funky things without using volatile. I would go so far to consider it an error to add optimizations in pkgconfig as they can be harmful later, much like .la-files. Best regards -- Dago From phil at bolthole.com Thu Feb 4 20:02:52 2010 From: phil at bolthole.com (Philip Brown) Date: Thu, 4 Feb 2010 11:02:52 -0800 Subject: [csw-maintainers] GAR: archall - a new checkpkg module In-Reply-To: <32004CA3-018E-4176-8788-BBFAED880FA2@opencsw.org> References: <32004CA3-018E-4176-8788-BBFAED880FA2@opencsw.org> Message-ID: On Thu, Feb 4, 2010 at 10:55 AM, Dagobert Michelsen wrote: > .... > It it even more strange: Some apps require higher optimization levels > (-xO4 for mutt) and some lower optimization levels (-xO1 for libmhash) > to successfully compile and pass the testsuite. Mostly this is due > to compiler bugs or badly code written code which does funky things > without using volatile. > > I would go so far to consider it an error to add optimizations in > pkgconfig as they can be harmful later, much like .la-files. > > Interesting. Makes sense to me though. From bonivart at opencsw.org Thu Feb 4 20:08:31 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 4 Feb 2010 20:08:31 +0100 Subject: [csw-maintainers] GAR: archall - a new checkpkg module In-Reply-To: <32004CA3-018E-4176-8788-BBFAED880FA2@opencsw.org> References: <32004CA3-018E-4176-8788-BBFAED880FA2@opencsw.org> Message-ID: <625385e31002041108o4030768dyf08513d12c61940f@mail.gmail.com> On Thu, Feb 4, 2010 at 7:55 PM, Dagobert Michelsen wrote: > It it even more strange: Some apps require higher optimization levels > (-xO4 for mutt) and some lower optimization levels (-xO1 for libmhash) > to successfully compile and pass the testsuite. Mostly this is due > to compiler bugs or badly code written code which does funky things > without using volatile. We use -xO3 as default, right? Clam Antivirus doesn't compile unless I use -xO2. Maybe Edwin should take a look at that now that he's even using our buildfarm? -- /peter From hson at opencsw.org Fri Feb 5 09:00:09 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Fri, 05 Feb 2010 09:00:09 +0100 Subject: [csw-maintainers] GAR: archall - a new checkpkg module In-Reply-To: References: Message-ID: <4B6BD009.8020903@opencsw.org> Maciej (Matchek) Blizinski wrote: > I spoke about this today with > Phil on IRC, there may be devel packages with architecture related > settings. I need to hunt down some of them and build checks based on > some examples. I don't think you can make it totally foolproof unless you have access to both ARCH-packages and diff them as part of the release procedure. Example of a couple of cases where it would be almost impossible to detect using a search for specific (BYTEORDER/BYTE_ORDER/ENDIAN/x86/i386/sparc/...) strings diff -r i386/include/ImageMagick/magick/magick-config.h sparc/include/ImageMagick/magick/magick-config.h 400c400,402 < /* #undef HAVE_LTDL */ --- > #ifndef MAGICKCORE_HAVE_LTDL > #define MAGICKCORE_HAVE_LTDL 1 > #endif diff -r i386/include/openssl/opensslconf.h sparc/include/openssl/opensslconf.h 200c200 < #undef DES_RISC1 --- > #define DES_RISC1 diff -r i386/include/orbit-2.0/orbit/orbit-config.h sparc/include/orbit-2.0/orbit/orbit-config.h 23c23 < #define ORBIT_ALIGNOF_CORBA_LONG_LONG 4 --- > #define ORBIT_ALIGNOF_CORBA_LONG_LONG 8 25,26c25,26 < #define ORBIT_ALIGNOF_CORBA_DOUBLE 4 < #define ORBIT_ALIGNOF_CORBA_LONG_DOUBLE 4 --- > #define ORBIT_ALIGNOF_CORBA_DOUBLE 8 > #define ORBIT_ALIGNOF_CORBA_LONG_DOUBLE 8 These differences will most certainly affect how a application compiled with those headers, will work. > > More examples of any autodetectible reasons why a binary-free package > might be architecture-dependent, would be appreciated. Include files containing BYTEORDER/BYTE_ORDER/ENDIAN/x86/i386/sparc But one thing I'm wondering about, why are we even bothering trying to make the devel-packages ARCHALL? Are we having some kind of problem regarding space on mirrors or? I can't think of any platform that don't have separate devel packages for each arch, even those that don't include .a files (which many do). I think that we might possible get more bugs when some maintainer releases a ARCHALL package based on what checkpkg tells him, rather on what upstream/autoconf belives to be true. Also such bugs might be hard to track down. Lets say package A actually have some arch-dependant stuff and then package B is built using some wrong defines from package A. Then the maintainer for package B might spend a lot of time tracking down a bug which actually isn't a bug in B but a error in the installed files for A. From dam at opencsw.org Fri Feb 5 10:53:35 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 5 Feb 2010 10:53:35 +0100 Subject: [csw-maintainers] GAR: archall - a new checkpkg module In-Reply-To: <4B6BD009.8020903@opencsw.org> References: <4B6BD009.8020903@opencsw.org> Message-ID: Hi, Am 05.02.2010 um 09:00 schrieb Roger H?kansson: > Maciej (Matchek) Blizinski wrote: >> I spoke about this today with >> Phil on IRC, there may be devel packages with architecture related >> settings. I need to hunt down some of them and build checks based on >> some examples. > > I don't think you can make it totally foolproof unless you have access > to both ARCH-packages and diff them as part of the release procedure. Please stop trying to make devel-files ARCHALL. It can't be done if you have 64 bit because you have arch-specific directories. If the app has devel-files at all it sounds like some other apps may rely on it and than we already decided to provide 64 bit libs just in case. And the few 32 bit ones are not worth the effort with only a few kbs of mirrorspace to gain. IMHO the risk outweighs the gain here. Best regards -- Dago From maciej at opencsw.org Fri Feb 5 11:08:20 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 5 Feb 2010 10:08:20 +0000 Subject: [csw-maintainers] GAR: archall - a new checkpkg module In-Reply-To: References: <4B6BD009.8020903@opencsw.org> Message-ID: On Fri, Feb 5, 2010 at 9:53 AM, Dagobert Michelsen wrote: > Hi, > > Am 05.02.2010 um 09:00 schrieb Roger H?kansson: >> >> Maciej (Matchek) Blizinski wrote: >>> >>> I spoke about this today with >>> Phil on IRC, there may be devel packages with architecture related >>> settings. ?I need to hunt down some of them and build checks based on >>> some examples. >> >> I don't think you can make it totally foolproof unless you have access >> to both ARCH-packages and diff them as part of the release procedure. > > Please stop trying to make devel-files ARCHALL. It can't be done if > you have 64 bit because you have arch-specific directories. If the > app has devel-files at all it sounds like some other apps may rely > on it and than we already decided to provide 64 bit libs just in > case. And the few 32 bit ones are not worth the effort with only a > few kbs of mirrorspace to gain. > > IMHO the risk outweighs the gain here. In this case, should checkpkg try to identify devel packages and throw an error if they're archall? From dam at opencsw.org Fri Feb 5 11:18:06 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 5 Feb 2010 11:18:06 +0100 Subject: [csw-maintainers] GAR: archall - a new checkpkg module In-Reply-To: References: <4B6BD009.8020903@opencsw.org> Message-ID: <030A90C6-BC37-4ED8-BDF1-A2704DD656A0@opencsw.org> Hi Maciej, Am 05.02.2010 um 11:08 schrieb Maciej (Matchek) Blizinski: > On Fri, Feb 5, 2010 at 9:53 AM, Dagobert Michelsen > wrote: >> Am 05.02.2010 um 09:00 schrieb Roger H?kansson: >>> Maciej (Matchek) Blizinski wrote: >>>> I spoke about this today with >>>> Phil on IRC, there may be devel packages with architecture related >>>> settings. I need to hunt down some of them and build checks >>>> based on >>>> some examples. >>> >>> I don't think you can make it totally foolproof unless you have >>> access >>> to both ARCH-packages and diff them as part of the release >>> procedure. >> >> Please stop trying to make devel-files ARCHALL. It can't be done if >> you have 64 bit because you have arch-specific directories. If the >> app has devel-files at all it sounds like some other apps may rely >> on it and than we already decided to provide 64 bit libs just in >> case. And the few 32 bit ones are not worth the effort with only a >> few kbs of mirrorspace to gain. >> >> IMHO the risk outweighs the gain here. > > In this case, should checkpkg try to identify devel packages and throw > an error if they're archall? I think that would be too hard. Depending on the language devel-packages may not always contain header-files, but manpages, developer documentation, perl developer scripts or something. Unless we have the exceptions machanism for checkpkg in place, at least. Best regards -- Dago From dam at opencsw.org Fri Feb 5 11:30:51 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 5 Feb 2010 11:30:51 +0100 Subject: [csw-maintainers] GAR: New variable names (dependencies and noisaexec) In-Reply-To: References: <20100204122714.GB20333@vonmossner.de> Message-ID: Hi, Am 04.02.2010 um 19:08 schrieb Maciej (Matchek) Blizinski: > On Thu, Feb 4, 2010 at 12:27 PM, Benjamin von Mossner > wrote: >>>> The change has been pushed in r8335[2]. ?Since all sources have >>>> been >>>> edited, including GAR, everything should Just Work(tm). >> >> wow, good work. >> How about a warning or error if someone still uses the old syntax? >> Something like.. >> [snip] >> REQUIRED_PKGS is deprecated in favour of RUNTIME_DEP_PKGS >> [snap] > > Yes, it would be useful. I guess Dago would have the best idea about > how to implement this check and where to put it. Done in r8357: http://sourceforge.net/apps/trac/gar/changeset/8357 Best regards -- Dago From bonivart at opencsw.org Fri Feb 5 16:57:41 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 5 Feb 2010 16:57:41 +0100 Subject: [csw-maintainers] /testing spamassassin In-Reply-To: <20100131.18401800.3054865960@gyor.oxdrove.co.uk> References: <625385e31001261327k31719e1bo2bd90963eb99a3d2@mail.gmail.com> <20100131.18401800.3054865960@gyor.oxdrove.co.uk> Message-ID: <625385e31002050757p7f50fbc9p6925912296349d22@mail.gmail.com> On Sun, Jan 31, 2010 at 7:40 PM, James Lee wrote: > 1. sa-update needs gpg and now that sa-update is needed CSWgpg should be > added to the package depend list. > > # /opt/csw/bin/sa-update > error: gpg required but not found! > > > 2. The new package includes spamd start up code. ?This is good (saves > me adding my own) but to change the spamd options requires editing > /etc/opt/csw/init.d/cswspamd and the edits will be lost on package > removal. ?Can we have a way of setting the spamd args from a conf file? > > ... find CONF ... > ARGS=`cat $CONF` > spamd -d $ARGS > > > > > Other thoughts... > The fist time it starts svc gets in a tiz because sa-update hasn't > run. ?Perhaps needs some way of breaking the loop if not configured. I have tried to fix the above in the latest package: http://mirror.opencsw.org/testing/spamassassin-3.3.0,REV=2010.02.05-SunOS5.8-sparc-CSW.pkg.gz http://mirror.opencsw.org/testing/spamassassin-3.3.0,REV=2010.02.05-SunOS5.8-i386-CSW.pkg.gz -- /peter From dam at opencsw.org Fri Feb 5 17:54:44 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 5 Feb 2010 17:54:44 +0100 Subject: [csw-maintainers] Problem with "alternatives" on updates Message-ID: <7E966BC5-D968-4A0B-B273-D491E8E2CDF2@opencsw.org> Hi, I have tested alternatives on CSWautomake to switch automake/aclocal between the included versions 1.6 to 1.11. The problem is that if I manually select a version (like 1.10) and then try to upgrade the package the selection is not preserved. On package deinstallation the choices are removed from the alternatives system, and if the manually selected choice is removed the group switches back to another choice. When the new package then installs the new choices the previous manual selection is lost. If I would just preserve the link in /etc/opt/csw the target may or may not exist in the new package. There should be something like "get me the existing manual config" and "re-apply this manual config". Could please some Linux-freak look at how Debian/RedHat handle this? I guess we need update-hook-scripts to handle this cleanly. Best regards -- Dago From phil at bolthole.com Fri Feb 5 18:31:48 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 5 Feb 2010 09:31:48 -0800 Subject: [csw-maintainers] Problem with "alternatives" on updates In-Reply-To: <7E966BC5-D968-4A0B-B273-D491E8E2CDF2@opencsw.org> References: <7E966BC5-D968-4A0B-B273-D491E8E2CDF2@opencsw.org> Message-ID: On Fri, Feb 5, 2010 at 8:54 AM, Dagobert Michelsen wrote: > I guess we need > update-hook-scripts to handle this cleanly. I'm guessing we just need to think more carefully about how the PKG system works. Lets analyze things a little more deeply. > I have tested alternatives on CSWautomake to switch > automake/aclocal between the included versions > 1.6 to 1.11. The problem is that if I manually select > a version (like 1.10) and then try to upgrade the > package the selection is not preserved. On > package deinstallation the choices are removed > from the alternatives system, Q1: do you mean "on deinstallation of CSWautomake"? I presume yes, but just want to make sure. Q2: Where is the information about the user choice stored? Is it solely in the symlink? If so, seems like the simple choice is to not have the symlink be part of the prototype file of CSWautomake, and then it wont go away. Contrariwise, if you want to keep the regular filesystem "clean" after pkgrm, then you may consider a between-installations symlink preservation class. You could use cswpreserveconf as a model. Although you would probably want more than just a "preservesymlink" class. You would probably want a "cswsymlinkalternatives" class, to make it hook in more fully to the "alternatives" package. From dam at opencsw.org Fri Feb 5 19:34:03 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 5 Feb 2010 19:34:03 +0100 Subject: [csw-maintainers] Problem with "alternatives" on updates In-Reply-To: References: <7E966BC5-D968-4A0B-B273-D491E8E2CDF2@opencsw.org> Message-ID: <541589E2-A9E9-4E0C-885E-4F47D14A97D0@opencsw.org> Hi Phil, Am 05.02.2010 um 18:31 schrieb Philip Brown: > On Fri, Feb 5, 2010 at 8:54 AM, Dagobert Michelsen > wrote: >> I guess we need >> update-hook-scripts to handle this cleanly. > > I'm guessing we just need to think more carefully about how the PKG > system works. > Lets analyze things a little more deeply. Yes. Before deploying :-) >> I have tested alternatives on CSWautomake to switch >> automake/aclocal between the included versions >> 1.6 to 1.11. The problem is that if I manually select >> a version (like 1.10) and then try to upgrade the >> package the selection is not preserved. On >> package deinstallation the choices are removed >> from the alternatives system, > > Q1: do you mean "on deinstallation of CSWautomake"? I presume yes, but > just want to make sure. In the context of an update, yes. Which means pkgrm followed by pkgadd. > Q2: Where is the information about the user choice stored? > Is it solely in the symlink? > If so, seems like the simple choice is to not have the symlink be part > of the prototype file of CSWautomake, and then it wont go away. The problem is slightly different: The symlinks are added dynamically by "alternatives --install ... " on package installation (either cas or postinstall) and removed by "alternatives --remove ..." on package removal (either cas or preremove). The means the link is not part of the package, but will go away on package removal. There are two different cases: 1. Use alternatives to select different binaries inside a package This would be used for CSWautomake, where there are multiple versions of the same software inside the package. In this case the manual selection should be preserved iff there is an update going on. 2. Use alternatives to select different flavors of an application in different packaes. This would be used for CSWmutt-ncurses and CSWmutt-slang. As you either upgrade a package or simply deinstall it you cannot decide from an in-package perspective if the current selection should be kept or discarded. I guess the only way is to use an update-hook. (/me taking deep look into http://wiki.opencsw.org/package-hooks) For case 1. the preupgrade- and postupgrade-hooks look useful to copy the link from /etc/opt/csw/alternatives/... to the preservation area similar to cswpreserveconf and replace the newly made link in /etc/opt/csw/alternatives, but only iff the group is operating in manual mode. The replacement should be done with --set to readlink() (--set is btw. only available in the RedHat implementaion, so we probaly choose the right one :-). Otherwise an addition of a new version would not automatically lead to updated links even if the group was in automatic mode. For case 2. the situation is slightly different: When multiple packages containing binaries of the same linkgroup are upgraded and the same procedure as 1. would be used the link would be preserved and recreated multiple times, but I guess it must be this way as on --install in the cas of the package the link would be adjusted and manual-mode will not be preserved on complete deinstallation of the linkgroup. One more thing about hook script naming conventions: When we start putting *a lot* of hooks in the directories this can become a serious performance bottleneck. I suggest to restrict calling of scripts to scripts starting with [0-9]. Additionally, scripts with the same name as the package are called. This way we avoid executing possibly hundreds of scripts where each one is only valid for a single package. Best regards -- Dago From bwalton at opencsw.org Fri Feb 5 19:52:25 2010 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 05 Feb 2010 13:52:25 -0500 Subject: [csw-maintainers] Problem with "alternatives" on updates In-Reply-To: <541589E2-A9E9-4E0C-885E-4F47D14A97D0@opencsw.org> References: <7E966BC5-D968-4A0B-B273-D491E8E2CDF2@opencsw.org> <541589E2-A9E9-4E0C-885E-4F47D14A97D0@opencsw.org> Message-ID: <1265395363-sup-5428@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Fri Feb 05 13:34:03 -0500 2010: Hi Dago, > I guess the only way is to use an update-hook. > (/me taking deep look into http://wiki.opencsw.org/package-hooks) I agree with your assessment, but we should note that pkg-get doesn't support hooks yet (unless I missed an update), so this could be thorny. Phil, are there plans to update pkg-get? I know the last time this was mentioned, you didn't have the time. Has that changed or is there someone else willing to add the feature? > One more thing about hook script naming conventions: When we > start putting *a lot* of hooks in the directories this can > become a serious performance bottleneck. I suggest to restrict Would you even notice amidst the stock slowness of pkgadd/pkgrm? :) > calling of scripts to scripts starting with [0-9]. Additionally, > scripts with the same name as the package are called. This way > we avoid executing possibly hundreds of scripts where each > one is only valid for a single package. Anyone know whether the Debian hook system has this limitation? I hadn't envisioned this sort of package-specific hook when I came up with this. The intent was for generic actions that should be done for all (or at least the bulk of) packages. The system doesn't preclude this specificity, but I think it could be handled slightly differently. Deliver a single package containing the hooks required to handle the various cases presented by this challenge. The hook looks for a file in /etc/opt/csw/pkg/CSWfoo/handle-altnernatives (or something) and takes the required action if that file is present. That way, you've made a CAS style generic hook script. Would that work better than each package dropping it's own custom hook in the directories to handle (essentially) the same task? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dam at opencsw.org Fri Feb 5 20:04:18 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 5 Feb 2010 20:04:18 +0100 Subject: [csw-maintainers] Problem with "alternatives" on updates In-Reply-To: <1265395363-sup-5428@ntdws12.chass.utoronto.ca> References: <7E966BC5-D968-4A0B-B273-D491E8E2CDF2@opencsw.org> <541589E2-A9E9-4E0C-885E-4F47D14A97D0@opencsw.org> <1265395363-sup-5428@ntdws12.chass.utoronto.ca> Message-ID: <96DA66CA-B8A6-4AA6-A51B-27E6942E537C@opencsw.org> Hi Ben, Am 05.02.2010 um 19:52 schrieb Ben Walton: > Excerpts from Dagobert Michelsen's message of Fri Feb 05 13:34:03 > -0500 2010: >> I guess the only way is to use an update-hook. >> (/me taking deep look into http://wiki.opencsw.org/package-hooks) > > I agree with your assessment, but we should note that pkg-get doesn't > support hooks yet (unless I missed an update), so this could be > thorny. Phil, are there plans to update pkg-get? I know the last > time this was mentioned, you didn't have the time. Has that changed > or is there someone else willing to add the feature? Without hooks the manual selection would just not be preserved. >> One more thing about hook script naming conventions: When we >> start putting *a lot* of hooks in the directories this can >> become a serious performance bottleneck. I suggest to restrict > > Would you even notice amidst the stock slowness of pkgadd/pkgrm? :) Maybe I would, but with your appraoch below it won't be necessary :) >> calling of scripts to scripts starting with [0-9]. Additionally, >> scripts with the same name as the package are called. This way >> we avoid executing possibly hundreds of scripts where each >> one is only valid for a single package. > > Anyone know whether the Debian hook system has this limitation? I > hadn't envisioned this sort of package-specific hook when I came up > with this. The intent was for generic actions that should be done for > all (or at least the bulk of) packages. The system doesn't preclude > this specificity, but I think it could be handled slightly > differently. > > Deliver a single package containing the hooks required to handle the > various cases presented by this challenge. The hook looks for a file > in /etc/opt/csw/pkg/CSWfoo/handle-altnernatives (or something) and > takes the required action if that file is present. > > That way, you've made a CAS style generic hook script. Would that > work better than each package dropping it's own custom hook in the > directories to handle (essentially) the same task? Clever! However, and here comes the tricky part: Which package should contain this generic alternatives-upgrade-hook? CSWalternatives itself? I would think so, but is the user supposed to know of the differences between pkg-get and pkgutil? Can we make him aware of differences in upgrade procedures? Anyay, thanks for the comment and for now I'll start adding the script to CSWalternatives and do some more experiments. Best regards -- Dago From bwalton at opencsw.org Fri Feb 5 20:12:54 2010 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 05 Feb 2010 14:12:54 -0500 Subject: [csw-maintainers] Problem with "alternatives" on updates In-Reply-To: <96DA66CA-B8A6-4AA6-A51B-27E6942E537C@opencsw.org> References: <7E966BC5-D968-4A0B-B273-D491E8E2CDF2@opencsw.org> <541589E2-A9E9-4E0C-885E-4F47D14A97D0@opencsw.org> <1265395363-sup-5428@ntdws12.chass.utoronto.ca> <96DA66CA-B8A6-4AA6-A51B-27E6942E537C@opencsw.org> Message-ID: <1265397059-sup-744@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Fri Feb 05 14:04:18 -0500 2010: Hi Dago, > Clever! However, and here comes the tricky part: Which package should > contain this generic alternatives-upgrade-hook? CSWalternatives itself? > I would think so, but is the user supposed to know of the differences > between pkg-get and pkgutil? Can we make him aware of differences in > upgrade procedures? I think the CSWalternatives package is a good spot for it. I'd suggest that the recently suggested i.cswnotice CAS be used to present a message at CSWalternatives install time indicating that unless the user uses pkgutil, some functionality will not work and that they'd need to manually intervene with the alternatives system. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 -------------- 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 Feb 5 21:10:14 2010 From: phil at bolthole.com (Philip Brown) Date: Fri, 5 Feb 2010 12:10:14 -0800 Subject: [csw-maintainers] Problem with "alternatives" on updates In-Reply-To: <96DA66CA-B8A6-4AA6-A51B-27E6942E537C@opencsw.org> References: <7E966BC5-D968-4A0B-B273-D491E8E2CDF2@opencsw.org> <541589E2-A9E9-4E0C-885E-4F47D14A97D0@opencsw.org> <1265395363-sup-5428@ntdws12.chass.utoronto.ca> <96DA66CA-B8A6-4AA6-A51B-27E6942E537C@opencsw.org> Message-ID: On Fri, Feb 5, 2010 at 11:04 AM, Dagobert Michelsen wrote: > >> I agree with your assessment, but we should note that pkg-get doesn't >> support hooks yet (unless I missed an update), so this could be >> thorny. ?Phil, are there plans to update pkg-get? ?I know the last >> time this was mentioned, you didn't have the time. ?Has that changed >> or is there someone else willing to add the feature? > > Without hooks the manual selection would just not be preserved. Dago, you seem to be jumping automatically to "let's use hooks", without considering if things can be achieved another way. I think there are even MULTIPLE ways the desired behaviour can be achieved, without using hooks. hooks should only be used as a *last resort*. (because our packages should do their best to work with plain old "/usr/sbin/pkgadd", as well as the more common tools!) Please examine the alternatives more thoroughly first. From maciej at opencsw.org Sat Feb 6 00:30:23 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 5 Feb 2010 23:30:23 +0000 Subject: [csw-maintainers] ldd -r and "symbol not found:" errors: how to disable the check Message-ID: I've added a new checkpkg module a few days ago, which runs "ldd -r" and greps the output for "symbol not found:". This catches shared libraries which are not self-contained. Some of you will hit the problem in which this check throws a false positive: There might be libraries which are non-self-contained by design. For now, the easiest way to go around this is to disable this particular module by removing the executable bit from the file: chmod 644 gar/bin/checkpkg.d/checkpkg-missing-symbols.py It's only a temporary workaround, before we get the overrides mechanism in place. From rupert at opencsw.org Sat Feb 6 18:35:39 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 6 Feb 2010 18:35:39 +0100 Subject: [csw-maintainers] building netscape security services, nss In-Reply-To: References: <6af4271002030207y1e952cdfycbbb1554d7eb548f@mail.gmail.com> Message-ID: <6af4271002060935s6dcc20eav8836148680c08f7d@mail.gmail.com> On Wed, Feb 3, 2010 at 19:14, Philip Brown wrote: > On Wed, Feb 3, 2010 at 2:17 AM, Maciej (Matchek) Blizinski > wrote: > > > > Firefox was done by William. I was working on NSS, and it even > > compiles on Solaris 10, but not Solaris 8, but the reason is unclear. > > I vaguely recall, that netscape for some unfathomable reason, took a > very different approach to security and nss, between [sol8 and sol > 10?] > > One of them attempts to compile, and does actually deliver in the > package, a completely separate [lib*nss*solaris*security*] or > something, and one does not. > It gets dynamically linked in to the "main" nss lib, and is a critical > dependancy, if i recall correctly. > my collegue found an existing old binary - so our need is less urgent now. as we are not using solaris-8 anymore, i tried to build a solaris-10 package and gar said: rupert at build10s:~/mgar/pkg/nss/trunk $ gmake clean package [ Cleaning for modulation isa-sparcv8: ISA=sparcv8 ] [ Cleaning for modulation isa-sparcv9: ISA=sparcv9 ] gar/gar.pkg.mk:691: *** You are building this package on a non-requested platform host 'build10s'. The follow platforms were requested: gar/gar.pkg.mk:691: *** - solaris8-sparc to be build on host 'build8s' gar/gar.pkg.mk:691: *** - solaris8-i386 to be build on host 'build8x' gar/gar.pkg.mk:691: *** You can execute 'gmake platforms' to automatically build on all necessary platforms.. Stop. would it be even appropriate to try to compile a solaris-10 package and release it? if yes, what is the correct way to do it? rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sun Feb 7 00:56:56 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 6 Feb 2010 23:56:56 +0000 Subject: [csw-maintainers] [GAR] Overrides implemented Message-ID: I've implemented overrides for the modular checks in checkpkg and committed it in r8367. It's a relatively major change from the previous workings of the modular checks. Here's a summary of changes: - modules no longer report failed tests via the system exit code - modules have a new command line flag, "-o", which tells which file to use for output - errors aren't reported when individual modules are running, they're reported later - a lintian-inspired simple minilanguage is used to communicate between modules and the central part of the code - it's possible to override a certain type of check, no matter what file it concerns, for instance "license-missing" - it's also possible to override only a specific file, for instance: missing-symbols foo.so - override files live in /opt/csw/share/checkpkg/overrides/ The documentation is at http://wiki.opencsw.org/checkpkg - it has a section explaining how to create overrides. There's not GAR integration yet, I'll talk to Dago about it. I'm sure it'll be easy to use. In case of any problems, please e-mail me, or talk to me on the IRC channel. If I'm not around and you need to get your stuff going, revert to r8366. Maciej From maciej at opencsw.org Sun Feb 7 13:33:34 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 7 Feb 2010 12:33:34 +0000 Subject: [csw-maintainers] [GAR] Overrides implemented In-Reply-To: References: Message-ID: On Sat, Feb 6, 2010 at 11:56 PM, Maciej (Matchek) Blizinski wrote: > I've implemented overrides for the modular checks in checkpkg and > committed it in r8367. There's an update: r8369 improves the screen output to be more informative. There one more important change I need to mention. Missing dependencies are no longer suggestions, they are errors. This means a relatively high rate of false positives, especially for SUNW packages. Here's an example: # You can use the following lines to create overrides # See http://wiki.opencsw.org/checkpkg # /var/tmp/dissect.26101/tags.libs: # Tags reported by shared library linking consistency module CSWlibpq-84: missing-dependency SUNWlmsx CSWlibpq-84: missing-dependency CSWkrb5lib One of them is a genuine missing library: CSWkrb5lib. I added it to RUNTIME_DEP_PKGS. But I don't want to add the other one. To fix this, I added the following lines to my Makefile: ginstall -m 755 -d $(PKGROOT)$(prefix)/share/checkpkg/overrides (echo "CSWlibpq-84: missing-dependency SUNWgssx"; \ echo "CSWlibpq-84: missing-dependency SUNWlmsx"; \ ) \ > $(PKGROOT)$(prefix)/share/checkpkg/overrides/libpq84 Maciej From bonivart at opencsw.org Sun Feb 7 13:40:19 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 7 Feb 2010 13:40:19 +0100 Subject: [csw-maintainers] [GAR] Overrides implemented In-Reply-To: References: Message-ID: <625385e31002070440u62cd1019g3813d1c5ede85896@mail.gmail.com> On Sun, Feb 7, 2010 at 1:33 PM, Maciej (Matchek) Blizinski wrote: > There one more important change I need to mention. ?Missing > dependencies are no longer suggestions, they are errors. ?This means a > relatively high rate of false positives, especially for SUNW packages. > ?Here's an example: Are you saying we will get errors for SUNW deps and need to use the override system for those? -- /peter From maciej at opencsw.org Sun Feb 7 13:59:53 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 7 Feb 2010 12:59:53 +0000 Subject: [csw-maintainers] [GAR] Overrides implemented In-Reply-To: <625385e31002070440u62cd1019g3813d1c5ede85896@mail.gmail.com> References: <625385e31002070440u62cd1019g3813d1c5ede85896@mail.gmail.com> Message-ID: On Sun, Feb 7, 2010 at 12:40 PM, Peter Bonivart wrote: > On Sun, Feb 7, 2010 at 1:33 PM, Maciej (Matchek) Blizinski > wrote: >> There one more important change I need to mention. ?Missing >> dependencies are no longer suggestions, they are errors. ?This means a >> relatively high rate of false positives, especially for SUNW packages. >> ?Here's an example: > > Are you saying we will get errors for SUNW deps and need to use the > override system for those? Yes. Please tell me if I'm nuts. From bonivart at opencsw.org Sun Feb 7 14:16:07 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 7 Feb 2010 14:16:07 +0100 Subject: [csw-maintainers] [GAR] Overrides implemented In-Reply-To: References: <625385e31002070440u62cd1019g3813d1c5ede85896@mail.gmail.com> Message-ID: <625385e31002070516ve3d8457oe3fd703f8c7f6be7@mail.gmail.com> On Sun, Feb 7, 2010 at 1:59 PM, Maciej (Matchek) Blizinski wrote: >> Are you saying we will get errors for SUNW deps and need to use the >> override system for those? > > Yes. ?Please tell me if I'm nuts. I wouldn't go that far ;-) but since we never include SUNW deps I don't think it should throw an error either (and cause more work by implementing the override system). I think we need a default override for SUNW deps. :-) Error for missing CSW deps. Suggestion for missing SUNW deps. -- /peter From maciej at opencsw.org Sun Feb 7 14:30:03 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 7 Feb 2010 13:30:03 +0000 Subject: [csw-maintainers] [GAR] Overrides implemented In-Reply-To: <625385e31002070516ve3d8457oe3fd703f8c7f6be7@mail.gmail.com> References: <625385e31002070440u62cd1019g3813d1c5ede85896@mail.gmail.com> <625385e31002070516ve3d8457oe3fd703f8c7f6be7@mail.gmail.com> Message-ID: On Sun, Feb 7, 2010 at 1:16 PM, Peter Bonivart wrote: > On Sun, Feb 7, 2010 at 1:59 PM, Maciej (Matchek) Blizinski > wrote: >>> Are you saying we will get errors for SUNW deps and need to use the >>> override system for those? >> >> Yes. ?Please tell me if I'm nuts. > > I wouldn't go that far ;-) but since we never include SUNW deps I > don't think it should throw an error either (and cause more work by > implementing the override system). I think we need a default override > for SUNW deps. :-) > > Error for missing CSW deps. > Suggestion for missing SUNW deps. Fair enough. Done in r8374. From james at opencsw.org Sun Feb 7 14:58:43 2010 From: james at opencsw.org (James Lee) Date: Sun, 07 Feb 2010 13:58:43 GMT Subject: [csw-maintainers] /testing spamassassin In-Reply-To: <625385e31002050757p7f50fbc9p6925912296349d22@mail.gmail.com> References: <625385e31001261327k31719e1bo2bd90963eb99a3d2@mail.gmail.com> <20100131.18401800.3054865960@gyor.oxdrove.co.uk> <625385e31002050757p7f50fbc9p6925912296349d22@mail.gmail.com> Message-ID: <20100207.13584300.1028863917@gyor.oxdrove.co.uk> On 05/02/10, 15:57:41, Peter Bonivart wrote regarding Re: [csw-maintainers] /testing spamassassin: > On Sun, Jan 31, 2010 at 7:40 PM, James Lee wrote: > > 1. sa-update needs gpg and now that sa-update is needed CSWgpg should be > > added to the package depend list. > > > > # /opt/csw/bin/sa-update > > error: gpg required but not found! > > > > > > 2. The new package includes spamd start up code. ?This is good (saves > > me adding my own) but to change the spamd options requires editing > > /etc/opt/csw/init.d/cswspamd and the edits will be lost on package > > removal. ?Can we have a way of setting the spamd args from a conf file? > > > > ... find CONF ... > > ARGS=`cat $CONF` > > spamd -d $ARGS > > > > > > > > > > Other thoughts... > > The fist time it starts svc gets in a tiz because sa-update hasn't > > run. ?Perhaps needs some way of breaking the loop if not configured. > I have tried to fix the above in the latest package: > http://mirror.opencsw.org/testing/spamassassin-3.3.0,REV=2010.02.05- > SunOS5.8-sparc-CSW.pkg.gz > http://mirror.opencsw.org/testing/spamassassin-3.3.0,REV=2010.02.05- > SunOS5.8-i386-CSW.pkg.gz Thank you, this addresses the three issues I mentioned. I am now running 3.3.0,REV=2010.02.05 sparc successfully. In addition to needed sa-update and the spamd changes there are some changes to the AWL SQL, please draw users' attention to the update notes on release. James. From james at opencsw.org Sun Feb 7 15:01:22 2010 From: james at opencsw.org (James Lee) Date: Sun, 07 Feb 2010 14:01:22 GMT Subject: [csw-maintainers] RFD: Releases and staging proposal In-Reply-To: References: Message-ID: <20100207.14012200.1398821831@gyor.oxdrove.co.uk> On 02/02/10, 16:26:45, Maciej "(Matchek)" Blizinski wrote regarding [csw-maintainers] RFD: Releases and staging proposal: > One of the larger topics during the Wintercamp in Zurich was the > release schedule: how do we get a new stable? Last weekend, I sat > down and wrote up a document describing the release proposal. It > describes the initial problem, Some attendees of your meeting control blocking bugs, we need less talk and more action. > the target mirror layout and the > release process. It also has a plan of how do we get there. Here's > the link: > http://wiki.opencsw.org/releases-and-staging > I'd like to thank all the people who helped by discussing, > copy-editing and reviewing the document. > What do people think about this design? Should we modify it? Should > we implement it? Please discuss. This is roughly what has existed for several years. Name changes. The snapshot has used its date stamp name and it works for its purpose. Experiment means a test or investigation planned to provide evidence for or against a hypothesis. What we currently called testing has release candidates and is not for proving hypotheses, therefor testing is a better name and is the currently used and known name. James. From james at opencsw.org Sun Feb 7 15:04:53 2010 From: james at opencsw.org (James Lee) Date: Sun, 07 Feb 2010 14:04:53 GMT Subject: [csw-maintainers] cswclassutils: location of template init scripts In-Reply-To: References: Message-ID: <20100207.14045300.4254301123@gyor.oxdrove.co.uk> On 01/02/10, 20:31:18, Philip Brown wrote regarding [csw-maintainers] cswclassutils: location of template init scripts: > currently, our wiki for cswclassutils suggests the initial location > for the init script should be > INITSMF = /etc/opt/csw/init.d/cswfoo > I think it would be better for our users, if we standardize on a > location under /opt/csw > For example, /opt/csw/etc/init.d I agree with this. I say the package should deliver to /opt/csw and user and local data files should go in /etc/opt and /var/opt. Template configuration files break this logic, the package might also lay out directories in /etc/opt and /var/opt. James. From hson at opencsw.org Sun Feb 7 19:23:39 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Sun, 07 Feb 2010 19:23:39 +0100 Subject: [csw-maintainers] ldd -r and "symbol not found:" errors: how to disable the check In-Reply-To: References: Message-ID: <4B6F052B.7020809@opencsw.org> On 2010-02-06 00:30, Maciej (Matchek) Blizinski wrote: > I've added a new checkpkg module a few days ago, which runs "ldd -r" > and greps the output for "symbol not found:". This catches shared > libraries which are not self-contained. > > Some of you will hit the problem in which this check throws a false > positive: There might be libraries which are non-self-contained by > design. That's not the only case, when building packages where you have binaries linked to libraries which belongs to the package being built, or when a package contains more than one library and there are some dependencies between them, you also get an error. Currently "missing-symbols" only seem to work when there are binaries and libraries linked to libraries outside the package. From dam at opencsw.org Sun Feb 7 21:21:53 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 7 Feb 2010 21:21:53 +0100 Subject: [csw-maintainers] building netscape security services, nss In-Reply-To: <6af4271002060935s6dcc20eav8836148680c08f7d@mail.gmail.com> References: <6af4271002030207y1e952cdfycbbb1554d7eb548f@mail.gmail.com> <6af4271002060935s6dcc20eav8836148680c08f7d@mail.gmail.com> Message-ID: <34E3C742-E04E-4FE7-8533-FEE6ED8223A3@opencsw.org> Hi Rupert, Am 06.02.2010 um 18:35 schrieb rupert THURNER: > On Wed, Feb 3, 2010 at 19:14, Philip Brown wrote: > On Wed, Feb 3, 2010 at 2:17 AM, Maciej (Matchek) Blizinski > wrote: > > > > Firefox was done by William. I was working on NSS, and it even > > compiles on Solaris 10, but not Solaris 8, but the reason is > unclear. > > I vaguely recall, that netscape for some unfathomable reason, took a > very different approach to security and nss, between [sol8 and sol > 10?] > > One of them attempts to compile, and does actually deliver in the > package, a completely separate [lib*nss*solaris*security*] or > something, and one does not. > It gets dynamically linked in to the "main" nss lib, and is a critical > dependancy, if i recall correctly. > > my collegue found an existing old binary - so our need is less > urgent now. as we are not using solaris-8 anymore, i tried to build > a solaris-10 package and gar said: > > rupert at build10s:~/mgar/pkg/nss/trunk > $ gmake clean package > [ Cleaning for modulation isa-sparcv8: ISA=sparcv8 ] > [ Cleaning for modulation isa-sparcv9: ISA=sparcv9 ] > gar/gar.pkg.mk:691: *** You are building this package on a non- > requested platform host 'build10s'. The follow platforms were > requested: > gar/gar.pkg.mk:691: *** - solaris8-sparc to be build on host 'build8s' > gar/gar.pkg.mk:691: *** - solaris8-i386 to be build on host 'build8x' > gar/gar.pkg.mk:691: *** You can execute 'gmake platforms' to > automatically build on all necessary platforms.. Stop. > > > would it be even appropriate to try to compile a solaris-10 package > and release it? if yes, what is the correct way to do it? The default is still to assemble only on Solaris 8. If you want to assemble on Solaris 10 you have to adjust PACKAGING_PLATFORMS as described here: BTW, no need to open a bug, and yes, the Trac bugtracker would be the right one for GAR :-) Apart from that it is AFAIK policy to release starting with Solaris 9 as the release is still fully supported by Sun. Best regards -- Dago -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Sun Feb 7 21:30:58 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 7 Feb 2010 21:30:58 +0100 Subject: [csw-maintainers] pkgrequests better on Mantis Message-ID: Hi, we just got another package request. I propose to collect package requests in Mantis. This way it is cleanly tracked. After the package has been released the "bug" can be moved over the new category and the original submitter gets notified automatically when the package is released. Comments? Best regards -- Dago From dam at opencsw.org Sun Feb 7 21:37:01 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 7 Feb 2010 21:37:01 +0100 Subject: [csw-maintainers] RFD: Releases and staging proposal In-Reply-To: <20100207.14012200.1398821831@gyor.oxdrove.co.uk> References: <20100207.14012200.1398821831@gyor.oxdrove.co.uk> Message-ID: <4CA1F901-C232-4A4B-AB97-0F7F0CE7E9F2@opencsw.org> Hi James, Am 07.02.2010 um 15:01 schrieb James Lee: > On 02/02/10, 16:26:45, Maciej "(Matchek)" Blizinski > > wrote regarding [csw-maintainers] RFD: Releases and staging proposal: > >> One of the larger topics during the Wintercamp in Zurich was the >> release schedule: how do we get a new stable? Last weekend, I sat >> down and wrote up a document describing the release proposal. It >> describes the initial problem, > > Some attendees of your meeting control blocking bugs, we need less > talk and more action. Then how about assembling a list of bugs to be fixed before a new stable? This is one of the things which we want to fix by assigning bugs to specific released so this list can be assembled automatically. >> the target mirror layout and the >> release process. It also has a plan of how do we get there. Here's >> the link: > >> http://wiki.opencsw.org/releases-and-staging > >> I'd like to thank all the people who helped by discussing, >> copy-editing and reviewing the document. > >> What do people think about this design? Should we modify it? Should >> we implement it? Please discuss. > > This is roughly what has existed for several years. > > Name changes. The snapshot has used its date stamp name and it works > for its purpose. Experiment means a test or investigation planned to > provide evidence for or against a hypothesis. What we currently > called > testing has release candidates and is not for proving hypotheses, > therefor testing is a better name and is the currently used and known > name. I am not sure if I understand you correctly. Do you propose a different naming or a different process than what was described? That building a catalog on testing is absolutely useless has been shown in the past and the new experimental is already there. I suggest you specifically point out problems in the proposal and suggest specific changes to changes in the document like "I propose to change this paragraph to the following words: ...". Or do you want to say we should just keep the process as is? Best regards -- Dago From rupert at opencsw.org Sun Feb 7 22:14:51 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 7 Feb 2010 22:14:51 +0100 Subject: [csw-maintainers] building netscape security services, nss In-Reply-To: <34E3C742-E04E-4FE7-8533-FEE6ED8223A3@opencsw.org> References: <6af4271002030207y1e952cdfycbbb1554d7eb548f@mail.gmail.com> <6af4271002060935s6dcc20eav8836148680c08f7d@mail.gmail.com> <34E3C742-E04E-4FE7-8533-FEE6ED8223A3@opencsw.org> Message-ID: <6af4271002071314t14e7cd11rc0070058a1fe4196@mail.gmail.com> On Sun, Feb 7, 2010 at 21:21, Dagobert Michelsen wrote: > Hi Rupert, > > Am 06.02.2010 um 18:35 schrieb rupert THURNER: > > On Wed, Feb 3, 2010 at 19:14, Philip Brown wrote: > >> On Wed, Feb 3, 2010 at 2:17 AM, Maciej (Matchek) Blizinski >> wrote: >> > >> > Firefox was done by William. I was working on NSS, and it even >> > compiles on Solaris 10, but not Solaris 8, but the reason is unclear. >> >> I vaguely recall, that netscape for some unfathomable reason, took a >> very different approach to security and nss, between [sol8 and sol >> 10?] >> >> One of them attempts to compile, and does actually deliver in the >> package, a completely separate [lib*nss*solaris*security*] or >> something, and one does not. >> It gets dynamically linked in to the "main" nss lib, and is a critical >> dependancy, if i recall correctly. >> > > my collegue found an existing old binary - so our need is less urgent now. > as we are not using solaris-8 anymore, i tried to build a solaris-10 package > and gar said: > > rupert at build10s:~/mgar/pkg/nss/trunk > $ gmake clean package > [ Cleaning for modulation isa-sparcv8: ISA=sparcv8 ] > [ Cleaning for modulation isa-sparcv9: ISA=sparcv9 ] > gar/gar.pkg.mk:691: *** You are building this package on a non-requested > platform host 'build10s'. The follow platforms were requested: > gar/gar.pkg.mk:691: *** - solaris8-sparc to be build on host 'build8s' > gar/gar.pkg.mk:691: *** - solaris8-i386 to be build on host 'build8x' > gar/gar.pkg.mk:691: *** You can execute 'gmake platforms' to automatically > build on all necessary platforms.. Stop. > > > would it be even appropriate to try to compile a solaris-10 package and > release it? if yes, what is the correct way to do it? > > > The default is still to assemble only on Solaris 8. If you want to assemble > on Solaris 10 > you have to adjust PACKAGING_PLATFORMS as described here: > > BTW, no need to open a bug, and yes, the Trac bugtracker > > would be the right one for GAR :-) > > Apart from that it is AFAIK policy to release starting with Solaris 9 as > the release > is still fully supported by Sun. > many thanks for the hint! i would really appreciate if creating a package for solaris-10 can be done with "gmake package", without changing and commiting a makefile. rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Sun Feb 7 22:45:38 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 7 Feb 2010 22:45:38 +0100 Subject: [csw-maintainers] building netscape security services, nss In-Reply-To: <6af4271002071314t14e7cd11rc0070058a1fe4196@mail.gmail.com> References: <6af4271002030207y1e952cdfycbbb1554d7eb548f@mail.gmail.com> <6af4271002060935s6dcc20eav8836148680c08f7d@mail.gmail.com> <34E3C742-E04E-4FE7-8533-FEE6ED8223A3@opencsw.org> <6af4271002071314t14e7cd11rc0070058a1fe4196@mail.gmail.com> Message-ID: Hi Rupert, Am 07.02.2010 um 22:14 schrieb rupert THURNER: > many thanks for the hint! i would really appreciate if creating a > package for solaris-10 can be done with "gmake package", without > changing and commiting a makefile. Unfortunately this wish collides with the necessity to build packages fully automated with "gmake platforms" which builds on all requested platforms. Additionally, I think it is good if the Makefile contains information about the exact assembly for each platform. Could you please explain why you don't want to add this information to the Makefile? Best regards -- Dago From dam at opencsw.org Sun Feb 7 22:49:10 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 7 Feb 2010 22:49:10 +0100 Subject: [csw-maintainers] Update on the experimental project list Message-ID: <9B708277-629B-4D31-B040-F479E4C8978F@opencsw.org> Hi, there is now a small integration of the wiki into the experimental webpage where pages with the name "project-" are automatically linked to the respective sections: BTW: This was done using the XML-RPC interface of WikiDot: More integration ahead! Best regards -- Dago From bonivart at opencsw.org Sun Feb 7 22:57:24 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 7 Feb 2010 22:57:24 +0100 Subject: [csw-maintainers] Update on the experimental project list In-Reply-To: <9B708277-629B-4D31-B040-F479E4C8978F@opencsw.org> References: <9B708277-629B-4D31-B040-F479E4C8978F@opencsw.org> Message-ID: <625385e31002071357u490b839q8e58f5748283b3c9@mail.gmail.com> On Sun, Feb 7, 2010 at 10:49 PM, Dagobert Michelsen wrote: > Hi, > > there is now a small integration of the wiki into the experimental > webpage where pages with the name "project-" are automatically > linked to the respective sections: > ? Cool! I renamed the perl project page to project-perl. -- /peter From rupert at opencsw.org Sun Feb 7 23:00:01 2010 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 7 Feb 2010 23:00:01 +0100 Subject: [csw-maintainers] building netscape security services, nss In-Reply-To: References: <6af4271002030207y1e952cdfycbbb1554d7eb548f@mail.gmail.com> <6af4271002060935s6dcc20eav8836148680c08f7d@mail.gmail.com> <34E3C742-E04E-4FE7-8533-FEE6ED8223A3@opencsw.org> <6af4271002071314t14e7cd11rc0070058a1fe4196@mail.gmail.com> Message-ID: <6af4271002071400o647c1ad0q85c9ebe7873e19e1@mail.gmail.com> On Sun, Feb 7, 2010 at 22:45, Dagobert Michelsen wrote: > Hi Rupert, > > Am 07.02.2010 um 22:14 schrieb rupert THURNER: > > many thanks for the hint! i would really appreciate if creating a package >> for solaris-10 can be done with "gmake package", without changing and >> commiting a makefile. >> > > Unfortunately this wish collides with the necessity to build packages > fully automated with "gmake platforms" which builds on all requested > platforms. Additionally, I think it is good if the Makefile contains > information > about the exact assembly for each platform. Could you please explain > why you don't want to add this information to the Makefile? > > i guess its only convenience for testing. contrary, that "gmake platforms" respects a variable "PACKAGING_PLATFORMS" makes perfectly sense imo. rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From william at wbonnet.net Mon Feb 8 00:22:35 2010 From: william at wbonnet.net (William Bonnet) Date: Mon, 08 Feb 2010 00:22:35 +0100 Subject: [csw-maintainers] pkgrequests better on Mantis In-Reply-To: References: Message-ID: <4B6F4B3B.3060403@wbonnet.net> Hi Dagobert > we just got another package request. I propose to collect > package requests in Mantis. This way it is cleanly tracked. > After the package has been released the "bug" can be moved > over the new category and the original submitter gets > notified automatically when the package is released. > > Comments? Very good idea But i have a question :) From what i understand, pkgrequest deals with "please can you add this package to the catalog", and mantis keeps track of bugs on packages. Thus, when you request a package it does not exist in the catalog nor in mantis. So my question is how will you handle that ? does it mean missing packages will be automatically added to mantis ? or should we create ? special package for that ? like a "pkgrequest" entry and open bugs on it ? 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 Mon Feb 8 09:29:29 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 8 Feb 2010 09:29:29 +0100 Subject: [csw-maintainers] pkgrequests better on Mantis In-Reply-To: <4B6F4B3B.3060403@wbonnet.net> References: <4B6F4B3B.3060403@wbonnet.net> Message-ID: <10ED8A7A-1FD2-4CAB-9EA6-D64E55BDB0F2@opencsw.org> Hi William, Am 08.02.2010 um 00:22 schrieb William Bonnet: > Hi Dagobert >> we just got another package request. I propose to collect >> package requests in Mantis. This way it is cleanly tracked. >> After the package has been released the "bug" can be moved >> over the new category and the original submitter gets >> notified automatically when the package is released. >> >> Comments? > > Very good idea > > But i have a question :) > > From what i understand, pkgrequest deals with "please can you add > this package to the catalog", and mantis keeps track of bugs on > packages. > > Thus, when you request a package it does not exist in the catalog > nor in mantis. > > So my question is how will you handle that ? does it mean missing > packages will be automatically added to mantis ? or should we create > ? special package for that ? like a "pkgrequest" entry and open bugs > on it ? Yes, that was my idea. Create a "pkgrequests" section in Mantis for the pkgrequests. After the request has been processed and the package has been created the "bug" will be moved to the new package. Best regards -- Dago From james at opencsw.org Mon Feb 8 13:17:47 2010 From: james at opencsw.org (James Lee) Date: Mon, 08 Feb 2010 12:17:47 GMT Subject: [csw-maintainers] RFD: Releases and staging proposal In-Reply-To: <4CA1F901-C232-4A4B-AB97-0F7F0CE7E9F2@opencsw.org> References: <20100207.14012200.1398821831@gyor.oxdrove.co.uk> <4CA1F901-C232-4A4B-AB97-0F7F0CE7E9F2@opencsw.org> Message-ID: <20100208.12174700.451840536@gyor.oxdrove.co.uk> On 07/02/10, 20:37:01, Dagobert Michelsen wrote regarding Re: [csw-maintainers] RFD: Releases and staging proposal: > >> One of the larger topics during the Wintercamp in Zurich was the > >> release schedule: how do we get a new stable? Last weekend, I sat > >> down and wrote up a document describing the release proposal. It > >> describes the initial problem, > > > > Some attendees of your meeting control blocking bugs, we need less > > talk and more action. > Then how about assembling a list of bugs to be fixed before a new > stable? Mantis is a list of bugs. Look for block, crash or major and just do it. > This is one of the things which we want to fix by assigning bugs to > specific released so this list can be assembled automatically. Let's say there was a bug with a package that was only revealed by a new version of another package, the bug on the first package alone does not prevent the 2nd from being released. If the 2nd package is kept back everything is fine and bugs are tolerable although it gets complex if that 2nd package supports or requires others and a new branch needs to be created but crucially the initial bug need not be blocking. Of course the best action is to fix the initial bug but that's where I started. > >> http://wiki.opencsw.org/releases-and-staging > > > >> I'd like to thank all the people who helped by discussing, > >> copy-editing and reviewing the document. > > > >> What do people think about this design? Should we modify it? Should > >> we implement it? Please discuss. > > > > This is roughly what has existed for several years. > > > > Name changes. The snapshot has used its date stamp name and it works > > for its purpose. Experiment means a test or investigation planned to > > provide evidence for or against a hypothesis. What we currently > > called > > testing has release candidates and is not for proving hypotheses, > > therefor testing is a better name and is the currently used and known > > name. > I am not sure if I understand you correctly. Do you propose a different > naming or a different process than what was described? I'm not making a proposal. > That building > a catalog on testing is absolutely useless has been shown in the past Which I pointed out many times. > and the new experimental is already there. I suggest you specifically > point out problems in the proposal and suggest specific changes to > changes in the document like "I propose to change this paragraph > to the following words: ...". Or do you want to say we should just > keep the process as is? Anyone can suggest change - make it in the form of a proposal and fully justify it. It is for the proposer not me to say "I propose ...". I can't work with wiki pages appearing and being treating as the standard. James. From dam at opencsw.org Mon Feb 8 13:42:36 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 8 Feb 2010 13:42:36 +0100 Subject: [csw-maintainers] RFD: Releases and staging proposal In-Reply-To: <20100208.12174700.451840536@gyor.oxdrove.co.uk> References: <20100207.14012200.1398821831@gyor.oxdrove.co.uk> <4CA1F901-C232-4A4B-AB97-0F7F0CE7E9F2@opencsw.org> <20100208.12174700.451840536@gyor.oxdrove.co.uk> Message-ID: Hi James, Am 08.02.2010 um 13:17 schrieb James Lee: > On 07/02/10, 20:37:01, Dagobert Michelsen wrote > regarding > Re: [csw-maintainers] RFD: Releases and staging proposal: >> This is one of the things which we want to fix by assigning bugs to >> specific released so this list can be assembled automatically. > > Let's say there was a bug with a package that was only revealed by a > new version of another package, the bug on the first package alone > does not prevent the 2nd from being released. If the 2nd package is > kept back everything is fine and bugs are tolerable although it gets > complex if that 2nd package supports or requires others and a new > branch needs to be created but crucially the initial bug need not be > blocking. Of course the best action is to fix the initial bug but > that's where I started. Yes. >>>> http://wiki.opencsw.org/releases-and-staging >>> >>>> I'd like to thank all the people who helped by discussing, >>>> copy-editing and reviewing the document. >>> >>>> What do people think about this design? Should we modify it? >>>> Should >>>> we implement it? Please discuss. >>> >>> This is roughly what has existed for several years. >>> >>> Name changes. The snapshot has used its date stamp name and it >>> works >>> for its purpose. Experiment means a test or investigation planned >>> to >>> provide evidence for or against a hypothesis. What we currently >>> called >>> testing has release candidates and is not for proving hypotheses, >>> therefor testing is a better name and is the currently used and >>> known >>> name. > >> I am not sure if I understand you correctly. Do you propose a >> different >> naming or a different process than what was described? > > I'm not making a proposal. So we should stick to what we have and just drop the proposal? >> That building >> a catalog on testing is absolutely useless has been shown in the past > > Which I pointed out many times. Ok, so we share an opinion in this point :-) >> and the new experimental is already there. I suggest you specifically >> point out problems in the proposal and suggest specific changes to >> changes in the document like "I propose to change this paragraph >> to the following words: ...". Or do you want to say we should just >> keep the process as is? > > Anyone can suggest change - make it in the form of a proposal and > fully > justify it. It is for the proposer not me to say "I propose ...". I > can't work with wiki pages appearing and being treating as the > standard. The wiki page is a proposal and you propose a change to the proposal. So how about some discussion on the matter instead of the wording? Best regards -- Dago From james at opencsw.org Mon Feb 8 15:47:03 2010 From: james at opencsw.org (James Lee) Date: Mon, 08 Feb 2010 14:47:03 GMT Subject: [csw-maintainers] RFD: Releases and staging proposal In-Reply-To: References: <20100207.14012200.1398821831@gyor.oxdrove.co.uk> <4CA1F901-C232-4A4B-AB97-0F7F0CE7E9F2@opencsw.org> <20100208.12174700.451840536@gyor.oxdrove.co.uk> Message-ID: <20100208.14470300.3305849645@gyor.oxdrove.co.uk> On 08/02/10, 12:42:36, Dagobert Michelsen wrote regarding Re: [csw-maintainers] RFD: Releases and staging proposal: > >> I am not sure if I understand you correctly. Do you propose a > >> different > >> naming or a different process than what was described? > > > > I'm not making a proposal. > So we should stick to what we have and just drop the proposal? Don't ask me, I'm not making a proposal. Discuss options and merits, suggest changes in form of a proposal, adopt if approved. Individuals may vote with feet if not acceptable. > >> and the new experimental is already there. I suggest you specifically > >> point out problems in the proposal and suggest specific changes to > >> changes in the document like "I propose to change this paragraph > >> to the following words: ...". Or do you want to say we should just > >> keep the process as is? > > > > Anyone can suggest change - make it in the form of a proposal and > > fully > > justify it. It is for the proposer not me to say "I propose ...". I > > can't work with wiki pages appearing and being treating as the > > standard. > The wiki page is a proposal and you propose a change to the proposal. > So how about some discussion on the matter instead of the wording? You've already put release candidate packages under experimental, so is it just a proposal? Ref also: http://wiki.opencsw.org/automated-release-process no mention of proposition status. The wording defines the matter so is inseparable - it's a written proposal. I've already question the naming and that there isn't much materially different to what has happened, at least there is not sufficient detail such that I can tell what distinguishes the proposal, perhaps it could explain? i.e. make incremental on previous. 6 month cycles make releases harder because it's harder to hold stuff back the longer the gap is. This situation afflicts us now having to accommodate a period of great change and innovation. Only regularly updated packages occur in every cycle and these tend not to be the problematic ones anyway. James. From phil at bolthole.com Mon Feb 8 18:39:13 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 8 Feb 2010 09:39:13 -0800 Subject: [csw-maintainers] RFD: Releases and staging proposal In-Reply-To: References: <20100207.14012200.1398821831@gyor.oxdrove.co.uk> <4CA1F901-C232-4A4B-AB97-0F7F0CE7E9F2@opencsw.org> <20100208.12174700.451840536@gyor.oxdrove.co.uk> Message-ID: On Mon, Feb 8, 2010 at 4:42 AM, Dagobert Michelsen wrote: > Hi James, > > Am 08.02.2010 um 13:17 schrieb James Lee: >> >> On 07/02/10, 20:37:01, Dagobert Michelsen wrote >> >>> I am not sure if I understand you correctly. Do you propose a different >>> naming or a different process than what was described? >> >> I'm not making a proposal. > > So we should stick to what we have and just drop the proposal? > maybe, maybe not. What does the "new" proposal fix? That has not been identified. Seems to me, that should be the first thing in the proposal; identifying "the problem" that the proposal has been created to fix. As far as I'm aware, the #1 problem that we have in this sort of area, is "no one has volunteered to commit to spend the many hours involved, to be the official stable release manager". And, as James can attest.. while it is possible to distribute SOME of the work out, it is not possible to perfectly or randomly distribute all of the job responsabilities. To re-use a phrase, "putting 9 women on the job, wont make a baby in 1 month instead of 9". > The wiki page is a proposal and you propose a change to the proposal. > So how about some discussion on the matter instead of the wording? Why are you objecting to changing the wording? whats the problem? He's suggested a change to the proposal. Are you only open to some kinds of change to it? How about we first fix "the easy part" of updating the wording, and then move on to the more detailed, labourious parts after that? From phil at bolthole.com Mon Feb 8 19:13:22 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 8 Feb 2010 10:13:22 -0800 Subject: [csw-maintainers] pkgrequests better on Mantis In-Reply-To: References: Message-ID: On Sun, Feb 7, 2010 at 12:30 PM, Dagobert Michelsen wrote: > Hi, > > we just got another package request. I propose to collect > package requests in Mantis. This way it is cleanly tracked. > After the package has been released the "bug" can be moved > over the new category and the original submitter gets > notified automatically when the package is released. > > Comments? > My comment is that this will leave us with a WHOOOLE lot of "bugs" in mantis that will never get closed. Plus, someone still has to either update the reuqested packages page, or make it autogenerate from the mantis bug filings. which means that they will have to manually clean up any "improperly" filed bugs. if you, or someone else, wants to take on this responsability.. fine with me! I just know that I dont want to do it. From dam at opencsw.org Mon Feb 8 21:52:01 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 8 Feb 2010 21:52:01 +0100 Subject: [csw-maintainers] RFD: Releases and staging proposal In-Reply-To: References: <20100207.14012200.1398821831@gyor.oxdrove.co.uk> <4CA1F901-C232-4A4B-AB97-0F7F0CE7E9F2@opencsw.org> <20100208.12174700.451840536@gyor.oxdrove.co.uk> Message-ID: Hi Phil, Am 08.02.2010 um 18:39 schrieb Philip Brown: > On Mon, Feb 8, 2010 at 4:42 AM, Dagobert Michelsen wrote: >> Hi James, >> >> Am 08.02.2010 um 13:17 schrieb James Lee: >>> >>> On 07/02/10, 20:37:01, Dagobert Michelsen wrote >>> >>>> I am not sure if I understand you correctly. Do you propose a different >>>> naming or a different process than what was described? >>> >>> I'm not making a proposal. >> >> So we should stick to what we have and just drop the proposal? > > maybe, maybe not. > What does the "new" proposal fix? > That has not been identified. > > Seems to me, that should be the first thing in the proposal; > identifying "the problem" that the proposal has been created to fix. It says so clearly in "background": "The main problem is that there are currently no processes that might potentially lead to a stable release" > And, as James can attest.. while it is possible to distribute SOME of > the work out, it is not possible to perfectly or randomly distribute > all of the job responsabilities. > To re-use a phrase, "putting 9 women on the job, wont make a baby in 1 > month instead of 9". To stick to your metaphor: It may not be faster, but it is much more fun :-) And with more fun there will be more people helping getting the job done. >> The wiki page is a proposal and you propose a change to the proposal. >> So how about some discussion on the matter instead of the wording? > > Why are you objecting to changing the wording? whats the problem? > He's suggested a change to the proposal. Are you only open to some > kinds of change to it? First it says clearly on top of the page "Status: Draft". If you want I can add "Status: draft" under each headline to make that even clearer. Changing the wording to something vague and changing it back later is IMHO not helpful and btw. not how other RFCs are done (which you may or may not find relevant for our document, as the OpenCSW-process should be "better than RFC", right?) > How about we first fix "the easy part" of updating the wording, and > then move on to the more detailed, labourious parts after that? There are two ways the document can be changed: 1. Describe the change in terms of "I propose to change the sentence 'abc' to 'def' in paragraph 1 of section 2" and discuss it on maintainers@ 2. Change it yourself and discuss it on maintainers@ Best regards -- Dago From dam at opencsw.org Mon Feb 8 22:05:43 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 8 Feb 2010 22:05:43 +0100 Subject: [csw-maintainers] RFD: Releases and staging proposal In-Reply-To: <20100208.14470300.3305849645@gyor.oxdrove.co.uk> References: <20100207.14012200.1398821831@gyor.oxdrove.co.uk> <4CA1F901-C232-4A4B-AB97-0F7F0CE7E9F2@opencsw.org> <20100208.12174700.451840536@gyor.oxdrove.co.uk> <20100208.14470300.3305849645@gyor.oxdrove.co.uk> Message-ID: Hi James, Am 08.02.2010 um 15:47 schrieb James Lee: > On 08/02/10, 12:42:36, Dagobert Michelsen wrote regarding > Re: [csw-maintainers] RFD: Releases and staging proposal: > >>>> I am not sure if I understand you correctly. Do you propose a >>>> different >>>> naming or a different process than what was described? >>> >>> I'm not making a proposal. > >> So we should stick to what we have and just drop the proposal? > > Don't ask me, I'm not making a proposal. Discuss options and merits, > suggest changes in form of a proposal, adopt if approved. Individuals > may vote with feet if not acceptable. We made a proposal and we can now happily discuss options and merits. >>>> and the new experimental is already there. I suggest you specifically >>>> point out problems in the proposal and suggest specific changes to >>>> changes in the document like "I propose to change this paragraph >>>> to the following words: ...". Or do you want to say we should just >>>> keep the process as is? >>> >>> Anyone can suggest change - make it in the form of a proposal and >>> fully >>> justify it. It is for the proposer not me to say "I propose ...". I >>> can't work with wiki pages appearing and being treating as the >>> standard. > >> The wiki page is a proposal and you propose a change to the proposal. >> So how about some discussion on the matter instead of the wording? > > You've already put release candidate packages under experimental, so is > it just a proposal? Ref also: > http://wiki.opencsw.org/automated-release-process > no mention of proposition status. Do you like it? If you have ideas to make this easier or more useful just say so. Additionally, I haven't changed anything on testing/, so, yes, it is still a proposal. If I get no feedback it may become the new standard. > The wording defines the matter so is inseparable - it's a written > proposal. I've already question the naming and that there isn't much > materially different to what has happened, at least there is not > sufficient detail such that I can tell what distinguishes the proposal, > perhaps it could explain? i.e. make incremental on previous. I'm sorry, I don't understand what you are asking. Really. What do you mean by "what distinguishes the proposal"? > 6 month cycles make releases harder because it's harder to hold stuff > back the longer the gap is. This situation afflicts us now having to > accommodate a period of great change and innovation. Only regularly > updated packages occur in every cycle and these tend not to be the > problematic ones anyway. Ok, so you are suggesting shortening release cycles to 4 or 3 month. During the discussion the problem was seen that there may be too many issues on testing/ to be fixed in that short amount in time and that a longer duration allows easier fixing. We can start with a shorter time and see if it works and extend it if necessary. I adjusted the wording on the proposal accordingly. Best regards -- Dago From william at wbonnet.net Mon Feb 8 22:09:16 2010 From: william at wbonnet.net (William Bonnet) Date: Mon, 08 Feb 2010 22:09:16 +0100 Subject: [csw-maintainers] pkgrequests better on Mantis In-Reply-To: References: Message-ID: <4B707D7C.3000409@wbonnet.net> Hi > My comment is that this will leave us with a WHOOOLE lot of "bugs" in > mantis that will never get closed. > They have to. Either we accept these request, or we have to answer to the user that we won't do it, giving a reason for that (out of scope, portability problem, not free, don't like it ;), or what ever), or scheduling this package for later. Identifying priority would be nice. > if you, or someone else, wants to take on this responsability.. fine with me! > I just know that I dont want to do it. > Ok i take it Once the web site out, i'll focus on packages management tools (database, pkgrequest tracking and this kind of things). 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 Mon Feb 8 22:11:17 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 8 Feb 2010 22:11:17 +0100 Subject: [csw-maintainers] pkgrequests better on Mantis In-Reply-To: References: Message-ID: <27FD7EE5-714B-4992-9CF2-443FB96A4BBE@opencsw.org> Hi Phil, Am 08.02.2010 um 19:13 schrieb Philip Brown: > On Sun, Feb 7, 2010 at 12:30 PM, Dagobert Michelsen wrote: >> we just got another package request. I propose to collect >> package requests in Mantis. This way it is cleanly tracked. >> After the package has been released the "bug" can be moved >> over the new category and the original submitter gets >> notified automatically when the package is released. >> >> Comments? > > My comment is that this will leave us with a WHOOOLE lot of "bugs" in > mantis that will never get closed. They will be closed when the package is added. I see nothing wrong with that. > Plus, someone still has to either update the reuqested packages page, > or make it autogenerate from the mantis bug filings. which means that > they will have to manually clean up any "improperly" filed bugs. Just point to the pkgrequests section in the bugtracker. The bugmanager can sort out dupes. > if you, or someone else, wants to take on this responsability.. fine with me! > I just know that I dont want to do it. Yes, I do it. Please add a new category and adjust the webpage. I'll then add all old pkgrequests as bugs. BTW, are these archived? I would like to add the original email adresses of the submitters. Best regards -- Dago From dam at opencsw.org Mon Feb 8 22:21:02 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 8 Feb 2010 22:21:02 +0100 Subject: [csw-maintainers] pkgrequests better on Mantis In-Reply-To: <4B707D7C.3000409@wbonnet.net> References: <4B707D7C.3000409@wbonnet.net> Message-ID: Hi William, Am 08.02.2010 um 22:09 schrieb William Bonnet: > Hi >> My comment is that this will leave us with a WHOOOLE lot of "bugs" in >> mantis that will never get closed. >> > They have to. Either we accept these request, or we have to answer to the user that we won't do it, giving a reason for that (out of scope, portability problem, not free, don't like it ;), or what ever), or scheduling this package for later. Identifying priority would be nice. >> if you, or someone else, wants to take on this responsability.. fine with me! >> I just know that I dont want to do it. >> > Ok i take it You're fast :-) Ok, we'll co-manage it, ok? Best regards -- Dago From phil at bolthole.com Mon Feb 8 22:30:44 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 8 Feb 2010 13:30:44 -0800 Subject: [csw-maintainers] pkgrequests better on Mantis In-Reply-To: <4B707D7C.3000409@wbonnet.net> References: <4B707D7C.3000409@wbonnet.net> Message-ID: On Mon, Feb 8, 2010 at 1:09 PM, William Bonnet wrote: > Hi >> >> My comment is that this will leave us with a WHOOOLE lot of "bugs" in >> mantis that will never get closed. >> > > They have to. Either we accept these request, or we have to answer to the > user that we won't do it, giving a reason for that (out of scope, > portability problem, not free, don't like it ;), but I dont see how any one person can say "we wont", since you woudl have to poll the entire maintainer base every time. and even if you did that, you dont konw that someone wont join next week that is willing to do it. > or > scheduling this package for later. Identifying priority would be nice. but who picks priority? and based on what criteria? From phil at bolthole.com Mon Feb 8 22:31:29 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 8 Feb 2010 13:31:29 -0800 Subject: [csw-maintainers] pkgrequests better on Mantis In-Reply-To: <27FD7EE5-714B-4992-9CF2-443FB96A4BBE@opencsw.org> References: <27FD7EE5-714B-4992-9CF2-443FB96A4BBE@opencsw.org> Message-ID: On Mon, Feb 8, 2010 at 1:11 PM, Dagobert Michelsen wrote: > > Yes, I do it. Please add a new category and adjust the webpage. I'll then > add all old pkgrequests as bugs. BTW, are these archived? I would like to > add the original email adresses of the submitters. and maybe they dont WANT their email addresses on a public place? From phil at bolthole.com Mon Feb 8 22:37:40 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 8 Feb 2010 13:37:40 -0800 Subject: [csw-maintainers] cswclassutils: location of template init scripts In-Reply-To: <20100207.14045300.4254301123@gyor.oxdrove.co.uk> References: <20100207.14045300.4254301123@gyor.oxdrove.co.uk> Message-ID: On Sun, Feb 7, 2010 at 6:04 AM, James Lee wrote: > > I agree with this. ?I say the package should deliver to /opt/csw and > user and local data files should go in /etc/opt and /var/opt. ?Template > configuration files break this logic, the package might also lay out > directories in /etc/opt and /var/opt. > > BTW: for those people who might point out, "but we already do delivery of other templates to /etc with cswXXXXconf"... I dont actually like that. The initial implementation was a quick hack, but I think we can do better. I think we should offer an additional cswclassutils class, to copy a foo.conf.CSW from /opt/csw/[???] to /etc/opt/csw/ Unfortunately, I havent found the time to write such a beast myself yet. Keep meaning to, but, ya know... :} But if anyone else would like to, please jump in. (It might even be a modification of one of the existing cswpreservconf type utils, where it allows for a comment in the file to specify preferred directory target. Just a thought, I dunno) From skayser at opencsw.org Mon Feb 8 22:37:43 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 08 Feb 2010 22:37:43 +0100 Subject: [csw-maintainers] pkgrequests better on Mantis In-Reply-To: References: <4B707D7C.3000409@wbonnet.net> Message-ID: <4B708427.1020702@opencsw.org> Philip Brown wrote on 08.02.2010 22:30: > On Mon, Feb 8, 2010 at 1:09 PM, William Bonnet wrote: >> Hi >>> My comment is that this will leave us with a WHOOOLE lot of "bugs" in >>> mantis that will never get closed. >>> >> They have to. Either we accept these request, or we have to answer to the >> user that we won't do it, giving a reason for that (out of scope, >> portability problem, not free, don't like it ;), > > > but I dont see how any one person can say "we wont", since you woudl > have to poll the entire maintainer base every time. and even if you > did that, you dont konw that someone wont join next week that is > willing to do it. If it's something big like samba or anything that depends on a whole gnome re-build anyone can easily tell the user that although his request is appreciated, the package will not be there tomorrow. At least he/she has got some feedback then. >> or >> scheduling this package for later. Identifying priority would be nice. > > but who picks priority? > and based on what criteria? Who does right now? Those who want to work on it can prioritize, just as they do right now when they pick the ones from the web page which they want to work on. If it's collaborative effort the priority can help to coordinate the effort. Even if we would find out, priorities don't help that much, nothing is lost and we might have learned something. Thanks Dago and William for working on it! Sebastian From skayser at opencsw.org Mon Feb 8 22:38:56 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 08 Feb 2010 22:38:56 +0100 Subject: [csw-maintainers] pkgrequests better on Mantis In-Reply-To: References: <27FD7EE5-714B-4992-9CF2-443FB96A4BBE@opencsw.org> Message-ID: <4B708470.9090109@opencsw.org> Philip Brown wrote on 08.02.2010 22:31: > On Mon, Feb 8, 2010 at 1:11 PM, Dagobert Michelsen wrote: >> Yes, I do it. Please add a new category and adjust the webpage. I'll then >> add all old pkgrequests as bugs. BTW, are these archived? I would like to >> add the original email adresses of the submitters. > > and may be they dont WANT their email addresses on a public place? Their email addresses won't be public, but they will get notified on actions regarding their requests. Something very worthwhile IMHO. Sebastian From phil at bolthole.com Mon Feb 8 22:43:03 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 8 Feb 2010 13:43:03 -0800 Subject: [csw-maintainers] RFD: Releases and staging proposal In-Reply-To: References: <20100207.14012200.1398821831@gyor.oxdrove.co.uk> <4CA1F901-C232-4A4B-AB97-0F7F0CE7E9F2@opencsw.org> <20100208.12174700.451840536@gyor.oxdrove.co.uk> Message-ID: On Mon, Feb 8, 2010 at 12:52 PM, Dagobert Michelsen wrote: > Changing the wording to something vague and changing it back later is > IMHO not helpful and btw. not how other RFCs are done (which you may or > may not find relevant for our document, as the OpenCSW-process should > be "better than RFC", right?) exactly. not to mention, it is a different process. Internet RFCs, are basically someone's writeup of, "Hi. This is what I myself am going to do. In fact, I'm doing it right now. But I think it would be nice if other people copied what I am doing, so it can become a standard. Please submit your comments about what I am doing." (hence, "Request For Comments" on what someone is doing already). Whereas what we are doing here, is writing up, "This is a proposal, that we change what we, as an organization, are doing, to do it another way. Lets discuss whether this is even the right way to do things?". There is a large conceptual difference between the two. From william at wbonnet.net Mon Feb 8 22:48:33 2010 From: william at wbonnet.net (William Bonnet) Date: Mon, 08 Feb 2010 22:48:33 +0100 Subject: [csw-maintainers] pkgrequests better on Mantis In-Reply-To: References: <4B707D7C.3000409@wbonnet.net> Message-ID: <4B7086B1.6000606@wbonnet.net> Hi > You're fast :-) Ok, we'll co-manage it, ok? > Sure, help is really welcomed :) 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 jgoerzen at opencsw.org Mon Feb 8 22:52:25 2010 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Mon, 8 Feb 2010 13:52:25 -0800 Subject: [csw-maintainers] confused with build-global and build-isa... Message-ID: <315c02ae1002081352w2ff2b777w96d4be3094eebdd3@mail.gmail.com> Hello, I want to copy a file from $FILEDIR/ to "where GAR extracted the source" for example: post-extract: @cp $(FILEDIR)/Makefile $(WORKDIR)/Makefile $(MAKECOOKIE) When I do this the file gets copied to work/solaris8-sparc/build-global. however, the source was extracted to work/solaris8-sparc/build-isa-sparcv8/gkrellm-2.3.4/ Isn't there a GAR variable that expands to the correct path? I thought $WORKDIR was it? Thanks, Jake From william at wbonnet.net Mon Feb 8 22:52:49 2010 From: william at wbonnet.net (William Bonnet) Date: Mon, 08 Feb 2010 22:52:49 +0100 Subject: [csw-maintainers] pkgrequests better on Mantis In-Reply-To: <4B707D7C.3000409@wbonnet.net> References: <4B707D7C.3000409@wbonnet.net> Message-ID: <4B7087B1.8010107@wbonnet.net> Hi > but I dont see how any one person can say "we wont" For example if we are not allowed to redistribute this package, or this package is Linux specific > but who picks priority? > and based on what criteria? That will be part of the maintainer discussion on this list i think. we could set up kind of review for requested packages, and setup priority. We can decide this based on importance, possibile dependencies, number of person requesting the package, etc. cheers W. From phil at bolthole.com Mon Feb 8 22:53:38 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 8 Feb 2010 13:53:38 -0800 Subject: [csw-maintainers] RFD: Releases and staging proposal In-Reply-To: References: <20100207.14012200.1398821831@gyor.oxdrove.co.uk> <4CA1F901-C232-4A4B-AB97-0F7F0CE7E9F2@opencsw.org> <20100208.12174700.451840536@gyor.oxdrove.co.uk> Message-ID: On Mon, Feb 8, 2010 at 12:52 PM, Dagobert Michelsen wrote: > >> Seems to me, that should be the first thing in the proposal; >> identifying "the problem" that the proposal has been created to fix. > > It says so clearly in "background": > ?"The main problem is that there are currently no processes that > ? might potentially lead to a stable release" > well, I would disagree about "clearly" :) Perhaps I will tweak the wording myself later to make that clearer. However, what both James and I have pointed out, is that we dont lack a process.. we lack a person to take responsability to make the Process actually make Progress. This came up before... and a person tentatively said they would look into doing so... but then they did not follow through. So lets bring up a critical point right now: If the primary purpose of this new proposal, is "getting a new stable release done", then let us ask the question, "Who is going to volunteer to be the stable release manager?", with the understanding that it will result in a commitment of time to do so? or are you proposing that there be a "stable release committee"? If so, then who is going to take responsability when things are behind? committees are semi-good for discussing options, but lousy, when it comes to taking responsibility. That's why, in any organization, every employee has one manager, and every project has one (primary) project manager. Who is going to be the primary "project manager" for stable release? No "well, I'll think about it", but a firm commitment to do it? I'd really love for someone to step up and take this on. But so far... no takers. Anyone? Anyone? From skayser at opencsw.org Mon Feb 8 23:43:07 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 08 Feb 2010 23:43:07 +0100 Subject: [csw-maintainers] confused with build-global and build-isa... In-Reply-To: <315c02ae1002081352w2ff2b777w96d4be3094eebdd3@mail.gmail.com> References: <315c02ae1002081352w2ff2b777w96d4be3094eebdd3@mail.gmail.com> Message-ID: <4B70937B.7010400@opencsw.org> Hi Jake, Jake Goerzen wrote on 08.02.2010 22:52: > Hello, I want to copy a file from $FILEDIR/ to "where GAR extracted > the source" for example: > > post-extract: > @cp $(FILEDIR)/Makefile $(WORKDIR)/Makefile > $(MAKECOOKIE) > > > When I do this the file gets copied to > work/solaris8-sparc/build-global. however, the source was extracted > to work/solaris8-sparc/build-isa-sparcv8/gkrellm-2.3.4/ > > Isn't there a GAR variable that expands to the correct path? I > thought $WORKDIR was it? should be WORKSRC instead of WORKDIR (see [1]) and I usually use post-extract-modulated, I am not quite sure whether the latter makes a difference though. In case the problem persists, please submit the build recipe so that others can have a look at it. HTH Sebastian [1] http://sourceforge.net/apps/trac/gar/wiki/GAR%20Variable%20Reference From bwalton at opencsw.org Tue Feb 9 04:01:38 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 08 Feb 2010 22:01:38 -0500 Subject: [csw-maintainers] RFD: Releases and staging proposal In-Reply-To: References: <20100207.14012200.1398821831@gyor.oxdrove.co.uk> <4CA1F901-C232-4A4B-AB97-0F7F0CE7E9F2@opencsw.org> <20100208.12174700.451840536@gyor.oxdrove.co.uk> Message-ID: <1265684048-sup-8867@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Feb 08 16:53:38 -0500 2010: > This came up before... and a person tentatively said they would look > into doing so... but then they did not follow through. For the record, I did follow through. James and I discussed this for a bit and left it that James was going to continue watching for the right time to cut a new stable. At that point, I was going to play the public point position (the whip) and keep things moving, thus taking some of the burden from his shoulders. Testing was going to be shared. That point in time has not come yet. That being said, I see that we have several people looking to put some effort into this, so that we can actually produce a release milestone. The process as documented may not be radically different than before, but that's not the key takeaway here. The important point: Several people are sitting down, thinking about how to move forward. They're documenting their thoughts and noting that they'll put time and effort in. The thoughts are public and are a good starting point for discussion. So far, the discussion hasn't been very constructive. IMO, this document is a good sign that we're already further ahead than we were. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Tue Feb 9 11:45:06 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 9 Feb 2010 11:45:06 +0100 Subject: [csw-maintainers] GAR change: Reordering of linker pathes Message-ID: Hi, with change r8433 in GAR the ordering of the library pathes have been changed to move the more specific pathes in front of the generic pathes: http://sourceforge.net/apps/trac/gar/changeset/8433 Especially EXTRA_LIB is now before /opt/csw/lib and thus avoids linking to legacy links in /opt/csw/lib although the correct path has been added in EXTRA_LIB. Best regards -- Dago From dam at opencsw.org Tue Feb 9 14:38:48 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 9 Feb 2010 14:38:48 +0100 Subject: [csw-maintainers] confused with build-global and build-isa... In-Reply-To: <4B70937B.7010400@opencsw.org> References: <315c02ae1002081352w2ff2b777w96d4be3094eebdd3@mail.gmail.com> <4B70937B.7010400@opencsw.org> Message-ID: <956B79A6-9C8C-4BD6-B40A-3210461B0ED2@opencsw.org> Hi Jake, Am 08.02.2010 um 23:43 schrieb Sebastian Kayser: > Jake Goerzen wrote on 08.02.2010 22:52: >> Hello, I want to copy a file from $FILEDIR/ to "where GAR extracted >> the source" for example: >> >> post-extract: >> @cp $(FILEDIR)/Makefile $(WORKDIR)/Makefile >> $(MAKECOOKIE) >> >> >> When I do this the file gets copied to >> work/solaris8-sparc/build-global. however, the source was extracted >> to work/solaris8-sparc/build-isa-sparcv8/gkrellm-2.3.4/ >> >> Isn't there a GAR variable that expands to the correct path? I >> thought $WORKDIR was it? > > should be WORKSRC instead of WORKDIR (see [1]) and I usually use > post-extract-modulated, I am not quite sure whether the latter makes a > difference though. In case the problem persists, please submit the > build > recipe so that others can have a look at it. The rationale is that post- is called after all modulations have been executed. The rule for that is then called post-- modulated. I have been thinking lately that the idea of allowing phase-wide rules are bad, mainly because of the independency of modultions to run separately and thus breaking sync points. I also talked about that during my presentation on SummerCamp 2009 in Oslo linked from here: http://sourceforge.net/apps/trac/gar/wiki/Learning%20the%20details Additionally, everything from FILEDIR is either copied or unpacked to $(WORKDIR), so what you supposedly want is cp $(WORKDIR)/Makefile $(WORKSRC)/Makefile If you have any further questions about GAR or why something has been done the way it is please don't hesitate to ask. Best regards -- Dago From phil at bolthole.com Tue Feb 9 18:21:35 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 9 Feb 2010 09:21:35 -0800 Subject: [csw-maintainers] RFD: Releases and staging proposal In-Reply-To: <1265684048-sup-8867@ntdws12.chass.utoronto.ca> References: <20100207.14012200.1398821831@gyor.oxdrove.co.uk> <4CA1F901-C232-4A4B-AB97-0F7F0CE7E9F2@opencsw.org> <20100208.12174700.451840536@gyor.oxdrove.co.uk> <1265684048-sup-8867@ntdws12.chass.utoronto.ca> Message-ID: On Mon, Feb 8, 2010 at 7:01 PM, Ben Walton wrote: ?The thoughts are public and are > a good starting point for discussion. ?So far, the discussion hasn't > been very constructive. > I would very much like to work together with other folks to getting a new stable out. Starting with having a useful discussion of the way forward. One of the things getting in the way of productive discussion, in my opinion, is the way this "proposal" is being handled. There's not enough structure in the discussion itself. We dont even have one person who is volunteering to officially update "the proposal" itself, and be "the proposal lead". I will ask now, once again, for someone to take *responsability* here. Just of the proposal, not even of the entire "stable release manager" position. The responsabilities of what I'm describing, include: 1. updating the wiki description when and as appropriate 2. attempting to get some kind of agreement or consensus from "members" 3. submitting the results of a "vote" of some kind to approve the "new" proceedure, once discussion has finished, to the board. If no-one steps up, then I guess I will do it. I'm busy, so I'd prefer not to, but in lieu of anyone else taking responsability for it, I will do so. I'll wait a day or two. My initial comment on the current "proposal", is that it includes too much, that is distracting and unneccesasry. As it stands right now, it's too large to have productive discussion on it. It needs to be split out into separate documents, of "this is the overall framework of our trees (experimental, current, etc)", vs "this is the proposal to move forward and produce a new stable release." From james at opencsw.org Tue Feb 9 18:37:48 2010 From: james at opencsw.org (James Lee) Date: Tue, 09 Feb 2010 17:37:48 GMT Subject: [csw-maintainers] cswclassutils: location of template init scripts In-Reply-To: References: <20100207.14045300.4254301123@gyor.oxdrove.co.uk> Message-ID: <20100209.17374800.3834452758@gyor.oxdrove.co.uk> On 08/02/10, 21:37:40, Philip Brown wrote regarding Re: [csw-maintainers] cswclassutils: location of template init scripts: > On Sun, Feb 7, 2010 at 6:04 AM, James Lee wrote: > > > > I agree with this. ?I say the package should deliver to /opt/csw and > > user and local data files should go in /etc/opt and /var/opt. ?Template > > configuration files break this logic, the package might also lay out > > directories in /etc/opt and /var/opt. > BTW: for those people who might point out, "but we already do delivery > of other templates to /etc with cswXXXXconf"... I dont actually like > that. The initial implementation was a quick hack, but I think we can > do better. > I think we should offer an additional cswclassutils class, to copy > a foo.conf.CSW from /opt/csw/[???] to /etc/opt/csw/ I agree. Where I said "configuration files break this logic" it is an observation on the existing and not a recommendation. James. From james at opencsw.org Tue Feb 9 20:07:12 2010 From: james at opencsw.org (James Lee) Date: Tue, 09 Feb 2010 19:07:12 GMT Subject: [csw-maintainers] RFD: Releases and staging proposal In-Reply-To: References: <20100207.14012200.1398821831@gyor.oxdrove.co.uk> <4CA1F901-C232-4A4B-AB97-0F7F0CE7E9F2@opencsw.org> <20100208.12174700.451840536@gyor.oxdrove.co.uk> Message-ID: <20100209.19071200.4075474606@gyor.oxdrove.co.uk> On 08/02/10, 17:39:13, Philip Brown wrote regarding Re: [csw-maintainers] RFD: Releases and staging proposal: > As far as I'm aware, the #1 problem that we have in this sort of area, is > "no one has volunteered to commit to spend the many hours involved, to > be the official stable release manager" The number one problem has been the number of packages and innovation. Taking a snapshot only makes sense if done at an opportune time and there hasn't been one. Remember it has to be the timed right for people too, not only those enacting release but those changing the game as we go. Stability needs less innovation. That means we need some people to hold off change while we plough though the mess. Here's one example, we have stuff linked to both /usr/openwin and /opt/csw/X11. I fear if we rebuild one package it just moves the front to another which will possibly meet something large like KDE. There are needs for experimental forks, /opt/csw/X11 could be one. It might end up this easily solved in a few moves but it will take time to verify the fact and it really shouldn't need asking in the first place. James. From james at opencsw.org Tue Feb 9 20:08:34 2010 From: james at opencsw.org (James Lee) Date: Tue, 09 Feb 2010 19:08:34 GMT Subject: [csw-maintainers] RFD: Releases and staging proposal In-Reply-To: References: <20100207.14012200.1398821831@gyor.oxdrove.co.uk> <4CA1F901-C232-4A4B-AB97-0F7F0CE7E9F2@opencsw.org> <20100208.12174700.451840536@gyor.oxdrove.co.uk> Message-ID: <20100209.19083400.2214484130@gyor.oxdrove.co.uk> On 08/02/10, 20:52:01, Dagobert Michelsen wrote regarding Re: [csw-maintainers] RFD: Releases and staging proposal: > >> So we should stick to what we have and just drop the proposal? > > > > maybe, maybe not. > > What does the "new" proposal fix? > > That has not been identified. > > > > Seems to me, that should be the first thing in the proposal; > > identifying "the problem" that the proposal has been created to fix. > It says so clearly in "background": > "The main problem is that there are currently no processes that > might potentially lead to a stable release" There is a process. The proposal doesn't say how it is more likely to lead to a release. > >> The wiki page is a proposal and you propose a change to the proposal. > >> So how about some discussion on the matter instead of the wording? > > > > Why are you objecting to changing the wording? whats the problem? > > He's suggested a change to the proposal. Are you only open to some > > kinds of change to it? > First it says clearly on top of the page "Status: Draft". The missing word is proposal. > There are two ways the document can be changed: > 1. Describe the change in terms of "I propose to change the sentence > 'abc' to 'def' in paragraph 1 of section 2" and discuss it on > maintainers@ This the form a proposal should take. > 2. Change it yourself and discuss it on maintainers@ Ouch. James. From james at opencsw.org Tue Feb 9 20:10:23 2010 From: james at opencsw.org (James Lee) Date: Tue, 09 Feb 2010 19:10:23 GMT Subject: [csw-maintainers] RFD: Releases and staging proposal In-Reply-To: References: <20100207.14012200.1398821831@gyor.oxdrove.co.uk> <4CA1F901-C232-4A4B-AB97-0F7F0CE7E9F2@opencsw.org> <20100208.12174700.451840536@gyor.oxdrove.co.uk> <20100208.14470300.3305849645@gyor.oxdrove.co.uk> Message-ID: <20100209.19102300.126154462@gyor.oxdrove.co.uk> On 08/02/10, 21:05:43, Dagobert Michelsen wrote regarding Re: [csw-maintainers] RFD: Releases and staging proposal: > > You've already put release candidate packages under experimental, so is > > it just a proposal? Ref also: > > http://wiki.opencsw.org/automated-release-process > > no mention of proposition status. > Do you like it? If you have ideas to make this easier or more > useful just say so. Additionally, I haven't changed anything on > testing/, so, yes, it is still a proposal. If I get no feedback > it may become the new standard. That's exactly what I don't like. Propose it, consider in the official way, if approved then adopt. > > The wording defines the matter so is inseparable - it's a written > > proposal. I've already question the naming and that there isn't much > > materially different to what has happened, at least there is not > > sufficient detail such that I can tell what distinguishes the proposal, > > perhaps it could explain? i.e. make incremental on previous. > I'm sorry, I don't understand what you are asking. Really. What do > you mean by "what distinguishes the proposal"? Highlight and detail what is different. > > 6 month cycles make releases harder because it's harder to hold stuff > > back the longer the gap is. This situation afflicts us now having to > > accommodate a period of great change and innovation. Only regularly > > updated packages occur in every cycle and these tend not to be the > > problematic ones anyway. > Ok, so you are suggesting shortening release cycles to 4 or 3 month. No. I'm not making a proposal. It is the proposer that suggests lengthening the previous cycle. I'm pointing out that doubling the length does not make the task twice as easy and the long span we currently have is a major factor in not moving forward. I can tell you the first stable release in 2005 which spanned maybe 2 years was by far the hardest. James. From jgoerzen at opencsw.org Tue Feb 9 20:46:57 2010 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Tue, 9 Feb 2010 11:46:57 -0800 Subject: [csw-maintainers] confused with build-global and build-isa... In-Reply-To: <956B79A6-9C8C-4BD6-B40A-3210461B0ED2@opencsw.org> References: <315c02ae1002081352w2ff2b777w96d4be3094eebdd3@mail.gmail.com> <4B70937B.7010400@opencsw.org> <956B79A6-9C8C-4BD6-B40A-3210461B0ED2@opencsw.org> Message-ID: <315c02ae1002091146y7a6f02ffo841aa40e57a5651@mail.gmail.com> On Tue, Feb 9, 2010 at 5:38 AM, Dagobert Michelsen wrote: > Hi Jake, > > Am 08.02.2010 um 23:43 schrieb Sebastian Kayser: >> >> Jake Goerzen wrote on 08.02.2010 22:52: >>> >>> Hello, I want to copy a file from $FILEDIR/ to "where GAR extracted >>> the source" for example: >>> >>> post-extract: >>> ? ? ? @cp $(FILEDIR)/Makefile $(WORKDIR)/Makefile >>> ? ? ? $(MAKECOOKIE) >>> >>> >>> When I do this the file gets copied to >>> work/solaris8-sparc/build-global. ?however, the source was extracted >>> to work/solaris8-sparc/build-isa-sparcv8/gkrellm-2.3.4/ >>> >>> Isn't there a GAR variable that expands to the correct path? ?I >>> thought $WORKDIR was it? >> >> should be WORKSRC instead of WORKDIR (see [1]) and I usually use >> post-extract-modulated, I am not quite sure whether the latter makes a >> difference though. In case the problem persists, please submit the build >> recipe so that others can have a look at it. > > The rationale is that post- is called after all modulations > have been executed. The rule for that is then called post--modulated. > I have been thinking lately that the idea of allowing phase-wide rules > are bad, mainly because of the independency of modultions to run separately > and thus breaking sync points. I also talked about that during my > presentation > on SummerCamp 2009 in Oslo linked from here: > ?http://sourceforge.net/apps/trac/gar/wiki/Learning%20the%20details > > Additionally, everything from FILEDIR is either copied or unpacked to > $(WORKDIR), so what you supposedly want is > ?cp $(WORKDIR)/Makefile $(WORKSRC)/Makefile For me $(WORKDIR) expands to (work/solaris8-sparc/build-global) and $(WORKSRC) expands to (work/solaris8-sparc/build-global/gkrellm-2.3.4). However GAR didn't extract my source here. GAR extracted my source in: work/solaris8-sparc/build-isa-sparcv8/gkrellm-2.3.4 Notice build-isa-sparcv8 instead of build-global. At the moment I hacked this together and it works: pre-configure-modulated: @cp $(FILEDIR)/Makefile $(WORKROOTDIR)/build-$(MODULATIONS)/$(GARNAME)-$ (GARVERSION)/Makefile @cp $(FILEDIR)/src.Makefile $(WORKROOTDIR)/build-$(MODULATIONS)/$(GARNAM E)-$(GARVERSION)/src/Makefile @cp $(FILEDIR)/server.Makefile $(WORKROOTDIR)/build-$(MODULATIONS)/$(GAR NAME)-$(GARVERSION)/server/Makefile The full recipe is commited to GAR: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/gkrellm/trunk/Makefile Thanks, Jake From dam at opencsw.org Wed Feb 10 15:52:36 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 10 Feb 2010 15:52:36 +0100 Subject: [csw-maintainers] confused with build-global and build-isa... In-Reply-To: <315c02ae1002091146y7a6f02ffo841aa40e57a5651@mail.gmail.com> References: <315c02ae1002081352w2ff2b777w96d4be3094eebdd3@mail.gmail.com> <4B70937B.7010400@opencsw.org> <956B79A6-9C8C-4BD6-B40A-3210461B0ED2@opencsw.org> <315c02ae1002091146y7a6f02ffo841aa40e57a5651@mail.gmail.com> Message-ID: <9046A4AF-9FBA-4FE4-A431-DB7B7A76F3F2@opencsw.org> Hi Jake, Am 09.02.2010 um 20:46 schrieb Jake Goerzen: > For me $(WORKDIR) expands to (work/solaris8-sparc/build-global) and > $(WORKSRC) expands to > (work/solaris8-sparc/build-global/gkrellm-2.3.4). However GAR didn't > extract my source here. GAR extracted my source in: > > work/solaris8-sparc/build-isa-sparcv8/gkrellm-2.3.4 > > Notice build-isa-sparcv8 instead of build-global. At the moment I > hacked this together and it works: > > pre-configure-modulated: > @cp $(FILEDIR)/Makefile $(WORKROOTDIR)/build-$(MODULATIONS)/$ > (GARNAME)-$ > (GARVERSION)/Makefile > @cp $(FILEDIR)/src.Makefile $(WORKROOTDIR)/build-$ > (MODULATIONS)/$(GARNAM > E)-$(GARVERSION)/src/Makefile > @cp $(FILEDIR)/server.Makefile $(WORKROOTDIR)/build-$ > (MODULATIONS)/$(GAR > NAME)-$(GARVERSION)/server/Makefile > > The full recipe is commited to GAR: > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/gkrellm/trunk/Makefile Ok, there are number of issues here: 1. Please add all files in files/ to either DISTFILES or PATCHFILES Doing so adds them for checksumming and will allow a clean collection of files for source packages later on. All files here will be delivered to $ (WORKDIR), pristine for build-global and uncompresses for build- 2. There are multiple modulations, at least the global modulation and an ISA specific one The global modulation is for downlading files and building the package, all expansion and building is done in a ISA-specific modulation. That's why you see build-global and build-isa-sparcv8 / build-isa-i386 3. Make sure to call $(MAKECOOKIE) at the end Otherwise the rule will be exeuted multipe times and can cause harm if it is not involutionary. 4. Apply in post-extract-modulated The copy operation than is applied after extraction. The copying in the global modulation usually fails, but causes no harm. That's why I prefixed it with '-'. This should be enhanced in a future GAR version that the rules for global/specific can be easier separated. I have made ticket for it: Anyway, I updated your Makefile and everything should be fine now. Sorry for twiddling so much with your package, but while I was at it I just couldn't stop :-) Feel free to rip it apart as it uses quite some of the newer GAR features now. Best regards and thanks for your efforts -- Dago From dam at opencsw.org Wed Feb 10 15:55:11 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 10 Feb 2010 15:55:11 +0100 Subject: [csw-maintainers] RFD: Releases and staging proposal In-Reply-To: <20100209.19071200.4075474606@gyor.oxdrove.co.uk> References: <20100207.14012200.1398821831@gyor.oxdrove.co.uk> <4CA1F901-C232-4A4B-AB97-0F7F0CE7E9F2@opencsw.org> <20100208.12174700.451840536@gyor.oxdrove.co.uk> <20100209.19071200.4075474606@gyor.oxdrove.co.uk> Message-ID: <856B65BA-3A64-4577-8367-F047BB76F804@opencsw.org> Hi James, Am 09.02.2010 um 20:07 schrieb James Lee: > On 08/02/10, 17:39:13, Philip Brown wrote > regarding Re: > [csw-maintainers] RFD: Releases and staging proposal: >> As far as I'm aware, the #1 problem that we have in this sort of >> area, is >> "no one has volunteered to commit to spend the many hours involved, >> to >> be the official stable release manager" > > The number one problem has been the number of packages and innovation. If that would be thase case why didn't I hear something like "Ok, lets schedule the new projects so we get a stable out of the door"? > Taking a snapshot only makes sense if done at an opportune time and > there hasn't been one. Remember it has to be the timed right for > people too, not only those enacting release but those changing the > game as we go. Stability needs less innovation. That means we need > some people to hold off change while we plough though the mess. Sure. And with the new concept and GAR we could patch packages in the snapshotted tree easily. > Here's one example, we have stuff linked to both /usr/openwin and > /opt/csw/X11. I fear if we rebuild one package it just moves the > front to another which will possibly meet something large like KDE. > There are needs for experimental forks, /opt/csw/X11 could be one. > It might end up this easily solved in a few moves but it will take > time to verify the fact and it really shouldn't need asking in the > first place. Ok then, identify problems, file bugs, lookup maintainers, fix. Best regards -- Dago From dam at opencsw.org Wed Feb 10 15:58:24 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 10 Feb 2010 15:58:24 +0100 Subject: [csw-maintainers] RFD: Releases and staging proposal In-Reply-To: <20100209.19083400.2214484130@gyor.oxdrove.co.uk> References: <20100207.14012200.1398821831@gyor.oxdrove.co.uk> <4CA1F901-C232-4A4B-AB97-0F7F0CE7E9F2@opencsw.org> <20100208.12174700.451840536@gyor.oxdrove.co.uk> <20100209.19083400.2214484130@gyor.oxdrove.co.uk> Message-ID: <6DED5B1F-8901-4B2E-87EC-0A426AFFBB48@opencsw.org> Hi James, Am 09.02.2010 um 20:08 schrieb James Lee: > On 08/02/10, 20:52:01, Dagobert Michelsen wrote > regarding > Re: [csw-maintainers] RFD: Releases and staging proposal: > >>>> So we should stick to what we have and just drop the proposal? >>> >>> maybe, maybe not. >>> What does the "new" proposal fix? >>> That has not been identified. >>> >>> Seems to me, that should be the first thing in the proposal; >>> identifying "the problem" that the proposal has been created to fix. > >> It says so clearly in "background": >> "The main problem is that there are currently no processes that >> might potentially lead to a stable release" > > There is a process. > The proposal doesn't say how it is more likely to lead to a release. Because snapshots get updates? >>>> The wiki page is a proposal and you propose a change to the >>>> proposal. >>>> So how about some discussion on the matter instead of the wording? >>> >>> Why are you objecting to changing the wording? whats the problem? >>> He's suggested a change to the proposal. Are you only open to some >>> kinds of change to it? > >> First it says clearly on top of the page "Status: Draft". > > The missing word is proposal. Changed. >> There are two ways the document can be changed: >> 1. Describe the change in terms of "I propose to change the sentence >> 'abc' to 'def' in paragraph 1 of section 2" and discuss it on >> maintainers@ > > This the form a proposal should take. Show me the written process of how stable works now and I reformat the new proposal with "I propose to replace the existing process with ...". Best regards -- Dago From bwalton at opencsw.org Wed Feb 10 16:02:33 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 10 Feb 2010 10:02:33 -0500 Subject: [csw-maintainers] RFD: Releases and staging proposal In-Reply-To: <6DED5B1F-8901-4B2E-87EC-0A426AFFBB48@opencsw.org> References: <20100207.14012200.1398821831@gyor.oxdrove.co.uk> <4CA1F901-C232-4A4B-AB97-0F7F0CE7E9F2@opencsw.org> <20100208.12174700.451840536@gyor.oxdrove.co.uk> <20100209.19083400.2214484130@gyor.oxdrove.co.uk> <6DED5B1F-8901-4B2E-87EC-0A426AFFBB48@opencsw.org> Message-ID: <1265814123-sup-3251@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Feb 10 09:58:24 -0500 2010: Hi Dago, > Show me the written process of how stable works now and I reformat > the new proposal with "I propose to replace the existing process > with ...". http://www.opencsw.org/~james/release_process.txt HTH. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pfelecan at opencsw.org Wed Feb 10 17:38:45 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 10 Feb 2010 17:38:45 +0100 Subject: [csw-maintainers] Wintercamp minutes in Google Wave In-Reply-To: <4B5F8B33.6000902@opencsw.org> (Sebastian Kayser's message of "Wed, 27 Jan 2010 01:39:15 +0100") References: <4B5F8B33.6000902@opencsw.org> Message-ID: Sebastian Kayser writes: > The picture set on flickr has also seen some additions and now includes > 12 pictures [2]. Will upload the full batch for separate download when I > return from vacation in two weeks. William, could you also upload your > pictures somewhere for us to download them? The 3rd picture gives the impression that you're working on an Apple related project, more than 50% of the laptops are of that origin! Wished to be there... but I'm in a Catch 22 situation: I buy an Apple laptop and I'm staying home or I'm going to the next camp and I'm not buying that laptop. -- Peter From dam at opencsw.org Wed Feb 10 17:42:48 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 10 Feb 2010 17:42:48 +0100 Subject: [csw-maintainers] Wintercamp minutes in Google Wave In-Reply-To: References: <4B5F8B33.6000902@opencsw.org> Message-ID: <8FF23544-3C61-41DD-A8AC-64C295EC72AE@opencsw.org> Hi Peter, Am 10.02.2010 um 17:38 schrieb Peter FELECAN: > Sebastian Kayser writes: >> The picture set on flickr has also seen some additions and now >> includes >> 12 pictures [2]. Will upload the full batch for separate download >> when I >> return from vacation in two weeks. William, could you also upload >> your >> pictures somewhere for us to download them? > > The 3rd picture gives the impression that you're working on an Apple > related project, more than 50% of the laptops are of that origin! > Wished to be there... but I'm in a Catch 22 situation: I buy an Apple > laptop and I'm staying home or I'm going to the next camp and I'm not > buying that laptop. I don't think so. William offered to make it in Paris :-) Best regards -- Dago From bonivart at opencsw.org Wed Feb 10 17:43:02 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 10 Feb 2010 17:43:02 +0100 Subject: [csw-maintainers] Wintercamp minutes in Google Wave In-Reply-To: References: <4B5F8B33.6000902@opencsw.org> Message-ID: <625385e31002100843k102b6902mcedc130495dcf783@mail.gmail.com> On Wed, Feb 10, 2010 at 5:38 PM, Peter FELECAN wrote: > The 3rd picture gives the impression that you're working on an Apple > related project, more than 50% of the laptops are of that origin! > Wished to be there... but I'm in a Catch 22 situation: I buy an Apple > laptop and I'm staying home or I'm going to the next camp and I'm not > buying that laptop. Apple gear is not expensive but it sure is valuable! ;-) -- /peter From pfelecan at opencsw.org Wed Feb 10 18:39:54 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 10 Feb 2010 18:39:54 +0100 Subject: [csw-maintainers] Wintercamp minutes in Google Wave In-Reply-To: <8FF23544-3C61-41DD-A8AC-64C295EC72AE@opencsw.org> (Dagobert Michelsen's message of "Wed, 10 Feb 2010 17:42:48 +0100") References: <4B5F8B33.6000902@opencsw.org> <8FF23544-3C61-41DD-A8AC-64C295EC72AE@opencsw.org> Message-ID: Dagobert Michelsen writes: > Hi Peter, > > Am 10.02.2010 um 17:38 schrieb Peter FELECAN: >> Sebastian Kayser writes: >>> The picture set on flickr has also seen some additions and now >>> includes >>> 12 pictures [2]. Will upload the full batch for separate download >>> when I >>> return from vacation in two weeks. William, could you also upload >>> your >>> pictures somewhere for us to download them? >> >> The 3rd picture gives the impression that you're working on an Apple >> related project, more than 50% of the laptops are of that origin! >> Wished to be there... but I'm in a Catch 22 situation: I buy an Apple >> laptop and I'm staying home or I'm going to the next camp and I'm not >> buying that laptop. > > I don't think so. William offered to make it in Paris :-) Nice to read this. I'm sure that William will contact me to help him organize that event... -- Peter From pfelecan at opencsw.org Wed Feb 10 18:43:18 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 10 Feb 2010 18:43:18 +0100 Subject: [csw-maintainers] Wintercamp minutes in Google Wave In-Reply-To: <625385e31002100843k102b6902mcedc130495dcf783@mail.gmail.com> (Peter Bonivart's message of "Wed, 10 Feb 2010 17:43:02 +0100") References: <4B5F8B33.6000902@opencsw.org> <625385e31002100843k102b6902mcedc130495dcf783@mail.gmail.com> Message-ID: Peter Bonivart writes: > On Wed, Feb 10, 2010 at 5:38 PM, Peter FELECAN wrote: >> The 3rd picture gives the impression that you're working on an Apple >> related project, more than 50% of the laptops are of that origin! >> Wished to be there... but I'm in a Catch 22 situation: I buy an Apple >> laptop and I'm staying home or I'm going to the next camp and I'm not >> buying that laptop. > > Apple gear is not expensive but it sure is valuable! ;-) Owning more Apple gear that have fingers on one hand, I know their value, although sometime I'm bothered by their obtuseness, but also their price; "not expansive" it's a very relative affirmation. -- Peter From pfelecan at opencsw.org Wed Feb 10 18:46:16 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 10 Feb 2010 18:46:16 +0100 Subject: [csw-maintainers] Wintercamp minutes in Google Wave In-Reply-To: (Maciej Blizinski's message of "Sun, 24 Jan 2010 14:17:43 +0000") References: Message-ID: "Maciej (Matchek) Blizinski" writes: > I've shared the Wintercamp waves with a newly created Google Group, > called opencsw-maintainers. People who would like to read the wave, > can join this group, using Google accounts. When people have joined > the group, they can go to http://wave.google.com - the wave should be > in your wave inboxes. The access to the waves will be read/write, so > all members will be able to continue the discussions started on the > Wintercamp, and there's a bunch of pretty interesting ones there. > > There are 2 waves from 2 days, containing a transcript of the > discussions during the meetings. > > We'll also provide a read-only export, but we don't know yet what will > be the exact way, perhaps a HTML or a PDF file. Matchek, To access a Wave you need a specific account. To open that account, you need an invitation. Well, another nice Catch 22. Oh, well, I asked omnious Google to invite me... -- Peter From bonivart at opencsw.org Wed Feb 10 18:50:49 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 10 Feb 2010 18:50:49 +0100 Subject: [csw-maintainers] Wintercamp minutes in Google Wave In-Reply-To: References: Message-ID: <625385e31002100950oe097c9fs4520415d9ed40f21@mail.gmail.com> On Wed, Feb 10, 2010 at 6:46 PM, Peter FELECAN wrote: > "Maciej (Matchek) Blizinski" writes: > >> I've shared the Wintercamp waves with a newly created Google Group, >> called opencsw-maintainers. People who would like to read the wave, >> can join this group, using Google accounts. When people have joined >> the group, they can go to http://wave.google.com - the wave should be >> in your wave inboxes. ?The access to the waves will be read/write, so >> all members will be able to continue the discussions started on the >> Wintercamp, and there's a bunch of pretty interesting ones there. >> >> There are 2 waves from 2 days, containing a transcript of the >> discussions during the meetings. >> >> We'll also provide a read-only export, but we don't know yet what will >> be the exact way, perhaps a HTML or a PDF file. > > Matchek, > > To access a Wave you need a specific account. To open that account, you > need an invitation. Well, another nice Catch 22. Oh, well, I asked > omnious Google to invite me... There's a text version on the wiki now if you haven't seen it. http://wiki.opencsw.org/wintercamp-2009-minutes -- /peter From pfelecan at opencsw.org Wed Feb 10 19:30:22 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 10 Feb 2010 19:30:22 +0100 Subject: [csw-maintainers] Wintercamp minutes in Google Wave In-Reply-To: <625385e31002100950oe097c9fs4520415d9ed40f21@mail.gmail.com> (Peter Bonivart's message of "Wed, 10 Feb 2010 18:50:49 +0100") References: <625385e31002100950oe097c9fs4520415d9ed40f21@mail.gmail.com> Message-ID: Peter Bonivart writes: > On Wed, Feb 10, 2010 at 6:46 PM, Peter FELECAN wrote: >> "Maciej (Matchek) Blizinski" writes: >> >>> I've shared the Wintercamp waves with a newly created Google Group, >>> called opencsw-maintainers. People who would like to read the wave, >>> can join this group, using Google accounts. When people have joined >>> the group, they can go to http://wave.google.com - the wave should be >>> in your wave inboxes. ?The access to the waves will be read/write, so >>> all members will be able to continue the discussions started on the >>> Wintercamp, and there's a bunch of pretty interesting ones there. >>> >>> There are 2 waves from 2 days, containing a transcript of the >>> discussions during the meetings. >>> >>> We'll also provide a read-only export, but we don't know yet what will >>> be the exact way, perhaps a HTML or a PDF file. >> >> Matchek, >> >> To access a Wave you need a specific account. To open that account, you >> need an invitation. Well, another nice Catch 22. Oh, well, I asked >> omnious Google to invite me... > > There's a text version on the wiki now if you haven't seen it. > > http://wiki.opencsw.org/wintercamp-2009-minutes I've seen it but I wanted to be more "in" and "wave"... Why do you call this winter-camp the 2009 one when it took place in 2010? there is something in calendar management that escapes my understanding. -- Peter From pfelecan at opencsw.org Wed Feb 10 19:49:01 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 10 Feb 2010 19:49:01 +0100 Subject: [csw-maintainers] Problem with "alternatives" on updates In-Reply-To: <7E966BC5-D968-4A0B-B273-D491E8E2CDF2@opencsw.org> (Dagobert Michelsen's message of "Fri, 5 Feb 2010 17:54:44 +0100") References: <7E966BC5-D968-4A0B-B273-D491E8E2CDF2@opencsw.org> Message-ID: Dagobert Michelsen writes: > Could please some Linux-freak look at how > Debian/RedHat handle this? I guess we need > update-hook-scripts to handle this cleanly. I'd like to help but that would qualify me as a freak isn't it? -- Peter From bwalton at opencsw.org Wed Feb 10 20:14:40 2010 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 10 Feb 2010 14:14:40 -0500 Subject: [csw-maintainers] Problem with "alternatives" on updates In-Reply-To: References: <7E966BC5-D968-4A0B-B273-D491E8E2CDF2@opencsw.org> Message-ID: <1265829205-sup-527@ntdws12.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Wed Feb 10 13:49:01 -0500 2010: > I'd like to help but that would qualify me as a freak isn't it? I'll take that action. :) I meant to send this the other day, but forgot. See attached dump from `rpm -q --scripts exim ` on RHEL5. There is non-alternatives stuff in there too as I haven't cleaned it up at all. HTH. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: exim_scripts.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skayser at opencsw.org Wed Feb 10 20:51:17 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 10 Feb 2010 20:51:17 +0100 Subject: [csw-maintainers] Wintercamp minutes in Google Wave In-Reply-To: References: <625385e31002100950oe097c9fs4520415d9ed40f21@mail.gmail.com> Message-ID: <4B730E35.10301@opencsw.org> Peter FELECAN wrote on 10.02.2010 19:30: > Peter Bonivart writes: > >> On Wed, Feb 10, 2010 at 6:46 PM, Peter FELECAN wrote: >>> "Maciej (Matchek) Blizinski" writes: >>> >>>> I've shared the Wintercamp waves with a newly created Google Group, >>>> called opencsw-maintainers. People who would like to read the wave, >>>> can join this group, using Google accounts. When people have joined >>>> the group, they can go to http://wave.google.com - the wave should be >>>> in your wave inboxes. The access to the waves will be read/write, so >>>> all members will be able to continue the discussions started on the >>>> Wintercamp, and there's a bunch of pretty interesting ones there. >>>> >>>> There are 2 waves from 2 days, containing a transcript of the >>>> discussions during the meetings. >>>> >>>> We'll also provide a read-only export, but we don't know yet what will >>>> be the exact way, perhaps a HTML or a PDF file. >>> Matchek, >>> >>> To access a Wave you need a specific account. To open that account, you >>> need an invitation. Well, another nice Catch 22. Oh, well, I asked >>> omnious Google to invite me... >> There's a text version on the wiki now if you haven't seen it. >> >> http://wiki.opencsw.org/wintercamp-2009-minutes > > I've seen it but I wanted to be more "in" and "wave"... > > Why do you call this winter-camp the 2009 one when it took place in > 2010? there is something in calendar management that escapes my > understanding. True :) Winter camp 2008 (aka IRL meeting) took place in early December. So could have winter camp 2009 when we started to plan it, but eventually it didn't. The name staid. At least there is now room for a genuine winter camp 2010 later this year, instead of winter camp 2010 II. We all know the curse on "II"s. ;) Sebastian From jgoerzen at opencsw.org Wed Feb 10 22:11:34 2010 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Wed, 10 Feb 2010 13:11:34 -0800 Subject: [csw-maintainers] confused with build-global and build-isa... In-Reply-To: <9046A4AF-9FBA-4FE4-A431-DB7B7A76F3F2@opencsw.org> References: <315c02ae1002081352w2ff2b777w96d4be3094eebdd3@mail.gmail.com> <4B70937B.7010400@opencsw.org> <956B79A6-9C8C-4BD6-B40A-3210461B0ED2@opencsw.org> <315c02ae1002091146y7a6f02ffo841aa40e57a5651@mail.gmail.com> <9046A4AF-9FBA-4FE4-A431-DB7B7A76F3F2@opencsw.org> Message-ID: <315c02ae1002101311q55defb3ahe1fefa15a79c9d28@mail.gmail.com> On Wed, Feb 10, 2010 at 6:52 AM, Dagobert Michelsen wrote: > Hi Jake, > > Am 09.02.2010 um 20:46 schrieb Jake Goerzen: >> >> For me $(WORKDIR) expands to (work/solaris8-sparc/build-global) and >> $(WORKSRC) expands to >> (work/solaris8-sparc/build-global/gkrellm-2.3.4). ?However GAR didn't >> extract my source here. ?GAR extracted my source in: >> >> work/solaris8-sparc/build-isa-sparcv8/gkrellm-2.3.4 >> >> Notice build-isa-sparcv8 instead of build-global. ?At the moment I >> hacked this together and it works: >> >> pre-configure-modulated: >> ? ? ? @cp $(FILEDIR)/Makefile >> $(WORKROOTDIR)/build-$(MODULATIONS)/$(GARNAME)-$ >> (GARVERSION)/Makefile >> ? ? ? @cp $(FILEDIR)/src.Makefile >> $(WORKROOTDIR)/build-$(MODULATIONS)/$(GARNAM >> E)-$(GARVERSION)/src/Makefile >> ? ? ? @cp $(FILEDIR)/server.Makefile >> $(WORKROOTDIR)/build-$(MODULATIONS)/$(GAR >> NAME)-$(GARVERSION)/server/Makefile >> >> The full recipe is commited to GAR: >> >> http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/gkrellm/trunk/Makefile > > Ok, there are number of issues here: > > 1. Please add all files in files/ to either DISTFILES or PATCHFILES > Doing so adds them for checksumming and will allow a clean collection of > files > for source packages later on. All files here will be delivered to > $(WORKDIR), > pristine for build-global and uncompresses for build- > > 2. There are multiple modulations, at least the global modulation and an ISA > specific one > The global modulation is for downlading files and building the package, all > expansion and > building is done in a ISA-specific modulation. That's why you see > build-global and > build-isa-sparcv8 / build-isa-i386 Thank you for explaining this. I knew that the actual build was being done in the ISA-specific modulation but I didn't fully understand what build-global was for. > > 3. Make sure to call $(MAKECOOKIE) at the end > Otherwise the rule will be exeuted multipe times and can cause harm if it is > not involutionary. > > 4. Apply in post-extract-modulated > The copy operation than is applied after extraction. The copying in the > global > modulation usually fails, but causes no harm. That's why I prefixed it with > '-'. > This should be enhanced in a future GAR version that the rules for > global/specific > can be easier separated. I have made ticket for it: > ? > > Anyway, I updated your Makefile and everything should be fine now. Sorry for > twiddling so much with your package, but while I was at it I just couldn't > stop :-) > Feel free to rip it apart as it uses quite some of the newer GAR features > now. Thank you I'm looking at this now and starting to understand better. not sure what this means, does this mean /usr/ucb/install is going to be used? Shouldn't I use /opt/csw/bin/ginstall instead? INSTALL_OVERRIDE_VARS = INSTALL INSTALL_OVERRIDE_VAR_INSTALL = /usr/ucb/install Thanks, Jake From maciej at opencsw.org Thu Feb 11 08:18:14 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 11 Feb 2010 07:18:14 +0000 Subject: [csw-maintainers] [GAR] Overrides implemented In-Reply-To: References: <625385e31002070440u62cd1019g3813d1c5ede85896@mail.gmail.com> <625385e31002070516ve3d8457oe3fd703f8c7f6be7@mail.gmail.com> Message-ID: Good news! Thanks to Dago, GAR has now support for overrides: starting with r8458[1], you can create an override with just one line in GAR: CHECKPKG_OVERRIDES = CSWfoo|error-tag-name If you want to create a more specific override, you can also write: CHECKPKG_OVERRIDES = CSWfoo|error-tag-name|parameter An example of a parameter would be a .so file name if you're overriding the symbol-not-found error. Enjoy! Maciej [1] http://sourceforge.net/apps/trac/gar/changeset/8458 From dam at opencsw.org Thu Feb 11 10:54:01 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 11 Feb 2010 10:54:01 +0100 Subject: [csw-maintainers] confused with build-global and build-isa... In-Reply-To: <315c02ae1002101311q55defb3ahe1fefa15a79c9d28@mail.gmail.com> References: <315c02ae1002081352w2ff2b777w96d4be3094eebdd3@mail.gmail.com> <4B70937B.7010400@opencsw.org> <956B79A6-9C8C-4BD6-B40A-3210461B0ED2@opencsw.org> <315c02ae1002091146y7a6f02ffo841aa40e57a5651@mail.gmail.com> <9046A4AF-9FBA-4FE4-A431-DB7B7A76F3F2@opencsw.org> <315c02ae1002101311q55defb3ahe1fefa15a79c9d28@mail.gmail.com> Message-ID: Hi Jake, Am 10.02.2010 um 22:11 schrieb Jake Goerzen: > Thank you I'm looking at this now and starting to understand better. > > not sure what this means, does this mean /usr/ucb/install is going to > be used? Shouldn't I use /opt/csw/bin/ginstall instead? > > INSTALL_OVERRIDE_VARS = INSTALL > INSTALL_OVERRIDE_VAR_INSTALL = /usr/ucb/install That means that INSTALL=/usr/ucb/install is passed to "make install" to override the Makefile variable "INSTALL". The syntax is INSTALL_OVERRIDE_VARS = INSTALL_OVERRIDE_VAR_ = ... The reason for using INSTALL_OVERRIDE_VAR_* instead of just the variable is that the overridden variables are often very common and may break the build at other places. I choose /usr/ucb/install because it worked :-) ginstall may have worked also. Best regards -- Dago From dam at opencsw.org Thu Feb 11 11:03:15 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 11 Feb 2010 11:03:15 +0100 Subject: [csw-maintainers] Problem with "alternatives" on updates In-Reply-To: <1265829205-sup-527@ntdws12.chass.utoronto.ca> References: <7E966BC5-D968-4A0B-B273-D491E8E2CDF2@opencsw.org> <1265829205-sup-527@ntdws12.chass.utoronto.ca> Message-ID: <73AFD8F7-3500-482B-B57B-BE2B114137E0@opencsw.org> Hi Ben, Am 10.02.2010 um 20:14 schrieb Ben Walton: > I'll take that action. :) > > I meant to send this the other day, but forgot. See attached dump > from `rpm -q --scripts exim ` on RHEL5. There is non-alternatives > stuff in there too as I haven't cleaned it up at all. Thanks for the snippet! However, I find the actions a bit strange: > preuninstall scriptlet (using /bin/sh): > if [ $1 = 0 ]; then > /sbin/service exim stop > /dev/null 2>&1 > /sbin/chkconfig --del exim > /usr/sbin/alternatives --remove mta /usr/sbin/sendmail.exim > fi This is ok. > postuninstall scriptlet (using /bin/sh): > if [ "$1" -ge "1" ]; then > /sbin/service exim condrestart > /dev/null 2>&1 > mta=`readlink /etc/alternatives/mta` > if [ "$mta" == "/usr/sbin/sendmail.exim" ]; then > /usr/sbin/alternatives --set mta /usr/sbin/sendmail.exim > fi > fi This is strange, when the alternatives linkgroup has been set to manual the readline would stay unaltered and the script would enter the clause. However, as sendmail.exim already has been deleted in preuninstall an error would have been thrown. Strange. Best regards -- Dago From bwalton at opencsw.org Thu Feb 11 13:00:21 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 11 Feb 2010 07:00:21 -0500 Subject: [csw-maintainers] Problem with "alternatives" on updates In-Reply-To: <73AFD8F7-3500-482B-B57B-BE2B114137E0@opencsw.org> References: <7E966BC5-D968-4A0B-B273-D491E8E2CDF2@opencsw.org> <1265829205-sup-527@ntdws12.chass.utoronto.ca> <73AFD8F7-3500-482B-B57B-BE2B114137E0@opencsw.org> Message-ID: <1265889472-sup-3249@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Thu Feb 11 05:03:15 -0500 2010: Hi Dago, > > postuninstall scriptlet (using /bin/sh): > > if [ "$1" -ge "1" ]; then This is the key to the script here. The rpm system has the notion of upgrades and when $1 -ne "0", the script can assume it was upgraded and that the postuninstall script is being triggered in that context. It's not as nice as the dpkg version, but it gets the job done. Hopefully that clears it up, although it won't make it easier for us, as we only have an upgrade notion when wrapped by pkgutil/pkg-get. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dam at opencsw.org Thu Feb 11 13:09:10 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 11 Feb 2010 13:09:10 +0100 Subject: [csw-maintainers] Problem with "alternatives" on updates In-Reply-To: <1265889472-sup-3249@ntdws12.chass.utoronto.ca> 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> Message-ID: <679A617A-8081-4AE4-BFBB-BE8ACEEA68C1@opencsw.org> Hi Ben, Am 11.02.2010 um 13:00 schrieb Ben Walton: > Excerpts from Dagobert Michelsen's message of Thu Feb 11 05:03:15 > -0500 2010: > > Hi Dago, > >>> postuninstall scriptlet (using /bin/sh): >>> if [ "$1" -ge "1" ]; then > > This is the key to the script here. The rpm system has the notion of > upgrades and when $1 -ne "0", the script can assume it was upgraded > and that the postuninstall script is being triggered in that context. > It's not as nice as the dpkg version, but it gets the job done. > > Hopefully that clears it up, although it won't make it easier for us, > as we only have an upgrade notion when wrapped by pkgutil/pkg-get. The current plan is to save the selection if the linkgroup is in manual mode *and* the selection in the package removed. On an alternatives addition it is checked if the saved selection is about to be re-added and then "set". This way updates will work in addition to removals. The one problem is a removal followed by an addition much later, which would also be noticed as update. Best regards -- Dago From hson at opencsw.org Thu Feb 11 14:49:40 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Thu, 11 Feb 2010 14:49:40 +0100 Subject: [csw-maintainers] ldd -r and "symbol not found:" errors: how to disable the check In-Reply-To: <4B6F052B.7020809@opencsw.org> References: <4B6F052B.7020809@opencsw.org> Message-ID: <4B740AF4.8030900@opencsw.org> Roger H?kansson wrote: > On 2010-02-06 00:30, Maciej (Matchek) Blizinski wrote: >> I've added a new checkpkg module a few days ago, which runs "ldd -r" >> and greps the output for "symbol not found:". This catches shared >> libraries which are not self-contained. >> >> Some of you will hit the problem in which this check throws a false >> positive: There might be libraries which are non-self-contained by >> design. > > That's not the only case, when building packages where you have binaries > linked to libraries which belongs to the package being built, or when a > package contains more than one library and there are some dependencies > between them, you also get an error. > > Currently "missing-symbols" only seem to work when there are binaries > and libraries linked to libraries outside the package. Found another problem: When building libsoup, I get: CSWlibsoup: symbol-not-found libsoup-gnome-2.4.so.1.2.0 libsoup-gnome-2.4.so.1.2.0 is the binary file and there are two links to that file, libsoup-gnome-2.4.so.1 and libsoup-gnome-2.4.so. SONAME for that lib is libsoup-gnome-2.4.so.1 so why checkpkg complains about not finding libsoup-gnome-2.4.so.1.2.0 I can't see. Also, in the package I've included the libraries from the current libsoup and libsoup2 packages and for one of those libraries I get the same error From bwalton at opencsw.org Thu Feb 11 14:50:03 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 11 Feb 2010 08:50:03 -0500 Subject: [csw-maintainers] Problem with "alternatives" on updates In-Reply-To: <679A617A-8081-4AE4-BFBB-BE8ACEEA68C1@opencsw.org> 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> Message-ID: <1265896142-sup-7879@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Thu Feb 11 07:09:10 -0500 2010: Hi Dago, > in addition to removals. The one problem is a removal followed > by an addition much later, which would also be noticed as update. The plan is sensible and should work. This is likely to be a corner case that doesn't get hit very often too...and since the links are in manual mode, presumably the admin is aware enough to 'do the right thing' anyway. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 -------------- 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 Thu Feb 11 15:15:50 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 11 Feb 2010 14:15:50 +0000 Subject: [csw-maintainers] ldd -r and "symbol not found:" errors: how to disable the check In-Reply-To: <4B740AF4.8030900@opencsw.org> References: <4B6F052B.7020809@opencsw.org> <4B740AF4.8030900@opencsw.org> Message-ID: On Thu, Feb 11, 2010 at 1:49 PM, Roger H?kansson wrote: > Found another problem: > > When building libsoup, I get: > CSWlibsoup: symbol-not-found libsoup-gnome-2.4.so.1.2.0 > > libsoup-gnome-2.4.so.1.2.0 is the binary file and there are two links to > that file, libsoup-gnome-2.4.so.1 and libsoup-gnome-2.4.so. > SONAME for that lib is libsoup-gnome-2.4.so.1 so why checkpkg complains > about not finding libsoup-gnome-2.4.so.1.2.0 I can't see. What's the output of "ldd -r libsoup-gnome-2.4.so.1.2.0"? If there are any "symbol not found" message, that would explain the thrown error. > Also, in the package I've included the libraries from the current libsoup > and libsoup2 packages and for one of those libraries I get the same error The same thing, try looking at "ldd -r ". Maciej From hson at opencsw.org Thu Feb 11 18:06:46 2010 From: hson at opencsw.org (=?UTF-8?B?Um9nZXIgSMOla2Fuc3Nvbg==?=) Date: Thu, 11 Feb 2010 18:06:46 +0100 Subject: [csw-maintainers] ldd -r and "symbol not found:" errors: how to disable the check In-Reply-To: References: <4B6F052B.7020809@opencsw.org> <4B740AF4.8030900@opencsw.org> Message-ID: <4B743926.9060703@opencsw.org> Maciej (Matchek) Blizinski wrote: > On Thu, Feb 11, 2010 at 1:49 PM, Roger H?kansson wrote: >> Found another problem: >> >> When building libsoup, I get: >> CSWlibsoup: symbol-not-found libsoup-gnome-2.4.so.1.2.0 >> >> libsoup-gnome-2.4.so.1.2.0 is the binary file and there are two links to >> that file, libsoup-gnome-2.4.so.1 and libsoup-gnome-2.4.so. >> SONAME for that lib is libsoup-gnome-2.4.so.1 so why checkpkg complains >> about not finding libsoup-gnome-2.4.so.1.2.0 I can't see. > > What's the output of "ldd -r libsoup-gnome-2.4.so.1.2.0"? If there > are any "symbol not found" message, that would explain the thrown > error. Ahh, I misinterpreted the error message, I thought the missing symbol was libsoup-gnome-2.4.so.1.2.0. It's the same problem as I reported earlier, libsoup-gnome-2.4.so.1.2.0 (with SONAME libsoup-gnome-2.4.so.1) have missing symbols (when running ldd -r ) which belongs to another lib (libsoup-2.4.so. in the libsoup package. >> Also, in the package I've included the libraries from the current libsoup >> and libsoup2 packages and for one of those libraries I get the same error > > The same thing, try looking at "ldd -r ". In this case, the error is related to this error: CheckpkgTag('CSWlibsoup', 'orphan-soname', 'libgnutls.so.11', ...) Also I'm wondering how the "missing-dependency" check is done, because I've seem many strange errors from this one. Most of the times it's like this: Package CSWxxx have binaries, CSWxxxrt have libraries and CSWxxxdevel. And since CSWxxx isn't really a requirement for development, only CSWxxxrt is listed in RUNTIME_DEP_PKGS_CSWxxxdevel. But "missing-dependency" always (at least from what I've seen) suggests that CSWxxxrt is a unnecessary dependency for CSWxxxdevel and that CSWxxx should be a added as a dependency. But what it bases that suggestion on I can't see. From maciej at opencsw.org Thu Feb 11 18:22:47 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 11 Feb 2010 17:22:47 +0000 Subject: [csw-maintainers] ldd -r and "symbol not found:" errors: how to disable the check In-Reply-To: <4B743926.9060703@opencsw.org> References: <4B6F052B.7020809@opencsw.org> <4B740AF4.8030900@opencsw.org> <4B743926.9060703@opencsw.org> Message-ID: On Thu, Feb 11, 2010 at 5:06 PM, Roger H?kansson wrote: > Also I'm wondering how the "missing-dependency" check is done, because I've > seem many strange errors from this one. > Most of the times it's like this: > Package CSWxxx have binaries, CSWxxxrt have libraries and CSWxxxdevel. > And since CSWxxx isn't really a requirement for development, only CSWxxxrt > is listed in RUNTIME_DEP_PKGS_CSWxxxdevel. > But "missing-dependency" always (at least from what I've seen) suggests that > CSWxxxrt is a unnecessary dependency for CSWxxxdevel and that CSWxxx should > be a added as a dependency. But what it bases that suggestion on I can't > see. There are some heuristics done, and the reasons aren't propagated outside of the script. I plan to extend the dependency checker so that it tells which packages should have dependencies and why it thinks that. My guesses are: CSWxxxdevel has no binaries that link against CSWxxxrt, so CSWxxxrt doesn't seem necessary. CSWxxx looks like a base name for CSWxxxrt, so it suggests that maybe it CSWxxxrt is an extension for CSWxxx. Again, a heuristic. These are only fuzzy guesses, and they only print messages to the screen. Once the dependency code becomes smarter and confident, it'll start throwing errors. In the current state of affairs, you can safely assume you're smarter than the script. From ihsan at opencsw.org Thu Feb 11 23:48:44 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Thu, 11 Feb 2010 23:48:44 +0100 Subject: [csw-maintainers] pkgsubmission list Message-ID: <4B74894C.4080206@opencsw.org> Good evening, I've set up the new mailing list pkgrequest. If you would like to be on this list, please subscribe your self. https://lists.opencsw.org/mailman/listinfo/pkgsubmissions Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From bonivart at opencsw.org Fri Feb 12 10:20:10 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 12 Feb 2010 10:20:10 +0100 Subject: [csw-maintainers] pkgsubmission list In-Reply-To: <4B74894C.4080206@opencsw.org> References: <4B74894C.4080206@opencsw.org> Message-ID: <625385e31002120120i58ab824bp4e57611d8ea0f43e@mail.gmail.com> On Thu, Feb 11, 2010 at 11:48 PM, Ihsan Dogan wrote: > Good evening, > > I've set up the new mailing list pkgrequest. If you would like to be on > this list, please subscribe your self. > > https://lists.opencsw.org/mailman/listinfo/pkgsubmissions Could you please manually subscribe me since I, for some reason, can't seem to do that myself. -- /peter From maciej at opencsw.org Fri Feb 12 10:53:39 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 12 Feb 2010 09:53:39 +0000 Subject: [csw-maintainers] pkgsubmission list In-Reply-To: <625385e31002120120i58ab824bp4e57611d8ea0f43e@mail.gmail.com> References: <4B74894C.4080206@opencsw.org> <625385e31002120120i58ab824bp4e57611d8ea0f43e@mail.gmail.com> Message-ID: On Fri, Feb 12, 2010 at 9:20 AM, Peter Bonivart wrote: > On Thu, Feb 11, 2010 at 11:48 PM, Ihsan Dogan wrote: >> Good evening, >> >> I've set up the new mailing list pkgrequest. If you would like to be on >> this list, please subscribe your self. >> >> https://lists.opencsw.org/mailman/listinfo/pkgsubmissions > > Could you please manually subscribe me since I, for some reason, can't > seem to do that myself. Fixing registrations still would be good. I filled the registration form on the linked page, but I haven't gotten the e-mail with confirmation. From skayser at opencsw.org Fri Feb 12 10:56:55 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 12 Feb 2010 10:56:55 +0100 Subject: [csw-maintainers] pkgsubmission list In-Reply-To: References: <4B74894C.4080206@opencsw.org> <625385e31002120120i58ab824bp4e57611d8ea0f43e@mail.gmail.com> Message-ID: <4B7525E7.6060403@opencsw.org> Maciej (Matchek) Blizinski wrote on 12.02.2010 10:53: > On Fri, Feb 12, 2010 at 9:20 AM, Peter Bonivart wrote: >> On Thu, Feb 11, 2010 at 11:48 PM, Ihsan Dogan wrote: >>> Good evening, >>> >>> I've set up the new mailing list pkgrequest. If you would like to be on >>> this list, please subscribe your self. >>> >>> https://lists.opencsw.org/mailman/listinfo/pkgsubmissions >> Could you please manually subscribe me since I, for some reason, can't >> seem to do that myself. > > Fixing registrations still would be good. I filled the registration > form on the linked page, but I haven't gotten the e-mail with > confirmation. Same here. Sebastian From bonivart at opencsw.org Fri Feb 12 11:00:48 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 12 Feb 2010 11:00:48 +0100 Subject: [csw-maintainers] pkgsubmission list In-Reply-To: References: <4B74894C.4080206@opencsw.org> <625385e31002120120i58ab824bp4e57611d8ea0f43e@mail.gmail.com> Message-ID: <625385e31002120200l6e83ec1btc0d816a108591fd2@mail.gmail.com> On Fri, Feb 12, 2010 at 10:53 AM, Maciej (Matchek) Blizinski wrote: > On Fri, Feb 12, 2010 at 9:20 AM, Peter Bonivart wrote: >> On Thu, Feb 11, 2010 at 11:48 PM, Ihsan Dogan wrote: >>> Good evening, >>> >>> I've set up the new mailing list pkgrequest. If you would like to be on >>> this list, please subscribe your self. >>> >>> https://lists.opencsw.org/mailman/listinfo/pkgsubmissions >> >> Could you please manually subscribe me since I, for some reason, can't >> seem to do that myself. > > Fixing registrations still would be good. ?I filled the registration > form on the linked page, but I haven't gotten the e-mail with > confirmation. Ok, so it's not just me then. Good to hear. :-) -- /peter From bwalton at opencsw.org Fri Feb 12 13:41:43 2010 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 12 Feb 2010 07:41:43 -0500 Subject: [csw-maintainers] pkgsubmission list In-Reply-To: <625385e31002120200l6e83ec1btc0d816a108591fd2@mail.gmail.com> References: <4B74894C.4080206@opencsw.org> <625385e31002120120i58ab824bp4e57611d8ea0f43e@mail.gmail.com> <625385e31002120200l6e83ec1btc0d816a108591fd2@mail.gmail.com> Message-ID: <1265978487-sup-968@ntdws12.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Fri Feb 12 05:00:48 -0500 2010: > Ok, so it's not just me then. Good to hear. :-) Mine didn't arrive either. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 -------------- 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 Fri Feb 12 13:59:15 2010 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 12 Feb 2010 07:59:15 -0500 Subject: [csw-maintainers] away for the weekend Message-ID: <1265979517-sup-145@ntdws12.chass.utoronto.ca> Hi All, I won't be in a position to handle any buildfarm stuff until late Sunday night (maybe Monday morning), so be patient with any weekend requests that fall outside of Dago's hours. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bonivart at opencsw.org Fri Feb 12 16:28:15 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 12 Feb 2010 16:28:15 +0100 Subject: [csw-maintainers] /testing cswclassutils Message-ID: <625385e31002120728h2f758f2aua9d6eb2c8e5bdd71@mail.gmail.com> There's a new version, 1.33, of cswclassutils in testing that I need help to test. It should (hopefully) close the following bugs: - cswinitsmf should refuse to create an FMRI with a dot in the name (http://www.opencsw.org/mantis/view.php?id=4075) - Alternate root installation (via pkgadd -R): i.cswcpsampleconf throws chown/chmod errors (http://www.opencsw.org/mantis/view.php?id=4118) - cswmigrateconf should print the warning only when necessary (http://www.opencsw.org/mantis/view.php?id=4143) And it introduces a new class called cswpostmsg which displays a files content at the end of a package install, think motd. One of the few remaining reasons to use a postinstall script is to display some info about the package setup or upgrade notes and there's no need to get an annoying superuser prompt for that. Just point this class towards a file and it will be displayed at the end of the install. This is documented on the wiki: http://wiki.opencsw.org/cswclassutils-package#toc17 http://mirror.opencsw.org/testing/cswclassutils-1.33,REV=2010.02.11-SunOS5.8-all-CSW.pkg.gz I would really appreciate some feedback on how the above stuff works. -- /peter From David.Mantock at connectis.ch Thu Feb 11 14:26:28 2010 From: David.Mantock at connectis.ch (Mantock David) Date: Thu, 11 Feb 2010 14:26:28 +0100 Subject: [csw-maintainers] CSWoldap In-Reply-To: <679A617A-8081-4AE4-BFBB-BE8ACEEA68C1@opencsw.org> 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> Message-ID: <940F857E6596B84BAFD05DBA869276E234B3225C7C@CON-EX-001.connectis.local> Hi Dago, I made the following packages yesterday and I have now loaded them in to build farm NFS share: /home/testing openldap_client-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz openldap_devel-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz openldap_rt-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz openldap-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz They are available for testing on http://mirror.opencsw.org/opencsw/testing Apart from making x86 versions is there something else I should do? Thanks and best regards, David -----Original Message----- From: maintainers-bounces+dlm=opencsw.org at lists.opencsw.org [mailto:maintainers-bounces+dlm=opencsw.org at lists.opencsw.org] On Behalf Of Dagobert Michelsen Sent: Donnerstag, 11. Februar 2010 13:09 To: List for OpenCSW maintainers Subject: Re: [csw-maintainers] Problem with "alternatives" on updates Hi Ben, Am 11.02.2010 um 13:00 schrieb Ben Walton: > Excerpts from Dagobert Michelsen's message of Thu Feb 11 05:03:15 > -0500 2010: > > Hi Dago, > >>> postuninstall scriptlet (using /bin/sh): >>> if [ "$1" -ge "1" ]; then > > This is the key to the script here. The rpm system has the notion of > upgrades and when $1 -ne "0", the script can assume it was upgraded > and that the postuninstall script is being triggered in that context. > It's not as nice as the dpkg version, but it gets the job done. > > Hopefully that clears it up, although it won't make it easier for us, > as we only have an upgrade notion when wrapped by pkgutil/pkg-get. The current plan is to save the selection if the linkgroup is in manual mode *and* the selection in the package removed. On an alternatives addition it is checked if the saved selection is about to be re-added and then "set". This way updates will work in addition to removals. The one problem is a removal followed by an addition much later, which would also be noticed as update. 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. ::. This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of connectis AG. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please destroy the message and/or contact the sender if you believe you have received this email in error. From ihsan at opencsw.org Sun Feb 14 14:53:05 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 14 Feb 2010 14:53:05 +0100 Subject: [csw-maintainers] pkgsubmissions list Message-ID: <4B780041.9000903@opencsw.org> Hello, Due a configuration error the new pkgsubmissions lists wasn't working. I've fixed this and sent again invitations to everybody. Sorry for that. Alternatively, it's also possible to join the mailing list from https://lists.opencsw.org/mailman/listinfo/pkgsubmissions . Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Mon Feb 15 09:43:47 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 15 Feb 2010 09:43:47 +0100 Subject: [csw-maintainers] CSWoldap In-Reply-To: <940F857E6596B84BAFD05DBA869276E234B3225C7C@CON-EX-001.connectis.local> 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> Message-ID: <317CA910-083A-48E2-83A8-012B4BB857CE@opencsw.org> Hi David, Am 11.02.2010 um 14:26 schrieb Mantock David: > I made the following packages yesterday and I have now loaded them > in to build farm NFS share: /home/testing > > openldap_client-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz > openldap_devel-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz > openldap_rt-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz > openldap-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz > > They are available for testing on http://mirror.opencsw.org/opencsw/testing > > Apart from making x86 versions is there something else I should do? The following things need to be either verified or implemented in the package: - Check that the package works (start server, stop server on Solaris 8/9 RC and 10 SMF) - Check functionality (create database, populate, access via SSL and Kerberos) - Check upgrade path from existing OpenLDAP package (especially relocation of database from /opt/csw/var to /var/opt/csw), conversion of database from BDB 4.4 to 4.7. If the upgrade is not straight-forward it needs to be documents. Feel free to give the issues a try. I have set up a wiki page to track progress and note open issues at Please register yourself and apply for write access on the wiki itself, Peter will enable your account. Best regards -- Dago From dam at opencsw.org Mon Feb 15 11:58:06 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 15 Feb 2010 11:58:06 +0100 Subject: [csw-maintainers] Problem with gcc4 Message-ID: <18137884-9DEE-473F-85EA-E521C01BDCF4@opencsw.org> Hi, I just had an IRC session about a failing gcc4 on Solaris 10 on 32 bit. As we currently use isaexec to branch between Solaris 8/32 and Solaris 10/64 the wrong feature include i386-pc-solaris2.8 is pulled in Solaris 10/32. Is there an easy way to fix this or do we need to provide an additional package for Solaris 10 on i386? (Please reply to all as I cc'ed the reporting user). Best regards -- Dago From dam at opencsw.org Mon Feb 15 17:02:54 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 15 Feb 2010 17:02:54 +0100 Subject: [csw-maintainers] Update: project-specific experimental catalog In-Reply-To: References: Message-ID: Hi, Am 01.02.2010 um 17:58 schrieb Dagobert Michelsen: > the first version of the experimental catalog is there made from > the packages in > /home/experimental/ > Locally the catalogs are > /export/mirror/opencsw/experimental/ > For starters I have made a project for each maintainer and > copied his packages from /home/testing into it. The catalogs > are an overlay over current, so the ugly install-stuff should > be much smoother now. The webpage can be accessed at > > The catalog generation still runs, please make sure the catalog > you are looking for has been generated: > There have been some minor updates to experimental, most notable there are now timestamps on the webpage to indicate when the catalogs have last been updated and the catalogs are now rebuild every five minutes. Initially I have created a project for every user to keep his stuff, please take everyone care that testing will be evacuated in the near future and catalog building will no longer be done on testing/. Best regards -- Dago From rupert at opencsw.org Mon Feb 15 19:43:44 2010 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 15 Feb 2010 19:43:44 +0100 Subject: [csw-maintainers] CSWoldap In-Reply-To: <317CA910-083A-48E2-83A8-012B4BB857CE@opencsw.org> 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> Message-ID: <6af4271002151043j334d92bck1ae23553f2f4b078@mail.gmail.com> On Mon, Feb 15, 2010 at 09:43, Dagobert Michelsen wrote: > Hi David, > > Am 11.02.2010 um 14:26 schrieb Mantock David: > >> I made the following packages yesterday and I have now loaded them in to >> build farm NFS share: /home/testing >> >> openldap_client-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz >> openldap_devel-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz >> openldap_rt-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz >> openldap-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz >> >> They are available for testing on >> http://mirror.opencsw.org/opencsw/testing >> >> Apart from making x86 versions is there something else I should do? >> > > The following things need to be either verified or implemented in the > package: > > - Check that the package works (start server, stop server on Solaris 8/9 RC > and 10 SMF) > - Check functionality (create database, populate, access via SSL and > Kerberos) > - Check upgrade path from existing OpenLDAP package (especially relocation > of database > from /opt/csw/var to /var/opt/csw), conversion of database from BDB 4.4 to > 4.7. > If the upgrade is not straight-forward it needs to be documents. > how can we avoid the database move to /var/opt ? rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ihsan at opencsw.org Mon Feb 15 21:55:08 2010 From: ihsan at opencsw.org (Ihsan Dogan) Date: Mon, 15 Feb 2010 21:55:08 +0100 Subject: [csw-maintainers] /testing spamassassin, bind, dhcp, dnstop In-Reply-To: <625385e31001261327k31719e1bo2bd90963eb99a3d2@mail.gmail.com> References: <625385e31001261327k31719e1bo2bd90963eb99a3d2@mail.gmail.com> Message-ID: <4B79B4AC.9050204@opencsw.org> Hello Peter, Am 26.01.10 22:27, schrieb Peter Bonivart: > - dnstop 20090128, a top-like utility for DNS servers. I've tested it quickly on x86. Works fine, but the man page seems to broken. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From bonivart at opencsw.org Mon Feb 15 22:03:34 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 15 Feb 2010 22:03:34 +0100 Subject: [csw-maintainers] /testing spamassassin, bind, dhcp, dnstop In-Reply-To: <4B79B4AC.9050204@opencsw.org> References: <625385e31001261327k31719e1bo2bd90963eb99a3d2@mail.gmail.com> <4B79B4AC.9050204@opencsw.org> Message-ID: <625385e31002151303g47f8dafdp14d2805078188af2@mail.gmail.com> On Mon, Feb 15, 2010 at 9:55 PM, Ihsan Dogan wrote: > Hello Peter, > > Am 26.01.10 22:27, schrieb Peter Bonivart: > >> - dnstop 20090128, a top-like utility for DNS servers. > > I've tested it quickly on x86. Works fine, but the man page seems to broken. Yes, the formatting is broken, it's just copied from the source. Anyone has any ideas how to get it into a proper man page? -- /peter From dam at opencsw.org Mon Feb 15 22:15:33 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 15 Feb 2010 22:15:33 +0100 Subject: [csw-maintainers] CSWoldap In-Reply-To: <6af4271002151043j334d92bck1ae23553f2f4b078@mail.gmail.com> 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> Message-ID: Hi Rupert, Am 15.02.2010 um 19:43 schrieb rupert THURNER: > On Mon, Feb 15, 2010 at 09:43, Dagobert Michelsen > wrote: >> Hi David, >> >> Am 11.02.2010 um 14:26 schrieb Mantock David: >> I made the following packages yesterday and I have now loaded them >> in to build farm NFS share: /home/testing >> >> openldap_client-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz >> openldap_devel-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz >> openldap_rt-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz >> openldap-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz >> >> They are available for testing on http://mirror.opencsw.org/opencsw/testing >> >> Apart from making x86 versions is there something else I should do? >> >> The following things need to be either verified or implemented in >> the package: >> >> - Check that the package works (start server, stop server on >> Solaris 8/9 RC and 10 SMF) >> - Check functionality (create database, populate, access via SSL >> and Kerberos) >> - Check upgrade path from existing OpenLDAP package (especially >> relocation of database >> from /opt/csw/var to /var/opt/csw), conversion of database from >> BDB 4.4 to 4.7. >> If the upgrade is not straight-forward it needs to be documents. > > how can we avoid the database move to /var/opt ? Well, IIRC we wanted to move all writable data to /var/opt/csw to be more sparse-zone friendly for r/o shared /opt. The moving itself is with cswmigrateconf no big deal. Or do you have other reasons in mind to not move it? Best regards -- Dago From skayser at opencsw.org Mon Feb 15 22:20:05 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 15 Feb 2010 22:20:05 +0100 Subject: [csw-maintainers] /testing spamassassin, bind, dhcp, dnstop In-Reply-To: <625385e31002151303g47f8dafdp14d2805078188af2@mail.gmail.com> References: <625385e31001261327k31719e1bo2bd90963eb99a3d2@mail.gmail.com> <4B79B4AC.9050204@opencsw.org> <625385e31002151303g47f8dafdp14d2805078188af2@mail.gmail.com> Message-ID: <4B79BA85.9010309@opencsw.org> Peter Bonivart wrote on 15.02.2010 22:03: > On Mon, Feb 15, 2010 at 9:55 PM, Ihsan Dogan wrote: >> Am 26.01.10 22:27, schrieb Peter Bonivart: >> >>> - dnstop 20090128, a top-like utility for DNS servers. >> I've tested it quickly on x86. Works fine, but the man page seems to broken. > > Yes, the formatting is broken, it's just copied from the source. > Anyone has any ideas how to get it into a proper man page? AFAIR Solaris nroff can't handle some of the stuff that the ?roff on Linux can handle. What I used to do is to file a request with upstream to make the man page work on Solaris, format the man page on Linux, put it into $(docdir)/$(GARNAME) and provide a stub man page which pointed to this pre-formatted text file (see autossh [1] for an example). Ugly, but it did the job for a workaround. Dago recently pointed out that (besides fixing the man page) there is a simpler approach. Pre-formatted man pages can supposedly be put into /opt/csw/share/cat
and will simply be cat-ed for display (in favor of man pages coming from /opt/csw/share/man
directories). Sebastian P.S.: If such non-formatable (on Solaris) man pages can be identified by some unique characteristics this might be a good thing to implement as a check for checkpkg. [1]https://gar.svn.sf.net/svnroot/gar/csw/mgar/pkg/autossh/trunk/Makefile From dam at opencsw.org Mon Feb 15 22:27:39 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 15 Feb 2010 22:27:39 +0100 Subject: [csw-maintainers] /testing spamassassin, bind, dhcp, dnstop In-Reply-To: <4B79BA85.9010309@opencsw.org> References: <625385e31001261327k31719e1bo2bd90963eb99a3d2@mail.gmail.com> <4B79B4AC.9050204@opencsw.org> <625385e31002151303g47f8dafdp14d2805078188af2@mail.gmail.com> <4B79BA85.9010309@opencsw.org> Message-ID: <833C5939-6B10-4681-9C60-DDE23D4D6D5A@opencsw.org> Hi Sebastian, Am 15.02.2010 um 22:20 schrieb Sebastian Kayser: > Peter Bonivart wrote on 15.02.2010 22:03: >> On Mon, Feb 15, 2010 at 9:55 PM, Ihsan Dogan >> wrote: >>> Am 26.01.10 22:27, schrieb Peter Bonivart: >>> >>>> - dnstop 20090128, a top-like utility for DNS servers. >>> I've tested it quickly on x86. Works fine, but the man page seems >>> to broken. >> >> Yes, the formatting is broken, it's just copied from the source. >> Anyone has any ideas how to get it into a proper man page? > > AFAIR Solaris nroff can't handle some of the stuff that the ?roff on > Linux can handle. What I used to do is to file a request with upstream > to make the man page work on Solaris, format the man page on Linux, > put > it into $(docdir)/$(GARNAME) and provide a stub man page which pointed > to this pre-formatted text file (see autossh [1] for an example). > Ugly, > but it did the job for a workaround. > > Dago recently pointed out that (besides fixing the man page) there > is a > simpler approach. Pre-formatted man pages can supposedly be put into > /opt/csw/share/cat
and will simply be cat-ed for display (in > favor of man pages coming from /opt/csw/share/man
> directories). Of course the better way is to just learn ROFF from here and rewrite the failing macros as James pointed out. I have another candidate (GNU File) with similar Macro problems. The book is quite good. Or you can try to use "groff -man" using the "an" macro packages from here and see how they work: /opt/csw/lib/groff/site-tmac/an.tmac /opt/csw/lib/groff/site-tmac/ansun.tmac > P.S.: If such non-formatable (on Solaris) man pages can be > identified by > some unique characteristics this might be a good thing to implement > as a > check for checkpkg. I guess that will be hard as you would need a ROFF parser for that. > [1]https://gar.svn.sf.net/svnroot/gar/csw/mgar/pkg/autossh/trunk/Makefile Best regards -- Dago From bonivart at opencsw.org Mon Feb 15 23:05:44 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 15 Feb 2010 23:05:44 +0100 Subject: [csw-maintainers] /testing spamassassin, bind, dhcp, dnstop In-Reply-To: <4B79BA85.9010309@opencsw.org> References: <625385e31001261327k31719e1bo2bd90963eb99a3d2@mail.gmail.com> <4B79B4AC.9050204@opencsw.org> <625385e31002151303g47f8dafdp14d2805078188af2@mail.gmail.com> <4B79BA85.9010309@opencsw.org> Message-ID: <625385e31002151405m61536773kea6bbf01b030ba1b@mail.gmail.com> On Mon, Feb 15, 2010 at 10:20 PM, Sebastian Kayser wrote: > AFAIR Solaris nroff can't handle some of the stuff that the ?roff on > Linux can handle. What I used to do is to file a request with upstream > to make the man page work on Solaris, format the man page on Linux, put > it into $(docdir)/$(GARNAME) and provide a stub man page which pointed > to this pre-formatted text file (see autossh [1] for an example). Ugly, > but it did the job for a workaround. The man page is available in roff- and HTML-format here: http://dns.measurement-factory.com/tools/dnstop/src/ Do we know which macros are not available in Solaris so we can replace/remove them? Or can we convert from HTML to man page format in any simple way? -- /peter From skayser at opencsw.org Mon Feb 15 23:56:18 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Mon, 15 Feb 2010 23:56:18 +0100 Subject: [csw-maintainers] CSWoldap In-Reply-To: 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> Message-ID: <4B79D112.4060803@opencsw.org> Dagobert Michelsen wrote on 15.02.2010 22:15: > Am 15.02.2010 um 19:43 schrieb rupert THURNER: >> On Mon, Feb 15, 2010 at 09:43, Dagobert Michelsen wrote: >>> Am 11.02.2010 um 14:26 schrieb Mantock David: >>> I made the following packages yesterday and I have now loaded them >>> in to build farm NFS share: /home/testing >>> >>> openldap_client-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz >>> openldap_devel-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz >>> openldap_rt-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz >>> openldap-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz >>> >>> They are available for testing on http://mirror.opencsw.org/opencsw/testing >>> >>> Apart from making x86 versions is there something else I should do? >>> >>> The following things need to be either verified or implemented in >>> the package: >>> >>> - Check that the package works (start server, stop server on >>> Solaris 8/9 RC and 10 SMF) >>> - Check functionality (create database, populate, access via SSL >>> and Kerberos) >>> - Check upgrade path from existing OpenLDAP package (especially >>> relocation of database >>> from /opt/csw/var to /var/opt/csw), conversion of database from >>> BDB 4.4 to 4.7. >>> If the upgrade is not straight-forward it needs to be documents. >> how can we avoid the database move to /var/opt ? > > Well, IIRC we wanted to move all writable data to /var/opt/csw to be > more sparse-zone friendly for r/o shared /opt. The moving itself is > with cswmigrateconf no big deal. Or do you have other reasons in mind > to not move it? Rupert once posted details about the particular setup at his workplace and the constraints that come along with it [1]. I think it was the requirement to have everything under /opt/csw that they were after, I don't know whether that still holds true though. Rupert? Sebastian [1]http://lists.opencsw.org/pipermail/maintainers/2009-August/003926.html From skayser at opencsw.org Tue Feb 16 00:06:33 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 16 Feb 2010 00:06:33 +0100 Subject: [csw-maintainers] cswclassutils: location of template init scripts In-Reply-To: <20100207.14045300.4254301123@gyor.oxdrove.co.uk> References: <20100207.14045300.4254301123@gyor.oxdrove.co.uk> Message-ID: <4B79D379.3010303@opencsw.org> James Lee wrote on 07.02.2010 15:04: > On 01/02/10, 20:31:18, Philip Brown wrote regarding > [csw-maintainers] cswclassutils: location of template init scripts: > >> currently, our wiki for cswclassutils suggests the initial location >> for the init script should be > >> INITSMF = /etc/opt/csw/init.d/cswfoo > >> I think it would be better for our users, if we standardize on a >> location under /opt/csw >> For example, /opt/csw/etc/init.d > > I agree with this. I say the package should deliver to /opt/csw and > user and local data files should go in /etc/opt and /var/opt. Template > configuration files break this logic, ... James, Phil, would anyone mind explaining to me what exactly you guys mean by "template configuration files"? I understood Phil's remark about /etc/opt/csw/init.d, but if there is more to it, some further examples might be helpful. > . the package might also lay out directories in /etc/opt and /var/opt. ? Sebastian From bwalton at opencsw.org Tue Feb 16 00:38:01 2010 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 15 Feb 2010 18:38:01 -0500 Subject: [csw-maintainers] git 1.7.0 up for test drive Message-ID: <1266276829-sup-1981@ntdws12.chass.utoronto.ca> Hi All, I've placed packages for git 1.7.0 (released 2010.02.13) in experimental/bwalton. My initial testing is positive, but I'd appreciate feedback from anyone else that uses the packages (especially the parts like the cvs bridge that I don't use myself). There are some behaviour changes in this release that may (or may not) interest you. For information, see the release announcement[1]. You can get it via the (awesome, btw) new experiemtnal/project catalogs with: pkgutil -t http://mirror.opencsw.org/opencsw/experimental/bwalton -i CSWgit Feedback welcome. Thanks -Ben [1] http://marc.info/?l=git&m=126602427512194&w=2 -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dam at opencsw.org Tue Feb 16 09:33:27 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 16 Feb 2010 09:33:27 +0100 Subject: [csw-maintainers] /testing spamassassin, bind, dhcp, dnstop In-Reply-To: <625385e31002151405m61536773kea6bbf01b030ba1b@mail.gmail.com> References: <625385e31001261327k31719e1bo2bd90963eb99a3d2@mail.gmail.com> <4B79B4AC.9050204@opencsw.org> <625385e31002151303g47f8dafdp14d2805078188af2@mail.gmail.com> <4B79BA85.9010309@opencsw.org> <625385e31002151405m61536773kea6bbf01b030ba1b@mail.gmail.com> Message-ID: <273F3E70-15FF-40B6-B255-7E47372763D9@opencsw.org> Hi Peter, Am 15.02.2010 um 23:05 schrieb Peter Bonivart: > On Mon, Feb 15, 2010 at 10:20 PM, Sebastian Kayser > wrote: >> AFAIR Solaris nroff can't handle some of the stuff that the ?roff on >> Linux can handle. What I used to do is to file a request with >> upstream >> to make the man page work on Solaris, format the man page on Linux, >> put >> it into $(docdir)/$(GARNAME) and provide a stub man page which >> pointed >> to this pre-formatted text file (see autossh [1] for an example). >> Ugly, >> but it did the job for a workaround. > > The man page is available in roff- and HTML-format here: > http://dns.measurement-factory.com/tools/dnstop/src/ > > Do we know which macros are not available in Solaris so we can > replace/remove them? There are quite a lot. It usually ends up in rewriting the manpage. Does it format correctly with /opt/csw/bin/gnroff -man ? Then you could produce plaintext during package creation and produce catman without much hassle. Unless, of course, you prefer to learn ROFF ;-) > Or can we convert from HTML to man page format in any simple way? At least I don't know a solution with reasonable results. Best regards -- Dago From bonivart at opencsw.org Tue Feb 16 09:53:34 2010 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 16 Feb 2010 09:53:34 +0100 Subject: [csw-maintainers] /testing spamassassin, bind, dhcp, dnstop In-Reply-To: <273F3E70-15FF-40B6-B255-7E47372763D9@opencsw.org> References: <625385e31001261327k31719e1bo2bd90963eb99a3d2@mail.gmail.com> <4B79B4AC.9050204@opencsw.org> <625385e31002151303g47f8dafdp14d2805078188af2@mail.gmail.com> <4B79BA85.9010309@opencsw.org> <625385e31002151405m61536773kea6bbf01b030ba1b@mail.gmail.com> <273F3E70-15FF-40B6-B255-7E47372763D9@opencsw.org> Message-ID: <625385e31002160053y792724f8vcb1714286aec65c2@mail.gmail.com> On Tue, Feb 16, 2010 at 9:33 AM, Dagobert Michelsen wrote: >> Or can we convert from HTML to man page format in any simple way? > > At least I don't know a solution with reasonable results. It's a pretty short and simple man page. I know POD and there's pod2man to convert. I may go that way (to avoid learning new stuff ;-). By the way, dnstop was just released so I will file a bug to myself about this so it won't be forgotten. Thanks for the help. -- /peter From james at opencsw.org Tue Feb 16 10:35:51 2010 From: james at opencsw.org (James Lee) Date: Tue, 16 Feb 2010 09:35:51 GMT Subject: [csw-maintainers] cswclassutils: location of template init scripts In-Reply-To: <4B79D379.3010303@opencsw.org> References: <20100207.14045300.4254301123@gyor.oxdrove.co.uk> <4B79D379.3010303@opencsw.org> Message-ID: <20100216.9355100.1823541554@gyor.oxdrove.co.uk> On 15/02/10, 23:06:33, Sebastian Kayser wrote regarding Re: [csw-maintainers] cswclassutils: location of template init scripts: > James, Phil, would anyone mind explaining to me what exactly you guys > mean by "template configuration files"? Eg: /opt/csw/etc/*.CSW /etc/opt/csw/*.CSW James. From ellson at opencsw.org Tue Feb 16 19:13:41 2010 From: ellson at opencsw.org (John Ellson) Date: Tue, 16 Feb 2010 13:13:41 -0500 Subject: [csw-maintainers] problems linking to libs with X11 dependencies Message-ID: <4B7AE055.1020704@opencsw.org> I having problems rebuilding the graphviz plugins that use -lgs and -lgd because of an unresolved symbol in /lib/libX11.so.4, but I don't understand why /lib/libX11.so.4 is being pulled in? I think this is a new problem because graphviz built with the gd plugin a few weeks ago. The configure test looks like this: conftest: conftest.c /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -xO3 -xarch=v8 -I/opt/csw/X11/include -I/opt/csw/include -xarch=v8 -L/opt/csw/X11/lib -L/opt/csw/lib conftest.c -lgs -ldl -lm and conftest.c contains: int main () { return main (); ; return 0; } This fails on build8s with: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -xO3 -xarch=v8 -I/opt/csw/X11/include -I/opt/csw/include -xarch=v8 -L/opt/csw/X11/lib -L/opt/csw/lib conftest.c -lgs -ldl -lm "conftest.c", line 5: warning: statement not reached Undefined first referenced symbol in file XSolarisIASetProcessInfo /lib/libX11.so.4 ld: fatal: Symbol referencing errors. No output written to conftest Help please? John From phil at bolthole.com Tue Feb 16 21:56:31 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 16 Feb 2010 12:56:31 -0800 Subject: [csw-maintainers] problems linking to libs with X11 dependencies In-Reply-To: <4B7AE055.1020704@opencsw.org> References: <4B7AE055.1020704@opencsw.org> Message-ID: On Tue, Feb 16, 2010 at 10:13 AM, John Ellson wrote: > I having problems rebuilding the graphviz plugins that use -lgs and -lgd > because of an unresolved symbol in /lib/libX11.so.4, but I don't understand > why /lib/libX11.so.4 is being pulled in? ? I think this is a new problem > because graphviz built with the gd plugin a few weeks ago. >... I would guess you're correct about that. > This fails on build8s with: > > ? ?/opt/studio/SOS11/SUNWspro/bin/cc -o conftest -xO3 -xarch=v8 > -I/opt/csw/X11/include -I/opt/csw/include -xarch=v8 -L/opt/csw/X11/lib > -L/opt/csw/lib conftest.c -lgs ?-ldl -lm > ? ?"conftest.c", line 5: warning: statement not reached > ? ?Undefined ? ? ? ? ? ? ? ? ? ? ? first referenced > ? ? ? ? symbol ? ? ? ? ? ? ? ? ? ? ? ? ? ? in file > ? ?XSolarisIASetProcessInfo ? ? ? ? ? ?/lib/libX11.so.4 > ? ?ld: fatal: Symbol referencing errors. No output written to conftest well, there's two things going on there: 1. something "hidden" would appear to be linking against libX11 2. since it is, and it appears to require the newer version, you'll have to force -R/opt/csw/X11/lib, as well as that -L line. From hson at opencsw.org Tue Feb 16 22:30:59 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Tue, 16 Feb 2010 22:30:59 +0100 Subject: [csw-maintainers] problems linking to libs with X11 dependencies In-Reply-To: <4B7AE055.1020704@opencsw.org> References: <4B7AE055.1020704@opencsw.org> Message-ID: <4B7B0E93.80602@opencsw.org> John Ellson wrote: > I having problems rebuilding the graphviz plugins that use -lgs and -lgd > because of an unresolved symbol in /lib/libX11.so.4, but I don't > understand why /lib/libX11.so.4 is being pulled in? I think this is a > new problem because graphviz built with the gd plugin a few weeks ago. Since the problem is when linking with gs, it's a new problem (unless you have built with gs previously). The problem is that libgs.so is linked with libX11.so.4 which is the openwin version and if you link with that lib it needs libXext.so.0 from the same place. But when linking with CSW X11 there exists a CSW version of that lib that doesn't contain XSolarisIASetProcessInfo. You can either wait for James to rebuild ghostscript or try to link with /usr/openwin/lib/libXext.so. If you want to try the second option, I've sometimes successfully managed to do it by adding the following to my Makefile. EXTRA_LINKER_FLAGS = /usr/openwin/lib/libXext.so Others have solved it by adding EXTRA_LDFLAGS = /usr/openwin/lib/libXext.so From william at wbonnet.net Wed Feb 17 00:42:10 2010 From: william at wbonnet.net (William Bonnet) Date: Wed, 17 Feb 2010 00:42:10 +0100 Subject: [csw-maintainers] New web site mockup available for feedbacks Message-ID: <4B7B2D52.1010503@wbonnet.net> Hi, We are pleased to announce that the mockup of the new web site is online and ready for a first internal review and feedback session. The URL of the mockup is http://www-mockup.opencsw.org Two pages have been added to the wiki, the first one : http://wiki.opencsw.org/new-website keeps track of the "Todo" things. There three priorities defined. Things to be done before switching the web site, things to be done quickly after, and things to be done later :) The second page is http://wiki.opencsw.org/new-website-comments Please use this page to send your feedbacks. Things to be fixed or done will be identified from the feedback list, and added to task list. In the Todos please already notice that the logo is not the final one, and the list of recently updated packages is not yet online. All this will be online in the next days, but there are still a few things to fix before ;) The statistics, including the number of active maintainers, etc are live data from the database and are updated on a daily basis. So if something looks strange (in the numbers) please report it :) Thanks in advance your comments 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 Wed Feb 17 01:54:20 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Wed, 17 Feb 2010 01:54:20 +0100 Subject: [csw-maintainers] Strange checkpkg override behavior Message-ID: <4B7B3E3C.40002@opencsw.org> When trying to package ilmbase I get some errors regarding symbols-not-found. But all my attempts to override them fails on the buildfarm, however on my own build machine I have no problem. The error I get is: # Tags reported by missing symbols module CSWilmbase: symbol-not-found libIex.so.2.0.2 CSWilmbase: symbol-not-found libHalf.so.2.0.2 CSWilmbase: symbol-not-found libImath.so.6.0.0 CSWilmbase: symbol-not-found libIlmThread.so.6.0.0 CSWilmbase: symbol-not-found libImath.so.2.0.2 The reported error tags are: * CheckpkgTag('CSWilmbase', 'symbol-not-found', 'libIex.so.2.0.2', ...) * CheckpkgTag('CSWilmbase', 'symbol-not-found', 'libHalf.so.2.0.2', ...) * CheckpkgTag('CSWilmbase', 'symbol-not-found', 'libImath.so.6.0.0', ...) * CheckpkgTag('CSWilmbase', 'symbol-not-found', 'libIlmThread.so.6.0.0', ...) * CheckpkgTag('CSWilmbase', 'symbol-not-found', 'libImath.so.2.0.2', ...) I've tried using several different syntaxes for the override CHECKPKG_OVERRIDES += CSWilmbase|symbol-not-found|libIex.so.2.0.2 CHECKPKG_OVERRIDES += CSWilmbase|symbol-not-found|libHalf.so.2.0.2 CHECKPKG_OVERRIDES += CSWilmbase|symbol-not-found|libImath.so.2.0.2 CHECKPKG_OVERRIDES += CSWilmbase|symbol-not-found|libIlmThread.so.6.0.0 CHECKPKG_OVERRIDES += CSWilmbase|symbol-not-found|libImath.so.6.0.0 CHECKPKG_OVERRIDES += CSWilmbase|symbol-not-found CHECKPKG_OVERRIDES += symbol-not-found CHECKPKG_OVERRIDES_CSWilmbase += symbol-not-found|libIex.so.2.0.2 CHECKPKG_OVERRIDES_CSWilmbase += symbol-not-found|libHalf.so.2.0.2 CHECKPKG_OVERRIDES_CSWilmbase += symbol-not-found|libImath.so.2.0.2 CHECKPKG_OVERRIDES_CSWilmbase += symbol-not-found|libIlmThread.so.6.0.0 CHECKPKG_OVERRIDES_CSWilmbase += symbol-not-found|libImath.so.6.0.0 But none of them works for some reason. Any clue on what might be the problem. From maciej at opencsw.org Wed Feb 17 09:17:30 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 17 Feb 2010 08:17:30 +0000 Subject: [csw-maintainers] Strange checkpkg override behavior In-Reply-To: <4B7B3E3C.40002@opencsw.org> References: <4B7B3E3C.40002@opencsw.org> Message-ID: On Wed, Feb 17, 2010 at 12:54 AM, Roger H?kansson wrote: > When trying to package ilmbase I get some errors regarding > symbols-not-found. > But all my attempts to override them fails on the buildfarm, however on my > own build machine I have no problem. > I've tried using several different syntaxes for the override (....) > CHECKPKG_OVERRIDES_CSWilmbase += symbol-not-found|libIex.so.2.0.2 > CHECKPKG_OVERRIDES_CSWilmbase += symbol-not-found|libHalf.so.2.0.2 > CHECKPKG_OVERRIDES_CSWilmbase += symbol-not-found|libImath.so.2.0.2 > CHECKPKG_OVERRIDES_CSWilmbase += symbol-not-found|libIlmThread.so.6.0.0 > CHECKPKG_OVERRIDES_CSWilmbase += symbol-not-found|libImath.so.6.0.0 This one is a good syntax. Otherwise you could use "CHECKPKG_OVERRIDES =", but then it would apply to all the packages within the build description, not just CSWilmbase. As far as debugging is concerned: could you show show the resulting override file? Is it created, and is it in the right directory? It should be in /opt/csw/share/checkpkg/overrides/ilmbase in the package and it should contain lines such as "CSWilmbase: symbol-not-found libIex.so.2.0.2". Maciej From hson at opencsw.org Wed Feb 17 09:40:11 2010 From: hson at opencsw.org (=?UTF-8?B?Um9nZXIgSMOla2Fuc3Nvbg==?=) Date: Wed, 17 Feb 2010 09:40:11 +0100 Subject: [csw-maintainers] Strange checkpkg override behavior In-Reply-To: References: <4B7B3E3C.40002@opencsw.org> Message-ID: <4B7BAB6B.5050203@opencsw.org> Maciej (Matchek) Blizinski wrote: > As far as debugging is concerned: could you show show the resulting > override file? Is it created, and is it in the right directory? It > should be in /opt/csw/share/checkpkg/overrides/ilmbase in the package > and it should contain lines such as "CSWilmbase: symbol-not-found > libIex.so.2.0.2". In my last attempt I used CHECKPKG_OVERRIDES += CSWilmbase|symbol-not-found|libIex.so.2.0.2 CHECKPKG_OVERRIDES += CSWilmbase|symbol-not-found|libHalf.so.2.0.2 CHECKPKG_OVERRIDES += CSWilmbase|symbol-not-found|libImath.so.2.0.2 CHECKPKG_OVERRIDES += CSWilmbase|symbol-not-found|libIlmThread.so.6.0.0 CHECKPKG_OVERRIDES += CSWilmbase|symbol-not-found|libImath.so.6.0.0 Using that the override file has this content CSWilmbase: CSWilmbase symbol-not-found libIex.so.2.0.2 CSWilmbase: CSWilmbase symbol-not-found libHalf.so.2.0.2 CSWilmbase: CSWilmbase symbol-not-found libImath.so.2.0.2 CSWilmbase: CSWilmbase symbol-not-found libIlmThread.so.6.0.0 CSWilmbase: CSWilmbase symbol-not-found libImath.so.6.0.0 From maciej at opencsw.org Wed Feb 17 09:50:44 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 17 Feb 2010 08:50:44 +0000 Subject: [csw-maintainers] Strange checkpkg override behavior In-Reply-To: <4B7BAB6B.5050203@opencsw.org> References: <4B7B3E3C.40002@opencsw.org> <4B7BAB6B.5050203@opencsw.org> Message-ID: On Wed, Feb 17, 2010 at 8:40 AM, Roger H?kansson wrote: > Maciej (Matchek) Blizinski wrote: >> >> As far as debugging is concerned: could you show show the resulting >> override file? ?Is it created, and is it in the right directory? ?It >> should be in /opt/csw/share/checkpkg/overrides/ilmbase in the package >> and it should contain lines such as "CSWilmbase: symbol-not-found >> libIex.so.2.0.2". > > In my last attempt I used > CHECKPKG_OVERRIDES += CSWilmbase|symbol-not-found|libIex.so.2.0.2 > CHECKPKG_OVERRIDES += CSWilmbase|symbol-not-found|libHalf.so.2.0.2 > CHECKPKG_OVERRIDES += CSWilmbase|symbol-not-found|libImath.so.2.0.2 > CHECKPKG_OVERRIDES += CSWilmbase|symbol-not-found|libIlmThread.so.6.0.0 > CHECKPKG_OVERRIDES += CSWilmbase|symbol-not-found|libImath.so.6.0.0 > > Using that the override file has this content > CSWilmbase: CSWilmbase symbol-not-found libIex.so.2.0.2 > CSWilmbase: CSWilmbase symbol-not-found libHalf.so.2.0.2 > CSWilmbase: CSWilmbase symbol-not-found libImath.so.2.0.2 > CSWilmbase: CSWilmbase symbol-not-found libIlmThread.so.6.0.0 > CSWilmbase: CSWilmbase symbol-not-found libImath.so.6.0.0 This won't work, because according to the grammar it'll override "CSWilmbase" errors, while the ones thrown are "symbol-not-found". Try this: CHECKPKG_OVERRIDES +=symbol-not-found|libIex.so.2.0.2 From maciej at opencsw.org Thu Feb 18 14:35:14 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 18 Feb 2010 13:35:14 +0000 Subject: [csw-maintainers] [GAR] checkpkg statistics collection separation merged into v2 Message-ID: I've recently developed a new feature for checkpkg, in which the checking functions only interact with previously saved package statistics. Since it's a fairly large change[1], I'm announcing it here. If you're interested in the internals of the change, see the wiki page[2]. Here's how a an individual check looks like right now: def CatalognameLowercase(pkg_data, debug): errors = [] pkgname = pkg_data["basic_stats"]["pkgname"] catalogname = pkg_data["basic_stats"]["catalogname"] if catalogname != catalogname.lower(): errors.append(checkpkg.CheckpkgTag( pkgname, "catalogname-not-lowercase")) if not re.match(r"^\w+$", catalogname): errors.append(checkpkg.CheckpkgTag( pkgname, "catalogname-is-not-a-simple-word")) return errors I'll keep working on reducing the amount of code necessary to develop new individual checks. Another recently added feature is that when checkpkg detects any problems, it'll print override statements which you can copy/paste to the GAR build file if you decide that they're false positives. In the meantime, if you run into any problems with checkpkg, please let me know. Maciej [1] https://sourceforge.net/apps/trac/gar/changeset/8650 [2] http://wiki.opencsw.org/checkpkg#toc17 From maciej at opencsw.org Sat Feb 20 09:09:58 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 20 Feb 2010 08:09:58 +0000 Subject: [csw-maintainers] OpenCSW listed on Subversion's binary packages page Message-ID: I've noticed that Suvbversion webpage has a subpage[1] with a list of binary packages for different operating systems, on which we weren't listed. I contacted[2] their dev mailing list, and got a reply that I'm welcome to update the page. They have a repository with the HTML code, so they pointed me at it and suggested submitting a patch. I wrote one[3], and sent it. They did their tweaks and applied it. Voila! We're now listed there, which means a little bit more traffic to our web site[4], and potentially -- more users. Maciej [1] http://subversion.apache.org/packages.html [2] http://tinyurl.com/yljo3op [3] http://www.opencsw.org/~maciej/opencsw-subversion-package-info.patch [4] Can we move to the new version soon? From bwalton at opencsw.org Sat Feb 20 14:16:04 2010 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 20 Feb 2010 08:16:04 -0500 Subject: [csw-maintainers] OpenCSW listed on Subversion's binary packages page In-Reply-To: References: Message-ID: <1266671680-sup-427@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Sat Feb 20 03:09:58 -0500 2010: > I'm welcome to update the page. They have a repository with the HTML > code, so they pointed me at it and suggested submitting a patch. I > wrote one[3], and sent it. They did their tweaks and applied it. I did the same with Git[1], but it was never picked up. Maybe I should bump them again... > Voila! We're now listed there, which means a little bit more traffic > to our web site[4], and potentially -- more users. Nice! Thanks -Ben [1] http://git-scm.com/download -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 -------------- 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 Sat Feb 20 15:40:34 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 20 Feb 2010 14:40:34 +0000 Subject: [csw-maintainers] OpenCSW listed on Subversion's binary packages page In-Reply-To: <1266671680-sup-427@ntdws12.chass.utoronto.ca> References: <1266671680-sup-427@ntdws12.chass.utoronto.ca> Message-ID: On Sat, Feb 20, 2010 at 1:16 PM, Ben Walton wrote: > Excerpts from Maciej (Matchek) Blizinski's message of Sat Feb 20 03:09:58 -0500 2010: > >> I'm welcome to update the page. ?They have a repository with the HTML >> code, so they pointed me at it and suggested submitting a patch. ?I >> wrote one[3], and sent it. ?They did their tweaks and applied it. > > I did the same with Git[1], but it was never picked up. ?Maybe I > should bump them again... Good idea! One of things to think about is that other sites pointing at opencsw.org will boost our PageRank. Current search results for "solaris packages" are just depressing. From pfelecan at opencsw.org Sat Feb 20 18:14:07 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 20 Feb 2010 18:14:07 +0100 Subject: [csw-maintainers] complex trac issue Message-ID: I have a complex trac issue and I don't think that is only one package which is in question (this multiplicity makes reporting difficult with mantis). On January 17th I updated one of my servers running Solaris 10 U8, x86. Among the updated packages were: - 1.6.6 svn - 2.6.4 python - 1.7.1 pysvn - 1.6.6 ap2svn Since then, the: trac-admin environment resync doesn't work any more and the error message is: Command failed: Unsupported version control system "svn": "No module named svn" I think that there is an issue of version synchronization between all this and probably something erroneous about pysvn (on which the current trac is depending) and pythonsvn (which a new instance but the current trac doesn't depend on); pysvn has a strange description string "python" while pythonsvn has the expected description: "Subversion Python Language Binding". In the mantis pages of trac there is some reference on pythonsvn replacing pysvn and a new trac put in testing at the end of the past year. Can the corresponding maintainers for the above mentioned packages look into this please? I'm willing to help... -- Peter From pfelecan at opencsw.org Sat Feb 20 18:17:01 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 20 Feb 2010 18:17:01 +0100 Subject: [csw-maintainers] OpenCSW listed on Subversion's binary packages page In-Reply-To: (Maciej Blizinski's message of "Sat, 20 Feb 2010 08:09:58 +0000") References: Message-ID: "Maciej (Matchek) Blizinski" writes: > Voila! We're now listed there, which means a little bit more traffic > to our web site[4], and potentially -- more users. This is something that all the maintainer should try. I've done it for all my packages but it's not always successful... something as 40% of positive answers. -- Peter From maciej at opencsw.org Sat Feb 20 19:26:50 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 20 Feb 2010 18:26:50 +0000 Subject: [csw-maintainers] complex trac issue In-Reply-To: References: Message-ID: On Sat, Feb 20, 2010 at 5:14 PM, Peter FELECAN wrote: > ? ? ? ?Command failed: Unsupported version control system "svn": "No > ? ? ? ?module named svn" This problem stems from the rename of pysvn to python svn -- the updated track package hasn't been released yet. Looks like we lost trac of this problem. The updated package is in experimental, I've just submitted it for release: http://lists.opencsw.org/pipermail/pkgsubmissions/2010-February/000100.html Maciej From pfelecan at opencsw.org Sat Feb 20 20:06:57 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 20 Feb 2010 20:06:57 +0100 Subject: [csw-maintainers] complex trac issue In-Reply-To: (Maciej Blizinski's message of "Sat, 20 Feb 2010 18:26:50 +0000") References: Message-ID: "Maciej (Matchek) Blizinski" writes: > On Sat, Feb 20, 2010 at 5:14 PM, Peter FELECAN wrote: >> ? ? ? ?Command failed: Unsupported version control system "svn": "No >> ? ? ? ?module named svn" > > This problem stems from the rename of pysvn to python svn -- the > updated track package hasn't been released yet. Looks like we lost > trac of this problem. The updated package is in experimental, I've > just submitted it for release: > > http://lists.opencsw.org/pipermail/pkgsubmissions/2010-February/000100.html I will test when it's released. However, I do not understand: you release a January 30th version when in testing there is a February 2nd version. -- Peter From maciej at opencsw.org Sat Feb 20 23:05:23 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 20 Feb 2010 22:05:23 +0000 Subject: [csw-maintainers] complex trac issue In-Reply-To: References: Message-ID: On Sat, Feb 20, 2010 at 7:06 PM, Peter FELECAN wrote: > I will test when it's released. However, I do not understand: you > release a January 30th version when in testing there is a February 2nd > version. I'm sending the one I've built. I'm unsure about the others, for instance there are ones that are not arch=all, and there's more than one trac version in testing right now. I feel safer sending the one I've built myself. Maciej From pfelecan at opencsw.org Sun Feb 21 10:02:29 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 21 Feb 2010 10:02:29 +0100 Subject: [csw-maintainers] complex trac issue In-Reply-To: (Maciej Blizinski's message of "Sat, 20 Feb 2010 22:05:23 +0000") References: Message-ID: "Maciej (Matchek) Blizinski" writes: > On Sat, Feb 20, 2010 at 7:06 PM, Peter FELECAN wrote: >> I will test when it's released. However, I do not understand: you >> release a January 30th version when in testing there is a February 2nd >> version. > > I'm sending the one I've built. I'm unsure about the others, for > instance there are ones that are not arch=all, and there's more than > one trac version in testing right now. I feel safer sending the one > I've built myself. I really appreciate your effort. However, can you clarify something for me: who's the maintainer of trac package? -- Peter From maciej at opencsw.org Sun Feb 21 13:55:41 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 21 Feb 2010 12:55:41 +0000 Subject: [csw-maintainers] A guy asks what's the best source of Solaris packages Message-ID: http://serverfault.com/questions/63267/what-is-the-best-source-for-solaris-packages Let's vote the best answer up! :-) Maciej From dam at opencsw.org Sun Feb 21 16:29:52 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 21 Feb 2010 16:29:52 +0100 Subject: [csw-maintainers] complex trac issue In-Reply-To: References: Message-ID: Hi Peter, Am 21.02.2010 um 10:02 schrieb Peter FELECAN: > "Maciej (Matchek) Blizinski" writes: >> On Sat, Feb 20, 2010 at 7:06 PM, Peter FELECAN wrote: >>> I will test when it's released. However, I do not understand: you >>> release a January 30th version when in testing there is a February 2nd >>> version. >> >> I'm sending the one I've built. I'm unsure about the others, for >> instance there are ones that are not arch=all, and there's more than >> one trac version in testing right now. I feel safer sending the one >> I've built myself. > > I really appreciate your effort. However, can you clarify something for > me: who's the maintainer of trac package? Rupert maintains it, but he pointed out that he is quite busy at the moment so Maciej did a respin for you as a courtesy :-) Best regards -- Dago From pfelecan at opencsw.org Sun Feb 21 17:19:03 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 21 Feb 2010 17:19:03 +0100 Subject: [csw-maintainers] complex trac issue In-Reply-To: (Dagobert Michelsen's message of "Sun, 21 Feb 2010 16:29:52 +0100") References: Message-ID: Dagobert Michelsen writes: > Hi Peter, > > Am 21.02.2010 um 10:02 schrieb Peter FELECAN: >> "Maciej (Matchek) Blizinski" writes: >>> On Sat, Feb 20, 2010 at 7:06 PM, Peter FELECAN wrote: >>>> I will test when it's released. However, I do not understand: you >>>> release a January 30th version when in testing there is a February 2nd >>>> version. >>> >>> I'm sending the one I've built. I'm unsure about the others, for >>> instance there are ones that are not arch=all, and there's more than >>> one trac version in testing right now. I feel safer sending the one >>> I've built myself. >> >> I really appreciate your effort. However, can you clarify something for >> me: who's the maintainer of trac package? > > Rupert maintains it, but he pointed out that he is quite busy at the moment > so Maciej did a respin for you as a courtesy :-) Nice. Thank you. Now, I'm waiting for the courtesy of the release manager... -- Peter From david.mantock at gmx.ch Mon Feb 15 19:57:05 2010 From: david.mantock at gmx.ch (David Mantock) Date: Mon, 15 Feb 2010 19:57:05 +0100 Subject: [csw-maintainers] CSWoldap In-Reply-To: <317CA910-083A-48E2-83A8-012B4BB857CE@opencsw.org> 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> Message-ID: Hi Dago Thanks for that. I will be re-starting from scratch to make sure there are no dependency errors and then I will proceed to go through these checks. Cheers, David -------------------------------------------------- From: "Dagobert Michelsen" Sent: Monday, February 15, 2010 9:43 AM To: "List for OpenCSW maintainers" Subject: Re: [csw-maintainers] CSWoldap > Hi David, > > Am 11.02.2010 um 14:26 schrieb Mantock David: >> I made the following packages yesterday and I have now loaded them in to >> build farm NFS share: /home/testing >> >> openldap_client-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz >> openldap_devel-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz >> openldap_rt-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz >> openldap-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz >> >> They are available for testing on >> http://mirror.opencsw.org/opencsw/testing >> >> Apart from making x86 versions is there something else I should do? > > The following things need to be either verified or implemented in the > package: > > - Check that the package works (start server, stop server on Solaris 8/9 > RC and 10 SMF) > - Check functionality (create database, populate, access via SSL and > Kerberos) > - Check upgrade path from existing OpenLDAP package (especially > relocation of database > from /opt/csw/var to /var/opt/csw), conversion of database from BDB 4.4 > to 4.7. > If the upgrade is not straight-forward it needs to be documents. > > Feel free to give the issues a try. I have set up a wiki page to track > progress > and note open issues at > > Please register yourself and apply for write access on the wiki itself, > Peter > will enable your account. > > > 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 david.mantock at gmx.ch Sat Feb 20 16:41:32 2010 From: david.mantock at gmx.ch (David Mantock) Date: Sat, 20 Feb 2010 16:41:32 +0100 Subject: [csw-maintainers] CSWoldap In-Reply-To: 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> Message-ID: Have a missed something? When I logged in to build10x I couldn't run gmake commands. I need to do part of the build there for x86/x64 stuff. -------------------------------------------------- From: "Dagobert Michelsen" Sent: Monday, February 15, 2010 10:15 PM To: "List for OpenCSW maintainers" Subject: Re: [csw-maintainers] CSWoldap > Hi Rupert, > > Am 15.02.2010 um 19:43 schrieb rupert THURNER: >> On Mon, Feb 15, 2010 at 09:43, Dagobert Michelsen >> wrote: >>> Hi David, >>> >>> Am 11.02.2010 um 14:26 schrieb Mantock David: >>> I made the following packages yesterday and I have now loaded them in >>> to build farm NFS share: /home/testing >>> >>> openldap_client-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz >>> openldap_devel-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz >>> openldap_rt-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz >>> openldap-2.4.19,REV=2010.02.10-SunOS5.8-sparc-CSW.pkg.gz >>> >>> They are available for testing on >>> http://mirror.opencsw.org/opencsw/testing >>> >>> Apart from making x86 versions is there something else I should do? >>> >>> The following things need to be either verified or implemented in the >>> package: >>> >>> - Check that the package works (start server, stop server on Solaris >>> 8/9 RC and 10 SMF) >>> - Check functionality (create database, populate, access via SSL and >>> Kerberos) >>> - Check upgrade path from existing OpenLDAP package (especially >>> relocation of database >>> from /opt/csw/var to /var/opt/csw), conversion of database from BDB >>> 4.4 to 4.7. >>> If the upgrade is not straight-forward it needs to be documents. >> >> how can we avoid the database move to /var/opt ? > > Well, IIRC we wanted to move all writable data to /var/opt/csw to be more > sparse-zone > friendly for r/o shared /opt. The moving itself is with cswmigrateconf no > big > deal. Or do you have other reasons in mind to not move it? > > > 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 dam at opencsw.org Mon Feb 22 09:04:37 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 22 Feb 2010 09:04:37 +0100 Subject: [csw-maintainers] CSWoldap In-Reply-To: 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> Message-ID: <0BF86C7C-7726-41EE-B847-F378B7B03EA7@opencsw.org> Hi David, Am 20.02.2010 um 16:41 schrieb David Mantock: > Have a missed something? When I logged in to build10x I couldn't run > gmake commands. I need to do part of the build there for x86/x64 > stuff. What did you do exactly? Usually the "gmake platforms" hops over automatically to build10x. See for details http://sourceforge.net/apps/trac/gar/wiki/Platforms Best regards -- Dago From maciej at opencsw.org Mon Feb 22 13:06:56 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 22 Feb 2010 12:06:56 +0000 Subject: [csw-maintainers] Taking symbols into account when checking binaries Message-ID: Sebastian, when you have time, I'd like to get you involved in writing new checks. We've talked about the checks with missing symbols reported by ldd -r. Here's the current code which extracts the data: https://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/python/checkpkg.py#L961 You can add a new method, similar to this one. Look at binary_abspath bit, it shows how to access the unpacked binary on the disk. All the method needs to return, is a data structure. Right now, it's just a list of lines from ldd -r output. Look at existing saved data structures: ls ~/.checkpkg/stats/*/*/ldd_dash_r.yml It's a dict of lists: {'foo.so': ['line1', 'line2']} here, you would do something similar {'foo.so': ['symbol1', 'symbol2', ...]} You can copy the GetLddMinusRlines() method to a new name (GetSymbols?) and modify it. Then you can add one line to CollectStats(), something along the lines of: self.DumpObject(self.GetSymbols(), "symbols") Once this is done, you can go to https://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/python/package_checks.py and use pkg_data["symbols"]. Maciej From phil at bolthole.com Mon Feb 22 18:50:39 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 22 Feb 2010 09:50:39 -0800 Subject: [csw-maintainers] OpenCSW listed on Subversion's binary packages page In-Reply-To: References: Message-ID: On Sat, Feb 20, 2010 at 12:09 AM, Maciej (Matchek) Blizinski wrote: > I've noticed that Suvbversion webpage has a subpage with a list of > binary packages for different operating systems, on which we weren't > listed. ?I contacted their dev mailing list, and got a reply that > I'm welcome to update the page. ?They have a repository with the HTML > code, so they pointed me at it and suggested submitting a patch. ?I > wrote one, and sent it. ?They did their tweaks and applied it. > Voila! ?We're now listed there, which means a little bit more traffic > to our web site, and potentially -- more users. > Thats great! Thanks for the extra effort, Maciej From maciej at opencsw.org Mon Feb 22 20:26:37 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 22 Feb 2010 19:26:37 +0000 Subject: [csw-maintainers] Registering packages in mantis (was Re: [csw-pkgsubmissions] newpkgs firefox_l10n_af, ...) Message-ID: [+maintainers, bcc:pkgsubmissions] On Mon, Feb 22, 2010 at 7:16 PM, Philip Brown wrote: > On Sun, Feb 21, 2010 at 4:40 AM, William Bonnet wrote: >> *... >> These packages are new. They provide l10n support to Firefox, based upon the official localization availables from MoFo. > > mo... fo...? > Umm.. > > *cough*... > > umm... > > > okay, i'll go with it :-} > > > i'm just shoving these things in and not registering them with mantis. Perhaps your time is spent better doing other things and mantis registration can be offloaded to somebody else or automated? Maciej From phil at bolthole.com Mon Feb 22 20:46:32 2010 From: phil at bolthole.com (Philip Brown) Date: Mon, 22 Feb 2010 11:46:32 -0800 Subject: [csw-maintainers] Registering packages in mantis (was Re: [csw-pkgsubmissions] newpkgs firefox_l10n_af, ...) In-Reply-To: References: Message-ID: On Mon, Feb 22, 2010 at 11:26 AM, Maciej (Matchek) Blizinski wrote: > .. >> i'm just shoving these things in and not registering them with mantis. > > Perhaps your time is spent better doing other things and mantis > registration can be offloaded to somebody else or automated? > its semi-automated, and not really an extra hassle. This was more a deliberate choice of, "I dont think we'll benefit from registering them in mantis,and there's a slight drawback of the extra clutter if we do put them in". From maciej at opencsw.org Tue Feb 23 00:50:04 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 22 Feb 2010 23:50:04 +0000 Subject: [csw-maintainers] Taking symbols into account when checking binaries In-Reply-To: References: Message-ID: I've implemented the check which does the following: 1. Collect triplets: pkgname, binary, missing symbol 2. If there are any missing symbols, collect all the symbols that are provided by the set of packages (nm -p -D). 3. From the list of missing symbols, remove all symbols that are provided by the set of packages. 4. Report any remaining symbols as errors. Symbols from binaries are collected with "/usr/ccs/bin/nm -p -D ". Only the entries of type T (text) are taken into account. I tested it against PostgreSQL packages and the outcome is that is still a lot of missing symbols: the ones that ldd -r says are missing, and that nm -p -D doesn't find. For those who want to see it on their own eyes, the command line to run is: /home/maciej/src/opencsw/gar/v2/bin/checkpkg ls -l /home/maciej/staging/build-2010-02-22/*sparc* An example symbol for PostgreSQL can be CurrentMemoryContext -- ldd complains about it, nm doesn't find it. Sebastian, what do you think? Maciej From maciej at opencsw.org Tue Feb 23 06:22:29 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 23 Feb 2010 05:22:29 +0000 Subject: [csw-maintainers] complex trac issue In-Reply-To: References: Message-ID: On Sat, Feb 20, 2010 at 7:06 PM, Peter FELECAN wrote: > I will test when it's released. It's out now. Please take a look. From william at wbonnet.net Tue Feb 23 08:39:20 2010 From: william at wbonnet.net (William Bonnet) Date: Tue, 23 Feb 2010 08:39:20 +0100 Subject: [csw-maintainers] Registering packages in mantis (was Re: [csw-pkgsubmissions] newpkgs firefox_l10n_af, ...) In-Reply-To: References: Message-ID: <4B838628.2040608@wbonnet.net> Hi > its semi-automated, and not really an extra hassle. This was more a > deliberate choice of, > "I dont think we'll benefit from registering them in mantis,and > there's a slight drawback of the extra clutter if we do put them in". > IMHO benefit will be the same as many other other "samll packages". If they are not registered, there will be no way to report problem (that's the initial release, and there my be problems). Moreover, it will not be possible to ask for update through the bug tracker. I think we should have a cohrent policy, and register in mantis each and every package. 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 maciej at opencsw.org Tue Feb 23 08:44:24 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 23 Feb 2010 07:44:24 +0000 Subject: [csw-maintainers] Registering packages in mantis (was Re: [csw-pkgsubmissions] newpkgs firefox_l10n_af, ...) In-Reply-To: <4B838628.2040608@wbonnet.net> References: <4B838628.2040608@wbonnet.net> Message-ID: On Tue, Feb 23, 2010 at 7:39 AM, William Bonnet wrote: > Hi > >> its semi-automated, and not really an extra hassle. This was more a >> deliberate choice of, >> "I dont think we'll benefit from registering them in mantis,and >> there's a slight drawback of the extra clutter if we do put them in". >> > > IMHO benefit will be the same as many other other "samll packages". If they > are not registered, there will be no way to report problem (that's the > initial release, and there my be problems). Moreover, it will not be > possible to ask for update through the bug tracker. > > I think we should have a cohrent policy, and register in mantis each and > every package. Mantis creates a drop-down select field with all the packages in a flat list. Selecting an item from a list of 2280 packages is annoying. I agree though that it's good to have every package registered in the database. What do we do then? From dam at opencsw.org Tue Feb 23 08:53:40 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 23 Feb 2010 08:53:40 +0100 Subject: [csw-maintainers] Registering packages in mantis (was Re: [csw-pkgsubmissions] newpkgs firefox_l10n_af, ...) In-Reply-To: References: <4B838628.2040608@wbonnet.net> Message-ID: <68CBAB65-8BF7-42C1-AAA0-5B07D977834F@opencsw.org> Hi, Am 23.02.2010 um 08:44 schrieb Maciej (Matchek) Blizinski: > On Tue, Feb 23, 2010 at 7:39 AM, William Bonnet > wrote: >>> its semi-automated, and not really an extra hassle. This was more a >>> deliberate choice of, >>> "I dont think we'll benefit from registering them in mantis,and >>> there's a slight drawback of the extra clutter if we do put them >>> in". >>> >> >> IMHO benefit will be the same as many other other "samll packages". >> If they >> are not registered, there will be no way to report problem (that's >> the >> initial release, and there my be problems). Moreover, it will not be >> possible to ask for update through the bug tracker. >> >> I think we should have a cohrent policy, and register in mantis >> each and >> every package. > > Mantis creates a drop-down select field with all the packages in a > flat list. Selecting an item from a list of 2280 packages is > annoying. I agree though that it's good to have every package > registered in the database. What do we do then? We could create "bundles" of packages built from the same source, like _rt, _devel, _base, _fance, _l18n_, ... and register only once. The correct bundle could be found by going over the package page packages/ -> "Report Bug" which links the package to the correct bundle. The packages per bundle can easily be retrieved from GAR. THis would also mean consolidating bugs from all individual bug sections to the bundle. Best regards -- Dago From maciej at opencsw.org Tue Feb 23 09:10:56 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 23 Feb 2010 08:10:56 +0000 Subject: [csw-maintainers] Taking symbols into account when checking binaries In-Reply-To: References: Message-ID: I've figured out that 'D' type symbols (data) need to be taken into account as well. This further lowers the false positive rate. I've submitted the new code to the repository. From pfelecan at opencsw.org Tue Feb 23 10:38:58 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 23 Feb 2010 10:38:58 +0100 Subject: [csw-maintainers] complex trac issue In-Reply-To: (Maciej Blizinski's message of "Tue, 23 Feb 2010 05:22:29 +0000") References: Message-ID: "Maciej (Matchek) Blizinski" writes: > On Sat, Feb 20, 2010 at 7:06 PM, Peter FELECAN wrote: >> I will test when it's released. > > It's out now. Please take a look. trac-admin /tracs/test resync Traceback (most recent call last): File "/opt/csw/bin/trac-admin", line 5, in from pkg_resources import load_entry_point ImportError: No module named pkg_resources -- Peter From maciej at opencsw.org Tue Feb 23 10:45:17 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 23 Feb 2010 09:45:17 +0000 Subject: [csw-maintainers] complex trac issue In-Reply-To: References: Message-ID: On Tue, Feb 23, 2010 at 9:38 AM, Peter FELECAN wrote: > "Maciej (Matchek) Blizinski" writes: > >> On Sat, Feb 20, 2010 at 7:06 PM, Peter FELECAN wrote: >>> I will test when it's released. >> >> It's out now. ?Please take a look. > > trac-admin /tracs/test resync > Traceback (most recent call last): > ?File "/opt/csw/bin/trac-admin", line 5, in > ? ?from pkg_resources import load_entry_point > ImportError: No module named pkg_resources Can you show a terminal session dump of how are you installing the package? From pfelecan at opencsw.org Tue Feb 23 11:05:35 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 23 Feb 2010 11:05:35 +0100 Subject: [csw-maintainers] complex trac issue In-Reply-To: (Maciej Blizinski's message of "Tue, 23 Feb 2010 09:45:17 +0000") References: Message-ID: "Maciej (Matchek) Blizinski" writes: > On Tue, Feb 23, 2010 at 9:38 AM, Peter FELECAN wrote: >> "Maciej (Matchek) Blizinski" writes: >> >>> On Sat, Feb 20, 2010 at 7:06 PM, Peter FELECAN wrote: >>>> I will test when it's released. >>> >>> It's out now. ?Please take a look. >> >> trac-admin /tracs/test resync >> Traceback (most recent call last): >> ?File "/opt/csw/bin/trac-admin", line 5, in >> ? ?from pkg_resources import load_entry_point >> ImportError: No module named pkg_resources > > Can you show a terminal session dump of how are you installing the package? As is quite verbose I attach it as a compressed file. -------------- next part -------------- A non-text attachment was scrubbed... Name: 20100223.bz2 Type: application/octet-stream Size: 27049 bytes Desc: terminal session of upgrading trac URL: -------------- next part -------------- -- Peter From maciej at opencsw.org Tue Feb 23 11:31:42 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 23 Feb 2010 10:31:42 +0000 Subject: [csw-maintainers] complex trac issue In-Reply-To: References: Message-ID: On Tue, Feb 23, 2010 at 10:05 AM, Peter FELECAN wrote: > "Maciej (Matchek) Blizinski" writes: > >> On Tue, Feb 23, 2010 at 9:38 AM, Peter FELECAN wrote: >>> "Maciej (Matchek) Blizinski" writes: >>> >>>> On Sat, Feb 20, 2010 at 7:06 PM, Peter FELECAN wrote: >>>>> I will test when it's released. >>>> >>>> It's out now. ?Please take a look. >>> >>> trac-admin /tracs/test resync >>> Traceback (most recent call last): >>> ?File "/opt/csw/bin/trac-admin", line 5, in >>> ? ?from pkg_resources import load_entry_point >>> ImportError: No module named pkg_resources >> >> Can you show a terminal session dump of how are you installing the package? > > As is quite verbose I attach it as a compressed file. Thanks. The problem can be seen below. pkg-get tries to update CSWpysetuptools. It first removes the old version, and when it tries to install the new version, it suddenly discovers that it cannot download a dependency of CSWpysetuptools (that is, CSWdistutils). CSWdistutils package is unavailable because it is obsolete and has been removed from the catalog. The system ends up with setuptools uninstalled. Removal of was successful. Analysing special files... ERROR: no info for CSWpydistutils. Cannot install dependancy. ERROR: could not install required dependancies for CSWpysetuptools Once dependancies are up to date, call /opt/csw/bin/pkg-get -i pysetuptools to (re)install I've just created an updated version of setuptools with the dependency on distutils removed. Please try the updated package in experimental. http://mirror.opencsw.org/experimental.html#maciej Maciej From pfelecan at opencsw.org Tue Feb 23 12:14:56 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 23 Feb 2010 12:14:56 +0100 Subject: [csw-maintainers] complex trac issue In-Reply-To: (Maciej Blizinski's message of "Tue, 23 Feb 2010 10:31:42 +0000") References: Message-ID: "Maciej (Matchek) Blizinski" writes: > On Tue, Feb 23, 2010 at 10:05 AM, Peter FELECAN wrote: >> "Maciej (Matchek) Blizinski" writes: >> >>> On Tue, Feb 23, 2010 at 9:38 AM, Peter FELECAN wrote: >>>> "Maciej (Matchek) Blizinski" writes: >>>> >>>>> On Sat, Feb 20, 2010 at 7:06 PM, Peter FELECAN wrote: >>>>>> I will test when it's released. >>>>> >>>>> It's out now. ?Please take a look. >>>> >>>> trac-admin /tracs/test resync >>>> Traceback (most recent call last): >>>> ?File "/opt/csw/bin/trac-admin", line 5, in >>>> ? ?from pkg_resources import load_entry_point >>>> ImportError: No module named pkg_resources >>> >>> Can you show a terminal session dump of how are you installing the package? >> >> As is quite verbose I attach it as a compressed file. > > Thanks. The problem can be seen below. pkg-get tries to update > CSWpysetuptools. It first removes the old version, and when it tries > to install the new version, it suddenly discovers that it cannot > download a dependency of CSWpysetuptools (that is, CSWdistutils). > CSWdistutils package is unavailable because it is obsolete and has > been removed from the catalog. The system ends up with setuptools > uninstalled. > > Removal of was successful. > Analysing special files... > ERROR: no info for CSWpydistutils. Cannot install dependancy. > ERROR: could not install required dependancies for CSWpysetuptools > Once dependancies are up to date, call > /opt/csw/bin/pkg-get -i pysetuptools > to (re)install > > I've just created an updated version of setuptools with the dependency > on distutils removed. Please try the updated package in experimental. > > http://mirror.opencsw.org/experimental.html#maciej Installed and: trac-admin /tracs/test resync Traceback (most recent call last): File "/opt/csw/bin/trac-admin", line 5, in from pkg_resources import load_entry_point File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 2603, in working_set.require(__requires__) File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 666, in require needed = self.resolve(parse_requirements(requirements)) File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 565, in resolve raise DistributionNotFound(req) # XXX put more info here pkg_resources.DistributionNotFound: Trac==0.11.6 -- Peter From maciej at opencsw.org Tue Feb 23 14:36:27 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 23 Feb 2010 13:36:27 +0000 Subject: [csw-maintainers] complex trac issue In-Reply-To: References: Message-ID: On Tue, Feb 23, 2010 at 11:14 AM, Peter FELECAN wrote: > Installed and: > > trac-admin /tracs/test resync > Traceback (most recent call last): > ?File "/opt/csw/bin/trac-admin", line 5, in > ? ?from pkg_resources import load_entry_point > ?File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 2603, in > ? ?working_set.require(__requires__) > ?File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 666, in require > ? ?needed = self.resolve(parse_requirements(requirements)) > ?File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 565, in resolve > ? ?raise DistributionNotFound(req) ?# XXX put more info here > pkg_resources.DistributionNotFound: Trac==0.11.6 This one isn't as obvious. Setup tools can't find the right version of Trac; at this point debugging is needed, it's hard to tell whether this issue is related only to packaging or software version mismatches, or local installation issues. Can you see whether the right version of Trac is present in Trac files in /opt/csw/lib/python/site-packages? From maciej at opencsw.org Tue Feb 23 14:40:34 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 23 Feb 2010 13:40:34 +0000 Subject: [csw-maintainers] Testing for file existence Message-ID: Here's something for Unix grey beards that I discovered when debugging a failing unit test in Google protobuf (protocol buffers). Let's consider the following set of commands: cd /var/tmp touch ${LOGNAME}-foo test -e ${LOGNAME}-foo/ && echo yes || echo no (note the trailing slash) What is in your opinion the proper outcome? Our buildfarm machines don't seem to agree on the issue. Here are the poll results: || build8s: no || build8x: yes || || build9s: no || build9x: yes || || build10s: no || build10x: no || The script that generated this output: http://paste.pocoo.org/show/181493/ What do you make of it? Is it a bug or a feature? If it's a bug, can it be fixed on the OS side? Maciej From dam at opencsw.org Tue Feb 23 14:46:31 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 23 Feb 2010 14:46:31 +0100 Subject: [csw-maintainers] Testing for file existence In-Reply-To: References: Message-ID: <4ED339EC-070F-4C94-8EB5-F60D58D79E0C@opencsw.org> Hi Maciej, Am 23.02.2010 um 14:40 schrieb Maciej (Matchek) Blizinski: > Here's something for Unix grey beards that I discovered when debugging > a failing unit test in Google protobuf (protocol buffers). Let's > consider the following set of commands: > > cd /var/tmp > touch ${LOGNAME}-foo > test -e ${LOGNAME}-foo/ && echo yes || echo no > > (note the trailing slash) > > What is in your opinion the proper outcome? > > Our buildfarm machines don't seem to agree on the issue. Here are the > poll results: > > || build8s: no || build8x: yes || > || build9s: no || build9x: yes || > || build10s: no || build10x: no || > > The script that generated this output: > http://paste.pocoo.org/show/181493/ > > What do you make of it? Is it a bug or a feature? If it's a bug, can > it be fixed on the OS side? The problem is the trailing "/" on test argument to "test -e". For the test the syscall "access" is issued which returns just 0 on Solaris 8 and 9 and ENOTDIR on Solaris 10 due to massive modifications in the access syscall code due to the CIFS extensions. Both build8s and build9s run as branded Zones and access() is not inerposed in the branded zone interposing lib. I think it is a bug as the branded zone should behave exactly the same as the native Solaris 8. I'll see that I open a bug report. Best regards -- Dago From phil at bolthole.com Tue Feb 23 15:12:33 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 23 Feb 2010 06:12:33 -0800 Subject: [csw-maintainers] Registering packages in mantis (was Re: [csw-pkgsubmissions] newpkgs firefox_l10n_af, ...) In-Reply-To: <68CBAB65-8BF7-42C1-AAA0-5B07D977834F@opencsw.org> References: <4B838628.2040608@wbonnet.net> <68CBAB65-8BF7-42C1-AAA0-5B07D977834F@opencsw.org> Message-ID: not quite sure what you mean by "bundle" Dago... but seems to me that in this case, the packages in question are pretty clearly a "part of" firefox already From dam at opencsw.org Tue Feb 23 15:15:27 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 23 Feb 2010 15:15:27 +0100 Subject: [csw-maintainers] Registering packages in mantis (was Re: [csw-pkgsubmissions] newpkgs firefox_l10n_af, ...) In-Reply-To: References: <4B838628.2040608@wbonnet.net> <68CBAB65-8BF7-42C1-AAA0-5B07D977834F@opencsw.org> Message-ID: Hi Phil, Am 23.02.2010 um 15:12 schrieb Philip Brown: > not quite sure what you mean by "bundle" Dago... but seems to me that > in this case, the packages in question are pretty clearly a "part of" > firefox already The idea is to map packages to "bundles" and report bugs with the "report bug" button on the packages page going to the Mantis project named after the bundle. This reduses and unifies the buglisting. That means that CSWmypkg CSWmypkgdevel CSWmypkgrt CSWmypkg_i18_de would all belong to the bundle "mypkg" derived after the main package catalog name. Best regards -- Dago From skayser at opencsw.org Tue Feb 23 15:21:47 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 23 Feb 2010 15:21:47 +0100 Subject: [csw-maintainers] complex trac issue In-Reply-To: References: Message-ID: <20100223142147.GB7613@sebastiankayser.de> * Maciej (Matchek) Blizinski wrote: > On Tue, Feb 23, 2010 at 11:14 AM, Peter FELECAN wrote: > > Installed and: > > > > trac-admin /tracs/test resync > > Traceback (most recent call last): > > ?File "/opt/csw/bin/trac-admin", line 5, in > > ? ?from pkg_resources import load_entry_point > > ?File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 2603, in > > ? ?working_set.require(__requires__) > > ?File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 666, in require > > ? ?needed = self.resolve(parse_requirements(requirements)) > > ?File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 565, in resolve > > ? ?raise DistributionNotFound(req) ?# XXX put more info here > > pkg_resources.DistributionNotFound: Trac==0.11.6 > > This one isn't as obvious. Setup tools can't find the right version > of Trac; Could it be that our approach of not shipping .egg files is coming into play here? Sebastian From pfelecan at opencsw.org Tue Feb 23 16:00:05 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 23 Feb 2010 16:00:05 +0100 Subject: [csw-maintainers] complex trac issue In-Reply-To: (Maciej Blizinski's message of "Tue, 23 Feb 2010 13:36:27 +0000") References: Message-ID: "Maciej (Matchek) Blizinski" writes: > On Tue, Feb 23, 2010 at 11:14 AM, Peter FELECAN wrote: >> Installed and: >> >> trac-admin /tracs/test resync >> Traceback (most recent call last): >> ?File "/opt/csw/bin/trac-admin", line 5, in >> ? ?from pkg_resources import load_entry_point >> ?File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 2603, in >> ? ?working_set.require(__requires__) >> ?File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 666, in require >> ? ?needed = self.resolve(parse_requirements(requirements)) >> ?File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 565, in resolve >> ? ?raise DistributionNotFound(req) ?# XXX put more info here >> pkg_resources.DistributionNotFound: Trac==0.11.6 > > This one isn't as obvious. Setup tools can't find the right version > of Trac; at this point debugging is needed, it's hard to tell whether > this issue is related only to packaging or software version > mismatches, or local installation issues. Can you see whether the > right version of Trac is present in Trac files in > /opt/csw/lib/python/site-packages? All the files are from the CSWtrac package. However, I do not understand what do you mean by "right version of Trac is present in Trac files"... I didn't found a reference to Trac in those files. -- Peter From pfelecan at opencsw.org Tue Feb 23 16:01:53 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 23 Feb 2010 16:01:53 +0100 Subject: [csw-maintainers] complex trac issue In-Reply-To: <20100223142147.GB7613@sebastiankayser.de> (Sebastian Kayser's message of "Tue, 23 Feb 2010 15:21:47 +0100") References: <20100223142147.GB7613@sebastiankayser.de> Message-ID: Sebastian Kayser writes: > * Maciej (Matchek) Blizinski wrote: >> On Tue, Feb 23, 2010 at 11:14 AM, Peter FELECAN wrote: >> > Installed and: >> > >> > trac-admin /tracs/test resync >> > Traceback (most recent call last): >> > ?File "/opt/csw/bin/trac-admin", line 5, in >> > ? ?from pkg_resources import load_entry_point >> > ?File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 2603, in >> > ? ?working_set.require(__requires__) >> > ?File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 666, in require >> > ? ?needed = self.resolve(parse_requirements(requirements)) >> > ?File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 565, in resolve >> > ? ?raise DistributionNotFound(req) ?# XXX put more info here >> > pkg_resources.DistributionNotFound: Trac==0.11.6 >> >> This one isn't as obvious. Setup tools can't find the right version >> of Trac; > > Could it be that our approach of not shipping .egg files is coming into > play here? Oh my! I didn't install a chicken... -- Peter From phil at bolthole.com Tue Feb 23 17:40:48 2010 From: phil at bolthole.com (Philip Brown) Date: Tue, 23 Feb 2010 08:40:48 -0800 Subject: [csw-maintainers] Registering packages in mantis (was Re: [csw-pkgsubmissions] newpkgs firefox_l10n_af, ...) In-Reply-To: References: <4B838628.2040608@wbonnet.net> <68CBAB65-8BF7-42C1-AAA0-5B07D977834F@opencsw.org> Message-ID: On Tue, Feb 23, 2010 at 6:15 AM, Dagobert Michelsen wrote: > Hi Phil, > *wave* > Am 23.02.2010 um 15:12 schrieb Philip Brown: >> >> not quite sure what you mean by "bundle" Dago... but seems to me that >> in this case, the packages in question are pretty clearly a "part of" >> firefox already > > The idea is to map packages to "bundles" and report bugs with the "report > bug" button on the packages page going to the Mantis project named after > the bundle. This reduses and unifies the buglisting. That means that > ?CSWmypkg > ?CSWmypkgdevel > ?CSWmypkgrt > ?CSWmypkg_i18_de > would all belong to the bundle "mypkg" derived after the main package > catalog name. > Erm.. I'm not exactly sure what that would gain us. we would avoid the extra 60 (yes, 60!) extraneous firefox local packages being listed in mantis. But we would then have them in the output of http://www.opencsw.org/packages. and it would make things quite a bit more complex to maintain, web-code wise. and release-wise. [complexity: what mechanism would we use to derive the "main package" name, and where/how would this information be stored?] Seems simpler, and yet quite straightforward, to have an understanding of, "If there is softname, softname_FOO, softname_BAR, softname_BAZ, and there are not separate mantis categories, you are expected to go file bugs for the base name 'softname' " Even a newbie user should be able to figure that one out as-is. From skayser at opencsw.org Wed Feb 24 01:09:22 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 24 Feb 2010 01:09:22 +0100 Subject: [csw-maintainers] /testing spamassassin, bind, dhcp, dnstop In-Reply-To: <625385e31002160053y792724f8vcb1714286aec65c2@mail.gmail.com> References: <625385e31001261327k31719e1bo2bd90963eb99a3d2@mail.gmail.com> <4B79B4AC.9050204@opencsw.org> <625385e31002151303g47f8dafdp14d2805078188af2@mail.gmail.com> <4B79BA85.9010309@opencsw.org> <625385e31002151405m61536773kea6bbf01b030ba1b@mail.gmail.com> <273F3E70-15FF-40B6-B255-7E47372763D9@opencsw.org> <625385e31002160053y792724f8vcb1714286aec65c2@mail.gmail.com> Message-ID: <4B846E32.1000109@opencsw.org> Peter Bonivart wrote on 16.02.2010 09:53: > On Tue, Feb 16, 2010 at 9:33 AM, Dagobert Michelsen wrote: >>> Or can we convert from HTML to man page format in any simple way? >> At least I don't know a solution with reasonable results. > > It's a pretty short and simple man page. I know POD and there's > pod2man to convert. I may go that way (to avoid learning new stuff > ;-). James helped out to dig deeper into what exactly is going on here (I faced a similar problem with autossh). The root cause as well as a possible workaround are described in [1]. In short: * man page is written with roff macros from the doc macro package (grog(1) can help to determine this), thus formatting it with the an/man macro package - which is what man does by default - fails. * "groff -m doc -Tascii -P-cuob " can be used to produce a pre-formatted man page which can then be placed in /opt/csw/share/man/catman
from where it will simply be read instead of being run through the roff chain. The second step is my simplistic approach after reading into the basics of roff a bit, so there might be very well a "better" approach ... but again, it does the job (and even better than the ugly workaround posted earlier). There is also some background on man vs. doc macro packages geared towards man page writers at [2]. Quote: "do yourself a favor: use tmac.an -- use of any other macro package is considered harmful." HTH Sebastian [1] http://www.opencsw.org/mantis/view.php?id=4280 [2] http://tldp.org/HOWTO/Man-Page/q5.html From dam at opencsw.org Wed Feb 24 11:52:26 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 24 Feb 2010 11:52:26 +0100 Subject: [csw-maintainers] Registering packages in mantis (was Re: [csw-pkgsubmissions] newpkgs firefox_l10n_af, ...) In-Reply-To: References: <4B838628.2040608@wbonnet.net> <68CBAB65-8BF7-42C1-AAA0-5B07D977834F@opencsw.org> Message-ID: <377F6978-3B43-4F0E-918B-42E484607D8D@opencsw.org> Hi Phil, Am 23.02.2010 um 17:40 schrieb Philip Brown: > On Tue, Feb 23, 2010 at 6:15 AM, Dagobert Michelsen > wrote: >> Am 23.02.2010 um 15:12 schrieb Philip Brown: >>> not quite sure what you mean by "bundle" Dago... but seems to me >>> that >>> in this case, the packages in question are pretty clearly a "part >>> of" >>> firefox already >> >> The idea is to map packages to "bundles" and report bugs with the >> "report >> bug" button on the packages page going to the Mantis project named >> after >> the bundle. This reduses and unifies the buglisting. That means that >> CSWmypkg >> CSWmypkgdevel >> CSWmypkgrt >> CSWmypkg_i18_de >> would all belong to the bundle "mypkg" derived after the main package >> catalog name. > > Erm.. I'm not exactly sure what that would gain us. > we would avoid the extra 60 (yes, 60!) extraneous firefox local > packages being listed in mantis. Yes. We would basically halve the number of listed items as all runtime and devel packages would collapse to the base bundles also. > But we would then have them in the output of > http://www.opencsw.org/packages. and it would make things quite a bit > more complex to maintain, web-code wise. and release-wise. But it would gain "What packages belong to that software?" which is now without browsing GAR to doable. > [complexity: what mechanism would we use to derive the "main package" > name, and where/how would this information be stored?] > > Seems simpler, and yet quite straightforward, to have an > understanding of, > > "If there is softname, softname_FOO, softname_BAR, softname_BAZ, and > there are not separate mantis categories, you are expected to go file > bugs for the base name 'softname' " And pm_softname and py_softname? > Even a newbie user should be able to figure that one out as-is. It should not replace the package listing. It is an additional page like /bundles// which contains information about the package in general (like how to use it) and links to the packages it contains. The information should be quite easily optainable by just looking at the upstream URL in the info field: same field - same bundle. Best regards -- Dago From maciej at opencsw.org Wed Feb 24 14:37:53 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 24 Feb 2010 13:37:53 +0000 Subject: [csw-maintainers] complex trac issue In-Reply-To: References: <20100223142147.GB7613@sebastiankayser.de> Message-ID: On Tue, Feb 23, 2010 at 3:01 PM, Peter FELECAN wrote: > Sebastian Kayser writes: > >> * Maciej (Matchek) Blizinski wrote: >>> On Tue, Feb 23, 2010 at 11:14 AM, Peter FELECAN wrote: >>> > Installed and: >>> > >>> > trac-admin /tracs/test resync >>> > Traceback (most recent call last): >>> > ?File "/opt/csw/bin/trac-admin", line 5, in >>> > ? ?from pkg_resources import load_entry_point >>> > ?File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 2603, in >>> > ? ?working_set.require(__requires__) >>> > ?File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 666, in require >>> > ? ?needed = self.resolve(parse_requirements(requirements)) >>> > ?File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 565, in resolve >>> > ? ?raise DistributionNotFound(req) ?# XXX put more info here >>> > pkg_resources.DistributionNotFound: Trac==0.11.6 >>> >>> This one isn't as obvious. ?Setup tools can't find the right version >>> of Trac; >> >> Could it be that our approach of not shipping .egg files is coming into >> play here? Peter, have you tried investigating what is happening in this code? If not, can you do that? From David.Mantock at connectis.ch Wed Feb 24 16:26:49 2010 From: David.Mantock at connectis.ch (Mantock David) Date: Wed, 24 Feb 2010 16:26:49 +0100 Subject: [csw-maintainers] CSWoldap In-Reply-To: <0BF86C7C-7726-41EE-B847-F378B7B03EA7@opencsw.org> 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> Message-ID: <940F857E6596B84BAFD05DBA869276E23504F1148A@CON-EX-001.connectis.local> Hi Dago, I followed the normal procedure for packaging with gar. My environment does not override the /etc/opt/csw/garrc BUILDHOST or PACKAGING_HOST variables. ------------snip---------------------------------------------- dlm at login [login]:~ > ssh build10x Last login: Mon Feb 22 09:38:04 2010 from login.bo.opencs Sun Microsystems Inc. SunOS 5.10 Generic January 2005 dlm at build10x [global]:~ > which gmake no gmake in /usr/bin /usr/sbin /sbin /usr/ccs/bin /usr/dt/bin /usr/openwin/bin /opt/bop/bin /usr/sfw/bin /usr/sfw/sbin ------------snip----------------------------------------------------------------------------- If I only wanted to build a package for this architecture shouldn't the gar stuff be here anyway? Cheers, David -----Original Message----- From: maintainers-bounces+dlm=opencsw.org at lists.opencsw.org [mailto:maintainers-bounces+dlm=opencsw.org at lists.opencsw.org] On Behalf Of Dagobert Michelsen Sent: Montag, 22. Februar 2010 09:05 To: David Mantock; List for OpenCSW maintainers Subject: Re: [csw-maintainers] CSWoldap Hi David, Am 20.02.2010 um 16:41 schrieb David Mantock: > Have a missed something? When I logged in to build10x I couldn't run > gmake commands. I need to do part of the build there for x86/x64 > stuff. What did you do exactly? Usually the "gmake platforms" hops over automatically to build10x. See for details http://sourceforge.net/apps/trac/gar/wiki/Platforms 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. ::. This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of connectis AG. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please destroy the message and/or contact the sender if you believe you have received this email in error. From maciej at opencsw.org Wed Feb 24 19:34:32 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 24 Feb 2010 18:34:32 +0000 Subject: [csw-maintainers] CSWoldap In-Reply-To: <940F857E6596B84BAFD05DBA869276E23504F1148A@CON-EX-001.connectis.local> References: <7E966BC5-D968-4A0B-B273-D491E8E2CDF2@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> Message-ID: On Wed, Feb 24, 2010 at 3:26 PM, Mantock David wrote: > Hi Dago, > > I followed the normal procedure for packaging with gar. > My environment does not override the /etc/opt/csw/garrc BUILDHOST or PACKAGING_HOST variables. > > ------------snip---------------------------------------------- > dlm at login [login]:~ > ssh build10x > Last login: Mon Feb 22 09:38:04 2010 from login.bo.opencs > Sun Microsystems Inc. ? SunOS 5.10 ? ? ?Generic January 2005 > dlm at build10x [global]:~ > which gmake > no gmake in /usr/bin /usr/sbin /sbin /usr/ccs/bin /usr/dt/bin /usr/openwin/bin /opt/bop/bin /usr/sfw/bin /usr/sfw/sbin > > ------------snip----------------------------------------------------------------------------- > > > If I only wanted to build a package for this architecture shouldn't the gar stuff be here anyway? Your PATH seems to be missing /opt/csw/bin. From skayser at opencsw.org Wed Feb 24 19:50:30 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 24 Feb 2010 19:50:30 +0100 Subject: [csw-maintainers] CSWoldap In-Reply-To: References: <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> Message-ID: <20100224185030.GC7613@sebastiankayser.de> * Maciej (Matchek) Blizinski wrote: > On Wed, Feb 24, 2010 at 3:26 PM, Mantock David > wrote: > > I followed the normal procedure for packaging with gar. > > My environment does not override the /etc/opt/csw/garrc BUILDHOST or PACKAGING_HOST variables. > > > > ------------snip---------------------------------------------- > > dlm at login [login]:~ > ssh build10x > > Last login: Mon Feb 22 09:38:04 2010 from login.bo.opencs > > Sun Microsystems Inc. ? SunOS 5.10 ? ? ?Generic January 2005 > > dlm at build10x [global]:~ > which gmake > > no gmake in /usr/bin /usr/sbin /sbin /usr/ccs/bin /usr/dt/bin /usr/openwin/bin /opt/bop/bin /usr/sfw/bin /usr/sfw/sbin > > > > ------------snip----------------------------------------------------------------------------- > > > > > > If I only wanted to build a package for this architecture shouldn't the gar stuff be here anyway? > > Your PATH seems to be missing /opt/csw/bin. How about adding this to the PATH on the buildfarm hosts per default? Sebastian From maciej at opencsw.org Wed Feb 24 20:17:31 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 24 Feb 2010 19:17:31 +0000 Subject: [csw-maintainers] building netscape security services, nss In-Reply-To: References: <6af4271002030207y1e952cdfycbbb1554d7eb548f@mail.gmail.com> Message-ID: On Wed, Feb 3, 2010 at 6:14 PM, Philip Brown wrote: > On Wed, Feb 3, 2010 at 2:17 AM, Maciej (Matchek) Blizinski > wrote: >> >> Firefox was done by William. ?I was working on NSS, and it even >> compiles on Solaris 10, but not Solaris 8, but the reason is unclear. > > I vaguely recall, that netscape for some unfathomable reason, took a > very different approach to security and nss, between [sol8 and sol > 10?] > > One of them attempts to compile, and does actually deliver in the > package, a completely separate [lib*nss*solaris*security*] Close, it stands for Network Security Services. > or > something, and one does not. > It gets dynamically linked in to the "main" nss lib, and is a critical > dependancy, if i recall correctly. The reason why NSS build was failing was that it uses a nonstandard and relatively brittle build system, which implicitly relied on the variable PLATFORM being unset. I tweaked GAR to stop using PLATFORM and use GAR_PLATFORM instead. This allowed me to build NSS (Solaris 8, sparc & i386, 32 + 64 bit). It's now in experimental. http://mirror.opencsw.org/experimental.html#maciej Rupert, would you like to test it? If it works fine for you, I'll release it. Maciej From phil at bolthole.com Wed Feb 24 21:29:11 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 24 Feb 2010 12:29:11 -0800 Subject: [csw-maintainers] Registering packages in mantis (was Re: [csw-pkgsubmissions] newpkgs firefox_l10n_af, ...) In-Reply-To: <377F6978-3B43-4F0E-918B-42E484607D8D@opencsw.org> References: <4B838628.2040608@wbonnet.net> <68CBAB65-8BF7-42C1-AAA0-5B07D977834F@opencsw.org> <377F6978-3B43-4F0E-918B-42E484607D8D@opencsw.org> Message-ID: On Wed, Feb 24, 2010 at 2:52 AM, Dagobert Michelsen wrote: > Am 23.02.2010 um 17:40 schrieb Philip Brown: >> >> "If there is ? softname, softname_FOO, softname_BAR, softname_BAZ, and >> there are not separate mantis categories, ?you are expected to go file >> bugs for the base name 'softname' " > > And pm_softname and py_softname? pm_xxx and py_xxxx do not tend to have sub-packages. I am not aware of even one. > >> Even a newbie user should be able to figure that one out as-is. > > It should not replace the package listing. It is an additional page > like /bundles// which contains information about the package > in general (like how to use it) and links to the packages it contains. > > The information should be quite easily optainable by just looking at the > upstream URL in the info field: same field - same bundle. I do not see a sane, easily maintainable way to do this. If I did, I would add it in. But I dont see one. If you want to spend time in writing up an implementation that easily ties in to our existing processes, feel free. From phil at bolthole.com Wed Feb 24 21:32:16 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 24 Feb 2010 12:32:16 -0800 Subject: [csw-maintainers] /testing spamassassin, bind, dhcp, dnstop In-Reply-To: <4B846E32.1000109@opencsw.org> References: <625385e31001261327k31719e1bo2bd90963eb99a3d2@mail.gmail.com> <4B79B4AC.9050204@opencsw.org> <625385e31002151303g47f8dafdp14d2805078188af2@mail.gmail.com> <4B79BA85.9010309@opencsw.org> <625385e31002151405m61536773kea6bbf01b030ba1b@mail.gmail.com> <273F3E70-15FF-40B6-B255-7E47372763D9@opencsw.org> <625385e31002160053y792724f8vcb1714286aec65c2@mail.gmail.com> <4B846E32.1000109@opencsw.org> Message-ID: Thanks for looking into that,and all the background, Sebastian. If you'd like to write it up appropriately, in HTML format, I'd be happy to insert it into the appropriate place in our standards pages. (Feel free to suggest the best place for it) From william at wbonnet.net Wed Feb 24 21:49:20 2010 From: william at wbonnet.net (William Bonnet) Date: Wed, 24 Feb 2010 21:49:20 +0100 Subject: [csw-maintainers] Registering packages in mantis (was Re: [csw-pkgsubmissions] newpkgs firefox_l10n_af, ...) In-Reply-To: References: <4B838628.2040608@wbonnet.net> Message-ID: <4B8590D0.5060402@wbonnet.net> Hi > Mantis creates a drop-down select field with all the packages in a > flat list. Selecting an item from a list of 2280 packages is > annoying. I agree though that it's good to have every package > registered in the database. What do we do then? > It's possible to hack mantis and add a package selector. Something ajax powered with completion. 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 Wed Feb 24 21:53:19 2010 From: phil at bolthole.com (Philip Brown) Date: Wed, 24 Feb 2010 12:53:19 -0800 Subject: [csw-maintainers] Registering packages in mantis (was Re: [csw-pkgsubmissions] newpkgs firefox_l10n_af, ...) In-Reply-To: <4B8590D0.5060402@wbonnet.net> References: <4B838628.2040608@wbonnet.net> <4B8590D0.5060402@wbonnet.net> Message-ID: On Wed, Feb 24, 2010 at 12:49 PM, William Bonnet wrote: > > > It's possible to hack mantis and add a package selector. Something ajax > powered with completion. you're talking about hacking the mantis code? whoever writes it then has the responsability to keep hacking it forevermore, when we upgrade mantis, or getting it accepted "upstream". site-local hacks to mantis are ugly, and best avoided. its complicated enough as it is. From dam at opencsw.org Wed Feb 24 23:05:36 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 24 Feb 2010 23:05:36 +0100 Subject: [csw-maintainers] Registering packages in mantis (was Re: [csw-pkgsubmissions] newpkgs firefox_l10n_af, ...) In-Reply-To: References: <4B838628.2040608@wbonnet.net> <68CBAB65-8BF7-42C1-AAA0-5B07D977834F@opencsw.org> <377F6978-3B43-4F0E-918B-42E484607D8D@opencsw.org> Message-ID: <8972FBF3-0B28-4200-9874-22CABAEA82F3@opencsw.org> Hi Phil, Am 24.02.2010 um 21:29 schrieb Philip Brown: > On Wed, Feb 24, 2010 at 2:52 AM, Dagobert Michelsen > wrote: >> Am 23.02.2010 um 17:40 schrieb Philip Brown: >>> >>> "If there is softname, softname_FOO, softname_BAR, softname_BAZ, >>> and >>> there are not separate mantis categories, you are expected to go >>> file >>> bugs for the base name 'softname' " >> >> And pm_softname and py_softname? > > pm_xxx and py_xxxx do not tend to have sub-packages. I am not aware > of even one. They may be subpackages of xxx, like for netsnmp or cyrus_imapd. That means they are generated in one go from the same set of sources during the same build. >>> Even a newbie user should be able to figure that one out as-is. >> >> It should not replace the package listing. It is an additional page >> like /bundles// which contains information about the package >> in general (like how to use it) and links to the packages it >> contains. >> >> The information should be quite easily optainable by just looking >> at the >> upstream URL in the info field: same field - same bundle. > > I do not see a sane, easily maintainable way to do this. If I did, I > would add it in. But I dont see one. > If you want to spend time in writing up an implementation that easily > ties in to our existing processes, feel free. Sebastian: Is there such a concept in Mantis? If yes we can easily create the bundles out of the GAR recipes or by using the above described procedure for all other packages. Best regards -- Dago From skayser at opencsw.org Thu Feb 25 00:25:46 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 25 Feb 2010 00:25:46 +0100 Subject: [csw-maintainers] Registering packages in mantis (was Re: [csw-pkgsubmissions] newpkgs firefox_l10n_af, ...) In-Reply-To: <8972FBF3-0B28-4200-9874-22CABAEA82F3@opencsw.org> References: <4B838628.2040608@wbonnet.net> <68CBAB65-8BF7-42C1-AAA0-5B07D977834F@opencsw.org> <377F6978-3B43-4F0E-918B-42E484607D8D@opencsw.org> <8972FBF3-0B28-4200-9874-22CABAEA82F3@opencsw.org> Message-ID: <4B85B57A.5050807@opencsw.org> Dagobert Michelsen wrote on 24.02.2010 23:05: > Am 24.02.2010 um 21:29 schrieb Philip Brown: >> On Wed, Feb 24, 2010 at 2:52 AM, Dagobert Michelsen >> wrote: >>> Am 23.02.2010 um 17:40 schrieb Philip Brown: >>>> "If there is softname, softname_FOO, softname_BAR, softname_BAZ, >>>> and >>>> there are not separate mantis categories, you are expected to go >>>> file >>>> bugs for the base name 'softname' " >>> And pm_softname and py_softname? >> pm_xxx and py_xxxx do not tend to have sub-packages. I am not aware >> of even one. > > They may be subpackages of xxx, like for netsnmp or cyrus_imapd. That > means > they are generated in one go from the same set of sources during the > same > build. > >>>> Even a newbie user should be able to figure that one out as-is. >>> It should not replace the package listing. It is an additional page >>> like /bundles// which contains information about the package >>> in general (like how to use it) and links to the packages it >>> contains. >>> >>> The information should be quite easily optainable by just looking >>> at the >>> upstream URL in the info field: same field - same bundle. >> I do not see a sane, easily maintainable way to do this. If I did, I >> would add it in. But I dont see one. >> If you want to spend time in writing up an implementation that easily >> ties in to our existing processes, feel free. > > Sebastian: Is there such a concept in Mantis? If yes we can easily > create > the bundles out of the GAR recipes or by using the above described > procedure > for all other packages. I haven't followed this thread in depth, so I still don't quite get the exact concept and the benefits that your after. Let's talk on the phone this week, I guess that will clear things up. Or just put together a small wiki page, which provides an idea of the concept. I can then draw a comparison to how it is done in Debian and what is available in Mantis. To repeat what I already said on IRC: Mantis supports the concept of projects (which we already use) and sub-projects. The logic for the sub-projects was the reason why Mantis was so extremely slow before I hacked it (sub-project logic is gone now). Unless Mantis 1.2.x provides significant speed improvements in that area, I don't see us using them in the near future. But tests will have to show that. Do we need specific Mantis features at all for this or is this rather something that would be implemented in an abstraction layer above? Sebastian From james at opencsw.org Thu Feb 25 10:53:25 2010 From: james at opencsw.org (James Lee) Date: Thu, 25 Feb 2010 09:53:25 GMT Subject: [csw-maintainers] /testing spamassassin, bind, dhcp, dnstop In-Reply-To: <4B846E32.1000109@opencsw.org> References: <625385e31001261327k31719e1bo2bd90963eb99a3d2@mail.gmail.com> <4B79B4AC.9050204@opencsw.org> <625385e31002151303g47f8dafdp14d2805078188af2@mail.gmail.com> <4B79BA85.9010309@opencsw.org> <625385e31002151405m61536773kea6bbf01b030ba1b@mail.gmail.com> <273F3E70-15FF-40B6-B255-7E47372763D9@opencsw.org> <625385e31002160053y792724f8vcb1714286aec65c2@mail.gmail.com> <4B846E32.1000109@opencsw.org> Message-ID: <20100225.9532500.3103127085@gyor.oxdrove.co.uk> On 24/02/10, 00:09:22, Sebastian Kayser wrote regarding Re: [csw-maintainers] /testing spamassassin, bind, dhcp, dnstop: > James helped out to dig deeper into what exactly is going on here (I > faced a similar problem with autossh). The root cause as well as a > possible workaround are described in [1]. > In short: > * man page is written with roff macros from the doc macro package > (grog(1) can help to determine this), thus formatting it with the > an/man macro package - which is what man does by default - fails. > * "groff -m doc -Tascii -P-cuob " can be used to produce a > pre-formatted man page which can then be placed in > /opt/csw/share/man/catman from where it will simply be read > instead of being run through the roff chain. In the general case make sure the flags for egn, tbl, etc. are added if needed, eg, -e -t. grog will advise but it's easier to add always even when not needed. The proof is in typing man and reading the output after you have installed your package. > The second step is my simplistic approach after reading into the basics > of roff a bit, so there might be very well a "better" approach ... but > again, it does the job (and even better than the ugly workaround posted > earlier). This works and is the least effort so do it. Some people are in the habit of removing the cat files but this dates from when it paid to keep the formatted pages in cat, see catman(1). To prevent removal of package files setting no write permission on the package cat files would help. Man uses environmental variables TCAT and TROFF, eg for fancy man pages to the screen (-t was intended for printing): $ export TROFF="groff" $ export TCAT="/opt/csw/bin/gsview" # or gv or ... $ man -t ls depending on your shell... $ alias man='man -t' $ man ls however the man command missed a trick, man needs the equivalent for nroff. You can get close by hijacking the troff formatting: $ export TROFF="gnroff" $ export TCAT="more" $ man -t ls unfortunately man adds "-man" always so TROFF="gnroff -mdoc" doesn't work so this does not work for groff mdoc pages but does for groff man pages. NBG: $ export TROFF="gnroff -mdoc" $ export TCAT="more" $ man -t groff_mdoc It is possible to provide an alternate groff aware man command but a lot of the Solaris man pages are in SGML (Standard Generalized Markup Language) sgml(5) format and any substitute man command would have to work with the system man pages too. Here's a man system: http://primates.ximian.com/~flucifredi/man/) but I can't see that it is SGML aware so is of limited help. The best idea is to support, promote and provide traditional man pages. This isn't always easy, I do write roff macro packages to format my documents but was defeating by the groff man page conversion and (not worth my time, I pre-formatted into cat - spend time on useful tasks). > There is also some background on man vs. doc macro packages geared > towards man page writers at [2]. Quote: "do yourself a favor: use > tmac.an -- use of any other macro package is considered harmful." The bit I liked in groff_mdoc was "The -mdoc package attempts to simplify the process of writing a man page." - oh thanks. James. From bwalton at opencsw.org Thu Feb 25 17:34:12 2010 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 25 Feb 2010 11:34:12 -0500 Subject: [csw-maintainers] svn/testing release? Message-ID: <1267115593-sup-2291@pinkfloyd.chass.utoronto.ca> Hi Rupert, Are you planning to release the updated CSWsvn that is in testing? If you haven't had any feedback on it, I can give you some shortly. I'm going to be deploying it. :) 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 pfelecan at opencsw.org Thu Feb 25 18:27:29 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 25 Feb 2010 18:27:29 +0100 Subject: [csw-maintainers] complex trac issue In-Reply-To: (Maciej Blizinski's message of "Wed, 24 Feb 2010 13:37:53 +0000") References: <20100223142147.GB7613@sebastiankayser.de> Message-ID: "Maciej (Matchek) Blizinski" writes: > On Tue, Feb 23, 2010 at 3:01 PM, Peter FELECAN wrote: >> Sebastian Kayser writes: >> >>> * Maciej (Matchek) Blizinski wrote: >>>> On Tue, Feb 23, 2010 at 11:14 AM, Peter FELECAN wrote: >>>> > Installed and: >>>> > >>>> > trac-admin /tracs/test resync >>>> > Traceback (most recent call last): >>>> > ?File "/opt/csw/bin/trac-admin", line 5, in >>>> > ? ?from pkg_resources import load_entry_point >>>> > ?File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 2603, in >>>> > ? ?working_set.require(__requires__) >>>> > ?File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 666, in require >>>> > ? ?needed = self.resolve(parse_requirements(requirements)) >>>> > ?File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 565, in resolve >>>> > ? ?raise DistributionNotFound(req) ?# XXX put more info here >>>> > pkg_resources.DistributionNotFound: Trac==0.11.6 >>>> >>>> This one isn't as obvious. ?Setup tools can't find the right version >>>> of Trac; >>> >>> Could it be that our approach of not shipping .egg files is coming into >>> play here? > > Peter, have you tried investigating what is happening in this code? > If not, can you do that? Sorry to take time to answer but I was traveling to a customer site... As you asked me, I investigated the origin of the files in /opt/csw/lib/python/site-packages and all the files are from the CSWtrac package. However, I do not understand what do you mean by "right version of Trac is present in Trac files"... I didn't found a reference to Trac version in those files. Not being a Python expert I can, however, follow instructions of one... -- Peter From maciej at opencsw.org Thu Feb 25 18:34:58 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 25 Feb 2010 17:34:58 +0000 Subject: [csw-maintainers] complex trac issue In-Reply-To: References: <20100223142147.GB7613@sebastiankayser.de> Message-ID: > Peter, have you tried investigating what is happening in this code? > If not, can you do that? There's one more thing to try for you: trac package from experimental which includes the egg files. You could try if that changes anything. It's only a guess though, I still don't know what's the actual issue there. Maciej From maciej at opencsw.org Thu Feb 25 18:43:09 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 25 Feb 2010 17:43:09 +0000 Subject: [csw-maintainers] complex trac issue In-Reply-To: References: <20100223142147.GB7613@sebastiankayser.de> Message-ID: On Thu, Feb 25, 2010 at 5:27 PM, Peter FELECAN wrote: > As you asked me, I investigated the origin of the files in > /opt/csw/lib/python/site-packages and all the files are from the CSWtrac > package. However, I do not understand what do you mean by "right version > of Trac is present in Trac files"... ?I didn't found a reference to Trac > version in those files. The theory is that pysetuptools look into the egg files for information about installed packages. It can be thought of as the Python equivalent of SONAMEs (kind of). pysetuptools might look into the egg files to figure out the versions of installed packages. If the egg files are missing, pysetuptools think that the package is not installed, and they throw an errors. Trying the package from experimental would test this theory. Can you do that? From maciej at opencsw.org Thu Feb 25 18:44:35 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 25 Feb 2010 17:44:35 +0000 Subject: [csw-maintainers] complex trac issue In-Reply-To: References: <20100223142147.GB7613@sebastiankayser.de> Message-ID: On Thu, Feb 25, 2010 at 5:43 PM, Maciej (Matchek) Blizinski wrote: > installed, and they throw an errors. ...and I can't spells. ;-) But you get the idea. From pfelecan at opencsw.org Thu Feb 25 19:30:45 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 25 Feb 2010 19:30:45 +0100 Subject: [csw-maintainers] complex trac issue In-Reply-To: (Maciej Blizinski's message of "Thu, 25 Feb 2010 17:43:09 +0000") References: <20100223142147.GB7613@sebastiankayser.de> Message-ID: "Maciej (Matchek) Blizinski" writes: > On Thu, Feb 25, 2010 at 5:27 PM, Peter FELECAN wrote: >> As you asked me, I investigated the origin of the files in >> /opt/csw/lib/python/site-packages and all the files are from the CSWtrac >> package. However, I do not understand what do you mean by "right version >> of Trac is present in Trac files"... ?I didn't found a reference to Trac >> version in those files. > > The theory is that pysetuptools look into the egg files for > information about installed packages. It can be thought of as the > Python equivalent of SONAMEs (kind of). pysetuptools might look into > the egg files to figure out the versions of installed packages. If > the egg files are missing, pysetuptools think that the package is not > installed, and they throw an errors. > > Trying the package from experimental would test this theory. Can you do that? Yes. It moves the issue a step farther: trac-admin /tracs/test resync Traceback (most recent call last): File "/opt/csw/bin/trac-admin", line 5, in from pkg_resources import load_entry_point File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 2603, in working_set.require(__requires__) File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 666, in require needed = self.resolve(parse_requirements(requirements)) File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 565, in resolve raise DistributionNotFound(req) # XXX put more info here pkg_resources.DistributionNotFound: setuptools>=0.6b1 Maybe more eggs missing -- Peter From maciej at opencsw.org Thu Feb 25 19:45:52 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 25 Feb 2010 18:45:52 +0000 Subject: [csw-maintainers] complex trac issue In-Reply-To: References: <20100223142147.GB7613@sebastiankayser.de> Message-ID: On Thu, Feb 25, 2010 at 6:30 PM, Peter FELECAN wrote: > "Maciej (Matchek) Blizinski" writes: > >> On Thu, Feb 25, 2010 at 5:27 PM, Peter FELECAN wrote: >>> As you asked me, I investigated the origin of the files in >>> /opt/csw/lib/python/site-packages and all the files are from the CSWtrac >>> package. However, I do not understand what do you mean by "right version >>> of Trac is present in Trac files"... ?I didn't found a reference to Trac >>> version in those files. >> >> The theory is that pysetuptools look into the egg files for >> information about installed packages. ?It can be thought of as the >> Python equivalent of SONAMEs (kind of). ?pysetuptools might look into >> the egg files to figure out the versions of installed packages. ?If >> the egg files are missing, pysetuptools think that the package is not >> installed, and they throw an errors. >> >> Trying the package from experimental would test this theory. ?Can you do that? > > Yes. It moves the issue a step farther: > > trac-admin /tracs/test resync > Traceback (most recent call last): > ?File "/opt/csw/bin/trac-admin", line 5, in > ? ?from pkg_resources import load_entry_point > ?File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 2603, in > ? ?working_set.require(__requires__) > ?File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 666, in require > ? ?needed = self.resolve(parse_requirements(requirements)) > ?File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 565, in resolve > ? ?raise DistributionNotFound(req) ?# XXX put more info here > pkg_resources.DistributionNotFound: setuptools>=0.6b1 > > Maybe more eggs missing Good, change in the error message equals progress! pysetuptools are waiting for you in experimental. From pfelecan at opencsw.org Thu Feb 25 19:59:34 2010 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 25 Feb 2010 19:59:34 +0100 Subject: [csw-maintainers] complex trac issue In-Reply-To: (Maciej Blizinski's message of "Thu, 25 Feb 2010 18:45:52 +0000") References: <20100223142147.GB7613@sebastiankayser.de> Message-ID: "Maciej (Matchek) Blizinski" writes: > On Thu, Feb 25, 2010 at 6:30 PM, Peter FELECAN wrote: >> "Maciej (Matchek) Blizinski" writes: >> >>> On Thu, Feb 25, 2010 at 5:27 PM, Peter FELECAN wrote: >>>> As you asked me, I investigated the origin of the files in >>>> /opt/csw/lib/python/site-packages and all the files are from the CSWtrac >>>> package. However, I do not understand what do you mean by "right version >>>> of Trac is present in Trac files"... ?I didn't found a reference to Trac >>>> version in those files. >>> >>> The theory is that pysetuptools look into the egg files for >>> information about installed packages. ?It can be thought of as the >>> Python equivalent of SONAMEs (kind of). ?pysetuptools might look into >>> the egg files to figure out the versions of installed packages. ?If >>> the egg files are missing, pysetuptools think that the package is not >>> installed, and they throw an errors. >>> >>> Trying the package from experimental would test this theory. ?Can you do that? >> >> Yes. It moves the issue a step farther: >> >> trac-admin /tracs/test resync >> Traceback (most recent call last): >> ?File "/opt/csw/bin/trac-admin", line 5, in >> ? ?from pkg_resources import load_entry_point >> ?File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 2603, in >> ? ?working_set.require(__requires__) >> ?File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 666, in require >> ? ?needed = self.resolve(parse_requirements(requirements)) >> ?File "/opt/csw/lib/python/site-packages/pkg_resources.py", line 565, in resolve >> ? ?raise DistributionNotFound(req) ?# XXX put more info here >> pkg_resources.DistributionNotFound: setuptools>=0.6b1 >> >> Maybe more eggs missing > > Good, change in the error message equals progress! pysetuptools are > waiting for you in experimental. It works: trac-admin /tracs/test resync Resyncing repository history... 0 revisions cached. Done. The learned lesson is that the eggs must be laid in the nest. -- Peter From maciej at opencsw.org Thu Feb 25 20:16:46 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 25 Feb 2010 19:16:46 +0000 Subject: [csw-maintainers] complex trac issue In-Reply-To: References: <20100223142147.GB7613@sebastiankayser.de> Message-ID: On Thu, Feb 25, 2010 at 6:59 PM, Peter FELECAN wrote: > It works: > > trac-admin /tracs/test resync > Resyncing repository history... > 0 revisions cached. > Done. > > The learned lesson is that the eggs must be laid in the nest. Updated packages have been sent for release. I also submitted a change to GAR, which makes all Python builds include egg files by default. Maciej From maciej at opencsw.org Thu Feb 25 22:23:58 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 25 Feb 2010 21:23:58 +0000 Subject: [csw-maintainers] solaris history question In-Reply-To: <1251074721-sup-2144@ntdws12.chass.utoronto.ca> References: <1251074721-sup-2144@ntdws12.chass.utoronto.ca> Message-ID: On Mon, Aug 24, 2009 at 1:04 AM, Ben Walton wrote: > I've discovered an interesting bit of solaris archaeology today and I > wanted to ask those with longer solaris memory why such a thing is > still supported. > > Long before I ever encountered a shell, ^ was the symbol used to > separate commands in a pipeline. ?It seems that solaris' /bin/sh is > still allowing this in some cases. It hit me today when I was building sharutils: they have an unquoted caret in a /bin/sh script[1]. Thanks for this e-mail Ben, remembering it sped up solving the problem for me. Maciej [1] https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/sharutils/trunk/files/sun-sed.patch From skayser at opencsw.org Thu Feb 25 23:30:55 2010 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 25 Feb 2010 23:30:55 +0100 Subject: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all? In-Reply-To: <4AC10A87.1090205@opencsw.org> References: <4AC10A87.1090205@opencsw.org> Message-ID: <4B86FA1F.8080608@opencsw.org> Sebastian Kayser wrote on 28.09.2009 21:12: > pkgutil was placed straight at the mirror root a while ago to facilitate > downloading, but it doesn't seem to get updates. The version floating > around [1,2] is 1.5, most recent pkgutil is 1.7. Could this please be > fixed (and be kept in sync in the future pleeeaase :). pkgutil is currently at 1.9.1, version at the mirror roots is 1.7. My mantra still is: could this be updated for now and be kept in sync in the future please. Sebastian From dam at opencsw.org Fri Feb 26 09:56:35 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 26 Feb 2010 09:56:35 +0100 Subject: [csw-maintainers] CSWoldap In-Reply-To: <940F857E6596B84BAFD05DBA869276E23504F1148A@CON-EX-001.connectis.local> 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> Message-ID: Hi David, Am 24.02.2010 um 16:26 schrieb Mantock David: > I followed the normal procedure for packaging with gar. > My environment does not override the /etc/opt/csw/garrc BUILDHOST or > PACKAGING_HOST variables. > > ------------snip---------------------------------------------- > dlm at login [login]:~ > ssh build10x > Last login: Mon Feb 22 09:38:04 2010 from login.bo.opencs > Sun Microsystems Inc. SunOS 5.10 Generic January 2005 > dlm at build10x [global]:~ > which gmake > no gmake in /usr/bin /usr/sbin /sbin /usr/ccs/bin /usr/dt/bin /usr/ > openwin/bin /opt/bop/bin /usr/sfw/bin /usr/sfw/sbin > > ------------ > snip > ----------------------------------------------------------------------------- > > > If I only wanted to build a package for this architecture shouldn't > the gar stuff be here anyway? It is, but as Maciej and Sebastian pointed out /opt/csw/bin is not in the default path. Until now it was in the responsibility of the maintainer to set up PATH correctly, but I do see the argument and will change it so the default path is set up correctly. To multi-ISA GAR: Usually you don't need to hop over to build10x. Usually you go to build8x and say gmake package and it hops over to any machine necessary. If you go to build10x to debug the amd64 build make sure to make the i386 32 bit version first on build8s. GAR builds them in order and would otherwise try to build 32 bit on build10x which is not correct. Best regards -- Dago From dam at opencsw.org Fri Feb 26 21:21:15 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 26 Feb 2010 21:21:15 +0100 Subject: [csw-maintainers] Updating buildfarm now In-Reply-To: <4B880091.2040508@opencsw.org> References: <4B880091.2040508@opencsw.org> Message-ID: Hi John, Am 26.02.2010 um 18:10 schrieb John Ellson: > There have been not-so-recent updates to "gd" and "swig" that > haven't been installed on the buildfarms > yet. I'm wondering if I've misunderstood some process? The packages on the farm are updates on request by mail to buildfarm@ or on a scheduled downtime every couple of month when I patch the machines. > Shouldn't the buildfarms be kept up to date with the absolute > latest, so that other packages that depend on updated packages and > that are waiting for fixes, can be built? Usually there are no hard constraints on package versions. When there are needs for new versions just mail to buildfarm@ that you want the packages updated after release. > Is there some other mechanism that I'm not aware of to tell a build > to use a test package rather than a stable package, perhaps? Requesting ;-) As you obviously want the new versions I am updating all farm machines now to current/. Best regards -- Dago From maciej at opencsw.org Sat Feb 27 00:32:44 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 26 Feb 2010 23:32:44 +0000 Subject: [csw-maintainers] Autoresponder spamming the users mailing list (Was: Vacation reply) Message-ID: Can we prevent this guy from posting on the list? His autoresponder is spamming us. ---------- Forwarded message ---------- From: Date: Fri, Feb 26, 2010 at 11:10 PM Subject: [csw-users] Vacation reply To: users at lists.opencsw.org FU? fu? #*? 38 _______________________________________________ users mailing list users at lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/users From bwalton at opencsw.org Sat Feb 27 00:37:44 2010 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 26 Feb 2010 18:37:44 -0500 Subject: [csw-maintainers] Fwd: [csw-users] Vacation reply Message-ID: <1267227424-sup-8960@pinkfloyd.chass.utoronto.ca> Is a vacation responder this dumb even possible without intent? Thanks -Ben --- Begin forwarded message from sovrez --- From: sovrez To: users Date: Fri, 26 Feb 2010 18:10:05 -0500 Subject: [csw-users] Vacation reply FU? fu? #*? 38 --- End forwarded message --- -------------- 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 Sat Feb 27 00:39:35 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 26 Feb 2010 23:39:35 +0000 Subject: [csw-maintainers] Fwd: [csw-users] Vacation reply In-Reply-To: <1267227424-sup-8960@pinkfloyd.chass.utoronto.ca> References: <1267227424-sup-8960@pinkfloyd.chass.utoronto.ca> Message-ID: On Fri, Feb 26, 2010 at 11:37 PM, Ben Walton wrote: > Is a vacation responder this dumb even possible without intent? Never underestimate... I suggest stopping to accept e-mail to the mailing list from this address. From bwalton at opencsw.org Sat Feb 27 00:51:02 2010 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 26 Feb 2010 18:51:02 -0500 Subject: [csw-maintainers] Fwd: [csw-users] Vacation reply In-Reply-To: References: <1267227424-sup-8960@pinkfloyd.chass.utoronto.ca> Message-ID: <1267228252-sup-5760@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Fri Feb 26 18:39:35 -0500 2010: > On Fri, Feb 26, 2010 at 11:37 PM, Ben Walton wrote: > Never underestimate... > > I suggest stopping to accept e-mail to the mailing list from this address. +1. -Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From hson at opencsw.org Sat Feb 27 04:09:29 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Sat, 27 Feb 2010 04:09:29 +0100 Subject: [csw-maintainers] Duplicate package xextproto/x11_xextproto Message-ID: <4B888CE9.40406@opencsw.org> Which package is "the real stuff", xextproto or x11_xextproto? They both seem to have the exact same content. From hson at opencsw.org Sat Feb 27 05:56:07 2010 From: hson at opencsw.org (=?UTF-8?B?Um9nZXIgSMOla2Fuc3Nvbg==?=) Date: Sat, 27 Feb 2010 05:56:07 +0100 Subject: [csw-maintainers] [libxext_devel 0004314]: xext.pc has xextproto as requirement, but no package dependency In-Reply-To: References: Message-ID: <4B88A5E7.6000306@opencsw.org> On 2010-02-27 05:43, Mantis Bug Tracker wrote: > > The following issue has been SUBMITTED. > ====================================================================== > http://www.opencsw.org/mantis/view.php?id=4314 ... > xext.pc has xextproto as requirement but libext_devel doesn't have > x11_xextproto (or xextproto whichever is the correct package) as dependency > ====================================================================== > Suggestion: Couldn't this kind of check be done with a checkpkg module? (No, I can't write it myself, I'm illiterate when it comes to python) From dam at opencsw.org Sat Feb 27 14:44:39 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 27 Feb 2010 14:44:39 +0100 Subject: [csw-maintainers] Adapting /home/testing cleaner to /home/experimental In-Reply-To: References: Message-ID: <5122D55F-CFD7-478C-9AD3-0A0BA316590B@opencsw.org> Hi, Am 27.02.2010 um 01:08 schrieb Maciej (Matchek) Blizinski: > Can the script that cleans /home/testing from released files be used > to clean also /home/experimental? Sure. I haven't done so yet because I don't know if this is what maintainers expect. Should only the packages from the current catalog be removed? Or also stable? Or allpkgs/ ? If we have consensus I can activate it any time. Best regards -- Dago From dam at opencsw.org Sat Feb 27 14:49:12 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 27 Feb 2010 14:49:12 +0100 Subject: [csw-maintainers] [libxext_devel 0004314]: xext.pc has xextproto as requirement, but no package dependency In-Reply-To: <4B88A5E7.6000306@opencsw.org> References: <4B88A5E7.6000306@opencsw.org> Message-ID: <6BBCD1F0-DAD9-4780-86E1-431E054AEDB8@opencsw.org> Hi Roger, Am 27.02.2010 um 05:56 schrieb Roger H?kansson: > On 2010-02-27 05:43, Mantis Bug Tracker wrote: >> >> The following issue has been SUBMITTED. >> ====================================================================== >> http://www.opencsw.org/mantis/view.php?id=4314 > ... >> xext.pc has xextproto as requirement but libext_devel doesn't have >> x11_xextproto (or xextproto whichever is the correct package) as dependency >> ====================================================================== >> > > Suggestion: > Couldn't this kind of check be done with a checkpkg module? (No, I can't write it myself, I'm illiterate when it comes to python) The more interesting question is: If the dependency is real, why hasn't it been cought up during link symbol checking? I don't see much value in checking redundant .pc files. Best regards -- Dago From maciej at opencsw.org Sat Feb 27 15:09:04 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 27 Feb 2010 14:09:04 +0000 Subject: [csw-maintainers] Adapting /home/testing cleaner to /home/experimental In-Reply-To: <5122D55F-CFD7-478C-9AD3-0A0BA316590B@opencsw.org> References: <5122D55F-CFD7-478C-9AD3-0A0BA316590B@opencsw.org> Message-ID: On Sat, Feb 27, 2010 at 1:44 PM, Dagobert Michelsen wrote: > Hi, > > Am 27.02.2010 um 01:08 schrieb Maciej (Matchek) Blizinski: >> Can the script that cleans /home/testing from released files be used >> to clean also /home/experimental? > > Sure. I haven't done so yet because I don't know if this is what maintainers > expect. Should only the packages from the current catalog be removed? Or > also stable? Or allpkgs/ ? If we have consensus I can activate it any time. I think that stable plus current would be good. I'm not sure about allpkgs, whether it's necessary. In the day-to-day work, removing packages matching those in current is the most important. From hson at opencsw.org Sat Feb 27 17:10:04 2010 From: hson at opencsw.org (=?ISO-8859-1?Q?Roger_H=E5kansson?=) Date: Sat, 27 Feb 2010 17:10:04 +0100 Subject: [csw-maintainers] [libxext_devel 0004314]: xext.pc has xextproto as requirement, but no package dependency In-Reply-To: <6BBCD1F0-DAD9-4780-86E1-431E054AEDB8@opencsw.org> References: <4B88A5E7.6000306@opencsw.org> <6BBCD1F0-DAD9-4780-86E1-431E054AEDB8@opencsw.org> Message-ID: <4B8943DC.6050908@opencsw.org> On 2010-02-27 14:49, Dagobert Michelsen wrote: > Hi Roger, > > Am 27.02.2010 um 05:56 schrieb Roger H?kansson: >> On 2010-02-27 05:43, Mantis Bug Tracker wrote: >>> >>> The following issue has been SUBMITTED. >>> ====================================================================== >>> http://www.opencsw.org/mantis/view.php?id=4314 >> ... >>> xext.pc has xextproto as requirement but libext_devel doesn't have >>> x11_xextproto (or xextproto whichever is the correct package) as dependency >>> ====================================================================== >>> >> >> Suggestion: >> Couldn't this kind of check be done with a checkpkg module? (No, I can't write it myself, I'm illiterate when it comes to python) > > The more interesting question is: If the dependency is real, why hasn't > it been cought up during link symbol checking? I don't see much value in > checking redundant .pc files. Because the dependency isn't symbol based rather then on header files. And even if there had been a lib dependency this kind of dependency wouldn't have been caught. Example: Package A have liba.so, A_devel a.pc, B libc.so which depends on liba.so, and B_devel b.pc which have a.pc as a requirement. When building the packages B will have A as a required dependency and checkpkg will sugggest that A_devel needs A and B_devel needs B, but not that B_devel needs A_devel. From maciej at opencsw.org Sat Feb 27 18:03:03 2010 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 27 Feb 2010 17:03:03 +0000 Subject: [csw-maintainers] [libxext_devel 0004314]: xext.pc has xextproto as requirement, but no package dependency In-Reply-To: <4B8943DC.6050908@opencsw.org> References: <4B88A5E7.6000306@opencsw.org> <6BBCD1F0-DAD9-4780-86E1-431E054AEDB8@opencsw.org> <4B8943DC.6050908@opencsw.org> Message-ID: On Sat, Feb 27, 2010 at 4:10 PM, Roger H?kansson wrote: > Example: > Package A have liba.so, A_devel a.pc, B libc.so which depends on liba.so, > and B_devel b.pc which have a.pc as a requirement. > When building the packages B will have A as a required dependency and > checkpkg will sugggest that A_devel needs A and B_devel needs B, but not > that B_devel needs A_devel. What would the algorithm look like? Something like this comes to mind: - parse pkgconfig/*.pc files - assemble a list of referenced.pc files - based on /var/sadm/install/contents figure out which packages provide those files - require dependency on the found packages Is already a parser of .pc files? Maciej From hson at opencsw.org Sat Feb 27 18:27:24 2010 From: hson at opencsw.org (=?UTF-8?B?Um9nZXIgSMOla2Fuc3Nvbg==?=) Date: Sat, 27 Feb 2010 18:27:24 +0100 Subject: [csw-maintainers] [libxext_devel 0004314]: xext.pc has xextproto as requirement, but no package dependency In-Reply-To: References: <4B88A5E7.6000306@opencsw.org> <6BBCD1F0-DAD9-4780-86E1-431E054AEDB8@opencsw.org> <4B8943DC.6050908@opencsw.org> Message-ID: <4B8955FC.8010108@opencsw.org> On 2010-02-27 18:03, Maciej (Matchek) Blizinski wrote: > On Sat, Feb 27, 2010 at 4:10 PM, Roger H?kansson wrote: >> Example: >> Package A have liba.so, A_devel a.pc, B libc.so which depends on liba.so, >> and B_devel b.pc which have a.pc as a requirement. >> When building the packages B will have A as a required dependency and >> checkpkg will sugggest that A_devel needs A and B_devel needs B, but not >> that B_devel needs A_devel. > > What would the algorithm look like? Something like this comes to mind: > > - parse pkgconfig/*.pc files > - assemble a list of referenced.pc files > - based on /var/sadm/install/contents figure out which packages > provide those files > - require dependency on the found packages Something like that, yes. > Is already a parser of .pc files? The only one I know of is pkg-config... From dam at opencsw.org Sat Feb 27 22:49:00 2010 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 27 Feb 2010 22:49:00 +0100 Subject: [csw-maintainers] Adapting /home/testing cleaner to /home/experimental In-Reply-To: References: <5122D55F-CFD7-478C-9AD3-0A0BA316590B@opencsw.org> Message-ID: <363EBF47-92FA-419B-A66E-9241B409D995@opencsw.org> Hi Maciej, Am 27.02.2010 um 15:09 schrieb Maciej (Matchek) Blizinski: > On Sat, Feb 27, 2010 at 1:44 PM, Dagobert Michelsen > wrote: >> Am 27.02.2010 um 01:08 schrieb Maciej (Matchek) Blizinski: >>> Can the script that cleans /home/testing from released files be used >>> to clean also /home/experimental? >> >> Sure. I haven't done so yet because I don't know if this is what >> maintainers >> expect. Should only the packages from the current catalog be >> removed? Or >> also stable? Or allpkgs/ ? If we have consensus I can activate it >> any time. > > I think that stable plus current would be good. I'm not sure about > allpkgs, whether it's necessary. In the day-to-day work, removing > packages matching those in current is the most important. Done. Experimental is now cleaned from released packages daily. To be removed the file in experimental must have the same name and must be identical to the released one. Best regards -- Dago From David.Mantock at connectis.ch Thu Feb 25 15:09:16 2010 From: David.Mantock at connectis.ch (Mantock David) Date: Thu, 25 Feb 2010 15:09:16 +0100 Subject: [csw-maintainers] CSWoldap In-Reply-To: <20100224185030.GC7613@sebastiankayser.de> References: <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> <20100224185030.GC7613@sebastiankayser.de> Message-ID: <940F857E6596B84BAFD05DBA869276E23504F115D3@CON-EX-001.connectis.local> 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. Small point but there is also a reference to Blastwave in the script:-( Cheers, David -----Original Message----- From: maintainers-bounces+dlm=opencsw.org at lists.opencsw.org [mailto:maintainers-bounces+dlm=opencsw.org at lists.opencsw.org] On Behalf Of Sebastian Kayser Sent: Mittwoch, 24. Februar 2010 19:51 To: List for OpenCSW maintainers Subject: Re: [csw-maintainers] CSWoldap * Maciej (Matchek) Blizinski wrote: > On Wed, Feb 24, 2010 at 3:26 PM, Mantock David > wrote: > > I followed the normal procedure for packaging with gar. > > My environment does not override the /etc/opt/csw/garrc BUILDHOST or PACKAGING_HOST variables. > > > > ------------snip---------------------------------------------- > > dlm at login [login]:~ > ssh build10x > > Last login: Mon Feb 22 09:38:04 2010 from login.bo.opencs > > Sun Microsystems Inc. SunOS 5.10 Generic January 2005 > > dlm at build10x [global]:~ > which gmake > > no gmake in /usr/bin /usr/sbin /sbin /usr/ccs/bin /usr/dt/bin /usr/openwin/bin /opt/bop/bin /usr/sfw/bin /usr/sfw/sbin > > > > ------------snip----------------------------------------------------------------------------- > > > > > > If I only wanted to build a package for this architecture shouldn't the gar stuff be here anyway? > > Your PATH seems to be missing /opt/csw/bin. How about adding this to the PATH on the buildfarm hosts per default? Sebastian _______________________________________________ maintainers mailing list maintainers at lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::. This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of connectis AG. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please destroy the message and/or contact the sender if you believe you have received this email in error. From david.mantock at gmx.ch Fri Feb 26 10:08:12 2010 From: david.mantock at gmx.ch (David Mantock) Date: Fri, 26 Feb 2010 10:08:12 +0100 Subject: [csw-maintainers] CSWoldap In-Reply-To: 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> Message-ID: <20100226090812.41300@gmx.net> Hi Dago, Thanks for that. 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. Small point but there is also a reference to Blastwave in the script:-( Cheers, David -------- Original-Nachricht -------- > Datum: Fri, 26 Feb 2010 09:56:35 +0100 > Von: Dagobert Michelsen > An: List for OpenCSW maintainers > Betreff: Re: [csw-maintainers] CSWoldap > Hi David, > > Am 24.02.2010 um 16:26 schrieb Mantock David: > > I followed the normal procedure for packaging with gar. > > My environment does not override the /etc/opt/csw/garrc BUILDHOST or > > PACKAGING_HOST variables. > > > > ------------snip---------------------------------------------- > > dlm at login [login]:~ > ssh build10x > > Last login: Mon Feb 22 09:38:04 2010 from login.bo.opencs > > Sun Microsystems Inc. SunOS 5.10 Generic January 2005 > > dlm at build10x [global]:~ > which gmake > > no gmake in /usr/bin /usr/sbin /sbin /usr/ccs/bin /usr/dt/bin /usr/ > > openwin/bin /opt/bop/bin /usr/sfw/bin /usr/sfw/sbin > > > > ------------ > > snip > > > ----------------------------------------------------------------------------- > > > > > > If I only wanted to build a package for this architecture shouldn't > > the gar stuff be here anyway? > > It is, but as Maciej and Sebastian pointed out /opt/csw/bin is not in > the default path. > Until now it was in the responsibility of the maintainer to set up > PATH correctly, but > I do see the argument and will change it so the default path is set up > correctly. > > To multi-ISA GAR: Usually you don't need to hop over to build10x. > Usually you go to > build8x and say > gmake package > and it hops over to any machine necessary. If you go to build10x to > debug the amd64 build > make sure to make the i386 32 bit version first on build8s. GAR builds > them in order > and would otherwise try to build 32 bit on build10x which is not > correct. > > > 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. ::. -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser From dam at baltic-online.de Fri Feb 26 16:16:17 2010 From: dam at baltic-online.de (Dagobert Michelsen) Date: Fri, 26 Feb 2010 16:16:17 +0100 Subject: [csw-maintainers] Restart: cvsproxy release In-Reply-To: References: <625385e30911101128x219298e0s9b7d7c56eed3d386@mail.gmail.com> Message-ID: <8C073C7B-6F23-41C2-9C33-055FEC3F1FD3@baltic-online.de> Hi, there hasn't been much progress on this topic, so I'll grab out my old mail: Am 10.11.2009 um 20:37 schrieb Dagobert Michelsen: > Am 10.11.2009 um 20:28 schrieb Peter Bonivart: >> On Tue, Nov 10, 2009 at 8:22 PM, Dagobert Michelsen >> wrote: >>> I noticed cvsproxy is still in testing/. Is it ready for release? >> >> James complained about an old bug with the current release. If people >> upgrade the remove procedure of the old package may screw up >> inetd.conf and James wants my package to make sure this doesn't >> happen. > > Just looked. I guess it is time now for the package hooks. We need > a global directory with script to fix messed-up stuff like package > renames and this kind. In this case it should be some kind of > on-upgrade-start: > if( package eq "CSWcvsproxy" && version eq "1.0.1" ) then > if( readlink( /etc/inetd.conf ) eq "./inet/inetd.conf" ) then > touch /var/run/CSWcvsproxy-redo-link > > on-upgrade-end: > if( package eq "CSWcvsproxy" && version eq "1.0.1" ) then > if( -f /var/run/CSWcvsproxy-redo-link ) > rm -f /etc/inetd.conf > ln -s ./inet/inetd.conf /etc/inetd.conf > > Hey, you did implement package hooks only days away, so this should > be really > easy. What is left is a concept on how to bundle and distribute these > fix-hooks. On each upgrade they must be updated first. Now, any feedback on this? I want cvsproxy released soon. Best regards -- Dago