From dam at opencsw.org Thu Oct 1 09:23:53 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 1 Oct 2009 09:23:53 +0200 Subject: [csw-maintainers] Handling of devel package splits Message-ID: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> Hi, I am currently packaging up a load of X11 packages. Some of them have a load of development-stuff (headers, etc.) in them, some only a few header files. I tend to split off the development stuff for all of them in _devel-packages for consistency, but as we don't have an explicit policy on this I would like to open up a small discussion if you would consider it feasible to split even for a few files for consistency. The alternative would be to split on a "by case" basis where some packages with many header files would have a devel package and some would include them in the base package. After a brief discussion I would like to open a poll for this. Thoughts? Best regards -- Dago From maciej at opencsw.org Thu Oct 1 11:15:32 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 1 Oct 2009 10:15:32 +0100 Subject: [csw-maintainers] V8+ binaries produced by gcc on build10s In-Reply-To: References: Message-ID: I have a relatively straightforward build: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/urxvt/trunk/Makefile After building the package on build10s, I see this: urxvt: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, stripped urxvtc: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, stripped urxvtd: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, stripped I've added -mno-v8plus to the compiler flags. gmake modenv says: CFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include CXXFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include Why is gcc still producing V8+ binaries? Is there a way to influence it? Maciej From james at opencsw.org Thu Oct 1 11:21:49 2009 From: james at opencsw.org (James Lee) Date: Thu, 01 Oct 2009 09:21:49 GMT Subject: [csw-maintainers] V8+ binaries produced by gcc on build10s In-Reply-To: References: Message-ID: <20091001.9214900.2853304098@gyor.oxdrove.co.uk> On 01/10/09, 10:15:32, Maciej "(Matchek)" Blizinski wrote regarding Re: [csw-maintainers] V8+ binaries produced by gcc on build10s: > After building the package on build10s, I see this: > urxvt: ELF 32-bit MSB executable SPARC32PLUS Version 1, > V8+ Required, dynamically linked, stripped > Why is gcc still producing V8+ binaries? Solaris 10 is at least v8plus so it's the right thing to do anyway. James. From dam at opencsw.org Thu Oct 1 11:35:41 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 1 Oct 2009 11:35:41 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> Message-ID: <2CEA8E5F-75B6-4EC1-969B-680BD2875FB8@opencsw.org> Hi, Am 01.10.2009 um 09:23 schrieb Dagobert Michelsen: > I am currently packaging up a load of X11 packages. Some of them > have a load of development-stuff (headers, etc.) in them, some > only a few header files. I tend to split off the development stuff > for all of them in _devel-packages for consistency, but as we don't > have an explicit policy on this I would like to open up a small > discussion if you would consider it feasible to split even for > a few files for consistency. The alternative would be to split > on a "by case" basis where some packages with many header files > would have a devel package and some would include them in the > base package. > > After a brief discussion I would like to open a poll for this. As we already had some discussion on IRC, here is the poll: Best regards -- Dago From dam at opencsw.org Thu Oct 1 11:40:13 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 1 Oct 2009 11:40:13 +0200 Subject: [csw-maintainers] V8+ binaries produced by gcc on build10s In-Reply-To: References: Message-ID: <349006FB-5015-4EA1-93DB-30297CA6A587@opencsw.org> Am 01.10.2009 um 11:15 schrieb Maciej (Matchek) Blizinski: > I have a relatively straightforward build: > > https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/urxvt/trunk/Makefile > > After building the package on build10s, I see this: > > urxvt: ELF 32-bit MSB executable SPARC32PLUS Version 1, > V8+ Required, dynamically linked, stripped > urxvtc: ELF 32-bit MSB executable SPARC32PLUS Version 1, > V8+ Required, dynamically linked, stripped > urxvtd: ELF 32-bit MSB executable SPARC32PLUS Version 1, > V8+ Required, dynamically linked, stripped > > I've added -mno-v8plus to the compiler flags. gmake modenv says: > > CFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include > CXXFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include > > Why is gcc still producing V8+ binaries? Is there a way to influence > it? This seems like a bug. Is there something on the GCC lists? Best regards -- Dago From dam at opencsw.org Thu Oct 1 11:45:08 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 1 Oct 2009 11:45:08 +0200 Subject: [csw-maintainers] V8+ binaries produced by gcc on build10s In-Reply-To: <349006FB-5015-4EA1-93DB-30297CA6A587@opencsw.org> References: <349006FB-5015-4EA1-93DB-30297CA6A587@opencsw.org> Message-ID: <54D09782-36B2-4653-9CEC-8D3CCC82FB8E@opencsw.org> Hi Maciej, Am 01.10.2009 um 11:40 schrieb Dagobert Michelsen: > Am 01.10.2009 um 11:15 schrieb Maciej (Matchek) Blizinski: > >> I have a relatively straightforward build: >> >> https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/urxvt/trunk/Makefile >> >> After building the package on build10s, I see this: >> >> urxvt: ELF 32-bit MSB executable SPARC32PLUS Version 1, >> V8+ Required, dynamically linked, stripped >> urxvtc: ELF 32-bit MSB executable SPARC32PLUS Version 1, >> V8+ Required, dynamically linked, stripped >> urxvtd: ELF 32-bit MSB executable SPARC32PLUS Version 1, >> V8+ Required, dynamically linked, stripped >> >> I've added -mno-v8plus to the compiler flags. gmake modenv says: >> >> CFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include >> CXXFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include >> >> Why is gcc still producing V8+ binaries? Is there a way to >> influence it? > > This seems like a bug. Is there something on the GCC lists? It looks like the compilation is ok, but as the provided libs in Solaris 10 are sparcv8plus the resulting binary is also: rxvtd: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, not stripped rxvtd.o: ELF 32-bit MSB relocatable SPARC Version 1 The object files are compiled correctly. Best regards -- Dago From james at opencsw.org Thu Oct 1 11:57:29 2009 From: james at opencsw.org (James Lee) Date: Thu, 01 Oct 2009 09:57:29 GMT Subject: [csw-maintainers] V8+ binaries produced by gcc on build10s In-Reply-To: <54D09782-36B2-4653-9CEC-8D3CCC82FB8E@opencsw.org> References: <349006FB-5015-4EA1-93DB-30297CA6A587@opencsw.org> <54D09782-36B2-4653-9CEC-8D3CCC82FB8E@opencsw.org> Message-ID: <20091001.9572900.1429675141@gyor.oxdrove.co.uk> On 01/10/09, 10:45:08, Dagobert Michelsen wrote regarding Re: [csw-maintainers] V8+ binaries produced by gcc on build10s: > >> > >> I've added -mno-v8plus to the compiler flags. gmake modenv says: > >> > >> CFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include > >> CXXFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include > >> > >> Why is gcc still producing V8+ binaries? Is there a way to > >> influence it? > > > > This seems like a bug. Is there something on the GCC lists? > It looks like the compilation is ok, but as the provided libs in > Solaris 10 > are sparcv8plus the resulting binary is also: > rxvtd: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ > Required, dynamically linked, not stripped > rxvtd.o: ELF 32-bit MSB relocatable SPARC Version 1 Because Solaris 10 is. Don't target a processor that can't run the OS. Set the compile flags to target what Solaris 10 will run. James. From james at opencsw.org Thu Oct 1 11:53:32 2009 From: james at opencsw.org (James Lee) Date: Thu, 01 Oct 2009 09:53:32 GMT Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <2CEA8E5F-75B6-4EC1-969B-680BD2875FB8@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <2CEA8E5F-75B6-4EC1-969B-680BD2875FB8@opencsw.org> Message-ID: <20091001.9533200.3095871799@gyor.oxdrove.co.uk> On 01/10/09, 10:35:41, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Handling of devel package splits: > Am 01.10.2009 um 09:23 schrieb Dagobert Michelsen: > > I am currently packaging up a load of X11 packages. Some of them > > have a load of development-stuff (headers, etc.) in them, some > > only a few header files. I tend to split off the development stuff > > for all of them in _devel-packages for consistency, but as we don't > > have an explicit policy on this I would like to open up a small > > discussion if you would consider it feasible to split even for > > a few files for consistency. The alternative would be to split > > on a "by case" basis where some packages with many header files > > would have a devel package and some would include them in the > > base package. > > > > After a brief discussion I would like to open a poll for this. > As we already had some discussion on IRC, here is the poll: > You are missing an option. If foo is a distribution, I install foo and I get CSWfoo with all foo's files. How that is split doesn't matter, eg, comprises an rt sub package, is split into arch neutral and binary. Package depends can bring in the rt only but I think that installing a product by name should install that product, a 1:1 correspondence between upstream product and top level package with the same name. Expanding this packages are of 2 types: those one installs and those installed automatically because they are required by others. Where we install by choice the naming matters. When it's a installed as depend sub division is right. X11 packages are typical of things users don't explicitly install. James. From phil at bolthole.com Thu Oct 1 18:16:29 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 1 Oct 2009 09:16:29 -0700 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <2CEA8E5F-75B6-4EC1-969B-680BD2875FB8@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <2CEA8E5F-75B6-4EC1-969B-680BD2875FB8@opencsw.org> Message-ID: On Thu, Oct 1, 2009 at 2:35 AM, Dagobert Michelsen wrote: > >> After a brief discussion I would like to open a poll for this. > > As we already had some discussion on IRC, here is the poll: > ? > I think this is a very unfair way to handle things. Discussions for official packaging issues, should either be done on the mailing list, or at MINIMUM, the full irc logs need to be posted. I do not see any reference to irc logs. From phil at bolthole.com Thu Oct 1 18:29:45 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 1 Oct 2009 09:29:45 -0700 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> Message-ID: The poll is inadequately described. For such a critical, major policy change such as this, you must be more explicit. The poll should describe what "split off devel" means. First, (presuming this is your intent), you should explicitly say, "MUST split off _devel". then you need to describe everything that should go in there. ALSO, you did not adequately describe potential justifications for when things should be split off vs not, for the "case by case basis". For example, the criteria that I personally use, are the following: a) Any time a maintainer wishes to provide a static library, it should be done in a separate _devel package b) when there are excessive amounts of development specific documentation, that belong more in a _devel package, than a _doc package. (eg: if there is substantial user documentation, but also substantial development documentation), it MAY be a good idea to split off the devel docs. c) when there's a bunch of development-useful-only tools, it MAY be useful to split them off. Generally speaking, when splitting off devel stuff saves 20% of the package, or a megabyte or more of download size. HOWEVER, none of the above to me are really important, if the _devel package is going to be something silly like 20k in size. or if a single combined package is going to be "small" anyway. The particular case in point: Dago is interested in splitting up "xpm", into "libxpm", and "libxpm_devel". The entire package, if it were one package, is 155k for sparc, and 88k for x86. The "devel" package, is 5k. yes, 5830 bytes. From dam at opencsw.org Thu Oct 1 20:45:22 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 1 Oct 2009 20:45:22 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> Message-ID: <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> Hi, Am 01.10.2009 um 18:29 schrieb Philip Brown: > The particular case in point: > Dago is interested in splitting up "xpm", into "libxpm", and > "libxpm_devel". > > The entire package, if it were one package, is 155k for sparc, and > 88k for x86. > The "devel" package, is 5k. yes, 5830 bytes. I specifically didn't do it for size, but for clearness and consistency. And I think the tradeoff of having a clean split against one more package is IMHO worthwhile. Best regards -- Dago From phil at bolthole.com Thu Oct 1 21:15:45 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 1 Oct 2009 12:15:45 -0700 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> Message-ID: On Thu, Oct 1, 2009 at 11:45 AM, Dagobert Michelsen wrote: > Hi, > > Am 01.10.2009 um 18:29 schrieb Philip Brown: >> >> The entire package, if it were one package, is 155k for sparc, and 88k for >> x86. >> The "devel" package, is 5k. yes, 5830 bytes. > > I specifically didn't do it for size, but for clearness and consistency. And > I think the tradeoff of having a clean split against one more package is > IMHO worthwhile. And I understand that point. My own opinion, is that fewer packages, makes for better "clearness" for our users, when there isnt a noticable benefit from splitting them up into mulitple. I cant see us ever splitting ALL our packages up into CSWmain vs CSWmain-doc While it would be "consistent", it would also be insane overkill, in my opinion :) So for similar reasoning, I dont think we should split up ALL packages to be CSWmain vs CSWmain-devel Just in the cases where there is actual benefit. From dam at opencsw.org Thu Oct 1 21:29:01 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 1 Oct 2009 21:29:01 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> Message-ID: <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> Hi Phil, Am 01.10.2009 um 21:15 schrieb Philip Brown: > On Thu, Oct 1, 2009 at 11:45 AM, Dagobert Michelsen > wrote: >> Am 01.10.2009 um 18:29 schrieb Philip Brown: >>> >>> The entire package, if it were one package, is 155k for sparc, and >>> 88k for >>> x86. >>> The "devel" package, is 5k. yes, 5830 bytes. >> >> I specifically didn't do it for size, but for clearness and >> consistency. And >> I think the tradeoff of having a clean split against one more >> package is >> IMHO worthwhile. > > And I understand that point. My own opinion, is that fewer packages, > makes > for better "clearness" for our users, when there isnt a noticable > benefit from > splitting them up into mulitple. > I cant see us ever splitting ALL our packages up into > CSWmain vs CSWmain-doc Me neither, because many users need the docs. > While it would be "consistent", it would also be insane overkill, in > my opinion :) > So for similar reasoning, I dont think we should split up ALL > packages to be > CSWmain vs CSWmain-devel The question is: How many users actually need the development files? > Just in the cases where there is actual benefit. If you know devel is always split you know that you have to install it. If it is sometimes split you are on your own. It may be a nice thing to have a script which adds all *_devel packages for the installed packages, though. Or to define a policy in pkg*.conf if _devel-packages are to be installed by default along with the main package. Best regards -- Dago From skayser at opencsw.org Thu Oct 1 23:21:04 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 01 Oct 2009 23:21:04 +0200 Subject: [csw-maintainers] OpenCSW Winter Camp 2009, when/where? Feedback needed. In-Reply-To: <50728.194.246.122.22.1253811743.squirrel@ssl.skayser.de> References: <50728.194.246.122.22.1253811743.squirrel@ssl.skayser.de> Message-ID: <4AC51D40.7060007@opencsw.org> Sebastian Kayser wrote on 24.09.2009 19:02: > before we head to Toronto next year in summer :D, i would like to kick off > this year's winter camp preparations for Munich. Two votes need your > input. > > - Which weekend can you participate? > http://doodle.com/p3rvwqkx542cu4rx > > - Which venue would you prefer (city/nature)? > http://doodle.com/xwnhvxp274i8b3iv Thanks to those who already voted, looking forward to seeing you (again) in a couple of months. Anyone else interested in coming? If so, please take part in the above polls so that we can plan accordingly (i will try to fix a date and venue by the end of next week). I have updated the winter camp page with possible topics. Feel free to brainstorm and add additional ones. Anyone interested in doing a technical workshop of some sort? Schedule is preliminary. Like during the last summer camp, it will simply serve as a rough guideline. http://opencsw.wikidot.com/wintercamp-2009 Thanks Sebastian From skayser at opencsw.org Fri Oct 2 09:32:17 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 02 Oct 2009 09:32:17 +0200 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: <4AC5AC81.1070606@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 :). Independent of the ongoing discussion: the version on the mirror roots is still outdated. Would some be so kind to put pkgutil 1.7 there? The pkg-get version is also downrev btw. (4.1.3 vs. 4.2.1). > Furthermore, could pkgutil be made an ARCH=all package, so that there is > just _one_ direct link that one can point new users to and not a > platform specific one (i know about uname -p, still it just makes things > more straightforward)? > > I see, the package contains a wget which is platform specific. Couldn't > we just include two wgets (wget.i386, wget.sparc)? From what i remember, > that is the same approach Sun uses for its explorer package. To add some facts: # find /opt/SUNWexplo/ -name "*curl*" /opt/SUNWexplo/bin/curl.i386 /opt/SUNWexplo/bin/curl.sparc # pkgparam SUNWexplo ARCH VENDOR all Sun Microsystems Inc. So it is not something unthinkable that we are talking about here, but something that Sun does too. Sebastian [1]http://www.ibiblio.org/pub/packages/solaris/opencsw/pkgutil-i386.pkg [2]http://www.ibiblio.org/pub/packages/solaris/opencsw/pkgutil-sparc.pkg From dam at opencsw.org Fri Oct 2 09:56:53 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 2 Oct 2009 09:56:53 +0200 Subject: [csw-maintainers] pkgutil/pkg-get version updates on the mirror roots? In-Reply-To: <4AC5AC81.1070606@opencsw.org> References: <4AC10A87.1090205@opencsw.org> <4AC5AC81.1070606@opencsw.org> Message-ID: <07837C40-572E-455C-AA33-ABD8E9BDCDAA@opencsw.org> Hi Sebastian, Am 02.10.2009 um 09:32 schrieb Sebastian Kayser: > 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 :). > > Independent of the ongoing discussion: the version on the mirror roots > is still outdated. Would some be so kind to put pkgutil 1.7 there? > > The pkg-get version is also downrev btw. (4.1.3 vs. 4.2.1). AFAIK Phil and James are the only persons with write access there. Phil, James, would any of you gentlemen be so kind to update both? Best regards -- Dago From james at opencsw.org Fri Oct 2 10:28:44 2009 From: james at opencsw.org (James Lee) Date: Fri, 02 Oct 2009 08:28:44 GMT Subject: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all? In-Reply-To: <4AC5AC81.1070606@opencsw.org> References: <4AC10A87.1090205@opencsw.org> <4AC5AC81.1070606@opencsw.org> Message-ID: <20091002.8284400.4088717404@gyor.oxdrove.co.uk> On 02/10/09, 08:32:17, Sebastian Kayser wrote regarding Re: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all?: > Independent of the ongoing discussion: the version on the mirror roots > is still outdated. Would some be so kind to put pkgutil 1.7 there? > The pkg-get version is also downrev btw. (4.1.3 vs. 4.2.1). The first thing any package tool should do is update itself. No, make that "must do" because other packages are only required to be updated with a contemporary version of pkg-get. The first batch of updates before updating itself are done with an old version, potentially too old, it need not be the previous version, it will be whatever is there and that can be very old. Using the update self first principle the initial package installer need only update itself and might not need advanced perl nor wget. James. From dam at opencsw.org Fri Oct 2 10:47:35 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 2 Oct 2009 10:47:35 +0200 Subject: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all? In-Reply-To: <20091002.8284400.4088717404@gyor.oxdrove.co.uk> References: <4AC10A87.1090205@opencsw.org> <4AC5AC81.1070606@opencsw.org> <20091002.8284400.4088717404@gyor.oxdrove.co.uk> Message-ID: <47166A8E-ABE3-491E-A1D3-EBEF8FDD8627@opencsw.org> Hi James, Am 02.10.2009 um 10:28 schrieb James Lee: > On 02/10/09, 08:32:17, Sebastian Kayser wrote > regarding Re: [csw-maintainers] pkgutil version updates on the mirror > roots? Make pkgutil package ARCH=all?: > >> Independent of the ongoing discussion: the version on the mirror >> roots >> is still outdated. Would some be so kind to put pkgutil 1.7 there? > >> The pkg-get version is also downrev btw. (4.1.3 vs. 4.2.1). > > The first thing any package tool should do is update itself. > > No, make that "must do" because other packages are only required to be > updated with a contemporary version of pkg-get. The first batch of > updates before updating itself are done with an old version, > potentially > too old, it need not be the previous version, it will be whatever is > there and that can be very old. > > Using the update self first principle the initial package installer > need > only update itself and might not need advanced perl nor wget. True. And that is the reason why we should deliberately ship outdated versions? I think it is good style to update the tools on the frontpage from time to time. Not with every minor release maybe, but a few times a year. Best regards -- Dago From james at opencsw.org Fri Oct 2 11:26:34 2009 From: james at opencsw.org (James Lee) Date: Fri, 02 Oct 2009 09:26:34 GMT Subject: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all? In-Reply-To: <47166A8E-ABE3-491E-A1D3-EBEF8FDD8627@opencsw.org> References: <4AC10A87.1090205@opencsw.org> <4AC5AC81.1070606@opencsw.org> <20091002.8284400.4088717404@gyor.oxdrove.co.uk> <47166A8E-ABE3-491E-A1D3-EBEF8FDD8627@opencsw.org> Message-ID: <20091002.9263400.2659167788@gyor.oxdrove.co.uk> On 02/10/09, 09:47:35, Dagobert Michelsen wrote regarding Re: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all?: > > Using the update self first principle the initial package installer > > need only update itself and might not need advanced perl nor wget. > True. And that is the reason why we should deliberately ship > outdated versions? I think it is good style to update the tools > on the frontpage from time to time. Not with every minor release > maybe, but a few times a year. There are 2 questions in this thread: 1. The root pkg tools are out of date. I say it doesn't matter as they are tools that update themselves. There isn't a reason to not keep them up-to-date but it's not interesting here. 2. The form the root pkg tools should take. I suggest it need not be the same as the actual package and can be a bootstrap version. To force its own update it could use versioning and datestamp or with an internal flag in the code. The bootstrap package can contain two archs of static wget, the actual package can use depends. There are other options. James. From bonivart at opencsw.org Fri Oct 2 13:17:13 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 2 Oct 2009 13:17:13 +0200 Subject: [csw-maintainers] /testing nicstat 1.20 Message-ID: <625385e30910020417k2b32d65ayf42a70e8ebd1ab48@mail.gmail.com> "nicstat is to network interfaces as "iostat" is to disks, or "prstat" is to processes. It is designed as a much better version of "netstat -i". Its differences include: * Reports bytes in & out as well as packets. * Normalizes these values to per-second rates. * Reports on all interfaces (while iterating) * Reports Utilization (rough calculation as of now) * Reports Saturation (also rough) * Prefixes statistics with the current time" http://blogs.sun.com/timc/entry/nicstat_the_solaris_and_linux http://mirror.opencsw.org/testing/nicstat-1.20,REV=2009.10.02-SunOS5.8-i386-CSW.pkg.gz http://mirror.opencsw.org/testing/nicstat-1.20,REV=2009.10.02-SunOS5.8-sparc-CSW.pkg.gz -- /peter From phil at bolthole.com Fri Oct 2 18:55:07 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 2 Oct 2009 09:55:07 -0700 Subject: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all? In-Reply-To: <20091002.9263400.2659167788@gyor.oxdrove.co.uk> References: <4AC10A87.1090205@opencsw.org> <4AC5AC81.1070606@opencsw.org> <20091002.8284400.4088717404@gyor.oxdrove.co.uk> <47166A8E-ABE3-491E-A1D3-EBEF8FDD8627@opencsw.org> <20091002.9263400.2659167788@gyor.oxdrove.co.uk> Message-ID: On Fri, Oct 2, 2009 at 2:26 AM, James Lee wrote: > >... > 2. The form the root pkg tools should take. > > I suggest it need not be the same as the actual package and can be a > bootstrap version. ?To force its own update it could use versioning > and datestamp or with an internal flag in the code. ?The bootstrap > package can contain two archs of static wget, the actual package can > use depends. ?There are other options. > > Indeed. And one of the options could be as follows: Instead duplicating our normal "packages" at the root level, have an actual INSTALLER proggie for CSW. That proggie could be a pkg, or one of those funky sh-wrapper things. If it's not a normal package,it then is free from any and all of our "standards", and can do whatever it likes. Such an installer could help a user select a pkg downloading tool, select a mirror site,and other fun things like that. From phil at bolthole.com Fri Oct 2 18:57:54 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 2 Oct 2009 09:57:54 -0700 Subject: [csw-maintainers] pkgutil/pkg-get version updates on the mirror roots? In-Reply-To: <07837C40-572E-455C-AA33-ABD8E9BDCDAA@opencsw.org> References: <4AC10A87.1090205@opencsw.org> <4AC5AC81.1070606@opencsw.org> <07837C40-572E-455C-AA33-ABD8E9BDCDAA@opencsw.org> Message-ID: On Fri, Oct 2, 2009 at 12:56 AM, Dagobert Michelsen wrote: > >> Independent of the ongoing discussion: the version on the mirror roots >> is still outdated. Would some be so kind to put pkgutil 1.7 there? >> >> The pkg-get version is also downrev btw. (4.1.3 vs. 4.2.1). > > AFAIK Phil and James are the only persons with write access there. > Phil, James, would any of you gentlemen be so kind to update both? > > ok, done. From bonivart at opencsw.org Sat Oct 3 20:48:14 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Sat, 3 Oct 2009 20:48:14 +0200 Subject: [csw-maintainers] Typo in descriptions file Message-ID: <625385e30910031148qc687fb0pccb5bc6f2b847a0b@mail.gmail.com> The entry for cvsproxy in the descriptions file lacks a space as separator. cvsproxy -an easy to use CVS proxy should be cvsproxy - an easy to use CVS proxy Note " - " instead of " -". -- /peter From dam at opencsw.org Sat Oct 3 21:09:09 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 3 Oct 2009 21:09:09 +0200 Subject: [csw-maintainers] Package GAR status page broken? Message-ID: <9851A323-886F-4276-A366-2146F64E7DE8@opencsw.org> Hi, I noticed that the package GAR status page is broken. Is this intended? Best regards -- Dago From dam at opencsw.org Sat Oct 3 21:09:37 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 3 Oct 2009 21:09:37 +0200 Subject: [csw-maintainers] Typo in descriptions file In-Reply-To: <625385e30910031148qc687fb0pccb5bc6f2b847a0b@mail.gmail.com> References: <625385e30910031148qc687fb0pccb5bc6f2b847a0b@mail.gmail.com> Message-ID: <6DDB819C-B683-440B-BCA1-4DB37EC7799D@opencsw.org> Hi Peter, Am 03.10.2009 um 20:48 schrieb Peter Bonivart: > The entry for cvsproxy in the descriptions file lacks a space as > separator. > > cvsproxy -an easy to use CVS proxy > > should be > > cvsproxy - an easy to use CVS proxy > > Note " - " instead of " -". Mmhhhh, "orphaned". Want to give it a try in GAR? Best regards -- Dago From bonivart at opencsw.org Sat Oct 3 21:20:16 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Sat, 3 Oct 2009 21:20:16 +0200 Subject: [csw-maintainers] Typo in descriptions file In-Reply-To: <6DDB819C-B683-440B-BCA1-4DB37EC7799D@opencsw.org> References: <625385e30910031148qc687fb0pccb5bc6f2b847a0b@mail.gmail.com> <6DDB819C-B683-440B-BCA1-4DB37EC7799D@opencsw.org> Message-ID: <625385e30910031220s325403a3ge9fcd448060353d7@mail.gmail.com> On Sat, Oct 3, 2009 at 9:09 PM, Dagobert Michelsen wrote: > Mmhhhh, "orphaned". Want to give it a try in GAR? Looks like a dead project, no updates since 2002. I can move it to GAR so we're ready for the next release. :-) -- /peter From dam at opencsw.org Sat Oct 3 21:21:47 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 3 Oct 2009 21:21:47 +0200 Subject: [csw-maintainers] Typo in descriptions file In-Reply-To: <625385e30910031220s325403a3ge9fcd448060353d7@mail.gmail.com> References: <625385e30910031148qc687fb0pccb5bc6f2b847a0b@mail.gmail.com> <6DDB819C-B683-440B-BCA1-4DB37EC7799D@opencsw.org> <625385e30910031220s325403a3ge9fcd448060353d7@mail.gmail.com> Message-ID: <11E3EAC5-7A9E-474E-B6E7-03A0AACA7061@opencsw.org> Hi Peter, Am 03.10.2009 um 21:20 schrieb Peter Bonivart: > On Sat, Oct 3, 2009 at 9:09 PM, Dagobert Michelsen > wrote: >> Mmhhhh, "orphaned". Want to give it a try in GAR? > > Looks like a dead project, no updates since 2002. Similar to CVS :-) > I can move it to GAR so we're ready for the next release. :-) He he :-D Best regards -- Dago From william at wbonnet.net Sat Oct 3 21:26:57 2009 From: william at wbonnet.net (William Bonnet) Date: Sat, 03 Oct 2009 21:26:57 +0200 Subject: [csw-maintainers] Package GAR status page broken? In-Reply-To: <9851A323-886F-4276-A366-2146F64E7DE8@opencsw.org> References: <9851A323-886F-4276-A366-2146F64E7DE8@opencsw.org> Message-ID: <4AC7A581.20500@wbonnet.net> Hi Dago > I noticed that the package GAR status page is broken. Is this intended? Thanks for reporting this. It is not intended, nor a feature :( I try to fix this ASAP. It is broken since a few days. I have to add a check for this kind of error. 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 Sun Oct 4 10:47:35 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 4 Oct 2009 10:47:35 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> Message-ID: <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> Hi, I would like to proceed on the splitting of devel packages as a package of mine is pending release whether the decision on this topic. The current poll is - 5 maintainers for "split off devel" - 1 maintainer for "decide on case-by-case" Does anyone feel that there is need for more discussion? Has anyone (especially those who have voted) understood that the split will then be mandatory for package releases? Sebastian, would you be willing to unify the bugs and introduce the "bugs-package-link" you suggested once we have clarified this issue? Best regards -- Dago From trygvis at opencsw.org Sun Oct 4 11:09:25 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Sun, 04 Oct 2009 11:09:25 +0200 Subject: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all? In-Reply-To: References: <4AC10A87.1090205@opencsw.org> <4AC5AC81.1070606@opencsw.org> <20091002.8284400.4088717404@gyor.oxdrove.co.uk> <47166A8E-ABE3-491E-A1D3-EBEF8FDD8627@opencsw.org> <20091002.9263400.2659167788@gyor.oxdrove.co.uk> Message-ID: <4AC86645.1040303@opencsw.org> Philip Brown wrote: > On Fri, Oct 2, 2009 at 2:26 AM, James Lee wrote: >> ... >> 2. The form the root pkg tools should take. >> >> I suggest it need not be the same as the actual package and can be a >> bootstrap version. To force its own update it could use versioning >> and datestamp or with an internal flag in the code. The bootstrap >> package can contain two archs of static wget, the actual package can >> use depends. There are other options. >> >> > > Indeed. And one of the options could be as follows: > > Instead duplicating our normal "packages" at the root level, have an > actual INSTALLER proggie for CSW. > That proggie could be a pkg, or one of those funky sh-wrapper things. > If it's not a normal package,it then is free from any and all of our > "standards", and can do whatever it likes. > > Such an installer could help a user select a pkg downloading tool, > select a mirror site,and other fun things like that. Something like that would be very nice. A nice touch is the ability to select a mirror, the Ibiblio mirror is always very slow from Europe.. -- Trygve From trygvis at opencsw.org Sun Oct 4 11:13:27 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Sun, 04 Oct 2009 11:13:27 +0200 Subject: [csw-maintainers] [csw-devel] SF.net SVN: gar:[6691] csw/mgar/pkg/git/trunk In-Reply-To: References: Message-ID: <4AC86737.5090300@opencsw.org> bdwalton at users.sourceforge.net wrote: > Revision: 6691 > http://gar.svn.sourceforge.net/gar/?rev=6691&view=rev > Author: bdwalton > Date: 2009-10-03 18:55:23 +0000 (Sat, 03 Oct 2009) > > Log Message: > ----------- > correct git registration in /etc/services postinstall > > Modified Paths: > -------------- > csw/mgar/pkg/git/trunk/checksums > csw/mgar/pkg/git/trunk/files/CSWgit.postinstall > > Modified: csw/mgar/pkg/git/trunk/checksums > =================================================================== > --- csw/mgar/pkg/git/trunk/checksums 2009-10-03 17:17:41 UTC (rev 6690) > +++ csw/mgar/pkg/git/trunk/checksums 2009-10-03 18:55:23 UTC (rev 6691) > @@ -1 +1 @@ > -6c2d8cf8dcdfc844ea32bc381f6a3bfd download/CSWgit.postinstall > +b2f8cba4fea2abc0cab666bb8a523a1a download/CSWgit.postinstall > > Modified: csw/mgar/pkg/git/trunk/files/CSWgit.postinstall > =================================================================== > --- csw/mgar/pkg/git/trunk/files/CSWgit.postinstall 2009-10-03 17:17:41 UTC (rev 6690) > +++ csw/mgar/pkg/git/trunk/files/CSWgit.postinstall 2009-10-03 18:55:23 UTC (rev 6691) > @@ -9,9 +9,9 @@ > cp -p "$GC_OLD" "$GC_NEW" > fi > > -/usr/xpg4/bin/grep -q CSWgit /etc/services > +/usr/xpg4/bin/grep -q CSWgit /etc/inet/services I think you should grep the output of "getent services git" here as people that does mass-hosting might include services in LDAP (or NIS?). -- Trygve From skayser at opencsw.org Sun Oct 4 11:37:31 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 4 Oct 2009 11:37:31 +0200 (CEST) Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> Message-ID: <49301.217.225.247.115.1254649051.squirrel@ssl.skayser.de> Dagobert Michelsen wrote: > I would like to proceed on the splitting of devel packages as a package > of mine is pending release whether the decision on this topic. > > The current poll is > - 5 maintainers for "split off devel" > - 1 maintainer for "decide on case-by-case" > > Does anyone feel that there is need for more discussion? > > Has anyone (especially those who have voted) understood that the split > will then be mandatory for package releases? Do we have a written out wording for what is subject to the _devel split then? > Sebastian, would you be willing to unify the bugs and introduce > the "bugs-package-link" you suggested once we have clarified this > issue? http://bugs.opencsw.org/ Yup, will develop this on my local box and then need Ihsan's help to implement it on the www box. What do you mean by "unify"? Sebastian From phil at bolthole.com Sun Oct 4 19:06:44 2009 From: phil at bolthole.com (Philip Brown) Date: Sun, 4 Oct 2009 10:06:44 -0700 Subject: [csw-maintainers] pkg-get in /testing Message-ID: <20091004170643.GA70566@bolthole.com> FYI: new pkg-get in testing. lots of bugs closed. including the one about, "use REV= as precedence over rest of name". 2nd party testing appreciated. From phil at bolthole.com Sun Oct 4 21:53:14 2009 From: phil at bolthole.com (Philip Brown) Date: Sun, 4 Oct 2009 12:53:14 -0700 Subject: [csw-maintainers] questions about GAR, history, and naming Message-ID: <20091004195314.GA33599@bolthole.com> SO.. I'm reading the front page blurb about GAR on http://sourceforge.net/apps/trac/gar/ A few questions and concerns come up, which I think would be best clarified and sorted out on the list here. "GAR is the build and packaging system used by OpenCSW. GAR is based on the GARNOME project" Err.. pardon? I thought it was based on "the linux BBC project"'s GAR build system. to remind people what THAT is/was all about: http://www.lnx-bbc.com/garticle.html I believe that GARNOME also forked off of that or something. and speaking of which.. I think that to do things cleanly, we need to EITHER have a "core, generic GAR" build system, and layer opencsw stuff on top of that (I think this is the cleanest thing to do) OR rename/rebrand "our" build system, as "cswgar", or "garcsw" or something. If we dont provide a generic "gar", then I think we need to migrate from gar.sourceforge.net, to something more specific. Otherwise, I think we do not deserve that namespace, and it should be ceeded to the ORIGINAL gar people at lnx-bbc.com From dam at opencsw.org Sun Oct 4 22:34:18 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 4 Oct 2009 22:34:18 +0200 Subject: [csw-maintainers] questions about GAR, history, and naming In-Reply-To: <20091004195314.GA33599@bolthole.com> References: <20091004195314.GA33599@bolthole.com> Message-ID: <719DE490-C858-436F-A1CC-A06029BA3D98@opencsw.org> Hi Phil, Am 04.10.2009 um 21:53 schrieb Philip Brown: > SO.. I'm reading the front page blurb about GAR on > > http://sourceforge.net/apps/trac/gar/ > > A few questions and concerns come up, which I think would be best > clarified > and sorted out on the list here. > > "GAR is the build and packaging system used by OpenCSW. GAR is > based on > the GARNOME project" > > Err.. pardon? I thought it was based on "the linux BBC project"'s > GAR build > system. Yes, and yes. It is more like Linux BBCs GAR -> GARNOME -> OpenCSW GAR So it is based on GARNOME, which itself is based on Linux BBC GAR. > to remind people what THAT is/was all about: > http://www.lnx-bbc.com/garticle.html > > I believe that GARNOME also forked off of that or something. True. But to be precise I guess we must ask Cory :-) > and speaking of which.. I think that to do things cleanly, we need to > EITHER have a "core, generic GAR" build system, and layer > opencsw stuff on top of that > (I think this is the cleanest thing to do) > OR rename/rebrand "our" build system, as "cswgar", or "garcsw" or > something. What do you mean by "generic GAR"? Of course we can split of the package descriptions, but also the rest has "csw" all over the place. > If we dont provide a generic "gar", then I think we need to migrate > from > gar.sourceforge.net, to something more specific. Otherwise, I think > we do > not deserve that namespace, and it should be ceeded to the ORIGINAL > gar > people at lnx-bbc.com I think moving to something more specific without being explicitly asked by someone wanting that project name on SourceForge is... quite a task. Changing URLs, switching all repos, all external references as they include the project name... everything not done quickly. Without a real need I don't want to do that now. Not just because another name is nicer. IMHO too many resources from too many people would be bound for something without immediate benefit. Just my 0,02? Best regards -- Dago From dam at opencsw.org Sun Oct 4 22:55:22 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 4 Oct 2009 22:55:22 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <49301.217.225.247.115.1254649051.squirrel@ssl.skayser.de> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <49301.217.225.247.115.1254649051.squirrel@ssl.skayser.de> Message-ID: Am 04.10.2009 um 11:37 schrieb Sebastian Kayser: > Dagobert Michelsen wrote: >> I would like to proceed on the splitting of devel packages as a >> package >> of mine is pending release whether the decision on this topic. >> >> The current poll is >> - 5 maintainers for "split off devel" >> - 1 maintainer for "decide on case-by-case" >> >> Does anyone feel that there is need for more discussion? >> >> Has anyone (especially those who have voted) understood that the >> split >> will then be mandatory for package releases? > > Do we have a written out wording for what is subject to the _devel > split > then? Like this: "Files related to developers must be split off in a separate developer package. Exceptions can be made when the primary target audience of the package are developers. When the base package is named CSW with the catalog name the developer package must be name CSWdevel with the catalog name _devel. The developer package should contain bin/*-config *.a (static libs, if at all included) pkgconfig/* include/* (header files) aclocal/* (for autoconf) man1/*-config.1* (man pages for *-config) man3/* (man pages for header files) It may contain other files not related to the normal functionality of the package only relevant for compiling or building programs not usually done by the user. This means that for packages primarily focused on developers like Perl do not have a separate devel package as the base module itself is already for developers. The developer package for Perl may include the libperl.a static lib only relevant when building new packages with an embedded Perl." >> Sebastian, would you be willing to unify the bugs and introduce >> the "bugs-package-link" you suggested once we have clarified this >> issue? > > http://bugs.opencsw.org/ > > Yup, will develop this on my local box and then need Ihsan's help to > implement it on the www box. What do you mean by "unify"? When we are going towards splitting up packages the package list in Mantis gets even longer and it is already very long. As the bugs are usually related to upstream packages it is feasible to put all bugs for packages produced for an upstream package together under its garname instead of having separate buglists for each individual package. That means you would e. g. have just "openssl" instead of "openssl_rt", "openssl_devel", "openssl_doc" etc. The change should only affect Mantis. The section in Mantis should then be accessed only with the URL syntax you described, so the abstraction is done at only one place. You can get the list of packages produced by a GAR description with gmake pkglist so the information for the mapping table is in there. Best regards -- Dago From dam at opencsw.org Sun Oct 4 22:59:51 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 4 Oct 2009 22:59:51 +0200 Subject: [csw-maintainers] pkgutil version updates on the mirror roots? In-Reply-To: <4AC86645.1040303@opencsw.org> References: <4AC10A87.1090205@opencsw.org> <4AC5AC81.1070606@opencsw.org> <20091002.8284400.4088717404@gyor.oxdrove.co.uk> <47166A8E-ABE3-491E-A1D3-EBEF8FDD8627@opencsw.org> <20091002.9263400.2659167788@gyor.oxdrove.co.uk> <4AC86645.1040303@opencsw.org> Message-ID: <96D34F16-1556-4399-8666-AFC9F7B8EFE5@opencsw.org> Hi Trygve, Am 04.10.2009 um 11:09 schrieb Trygve Laugst?l: > Something like that would be very nice. A nice touch is the ability > to select a mirror, the Ibiblio mirror is always very slow from > Europe.. Yes. Even better would be a redirection service to the next mirror. The would serve two purposes: - close statistics on mirror usage and performance - usually better-than-manual routing As we usually don't have access to the BGP data we can't use SuperSparrow [1], but something like mirrorbrain [2] could be used. Best regards -- Dago [1] http://www.supersparrow.org/ [2] http://mirrorbrain.org/ From james at opencsw.org Mon Oct 5 10:54:48 2009 From: james at opencsw.org (James Lee) Date: Mon, 05 Oct 2009 08:54:48 GMT Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> Message-ID: <20091005.8544800.2981934600@gyor.oxdrove.co.uk> On 04/10/09, 09:47:35, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Handling of devel package splits: > I would like to proceed on the splitting of devel packages as a package > of mine is pending release whether the decision on this topic. > The current poll is > - 5 maintainers for "split off devel" > - 1 maintainer for "decide on case-by-case" > Does anyone feel that there is need for more discussion? Yes since you are missing options and no justification is offered. > Has anyone (especially those who have voted) understood that the split > will then be mandatory for package releases? No. You have not made that clear. The poll lumps doc too but the thread subject says devel. Your poll is void. James. From dam at opencsw.org Mon Oct 5 11:05:49 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Oct 2009 11:05:49 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <20091005.8544800.2981934600@gyor.oxdrove.co.uk> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> Message-ID: <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> Hi James, Am 05.10.2009 um 10:54 schrieb James Lee: > On 04/10/09, 09:47:35, Dagobert Michelsen wrote > regarding > Re: [csw-maintainers] Handling of devel package splits: > >> I would like to proceed on the splitting of devel packages as a >> package >> of mine is pending release whether the decision on this topic. > >> The current poll is >> - 5 maintainers for "split off devel" >> - 1 maintainer for "decide on case-by-case" > >> Does anyone feel that there is need for more discussion? > > Yes since you are missing options and no justification is offered. And that missing options would be? The justification is that it is a Good Thing not to have headers on a deployment machine and that it is confusing for users to sometimes have the devel-files inside the main package and sometimes not. >> Has anyone (especially those who have voted) understood that the >> split >> will then be mandatory for package releases? > > No. You have not made that clear. > > The poll lumps doc too but the thread subject says devel. What does "lumps doc" mean? > Your poll is void. Ok then, do the maintainers who have already voted feel the same? Best regards -- Dago From james at opencsw.org Mon Oct 5 11:54:40 2009 From: james at opencsw.org (James Lee) Date: Mon, 05 Oct 2009 09:54:40 GMT Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> Message-ID: <20091005.9544000.198172607@gyor.oxdrove.co.uk> On 05/10/09, 10:05:49, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Handling of devel package splits: > >> I would like to proceed on the splitting of devel packages as a > >> package > >> of mine is pending release whether the decision on this topic. > > > >> The current poll is > >> - 5 maintainers for "split off devel" > >> - 1 maintainer for "decide on case-by-case" > > > >> Does anyone feel that there is need for more discussion? > > > > Yes since you are missing options and no justification is offered. > And that missing options would be? As previously communicated. The only addition I have it to version runtimes as it means only one version is needed at a time for a given depend. jpeg depends on jpeg7rt jpeg7rt - latest runtime jpeg62rt - legacy runtime packages depend on whichever rt version being used. > The justification is that it is a Good Thing not to have headers on > a deployment machine and that it is confusing for users to sometimes > have the devel-files inside the main package and sometimes not. Thank you, that's a start. Any proposal should start by stating the problem it's trying to solve. In the case of X11 packages (example at start) a user doesn't install (because only the libs are needed) so this problem does not exist. We have to balance the confusion of installing package foo and not getting product foo. It's traditional for Unix machines to come with headers. I agree a first time user thinks "what all this for?" but why is a user looking in /usr/include? It's not like they are the only headers on the system nor the only thing a user won't use. > >> Has anyone (especially those who have voted) understood that the > >> split > >> will then be mandatory for package releases? > > > > No. You have not made that clear. > > > > The poll lumps doc too but the thread subject says devel. > What does "lumps doc" mean? lump = "3. a collection of things; aggregate" doc = documentation combined with "too" you are ruling on the documentation files with the same action as developments files. James. From james at opencsw.org Mon Oct 5 12:11:47 2009 From: james at opencsw.org (James Lee) Date: Mon, 05 Oct 2009 10:11:47 GMT Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <20091005.9544000.198172607@gyor.oxdrove.co.uk> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> Message-ID: <20091005.10114700.540252802@gyor.oxdrove.co.uk> On 05/10/09, 10:54:40, James Lee wrote regarding Re: [csw-maintainers] Handling of devel package splits: > > > The poll lumps doc too but the thread subject says devel. > > What does "lumps doc" mean? > lump = "3. a collection of things; aggregate" > doc = documentation > combined with "too" you are ruling on the documentation files with the > same action as developments files. Applying the development split rational you must split user and development documentation. James. From dam at opencsw.org Mon Oct 5 14:32:26 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Oct 2009 14:32:26 +0200 Subject: [csw-maintainers] More checkpkg issues Message-ID: <9E57D892-7407-48CC-B294-A4DA33279A05@opencsw.org> Hi there, after the nice fix from Ben with checkpkg now knowing package depencies there is still one flaw left: When a package for Solaris x86 is assembled with 64 bit components from Solaris 10 in it the checkpkg on Solaris 8 fails with something like ERROR: Couldn't find a package providing libm.so.2 Maybe someone has a smart idea how to circumvent this? Best regards -- Dago From james at opencsw.org Mon Oct 5 14:41:15 2009 From: james at opencsw.org (James Lee) Date: Mon, 05 Oct 2009 12:41:15 GMT Subject: [csw-maintainers] More checkpkg issues In-Reply-To: <9E57D892-7407-48CC-B294-A4DA33279A05@opencsw.org> References: <9E57D892-7407-48CC-B294-A4DA33279A05@opencsw.org> Message-ID: <20091005.12411500.882653828@gyor.oxdrove.co.uk> On 05/10/09, 13:32:26, Dagobert Michelsen wrote regarding [csw-maintainers] More checkpkg issues: > after the nice fix from Ben with checkpkg now knowing package > depencies there is still one flaw left: When a package for Solaris > x86 is assembled with 64 bit components from Solaris 10 in it > the checkpkg on Solaris 8 fails with something like > ERROR: Couldn't find a package providing libm.so.2 > Maybe someone has a smart idea how to circumvent this? I have: [ "$lib" = "libm.so.2" ] && continue in the appropriate loop. Sorry, it's not smart. You have to note it will only execute on Solaris 10 for it to be smart. James. From dam at opencsw.org Mon Oct 5 14:56:55 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Oct 2009 14:56:55 +0200 Subject: [csw-maintainers] More checkpkg issues In-Reply-To: <20091005.12411500.882653828@gyor.oxdrove.co.uk> References: <9E57D892-7407-48CC-B294-A4DA33279A05@opencsw.org> <20091005.12411500.882653828@gyor.oxdrove.co.uk> Message-ID: Hi James, Am 05.10.2009 um 14:41 schrieb James Lee: > On 05/10/09, 13:32:26, Dagobert Michelsen wrote > regarding > [csw-maintainers] More checkpkg issues: > >> after the nice fix from Ben with checkpkg now knowing package >> depencies there is still one flaw left: When a package for Solaris >> x86 is assembled with 64 bit components from Solaris 10 in it >> the checkpkg on Solaris 8 fails with something like > >> ERROR: Couldn't find a package providing libm.so.2 > >> Maybe someone has a smart idea how to circumvent this? > > I have: > > [ "$lib" = "libm.so.2" ] && continue > > in the appropriate loop. > > > Sorry, it's not smart. You have to note it will only execute on > Solaris 10 for it to be smart. Well, it is better then my solution changing the error to a warning. Ben, if you agree I would like to add that to GARs checkpkg as default behaviour. Best regards -- Dago From bwalton at opencsw.org Mon Oct 5 15:25:22 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 05 Oct 2009 09:25:22 -0400 Subject: [csw-maintainers] More checkpkg issues In-Reply-To: References: <9E57D892-7407-48CC-B294-A4DA33279A05@opencsw.org> <20091005.12411500.882653828@gyor.oxdrove.co.uk> Message-ID: <1254749063-sup-2640@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Mon Oct 05 08:56:55 -0400 2009: > > [ "$lib" = "libm.so.2" ] && continue > > Sorry, it's not smart. You have to note it will only execute on > > Solaris 10 for it to be smart. It's smarter than dying for something that we know is typically correct. :) > Well, it is better then my solution changing the error to a warning. > Ben, if you agree I would like to add that to GARs checkpkg as default > behaviour. Yes, I'm all for making it as usable a tool as possible in the general case. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Mon Oct 5 16:08:45 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Oct 2009 16:08:45 +0200 Subject: [csw-maintainers] GAR Platform builds now open for testing Message-ID: <0F1DEF08-4D55-4224-ADFC-DE1DD712E9A7@opencsw.org> Hi folks, I have been able to finish up the pbuilds feature in GAR. The official naming is "GAR Platforms". The important features are: - Allows building of Sparc/x86 at the same time (Just issue "gmake package" on build8s / build8x) - Allows fully unattended builds for both Sparc and X86 suitable for buildbot use (Use "gmake platforms") - For the brave: build all ISAs for a package in parallel and watch the build with multitail. Watch out: Ctrl-C doesn't work too good yet during build (Activate this with "PARALLELMODULATIONS = 1" in your .garrc) It lives currently in mgar/gar/v2-pbuild, just link it in to your project for testing. I have used it for some packages now and it looks good to me, but I don't use all features of GAR ;-) So feedback is especially welcome here! After some positive feedback I would like to make this version the default for GAR. It will be the basis for the enhanced release process (tagging of build recipes to tags/ triggering automated builds which will be automatically installed on new "experimental" hosts. More on that later.) Best regards -- Dago From dam at opencsw.org Mon Oct 5 16:12:51 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Oct 2009 16:12:51 +0200 Subject: [csw-maintainers] GAR Platform builds now open for testing In-Reply-To: <0F1DEF08-4D55-4224-ADFC-DE1DD712E9A7@opencsw.org> References: <0F1DEF08-4D55-4224-ADFC-DE1DD712E9A7@opencsw.org> Message-ID: <05F1A42C-9047-4EBF-A531-3A2212A8DC19@opencsw.org> Hi folks, Am 05.10.2009 um 16:08 schrieb Dagobert Michelsen: > Hi folks, > > I have been able to finish up the pbuilds feature in GAR. The > official naming is "GAR Platforms". > > The important features are: > > - Allows building of Sparc/x86 at the same time > (Just issue "gmake package" on build8s / build8x) > > - Allows fully unattended builds for both Sparc and X86 suitable > for buildbot use > (Use "gmake platforms") > > - For the brave: build all ISAs for a package in parallel and > watch the build with multitail. > Watch out: Ctrl-C doesn't work too good yet during build > (Activate this with "PARALLELMODULATIONS = 1" in your .garrc) > > > It lives currently in mgar/gar/v2-pbuild, just link it in to > your project for testing. I have used it for some packages now > and it looks good to me, but I don't use all features of GAR ;-) > So feedback is especially welcome here! > > After some positive feedback I would like to make this version > the default for GAR. It will be the basis for the enhanced > release process (tagging of build recipes to tags/ triggering > automated builds which will be automatically installed on > new "experimental" hosts. More on that later.) Of course there is also documentation :-) http://sourceforge.net/apps/trac/gar/wiki/Platforms Best regards -- Dago From phil at bolthole.com Mon Oct 5 18:58:32 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 5 Oct 2009 09:58:32 -0700 Subject: [csw-maintainers] questions about GAR, history, and naming In-Reply-To: <719DE490-C858-436F-A1CC-A06029BA3D98@opencsw.org> References: <20091004195314.GA33599@bolthole.com> <719DE490-C858-436F-A1CC-A06029BA3D98@opencsw.org> Message-ID: On Sun, Oct 4, 2009 at 1:34 PM, Dagobert Michelsen wrote: > Hi Phil, *wave* > I think moving to something more specific without being explicitly asked > by someone wanting that project name on SourceForge is... quite a task. > Changing URLs, switching all repos, all external references as they > include the project name... everything not done quickly. Without a real > need I don't want to do that now. Not just because another name is > nicer. IMHO too many resources from too many people would be bound for > something without immediate benefit. > "doing the right thing", RARELY has "immediate benefit" :-P PS: renaming is not the only option that would be morally clean. The other option that I see, and mentioned, is to offer a "generic gar" package. Shouldnt be too difficult, relatively speaking? From maciej at opencsw.org Mon Oct 5 19:44:02 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 5 Oct 2009 18:44:02 +0100 Subject: [csw-maintainers] GAR Platform builds now open for testing In-Reply-To: <05F1A42C-9047-4EBF-A531-3A2212A8DC19@opencsw.org> References: <0F1DEF08-4D55-4224-ADFC-DE1DD712E9A7@opencsw.org> <05F1A42C-9047-4EBF-A531-3A2212A8DC19@opencsw.org> Message-ID: I took a look at the documentation and I have a questions: What about building packages outside the buildfarm. I use to work on a relatively powerful, local x86 machine. When I'm happy with the build files, I submit the changes to the repository, go to the buildfarm, log into build8s, launch the build and pray. What is the pbuild branch going to do on a machine outside the buildfarm, is it going to try to log into build8s, which isn't there? Maciej From dam at opencsw.org Mon Oct 5 20:54:49 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Oct 2009 20:54:49 +0200 Subject: [csw-maintainers] questions about GAR, history, and naming In-Reply-To: References: <20091004195314.GA33599@bolthole.com> <719DE490-C858-436F-A1CC-A06029BA3D98@opencsw.org> Message-ID: <9046596F-57B6-4AA0-9B36-60C9F1497A56@opencsw.org> Hi Phil, Am 05.10.2009 um 18:58 schrieb Philip Brown: >> I think moving to something more specific without being explicitly >> asked >> by someone wanting that project name on SourceForge is... quite a >> task. >> Changing URLs, switching all repos, all external references as they >> include the project name... everything not done quickly. Without a >> real >> need I don't want to do that now. Not just because another name is >> nicer. IMHO too many resources from too many people would be bound >> for >> something without immediate benefit. > > "doing the right thing", RARELY has "immediate benefit" :-P > > PS: renaming is not the only option that would be morally clean. > The other option that I see, and mentioned, is to offer a "generic > gar" package. > Shouldnt be too difficult, relatively speaking? Following your argumentation the "generic gar" would be the GAR from linuxbbc without changes as the generic name "GAR" belongs to them. Every fork could be thought of a takeover of the namespace. But anyway, I am against changing the name unless someone from linuxbbc is claiming the name on sourceforge. Best regards -- Dago From phil at bolthole.com Mon Oct 5 21:14:37 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 5 Oct 2009 12:14:37 -0700 Subject: [csw-maintainers] libtool, compiling shared lib Message-ID: Anyhone understand automake/libtool gobbldygook? I'm trying to compile something. It's libtool infested. I do a gmake. it builds something. but it only builds the libXXX.la It doesnt build the SHARED LIBRARY libXXX.so.x.y.z There are zero errors. it just doesnt build it. And I dont understand which target, out of the 100 or so in the stupid automake-generated-soup, to call for it. It makes the damn symlinks, .libs/libXXX.so.4 -> libXXX.so.4.0.0 but no actual shared lib ? !!! I've hit this in MULTIPLE software things now and am lost for words. From blizinski at google.com Thu Oct 1 10:16:42 2009 From: blizinski at google.com (Maciej (Matchek) Blizinski) Date: Thu, 1 Oct 2009 09:16:42 +0100 Subject: [csw-maintainers] V8+ binaries produced by gcc on build10s Message-ID: I have a relatively straightforward build: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/urxvt/trunk/Makefile After building the package on build10s, I see this: urxvt: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, stripped urxvtc: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, stripped urxvtd: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, stripped I added -mno-v8plus to the compiler flags. gmake modenv says: CFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include CXXFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include Why is gcc still producing V8+ binaries? Is there a way to influence it? Maciej From dam at baltic-online.de Fri Oct 2 22:17:19 2009 From: dam at baltic-online.de (Dagobert Michelsen) Date: Fri, 2 Oct 2009 22:17:19 +0200 Subject: [csw-maintainers] Page "Suggestions" edited at wiki.opencsw.org In-Reply-To: <9158b4aaa5a04a352c0847669ef7bd85@as2-1.s.wikidot.com> References: <9158b4aaa5a04a352c0847669ef7bd85@as2-1.s.wikidot.com> Message-ID: Hi folks, Am 02.10.2009 um 20:42 schrieb Philip Brown: > Philip Brown edited the page "Suggestions" at > http://wiki.opencsw.org/suggestions Am 02.10.2009 um 21:51 schrieb bonivart: > bonivart edited the page "Suggestions" at > http://wiki.opencsw.org/suggestions Gentlemen, if you have anything to discuss please do it on the list as I get spammed with the notifications ;-) Best regards -- Dago From phil at bolthole.com Mon Oct 5 21:20:38 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 5 Oct 2009 12:20:38 -0700 Subject: [csw-maintainers] questions about GAR, history, and naming In-Reply-To: <9046596F-57B6-4AA0-9B36-60C9F1497A56@opencsw.org> References: <20091004195314.GA33599@bolthole.com> <719DE490-C858-436F-A1CC-A06029BA3D98@opencsw.org> <9046596F-57B6-4AA0-9B36-60C9F1497A56@opencsw.org> Message-ID: On Mon, Oct 5, 2009 at 11:54 AM, Dagobert Michelsen wrote: > Hi Phil, > >> PS: renaming is not the only option that would be morally clean. >> The other option that I see, and mentioned, is to offer a "generic gar" >> package. >> Shouldnt be too difficult, relatively speaking? > > Following your argumentation the "generic gar" would be the GAR from > linuxbbc > without changes as the generic name "GAR" belongs to them. Every fork could > be thought of a takeover of the namespace. Not neccessarily the original one unchanged. It could be an "improved gar" in my opinion. I think that "gar.sourceforge.net", belongs most properly as a place where other people interested "in gar", could work on a common base. This would include linuxbbc, AND possibly GARNOME people. Or, if you just "take out all the opencsw bits" from what you have already, and make sure that what is left, is internally consistent for someone who might take it and build their own GAR-based build setup. That's all. I think we would be perfectly justified in keeping the opencsw gar addons, as also at gar.sourceforge.net Just so long as they are an *optional* addon. From dam at opencsw.org Mon Oct 5 21:28:08 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Oct 2009 21:28:08 +0200 Subject: [csw-maintainers] BerkeleyDB final call Message-ID: Hi, I have now finally assembled a new and complete rebuild of the Berkeley DB libraries. In the new schema every version of BDB is sitting in a separate subdirectory, that means Berkeley DB X.Y.Z is located at /opt/csw/bdbXY/(bin|lib|...) All versions have been packaged up from 4.2 to 4.8 (3.3 was included because there were existing packages needing it). This should allow building and testing for regression tests against every version available. If necessary the legacy packages needed as dependencies have been replaced by stubs containing minimal links to the new locations with a respective dependency in the package. The following packages have been updated: berkeleydb CSWbdb berkeleydb3 CSWbdb3 berkeleydb33 CSWbdb33 berkeleydb33_devel CSWbdb33devel berkeleydb33_doc CSWbdb33doc berkeleydb4 CSWbdb4 berkeleydb42 CSWbdb42 berkeleydb42_devel CSWbdb42devel berkeleydb42_doc CSWbdb42doc berkeleydb43 CSWbdb43 berkeleydb43_devel CSWbdb43devel berkeleydb43_doc CSWbdb43doc berkeleydb44 CSWbdb44 berkeleydb44_devel CSWbdb44devel berkeleydb44_doc CSWbdb44doc berkeleydb45 CSWbdb45 berkeleydb45_devel CSWbdb45devel berkeleydb45_doc CSWbdb45doc berkeleydb46 CSWbdb46 berkeleydb46_devel CSWbdb46devel berkeleydb46_doc CSWbdb46doc berkeleydb47 CSWbdb47 berkeleydb47_devel CSWbdb47devel berkeleydb47_doc CSWbdb47doc berkeleydb48 CSWbdb48 berkeleydb48_devel CSWbdb48devel berkeleydb48_doc CSWbdb48doc The following packages are deprecated: - CSWbdb was newly introduced during the unification. It contains /opt/csw/lib/amd64/libdb-4.7.so=../../bdb47/lib/amd64/libdb-4.7.so /opt/csw/lib/libdb-4.7.so=../bdb47/lib/libdb-4.7.so - CSWbdb3 contains the original Berkeley DB 3.3 version in /opt/csw/lib, which is now in /opt/csw/bdb33. It contains /opt/csw/lib/libdb-3.3.so=../bdb33/lib/libdb-3.3.so - CSWbdb4 contained the original Berkeley DB 4.2 in /opt/csw/bdb4. The package now contains /opt/csw/bdb4=bdb42 The following packages do not exist any more as the base packages are deprecated: - berkeleydb_doc CSWbdbdoc - berkeleydb_devel CSWbdbdevel - berkeleydb4_doc CSWbdb4-doc The following package names have been changed to match the general naming convetions: - berkeleydb43_devel CSWbdb43-devel -> CSWbdb43devel - berkeleydb43_doc CSWbdb43-doc -> CSWbdb43doc - berkeleydb44_devel CSWbdb44-devel -> CSWbdb44devel - berkeleydb44_doc CSWbdb44-doc -> CSWbdb44doc I know that package renames are always ugly, but I neither wanted to continue with the broken scheme nor wanted to have some package with the old and some with the new scheme. Additionally, the devel- and doc-packages shouldn't be in wide use and should not make much trouble. The packages are available from and there are subdirectories for Solaris 8 Sparc and x86 with catalogs which should allow direct updating with pkg-get/pkgutil. Additionally all packages have been installed on test8s and test8x. To make this transition less painful than the previous one please test the new packages in your environment, test them with the packages which failed last time and the packages you would consider most important. Thank you! -- Dago From dam at opencsw.org Mon Oct 5 21:29:49 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Oct 2009 21:29:49 +0200 Subject: [csw-maintainers] libtool, compiling shared lib In-Reply-To: References: Message-ID: <5D9255A8-5F8F-4DBE-9BD4-443075A9AC06@opencsw.org> Hi Phil, Am 05.10.2009 um 21:14 schrieb Philip Brown: > Anyhone understand automake/libtool gobbldygook? > > I'm trying to compile something. It's libtool infested. > > I do a gmake. it builds something. but it only builds the libXXX.la > It doesnt build the SHARED LIBRARY libXXX.so.x.y.z > > There are zero errors. it just doesnt build it. And I dont understand > which target, out of the 100 or so in the stupid > automake-generated-soup, to call for it. > > It makes the damn symlinks, .libs/libXXX.so.4 -> libXXX.so.4.0.0 > > but no actual shared lib ? !!! > > I've hit this in MULTIPLE software things now and am lost for words. If you were using SVN I would say "just commit your work and post the URL", now I say "where is the directory so I can have a look" ;-) Best regards -- Dago From dam at opencsw.org Mon Oct 5 21:31:24 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Oct 2009 21:31:24 +0200 Subject: [csw-maintainers] librsync 0.9.7 uploaded to testing In-Reply-To: <20090920221939.GA25482@vm-1.bch.net> References: <20090920221939.GA25482@vm-1.bch.net> Message-ID: Hi Brian, Am 21.09.2009 um 00:19 schrieb Brian Hill: > I have uploaded librsync for testing. It isn't all that useful > by itself, but it is needed for rdiff-backup, which is coming soon. > > Does the descriptions file update at regular intervals or is it > done by hand? A pkg-get of librsync from testing doesn't work yet. The catalog is updated every 10 minutes, so it should have been updated by now (ups, 21.09.2009?? Have you posted from a non-subscribed address?) Best regards -- Dago From wbonnet at opencsw.org Mon Oct 5 21:16:10 2009 From: wbonnet at opencsw.org (William Bonnet) Date: Mon, 05 Oct 2009 21:16:10 +0200 Subject: [csw-maintainers] Package GAR status page broken? In-Reply-To: <4AC7A581.20500@wbonnet.net> References: <9851A323-886F-4276-A366-2146F64E7DE8@opencsw.org> <4AC7A581.20500@wbonnet.net> Message-ID: <4ACA45FA.6070100@opencsw.org> Hi This should be fixed now (even if until tomorrow morning it is still broken...). The problem came from an upstream modification on the packages list i was parsing. I was not aware of the URL change, and i did not modified my code. cheers W. -- William Bonnet http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From dam at opencsw.org Mon Oct 5 21:34:49 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Oct 2009 21:34:49 +0200 Subject: [csw-maintainers] questions about GAR, history, and naming In-Reply-To: References: <20091004195314.GA33599@bolthole.com> <719DE490-C858-436F-A1CC-A06029BA3D98@opencsw.org> <9046596F-57B6-4AA0-9B36-60C9F1497A56@opencsw.org> Message-ID: <0315E28D-99D7-42DB-A144-8A6B4E85A771@opencsw.org> Hi Phil, Am 05.10.2009 um 21:20 schrieb Philip Brown: > On Mon, Oct 5, 2009 at 11:54 AM, Dagobert Michelsen > wrote: >>> PS: renaming is not the only option that would be morally clean. >>> The other option that I see, and mentioned, is to offer a "generic >>> gar" >>> package. >>> Shouldnt be too difficult, relatively speaking? >> >> Following your argumentation the "generic gar" would be the GAR from >> linuxbbc >> without changes as the generic name "GAR" belongs to them. Every >> fork could >> be thought of a takeover of the namespace. > > > Not neccessarily the original one unchanged. It could be an "improved > gar" in my opinion. > > I think that "gar.sourceforge.net", belongs most properly as a place > where other people interested "in gar", could work on a common base. > This would include linuxbbc, AND possibly GARNOME people. > > Or, if you just "take out all the opencsw bits" from what you have > already, and make sure that what is left, is internally consistent for > someone who might take it and build their own GAR-based build setup. > > That's all. > > I think we would be perfectly justified in keeping the opencsw gar > addons, as also at gar.sourceforge.net > Just so long as they are an *optional* addon. The problem is that the enhancements specific to Solaris can't cleanly be ripped out. Basically all I did was adding Solaris-specific stuff. If I take it out you have the original version again. Best regards -- Dago From phil at bolthole.com Mon Oct 5 21:45:11 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 5 Oct 2009 12:45:11 -0700 Subject: [csw-maintainers] libtool, compiling shared lib In-Reply-To: <5D9255A8-5F8F-4DBE-9BD4-443075A9AC06@opencsw.org> References: <5D9255A8-5F8F-4DBE-9BD4-443075A9AC06@opencsw.org> Message-ID: On Mon, Oct 5, 2009 at 12:29 PM, Dagobert Michelsen wrote: > >> It makes the damn symlinks, .libs/libXXX.so.4 -> libXXX.so.4.0.0 >> >> but no actual shared lib ? !!! >> >> I've hit this in MULTIPLE software things now and am lost for words. > > If you were using SVN I would say "just commit your work and post the URL", > now I say "where is the directory so I can have a look" ;-) > It's actually a not-for-csw compile. but I figure it is useful information so thought I would ask about it here :) It's also general principle knowlege, too. Take ANY shared lib,that is compiled with libtool. rm .libs/libFOOO.so.x.y.z (the "real" library) Now try to figure out what "make x" command to run, to recompile/relink the damn library. Figure it out with ANY libtool-subjugated package, and I bet we then have it figured out for all. I'm stumped on any of them :( There MAY be some magic "libtool libfoo.la" to relink/recreate the library instead of a make target command that I dont know. That would be just as nice to know, perhaps even nicer. From phil at bolthole.com Mon Oct 5 21:57:44 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 5 Oct 2009 12:57:44 -0700 Subject: [csw-maintainers] questions about GAR, history, and naming In-Reply-To: <0315E28D-99D7-42DB-A144-8A6B4E85A771@opencsw.org> References: <20091004195314.GA33599@bolthole.com> <719DE490-C858-436F-A1CC-A06029BA3D98@opencsw.org> <9046596F-57B6-4AA0-9B36-60C9F1497A56@opencsw.org> <0315E28D-99D7-42DB-A144-8A6B4E85A771@opencsw.org> Message-ID: On Mon, Oct 5, 2009 at 12:34 PM, Dagobert Michelsen wrote: > >> I think we would be perfectly justified in keeping the opencsw gar >> addons, as also at gar.sourceforge.net >> Just so long as they are an *optional* addon. > > The problem is that the enhancements specific to Solaris can't cleanly > be ripped out. Basically all I did was adding Solaris-specific stuff. > If I take it out you have the original version again. > well, that's not "opencsw specific". Can you not leave them in, but make it so that they only come into play if you run it on solaris? From dam at opencsw.org Mon Oct 5 22:05:13 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Oct 2009 22:05:13 +0200 Subject: [csw-maintainers] GAR Platform builds now open for testing In-Reply-To: References: <0F1DEF08-4D55-4224-ADFC-DE1DD712E9A7@opencsw.org> <05F1A42C-9047-4EBF-A531-3A2212A8DC19@opencsw.org> Message-ID: Hi Maciej, Am 05.10.2009 um 19:44 schrieb Maciej (Matchek) Blizinski: > I took a look at the documentation and I have a questions: What about > building packages outside the buildfarm. I use to work on a relatively > powerful, local x86 machine. When I'm happy with the build files, I > submit the changes to the repository, go to the buildfarm, log into > build8s, launch the build and pray. What is the pbuild branch going to > do on a machine outside the buildfarm, is it going to try to log into > build8s, which isn't there? If you don't set PACKAGING_HOST_* and BUILD_HOST_* it should behave similar to the regular GAR v2 - no hopping around, but with separete directory trees for Sparc and X86 allowing concurrent builds. Best regards -- Dago From ihsan at opencsw.org Mon Oct 5 22:08:53 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Mon, 05 Oct 2009 22:08:53 +0200 Subject: [csw-maintainers] OpenCSW Winter Camp 2009, when/where? Feedback needed. In-Reply-To: <50728.194.246.122.22.1253811743.squirrel@ssl.skayser.de> References: <50728.194.246.122.22.1253811743.squirrel@ssl.skayser.de> Message-ID: <4ACA5255.4000408@opencsw.org> Am 24.9.2009 19:02 Uhr, Sebastian Kayser schrieb: > before we head to Toronto next year in summer :D, i would like to kick off > this year's winter camp preparations for Munich. Two votes need your > input. > > - Which weekend can you participate? > http://doodle.com/p3rvwqkx542cu4rx > > - Which venue would you prefer (city/nature)? > http://doodle.com/xwnhvxp274i8b3iv > > Please participate so that we can proceed with the plannings. If you have > any questions or feedback, please let me know. Similar to the past camps, > i have created a wiki page on http://wiki.opencsw.org/wintercamp-2009 > which we can use for planning purposes and for gathering ideas. Thank you very much for organizing the winter camp. Currently, I really can't say if I'll be able to join or not - even I'm living closer to Munich than Dago. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From bwalton at opencsw.org Tue Oct 6 04:26:12 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 05 Oct 2009 22:26:12 -0400 Subject: [csw-maintainers] Fwd: big xml/docbook package update Message-ID: <1254795959-sup-260@ntdws12.chass.utoronto.ca> --- Begin forwarded message from Ben Walton --- From: Ben Walton To: users Date: Mon, 05 Oct 2009 22:24:43 -0400 Subject: big xml/docbook package update Hi All, I've just released a large set of interdependent packages[1] to the 'current' stream. This update will see several changes, but most importantly with respect to a clean update is that $sysconfdir is moving from /opt/csw/etc/ to /etc/opt/csw for all packages in this set. To smoothly handle the transition, I've provided a small script[2]. It will remove the packages (if found) in an order that won't upset the inter-dependencies and then reinstall them one by one. Other notable changes: docbook now provides 4.5 dtd's and sets this version as primary asciidoc is bumped to 8.4.5, which should fix a few bugs issues py_libxslt was formerly known as pylibxslt. renamed for consistency xmlto is bumped to 0.0.23 and should work better on solaris libxslt has a patch applied that corrects a segfault while debugging Sorry for any hassle this causes you. Thanks -Ben [1] List of updated packages: asciidoc-8.4.5,REV=2009.09.18-SunOS5.8-all-CSW.pkg.gz docbookdsssl-1.79,REV=2009.09.15-SunOS5.8-all-CSW.pkg.gz docbookdtds-4.5,REV=2009.09.16-SunOS5.8-all-CSW.pkg.gz docbookxsl-1.74.3,REV=2009.09.11-SunOS5.8-all-CSW.pkg.gz docbookxsldoc-1.74.3,REV=2009.09.11-SunOS5.8-all-CSW.pkg.gz libxml2-2.7.3,REV=2009.09.12-SunOS5.8-i386-CSW.pkg.gz libxml2-2.7.3,REV=2009.09.12-SunOS5.8-sparc-CSW.pkg.gz libxml2_devel-2.7.3,REV=2009.09.12-SunOS5.8-i386-CSW.pkg.gz libxml2_devel-2.7.3,REV=2009.09.12-SunOS5.8-sparc-CSW.pkg.gz libxslt-1.1.24,REV=2009.09.08-SunOS5.8-i386-CSW.pkg.gz libxslt-1.1.24,REV=2009.09.08-SunOS5.8-sparc-CSW.pkg.gz libxslt_devel-1.1.24,REV=2009.09.08-SunOS5.8-i386-CSW.pkg.gz libxslt_devel-1.1.24,REV=2009.09.08-SunOS5.8-sparc-CSW.pkg.gz openjade-1.3.2,REV=2009.09.11-SunOS5.8-i386-CSW.pkg.gz openjade-1.3.2,REV=2009.09.11-SunOS5.8-sparc-CSW.pkg.gz py_libxml2-2.7.3,REV=2009.09.12-SunOS5.8-i386-CSW.pkg.gz py_libxml2-2.7.3,REV=2009.09.12-SunOS5.8-sparc-CSW.pkg.gz py_libxslt-1.1.24,REV=2009.09.08-SunOS5.8-i386-CSW.pkg.gz py_libxslt-1.1.24,REV=2009.09.08-SunOS5.8-sparc-CSW.pkg.gz sgmlcommon-0.6.3,REV=2009.09.13-SunOS5.8-all-CSW.pkg.gz xmlcommon-0.6.3,REV=2009.09.13-SunOS5.8-all-CSW.pkg.gz xmlto-0.0.23,REV=2009.09.27-SunOS5.8-i386-CSW.pkg.gz xmlto-0.0.23,REV=2009.09.27-SunOS5.8-sparc-CSW.pkg.gz [2] http://mirror.opencsw.org/testing/update_xml_pkgs.sh --- End forwarded message --- -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Oct 6 09:48:10 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 6 Oct 2009 09:48:10 +0200 Subject: [csw-maintainers] questions about GAR, history, and naming In-Reply-To: References: <20091004195314.GA33599@bolthole.com> <719DE490-C858-436F-A1CC-A06029BA3D98@opencsw.org> <9046596F-57B6-4AA0-9B36-60C9F1497A56@opencsw.org> <0315E28D-99D7-42DB-A144-8A6B4E85A771@opencsw.org> Message-ID: <32973644-DFF4-4BD1-A760-90422E02A60A@opencsw.org> Hi Phil, Am 05.10.2009 um 21:57 schrieb Philip Brown: > On Mon, Oct 5, 2009 at 12:34 PM, Dagobert Michelsen > wrote: >> >>> I think we would be perfectly justified in keeping the opencsw gar >>> addons, as also at gar.sourceforge.net >>> Just so long as they are an *optional* addon. >> >> The problem is that the enhancements specific to Solaris can't >> cleanly >> be ripped out. Basically all I did was adding Solaris-specific stuff. >> If I take it out you have the original version again. >> > > well, that's not "opencsw specific". Can you not leave them in, but > make it so that they only come into play if you run it on solaris? The decision logic is already quite complex and inserting these switches would even increase it, making it unreadable for new GAR maintainers. And what for? If there are people from linux bbc or Garnome who want to work in a unified development tree I would certainly help in making it. If you really think the project needs this I won't stop you from doing work in that area ;-) Just to give you in impression: This separation would mean a complete restructuring of GAR which will take at least a week for me to do it. A week I would like to spend better on updating the farm and deploying automated builds. Best regards -- Dago From dam at opencsw.org Tue Oct 6 10:13:35 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 6 Oct 2009 10:13:35 +0200 Subject: [csw-maintainers] X11 woes Message-ID: <142A0DD9-4FB7-45D7-9092-6BA80999A7D1@opencsw.org> Hi, I am currently refreshing imlib/imlib2. On compilation they seem to pull in the old libx11 (and breaks!) as the depend on libungif which itself is compiled against the old X11. I guess it would be cleanest to go through all libraries which depend on X11 and recompile them against the new version or maybe someone has a better idea? Best regards -- Dago From maciej at opencsw.org Tue Oct 6 10:43:12 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 6 Oct 2009 09:43:12 +0100 Subject: [csw-maintainers] questions about GAR, history, and naming In-Reply-To: <32973644-DFF4-4BD1-A760-90422E02A60A@opencsw.org> References: <20091004195314.GA33599@bolthole.com> <719DE490-C858-436F-A1CC-A06029BA3D98@opencsw.org> <9046596F-57B6-4AA0-9B36-60C9F1497A56@opencsw.org> <0315E28D-99D7-42DB-A144-8A6B4E85A771@opencsw.org> <32973644-DFF4-4BD1-A760-90422E02A60A@opencsw.org> Message-ID: On Tue, Oct 6, 2009 at 8:48 AM, Dagobert Michelsen wrote: > The decision logic is already quite complex and inserting these switches > would even increase it, making it unreadable for new GAR maintainers. > And what for? If there are people from linux bbc or Garnome who want to > work in a unified development tree I would certainly help in making it. > If you really think the project needs this I won't stop you from doing > work in that area ;-) Just to give you in impression: This separation > would mean a complete restructuring of GAR which will take at least a > week for me to do it. A week I would like to spend better on updating > the farm and deploying automated builds. Is "to do things cleanly" the only reason, or are there more reasons? I think everyone would agree that, all other things equal, clean is better, nicer, and in the long term also useful. But there's also the cost. If software developer has time on their hands, they can spend time just polishing the code, making it more readable, structured, layered, functional, unit-tested, or whatever property they want it to have. However, in our case we're after very specific needs in GAR development: parallel builds and modulations. There are also other things that currently need attention. I'd like us to make development decisions based on current needs rather than aesthetics. The restructuring of GAR can be filed in an issue tracking system so the idea doesn't get lost or forgotten. Maciej From dam at opencsw.org Tue Oct 6 13:55:05 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 6 Oct 2009 13:55:05 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <20091005.9544000.198172607@gyor.oxdrove.co.uk> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> Message-ID: Hi James, Am 05.10.2009 um 11:54 schrieb James Lee: > On 05/10/09, 10:05:49, Dagobert Michelsen wrote > regarding > Re: [csw-maintainers] Handling of devel package splits: > >>>> I would like to proceed on the splitting of devel packages as a >>>> package >>>> of mine is pending release whether the decision on this topic. >>> >>>> The current poll is >>>> - 5 maintainers for "split off devel" >>>> - 1 maintainer for "decide on case-by-case" >>> >>>> Does anyone feel that there is need for more discussion? >>> >>> Yes since you are missing options and no justification is offered. >> >> And that missing options would be? > > As previously communicated. > > The only addition I have it to version runtimes as it means only one > version is needed at a time for a given depend. > > jpeg depends on jpeg7rt > jpeg7rt - latest runtime > jpeg62rt - legacy runtime > > packages depend on whichever rt version being used. I don't think this will work. It would mean that you know in advance which version is compatible to name it correctly, here you must know that jpeg62rt is the compatible version, and without naming it too strict like jpeg6203b2rt. At the same time you want the name of the package to be as easy as possible which contradicts specific naming in advance. I have written the rationale for this in the Wiki at If there are arguments for/against the split please note them there. As I haven't heard of the maintainers who have already voted I guess the votes are still valid? If not, please adjust your vote accordingly as I want to have some kind of decision to go ahead: Best regards -- Dago From trygvis at opencsw.org Tue Oct 6 14:57:06 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Tue, 06 Oct 2009 14:57:06 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> Message-ID: <4ACB3EA2.7050900@opencsw.org> Dagobert Michelsen wrote: > Hi James, > > Am 05.10.2009 um 10:54 schrieb James Lee: >> On 04/10/09, 09:47:35, Dagobert Michelsen wrote >> regarding >> Re: [csw-maintainers] Handling of devel package splits: >> >>> I would like to proceed on the splitting of devel packages as a package >>> of mine is pending release whether the decision on this topic. >> >>> The current poll is >>> - 5 maintainers for "split off devel" >>> - 1 maintainer for "decide on case-by-case" >> >>> Does anyone feel that there is need for more discussion? >> >> Yes since you are missing options and no justification is offered. > > And that missing options would be? > > The justification is that it is a Good Thing not to have headers on > a deployment machine and that it is confusing for users to sometimes > have the devel-files inside the main package and sometimes not. > >>> Has anyone (especially those who have voted) understood that the split >>> will then be mandatory for package releases? >> >> No. You have not made that clear. >> >> The poll lumps doc too but the thread subject says devel. > > What does "lumps doc" mean? > >> Your poll is void. > > Ok then, do the maintainers who have already voted feel the same? Being even more explicit in proposal might be good. In particular the point that James raised about developer vs user documentation would be good to specify. Is the "doc" package user documentation? If so, should the development documentation go into the "devel" package? It states a requirement for splitting up the package into "rt" and "devel" but where should the documentation go then? -- Trygve From maciej at opencsw.org Tue Oct 6 15:04:39 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 6 Oct 2009 14:04:39 +0100 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <49301.217.225.247.115.1254649051.squirrel@ssl.skayser.de> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <49301.217.225.247.115.1254649051.squirrel@ssl.skayser.de> Message-ID: On Sun, Oct 4, 2009 at 10:37 AM, Sebastian Kayser wrote: > Dagobert Michelsen wrote: >> I would like to proceed on the splitting of devel packages as a package >> of mine is pending release whether the decision on this topic. >> >> The current poll is >> - 5 maintainers for "split off devel" >> - 1 maintainer for "decide on case-by-case" >> >> Does anyone feel that there is need for more discussion? >> >> Has anyone (especially those who have voted) understood that the split >> will then be mandatory for package releases? > > Do we have a written out wording for what is subject to the _devel split > then? > >> Sebastian, would you be willing to unify the bugs and introduce >> the "bugs-package-link" you suggested once we have clarified this >> issue? > > ?http://bugs.opencsw.org/ I think the domain bugs.opencsw.org is too nice to use up its top-level namespace! Can we have use like bugs.opencsw.org/p/ instead? Otherwise, we could have an explicitly shortcut domain, say, b.opencsw.org for the purpose of deploying shortcuts: b.opencsw.org/, so if anybody had "search opencsw.org" in their resolv.conf, they could use http://b/ (apart from the really useful Firefox keyword shortcuts). Maciej From dam at opencsw.org Tue Oct 6 15:25:18 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 6 Oct 2009 15:25:18 +0200 Subject: [csw-maintainers] Draft of the new release process Message-ID: Hi, I have finally written down the updated release process we talked about in Oslo: It is mainly about the different uses of the experimental / testing catalogs and automated builds. Trygve: I couldn't figure out what we intended with csw-build and csw-release. As you have proposed that it would be nice if you could add that to the Wiki. I have added pictures of the slides to refresh your memory ;-) Best regards -- Dago From maciej at opencsw.org Tue Oct 6 15:29:46 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 6 Oct 2009 14:29:46 +0100 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <49301.217.225.247.115.1254649051.squirrel@ssl.skayser.de> Message-ID: I've added a note about the drawbacks of *_devel package splitting. (Note: I'm not saying that splitting overall bad. I'm saying it has drawbacks, and it's a good idea to minimize the negative impact.) Maciej From dam at opencsw.org Tue Oct 6 15:38:43 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 6 Oct 2009 15:38:43 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <4ACB3EA2.7050900@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <4ACB3EA2.7050900@opencsw.org> Message-ID: <6DFA4F1D-1B3A-4D1E-A5B0-80E7124C8118@opencsw.org> Hi, Am 06.10.2009 um 14:57 schrieb Trygve Laugst?l: > Being even more explicit in proposal might be good. Thanks for your feedback, Wiki has been clarified with your and Maciejs statements. Best regards -- Dago From maciej at opencsw.org Tue Oct 6 15:47:58 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 6 Oct 2009 14:47:58 +0100 Subject: [csw-maintainers] Draft of the new release process In-Reply-To: References: Message-ID: On Tue, Oct 6, 2009 at 2:25 PM, Dagobert Michelsen wrote: > Hi, > > I have finally written down the updated release process we > talked about in Oslo: > ? > It is mainly about the different uses of the experimental / testing > catalogs and automated builds. Yey! The mentioned script, cswrepo -- is it something that's planned or already implemented? > Trygve: I couldn't figure out what we intended with csw-build and > csw-release. As you have proposed that it would be nice if you could > add that to the Wiki. I have added pictures of the slides to refresh > your memory ;-) IIRC, There was talk about two scripts. One for the maintainers, something which would copy the ready packages into an appropriate place (bender:/home/newpkgs or equivalent) and format e-mails to the release manager. The one for the release manager would help the release manager do his thing, whatever that is. Trygve was interested in what steps are taken when a package is being released, in terms of updating information in various places (databases, files, etc). Maciej From james at opencsw.org Tue Oct 6 16:03:30 2009 From: james at opencsw.org (James Lee) Date: Tue, 06 Oct 2009 14:03:30 GMT Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> Message-ID: <20091006.14033000.2372649415@gyor.oxdrove.co.uk> On 06/10/09, 12:55:05, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Handling of devel package splits: > > The only addition I have it to version runtimes as it means only one > > version is needed at a time for a given depend. > > > > jpeg depends on jpeg7rt > > jpeg7rt - latest runtime > > jpeg62rt - legacy runtime > > > > packages depend on whichever rt version being used. > I don't think this will work. Don't think, watch the opposition. > It would mean that you know in advance > which > version is compatible to name it correctly, here you must know that > jpeg62rt > is the compatible version, and without naming it too strict like > jpeg6203b2rt. I know because of the SONAME. Example of potential saving. CSWlibicu 4.2.1,REV=2009.08.10 Package size: 14883205 installed size: 35943114 Contains libraries with 2 SONAMEs: .so.36 and .so.42 $ cat /opt/csw/lib/libicu*so.36.0 | wc -c 12916776 $ cat /opt/csw/lib/libicu*so.42.1 | wc -c 19310756 1 package uses .42 (CSWooocore), 2 use .36 (CSWtin, CSWx3270) Each could use just the rt that it needs. The best bit is when the 2 older packages are rebuilt to use the newer rt the combined package does not need rebuilding with only the used lib as the unused rt package can just be dropped. Potential savings are massive, far greater than some x lib headers. Package split: libiuc42rt - the .so.42 runtime used by CSWooocore, CSWlibicu libiuc36rt - the .so.36 runtime used by CSWtin, CSWx3270 libicu everything 4.2 except libiuc42rt No user will ever install libicu, only developers. > At the same time you want the name of the package to be as easy as > possible > which contradicts specific naming in advance. > I have written the rationale for this in the Wiki at > > Why are packages split? > There are multiple reasons why packages are split: I suppose two is "multiple" > To minimize the size of the installed software, both in terms of > megabytes and number of files In the case of the x libs (where this started) only the run time is installed for users so there are no extra development or documentation bytes. Minimising the number of package also has benefits. Quicker install. Shorter lists. Easier management. File storage is not that important. > To have a clean installation of the software (no developer files on > deployment machines) man filesytem(5). There is a handy established way of keeping the system tidy. Reasons not to split: + Many more packages to manage + No space saving when only runtimes used, which is in most cases. + It's a pain for the developer to know to install the -dev packages. Not all packages naturally have dev parts and it's not possible to tell if it's missing or never exists (oh great, lets have empty packages where none is needed to keep the system symmetric and avoid all confusion). + I always install "full" OS (because it's saves any effort when I later find something is missing) so there is no problem with finding headers on the system. + Solaris has lots of files that are never needed. Doesn't make it right but the user tolerates it, assuming a true user even notices. + CSW wastes space in many ways, this isn't the most significant. Packages are about package deals and a one size fits all approach might be best, ie, the user accepts extra bytes in exchange for a shared system. + It's pissing me off. James. From dam at opencsw.org Tue Oct 6 16:04:41 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 6 Oct 2009 16:04:41 +0200 Subject: [csw-maintainers] Draft of the new release process In-Reply-To: References: Message-ID: Hi Maciej, Am 06.10.2009 um 15:47 schrieb Maciej (Matchek) Blizinski: > On Tue, Oct 6, 2009 at 2:25 PM, Dagobert Michelsen > wrote: >> I have finally written down the updated release process we >> talked about in Oslo: >> >> It is mainly about the different uses of the experimental / testing >> catalogs and automated builds. > > Yey! > > The mentioned script, cswrepo -- is it something that's planned or > already implemented? Planned :) >> Trygve: I couldn't figure out what we intended with csw-build and >> csw-release. As you have proposed that it would be nice if you could >> add that to the Wiki. I have added pictures of the slides to refresh >> your memory ;-) > > IIRC, There was talk about two scripts. One for the maintainers, > something which would copy the ready packages into an appropriate > place (bender:/home/newpkgs or equivalent) and format e-mails to the > release manager. The one for the release manager would help the > release manager do his thing, whatever that is. Trygve was interested > in what steps are taken when a package is being released, in terms of > updating information in various places (databases, files, etc). As you see there is some more work to clarify this. Phil has already written down something of this: Best regards -- Dago From schwindt at dfki.uni-kl.de Tue Oct 6 16:16:41 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Tue, 06 Oct 2009 16:16:41 +0200 Subject: [csw-maintainers] Installation issues Message-ID: <200910061416.n96EGf18013821@dfki.uni-kl.de> Recently I do get some messages like this on installing packages. Here as an example openssh , but there are others. This could be observed on different machines, doing fresh installs or upgrades. [ verifying class ] Copying sample config to /opt/csw/etc/ssh/moduli usage: chmod [-fR] file ... chmod [-fR] file ... chmod [-fR] file ... where is a comma-separated list of [ugoa]{+|-|=}[rwxXlstugo] where is one of the following A- A[number]- A[number]{+|=} where is a comma-separated list of ACEs Copying sample config to /opt/csw/etc/ssh/sshd_config usage: chmod [-fR] file ... chmod [-fR] file ... chmod [-fR] file ... where is a comma-separated list of [ugoa]{+|-|=}[rwxXlstugo] where is one of the following A- A[number]- A[number]{+|=} where is a comma-separated list of ACEs [ verifying class ] Installing class ... This end up on disk : rw-r--r-- 1 root bin 125811 Jul 25 13:30 moduli.CSW -rwxr-xr-x 1 root root 125811 Oct 6 15:15 moduli Anyone else ? Nicolai From dam at opencsw.org Tue Oct 6 16:47:27 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 6 Oct 2009 16:47:27 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <20091006.14033000.2372649415@gyor.oxdrove.co.uk> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> <20091006.14033000.2372649415@gyor.oxdrove.co.uk> Message-ID: <3DBDD958-E508-4B74-BF39-03DD16B16BB3@opencsw.org> Hi James, Am 06.10.2009 um 16:03 schrieb James Lee: > On 06/10/09, 12:55:05, Dagobert Michelsen wrote > regarding > Re: [csw-maintainers] Handling of devel package splits: > >>> The only addition I have it to version runtimes as it means only one >>> version is needed at a time for a given depend. >>> >>> jpeg depends on jpeg7rt >>> jpeg7rt - latest runtime >>> jpeg62rt - legacy runtime >>> >>> packages depend on whichever rt version being used. > >> I don't think this will work. > > Don't think, watch the opposition. > > >> It would mean that you know in advance >> which >> version is compatible to name it correctly, here you must know that >> jpeg62rt >> is the compatible version, and without naming it too strict like >> jpeg6203b2rt. > > I know because of the SONAME. > > Example of potential saving. > > CSWlibicu 4.2.1,REV=2009.08.10 > > Package size: 14883205 > installed size: 35943114 > > Contains libraries with 2 SONAMEs: .so.36 and .so.42 > > $ cat /opt/csw/lib/libicu*so.36.0 | wc -c > 12916776 > $ cat /opt/csw/lib/libicu*so.42.1 | wc -c > 19310756 > > 1 package uses .42 (CSWooocore), 2 use .36 (CSWtin, CSWx3270) > > Each could use just the rt that it needs. > > The best bit is when the 2 older packages are rebuilt to use the > newer rt the combined package does not need rebuilding with only > the used lib as the unused rt package can just be dropped. > > Potential savings are massive, far greater than some x lib headers. > > Package split: > > libiuc42rt - the .so.42 runtime used by CSWooocore, CSWlibicu > libiuc36rt - the .so.36 runtime used by CSWtin, CSWx3270 > libicu everything 4.2 except libiuc42rt > > No user will ever install libicu, only developers. Ok, that means you look what is linked against and then decide how the rt is named? > At the same time you want the name of the package to be as easy as >> possible >> which contradicts specific naming in advance. > >> I have written the rationale for this in the Wiki at >> > >> Why are packages split? > >> There are multiple reasons why packages are split: > > I suppose two is "multiple" > > >> To minimize the size of the installed software, both in terms of >> megabytes and number of files > > In the case of the x libs (where this started) only the run time is > installed for users so there are no extra development or documentation > bytes. > > Minimising the number of package also has benefits. Quicker install. > Shorter lists. Easier management. > > File storage is not that important. > > >> To have a clean installation of the software (no developer files on >> deployment machines) > > man filesytem(5). There is a handy established way of keeping the > system tidy. Separating filesystems still gets them inside the tree. > Reasons not to split: > > + Many more packages to manage > > + No space saving when only runtimes used, which is in most cases. > > + It's a pain for the developer to know to install the -dev packages. > Not all packages naturally have dev parts and it's not possible to > tell if it's missing or never exists (oh great, lets have empty > packages where none is needed to keep the system symmetric and avoid > all confusion). > > + I always install "full" OS (because it's saves any effort when I > later find something is missing) so there is no problem with finding > headers on the system. > > + Solaris has lots of files that are never needed. Doesn't make it > right but the user tolerates it, assuming a true user even notices. > > + CSW wastes space in many ways, this isn't the most significant. > Packages are about package deals and a one size fits all approach > might be best, ie, the user accepts extra bytes in exchange for > a shared system. Added to the wiki for further discussion. > + It's pissing me off. Not added to the wiki. Best regards -- Dago From james at opencsw.org Tue Oct 6 17:17:47 2009 From: james at opencsw.org (James Lee) Date: Tue, 06 Oct 2009 15:17:47 GMT Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <3DBDD958-E508-4B74-BF39-03DD16B16BB3@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> <20091006.14033000.2372649415@gyor.oxdrove.co.uk> <3DBDD958-E508-4B74-BF39-03DD16B16BB3@opencsw.org> Message-ID: <20091006.15174700.2402857481@gyor.oxdrove.co.uk> On 06/10/09, 15:47:27, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Handling of devel package splits: > >>> The only addition I have it to version runtimes as it means only one > >>> version is needed at a time for a given depend. > >>> > >>> jpeg depends on jpeg7rt > >>> jpeg7rt - latest runtime > >>> jpeg62rt - legacy runtime > >>> > >>> packages depend on whichever rt version being used. > > > >> I don't think this will work. > > > > Don't think, watch the opposition. > > > > > >> It would mean that you know in advance > >> which > >> version is compatible to name it correctly, here you must know that > >> jpeg62rt > >> is the compatible version, and without naming it too strict like > >> jpeg6203b2rt. > > > > I know because of the SONAME. > > > > Example of potential saving. > > > > CSWlibicu 4.2.1,REV=2009.08.10 > > > > Package size: 14883205 > > installed size: 35943114 > > > > Contains libraries with 2 SONAMEs: .so.36 and .so.42 > > > > $ cat /opt/csw/lib/libicu*so.36.0 | wc -c > > 12916776 > > $ cat /opt/csw/lib/libicu*so.42.1 | wc -c > > 19310756 > > > > 1 package uses .42 (CSWooocore), 2 use .36 (CSWtin, CSWx3270) > > > > Each could use just the rt that it needs. > > > > The best bit is when the 2 older packages are rebuilt to use the > > newer rt the combined package does not need rebuilding with only > > the used lib as the unused rt package can just be dropped. > > > > Potential savings are massive, far greater than some x lib headers. > > > > Package split: > > > > libiuc42rt - the .so.42 runtime used by CSWooocore, CSWlibicu > > libiuc36rt - the .so.36 runtime used by CSWtin, CSWx3270 > > libicu everything 4.2 except libiuc42rt > > > > No user will ever install libicu, only developers. > Ok, that means you look what is linked against and then decide > how the rt is named? No, I look at the SONAME, this defines the library that is used. In the case of PNG there are 2 SONAMEs indicating version: libpng12.so.0 libpng.so.3 but rather than use the actual SONAME's number I'd assume that the major package version change mirrors the so changes, so for PNG I guess it would simply follow the package version. Either way it's just a name. Same SONAME, same RT package name. Bumped SONAME, new RT package name. James. From maciej at opencsw.org Tue Oct 6 17:55:51 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 6 Oct 2009 16:55:51 +0100 Subject: [csw-maintainers] GAR modulations questions Message-ID: I have two issues regarding modulations. One is a feature request. Suppose I have two extra modulators, foo and bar. If each has two values, I end up with four... um... modulations. The name for each modulation is foomod-foovar-barmod-barval. If I want to add my own merge rules, I need to enter: MERGE_foomod-fooval1-barmod-barval1 = ... MERGE_foomod-fooval1-barmod-barval2 = ... MERGE_foomod-fooval2-barmod-barval1 = ... MERGE_foomod-fooval2-barmod-barval2 = ... Suppose I have a merge rule that applies to both values of barmod. I would like then to say: MERGE_foomod-fooval1 = one thing MERGE_foomod-fooval2 = some other thing The desired effect is that "one thing" is included in both barval1 and barval2 modulations. Is it doable? The second thing, version-modulated distfiles. Can we, instead of creating the list and the filtering it, include only the right versions? For instance: DISTFILES_version-$(GARVERSION) = $(GARNAME)-$(GARVERSION).tar.gz ...and then have DISTFILES being assembled by GAR? Maciej From phil at bolthole.com Tue Oct 6 18:02:16 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 6 Oct 2009 09:02:16 -0700 Subject: [csw-maintainers] questions about GAR, history, and naming In-Reply-To: References: <20091004195314.GA33599@bolthole.com> <719DE490-C858-436F-A1CC-A06029BA3D98@opencsw.org> <9046596F-57B6-4AA0-9B36-60C9F1497A56@opencsw.org> <0315E28D-99D7-42DB-A144-8A6B4E85A771@opencsw.org> <32973644-DFF4-4BD1-A760-90422E02A60A@opencsw.org> Message-ID: On Tue, Oct 6, 2009 at 1:43 AM, Maciej (Matchek) Blizinski wrote: >I'd like us to make development > decisions based on current needs rather than aesthetics. The > restructuring of GAR can be filed in an issue tracking system so the > idea doesn't get lost or forgotten. Hmm. an idea that is filed away and never acted upon, may as well be forgotten. The idea of having a proper "gar package" that is a CSW package, has been lurking around for YEARS now, and never acted upon. > Is "to do things cleanly" the only reason, or are there more reasons? Well, to me, it is also somewhat of a branding issue. We cant really publicise our build system fairly. It's almost as bad as sun labelling everything they do, "sun java xxxx" :-) Claiming "we use gar", at this point,is very wrong. What we use is not "gar", but "gar++". And the longer we wait to fix this issue, the worse it gets. It would have been easier to fix this a year ago, than now, I think everyone can agree. It stands to reason it will be even more difficult to fix this a year in the future, than to fix this now. It bothers me to the point where I would do the work myself, but all my "free" time goes to package release issues, etc. From dam at opencsw.org Tue Oct 6 18:04:55 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 6 Oct 2009 18:04:55 +0200 Subject: [csw-maintainers] GAR modulations questions In-Reply-To: References: Message-ID: <5BC0D8E5-7CE6-4FE3-8BD3-942F5685FD72@opencsw.org> Hi Maciej, Am 06.10.2009 um 17:55 schrieb Maciej (Matchek) Blizinski: > I have two issues regarding modulations. One is a feature request. > Suppose I have two extra modulators, foo and bar. If each has two > values, I end up with four... um... modulations. The name for each > modulation is foomod-foovar-barmod-barval. If I want to add my own > merge rules, I need to enter: > > MERGE_foomod-fooval1-barmod-barval1 = ... > MERGE_foomod-fooval1-barmod-barval2 = ... > MERGE_foomod-fooval2-barmod-barval1 = ... > MERGE_foomod-fooval2-barmod-barval2 = ... > > Suppose I have a merge rule that applies to both values of barmod. I > would like then to say: > > MERGE_foomod-fooval1 = one thing > MERGE_foomod-fooval2 = some other thing > > The desired effect is that "one thing" is included in both barval1 and > barval2 modulations. Is it doable? Sure. But I don't see a usecase for this. Usually you take all from barval1 and only some specific things with renames from barval2. Additionally, the modulators grow long with the default ISA modulation and maybe the added version modulator. Some kind of sane defaults can make this much easier to use. Can I have a look at your Makefile? > The second thing, version-modulated distfiles. Can we, instead of > creating the list and the filtering it, include only the right > versions? For instance: > > DISTFILES_version-$(GARVERSION) = $(GARNAME)-$(GARVERSION).tar.gz > > ...and then have DISTFILES being assembled by GAR? I have already tought of something similar as you your left-hand side would expand during Makefile parsing. You would need some kind of definition like VDISTFILES = $$(GARNAME)-$$(VERSION).tar.gz which would then be expanded during evaluation. It would also allow automatic upstream watches with substituted $$(VERSION) for UWATCH and easier version modulations. But before I make more changes to GAR I would like to deploy v2-pbuild for general use, so please everyone test! Best regards -- Dago From maciej at opencsw.org Tue Oct 6 18:16:36 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 6 Oct 2009 17:16:36 +0100 Subject: [csw-maintainers] GAR modulations questions In-Reply-To: <5BC0D8E5-7CE6-4FE3-8BD3-942F5685FD72@opencsw.org> References: <5BC0D8E5-7CE6-4FE3-8BD3-942F5685FD72@opencsw.org> Message-ID: On Tue, Oct 6, 2009 at 5:04 PM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 06.10.2009 um 17:55 schrieb Maciej (Matchek) Blizinski: >> >> I have two issues regarding modulations. One is a feature request. >> Suppose I have two extra modulators, foo and bar. If each has two >> values, I end up with four... um... modulations. The name for each >> modulation is foomod-foovar-barmod-barval. If I want to add my own >> merge rules, I need to enter: >> >> MERGE_foomod-fooval1-barmod-barval1 = ... >> MERGE_foomod-fooval1-barmod-barval2 = ... >> MERGE_foomod-fooval2-barmod-barval1 = ... >> MERGE_foomod-fooval2-barmod-barval2 = ... >> >> Suppose I have a merge rule that applies to both values of barmod. I >> would like then to say: >> >> MERGE_foomod-fooval1 = one thing >> MERGE_foomod-fooval2 = some other thing >> >> The desired effect is that "one thing" is included in both barval1 and >> barval2 modulations. Is it doable? > > Sure. But I don't see a usecase for this. Usually you take all from > barval1 and only some specific things with renames from barval2. > Additionally, the modulators grow long with the default ISA modulation > and maybe the added version modulator. Some kind of sane defaults > can make this much easier to use. > Can I have a look at your Makefile? Here's my minimal example: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/examples/modulations/branches/minimal-version-modulation/Makefile > But before I make more changes to GAR I would like to deploy v2-pbuild > for general use, so please everyone test! Okay, I'm going to start using it with the packages I'm currently working on. Maciej From bwalton at opencsw.org Tue Oct 6 19:12:51 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 06 Oct 2009 13:12:51 -0400 Subject: [csw-maintainers] passwd -N Message-ID: <1254848861-sup-1353@ntdws12.chass.utoronto.ca> Is anyone aware of a clever alternative to solaris 10's `passwd -N` for munging the password field in a shadow file? Ultimately, I'd prefer not to twiddle the file with sed, but that seems to be the best option I've found. Any help is appreciated. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Oct 6 19:18:21 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 6 Oct 2009 19:18:21 +0200 Subject: [csw-maintainers] GAR modulations questions In-Reply-To: References: <5BC0D8E5-7CE6-4FE3-8BD3-942F5685FD72@opencsw.org> Message-ID: <2C186202-52BD-4D17-A1F8-B0CBD8727EFD@opencsw.org> Hi Maciej, Am 06.10.2009 um 18:16 schrieb Maciej (Matchek) Blizinski: > Here's my minimal example: > > https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/examples/modulations/branches/minimal-version-modulation/Makefile Ok. But allow me the comment that this is a real special case. I have exactly 1 (one) package that needs this (automake) and I do it with $(foreach VERSION,$(MODULATIONS_GARVERSION),$(eval MERGE_SCRIPTS_isa-$(ISA)-garversion-$(VERSION) = copy-all)) All other packages need different rules: expat flac libmm libtool neon openldap readline Usually you have something like this: MERGE_SCRIPTS_isa-i386-garversion-1.95.8 = copy-only MERGE_DIRS_isa-i386-garversion-1.95.8 = $(libdir) MERGE_SCRIPTS_isa-amd64-garversion-1.95.8 = copy-relocated-only MERGE_DIRS_isa-amd64-garversion-1.95.8 = $(libdir) MERGE_SCRIPTS_isa-i386-garversion-2.0.1 = copy-all MERGE_SCRIPTS_isa-amd64-garversion-2.0.1 = copy-relocated-only MERGE_DIRS_isa-amd64-garversion-2.0.1 = $(bindir) $(sbindir) $ (libexecdir) $(libdir) MERGE_SCRIPTS_isa-sparcv8-garversion-1.95.8 = copy-only MERGE_DIRS_isa-sparcv8-garversion-1.95.8 = $(libdir) MERGE_SCRIPTS_isa-sparcv9-garversion-1.95.8 = copy-relocated-only MERGE_DIRS_isa-sparcv9-garversion-1.95.8 = $(libdir) MERGE_SCRIPTS_isa-sparcv8-garversion-2.0.1 = copy-all MERGE_SCRIPTS_isa-sparcv9-garversion-2.0.1 = copy-relocated-only MERGE_DIRS_isa-sparcv9-garversion-2.0.1 = $(bindir) $(sbindir) $ (libexecdir) $(libdir) which could be collapsed with smart merge rules as MERGE_SCRIPTS_isa-default-garversion-extra = copy-only MERGE_DIRS_isa-default-garversion-extra = $(libdir) MERGE_SCRIPTS_isa-extra-garversion-extra = copy-relocated-only MERGE_DIRS_isa-extra-garversion-extra = $(libdir) MERGE_SCRIPTS_isa-default-garversion-default = copy-all MERGE_SCRIPTS_isa-extra-garversion-default = copy-relocated-only MERGE_DIRS_isa-extra-garversion-default = $(bindir) $(sbindir) $ (libexecdir) $(libdir) And this can be the default for version modulations if it were built-in. Best regards -- Dago From phil at bolthole.com Tue Oct 6 19:20:36 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 6 Oct 2009 10:20:36 -0700 Subject: [csw-maintainers] X11 woes In-Reply-To: <142A0DD9-4FB7-45D7-9092-6BA80999A7D1@opencsw.org> References: <142A0DD9-4FB7-45D7-9092-6BA80999A7D1@opencsw.org> Message-ID: On Tue, Oct 6, 2009 at 1:13 AM, Dagobert Michelsen wrote: > Hi, > > I am currently refreshing imlib/imlib2. On compilation they seem to pull > in the old libx11 (and breaks!) as the depend on libungif which itself > is compiled against the old X11. I guess it would be cleanest to go > through all libraries which depend on X11 and recompile them against the > new version or maybe someone has a better idea? > > that is a little overkill. Lets get more specific here: Since YOU "broke", you now need to ensure that everything that depends on it, gets recompiled. Either that, or provide an older compat version of libungif. Other stuf that still works, can be left alone, even if it uses standard "old libx11". From maciej at opencsw.org Tue Oct 6 19:33:35 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 6 Oct 2009 18:33:35 +0100 Subject: [csw-maintainers] GAR modulations questions In-Reply-To: <2C186202-52BD-4D17-A1F8-B0CBD8727EFD@opencsw.org> References: <5BC0D8E5-7CE6-4FE3-8BD3-942F5685FD72@opencsw.org> <2C186202-52BD-4D17-A1F8-B0CBD8727EFD@opencsw.org> Message-ID: On Tue, Oct 6, 2009 at 6:18 PM, Dagobert Michelsen wrote: > Ok. But allow me the comment that this is a real special case. OK, I understand. > MERGE_SCRIPTS_isa-i386-garversion-2.0.1 = copy-all > MERGE_SCRIPTS_isa-amd64-garversion-2.0.1 = copy-relocated-only > MERGE_DIRS_isa-amd64-garversion-2.0.1 = $(bindir) $(sbindir) $(libexecdir) > $(libdir) More questions are coming: Why are MERGE_DIRS needed? How do I make sure I have the right ones? From mwatters at opencsw.org Tue Oct 6 21:24:13 2009 From: mwatters at opencsw.org (Mike Watters) Date: Tue, 06 Oct 2009 14:24:13 -0500 Subject: [csw-maintainers] sendmail-8.14.3 in testing Message-ID: <4ACB995D.90707@opencsw.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 once Dago is done with berkeley DB it will be recompiled based on the "new" package names for bdb. please test and provide feedback. - -- ~Mike "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." --> Albert Einstein 1879 - 1955 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrLmV0ACgkQLrhmsXMSLxcCvwCfbD1K8s6MUG0qYU0SJBjTRNwY YfwAoIZKLWZm0FKSFVRrckthtfrwYnZc =aqI+ -----END PGP SIGNATURE----- From skayser at opencsw.org Tue Oct 6 22:09:34 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 6 Oct 2009 22:09:34 +0200 (CEST) Subject: [csw-maintainers] BerkeleyDB final call In-Reply-To: References: Message-ID: <52119.194.246.122.22.1254859774.squirrel@ssl.skayser.de> Dagobert Michelsen wrote: > The packages are available from > > and there are subdirectories for Solaris 8 Sparc and x86 with catalogs > which should allow direct updating with pkg-get/pkgutil. > Additionally all packages have been installed on test8s and test8x. > > To make this transition less painful than the previous one please > test the new packages in your environment, test them with the > packages which failed last time and the packages you would consider > most important. Thanks Dago for working towards the old status quo. Attached is a list of packages directly depending on CSWbdb* packages. If someone spots a package he is using regularly (best in a scenario with bdb involved), please help testing by updating your BDB packages. CSWap2modapreq2 CSWap2modphp4 CSWap2prefork CSWap2worker CSWapache CSWapache2c CSWapache2rt CSWcfengine CSWclaws-mail CSWcourierauth CSWcourierimap CSWcyrusimapd CSWcyrusimapdutils CSWdsniff CSWjavasvn CSWkdesdk CSWkdesdk CSWkdevelop CSWkdevelop CSWlibapreq2 CSWlibetpan CSWmaildrop CSWmodphp4 CSWoldap CSWooocore CSWperl CSWphp4cgi CSWphp4dba CSWphp5dba CSWpmapreq2 CSWpmberkeleydb CSWpmcyrus CSWpmsvn CSWpostfix CSWpysvn CSWpython CSWrbsvn CSWruby CSWsasl CSWsendmail CSWsquidguard CSWsqwebmail CSWsvn CSWwebalizer Dago has setup a separate subdirectory in testing/ where you can upgrade from, so you will only get BDB updates (and none of the possibly-in-development-pkgs from testing). Sebastian From mwatters at opencsw.org Tue Oct 6 22:17:09 2009 From: mwatters at opencsw.org (Mike Watters) Date: Tue, 06 Oct 2009 15:17:09 -0500 Subject: [csw-maintainers] libssh2 1.2.1 in testing Message-ID: <4ACBA5C5.5030804@opencsw.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Changes: upgraded to version 1.2.1 feedback welcome - -- ~Mike "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." --> Albert Einstein 1879 - 1955 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrLpcQACgkQLrhmsXMSLxczbwCdGL3niQV1rG6L7ECKYSTPt/ZP yjYAn3fUYad0TFKm/Kg5a57i8pqWxVmM =gL9w -----END PGP SIGNATURE----- From mwatters at opencsw.org Tue Oct 6 22:49:55 2009 From: mwatters at opencsw.org (Mike Watters) Date: Tue, 06 Oct 2009 15:49:55 -0500 Subject: [csw-maintainers] drupal 6.14 now in testing Message-ID: <4ACBAD73.2060905@opencsw.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Changes: updated to 6.14 - -- ~Mike "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." --> Albert Einstein 1879 - 1955 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrLrXMACgkQLrhmsXMSLxdK2gCeNtf1v6nNziHzQG9CtyH/TRka 32AAmgJWzM3fQa8sNJCjDt8ZeEr1QAjs =BD0J -----END PGP SIGNATURE----- From bchill at opencsw.org Wed Oct 7 07:54:48 2009 From: bchill at opencsw.org (Brian Hill) Date: Wed, 7 Oct 2009 05:54:48 +0000 Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <4ACB995D.90707@opencsw.org> References: <4ACB995D.90707@opencsw.org> Message-ID: <20091007055448.GA13472@vm-1.bch.net> Hi Mike, I assume that this should work with existing CSWberkeleydb package until you rebuild it with the new berk db package name. Am I missing something? ... Updated description file INTERNAL ERROR: cannot get remote version for CSWbdb Perhaps your catalog is out of date Error: dependancies for sendmail not up to date. You may call pkg-get again with '-v -u sendmail' to see which ones Or, call pkg-get with 'upgrade' to bring all installed pkgs up to date Brian ====================================================================== On Tue, Oct 06, 2009 at 02:24:13PM -0500, Mike Watters wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > once Dago is done with berkeley DB it will be recompiled based on the "new" > package names for bdb. > > please test and provide feedback. > > > - -- > ~Mike > "Any intelligent fool can make things bigger, more complex, > and more violent. It takes a touch of genius -- and a lot of courage -- > to move in the opposite direction." --> Albert Einstein 1879 - 1955 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (SunOS) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkrLmV0ACgkQLrhmsXMSLxcCvwCfbD1K8s6MUG0qYU0SJBjTRNwY > YfwAoIZKLWZm0FKSFVRrckthtfrwYnZc > =aqI+ > -----END PGP SIGNATURE----- > _______________________________________________ > users mailing list > users at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/users -- _____________________________________________________________________ / Brian C. Hill bchill at bch.net http://brian.bch.net \ | UNIX Specialist BCH Technical Services http://www.bch.net | From dam at opencsw.org Wed Oct 7 13:39:54 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 7 Oct 2009 13:39:54 +0200 Subject: [csw-maintainers] questions about GAR, history, and naming In-Reply-To: References: <20091004195314.GA33599@bolthole.com> <719DE490-C858-436F-A1CC-A06029BA3D98@opencsw.org> <9046596F-57B6-4AA0-9B36-60C9F1497A56@opencsw.org> <0315E28D-99D7-42DB-A144-8A6B4E85A771@opencsw.org> <32973644-DFF4-4BD1-A760-90422E02A60A@opencsw.org> Message-ID: <493A50BB-64A2-457D-A307-185096960F35@opencsw.org> Hi Phil, Am 06.10.2009 um 18:02 schrieb Philip Brown: > On Tue, Oct 6, 2009 at 1:43 AM, Maciej (Matchek) Blizinski > wrote: >> I'd like us to make development >> decisions based on current needs rather than aesthetics. The >> restructuring of GAR can be filed in an issue tracking system so the >> idea doesn't get lost or forgotten. > > Hmm. an idea that is filed away and never acted upon, may as well be > forgotten. > The idea of having a proper "gar package" that is a CSW package, has > been lurking around for YEARS now, and never acted upon. It is not forgotten. A GAR package is lurking around in newpkgs/ since May and you didn't want to release it ;-) To get something done there are two ways: either do it yourself or find someone to do it. I may have put more energy to source packages if you would show real interest in GAR by using it for your packages or at least to a level where you can reproduce a build without the demand that "someone writes up an interface for me that I can do 'gartool compile '". And now you are proposing a complete rewrite of GAR which means at least a week of work for me only for you to feel better about it. If you want a rewrite of GAR at least learn the basics on how to use it. >> Is "to do things cleanly" the only reason, or are there more reasons? > > Well, to me, it is also somewhat of a branding issue. We cant really > publicise our build system fairly. It's almost as bad as sun labelling > everything they do, "sun java xxxx" :-) > Claiming "we use gar", at this point,is very wrong. What we use is not > "gar", but "gar++". > And the longer we wait to fix this issue, the worse it gets. It is perfectly ok to say that we use "gar++" to build our packages. The sources are available at SF under the project name "gar". > It would have been easier to fix this a year ago, than now, I think > everyone can agree. > It stands to reason it will be even more difficult to fix this a year > in the future, than to fix this now. > > It bothers me to the point where I would do the work myself, but all > my "free" time goes to package release issues, etc. That is a real pitty as I don't have time for this either. Best regards -- Dago From dam at opencsw.org Wed Oct 7 14:36:01 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 7 Oct 2009 14:36:01 +0200 Subject: [csw-maintainers] Proposal for name of our GAR version Message-ID: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> Hi, I did some thinking about a name for our version of the GAR build system and ended up with "GARISOL". This is an anagram of girasol, which is italian for sunflower showing the affinity both to GAR and Solaris without being an actual word - this makes searching for it and reserving names easier. Feedback especially welcome! Best regards -- Dago From dam at opencsw.org Wed Oct 7 14:41:31 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 7 Oct 2009 14:41:31 +0200 Subject: [csw-maintainers] passwd -N In-Reply-To: <1254848861-sup-1353@ntdws12.chass.utoronto.ca> References: <1254848861-sup-1353@ntdws12.chass.utoronto.ca> Message-ID: <47474866-5DFA-48C5-8DA4-4D0CEFB5F373@opencsw.org> Hi Ben, Am 06.10.2009 um 19:12 schrieb Ben Walton: > Is anyone aware of a clever alternative to solaris 10's `passwd -N` > for munging the password field in a shadow file? Ultimately, I'd > prefer not to twiddle the file with sed, but that seems to be the best > option I've found. Yes. It may be a little clean with awk: awk -F: 'BEGIN { OFS=":" } $1 == "dam" { $2 = "NP" } { print }' < / etc/shadow Best regards -- Dago From maciej at opencsw.org Wed Oct 7 14:50:13 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 7 Oct 2009 13:50:13 +0100 Subject: [csw-maintainers] GAR Platform builds now open for testing In-Reply-To: References: <0F1DEF08-4D55-4224-ADFC-DE1DD712E9A7@opencsw.org> <05F1A42C-9047-4EBF-A531-3A2212A8DC19@opencsw.org> Message-ID: I've got a problem with building cups: $ ENABLE_CHECK=0 gmake platforms (...) mkp: exec( gzip -9 -f /tmp/cupsd-1.4.0,REV=2009.10.07.14.32-SunOS5.8-i386-CSW.pkg ) mkp: exec( mv /tmp/cupsd-1.4.0,REV=2009.10.07.14.32-SunOS5.8-i386-CSW.pkg.gz /home/maciej/staging/build-2009-10-07 ) mkp: exec( rm -rf /home/maciej/spool.5.8-i386/CSWcupsd ) ==> Checking compliance: CSWcupsd ERROR: /home/maciej/staging/build-2009-10-07/cupsd-1.4.0,REV=2009.10.07.14.33-SunOS5.8-i386-CSW.pkg.gz does not exist gmake: *** [pkgcheck-CSWcupsd] Error 2 gmake: Leaving directory `/home/maciej/src/opencsw/pkg/cups/branches/cups-1.4' Connection to build8x closed. gmake: *** [platforms] Error 2 Looks like it's the usual checkpkg problem, this only this time ENABLE_CHECK=0 doesn't work around the issue. Any ideas? It's the cups-1.4 branch. Maciej From dam at opencsw.org Wed Oct 7 14:51:56 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 7 Oct 2009 14:51:56 +0200 Subject: [csw-maintainers] GAR modulations questions In-Reply-To: References: <5BC0D8E5-7CE6-4FE3-8BD3-942F5685FD72@opencsw.org> <2C186202-52BD-4D17-A1F8-B0CBD8727EFD@opencsw.org> Message-ID: <6E5C90B7-073B-46FC-AD64-0897884DA807@opencsw.org> Hi Maciej, Am 06.10.2009 um 19:33 schrieb Maciej (Matchek) Blizinski: > On Tue, Oct 6, 2009 at 6:18 PM, Dagobert Michelsen > wrote: >> Ok. But allow me the comment that this is a real special case. > > OK, I understand. > >> MERGE_SCRIPTS_isa-i386-garversion-2.0.1 = copy-all >> MERGE_SCRIPTS_isa-amd64-garversion-2.0.1 = copy-relocated-only >> MERGE_DIRS_isa-amd64-garversion-2.0.1 = $(bindir) $(sbindir) $ >> (libexecdir) $(libdir) > > More questions are coming: > > Why are MERGE_DIRS needed? How do I make sure I have the right ones? Remember pages 46/47 from the Advanced GAR presentation: You need the dirs for the rules "copy-only" and "copy-relocated-only". They specify which directories from the installed files for that modulation will go into the package. Usually you use this for stuff which is somewhat "extra" to the package: extra (older) libraries, extra (64 bit) binaries etc. The default can be thought of $(bindir) $(sbindir) $(libexecdir) $(libdir) which basically means "everything sensible". If you want only libs (e. g. when doing 64 bits) and no executable you do $(libdir) I have started to write this up at (Don't look yet, I have *just* started ;-) Best regards -- Dago From bwalton at opencsw.org Wed Oct 7 15:16:48 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 07 Oct 2009 09:16:48 -0400 Subject: [csw-maintainers] Proposal for name of our GAR version In-Reply-To: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> References: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> Message-ID: <1254921389-sup-6432@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Oct 07 08:36:01 -0400 2009: > I did some thinking about a name for our version of the GAR build > system and ended up with "GARISOL". This is an anagram of girasol, > which is italian for sunflower showing the affinity both to GAR > and Solaris without being an actual word - this makes searching for > it and reserving names easier. I like it! -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Wed Oct 7 15:26:35 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 7 Oct 2009 14:26:35 +0100 Subject: [csw-maintainers] Proposal for name of our GAR version In-Reply-To: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> References: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> Message-ID: On Wed, Oct 7, 2009 at 1:36 PM, Dagobert Michelsen wrote: > Hi, > > I did some thinking about a name for our version of the GAR build > system and ended up with "GARISOL". This is an anagram of girasol, > which is italian for sunflower showing the affinity both to GAR > and Solaris without being an actual word - this makes searching for > it and reserving names easier. How about shortening it to "garis"? It's nicer to pronounce. It also makes me thing of tardis. http://en.wikipedia.org/wiki/TARDIS We could also have "gardis". (The time machine! Bigger inside than outside!) Maciej From bwalton at opencsw.org Wed Oct 7 15:28:56 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 07 Oct 2009 09:28:56 -0400 Subject: [csw-maintainers] passwd -N In-Reply-To: <47474866-5DFA-48C5-8DA4-4D0CEFB5F373@opencsw.org> References: <1254848861-sup-1353@ntdws12.chass.utoronto.ca> <47474866-5DFA-48C5-8DA4-4D0CEFB5F373@opencsw.org> Message-ID: <1254922080-sup-8462@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Oct 07 08:41:31 -0400 2009: > Yes. It may be a little clean with awk: > awk -F: 'BEGIN { OFS=":" } $1 == "dam" { $2 = "NP" } { print }' < / > etc/shadow Thanks Dago. I said 'sed' but meant 'some manual tool.' Manual it is. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Wed Oct 7 15:34:21 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 07 Oct 2009 09:34:21 -0400 Subject: [csw-maintainers] Proposal for name of our GAR version In-Reply-To: References: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> Message-ID: <1254922433-sup-411@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Wed Oct 07 09:26:35 -0400 2009: > How about shortening it to "garis"? It's nicer to pronounce. It also > makes me thing of tardis. I still prefer GARISOL, but great reference! :) -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Wed Oct 7 16:07:17 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 7 Oct 2009 16:07:17 +0200 Subject: [csw-maintainers] GAR Platform builds now open for testing In-Reply-To: References: <0F1DEF08-4D55-4224-ADFC-DE1DD712E9A7@opencsw.org> <05F1A42C-9047-4EBF-A531-3A2212A8DC19@opencsw.org> Message-ID: <32788F30-9EF8-4D54-8640-911A74FD7FA3@opencsw.org> Hi Maciej, Am 07.10.2009 um 14:50 schrieb Maciej (Matchek) Blizinski: > I've got a problem with building cups: > > $ ENABLE_CHECK=0 gmake platforms > (...) > mkp: exec( gzip -9 -f > /tmp/cupsd-1.4.0,REV=2009.10.07.14.32-SunOS5.8-i386-CSW.pkg ) > mkp: exec( mv /tmp/cupsd-1.4.0,REV=2009.10.07.14.32-SunOS5.8-i386- > CSW.pkg.gz > /home/maciej/staging/build-2009-10-07 ) > mkp: exec( rm -rf /home/maciej/spool.5.8-i386/CSWcupsd ) > ==> Checking compliance: CSWcupsd > ERROR: /home/maciej/staging/build-2009-10-07/ > cupsd-1.4.0,REV=2009.10.07.14.33-SunOS5.8-i386-CSW.pkg.gz > does not exist The problem is that you use high resolution timestamps which have changed during build: mkp: exec( mv /tmp/ cupsd-1.4.0,REV=2009.10.07.14.32-SunOS5.8-i386-CSW.pkg.gz ERROR: /home/maciej/staging/build-2009-10-07/ cupsd-1.4.0,REV=2009.10.07.14.33-SunOS5.8-i386-CSW.pkg.gz I have solved this with SETONCE magic, using recursively expanded variable as if they were simply expanded: SETONCE = $(eval $(1) ?= $(2)) $(call SETONCE,myvar,myvalue) Because it is only set once the value can not change during make, and if it is not used it is never expanded making its use also fast :-) > gmake: *** [pkgcheck-CSWcupsd] Error 2 > gmake: Leaving directory `/home/maciej/src/opencsw/pkg/cups/branches/ > cups-1.4' > Connection to build8x closed. > gmake: *** [platforms] Error 2 > > Looks like it's the usual checkpkg problem, this only this time > ENABLE_CHECK=0 doesn't work around the issue. Any ideas? > > It's the cups-1.4 branch. The following error persists: > Doing late evaluations of package library dependencies. > ERROR: Couldn't find a package providing libcupscgi.so.1 > gmake: *** [pkgcheck-CSWcupsd] Error 2 This however seems to be a bug in the file-distribution in PKGFILES as the library is generally there: > build8s% find . -name libcupscgi.so.1 > ./work/solaris8-sparc/pkgroot/opt/csw/lib/libcupscgi.so.1 > ./work/solaris8-sparc/build-isa-sparcv8/cups-1.4.0/cgi-bin/ > libcupscgi.so.1 > ./work/solaris8-sparc/install-isa-sparcv8/opt/csw/lib/libcupscgi.so.1 > build8s% grep libcupscgi.so.1 work/solaris8-sparc/build-global/ > *.prototype Best regards -- Dago From mwatters at opencsw.org Wed Oct 7 16:41:02 2009 From: mwatters at opencsw.org (Mike Watters) Date: Wed, 07 Oct 2009 09:41:02 -0500 Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <20091007055448.GA13472@vm-1.bch.net> References: <4ACB995D.90707@opencsw.org> <20091007055448.GA13472@vm-1.bch.net> Message-ID: <4ACCA87E.6080903@opencsw.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Hill wrote: > Hi Mike, > > I assume that this should work with existing CSWberkeleydb > package until you rebuild it with the new berk db package name. > > Am I missing something? > > ... > Updated description file > INTERNAL ERROR: cannot get remote version for CSWbdb > Perhaps your catalog is out of date > Error: dependancies for sendmail not up to date. > You may call pkg-get again with '-v -u sendmail' to see which ones > Or, call pkg-get with 'upgrade' to bring all installed pkgs up to date > > Brian > ====================================================================== > On Tue, Oct 06, 2009 at 02:24:13PM -0500, Mike Watters wrote: > once Dago is done with berkeley DB it will be recompiled based on the "new" > package names for bdb. > > please test and provide feedback. > > That error usually means it can't find the version in the "testing catalog" do a pkg-get -U -u bdb from the "current" catalog and you should get the right version. _______________________________________________ users mailing list users at lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/users - -- ~Mike "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." --> Albert Einstein 1879 - 1955 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrMqH0ACgkQLrhmsXMSLxfjCwCfdVKhX1OUccluozOex5FUOOy/ t4sAn1sBZdHcVgcICob08dKLD2ndcTHV =y8+r -----END PGP SIGNATURE----- From bchill at opencsw.org Wed Oct 7 17:33:25 2009 From: bchill at opencsw.org (Brian Hill) Date: Wed, 7 Oct 2009 15:33:25 +0000 Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <4ACCA87E.6080903@opencsw.org> References: <4ACB995D.90707@opencsw.org> <20091007055448.GA13472@vm-1.bch.net> <4ACCA87E.6080903@opencsw.org> Message-ID: <20091007153325.GA23587@vm-1.bch.net> On Wed, Oct 07, 2009 at 09:41:02AM -0500, Mike Watters wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Brian Hill wrote: > > Hi Mike, > > > > I assume that this should work with existing CSWberkeleydb > > package until you rebuild it with the new berk db package name. > > > > Am I missing something? > > > > ... > > Updated description file > > INTERNAL ERROR: cannot get remote version for CSWbdb > > Perhaps your catalog is out of date > > Error: dependancies for sendmail not up to date. > > You may call pkg-get again with '-v -u sendmail' to see which ones > > Or, call pkg-get with 'upgrade' to bring all installed pkgs up to date > > > > Brian > > ====================================================================== > > On Tue, Oct 06, 2009 at 02:24:13PM -0500, Mike Watters wrote: > > once Dago is done with berkeley DB it will be recompiled based on the "new" > > package names for bdb. > > > > please test and provide feedback. > > > > > > That error usually means it can't find the version in the "testing catalog" > do a pkg-get -U -u bdb from the "current" catalog and you should get the right > version. Hi Mike, That didn't help: # pkg-get -U -u bdb Getting catalog... --2009-10-07 15:31:57-- http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/catalog Resolving ibiblio.org... 152.46.7.80 Connecting to ibiblio.org|152.46.7.80|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 407617 (398K) [text/plain] Saving to: `catalog' 100%[================================================================>] 407,617 125K/s in 3.2s 2009-10-07 15:32:01 (125 KB/s) - `catalog' saved [407617/407617] Stripping off catalog signature without verifying Updating catalog file /var/pkg-get/catalog-ibiblio.org updated --2009-10-07 15:32:01-- http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/descriptions Resolving ibiblio.org... 152.46.7.80 Connecting to ibiblio.org|152.46.7.80|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 112691 (110K) [text/plain] Saving to: `descriptions' 100%[================================================================>] 112,691 215K/s in 0.5s 2009-10-07 15:32:02 (215 KB/s) - `descriptions' saved [112691/112691] Updated description file ERROR: bdb unrecognized Perhaps you need to run pkg-get -U From dam at opencsw.org Wed Oct 7 17:44:03 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 7 Oct 2009 17:44:03 +0200 Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <20091007153325.GA23587@vm-1.bch.net> References: <4ACB995D.90707@opencsw.org> <20091007055448.GA13472@vm-1.bch.net> <4ACCA87E.6080903@opencsw.org> <20091007153325.GA23587@vm-1.bch.net> Message-ID: <1E7DFDC6-AAAA-46F0-9C47-DECC534F88D6@opencsw.org> Hi Brian, Am 07.10.2009 um 17:33 schrieb Brian Hill: > On Wed, Oct 07, 2009 at 09:41:02AM -0500, Mike Watters wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Brian Hill wrote: >>> Hi Mike, >>> >>> I assume that this should work with existing CSWberkeleydb >>> package until you rebuild it with the new berk db package name. >>> >>> Am I missing something? >>> >>> ... >>> Updated description file >>> INTERNAL ERROR: cannot get remote version for CSWbdb >>> Perhaps your catalog is out of date >>> Error: dependancies for sendmail not up to date. >>> You may call pkg-get again with '-v -u sendmail' to see which ones >>> Or, call pkg-get with 'upgrade' to bring all installed pkgs up to >>> date >>> >>> Brian >>> = >>> = >>> ==================================================================== >>> On Tue, Oct 06, 2009 at 02:24:13PM -0500, Mike Watters wrote: >>> once Dago is done with berkeley DB it will be recompiled based on >>> the "new" >>> package names for bdb. >>> >>> please test and provide feedback. >>> >>> >> >> That error usually means it can't find the version in the "testing >> catalog" >> do a pkg-get -U -u bdb from the "current" catalog and you should >> get the right >> version. > > Hi Mike, > > That didn't help: > > # pkg-get -U -u bdb > Getting catalog... > --2009-10-07 15:31:57-- http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/catalog > Resolving ibiblio.org... 152.46.7.80 > Connecting to ibiblio.org|152.46.7.80|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 407617 (398K) [text/plain] > Saving to: `catalog' > > 100% > [================================================================>] > 407,617 125K/s in 3.2s > > 2009-10-07 15:32:01 (125 KB/s) - `catalog' saved [407617/407617] > > Stripping off catalog signature without verifying > Updating catalog file > /var/pkg-get/catalog-ibiblio.org updated > > --2009-10-07 15:32:01-- http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/descriptions > Resolving ibiblio.org... 152.46.7.80 > Connecting to ibiblio.org|152.46.7.80|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 112691 (110K) [text/plain] > Saving to: `descriptions' > > 100% > [================================================================>] > 112,691 215K/s in 0.5s > > 2009-10-07 15:32:02 (215 KB/s) - `descriptions' saved [112691/112691] > > Updated description file > ERROR: bdb unrecognized Sure :) Because the catalogname is berkeleydb and the package name is CSWbdb: berkeleydb 4.7.25,REV=2009.07.01 CSWbdb berkeleydb-4.7.25,REV=2009.07.01-SunOS5.8-sparc-CSW.pkg.gz dc8ecc49f6b324c54f6042a2cac60109 6138945 CSWcommon none So either update berkeleydb or CSWbdb. Best regards -- Dago From bchill at opencsw.org Wed Oct 7 17:52:11 2009 From: bchill at opencsw.org (Brian Hill) Date: Wed, 7 Oct 2009 15:52:11 +0000 Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <1E7DFDC6-AAAA-46F0-9C47-DECC534F88D6@opencsw.org> References: <4ACB995D.90707@opencsw.org> <20091007055448.GA13472@vm-1.bch.net> <4ACCA87E.6080903@opencsw.org> <20091007153325.GA23587@vm-1.bch.net> <1E7DFDC6-AAAA-46F0-9C47-DECC534F88D6@opencsw.org> Message-ID: <20091007155211.GA24940@vm-1.bch.net> On Wed, Oct 07, 2009 at 05:44:03PM +0200, Dagobert Michelsen wrote: > Hi Brian, > > > Hi Mike, > > > > That didn't help: > > > ># pkg-get -U -u bdb > >Getting catalog... > >--2009-10-07 15:31:57-- > >http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/catalog > >Resolving ibiblio.org... 152.46.7.80 > >Connecting to ibiblio.org|152.46.7.80|:80... connected. > >HTTP request sent, awaiting response... 200 OK > >Length: 407617 (398K) [text/plain] > >Saving to: `catalog' > > > >100% > >[================================================================>] > >407,617 125K/s in 3.2s > > > >2009-10-07 15:32:01 (125 KB/s) - `catalog' saved [407617/407617] > > > >Stripping off catalog signature without verifying > >Updating catalog file > >/var/pkg-get/catalog-ibiblio.org updated > > > >--2009-10-07 15:32:01-- > >http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/descriptions > >Resolving ibiblio.org... 152.46.7.80 > >Connecting to ibiblio.org|152.46.7.80|:80... connected. > >HTTP request sent, awaiting response... 200 OK > >Length: 112691 (110K) [text/plain] > >Saving to: `descriptions' > > > >100% > >[================================================================>] > >112,691 215K/s in 0.5s > > > >2009-10-07 15:32:02 (215 KB/s) - `descriptions' saved [112691/112691] > > > >Updated description file > >ERROR: bdb unrecognized > > Sure :) Because the catalogname is berkeleydb and the package name is > CSWbdb: > > berkeleydb 4.7.25,REV=2009.07.01 CSWbdb > berkeleydb-4.7.25,REV=2009.07.01-SunOS5.8-sparc-CSW.pkg.gz > dc8ecc49f6b324c54f6042a2cac60109 6138945 CSWcommon none > > So either update berkeleydb or CSWbdb. > > > Best regards > > -- Dago Still, no luck: # pkg-get -U -u CSWbdb Getting catalog... --2009-10-07 15:49:11-- http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/catalog Resolving ibiblio.org... 152.46.7.80 Connecting to ibiblio.org|152.46.7.80|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 407617 (398K) [text/plain] Saving to: `catalog' 100%[================================================================>] 407,617 336K/s in 1.2s 2009-10-07 15:49:13 (336 KB/s) - `catalog' saved [407617/407617] Stripping off catalog signature without verifying Updating catalog file /var/pkg-get/catalog-ibiblio.org updated --2009-10-07 15:49:13-- http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/descriptions Resolving ibiblio.org... 152.46.7.80 Connecting to ibiblio.org|152.46.7.80|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 112691 (110K) [text/plain] Saving to: `descriptions' 100%[================================================================>] 112,691 214K/s in 0.5s 2009-10-07 15:49:13 (214 KB/s) - `descriptions' saved [112691/112691] Updated description file No worries... you already have version 4.7.25,REV=2009.07.01 of berkeleydb If you doubt this message, run 'pkg-get -U', then run 'pkg-get upgrade berkeleydb' # pkg-get -s http://mirror.opencsw.org/opencsw/testing -v -U upgrade sendmail DEBUG-ONLY/VERBOSE MODE: level=1 Getting catalog... --2009-10-07 15:49:33-- http://mirror.opencsw.org/opencsw/testing/sparc/5.8/catalog Resolving mirror.opencsw.org... 213.178.77.176 Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 37272 (36K) [text/plain] Saving to: `catalog' 100%[================================================================>] 37,272 49.7K/s in 0.7s 2009-10-07 15:49:34 (49.7 KB/s) - `catalog' saved [37272/37272] Updating catalog file /var/pkg-get/catalog-mirror.opencsw.org updated --2009-10-07 15:49:34-- http://mirror.opencsw.org/opencsw/testing/sparc/5.8/descriptions Resolving mirror.opencsw.org... 213.178.77.176 Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 9040 (8.8K) [text/plain] Saving to: `descriptions' 100%[================================================================>] 9,040 29.8K/s in 0.3s 2009-10-07 15:49:35 (29.8 KB/s) - `descriptions' saved [9040/9040] Updated description file INTERNAL ERROR: cannot get remote version for CSWbdb Perhaps your catalog is out of date Error: dependancies for sendmail not up to date. Relevant packages needing download: INTERNAL ERROR: cannot get remote version for CSWbdb Perhaps your catalog is out of date CSWoldaprt openldap_rt 643862 bytes INTERNAL ERROR: cannot get remote version for CSWosslrt Perhaps your catalog is out of date INTERNAL ERROR: cannot get remote version for CSWsasl Perhaps your catalog is out of date INTERNAL ERROR: cannot get remote version for CSWcswclassutils Perhaps your catalog is out of date INTERNAL ERROR: cannot get remote version for CSWcommon Perhaps your catalog is out of date INTERNAL ERROR: cannot get remote version for CSWisaexec Perhaps your catalog is out of date INTERNAL ERROR: cannot get remote version for CSWlibnet Perhaps your catalog is out of date INTERNAL ERROR: cannot get remote version for CSWkrb5lib Perhaps your catalog is out of date CSWsendmail sendmail 2796157 bytes Brian From dam at opencsw.org Wed Oct 7 17:57:11 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 7 Oct 2009 17:57:11 +0200 Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <20091007155211.GA24940@vm-1.bch.net> References: <4ACB995D.90707@opencsw.org> <20091007055448.GA13472@vm-1.bch.net> <4ACCA87E.6080903@opencsw.org> <20091007153325.GA23587@vm-1.bch.net> <1E7DFDC6-AAAA-46F0-9C47-DECC534F88D6@opencsw.org> <20091007155211.GA24940@vm-1.bch.net> Message-ID: <9A4426DC-8953-4C7A-B367-F477FCF2246C@opencsw.org> Hi Brian, Am 07.10.2009 um 17:52 schrieb Brian Hill: > Still, no luck: > > # pkg-get -U -u CSWbdb > Getting catalog... > --2009-10-07 15:49:11-- http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/catalog > Resolving ibiblio.org... 152.46.7.80 > Connecting to ibiblio.org|152.46.7.80|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 407617 (398K) [text/plain] > Saving to: `catalog' > > 100% > [================================================================>] > 407,617 336K/s in 1.2s > > 2009-10-07 15:49:13 (336 KB/s) - `catalog' saved [407617/407617] > > Stripping off catalog signature without verifying > Updating catalog file > /var/pkg-get/catalog-ibiblio.org updated > > --2009-10-07 15:49:13-- http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/descriptions > Resolving ibiblio.org... 152.46.7.80 > Connecting to ibiblio.org|152.46.7.80|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 112691 (110K) [text/plain] > Saving to: `descriptions' > > 100% > [================================================================>] > 112,691 214K/s in 0.5s > > 2009-10-07 15:49:13 (214 KB/s) - `descriptions' saved [112691/112691] > > Updated description file > No worries... you already have version 4.7.25,REV=2009.07.01 of > berkeleydb > If you doubt this message, run 'pkg-get -U', then run > 'pkg-get upgrade berkeleydb' This is good. > # pkg-get -s http://mirror.opencsw.org/opencsw/testing -v -U upgrade > sendmail > DEBUG-ONLY/VERBOSE MODE: level=1 > Getting catalog... > --2009-10-07 15:49:33-- http://mirror.opencsw.org/opencsw/testing/sparc/5.8/catalog > Resolving mirror.opencsw.org... 213.178.77.176 > Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 37272 (36K) [text/plain] > Saving to: `catalog' > > 100% > [================================================================>] > 37,272 49.7K/s in 0.7s > > 2009-10-07 15:49:34 (49.7 KB/s) - `catalog' saved [37272/37272] > > Updating catalog file > /var/pkg-get/catalog-mirror.opencsw.org updated > > --2009-10-07 15:49:34-- http://mirror.opencsw.org/opencsw/testing/sparc/5.8/descriptions > Resolving mirror.opencsw.org... 213.178.77.176 > Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 9040 (8.8K) [text/plain] > Saving to: `descriptions' > > 100% > [================================================================>] > 9,040 29.8K/s in 0.3s > > 2009-10-07 15:49:35 (29.8 KB/s) - `descriptions' saved [9040/9040] > > Updated description file > INTERNAL ERROR: cannot get remote version for CSWbdb > Perhaps your catalog is out of date > Error: dependancies for sendmail not up to date. > Relevant packages needing download: > INTERNAL ERROR: cannot get remote version for CSWbdb > Perhaps your catalog is out of date > CSWoldaprt openldap_rt 643862 bytes > INTERNAL ERROR: cannot get remote version for CSWosslrt > Perhaps your catalog is out of date > INTERNAL ERROR: cannot get remote version for CSWsasl > Perhaps your catalog is out of date > INTERNAL ERROR: cannot get remote version for CSWcswclassutils > Perhaps your catalog is out of date > INTERNAL ERROR: cannot get remote version for CSWcommon > Perhaps your catalog is out of date > INTERNAL ERROR: cannot get remote version for CSWisaexec > Perhaps your catalog is out of date > INTERNAL ERROR: cannot get remote version for CSWlibnet > Perhaps your catalog is out of date > INTERNAL ERROR: cannot get remote version for CSWkrb5lib > Perhaps your catalog is out of date > CSWsendmail sendmail 2796157 bytes This is bad. It looks like a bug in pkg-get when dependencies are already installed on the local system but not in the catalog (which should be ok). Phil, how is this handled in pkg-get? Best regards -- Dago From mwatters at opencsw.org Wed Oct 7 18:04:34 2009 From: mwatters at opencsw.org (Mike Watters) Date: Wed, 07 Oct 2009 11:04:34 -0500 Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <9A4426DC-8953-4C7A-B367-F477FCF2246C@opencsw.org> References: <4ACB995D.90707@opencsw.org> <20091007055448.GA13472@vm-1.bch.net> <4ACCA87E.6080903@opencsw.org> <20091007153325.GA23587@vm-1.bch.net> <1E7DFDC6-AAAA-46F0-9C47-DECC534F88D6@opencsw.org> <20091007155211.GA24940@vm-1.bch.net> <9A4426DC-8953-4C7A-B367-F477FCF2246C@opencsw.org> Message-ID: <4ACCBC12.6040505@opencsw.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dagobert Michelsen wrote: > Hi Brian, > > Am 07.10.2009 um 17:52 schrieb Brian Hill: >> Still, no luck: >> >> # pkg-get -U -u CSWbdb >> Getting catalog... >> --2009-10-07 15:49:11-- >> http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/catalog >> Resolving ibiblio.org... 152.46.7.80 >> Connecting to ibiblio.org|152.46.7.80|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 407617 (398K) [text/plain] >> Saving to: `catalog' >> >> 100%[================================================================>] >> 407,617 336K/s in 1.2s >> >> 2009-10-07 15:49:13 (336 KB/s) - `catalog' saved [407617/407617] >> >> Stripping off catalog signature without verifying >> Updating catalog file >> /var/pkg-get/catalog-ibiblio.org updated >> >> --2009-10-07 15:49:13-- >> http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/descriptions >> >> Resolving ibiblio.org... 152.46.7.80 >> Connecting to ibiblio.org|152.46.7.80|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 112691 (110K) [text/plain] >> Saving to: `descriptions' >> >> 100%[================================================================>] >> 112,691 214K/s in 0.5s >> >> 2009-10-07 15:49:13 (214 KB/s) - `descriptions' saved [112691/112691] >> >> Updated description file >> No worries... you already have version 4.7.25,REV=2009.07.01 of >> berkeleydb >> If you doubt this message, run 'pkg-get -U', then run >> 'pkg-get upgrade berkeleydb' > > This is good. > >> # pkg-get -s http://mirror.opencsw.org/opencsw/testing -v -U upgrade >> sendmail >> DEBUG-ONLY/VERBOSE MODE: level=1 >> Getting catalog... >> --2009-10-07 15:49:33-- >> http://mirror.opencsw.org/opencsw/testing/sparc/5.8/catalog >> Resolving mirror.opencsw.org... 213.178.77.176 >> Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 37272 (36K) [text/plain] >> Saving to: `catalog' >> >> 100%[================================================================>] >> 37,272 49.7K/s in 0.7s >> >> 2009-10-07 15:49:34 (49.7 KB/s) - `catalog' saved [37272/37272] >> >> Updating catalog file >> /var/pkg-get/catalog-mirror.opencsw.org updated >> >> --2009-10-07 15:49:34-- >> http://mirror.opencsw.org/opencsw/testing/sparc/5.8/descriptions >> Resolving mirror.opencsw.org... 213.178.77.176 >> Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 9040 (8.8K) [text/plain] >> Saving to: `descriptions' >> >> 100%[================================================================>] >> 9,040 29.8K/s in 0.3s >> >> 2009-10-07 15:49:35 (29.8 KB/s) - `descriptions' saved [9040/9040] >> >> Updated description file >> INTERNAL ERROR: cannot get remote version for CSWbdb >> Perhaps your catalog is out of date >> Error: dependancies for sendmail not up to date. >> Relevant packages needing download: >> INTERNAL ERROR: cannot get remote version for CSWbdb >> Perhaps your catalog is out of date >> CSWoldaprt openldap_rt 643862 bytes >> INTERNAL ERROR: cannot get remote version for CSWosslrt >> Perhaps your catalog is out of date >> INTERNAL ERROR: cannot get remote version for CSWsasl >> Perhaps your catalog is out of date >> INTERNAL ERROR: cannot get remote version for CSWcswclassutils >> Perhaps your catalog is out of date >> INTERNAL ERROR: cannot get remote version for CSWcommon >> Perhaps your catalog is out of date >> INTERNAL ERROR: cannot get remote version for CSWisaexec >> Perhaps your catalog is out of date >> INTERNAL ERROR: cannot get remote version for CSWlibnet >> Perhaps your catalog is out of date >> INTERNAL ERROR: cannot get remote version for CSWkrb5lib >> Perhaps your catalog is out of date >> CSWsendmail sendmail 2796157 bytes > > This is bad. It looks like a bug in pkg-get when dependencies are > already installed on the local system but not in the catalog (which > should be ok). Phil, how is this handled in pkg-get? > > > Best regards > > -- Dago > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers I think you need to update your version of openldap_rt - -- ~Mike "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." --> Albert Einstein 1879 - 1955 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrMvBEACgkQLrhmsXMSLxe8uACfbEYWDBJXRfhZMbRVBbPQ3yDg wYcAnA3YtXgS42/4XgxEI4ZGEF0uzAGl =W/g6 -----END PGP SIGNATURE----- From bwalton at opencsw.org Wed Oct 7 18:08:25 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 07 Oct 2009 12:08:25 -0400 Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <4ACCBC12.6040505@opencsw.org> References: <4ACB995D.90707@opencsw.org> <20091007055448.GA13472@vm-1.bch.net> <4ACCA87E.6080903@opencsw.org> <20091007153325.GA23587@vm-1.bch.net> <1E7DFDC6-AAAA-46F0-9C47-DECC534F88D6@opencsw.org> <20091007155211.GA24940@vm-1.bch.net> <9A4426DC-8953-4C7A-B367-F477FCF2246C@opencsw.org> <4ACCBC12.6040505@opencsw.org> Message-ID: <1254931603-sup-107@ntdws12.chass.utoronto.ca> Excerpts from Mike Watters's message of Wed Oct 07 12:04:34 -0400 2009: > I think you need to update your version of openldap_rt The openldap_rt package in testing only has 2.4 libs. Things linked to 2.3 will break. I'd recommend not updating to that package from testing at this point in time. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Oct 7 18:12:16 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 7 Oct 2009 18:12:16 +0200 (CEST) Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <4ACCBC12.6040505@opencsw.org> References: <4ACB995D.90707@opencsw.org> <20091007055448.GA13472@vm-1.bch.net> <4ACCA87E.6080903@opencsw.org> <20091007153325.GA23587@vm-1.bch.net> <1E7DFDC6-AAAA-46F0-9C47-DECC534F88D6@opencsw.org> <20091007155211.GA24940@vm-1.bch.net> <9A4426DC-8953-4C7A-B367-F477FCF2246C@opencsw.org> <4ACCBC12.6040505@opencsw.org> Message-ID: <58883.194.246.122.22.1254931936.squirrel@ssl.skayser.de> Mike Watters wrote: > Dagobert Michelsen wrote: >> Am 07.10.2009 um 17:52 schrieb Brian Hill: >>> # pkg-get -s http://mirror.opencsw.org/opencsw/testing -v -U upgrade >>> sendmail >>> DEBUG-ONLY/VERBOSE MODE: level=1 >>> Getting catalog... >>> --2009-10-07 15:49:33-- >>> http://mirror.opencsw.org/opencsw/testing/sparc/5.8/catalog >>> Resolving mirror.opencsw.org... 213.178.77.176 >>> Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. >>> HTTP request sent, awaiting response... 200 OK >>> Length: 37272 (36K) [text/plain] >>> Saving to: `catalog' >>> >>> 100%[================================================================>] >>> 37,272 49.7K/s in 0.7s >>> >>> 2009-10-07 15:49:34 (49.7 KB/s) - `catalog' saved [37272/37272] >>> >>> Updating catalog file >>> /var/pkg-get/catalog-mirror.opencsw.org updated >>> >>> --2009-10-07 15:49:34-- >>> http://mirror.opencsw.org/opencsw/testing/sparc/5.8/descriptions >>> Resolving mirror.opencsw.org... 213.178.77.176 >>> Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. >>> HTTP request sent, awaiting response... 200 OK >>> Length: 9040 (8.8K) [text/plain] >>> Saving to: `descriptions' >>> >>> 100%[================================================================>] >>> 9,040 29.8K/s in 0.3s >>> >>> 2009-10-07 15:49:35 (29.8 KB/s) - `descriptions' saved [9040/9040] >>> >>> Updated description file >>> INTERNAL ERROR: cannot get remote version for CSWbdb >>> Perhaps your catalog is out of date >>> Error: dependancies for sendmail not up to date. >>> Relevant packages needing download: >>> INTERNAL ERROR: cannot get remote version for CSWbdb >>> Perhaps your catalog is out of date >>> CSWoldaprt openldap_rt 643862 bytes >>> INTERNAL ERROR: cannot get remote version for CSWosslrt >>> Perhaps your catalog is out of date >>> INTERNAL ERROR: cannot get remote version for CSWsasl >>> Perhaps your catalog is out of date >>> INTERNAL ERROR: cannot get remote version for CSWcswclassutils >>> Perhaps your catalog is out of date >>> INTERNAL ERROR: cannot get remote version for CSWcommon >>> Perhaps your catalog is out of date >>> INTERNAL ERROR: cannot get remote version for CSWisaexec >>> Perhaps your catalog is out of date >>> INTERNAL ERROR: cannot get remote version for CSWlibnet >>> Perhaps your catalog is out of date >>> INTERNAL ERROR: cannot get remote version for CSWkrb5lib >>> Perhaps your catalog is out of date >>> CSWsendmail sendmail 2796157 bytes >> >> This is bad. It looks like a bug in pkg-get when dependencies are >> already installed on the local system but not in the catalog (which >> should be ok). Phil, how is this handled in pkg-get? > > I think you need to update your version of openldap_rt Thanks for testing, Brian. I second Dago's impression, we have had pkg-get cope badly with testing (or any partial catalog) several times in the past. Did you try pkgutil? pkgutil -t http://mirror.opencsw.org/opencsw/testing -u sendmail When using -t, pkgutil automatically creates an internal overlay to the catalog configured via pkgutil.conf and thus can resolve dependencies which are not covered by testing alone. pkg-get doesn't do so IIRC. Could we point that out on the testing page? Sebastian From phil at bolthole.com Wed Oct 7 18:14:47 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 7 Oct 2009 09:14:47 -0700 Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <9A4426DC-8953-4C7A-B367-F477FCF2246C@opencsw.org> References: <4ACB995D.90707@opencsw.org> <20091007055448.GA13472@vm-1.bch.net> <4ACCA87E.6080903@opencsw.org> <20091007153325.GA23587@vm-1.bch.net> <1E7DFDC6-AAAA-46F0-9C47-DECC534F88D6@opencsw.org> <20091007155211.GA24940@vm-1.bch.net> <9A4426DC-8953-4C7A-B367-F477FCF2246C@opencsw.org> Message-ID: On Wed, Oct 7, 2009 at 8:57 AM, Dagobert Michelsen wrote: > >> # pkg-get -U -u CSWbdb >... >> ?http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/catalog > >> No worries... you already have version 4.7.25,REV=2009.07.01 of berkeleydb >> If you doubt this message, run 'pkg-get -U', then run >> 'pkg-get upgrade berkeleydb' > > This is good. > >> # pkg-get -s [testing] -v -U upgrade sendmail >> >> INTERNAL ERROR: cannot get remote version for CSWbdb >> Perhaps your catalog is out of date > > This is bad. It looks like a bug in pkg-get when dependencies are > already installed on the local system but not in the catalog (which > should be ok). Well, I dunno about that being "should be ok" :-} that might be a "feature" ;-) [to guard against broken catalogs/packages] That being said, I already have longer term plans to implement better handling of this sort of thing, by directly supporting dual-site in pkg-get. Unfortunately that is MAJOR work for pkg-get, and I did not have time during my updates last weekend. it will have to wait until I have another free weekend, to implement it. (odd though.. i thought pkg-get used to be a bit more forgiving about this sort of thing from testing) From skayser at opencsw.org Wed Oct 7 18:21:04 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 7 Oct 2009 18:21:04 +0200 (CEST) Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <1254931603-sup-107@ntdws12.chass.utoronto.ca> References: <4ACB995D.90707@opencsw.org> <20091007055448.GA13472@vm-1.bch.net> <4ACCA87E.6080903@opencsw.org> <20091007153325.GA23587@vm-1.bch.net> <1E7DFDC6-AAAA-46F0-9C47-DECC534F88D6@opencsw.org> <20091007155211.GA24940@vm-1.bch.net> <9A4426DC-8953-4C7A-B367-F477FCF2246C@opencsw.org> <4ACCBC12.6040505@opencsw.org> <1254931603-sup-107@ntdws12.chass.utoronto.ca> Message-ID: <53910.194.246.122.22.1254932464.squirrel@ssl.skayser.de> Ben Walton wrote: > Excerpts from Mike Watters's message of Wed Oct 07 12:04:34 -0400 2009: > >> I think you need to update your version of openldap_rt > > The openldap_rt package in testing only has 2.4 libs. Things linked > to 2.3 will break. I'd recommend not updating to that package from > testing at this point in time. True, testing needs to be handled with care (time to get the in-development-stuff out of testing, glad that Dago is working towards it). To only update the sendmail package you could do pkgutil -t http://mirror.opencsw.org/opencsw/testing -Nu sendmail Requires pkgutil version 1.7. Sebastian From phil at bolthole.com Wed Oct 7 18:23:50 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 7 Oct 2009 09:23:50 -0700 Subject: [csw-maintainers] questions about GAR, history, and naming In-Reply-To: <493A50BB-64A2-457D-A307-185096960F35@opencsw.org> References: <20091004195314.GA33599@bolthole.com> <9046596F-57B6-4AA0-9B36-60C9F1497A56@opencsw.org> <0315E28D-99D7-42DB-A144-8A6B4E85A771@opencsw.org> <32973644-DFF4-4BD1-A760-90422E02A60A@opencsw.org> <493A50BB-64A2-457D-A307-185096960F35@opencsw.org> Message-ID: On Wed, Oct 7, 2009 at 4:39 AM, Dagobert Michelsen wrote: > . I may have put more energy to source packages if you would > show real interest in GAR by using it for your packages or at > least to a level where you can reproduce a build without the > demand that "someone writes up an interface for me that I can > do 'gartool compile '". Well, then, we have a "catch 22". You dont wish to work on GAR in that direction until I use it, and I dont want to use it until GAR is more complete in that area :-} For the record though, I have not insisted that there actually be an INTERFACE WRITTEN to do all that, before I use it. What I have been more pushy about, is for our [gar-related source repository] to be completely flattened, so that it is then POSSIBLE for "someone" to write a simple interface to support "[cswtool compile pkg]", for any arbitrary package in our svn repository. *I* would even be willing to write that tool! But right now, there is no proper standardized namespace in our svn to support that cleanly. Also for the record, we have discussed on the mailing list that things could potentially be added into the repository that build without using gar. Which is why I specified above, [cswtool], rather than [gartool]. Such a tool, (which, again, I myself would be willing to write), would support building via gar, or other standard-compliant subtrees in our source tree. From william at wbonnet.net Wed Oct 7 20:59:25 2009 From: william at wbonnet.net (William Bonnet) Date: Wed, 07 Oct 2009 20:59:25 +0200 Subject: [csw-maintainers] Proposal for name of our GAR version In-Reply-To: <1254921389-sup-6432@ntdws12.chass.utoronto.ca> References: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> <1254921389-sup-6432@ntdws12.chass.utoronto.ca> Message-ID: <4ACCE50D.40801@wbonnet.net> Hi A few puns are coming to my mind like Gar-Age or Gar-Land :) Garrigue is cool also ... or Garvey ? 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 Wed Oct 7 22:26:15 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 7 Oct 2009 22:26:15 +0200 Subject: [csw-maintainers] Updating farm now Message-ID: Hi, I am updating the farm now with XML stuff and everything else. Sorry for the inconvenience -- Dago From ihsan at opencsw.org Wed Oct 7 22:33:04 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 07 Oct 2009 22:33:04 +0200 Subject: [csw-maintainers] BerkeleyDB final call In-Reply-To: <52119.194.246.122.22.1254859774.squirrel@ssl.skayser.de> References: <52119.194.246.122.22.1254859774.squirrel@ssl.skayser.de> Message-ID: <4ACCFB00.1020008@opencsw.org> Am 6.10.2009 22:09 Uhr, Sebastian Kayser schrieb: > Thanks Dago for working towards the old status quo. Attached is a list of > packages directly depending on CSWbdb* packages. If someone spots a > package he is using regularly (best in a scenario with bdb involved), > please help testing by updating your BDB packages. > > CSWap2prefork > CSWap2worker > CSWapache > CSWapache2c > CSWapache2rt > CSWpmberkeleydb These are my packages and I'm already working on a update, especially for Apache. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From skayser at opencsw.org Wed Oct 7 22:51:34 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 07 Oct 2009 22:51:34 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <20091006.14033000.2372649415@gyor.oxdrove.co.uk> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> <20091006.14033000.2372649415@gyor.oxdrove.co.uk> Message-ID: <4ACCFF56.3010901@opencsw.org> James Lee wrote on 06.10.2009 16:03: > Reasons not to split: > > + Many more packages to manage > > + No space saving when only runtimes used, which is in most cases. > > + It's a pain for the developer to know to install the -dev packages. > Not all packages naturally have dev parts and it's not possible to > tell if it's missing or never exists (oh great, lets have empty > packages where none is needed to keep the system symmetric and avoid > all confusion). This reminds me of when i started using Debian. It was always the one -devel package that was missing. You get used to it somehow, just in our case one doesn't even know whether there is a a -devel package at all. Would going back to don't have devel splits at all be an option? Sebastian From phil at bolthole.com Wed Oct 7 23:28:34 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 7 Oct 2009 14:28:34 -0700 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <4ACCFF56.3010901@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> <20091006.14033000.2372649415@gyor.oxdrove.co.uk> <4ACCFF56.3010901@opencsw.org> Message-ID: On Wed, Oct 7, 2009 at 1:51 PM, Sebastian Kayser wrote: > > > This reminds me of when i started using Debian. It was always the one > -devel package that was missing. You get used to it somehow, just in our > case one doesn't even know whether there is a a -devel package at all. > > Would going back to don't have devel splits at all be an option? > well, it sort of would be, if you voted for "case by case basis". Why did you not vote for that option, if you feel this way? http://doodle.com/2e8eakee997gtmmv From phil at bolthole.com Wed Oct 7 23:31:46 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 7 Oct 2009 14:31:46 -0700 Subject: [csw-maintainers] Proposal for name of our GAR version In-Reply-To: <4ACCE50D.40801@wbonnet.net> References: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> <1254921389-sup-6432@ntdws12.chass.utoronto.ca> <4ACCE50D.40801@wbonnet.net> Message-ID: On Wed, Oct 7, 2009 at 11:59 AM, William Bonnet wrote: > Hi > > A few puns are coming to my mind like Gar-Age or Gar-Land :) > > Garrigue is cool also ... or Garvey ? > Maybe something that implies storage, or putting things together... Garrison? :-) surprisingly, it would seen to NOT be taken by anything, according to freshmeat.net From skayser at opencsw.org Wed Oct 7 23:45:49 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 07 Oct 2009 23:45:49 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> <20091006.14033000.2372649415@gyor.oxdrove.co.uk> <4ACCFF56.3010901@opencsw.org> Message-ID: <4ACD0C0D.5040008@opencsw.org> Philip Brown wrote on 07.10.2009 23:28: > On Wed, Oct 7, 2009 at 1:51 PM, Sebastian Kayser wrote: >> >> This reminds me of when i started using Debian. It was always the one >> -devel package that was missing. You get used to it somehow, just in our >> case one doesn't even know whether there is a a -devel package at all. >> >> Would going back to don't have devel splits at all be an option? >> > > well, it sort of would be, if you voted for "case by case basis". > Why did you not vote for that option, if you feel this way? > > http://doodle.com/2e8eakee997gtmmv Simply rethinking my opinion after the input in this thread. Was used to the -devel split from other platforms, we started introducing more -devel packages. Consistent user experience makes great sense to me, so why not go all the way. Thinking about the contrary, like James suggested ("I think that installing a product by name should install that product, a 1:1 correspondence between upstream product and top level package with the same name"), also makes sense to me. It is just as consistent as strict _devel splits. That's why i was asking: Would going back to don't have devel splits *at all* also be an option? Sebastian From phil at bolthole.com Wed Oct 7 23:58:38 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 7 Oct 2009 14:58:38 -0700 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <4ACD0C0D.5040008@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> <20091006.14033000.2372649415@gyor.oxdrove.co.uk> <4ACCFF56.3010901@opencsw.org> <4ACD0C0D.5040008@opencsw.org> Message-ID: On Wed, Oct 7, 2009 at 2:45 PM, Sebastian Kayser wrote: > .... > That's why i was asking: > Would going back to don't have devel splits *at all* also be an option? > That would result in certain packages quadrupling in size, I think. Mostly this is to do with the libfoo.a splitout. download size IS an issue for some set of our users. That is after all, why we split out _rt packages. I will say this, as something to ruminate on: Having 100% consistency, purely for consistency's sake alone, is not a good thing, in my opinion. It is not the greatest benefit to the greatest amount of users. Dago's arguments for always splitting, are "consistency, and security". I have just addressed the first here, and the second I think is fallacious. Come on now, how does it really lower security, to have header files on the system, for completely public software? !!! even if it did... it wouldnt do any good unless you have a COMPILER on the system. Dont want people to compile stuff on your system? Remove the compiler. Simple. Then it doesnt matter if there are header files, or any other development paraphernalia on the system. If a potential attacker can somehow install their own compiler.. they can sure install their own header files too!!! From dam at opencsw.org Thu Oct 8 09:45:46 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 8 Oct 2009 09:45:46 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> <20091006.14033000.2372649415@gyor.oxdrove.co.uk> <4ACCFF56.3010901@opencsw.org> <4ACD0C0D.5040008@opencsw.org> Message-ID: <16EB4321-3E1C-48CC-9D05-10D8F4C0DFCA@opencsw.org> Hi Phil, Am 07.10.2009 um 23:58 schrieb Philip Brown: > On Wed, Oct 7, 2009 at 2:45 PM, Sebastian Kayser > wrote: >> .... >> That's why i was asking: >> Would going back to don't have devel splits *at all* also be an >> option? > > That would result in certain packages quadrupling in size, I think. > Mostly this is to do with the libfoo.a splitout. > > download size IS an issue for some set of our users. That is after > all, why we split out _rt packages. > > I will say this, as something to ruminate on: > Having 100% consistency, purely for consistency's sake alone, is not a > good thing, in my opinion. > It is not the greatest benefit to the greatest amount of users. So, what does the user want? The users eithers wants headers or not. It would be fairly easy to add a flag "wants_devel = 1" to pkg-get.conf or pkgutil.conf which additionally tries to install _devel when is requested. There could also be a command to add _devel for every package installed. So, for the usability is doesn't matter if _devel is split of or not. It may even be better to split it off and automate it this way. PS: Same goes for _doc. Best regards -- Dago From james at opencsw.org Thu Oct 8 10:27:13 2009 From: james at opencsw.org (James Lee) Date: Thu, 08 Oct 2009 08:27:13 GMT Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <4ACCFF56.3010901@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> <20091006.14033000.2372649415@gyor.oxdrove.co.uk> <4ACCFF56.3010901@opencsw.org> Message-ID: <20091008.8271300.4238381744@gyor.oxdrove.co.uk> On 07/10/09, 21:51:34, Sebastian Kayser wrote regarding Re: [csw-maintainers] Handling of devel package splits: > > + It's a pain for the developer to know to install the -dev packages. > > Not all packages naturally have dev parts and it's not possible to > > tell if it's missing or never exists (oh great, lets have empty > > packages where none is needed to keep the system symmetric and avoid > > all confusion). > This reminds me of when i started using Debian. It was always the one > -devel package that was missing. You get used to it somehow, just in our > case one doesn't even know whether there is a a -devel package at all. I don't know Debian but am I right in thinking it's both an OS and user software distribution? In which case it's more like the user software that come with Solaris. Consider an OS supplied supplementary package: $ pkginfo | grep SUNWjpg GNOME2 SUNWjpg jpeg - The Independent JPEG Groups JPEG software GNOME2 SUNWjpg-devel jpeg - The Independent JPEG Groups JPEG software - development files GNOME2 SUNWjpg-devel-share jpeg - The Independent JPEG Groups JPEG software - development files - /usr/share It's split into 3 parts. First notice that although it is split I have all three parts so without looking at the packaging it's no different to having a single package. Reasons to install a full distribution at OS install: (1) It avoids decided what is needed and what is not. At first install I defy anyone to know what every package does. (2) Can patch the system and then use a patch version of something I later found I needed. If only some OS packages are installed and the system is patched and later more OS packages are add the additions are unpatched. Best to add them in the first place. (3) The hassle of adding later - it's not as easy as pkg-get. So I accept that a system has bits I don't need for reasons I don't need to know. There are cases when a bare system install is right but think how that is achieved. Not by naming each packages on the command line of pkg-get but by a single selection made at install time. If there was an install option such that when I install foo I get foo-dev or not than it would make managing the shadow development set easier. James. From james at opencsw.org Thu Oct 8 10:27:16 2009 From: james at opencsw.org (James Lee) Date: Thu, 08 Oct 2009 08:27:16 GMT Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> <20091006.14033000.2372649415@gyor.oxdrove.co.uk> <4ACCFF56.3010901@opencsw.org> <4ACD0C0D.5040008@opencsw.org> Message-ID: <20091008.8271600.282988649@gyor.oxdrove.co.uk> On 07/10/09, 22:58:38, Philip Brown wrote regarding Re: [csw-maintainers] Handling of devel package splits: > That would result in certain packages quadrupling in size, I think. > Mostly this is to do with the libfoo.a splitout. Why do we ship static libs at all? (Excepting a few obvious cases, gcc) James. From dam at opencsw.org Thu Oct 8 10:38:28 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 8 Oct 2009 10:38:28 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <20091008.8271600.282988649@gyor.oxdrove.co.uk> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> <20091006.14033000.2372649415@gyor.oxdrove.co.uk> <4ACCFF56.3010901@opencsw.org> <4ACD0C0D.5040008@opencsw.org> <20091008.8271600.282988649@gyor.oxdrove.co.uk> Message-ID: <6314D9FE-F00F-4162-9F53-C69728786223@opencsw.org> Hi James, Am 08.10.2009 um 10:27 schrieb James Lee: > On 07/10/09, 22:58:38, Philip Brown wrote > regarding Re: > [csw-maintainers] Handling of devel package splits: > >> That would result in certain packages quadrupling in size, I think. >> Mostly this is to do with the libfoo.a splitout. > > Why do we ship static libs at all? > (Excepting a few obvious cases, gcc) Because there are some cases where you need it. Perls DynaLoader.a for FFI comes to my mind which bit us lately. But you are right: Usually static libs should be avoided even in devel packages. GAR already excludes them by default for all packages. Best regards -- Dago From maciej at opencsw.org Thu Oct 8 16:16:22 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 8 Oct 2009 15:16:22 +0100 Subject: [csw-maintainers] Submitting a package to the release manager Message-ID: I'm writing a script to automate bits of the release process from the package maintainer side, and I'd like to learn more about how people do things currently, so I can write something that fits reasonably well with the current practices. When a maintainer decides to release a package, they need to remove the package from testing/ and copy it to newpkgs/ on bender. However, the maintainer needs to retain a copy of the package for future reference. I have a directory ~/to-release, in which I keep the packages I intend to send to the release maintainer. I also have ~/to-release/released where I keep copies of the packages that have been released. Do other people do it similarly? Where do you store the copies of packages being currently in the release process? Maciej From bwalton at opencsw.org Thu Oct 8 16:28:04 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 08 Oct 2009 10:28:04 -0400 Subject: [csw-maintainers] Submitting a package to the release manager In-Reply-To: References: Message-ID: <1255011826-sup-4723@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Thu Oct 08 10:16:22 -0400 2009: > been released. Do other people do it similarly? Where do you store the > copies of packages being currently in the release process? I bounce my packages through my own boxes here, as I haven't setup a shared key between the buildfarm and bender. I maintain a local ~/csw which houses packages that I've pushed over to bender. HTH. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Oct 8 16:41:54 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 8 Oct 2009 15:41:54 +0100 Subject: [csw-maintainers] Submitting a package to the release manager In-Reply-To: <1255011826-sup-4723@ntdws12.chass.utoronto.ca> References: <1255011826-sup-4723@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Oct 8, 2009 at 3:28 PM, Ben Walton wrote: > Excerpts from Maciej (Matchek) Blizinski's message of Thu Oct 08 10:16:22 -0400 2009: > >> been released. Do other people do it similarly? Where do you store the >> copies of packages being currently in the release process? > > I bounce my packages through my own boxes here, as I haven't setup a > shared key between the buildfarm and bender. ?I maintain a local ~/csw > which houses packages that I've pushed over to bender. I think I'll make the directory names configurable, with the defaults set to ~/csw/pending-release and ~/csw/released. I guess people will agree that the two directories are needed in the release process (from the maintainer perspective). Maciej From dam at opencsw.org Thu Oct 8 16:43:59 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 8 Oct 2009 16:43:59 +0200 Subject: [csw-maintainers] Submitting a package to the release manager In-Reply-To: References: Message-ID: Hi Maciej, Am 08.10.2009 um 16:16 schrieb Maciej (Matchek) Blizinski: > When a maintainer decides to release a package, they need to remove > the package from testing/ and copy it to newpkgs/ on bender. However, > the maintainer needs to retain a copy of the package for future > reference. I have a directory ~/to-release, in which I keep the > packages I intend to send to the release maintainer. I also have > ~/to-release/released where I keep copies of the packages that have > been released. Do other people do it similarly? Where do you store the > copies of packages being currently in the release process? I leave them in testing/. An automated tool could fingerprint the pkgs and remove it automatically from testing if there has been a package with the same fingerprint released. Best regards -- Dago From bonivart at opencsw.org Thu Oct 8 16:46:50 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 8 Oct 2009 16:46:50 +0200 Subject: [csw-maintainers] Submitting a package to the release manager In-Reply-To: References: Message-ID: <625385e30910080746o5d6aca4fv96bea1401427a934@mail.gmail.com> On Thu, Oct 8, 2009 at 4:43 PM, Dagobert Michelsen wrote: > I leave them in testing/. An automated tool could fingerprint the pkgs > and remove it automatically from testing if there has been a package with > the same fingerprint released. +1 It's nice to be able to easily get the packages during the package release cycle. -- /peter From bwalton at opencsw.org Thu Oct 8 16:52:22 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 08 Oct 2009 10:52:22 -0400 Subject: [csw-maintainers] Submitting a package to the release manager In-Reply-To: <625385e30910080746o5d6aca4fv96bea1401427a934@mail.gmail.com> References: <625385e30910080746o5d6aca4fv96bea1401427a934@mail.gmail.com> Message-ID: <1255013505-sup-9288@ntdws12.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Thu Oct 08 10:46:50 -0400 2009: > +1 I'll see your +1 and raise it another +1. I think this is the most convenient approach from the human interaction point of view. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Oct 8 17:06:35 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 8 Oct 2009 16:06:35 +0100 Subject: [csw-maintainers] Submitting a package to the release manager In-Reply-To: References: <1255011826-sup-4723@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Oct 8, 2009 at 3:41 PM, Maciej (Matchek) Blizinski wrote: > On Thu, Oct 8, 2009 at 3:28 PM, Ben Walton wrote: >> Excerpts from Maciej (Matchek) Blizinski's message of Thu Oct 08 10:16:22 -0400 2009: >> >>> been released. Do other people do it similarly? Where do you store the >>> copies of packages being currently in the release process? >> >> I bounce my packages through my own boxes here, as I haven't setup a >> shared key between the buildfarm and bender. ?I maintain a local ~/csw >> which houses packages that I've pushed over to bender. > > I think I'll make the directory names configurable, with the defaults > set to ~/csw/pending-release and ~/csw/released. I guess people will > agree that the two directories are needed in the release process (from > the maintainer perspective). I would like to discuss the configuration file. For the current needs, it's going to be the configuration file for the release process, but in principle it could be a maintainer-specific configuration file for other csw-related scripts. Python provides a configuration parser which deals with the .ini format, and I'm tempted to use it.. I like to use readily available components where I can. Another option would be to reuse ~/.garrc, but I don't know how to reliably extract information from this file. I don't want to write a lame Makefile parser in Python, and I can't write a decent one in my allocated time. Also, I don't want my tool to be GAR-dependent. So, a separate config file. What do people think is a good configuration file name? The first name which comes to my mind is ~/.csw.ini or ~/.opencsw.ini. (I somehow like ~/.opencsw.ini better, because it's less ambiguous.) The format would be something along the lines of: [release] statedir: /home/maciej/csw/state releasedpkgs: /home/maciej/csw/released releasemgr: ... at opencsw.org releasecc: ... at opencsw.org Thoughts? Maciej From maciej at opencsw.org Thu Oct 8 17:08:23 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 8 Oct 2009 16:08:23 +0100 Subject: [csw-maintainers] Submitting a package to the release manager In-Reply-To: <625385e30910080746o5d6aca4fv96bea1401427a934@mail.gmail.com> References: <625385e30910080746o5d6aca4fv96bea1401427a934@mail.gmail.com> Message-ID: On Thu, Oct 8, 2009 at 3:46 PM, Peter Bonivart wrote: > On Thu, Oct 8, 2009 at 4:43 PM, Dagobert Michelsen wrote: >> I leave them in testing/. An automated tool could fingerprint the pkgs >> and remove it automatically from testing if there has been a package with >> the same fingerprint released. > > +1 > > It's nice to be able to easily get the packages during the package > release cycle. I thought the same way, but there was a thread on this list (I couldn't find it in the archives) in which somebody said that the package file should be removed from testing when it's being send to the release manager. Intuitively, I would think that it's best if the files stays in testing/ until it's released, to avoid a gap in the file availability. Maciej From bwalton at opencsw.org Thu Oct 8 17:14:22 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 08 Oct 2009 11:14:22 -0400 Subject: [csw-maintainers] Submitting a package to the release manager In-Reply-To: References: <625385e30910080746o5d6aca4fv96bea1401427a934@mail.gmail.com> Message-ID: <1255014771-sup-2482@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Thu Oct 08 11:08:23 -0400 2009: > I thought the same way, but there was a thread on this list (I > couldn't find it in the archives) in which somebody said that the > package file should be removed from testing when it's being send to > the release manager. Intuitively, I would think that it's best if the > files stays in testing/ until it's released, to avoid a gap in the > file availability. The tool that pushes files to the mirrors and registers it in the DB should also reach in an rm the file iff the filename and md5sum match. That gets the best of both worlds. The release script is then simply a wrapper around an email (or other trigger) to the release system. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: not available URL: From maciej at opencsw.org Thu Oct 8 17:23:57 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 8 Oct 2009 16:23:57 +0100 Subject: [csw-maintainers] Submitting a package to the release manager In-Reply-To: <1255014771-sup-2482@ntdws12.chass.utoronto.ca> References: <625385e30910080746o5d6aca4fv96bea1401427a934@mail.gmail.com> <1255014771-sup-2482@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Oct 8, 2009 at 4:14 PM, Ben Walton wrote: > Excerpts from Maciej (Matchek) Blizinski's message of Thu Oct 08 11:08:23 -0400 2009: > >> I thought the same way, but there was a thread on this list (I >> couldn't find it in the archives) in which somebody said that the >> package file should be removed from testing when it's being send to >> the release manager. Intuitively, I would think that it's best if the >> files stays in testing/ until it's released, to avoid a gap in the >> file availability. > > The tool that pushes files to the mirrors and registers it in the DB > should also reach in an rm the file iff the filename and md5sum match. > That gets the best of both worlds. ?The release script is then simply > a wrapper around an email (or other trigger) to the release system. Yes, primarily it would be a wrapper around e-mail. I also thought about making it move files around a little. For instance, copy files from testing/ to newpkgs/ and store state, or log the activity for future reference. (When did I send this? What were the checksums? etc.) Maciej From bonivart at opencsw.org Thu Oct 8 17:33:01 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 8 Oct 2009 17:33:01 +0200 Subject: [csw-maintainers] Submitting a package to the release manager In-Reply-To: References: <1255011826-sup-4723@ntdws12.chass.utoronto.ca> Message-ID: <625385e30910080833y763d4e7ar4e6741436b30a68d@mail.gmail.com> On Thu, Oct 8, 2009 at 5:06 PM, Maciej (Matchek) Blizinski wrote: > What do people think is a good configuration file name? The first name > which comes to my mind is ~/.csw.ini or ~/.opencsw.ini. (I somehow > like ~/.opencsw.ini better, because it's less ambiguous.) I think those are too generic. I usually use the script name itself so .ini in your case. -- /peter From maciej at opencsw.org Thu Oct 8 18:07:38 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 8 Oct 2009 17:07:38 +0100 Subject: [csw-maintainers] UTF-8 on the buildfarm Message-ID: Is anyone able to edit files in UTF-8 on the buildfarm? Say, on the 'login' host. On my Solaris boxen, I only need to specify two environment variables: > set | grep UTF LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 Once they're set, I'm able to type the unicode characters in the shell and in vim. In Solaris 10, that is. For instance $ uname -a SunOS sunbox 5.10 Generic_138888-03 sun4u sparc SUNW,Sun-Fire-V215 $ echo ????????? ????????? On 'login' I can't type these characters at all. Any ideas? Maciej From phil at bolthole.com Thu Oct 8 18:10:05 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 8 Oct 2009 09:10:05 -0700 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <20091008.8271300.4238381744@gyor.oxdrove.co.uk> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> <20091006.14033000.2372649415@gyor.oxdrove.co.uk> <4ACCFF56.3010901@opencsw.org> <20091008.8271300.4238381744@gyor.oxdrove.co.uk> Message-ID: On Thu, Oct 8, 2009 at 1:27 AM, James Lee wrote: > ... ?Consider an OS supplied supplementary package: > > $ pkginfo | grep SUNWjpg > GNOME2 ? ? ?SUNWjpg ? ? ? ? ? ? ? ? ? ? ? ? ?jpeg - The Independent JPEG > Groups JPEG software > GNOME2 ? ? ?SUNWjpg-devel ? ? ? ? ? ? ? ? ? ?jpeg - The Independent JPEG > Groups JPEG software - development files Consider also, that sun does NOT consistently do things this way. SOME things are split into SUNWfoo and SUNWfoo-devel OTHER things, have their "devel" bits lumped together with other things. For example, a recent "hot button" issue: xpm.h There is no separate xpmdevel for it. it is in SUNWxwinc. (mind you, thats because libxpm itself isnt in its own package, it's in SUNWxwplt But it's still something to think about; having more consolidation of certain development files, rather than the "one tarfile, one package" approach for everything. > There are cases when a bare system install is right but think how that > is achieved. ?Not by naming each packages on the command line of pkg-get > but by a single selection made at install time. ?If there was an install > option such that when I install foo I get foo-dev or not than it would > make managing the shadow development set easier. the interesting part comes when someone previously had a non-devel system, then decides they want to compile packge "A", and so needs to install the devel for it.. but does NOT want to download/install the devel stuff for "B", "C", "D", "E", ... From maciej at opencsw.org Thu Oct 8 18:12:28 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 8 Oct 2009 17:12:28 +0100 Subject: [csw-maintainers] UTF-8 on the buildfarm In-Reply-To: References: Message-ID: One more thing: Perl complains: ------------8<------------- maciej at login [login]:~ > pkgutil -h perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL = "en_US.UTF-8", LANG = "en_US.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). Pkgutil 1.5, install Solaris packages the easy way. Usage: pkgutil [option]... [package](-[version])... ------------8<------------- On my boxes, it doesn't complain at all. Maciej From trygvis at opencsw.org Thu Oct 8 18:22:29 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Thu, 08 Oct 2009 18:22:29 +0200 Subject: [csw-maintainers] Submitting a package to the release manager In-Reply-To: References: Message-ID: <4ACE11C5.5020902@opencsw.org> Maciej (Matchek) Blizinski wrote: > I'm writing a script to automate bits of the release process from the > package maintainer side, and I'd like to learn more about how people > do things currently, so I can write something that fits reasonably > well with the current practices. > > When a maintainer decides to release a package, they need to remove > the package from testing/ and copy it to newpkgs/ on bender. However, > the maintainer needs to retain a copy of the package for future > reference. I have a directory ~/to-release, in which I keep the > packages I intend to send to the release maintainer. I also have > ~/to-release/released where I keep copies of the packages that have > been released. Do other people do it similarly? Where do you store the > copies of packages being currently in the release process? Gar always put it in ~/gar/pkgs which I use to copy to testing/ and to newpkgs/ when I'm ready for a release. -- Trygve From bchill at opencsw.org Thu Oct 8 18:42:01 2009 From: bchill at opencsw.org (Brian Hill) Date: Thu, 8 Oct 2009 16:42:01 +0000 Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <58883.194.246.122.22.1254931936.squirrel@ssl.skayser.de> References: <4ACB995D.90707@opencsw.org> <20091007055448.GA13472@vm-1.bch.net> <4ACCA87E.6080903@opencsw.org> <20091007153325.GA23587@vm-1.bch.net> <1E7DFDC6-AAAA-46F0-9C47-DECC534F88D6@opencsw.org> <20091007155211.GA24940@vm-1.bch.net> <9A4426DC-8953-4C7A-B367-F477FCF2246C@opencsw.org> <4ACCBC12.6040505@opencsw.org> <58883.194.246.122.22.1254931936.squirrel@ssl.skayser.de> Message-ID: <20091008164201.GC8715@vm-1.bch.net> Thanks everyone! Peter Bonivart's and Sebastian Kayser's suggestion to use pkgutil worked to install the sendmail from testing. This worked: # pkgutil -t http://mirror.opencsw.org/opencsw/testing -iN sendmail Brian ====================================================================== On Wed, Oct 07, 2009 at 06:12:16PM +0200, Sebastian Kayser wrote: > Mike Watters wrote: > > Dagobert Michelsen wrote: > >> Am 07.10.2009 um 17:52 schrieb Brian Hill: > >>> # pkg-get -s http://mirror.opencsw.org/opencsw/testing -v -U upgrade > >>> sendmail > >>> DEBUG-ONLY/VERBOSE MODE: level=1 > >>> Getting catalog... > >>> --2009-10-07 15:49:33-- > >>> http://mirror.opencsw.org/opencsw/testing/sparc/5.8/catalog > >>> Resolving mirror.opencsw.org... 213.178.77.176 > >>> Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. > >>> HTTP request sent, awaiting response... 200 OK > >>> Length: 37272 (36K) [text/plain] > >>> Saving to: `catalog' > >>> > >>> 100%[================================================================>] > >>> 37,272 49.7K/s in 0.7s > >>> > >>> 2009-10-07 15:49:34 (49.7 KB/s) - `catalog' saved [37272/37272] > >>> > >>> Updating catalog file > >>> /var/pkg-get/catalog-mirror.opencsw.org updated > >>> > >>> --2009-10-07 15:49:34-- > >>> http://mirror.opencsw.org/opencsw/testing/sparc/5.8/descriptions > >>> Resolving mirror.opencsw.org... 213.178.77.176 > >>> Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. > >>> HTTP request sent, awaiting response... 200 OK > >>> Length: 9040 (8.8K) [text/plain] > >>> Saving to: `descriptions' > >>> > >>> 100%[================================================================>] > >>> 9,040 29.8K/s in 0.3s > >>> > >>> 2009-10-07 15:49:35 (29.8 KB/s) - `descriptions' saved [9040/9040] > >>> > >>> Updated description file > >>> INTERNAL ERROR: cannot get remote version for CSWbdb > >>> Perhaps your catalog is out of date > >>> Error: dependancies for sendmail not up to date. > >>> Relevant packages needing download: > >>> INTERNAL ERROR: cannot get remote version for CSWbdb > >>> Perhaps your catalog is out of date > >>> CSWoldaprt openldap_rt 643862 bytes > >>> INTERNAL ERROR: cannot get remote version for CSWosslrt > >>> Perhaps your catalog is out of date > >>> INTERNAL ERROR: cannot get remote version for CSWsasl > >>> Perhaps your catalog is out of date > >>> INTERNAL ERROR: cannot get remote version for CSWcswclassutils > >>> Perhaps your catalog is out of date > >>> INTERNAL ERROR: cannot get remote version for CSWcommon > >>> Perhaps your catalog is out of date > >>> INTERNAL ERROR: cannot get remote version for CSWisaexec > >>> Perhaps your catalog is out of date > >>> INTERNAL ERROR: cannot get remote version for CSWlibnet > >>> Perhaps your catalog is out of date > >>> INTERNAL ERROR: cannot get remote version for CSWkrb5lib > >>> Perhaps your catalog is out of date > >>> CSWsendmail sendmail 2796157 bytes > >> > >> This is bad. It looks like a bug in pkg-get when dependencies are > >> already installed on the local system but not in the catalog (which > >> should be ok). Phil, how is this handled in pkg-get? > > > > I think you need to update your version of openldap_rt > > Thanks for testing, Brian. I second Dago's impression, we have had pkg-get > cope badly with testing (or any partial catalog) several times in the > past. > > Did you try pkgutil? > > pkgutil -t http://mirror.opencsw.org/opencsw/testing -u sendmail > > When using -t, pkgutil automatically creates an internal overlay to the > catalog configured via pkgutil.conf and thus can resolve dependencies > which are not covered by testing alone. pkg-get doesn't do so IIRC. > > Could we point that out on the testing page? > > Sebastian > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers -- _____________________________________________________________________ / Brian C. Hill bchill at bch.net http://brian.bch.net \ | UNIX Specialist BCH Technical Services http://www.bch.net | From bchill at opencsw.org Thu Oct 8 18:52:27 2009 From: bchill at opencsw.org (Brian Hill) Date: Thu, 8 Oct 2009 16:52:27 +0000 Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <4ACCBC12.6040505@opencsw.org> References: <4ACB995D.90707@opencsw.org> <20091007055448.GA13472@vm-1.bch.net> <4ACCA87E.6080903@opencsw.org> <20091007153325.GA23587@vm-1.bch.net> <1E7DFDC6-AAAA-46F0-9C47-DECC534F88D6@opencsw.org> <20091007155211.GA24940@vm-1.bch.net> <9A4426DC-8953-4C7A-B367-F477FCF2246C@opencsw.org> <4ACCBC12.6040505@opencsw.org> Message-ID: <20091008165227.GD8715@vm-1.bch.net> Hi Mike, sendmail-8.14.3 is running without an issue using /etc/mail/sendmai.cf (which I sort of prefer over /opt/csw/etc/mail or /etc/opt/csw/mail). I had to do a few changes myself (added to my cfengine shadow tree repo): * add some ifelf/sinclude handling to my sendmail.mc to find the /opt/csw/share/mail/cf files * symlink /usr/lib/sendmail -> /opt/csw/lib/sendmail * symlink /etc/mail/submit.cf -> /opt/csw/etc/mail/submit.cf * create a /var/spool/mail/clientmqueue (smmsp:smmsp) * add smmsp login/group to my supplementary passwd/group files (I think that's it) I guess the Sun conversion script included in the package would have taken care of these, but I wanted to add this all to my CFE repo anyway - better to understand the details intimately. Thanks! Brian ====================================================================== On Wed, Oct 07, 2009 at 11:04:34AM -0500, Mike Watters wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dagobert Michelsen wrote: > > Hi Brian, > > > > Am 07.10.2009 um 17:52 schrieb Brian Hill: > >> Still, no luck: > >> > >> # pkg-get -U -u CSWbdb > >> Getting catalog... > >> --2009-10-07 15:49:11-- > >> http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/catalog > >> Resolving ibiblio.org... 152.46.7.80 > >> Connecting to ibiblio.org|152.46.7.80|:80... connected. > >> HTTP request sent, awaiting response... 200 OK > >> Length: 407617 (398K) [text/plain] > >> Saving to: `catalog' > >> > >> 100%[================================================================>] > >> 407,617 336K/s in 1.2s > >> > >> 2009-10-07 15:49:13 (336 KB/s) - `catalog' saved [407617/407617] > >> > >> Stripping off catalog signature without verifying > >> Updating catalog file > >> /var/pkg-get/catalog-ibiblio.org updated > >> > >> --2009-10-07 15:49:13-- > >> http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/descriptions > >> > >> Resolving ibiblio.org... 152.46.7.80 > >> Connecting to ibiblio.org|152.46.7.80|:80... connected. > >> HTTP request sent, awaiting response... 200 OK > >> Length: 112691 (110K) [text/plain] > >> Saving to: `descriptions' > >> > >> 100%[================================================================>] > >> 112,691 214K/s in 0.5s > >> > >> 2009-10-07 15:49:13 (214 KB/s) - `descriptions' saved [112691/112691] > >> > >> Updated description file > >> No worries... you already have version 4.7.25,REV=2009.07.01 of > >> berkeleydb > >> If you doubt this message, run 'pkg-get -U', then run > >> 'pkg-get upgrade berkeleydb' > > > > This is good. > > > >> # pkg-get -s http://mirror.opencsw.org/opencsw/testing -v -U upgrade > >> sendmail > >> DEBUG-ONLY/VERBOSE MODE: level=1 > >> Getting catalog... > >> --2009-10-07 15:49:33-- > >> http://mirror.opencsw.org/opencsw/testing/sparc/5.8/catalog > >> Resolving mirror.opencsw.org... 213.178.77.176 > >> Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. > >> HTTP request sent, awaiting response... 200 OK > >> Length: 37272 (36K) [text/plain] > >> Saving to: `catalog' > >> > >> 100%[================================================================>] > >> 37,272 49.7K/s in 0.7s > >> > >> 2009-10-07 15:49:34 (49.7 KB/s) - `catalog' saved [37272/37272] > >> > >> Updating catalog file > >> /var/pkg-get/catalog-mirror.opencsw.org updated > >> > >> --2009-10-07 15:49:34-- > >> http://mirror.opencsw.org/opencsw/testing/sparc/5.8/descriptions > >> Resolving mirror.opencsw.org... 213.178.77.176 > >> Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. > >> HTTP request sent, awaiting response... 200 OK > >> Length: 9040 (8.8K) [text/plain] > >> Saving to: `descriptions' > >> > >> 100%[================================================================>] > >> 9,040 29.8K/s in 0.3s > >> > >> 2009-10-07 15:49:35 (29.8 KB/s) - `descriptions' saved [9040/9040] > >> > >> Updated description file > >> INTERNAL ERROR: cannot get remote version for CSWbdb > >> Perhaps your catalog is out of date > >> Error: dependancies for sendmail not up to date. > >> Relevant packages needing download: > >> INTERNAL ERROR: cannot get remote version for CSWbdb > >> Perhaps your catalog is out of date > >> CSWoldaprt openldap_rt 643862 bytes > >> INTERNAL ERROR: cannot get remote version for CSWosslrt > >> Perhaps your catalog is out of date > >> INTERNAL ERROR: cannot get remote version for CSWsasl > >> Perhaps your catalog is out of date > >> INTERNAL ERROR: cannot get remote version for CSWcswclassutils > >> Perhaps your catalog is out of date > >> INTERNAL ERROR: cannot get remote version for CSWcommon > >> Perhaps your catalog is out of date > >> INTERNAL ERROR: cannot get remote version for CSWisaexec > >> Perhaps your catalog is out of date > >> INTERNAL ERROR: cannot get remote version for CSWlibnet > >> Perhaps your catalog is out of date > >> INTERNAL ERROR: cannot get remote version for CSWkrb5lib > >> Perhaps your catalog is out of date > >> CSWsendmail sendmail 2796157 bytes > > > > This is bad. It looks like a bug in pkg-get when dependencies are > > already installed on the local system but not in the catalog (which > > should be ok). Phil, how is this handled in pkg-get? > > > > > > Best regards > > > > -- Dago > > _______________________________________________ > > maintainers mailing list > > maintainers at lists.opencsw.org > > https://lists.opencsw.org/mailman/listinfo/maintainers > > I think you need to update your version of openldap_rt > > - -- > ~Mike > "Any intelligent fool can make things bigger, more complex, > and more violent. It takes a touch of genius -- and a lot of courage -- > to move in the opposite direction." --> Albert Einstein 1879 - 1955 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (SunOS) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkrMvBEACgkQLrhmsXMSLxe8uACfbEYWDBJXRfhZMbRVBbPQ3yDg > wYcAnA3YtXgS42/4XgxEI4ZGEF0uzAGl > =W/g6 > -----END PGP SIGNATURE----- -- _____________________________________________________________________ / Brian C. Hill bchill at bch.net http://brian.bch.net \ | UNIX Specialist BCH Technical Services http://www.bch.net | From skayser at opencsw.org Thu Oct 8 19:11:25 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 08 Oct 2009 19:11:25 +0200 Subject: [csw-maintainers] UTF-8 on the buildfarm In-Reply-To: References: Message-ID: <4ACE1D3D.3010602@opencsw.org> Hi Maciej, Maciej (Matchek) Blizinski wrote on 08.10.2009 18:12: > One more thing: Perl complains: > > ------------8<------------- > maciej at login [login]:~ > pkgutil -h > perl: warning: Setting locale failed. > perl: warning: Please check that your locale settings: > LC_ALL = "en_US.UTF-8", > LANG = "en_US.UTF-8" > are supported and installed on your system. > perl: warning: Falling back to the standard locale ("C"). > Pkgutil 1.5, install Solaris packages the easy way. > > Usage: pkgutil [option]... [package](-[version])... > ------------8<------------- > > On my boxes, it doesn't complain at all. that's a matter of the installed (available) locales. The requested UTF-8 locales are currently just not installed on the login box. $ locale -a C POSIX iso_8859_1 localeadm can be used on Solaris 10 to install the missing locales from the installation medium. As a side note: LC_ALL and LANG is IMHO more than you would need. Both are responsible for setting locale category settings (LC_*). LC_ALL overrides all LC_* categories, while LANG is a fallback for those that are undefined. An example: $ LC_CTYPE=en_US.UTF-8 locale LANG= LC_CTYPE=en_US.UTF-8 LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_ALL= The locale values enclosed in double quotes are the ones derived by LANG or LC_ALL (default C), those without double quotes are explicit ones. Another example, use a fallback via LANG, set LC_CTYPE explicitly. $ LANG=en_US LC_CTYPE=en_US.UTF-8 locale LANG=en_US LC_CTYPE=en_US.UTF-8 LC_NUMERIC="en_US" LC_TIME="en_US" LC_COLLATE="en_US" LC_MONETARY="en_US" LC_MESSAGES="en_US" LC_ALL= Now if we set LC_ALL, it has priority over LANG as well as over the explicit LC_CTYPE. $ LANG=en_US LC_CTYPE=en_US.UTF-8 LC_ALL=C locale LANG=en_US LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_ALL=C Makes sense? Sebastian From bwalton at opencsw.org Thu Oct 8 19:15:32 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 08 Oct 2009 13:15:32 -0400 Subject: [csw-maintainers] Submitting a package to the release manager In-Reply-To: <4ACE11C5.5020902@opencsw.org> References: <4ACE11C5.5020902@opencsw.org> Message-ID: <1255022101-sup-6594@ntdws12.chass.utoronto.ca> Excerpts from Trygve Laugst?l's message of Thu Oct 08 12:22:29 -0400 2009: > Gar always put it in ~/gar/pkgs which I use to copy to testing/ and to > newpkgs/ when I'm ready for a release. I have gar dump output package files into ~/staging (set in my .garrc). -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Oct 8 19:54:22 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 8 Oct 2009 19:54:22 +0200 Subject: [csw-maintainers] UTF-8 on the buildfarm In-Reply-To: <4ACE1D3D.3010602@opencsw.org> References: <4ACE1D3D.3010602@opencsw.org> Message-ID: <05534EA6-6BB0-453C-895F-435ACCEC172A@opencsw.org> Hi, Am 08.10.2009 um 19:11 schrieb Sebastian Kayser: > Hi Maciej, > > Maciej (Matchek) Blizinski wrote on 08.10.2009 18:12: >> One more thing: Perl complains: >> >> ------------8<------------- >> maciej at login [login]:~ > pkgutil -h >> perl: warning: Setting locale failed. >> perl: warning: Please check that your locale settings: >> LC_ALL = "en_US.UTF-8", >> LANG = "en_US.UTF-8" >> are supported and installed on your system. >> perl: warning: Falling back to the standard locale ("C"). >> Pkgutil 1.5, install Solaris packages the easy way. >> >> Usage: pkgutil [option]... [package](-[version])... >> ------------8<------------- >> >> On my boxes, it doesn't complain at all. > > that's a matter of the installed (available) locales. The requested > UTF-8 locales are currently just not installed on the login box. Maciej, do you need UTF8? Than I'll install it, but I tend to keep the installed languages not longer than necessary. Best regards -- Dago From Joerg.Schilling at fokus.fraunhofer.de Thu Oct 8 20:15:53 2009 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Thu, 08 Oct 2009 20:15:53 +0200 Subject: [csw-maintainers] UTF-8 on the buildfarm In-Reply-To: <05534EA6-6BB0-453C-895F-435ACCEC172A@opencsw.org> References: <4ACE1D3D.3010602@opencsw.org> <05534EA6-6BB0-453C-895F-435ACCEC172A@opencsw.org> Message-ID: <4ace2c59.0WiemAQFOzPNkwIP%Joerg.Schilling@fokus.fraunhofer.de> Dagobert Michelsen wrote: > > that's a matter of the installed (available) locales. The requested > > UTF-8 locales are currently just not installed on the login box. > > Maciej, do you need UTF8? Than I'll install it, but I tend to > keep the installed languages not longer than necessary. Don't forget: If you like to avoid make or autoconf failures, you need to set the locale to "C". J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From dam at opencsw.org Thu Oct 8 20:46:01 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 8 Oct 2009 20:46:01 +0200 Subject: [csw-maintainers] Archived catalogs Message-ID: <12235AB2-958C-46C1-82E9-A5B9C3FDB854@opencsw.org> Hi, has someone (Phil?) archived the old catalogs? Alternatively the newpkgs list would also be good. Ihsan, can you send me them as mbox? I would like to run some statistics and hack on generational catalogs and repo views. Best regards -- Dago From william at wbonnet.net Thu Oct 8 22:01:57 2009 From: william at wbonnet.net (William Bonnet) Date: Thu, 08 Oct 2009 22:01:57 +0200 Subject: [csw-maintainers] Archived catalogs In-Reply-To: <12235AB2-958C-46C1-82E9-A5B9C3FDB854@opencsw.org> References: <12235AB2-958C-46C1-82E9-A5B9C3FDB854@opencsw.org> Message-ID: <4ACE4535.3040103@wbonnet.net> Hi Dago > has someone (Phil?) archived the old catalogs? Alternatively the newpkgs > list would also be good. Ihsan, can you send me them as mbox? You'll find a few catalogs in the working folder of uwatch 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 Thu Oct 8 22:05:13 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 8 Oct 2009 22:05:13 +0200 Subject: [csw-maintainers] Archived catalogs In-Reply-To: <4ACE4535.3040103@wbonnet.net> References: <12235AB2-958C-46C1-82E9-A5B9C3FDB854@opencsw.org> <4ACE4535.3040103@wbonnet.net> Message-ID: Hi William, Am 08.10.2009 um 22:01 schrieb William Bonnet: >> has someone (Phil?) archived the old catalogs? Alternatively the >> newpkgs >> list would also be good. Ihsan, can you send me them as mbox? > You'll find a few catalogs in the working folder of uwatch Umh, not in /home/uwatch... And may you have a look at http://www.opencsw.org/package-gar-status.html again? Best regards -- Dago From maciej at opencsw.org Fri Oct 9 00:11:04 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 8 Oct 2009 23:11:04 +0100 Subject: [csw-maintainers] /var/opt/csw/run in the CSWcommon package Message-ID: Do people think it makes sense to include it? It looks like a shared directory. 5 packages use it already, and another 6 use /opt/csw/var/run, which is going to be ported. This makes 11 packages. Is it enough? Maciej From phil at bolthole.com Fri Oct 9 00:18:36 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 8 Oct 2009 15:18:36 -0700 Subject: [csw-maintainers] /var/opt/csw/run in the CSWcommon package In-Reply-To: References: Message-ID: On Thu, Oct 8, 2009 at 3:11 PM, Maciej (Matchek) Blizinski wrote: > Do people think it makes sense to include it? It looks like a shared > directory. 5 packages use it already, and another 6 use > /opt/csw/var/run, which is going to be ported. This makes 11 packages. > Is it enough? > errr.. there's also the issue of, should we actually be USING "/opt/csw/var/run"? it is rather different from the standard system version of /var/run, in that the system one is tmpfs, and nuked after every reboot. also.. why would we not use /var/run directly? we would just need to be careful about the naming of what goes in there. From bchill at opencsw.org Fri Oct 9 00:28:57 2009 From: bchill at opencsw.org (Brian Hill) Date: Thu, 8 Oct 2009 22:28:57 +0000 Subject: [csw-maintainers] /var/opt/csw/run in the CSWcommon package In-Reply-To: References: Message-ID: <20091008222857.GA3041@vm-1.bch.net> On Thu, Oct 08, 2009 at 03:18:36PM -0700, Philip Brown wrote: > On Thu, Oct 8, 2009 at 3:11 PM, Maciej (Matchek) Blizinski > wrote: > > Do people think it makes sense to include it? It looks like a shared > > directory. 5 packages use it already, and another 6 use > > /opt/csw/var/run, which is going to be ported. This makes 11 packages. > > Is it enough? > > > > errr.. there's also the issue of, should we actually be USING > "/opt/csw/var/run"? > > it is rather different from the standard system version of /var/run, > in that the system one is tmpfs, and nuked after every reboot. > > also.. why would we not use /var/run directly? we would just need to > be careful about the naming of what goes in there. I have to agree with Phillip. This ties into the discussion of /etc/opt/csw vs /opt/csw/etc somewhat. PID files should go in /var/run. Even if there are perceived namespace collisions, how often would you run, for example, Sun's bundled sendmail and CSW's sendmail at the same time? Brian From maciej at opencsw.org Fri Oct 9 00:54:00 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 8 Oct 2009 23:54:00 +0100 Subject: [csw-maintainers] /var/opt/csw/run in the CSWcommon package In-Reply-To: References: Message-ID: On Thu, Oct 8, 2009 at 11:18 PM, Philip Brown wrote: > it is rather different from the standard system version of /var/run, > in that the system one is tmpfs, and nuked after every reboot. > > also.. why would we not use /var/run directly? we would just need to > be careful about the naming of what goes in there. All right, I'm updating syslog-ng to use /var/run. Here's also a bit of a documentation update: diff --git a/htdocs/standards/layout.shtml b/htdocs/standards/layout.shtml index 7f8a1f1..7bfb709 100644 --- a/htdocs/standards/layout.shtml +++ b/htdocs/standards/layout.shtml @@ -156,8 +156,15 @@ on configuration of complex packages
var
-
Dont use this. Use /var/opt/csw instead. -

+
Don't use this. Use /var/opt/csw instead. +

+ There's an exception with relation to the pid + files. The /var/run directory is a tmpfs, + purged after each system restart. CSW packages should place + their pid files in /var/run rather + than /var/opt/csw/run, provided that there are + no file name clashes. +

X11
Maciej From phil at bolthole.com Fri Oct 9 02:57:58 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 8 Oct 2009 17:57:58 -0700 Subject: [csw-maintainers] /var/opt/csw/run in the CSWcommon package In-Reply-To: <20091008222857.GA3041@vm-1.bch.net> References: <20091008222857.GA3041@vm-1.bch.net> Message-ID: On Thu, Oct 8, 2009 at 3:28 PM, Brian Hill wrote: >> PID files should go in /var/run. > Even if there are perceived namespace collisions, how often would you run, > for example, Sun's bundled sendmail and CSW's sendmail at the same time? > not the point; you should be allowed to. just rename the pid file to cswsendmail.pid or whatever. Use whatever would be used in the SMF "short" definition for the demon. From phil at bolthole.com Fri Oct 9 03:00:28 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 8 Oct 2009 18:00:28 -0700 Subject: [csw-maintainers] /var/opt/csw/run in the CSWcommon package In-Reply-To: References: Message-ID: On Thu, Oct 8, 2009 at 3:54 PM, Maciej (Matchek) Blizinski wrote: > All right, I'm updating syslog-ng to use /var/run. Here's also a bit > of a documentation update: > > diff --git a/htdocs/standards/layout.shtml b/htdocs/standards/layout.shtml > ... I dont think that belongs in that section. However, I did now add a specific mention of /var/run higher up on the page. From maciej at opencsw.org Fri Oct 9 09:01:57 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 9 Oct 2009 08:01:57 +0100 Subject: [csw-maintainers] /var/opt/csw/run in the CSWcommon package In-Reply-To: References: Message-ID: On Fri, Oct 9, 2009 at 2:00 AM, Philip Brown wrote: > On Thu, Oct 8, 2009 at 3:54 PM, Maciej (Matchek) Blizinski > wrote: > >> All right, I'm updating syslog-ng to use /var/run. Here's also a bit >> of a documentation update: >> >> diff --git a/htdocs/standards/layout.shtml b/htdocs/standards/layout.shtml >> ... > > > I dont think that belongs in that section. > However, I did now add a specific mention of /var/run higher up on the page. How about this existing bit: var: Dont use this. Use /var/opt/csw instead. ...it seems to be in contradiction with "use /var/run" above. You could say "well, it's talking about /var, and not /var/run, it's not the same thing", to which I'm going to reply "do you mean it's okay if csw files are scattered across subdirectories, just because /var/whatever is not the same thing as /var?" I think the best way to put it is: "The rule of thumb is to do X. One of the known exceptions is case Y, in which you need to do Z, because of W." -- giving the rule and the exception in the same place/paragraph. Maciej From maciej at opencsw.org Fri Oct 9 10:44:29 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 9 Oct 2009 09:44:29 +0100 Subject: [csw-maintainers] Page "CSW class action utilities" edited at wiki.opencsw.org In-Reply-To: <7660c51054bd7dacc5b850f7caeddd8d@as2-1.s.wikidot.com> References: <7660c51054bd7dacc5b850f7caeddd8d@as2-1.s.wikidot.com> Message-ID: On Fri, Oct 9, 2009 at 9:12 AM, bonivart wrote: > bonivart edited the page "CSW class action utilities" at > http://wiki.opencsw.org/cswclassutils-package You updated cswclassutils to use the catalog names for files such as opt/csw/etc/pkg/foo/cswusergroup? From which version? Can we have some sort of a check so that package installs don't break? Or, is it backwards compatible? Maciej From bonivart at opencsw.org Fri Oct 9 10:54:56 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 9 Oct 2009 10:54:56 +0200 Subject: [csw-maintainers] Page "CSW class action utilities" edited at wiki.opencsw.org In-Reply-To: References: <7660c51054bd7dacc5b850f7caeddd8d@as2-1.s.wikidot.com> Message-ID: <625385e30910090154j49d457am6a5c72f91af79bd3@mail.gmail.com> On Fri, Oct 9, 2009 at 10:44 AM, Maciej (Matchek) Blizinski wrote: > On Fri, Oct 9, 2009 at 9:12 AM, bonivart wrote: >> bonivart edited the page "CSW class action utilities" at >> http://wiki.opencsw.org/cswclassutils-package > > You updated cswclassutils to use the catalog names for files such as > opt/csw/etc/pkg/foo/cswusergroup? From which version? Can we have some > sort of a check so that package installs don't break? Or, is it > backwards compatible? I only changed the /recommended/ path to use for cswusergroup configuration files. I didn't change any code in the class action script. What problems do you see? The change was to be more consistent with other use of the common name instead of the package name and that it's easily available in GAR with $(GARNAME). -- /peter From dam at opencsw.org Fri Oct 9 11:14:43 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 9 Oct 2009 11:14:43 +0200 Subject: [csw-maintainers] FYI: For your reference Message-ID: <4B161726-3FB8-459D-9BDC-E36ADF93BFEA@opencsw.org> Hi, I now mirror SpecFileExtra on the farm at /export/mirror/sfe It may give some insights when looking at the Specfiles or patches. They have other useful stuff too, like scripts/copyright-extractor which is under CDDL and may be useful for OpenCSW. And they have some interesting tweaks on CFLAGS in inlude/arch64.inc which look pretty good too. And that is the exact reason why OpenCSW must also have an open repository: For others to look and learn and not make hard patches a second time! Best regards -- Dago From dam at opencsw.org Fri Oct 9 14:05:22 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 9 Oct 2009 14:05:22 +0200 Subject: [csw-maintainers] GAR Major Change: Platform feature now activated Message-ID: <4F4D02E7-39FC-482F-AA2F-4DEB35592C14@opencsw.org> Hi, I just activated the new Platform build feature ("v2-pbuild") in GAR. It is available under the regular name gar/v2 in the repository, the old experimental branch gar/v2-build has been deleted. A simple svn update --ignore externals should be sufficient to update your tree. The new features have been documented at (see "Prototype Modifiers"). Let me know if you encounter anything unusual or feel the docs need some clarification :-) Best regards -- Dago From dam at opencsw.org Fri Oct 9 15:15:57 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 9 Oct 2009 15:15:57 +0200 Subject: [csw-maintainers] BDBs (hopefully) last update Message-ID: Hi, I got no negative feedback on BDB (apart from James who complained about db.jar in both 32/64 bit which I have removed now). If there are no complaints I will release tomorrow. If anyone forgot, here are the latest builds: Best regards -- Dago From dam at opencsw.org Fri Oct 9 15:18:36 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 9 Oct 2009 15:18:36 +0200 Subject: [csw-maintainers] Flex twice? Message-ID: <50B68BC5-E0AC-406D-9841-171BADAD936F@opencsw.org> Hi, I noticed that we have two versions of Flex: CSWflex flex CSWoflex oflex Both are 2.5.4 and from 2005 before my time. Maybe some of the old-timers remembers or is this just an artifact to be dropped? Best regards -- Dago From phil at bolthole.com Fri Oct 9 17:41:34 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 9 Oct 2009 08:41:34 -0700 Subject: [csw-maintainers] /var/opt/csw/run in the CSWcommon package In-Reply-To: References: Message-ID: On Fri, Oct 9, 2009 at 12:01 AM, Maciej (Matchek) Blizinski wrote: > On Fri, Oct 9, 2009 at 2:00 AM, Philip Brown wrote: >> On Thu, Oct 8, 2009 at 3:54 PM, Maciej (Matchek) Blizinski >> wrote: >> >>> All right, I'm updating syslog-ng to use /var/run. Here's also a bit >>> of a documentation update: >>> >>> diff --git a/htdocs/standards/layout.shtml b/htdocs/standards/layout.shtml >>> ... >> >> >> I dont think that belongs in that section. >> However, I did now add a specific mention of /var/run higher up on the page. > > How about this existing bit: > > var: Dont use this. Use /var/opt/csw instead. > > ...it seems to be in contradiction with "use /var/run" above. > > You could say "well, it's talking about /var, and not /var/run, No, it's in the subsection of "things under /opt/csw". /opt/csw/var is not /var that being said, I dont see why anyone would default to using /opt/csw/var/run. am I missing something? Things usually default to using /var/run. you have to go out of your way to force it to translate to /opt/csw/var/run ? From maciej at opencsw.org Fri Oct 9 18:28:25 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 9 Oct 2009 17:28:25 +0100 Subject: [csw-maintainers] /var/opt/csw/run in the CSWcommon package In-Reply-To: References: Message-ID: On Fri, Oct 9, 2009 at 4:41 PM, Philip Brown wrote: > On Fri, Oct 9, 2009 at 12:01 AM, Maciej (Matchek) Blizinski > wrote: >> On Fri, Oct 9, 2009 at 2:00 AM, Philip Brown wrote: >>> On Thu, Oct 8, 2009 at 3:54 PM, Maciej (Matchek) Blizinski >>> wrote: >>> >>>> All right, I'm updating syslog-ng to use /var/run. Here's also a bit >>>> of a documentation update: >>>> >>>> diff --git a/htdocs/standards/layout.shtml b/htdocs/standards/layout.shtml >>>> ... >>> >>> >>> I dont think that belongs in that section. >>> However, I did now add a specific mention of /var/run higher up on the page. >> >> How about this existing bit: >> >> var: Dont use this. Use /var/opt/csw instead. >> >> ...it seems to be in contradiction with "use /var/run" above. >> >> You could say "well, it's talking about /var, and not /var/run, > > No, it's in the subsection of "things under /opt/csw". > > /opt/csw/var is not /var I see. Perhaps it would make sense to write /opt/csw/var, when you mean /opt/csw/var. (I know it's written at the top. It's about how easy it is to read and understand.) > that being said, I dont see why anyone would default to using > /opt/csw/var/run. am I missing something? Because of the "everything is under /opt/csw" rule. > Things usually default to using /var/run. you have to go out of your > way to force it to translate to /opt/csw/var/run ? syslog-ng defaults to /var/run, but I usually don't allow packages to install anything outside /opt/csw, so I wouldn't let it use the default without a reason. Maciej From phil at bolthole.com Fri Oct 9 19:24:16 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 9 Oct 2009 10:24:16 -0700 Subject: [csw-maintainers] /var/opt/csw/run in the CSWcommon package In-Reply-To: References: Message-ID: FYI: I updated the first few pargraphs of http://www.opencsw.org/standards/layout so hopefully it is even clearer now. From phil at bolthole.com Fri Oct 9 19:26:16 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 9 Oct 2009 10:26:16 -0700 Subject: [csw-maintainers] Flex twice? In-Reply-To: <50B68BC5-E0AC-406D-9841-171BADAD936F@opencsw.org> References: <50B68BC5-E0AC-406D-9841-171BADAD936F@opencsw.org> Message-ID: On Fri, Oct 9, 2009 at 6:18 AM, Dagobert Michelsen wrote: > Hi, > > I noticed that we have two versions of Flex: > ?CSWflex ? flex > ?CSWoflex ?oflex > Both are 2.5.4 and from 2005 before my time. Maybe some of the > old-timers remembers or is this just an artifact to be dropped? huh. wierd. I thought there were two actual separate versions. But they both list the same source url. so i guess not. From james at opencsw.org Sun Oct 11 10:57:47 2009 From: james at opencsw.org (James Lee) Date: Sun, 11 Oct 2009 08:57:47 GMT Subject: [csw-maintainers] Flex twice? In-Reply-To: <50B68BC5-E0AC-406D-9841-171BADAD936F@opencsw.org> References: <50B68BC5-E0AC-406D-9841-171BADAD936F@opencsw.org> Message-ID: <20091011.8574700.2930021673@gyor.oxdrove.co.uk> On 09/10/09, 14:18:36, Dagobert Michelsen wrote regarding [csw-maintainers] Flex twice?: > I noticed that we have two versions of Flex: > CSWflex flex > CSWoflex oflex There are three. Dagobert, see if you can notify the maintainer of CSWflex-new by kicking him in the nuts. > Both are 2.5.4 and from 2005 before my time. Maybe some of the > old-timers remembers or is this just an artifact to be dropped? oflex, flex and flex_new were supposed to be because of compatibility versioning. Why I don't know, there was talk on the maintainers' list and the history of release can be see in oldpkgs. I wish for only one version that works. James. From dam at opencsw.org Sun Oct 11 11:10:06 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 11 Oct 2009 11:10:06 +0200 Subject: [csw-maintainers] Flex twice? In-Reply-To: <20091011.8574700.2930021673@gyor.oxdrove.co.uk> References: <50B68BC5-E0AC-406D-9841-171BADAD936F@opencsw.org> <20091011.8574700.2930021673@gyor.oxdrove.co.uk> Message-ID: <31EC969D-8780-4784-9B11-CB1599515370@opencsw.org> Hi James, Am 11.10.2009 um 10:57 schrieb James Lee: > On 09/10/09, 14:18:36, Dagobert Michelsen wrote > regarding > [csw-maintainers] Flex twice?: > >> I noticed that we have two versions of Flex: >> CSWflex flex >> CSWoflex oflex > > There are three. Dagobert, see if you can notify the maintainer of > CSWflex-new by kicking him in the nuts. Done. *OUCH* >> Both are 2.5.4 and from 2005 before my time. Maybe some of the >> old-timers remembers or is this just an artifact to be dropped? > > oflex, flex and flex_new were supposed to be because of compatibility > versioning. Why I don't know, there was talk on the maintainers' list > and the history of release can be see in oldpkgs. I wish for only one > version that works. I can understand why there is flex and flex_new, but I can not understand why there are two identical versions flex and oflex. The old maintainers list is closed now that the new list became public. Ihsan, could you please send me the old mails in some format I can import? I don't want to make the same errors twice, usually... Best regards -- Dago From james at opencsw.org Sun Oct 11 11:21:23 2009 From: james at opencsw.org (James Lee) Date: Sun, 11 Oct 2009 09:21:23 GMT Subject: [csw-maintainers] Flex twice? In-Reply-To: <31EC969D-8780-4784-9B11-CB1599515370@opencsw.org> References: <50B68BC5-E0AC-406D-9841-171BADAD936F@opencsw.org> <20091011.8574700.2930021673@gyor.oxdrove.co.uk> <31EC969D-8780-4784-9B11-CB1599515370@opencsw.org> Message-ID: <20091011.9212300.1497987078@gyor.oxdrove.co.uk> On 11/10/09, 10:10:06, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Flex twice?: > >> I noticed that we have two versions of Flex: > >> CSWflex flex > >> CSWoflex oflex > > > > There are three. Dagobert, see if you can notify the maintainer of > > CSWflex-new by kicking him in the nuts. > Done. *OUCH* Impressive, you are truly a flex expert. James. From dam at opencsw.org Sun Oct 11 11:50:19 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 11 Oct 2009 11:50:19 +0200 Subject: [csw-maintainers] Flex twice? In-Reply-To: References: <50B68BC5-E0AC-406D-9841-171BADAD936F@opencsw.org> Message-ID: <3A48863F-0D0D-4D29-B6AD-B2361BE569F6@opencsw.org> Hi Phil, Am 09.10.2009 um 19:26 schrieb Philip Brown: > On Fri, Oct 9, 2009 at 6:18 AM, Dagobert Michelsen > wrote: >> I noticed that we have two versions of Flex: >> CSWflex flex >> CSWoflex oflex >> Both are 2.5.4 and from 2005 before my time. Maybe some of the >> old-timers remembers or is this just an artifact to be dropped? > > huh. wierd. I thought there were two actual separate versions. > But they both list the same source url. so i guess not. Ok then, please remove the package CSWoflex from the catalog and the mirrors. Best regards -- Dago From ihsan at opencsw.org Sun Oct 11 13:22:42 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 11 Oct 2009 13:22:42 +0200 Subject: [csw-maintainers] GAR Major Change: Platform feature now activated In-Reply-To: <4F4D02E7-39FC-482F-AA2F-4DEB35592C14@opencsw.org> References: <4F4D02E7-39FC-482F-AA2F-4DEB35592C14@opencsw.org> Message-ID: <4AD1C002.1050409@opencsw.org> Am 9.10.2009 14:05 Uhr, Dagobert Michelsen schrieb: > Let me know if you encounter anything unusual or feel the docs > need some clarification :-) I have two packages, ldns and unbound, which are build with gcc on Solaris 8, while the Solaris 10 version is built with Studio 12. Does this change has any influence to this very specific case? Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Sun Oct 11 14:00:02 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 11 Oct 2009 14:00:02 +0200 Subject: [csw-maintainers] GAR Major Change: Platform feature now activated In-Reply-To: <4AD1C002.1050409@opencsw.org> References: <4F4D02E7-39FC-482F-AA2F-4DEB35592C14@opencsw.org> <4AD1C002.1050409@opencsw.org> Message-ID: <7D96D3D3-FA0A-40E1-9549-9114E56174DC@opencsw.org> Hi Ihsan, Am 11.10.2009 um 13:22 schrieb Ihsan Dogan: > Am 9.10.2009 14:05 Uhr, Dagobert Michelsen schrieb: > >> Let me know if you encounter anything unusual or feel the docs >> need some clarification :-) > > I have two packages, ldns and unbound, which are build with gcc on > Solaris 8, while the Solaris 10 version is built with Studio 12. > > Does this change has any influence to this very specific case? Yes! Please add PACKAGING_PLATFORMS = solaris8-sparc solaris8-i386 solaris10-sparc solaris10-i386 to you Makefile. This tells GAR about all platforms you want packages built on. It may needs additional tweaking. Have you committed all your local changes? Than I'd love to take a look and allow gmake platforms to automatically build packages for all 4 platforms without intervention. Best regards -- Dago From william at wbonnet.net Sun Oct 11 18:11:32 2009 From: william at wbonnet.net (William Bonnet) Date: Sun, 11 Oct 2009 18:11:32 +0200 Subject: [csw-maintainers] Looking for old catalogs Message-ID: <4AD203B4.3090700@wbonnet.net> Hi, I have replaced the previous solution (sending email to the list with some stats) by a mysql database, and a web page displaying graphics. But i need some data to populate it. So I am looking for olds packages catalog in order to populate a statistic database. Does any of you have some ? i would need a few per month starting december 2008 (or older if i cannot found some from december). I would like to prefer to get the full catalog, bu just a list of available packages would be ok (i already all the lists starting from march, so no need to resend it). Thanks in advance cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From bonivart at opencsw.org Sun Oct 11 20:40:29 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 11 Oct 2009 20:40:29 +0200 Subject: [csw-maintainers] cswclassutils/initsmf defaults Message-ID: <625385e30910111140m4d564cb0qb1aab34bb351dbf3@mail.gmail.com> I'm glad many of you use the cswclassutils package but I notice that you often specify the defaults in the init script you provide. These are the defaults and they do not need to be specified: #RC_KNUM 20 # Number used for kill script symlink, e.g. K20cswfoo #RC_SNUM 80 # Number used for start script symlink, e.g. S80cswfoo #RC_KLEV 0,1,2,S # Run levels that should have a kill script symlink #RC_SLEV 3 # Run levels that should have a start script symlink #FMRI network # FMRI path for service (S10+), default is /network. # # Changing the value here, yields a generated FMRI of # # "svc:/somethingelse/cswfoo:default" #AUTOENABLE yes # If set to no will not enable service regardless of # local csw.conf, use when a package needs setup before # being useful, would otherwise leave service in # maintenance mode #MANIFEST /absolute/path/to/manifest # If set, use this manifest instead # of autogenerating one (default) You only need to specify those options where you want something different than the default. It's of course (technically) OK to specify the defaults anyway if you think it makes it more clear. Wiki: http://wiki.opencsw.org/cswclassutils-package -- /peter From maciej at opencsw.org Mon Oct 12 15:10:18 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 12 Oct 2009 14:10:18 +0100 Subject: [csw-maintainers] GAR: building a package from loose files, with checksumming Message-ID: I was trying to create a GAR build which would be done from loose files, with checksumming. Image this existing directory structure: $ tree . `-- opt `-- csw |-- bin | `-- foo `-- share `-- foo |-- README `-- examples `-- doing-it-right.conf (In other words: loose files which are already in the corresponding directories.) Suppose I'd like to create a GAR package from such files. I'd like to calculate a checksum of each single file. I was thinking about doing something like this, although it only allows to create a single checksum for all the files: - create a fake download file in DESTDIR - override its download target: $(DOWNLOADDIR)/fakefile: ...copy the tree structure... ...touch $(DOWNLOADDIR)/fakefile to make GAR happy; optionally put the checksums of all the copied files in there. - in the extract step, copy the tree structure from $(DOWNLOADDIR) to $(WORKSRC). - skip the build step - in the install step, copy files once again from $(WORKSRC) to $(DESTDIR) That's my take, and it hardly works. Dago, how would you go about it? Maciej From phil at bolthole.com Mon Oct 12 17:17:20 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 12 Oct 2009 08:17:20 -0700 Subject: [csw-maintainers] Flex twice? In-Reply-To: <3A48863F-0D0D-4D29-B6AD-B2361BE569F6@opencsw.org> References: <50B68BC5-E0AC-406D-9841-171BADAD936F@opencsw.org> <3A48863F-0D0D-4D29-B6AD-B2361BE569F6@opencsw.org> Message-ID: On Sun, Oct 11, 2009 at 2:50 AM, Dagobert Michelsen wrote: > > > Ok then, please remove the package CSWoflex from the catalog and the > mirrors. > change batched. From dam at opencsw.org Mon Oct 12 17:21:40 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 12 Oct 2009 17:21:40 +0200 Subject: [csw-maintainers] Flex twice? In-Reply-To: References: <50B68BC5-E0AC-406D-9841-171BADAD936F@opencsw.org> <3A48863F-0D0D-4D29-B6AD-B2361BE569F6@opencsw.org> Message-ID: <0058D8D8-059C-4CD6-983B-471F200374DD@opencsw.org> Hi Phil, Am 12.10.2009 um 17:17 schrieb Philip Brown: > On Sun, Oct 11, 2009 at 2:50 AM, Dagobert Michelsen > wrote: >> Ok then, please remove the package CSWoflex from the catalog and the >> mirrors. > > change batched. I hope you also merged in the bugs from oflex, yes? Best regards -- Dago From phil at bolthole.com Mon Oct 12 17:23:07 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 12 Oct 2009 08:23:07 -0700 Subject: [csw-maintainers] GAR: building a package from loose files, with checksumming In-Reply-To: References: Message-ID: On Mon, Oct 12, 2009 at 6:10 AM, Maciej (Matchek) Blizinski wrote: > I was trying to create a GAR build which would be done from loose > files, with checksumming. > [....] > > Suppose I'd like to create a GAR package from such files. I'd like to > calculate a checksum of each single file. eeeesh.. why would you want to do this with the gar "build" framework? The easiest way to do this otherwise, (if you already know the locations), is to pre-generate a prototype file, and then use createpkg. Or even if you want to do it "dynamically"... (echo "i pkginfo" ; [output file list] | pkgproto) >prototype createpkg -r / (or if appropriate, createpkg -b /opt/csw for relocatable pkg) Apologies if I dont get the syntax EXACTLY right; the above is typed from memory without testing. but it shoudl be pretty much what is needed. From phil at bolthole.com Mon Oct 12 17:27:07 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 12 Oct 2009 08:27:07 -0700 Subject: [csw-maintainers] Flex twice? In-Reply-To: <0058D8D8-059C-4CD6-983B-471F200374DD@opencsw.org> References: <50B68BC5-E0AC-406D-9841-171BADAD936F@opencsw.org> <3A48863F-0D0D-4D29-B6AD-B2361BE569F6@opencsw.org> <0058D8D8-059C-4CD6-983B-471F200374DD@opencsw.org> Message-ID: On Mon, Oct 12, 2009 at 8:21 AM, Dagobert Michelsen wrote: > > I hope you also merged in the bugs from oflex, yes? > > Bah. no i just made it hidden. didnt check for bugs. but.. there doesnt seem to be any. From dam at opencsw.org Mon Oct 12 20:10:20 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 12 Oct 2009 20:10:20 +0200 Subject: [csw-maintainers] GAR: building a package from loose files, with checksumming In-Reply-To: References: Message-ID: <141D5D6D-9C60-4F95-BC9D-A593E81E6F77@opencsw.org> Hi Maciej, Am 12.10.2009 um 15:10 schrieb Maciej (Matchek) Blizinski: > I was trying to create a GAR build which would be done from loose > files, with checksumming. Image this existing directory structure: > > $ tree > . > `-- opt > `-- csw > |-- bin > | `-- foo > `-- share > `-- foo > |-- README > `-- examples > `-- doing-it-right.conf > > (In other words: loose files which are already in the corresponding > directories.) Ok, for now I'll stick to /usr/bin/ls and /usr/share/man/man1/ls.1, ok? > Suppose I'd like to create a GAR package from such files. I'd like to > calculate a checksum of each single file. > > I was thinking about doing something like this, although it only > allows to create a single checksum for all the files: > > - create a fake download file in DESTDIR > - override its download target: > $(DOWNLOADDIR)/fakefile: > ...copy the tree structure... > ...touch $(DOWNLOADDIR)/fakefile to make GAR happy; optionally put > the checksums of all the copied files in there. These steps are very valid and useful. I use it in automake to put the list of versions in the README: > $(DOWNLOADDIR)/README.CSW: > @echo " ==> Generating README.CSW" > @(exec > > $@; \ > echo "This package contains the following automake > versions:"; \ > for VERSION in $(MODULATIONS_GARVERSION); > do \ > echo " automake-$ > $VERSION"; \ > done) However, as the files are already there you can use a more elegant method wel'll see below. > - in the extract step, copy the tree structure from $(DOWNLOADDIR) to > $(WORKSRC). > - skip the build step > - in the install step, copy files once again from $(WORKSRC) to $ > (DESTDIR) > > That's my take, and it hardly works. Dago, how would you go about it? Here's my small example: > GARNAME = example > GARVERSION = 1.0 > CATEGORIES = apps > > DESCRIPTION = An example > > FILES = /usr/bin/ls /usr/share/man/man1/ls.1 This is the list of files you want. > MASTER_SITES = $(sort $(addprefix file://,$(dir $(FILES)))) Every data source from MASTER_SITES is searched for the files in DISTFILES. It is in URL syntax, the sort is only to make the dirs unique if you have multiple files from one dir (essentially not needed here). > DISTFILES = $(notdir $(FILES)) There files get downloaded. Only the files as the data sources are multiplexed as above. It would be nice to specify a location per file, but historically it is not in there. AFAIK Ben requested that for his zillion XML-sources-sites. > CONFIGURE_SCRIPTS = > BUILD_SCRIPTS = > INSTALL_SCRIPTS = custom > TEST_SCRIPTS = > > include gar/category.mk > > install-custom: > $(foreach F,$(FILES),ginstall -d $(DESTDIR)$(dir $F) && > ginstall $(WORKDIR)/$(notdir $F) $(DESTDIR)$(dir $F);) > @$(MAKECOOKIE) The install is pretty straight. Please note that install should *always* copy from WORKDIR (or WORKSRC) to DESTDIR because that is the flow of the data, instead of taking from DOWNLOADDIR and installing to PKGROOT or something! Best regards -- Dago From trygvis at opencsw.org Tue Oct 13 13:02:53 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Tue, 13 Oct 2009 13:02:53 +0200 Subject: [csw-maintainers] ncmpc-0.15 in testing Message-ID: <4AD45E5D.6080106@opencsw.org> Changes: o Upgrading to 0.15 which is a significant jump from 0.11.1 o Fixing bug #3382: "Depend on CSWggettextrt" -- Trygve From maciej at opencsw.org Tue Oct 13 14:58:20 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 13 Oct 2009 13:58:20 +0100 Subject: [csw-maintainers] GAR: building a package from loose files, with checksumming In-Reply-To: <141D5D6D-9C60-4F95-BC9D-A593E81E6F77@opencsw.org> References: <141D5D6D-9C60-4F95-BC9D-A593E81E6F77@opencsw.org> Message-ID: Thanks Dago! Your example works. I bumped against another problem: umask setting. My default umask setting is 027. I think it influences GAR somehow, take a look at this. I have an install directory with the correct permissions: $ ls -l (...)/loose-files/trunk/work/install-isa-i386/opt/csw/include/curses.h -rwxr-xr-x 1 blizinski eng 41408 Oct 13 13:40 (...)/loose-files/trunk/work/install-isa-i386/opt/csw/include/curses.h This is OK: The file is world-readable. Let's take a look at the prototype: $ cat work/build-global/CSWloosefilesexa.prototype-i386 f none /opt/csw/include/curses.h 0750 root bin i depend=CSWloosefilesexa.depend i pkginfo=CSWloosefilesexa.pkginfo The file isn't world-readable! Are there any intermediate file copying steps involved? If so, perhaps "gcp --preserve" could be used to prevent umask from affecting the outcome? Maciej From maciej at opencsw.org Tue Oct 13 15:46:01 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 13 Oct 2009 14:46:01 +0100 Subject: [csw-maintainers] GAR: building a package from loose files, with checksumming In-Reply-To: <141D5D6D-9C60-4F95-BC9D-A593E81E6F77@opencsw.org> References: <141D5D6D-9C60-4F95-BC9D-A593E81E6F77@opencsw.org> Message-ID: On Mon, Oct 12, 2009 at 7:10 PM, Dagobert Michelsen wrote: > Here's my small example: > >> GARNAME = example >> GARVERSION = 1.0 >> CATEGORIES = apps >> >> DESCRIPTION = An example >> >> FILES = /usr/bin/ls /usr/share/man/man1/ls.1 > > This is the list of files you want. > >> MASTER_SITES = $(sort $(addprefix file://,$(dir $(FILES)))) > > Every data source from MASTER_SITES is searched for the files in DISTFILES. > It is in URL syntax, the sort is only to make the dirs unique if you have > multiple files from one dir (essentially not needed here). > >> DISTFILES = $(notdir $(FILES)) What if there are two files with the same name, in different directories? Say: /opt/csw/share/foo/foo.conf /opt/csw/share/foo/examples/foo.conf My guess is that one of the files will be duplicated. Maciej From dam at opencsw.org Tue Oct 13 17:54:14 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 13 Oct 2009 17:54:14 +0200 Subject: [csw-maintainers] GAR: building a package from loose files, with checksumming In-Reply-To: References: <141D5D6D-9C60-4F95-BC9D-A593E81E6F77@opencsw.org> Message-ID: <7097ACF4-6EBD-4068-840B-7E1A342E0ADD@opencsw.org> Hi Maciej, Am 13.10.2009 um 15:46 schrieb Maciej (Matchek) Blizinski: > On Mon, Oct 12, 2009 at 7:10 PM, Dagobert Michelsen > wrote: >> Here's my small example: >> >>> GARNAME = example >>> GARVERSION = 1.0 >>> CATEGORIES = apps >>> >>> DESCRIPTION = An example >>> >>> FILES = /usr/bin/ls /usr/share/man/man1/ls.1 >> >> This is the list of files you want. >> >>> MASTER_SITES = $(sort $(addprefix file://,$(dir $(FILES)))) >> >> Every data source from MASTER_SITES is searched for the files in >> DISTFILES. >> It is in URL syntax, the sort is only to make the dirs unique if >> you have >> multiple files from one dir (essentially not needed here). >> >>> DISTFILES = $(notdir $(FILES)) > > What if there are two files with the same name, in different > directories? Say: > > /opt/csw/share/foo/foo.conf > /opt/csw/share/foo/examples/foo.conf > > My guess is that one of the files will be duplicated. Yes. And it must be that way because the files are checksummed without path. If you want that you should really think about making a tar.gz first and just copy that over. Best regards -- Dago From dam at opencsw.org Tue Oct 13 18:03:03 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 13 Oct 2009 18:03:03 +0200 Subject: [csw-maintainers] GAR: building a package from loose files, with checksumming In-Reply-To: References: <141D5D6D-9C60-4F95-BC9D-A593E81E6F77@opencsw.org> Message-ID: Hi Maciej, Am 13.10.2009 um 14:58 schrieb Maciej (Matchek) Blizinski: > I bumped against another problem: umask setting. My default umask > setting is 027. I think it influences GAR somehow, take a look at > this. I have an install directory with the correct permissions: > > $ ls -l (...)/loose-files/trunk/work/install-isa-i386/opt/csw/ > include/curses.h > -rwxr-xr-x 1 blizinski eng 41408 Oct 13 13:40 > (...)/loose-files/trunk/work/install-isa-i386/opt/csw/include/curses.h > > This is OK: The file is world-readable. Let's take a look at the > prototype: > > $ cat work/build-global/CSWloosefilesexa.prototype-i386 > f none /opt/csw/include/curses.h 0750 root bin > i depend=CSWloosefilesexa.depend > i pkginfo=CSWloosefilesexa.pkginfo > > The file isn't world-readable! Are there any intermediate file copying > steps involved? If so, perhaps "gcp --preserve" could be used to > prevent umask from affecting the outcome? The problem was caused by pax applying the umask. I have now changed this by adding '-p e' (preserve everything) to all pax invocations on r6854. Thanks for the report! -- Dago From maciej at opencsw.org Tue Oct 13 18:20:45 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 13 Oct 2009 17:20:45 +0100 Subject: [csw-maintainers] GAR: Checking for certain variables inside a category file Message-ID: I'm implementing a new category for gar, to create packages from loose files. The usage is going to be: CATEGORIES = loose FILES = ... LOCAL_SRC = ... include gar/category.mk I'd like to implement checks for FILES and LOCAL_SRC: if undefined, I want GAR to display an error with an explanation. I need to do this inside a target. Which target to use? Maciej From dam at opencsw.org Tue Oct 13 18:28:18 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 13 Oct 2009 18:28:18 +0200 Subject: [csw-maintainers] GAR: Checking for certain variables inside a category file In-Reply-To: References: Message-ID: <8E8DD0EF-5E7A-4F06-8EE6-3A5320CE279D@opencsw.org> Hi Maciej, Am 13.10.2009 um 18:20 schrieb Maciej (Matchek) Blizinski: > I'm implementing a new category for gar, to create packages from loose > files. The usage is going to be: > > CATEGORIES = loose > FILES = ... > LOCAL_SRC = ... > > include gar/category.mk > > I'd like to implement checks for FILES and LOCAL_SRC: if undefined, I > want GAR to display an error with an explanation. I need to do this > inside a target. Which target to use? No. You can just put ifeq ($(FILES),) $(error Please set FILE to ...) endif in your categories/loose/category.mk. Or are there other reasons you want to do that inside a target? Best regards -- Dago From maciej at opencsw.org Tue Oct 13 18:38:55 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 13 Oct 2009 17:38:55 +0100 Subject: [csw-maintainers] GAR: Checking for certain variables inside a category file In-Reply-To: <8E8DD0EF-5E7A-4F06-8EE6-3A5320CE279D@opencsw.org> References: <8E8DD0EF-5E7A-4F06-8EE6-3A5320CE279D@opencsw.org> Message-ID: On Tue, Oct 13, 2009 at 5:28 PM, Dagobert Michelsen wrote: >> I'd like to implement checks for FILES and LOCAL_SRC: if undefined, I >> want GAR to display an error with an explanation. I need to do this >> inside a target. Which target to use? > > No. You can just put > > ifeq ($(FILES),) > $(error Please set FILE to ...) > endif > > in your categories/loose/category.mk. Or are there other reasons > you want to do that inside a target? No, no other reasons. My code looks like this: http://dpaste.com/106704/ I'm getting this error: gar/categories/loose/category.mk:12: *** commands commence before first target. Stop. Maciej From maciej at opencsw.org Tue Oct 13 18:52:01 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 13 Oct 2009 17:52:01 +0100 Subject: [csw-maintainers] GAR: Checking for certain variables inside a category file In-Reply-To: References: <8E8DD0EF-5E7A-4F06-8EE6-3A5320CE279D@opencsw.org> Message-ID: On Tue, Oct 13, 2009 at 5:38 PM, Maciej (Matchek) Blizinski wrote: > On Tue, Oct 13, 2009 at 5:28 PM, Dagobert Michelsen wrote: >>> I'd like to implement checks for FILES and LOCAL_SRC: if undefined, I >>> want GAR to display an error with an explanation. I need to do this >>> inside a target. Which target to use? >> >> No. You can just put >> >> ifeq ($(FILES),) >> $(error Please set FILE to ...) >> endif >> >> in your categories/loose/category.mk. Or are there other reasons >> you want to do that inside a target? > > No, no other reasons. My code looks like this: > > http://dpaste.com/106704/ > > I'm getting this error: > > gar/categories/loose/category.mk:12: *** commands commence before > first target. ?Stop. This code works correctly: http://dpaste.com/106711/ ...but I'd rather avoid overriding the pre-fetch target inside a category file. I suspect that pre-fetch is meant to be set inside the package-specific Makefile. Maciej From dam at opencsw.org Tue Oct 13 19:03:29 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 13 Oct 2009 19:03:29 +0200 Subject: [csw-maintainers] GAR: Checking for certain variables inside a category file In-Reply-To: References: <8E8DD0EF-5E7A-4F06-8EE6-3A5320CE279D@opencsw.org> Message-ID: <6571CF03-1DFF-428B-92A8-0DB97B30B687@opencsw.org> Hi Maciej, Am 13.10.2009 um 18:38 schrieb Maciej (Matchek) Blizinski: > On Tue, Oct 13, 2009 at 5:28 PM, Dagobert Michelsen > wrote: >>> I'd like to implement checks for FILES and LOCAL_SRC: if >>> undefined, I >>> want GAR to display an error with an explanation. I need to do this >>> inside a target. Which target to use? >> >> No. You can just put >> >> ifeq ($(FILES),) >> $(error Please set FILE to ...) >> endif >> >> in your categories/loose/category.mk. Or are there other reasons >> you want to do that inside a target? > > No, no other reasons. My code looks like this: > > http://dpaste.com/106704/ > > I'm getting this error: > > gar/categories/loose/category.mk:12: *** commands commence before > first target. Stop. It means > This means the first thing in the makefile seems to be part of a > command script: it begins with a TAB character and doesn't appear to > be a legal make command (such as a variable assignment). Command > scripts must always be associated with a target. You have plenty of rules before this in your included gar.mk. Just remove the tab before the $(error). Take a look at gar.mk where I do exact what you want: > ifneq ($(abspath /),/) > $(error Your version of 'make' is too old: $(MAKE_VERSION). Please > make sure you are using at least 3.81) > endif Best regards -- Dago From maciej at opencsw.org Tue Oct 13 21:21:59 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 13 Oct 2009 20:21:59 +0100 Subject: [csw-maintainers] GAR: Adding own modifications to the categories Message-ID: I'm working on building in-house packages using GAR. There are bits of the local configuration that my packages could share, for instance common prefix (different from /opt/csw or /usr or /usr/local). I would like to do something along the lines of creating a category, but I don't think you can assign two categories to one package. Dago, how would you go about it? Create an additional include file and add a reference in each Makefile? For instance: (...) include /opt/csw/src/gar/v2/category.mk include /opt/myown/src/gar/localtweaks.mk ...or do something else? Maciej From maciej at opencsw.org Tue Oct 13 21:25:19 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 13 Oct 2009 20:25:19 +0100 Subject: [csw-maintainers] Packaged version of GAR Message-ID: There is a GAR build for GAR, it currently builds gar-6856,REV=2009.10.13.19.17-SunOS5.10-all-CSW.pkg.gz, I've built that and I'm using it to distribute GAR internally. But it bothers me that it hasn't been released yet, I'd like it to be in the official repository, if possible. Can we have it released? Maciej From phil at bolthole.com Tue Oct 13 22:10:54 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 13 Oct 2009 13:10:54 -0700 Subject: [csw-maintainers] Packaged version of GAR In-Reply-To: References: Message-ID: On Tue, Oct 13, 2009 at 12:25 PM, Maciej (Matchek) Blizinski wrote: > There is a GAR build for GAR, it currently builds > gar-6856,REV=2009.10.13.19.17-SunOS5.10-all-CSW.pkg.gz, I've built > that and I'm using it to distribute GAR internally. But it bothers me > that it hasn't been released yet, I'd like it to be in the official > repository, if possible. Can we have it released? > well, that's kinda difficult, when you have not submitted it through the usual proceedures for release... please do so? (whats up with that "REV" though? wiierd...) also, perhaps it should use the new name... wait did we decide on a proper name for it yet? :-) From skayser at opencsw.org Tue Oct 13 22:37:53 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 13 Oct 2009 22:37:53 +0200 Subject: [csw-maintainers] Proposal for name of our GAR version In-Reply-To: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> References: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> Message-ID: <4AD4E521.3000706@opencsw.org> Dagobert Michelsen wrote on 07.10.2009 14:36: > I did some thinking about a name for our version of the GAR build > system and ended up with "GARISOL". This is an anagram of girasol, > which is italian for sunflower showing the affinity both to GAR > and Solaris without being an actual word - this makes searching for > it and reserving names easier. > > Feedback especially welcome! What i noticed during summer camp is that short names are handy when it comes to something that you talk about very often. OpenCSW was almost too long to pronounce in every second sentence. "GAR" equals to one syllable, "GA-RI-SOL" to three of them. Sorry, no alternative option from my side for now. Sebastian From skayser at opencsw.org Tue Oct 13 23:06:54 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 13 Oct 2009 23:06:54 +0200 Subject: [csw-maintainers] Proposal for name of our GAR version In-Reply-To: <4AD4E521.3000706@opencsw.org> References: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> <4AD4E521.3000706@opencsw.org> Message-ID: <4AD4EBEE.6060201@opencsw.org> Sebastian Kayser wrote on 13.10.2009 22:37: > Dagobert Michelsen wrote on 07.10.2009 14:36: >> I did some thinking about a name for our version of the GAR build >> system and ended up with "GARISOL". This is an anagram of girasol, >> which is italian for sunflower showing the affinity both to GAR >> and Solaris without being an actual word - this makes searching for >> it and reserving names easier. >> >> Feedback especially welcome! > > What i noticed during summer camp is that short names are handy when it > comes to something that you talk about very often. OpenCSW was almost > too long to pronounce in every second sentence. > > "GAR" equals to one syllable, "GA-RI-SOL" to three of them. As an idea "garcel: Putting together your SVR4/IPS/... parcel" With a bit of imagination the pronunciation even comes close to GARISOL (or the SOL part of it) and it is one syllable less: GAR-CEL. Sebastian From mwatters at opencsw.org Tue Oct 13 23:13:49 2009 From: mwatters at opencsw.org (Mike Watters) Date: Tue, 13 Oct 2009 16:13:49 -0500 Subject: [csw-maintainers] Proposal for name of our GAR version In-Reply-To: <4AD4E521.3000706@opencsw.org> References: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> <4AD4E521.3000706@opencsw.org> Message-ID: <4AD4ED8D.4070508@opencsw.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sebastian Kayser wrote: > Dagobert Michelsen wrote on 07.10.2009 14:36: >> I did some thinking about a name for our version of the GAR build >> system and ended up with "GARISOL". This is an anagram of girasol, >> which is italian for sunflower showing the affinity both to GAR >> and Solaris without being an actual word - this makes searching for >> it and reserving names easier. >> >> Feedback especially welcome! > > What i noticed during summer camp is that short names are handy when it > comes to something that you talk about very often. OpenCSW was almost > too long to pronounce in every second sentence. > > "GAR" equals to one syllable, "GA-RI-SOL" to three of them. > > Sorry, no alternative option from my side for now. > > Sebastian > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers I vote for mGAR short, sweet, easy to type or PBC ( Package Builder - CSW) - -- ~Mike "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." --> Albert Einstein 1879 - 1955 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrU7Y0ACgkQLrhmsXMSLxfbHQCgv4vPgPcqn5i+FAoO4dWn90Lm ZnEAoIOlm/M3bc3E37w9SesnNEjauQaG =0/R1 -----END PGP SIGNATURE----- From maciej at opencsw.org Tue Oct 13 23:34:57 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 13 Oct 2009 22:34:57 +0100 Subject: [csw-maintainers] Proposal for name of our GAR version In-Reply-To: <4AD4ED8D.4070508@opencsw.org> References: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> <4AD4E521.3000706@opencsw.org> <4AD4ED8D.4070508@opencsw.org> Message-ID: To sum up, we've got (in alphabetical order): Garcel Gardis Garis Garisol Garland Garrigue Garrison Garvey mGAR PBC (Package Builder for CSW) How about putting it to the vote? From william at wbonnet.net Wed Oct 14 00:28:42 2009 From: william at wbonnet.net (William Bonnet) Date: Wed, 14 Oct 2009 00:28:42 +0200 Subject: [csw-maintainers] Proposal for name of our GAR version In-Reply-To: References: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> <4AD4E521.3000706@opencsw.org> <4AD4ED8D.4070508@opencsw.org> Message-ID: <4AD4FF1A.3020603@wbonnet.net> Hi > To sum up, we've got (in alphabetical order): > > Garcel > Gardis > Garis > Garisol > Garland > Garrigue > Garrison > Garvey > mGAR > PBC (Package Builder for CSW) > > How about putting it to the vote? > Sure I suppose something like TBSFKAG ? (The Build System Formerly Known As Gar) cannot take part to the constest ;) Yep it's time to go to bed ! cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From bwalton at opencsw.org Wed Oct 14 02:57:04 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 13 Oct 2009 20:57:04 -0400 Subject: [csw-maintainers] stable release? Message-ID: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> Hi All, I haven't been involved with the drum banging for a stable release (or the discussions surrounding it). For the most part, I'm able and happy to run from current/ on my systems. I have a friend that isn't so fortunate and is locked to stable releases for his boxes. Is there any progress in this area? What are the current stumbling blocks? Should we set some sort of goal to work towards where we can know that the current package set is 'clean' enough to mark as stable? What would such a milestone look like? 0 critical bugs, From bwalton at opencsw.org Wed Oct 14 16:34:42 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 14 Oct 2009 10:34:42 -0400 Subject: [csw-maintainers] GAR tweak Message-ID: <1255530405-sup-7736@ntdws12.chass.utoronto.ca> Hi All, I just committed a change to GAR (garisol, tbsfkag ) that adds support for two new variables: ETCSERVICES: a list of files that contain entries destined to be added to /etc/services INETDCONF: a list of files that define (one per file) services that should be added to inetd.conf (or svcs on 10+). Documentation is available on the wiki: http://wiki.opencsw.org/cswclassutils-package The support in cswclassutils is pending still, but should be available soon. I also rearranged the order in which SPKG_CLASSES is handled to see cswinitsmf get its place at the end of the list as it once had. cswinetd is second last. Both of these could depend on having binaries and configs in place before they get enabled (depending on csw.conf), and as such need to be at the end. Please let me know if you encounter any issues with this change. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Wed Oct 14 17:11:30 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 14 Oct 2009 16:11:30 +0100 Subject: [csw-maintainers] stable release? In-Reply-To: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Oct 14, 2009 at 1:57 AM, Ben Walton wrote: > Is there any progress in this area? ?What are the current stumbling > blocks? ?Should we set some sort of goal to work towards where we can > know that the current package set is 'clean' enough to mark as stable? > What would such a milestone look like? ?0 critical bugs, bugs? ?Release when all the bdb stuff is sorted out? ?Release > 'sometime' next month? There is a wiki page which describes proposed automated release and 4 proposed tiers: http://wiki.opencsw.org/automated-release-process - experimental (like in debian) - testing (equiv. to debian unstable) - current (equiv. to debian testing) - stable (like in debian) I suggested that promotions from testing to current and from current to stable could be done periodically (quarterly?), as snapshots. Bug and security fixed would be promoted bypassing the periodic schedule. Thoughts? Maciej From maciej at opencsw.org Wed Oct 14 17:24:04 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 14 Oct 2009 16:24:04 +0100 Subject: [csw-maintainers] Anyone wants to update wxWidgets? In-Reply-To: <20090923.11441600.3790365392@gyor.oxdrove.co.uk> References: <625385e30908200922j40df818cn24ef7b7bda28c609@mail.gmail.com> <1251551183-sup-4494@ntdws12.chass.utoronto.ca> <1251678005-sup-226@ntdws12.chass.utoronto.ca> <20090923.11441600.3790365392@gyor.oxdrove.co.uk> Message-ID: On Wed, Sep 23, 2009 at 12:44 PM, James Lee wrote: > On 23/09/09, 12:38:15, Maciej "(Matchek)" Blizinski > wrote regarding Re: [csw-maintainers] Anyone wants to update wxWidgets?: > >> One more question: If two versions of a library are installed on one >> system, which one is being used during linking? > > The one pointed to by (or that is) .so > > /opt/csw/lib/libjpeg.so.62.0.0 > /opt/csw/lib/libjpeg.so.62=libjpeg.so.62.0.0 > /opt/csw/lib/libjpeg.so.7.0.0 > /opt/csw/lib/libjpeg.so.7=libjpeg.so.7.0.0 > /opt/csw/lib/libjpeg.so=libjpeg.so.7.0.0 > > at link libjpeg.so uses .so.7 not .62 > > > SONAME is used at run time. Thanks for the clarification. It makes sense to me now. I've got a package with both 0.2.0 and 0.6.0 in it. I compared it with the 2.8.5 version of the package: http://dpaste.com/107154/ It doesn't seem right. There are three files that are missing from my 2.8.5, that are present in the 2.8.5 from the current catalog: -/opt/csw/lib/libwx_gtk2u-2.8.so --> libwx_gtk2u-2.8.so.0 -/opt/csw/lib/libwx_gtk2u-2.8.so.0 --> libwx_gtk2u-2.8.so.0.2.0 -/opt/csw/lib/libwx_gtk2u-2.8.so.0.2.0 I checked it -- those files don't get created in my 2.8.5. After the compilation is finished, they just aren't there. There are also additional shared objects: http://dpaste.com/107157/ +/opt/csw/lib/libwx_baseu-2.8.so --> libwx_baseu-2.8.so.0 +/opt/csw/lib/libwx_baseu-2.8.so.0 --> libwx_baseu-2.8.so.0.6.0 +/opt/csw/lib/libwx_baseu-2.8.so.0.2.0 +/opt/csw/lib/libwx_baseu-2.8.so.0.6.0 +/opt/csw/lib/libwx_baseu_net-2.8.so --> libwx_baseu_net-2.8.so.0 +/opt/csw/lib/libwx_baseu_net-2.8.so.0 --> libwx_baseu_net-2.8.so.0.6.0 +/opt/csw/lib/libwx_baseu_net-2.8.so.0.2.0 +/opt/csw/lib/libwx_baseu_net-2.8.so.0.6.0 +/opt/csw/lib/libwx_baseu_xml-2.8.so --> libwx_baseu_xml-2.8.so.0 +/opt/csw/lib/libwx_baseu_xml-2.8.so.0 --> libwx_baseu_xml-2.8.so.0.6.0 +/opt/csw/lib/libwx_baseu_xml-2.8.so.0.2.0 +/opt/csw/lib/libwx_baseu_xml-2.8.so.0.6.0 ...which aren't there in 2.8.5. Is my 2.8.5 from the original maintainer's 2.8.5? Or is it something in the compilation options? (wxwidgets have a lot of them). * * * It looks like it might be the question of setting --enable-monolithic. It isn't the default for wxwidgets. Should should be used: the library default or the previous package's setting? Maciej From bwalton at opencsw.org Wed Oct 14 18:38:19 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 14 Oct 2009 12:38:19 -0400 Subject: [csw-maintainers] stable release? In-Reply-To: References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> Message-ID: <1255538113-sup-8465@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Wed Oct 14 11:11:30 -0400 2009: > I suggested that promotions from testing to current and from current > to stable could be done periodically (quarterly?), as snapshots. Bug > and security fixed would be promoted bypassing the periodic schedule. > > Thoughts? Overall, I like this, and I think that my only hesitations on the current draft are related to technical workflow issues (eg: tagging a release and then having it rejected leads to...?). These can certainly be handled. The overall plan/flow looks sound. So, apart from the automation tools required, what is preventing us from implementing this with manual methods now? Can we agree on a point at which we'd be happy to carve off a new stable and begin this process? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Wed Oct 14 18:59:19 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 14 Oct 2009 09:59:19 -0700 Subject: [csw-maintainers] stable release? In-Reply-To: <1255538113-sup-8465@ntdws12.chass.utoronto.ca> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Oct 14, 2009 at 9:38 AM, Ben Walton wrote: > > So, apart from the automation tools required, what is preventing us > from implementing this with manual methods now? responsability. It takes someone, or sometimes, with both a large chunk of time to commit, AND someone who is incredibly quality concious, to commit to taking on responsability for this. Otherwise, the result is not "stable", but merely a snapshot. We have not had anyone fitting that description speak up to volunteer taking on that responsability. From bwalton at opencsw.org Wed Oct 14 19:08:05 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 14 Oct 2009 13:08:05 -0400 Subject: [csw-maintainers] stable release? In-Reply-To: References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> Message-ID: <1255539893-sup-1957@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Wed Oct 14 12:59:19 -0400 2009: > Otherwise, the result is not "stable", but merely a snapshot. Your point is taken, but I'm more interested in defining our criteria for what separates 'stable' from 'snapshot' for the purposes of advancing the discussion. When we've agreed what our basis of quality is, people will be in a better situation to determine if they (or a small group) can tackle the responsibility of enforcing the quality we've defined as our benchmark. An elderly relative used to say (paraphrased): "Only people in the army volunteer for missions before they know what the mission consists of." -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Wed Oct 14 19:27:08 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 14 Oct 2009 18:27:08 +0100 Subject: [csw-maintainers] Anyone wants to update wxWidgets? In-Reply-To: References: <625385e30908200922j40df818cn24ef7b7bda28c609@mail.gmail.com> <1251551183-sup-4494@ntdws12.chass.utoronto.ca> <1251678005-sup-226@ntdws12.chass.utoronto.ca> <20090923.11441600.3790365392@gyor.oxdrove.co.uk> Message-ID: One more problem: It doesn't compile it on build8s, while it does on my local machine at work. Here's what happens on build8s: checking for GTK+ - version >= 2.0.0... no *** Could not run GTK+ test program, checking why... *** The test program failed to compile or link. See the file config.log for the *** exact error that occured. This usually means GTK+ is incorrectly installed. configure: error: The development files for GTK+ were not found. For GTK+ 2, please ensure that pkg-config is in the path and that gtk+-2.0.pc is installed. For GTK+ 1.2 please check that gtk-config is in the path, and that the version is 1.2.3 or above. Also check that the libraries returned by 'pkg-config gtk+-2.0 --libs' or 'gtk-config --libs' are in the LD_LIBRARY_PATH or equivalent. gmake[1]: *** [configure-work/solaris8-sparc/build-isa-sparcv8-garversion-2.8.5/wxWidgets-2.8.5/configure] Error 1 gmake[1]: Leaving directory `/home/maciej/src/opencsw/pkg/wxwidgets/trunk' gmake: *** [merge-isa-sparcv8-garversion-2.8.5] Error 2 Let's see what is my PKG_CONFIG_PATH: maciej at build8s [build8s]:~/src/opencsw/pkg/wxwidgets/trunk > gmake modenv | grep PKG_CONFIG PKG_CONFIG_PATH = /opt/csw/lib/pkgconfig:/opt/csw/X11/lib/pkgconfig PKG_CONFIG_PATH = /opt/csw/lib/pkgconfig:/opt/csw/X11/lib/pkgconfig Using this PKG_CONFIG_PATH to check the command that looks for gtk+2.0.pc: maciej at build8s [build8s]:~/src/opencsw/pkg/wxwidgets/trunk > PKG_CONFIG_PATH=/opt/csw/lib/pkgconfig:/opt/csw/X11/lib/pkgconfig pkg-config gtk+-2.0 --libs -L/opt/csw/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl It works. Strange. Looking at config.log: configure:27183: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -erroff=E_NO_EXPLICIT_TYPE_GIVEN -xO3 -xarch=v8 -fast -xstrconst -xnolibmopt -I/opt/csw/X11/include -I/usr/X11/include -I/usr/openwin/share/include -I/opt/csw/include -D_REENTRANT -D_PTHREADS -D__solaris__ -D_POSIX_PTHREAD_SEMANTICS -I/opt/csw/include/gtk-2.0 -I/opt/csw/lib/gtk-2.0/include -I/opt/csw/include/atk-1.0 -I/opt/csw/include/cairo -I/opt/csw/include/pango-1.0 -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -I/opt/csw/include/pixman-1 -I/opt/csw/include/freetype2 -I/opt/csw/include -I/opt/csw/include/libpng12 -I/opt/csw/X11/include -I/opt/csw/X11/include -I/usr/X11/include -I/usr/openwin/share/include -I/opt/csw/include -xarch=v8 -L/opt/csw/lib -L/opt/csw/X11/lib conftest.c -lm -L/opt/csw/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lpthread -lthread -lrt -lglib-2.0 -lintl >&5 "conftest.c", line 74: warning: statement not reached Undefined first referenced symbol in file XSolarisIASetProcessInfo /usr/openwin/lib/libX11.so.4 ld: fatal: Symbol referencing errors. No output written to conftest Is it related to the recent discussions about X11 libs? Is it a common problem, and are there any common fixes? Maciej From phil at bolthole.com Wed Oct 14 20:58:08 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 14 Oct 2009 11:58:08 -0700 Subject: [csw-maintainers] stable release? In-Reply-To: <1255539893-sup-1957@ntdws12.chass.utoronto.ca> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Oct 14, 2009 at 10:08 AM, Ben Walton wrote: > > Your point is taken, but I'm more interested in defining our criteria > for what separates 'stable' from 'snapshot' for the purposes of > advancing the discussion. ?When we've agreed what our basis of quality > is, ... ok. here is, approximately stated, our historical definition of quality for stable. (which technically should be archived somewhere in the oooold archives, but here 'tis again :-) A package qualifies for stable, when ALL of the following conditions are met: 1. package has been publically released for more than T time. (T usually defined as 30 days) 2. package has no significant bugs filed against it 3. All its dependancies also meet criteria 1 and 2. This sounds simple. But in practice, it has in the past, involved a large chunk of packages sitting in "current", not actually making it into a particular date's "stable" release. Then, the more packages that are excluded, then make a potential for other packages being excluded because of dependancies, which make for more headaches for the stable release manager. Not to mention the additional headaches of going around bugging people, "Hey, fix your bugs so we can have your package released to stable"! This is not a popular position to have, to put it mildly ;-) From phil at bolthole.com Wed Oct 14 21:01:23 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 14 Oct 2009 12:01:23 -0700 Subject: [csw-maintainers] stable release? In-Reply-To: References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> Message-ID: I should mention that, when you have packages in current that have been excluded from 'stable' release,so you have to use older versions of things.... a thorough "stable release manager" then gets stuck with *TESTING* whether these older package combinations still work. Consider the following proposition: Software S, depends on Library L. It is discovered that "current" L, is not qualified for stable. So, we potentially need to release with the prior version of L. Which in theory, is binary compatible with the more recent one, so it "should" be fine. But this is supposed to be "stable". So we need to actually VERIFY that it works, rather than just make guesses and shove it out to the public. From bwalton at opencsw.org Wed Oct 14 21:15:58 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 14 Oct 2009 15:15:58 -0400 Subject: [csw-maintainers] stable release? In-Reply-To: References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> Message-ID: <1255547752-sup-1532@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Wed Oct 14 14:58:08 -0400 2009: > This sounds simple. But in practice, it has in the past, involved a > large chunk of packages sitting in "current", not actually making it > into a particular date's "stable" release. So then, for purposes of a starting marker, a helpful thing to do would be to say: as of date X, any new packages are not eligible for transition from current/ to stable/ in the next release. This would be similar to the Debian release freeze, I believe. Bug fixes are the only eligible changes to packages after the freeze. Without this freeze, there is no chance of making a stable release where all packages meet the criteria. If we were to set October 31st as the date after which new packages couldn't enter the next stable, record the current list of packages in current/ and then look at the bug list, would this be a good start? > Then, the more packages that are excluded, then make a potential for > other packages being excluded because of dependancies, which make for > more headaches for the stable release manager. Are we relying on mantis for this info? > Not to mention the additional headaches of going around bugging > people, "Hey, fix your bugs so we can have your package released to > stable"! Having users jump ship because we've Debianized our release process to a glacial pace isn't fun either! :) I don't have numbers, but I bet there are lots of shops really wondering where the stable release is at this point... I could dedicate some cycles to whip cracking if it would help. I can't (and don't want to) shoulder the entire load myself, so help from others would be appreciated. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Wed Oct 14 22:32:17 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 14 Oct 2009 13:32:17 -0700 Subject: [csw-maintainers] stable release? In-Reply-To: <1255547752-sup-1532@ntdws12.chass.utoronto.ca> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Oct 14, 2009 at 12:15 PM, Ben Walton wrote: > > > So then, for purposes of a starting marker, a helpful thing to do > would be to say: as of date X, any new packages are not eligible for > transition from current/ to stable/ in the next release. yes that is exactly what we used to do. we used to have a "quarterly freeze" time. > If we were to set October 31st as the date after which new packages > couldn't enter the next stable, record the current list of packages in > current/ and then look at the bug list, would this be a good start? yes > Are we relying on mantis for this info? yes From bonivart at opencsw.org Wed Oct 14 22:44:50 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 14 Oct 2009 22:44:50 +0200 Subject: [csw-maintainers] stable release? In-Reply-To: References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> Message-ID: <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> On Wed, Oct 14, 2009 at 10:32 PM, Philip Brown wrote: > yes that is exactly what we used to do. we used to have a "quarterly > freeze" time. That freeze also affected unstable for some reason. We were basically not being able to release anything for weeks. If were going to revive this corpse we should still be able to release to current. Also, we should ask ourselves what's the most important thing for the users? Is it really stability which we hardly can guarantee or is it just a frozen state? Many sync our mirrors from time to time with no interest in having the latest and greatest, most important to them is that every machine gets the same version. We're a small organization and to put all the work James did onto someone else, even if shared by a few, is not time well spent in my opinion. We should rethink this, not just start it up again. It died for a reason. -- /peter From phil at bolthole.com Thu Oct 15 00:57:34 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 14 Oct 2009 15:57:34 -0700 Subject: [csw-maintainers] stable release? In-Reply-To: <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> Message-ID: On Wed, Oct 14, 2009 at 1:44 PM, Peter Bonivart wrote: > > Also, we should ask ourselves what's the most important thing for the > users? Is it really stability which we hardly can guarantee or is it > just a frozen state? Different users, have different scales of importance. To some users, it is important. Ben, specifically, knows of a set of users to whom it is very important. > We're a small organization and to put all the work James did onto > someone else, even if shared by a few, is not time well spent in my > opinion. We should rethink this, not just start it up again. It died > for a reason. The only "reason" it died, is that James got tired of doing the work. Not that it isnt important to do in the first place. but to address what you also wrote: it should be possible to also allow continued release to current, during the [stable release freeze phase]. It's just a matter of implementation choices. In the last round or two, we were actually allowing it. From bwalton at opencsw.org Thu Oct 15 03:35:53 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 14 Oct 2009 21:35:53 -0400 Subject: [csw-maintainers] stable release? In-Reply-To: <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> Message-ID: <1255570524-sup-9234@ntdws12.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Wed Oct 14 16:44:50 -0400 2009: > That freeze also affected unstable for some reason. We were > basically not being able to release anything for weeks. If were > going to revive this corpse we should still be able to release to > current. I agree that a freeze shouldn't be a 'stop the world' event. You're using 'current' as we commonly do now, as in 'where Phil puts packages'? If this is still open for business during a freeze then there would need to be some intermediary (a staging area) between stable and current. It should start as a snapshot of current. Updates to the snapshot should be of only two types: 1. Update to fix open bugs on the package so it can be moved into stable. 2. Removal so packages don't go to stable. > Also, we should ask ourselves what's the most important thing for > the users? Is it really stability which we hardly can guarantee or > is it just a frozen state? Many sync our mirrors from time to time > with no interest in having the latest and greatest, most important > to them is that every machine gets the same version. I think there is merit to this view, but I also think that Phil is right too. It will be dependent on the user/site. Even though I run current/ on my own boxes, I'm always a little nervous of large updates. We've seen some fairly high visibility breakages recently that would really stink on production machines. > We're a small organization and to put all the work James did onto > someone else, even if shared by a few, is not time well spent in my > opinion. We should rethink this, not just start it up again. It died > for a reason. Suggestions? I haven't been through this before, so I'm a fresh slate in this regard. Personally, if I knew that stable/ was moving forward at a regular interval, I'd probably run most of my boxes from it, leaning toward the stability side rather than the standardized versions side. As it is, I run current since that's where I can get lots of things that I want on all my machines that aren't part of stable. One thing I'd suggest is to only aim for 2 stable releases per year. More than that and too much time is spent in freeze states, I think. As a quick straw poll, what sort of major issues are people dealing with in their packages right now that would see you personally withhold the package from a stable release? [I'm considering Phil's "offer" of pushing this forward...] Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Oct 15 09:21:35 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 15 Oct 2009 08:21:35 +0100 Subject: [csw-maintainers] GAR tweak In-Reply-To: <1255530405-sup-7736@ntdws12.chass.utoronto.ca> References: <1255530405-sup-7736@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Oct 14, 2009 at 3:34 PM, Ben Walton wrote: > I just committed a change to GAR (garisol, tbsfkag ) that adds > support for two new variables: > > ETCSERVICES: a list of files that contain entries destined to be added > ? ? ? ? ? ? to /etc/services > INETDCONF: a list of files that define (one per file) services that > ? ? ? ? ? ? should be added to inetd.conf (or svcs on 10+). > > Documentation is available on the wiki: > http://wiki.opencsw.org/cswclassutils-package Would you mind adding references to those variables in the GAR template? (pkg/template/trunk/Makefile) Maciej From maciej at opencsw.org Thu Oct 15 09:40:06 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 15 Oct 2009 08:40:06 +0100 Subject: [csw-maintainers] Where's my CSWpydistutils? Message-ID: The Python GAR Makefile refers to CSWpydistutils: PACKAGES = CSWidle CSWpython CSWpydistutils CSWpython-devel CSWpython-rt CSWpython-tk CATALOGNAME_CSWpydistutils = pydistutils PKGFILES_CSWpydistutils += $(libdir)/.*/distutils/.* ...but the distutils package isn't there in the catalog! I can't build Python packages with CSWpython and it makes me a sad panda... Maciej From bonivart at opencsw.org Thu Oct 15 10:04:21 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 15 Oct 2009 10:04:21 +0200 Subject: [csw-maintainers] stable release? In-Reply-To: <1255570524-sup-9234@ntdws12.chass.utoronto.ca> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> <1255570524-sup-9234@ntdws12.chass.utoronto.ca> Message-ID: <625385e30910150104qc228e79wc6dc249a19a63cfe@mail.gmail.com> On Thu, Oct 15, 2009 at 3:35 AM, Ben Walton wrote: > One thing I'd suggest is to only aim for 2 stable releases per year. > More than that and too much time is spent in freeze states, I think. If we can still release to current during the freeze and limit it to two per year then we have gotten somewhere. To me it's more interesting to put an extra layer before current and implement more/better testing, that should raise the quality of current. > [I'm considering Phil's "offer" of pushing this forward...] Overworked and underpaid...great offer! ;-) -- /peter From james at opencsw.org Thu Oct 15 10:50:05 2009 From: james at opencsw.org (James Lee) Date: Thu, 15 Oct 2009 08:50:05 GMT Subject: [csw-maintainers] Proposal for name of our GAR version In-Reply-To: References: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> <4AD4E521.3000706@opencsw.org> <4AD4ED8D.4070508@opencsw.org> Message-ID: <20091015.8500500.1788570355@gyor.oxdrove.co.uk> On 13/10/09, 22:34:57, Maciej "(Matchek)" Blizinski wrote regarding Re: [csw-maintainers] Proposal for name of our GAR version: > Garisol Sounds like ointment for a private area. From james at opencsw.org Thu Oct 15 10:52:11 2009 From: james at opencsw.org (James Lee) Date: Thu, 15 Oct 2009 08:52:11 GMT Subject: [csw-maintainers] stable release? In-Reply-To: References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> Message-ID: <20091015.8521100.2971713327@gyor.oxdrove.co.uk> On 14/10/09, 16:11:30, Maciej "(Matchek)" Blizinski wrote regarding Re: [csw-maintainers] stable release?: > There is a wiki page which describes proposed automated releas Automated release is not the idea. The value of stable is the QA process. From james at opencsw.org Thu Oct 15 10:53:14 2009 From: james at opencsw.org (James Lee) Date: Thu, 15 Oct 2009 08:53:14 GMT Subject: [csw-maintainers] stable release? In-Reply-To: <1255538113-sup-8465@ntdws12.chass.utoronto.ca> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> Message-ID: <20091015.8531400.1289568934@gyor.oxdrove.co.uk> On 14/10/09, 17:38:19, Ben Walton wrote regarding Re: [csw-maintainers] stable release?: > So, apart from the automation tools required, what is preventing us > from implementing this with manual methods now? Can we agree on a > point at which we'd be happy to carve off a new stable and begin this > process? It would fail and the main players already know what to do (look at your mantis reports). James. From james at opencsw.org Thu Oct 15 10:54:34 2009 From: james at opencsw.org (James Lee) Date: Thu, 15 Oct 2009 08:54:34 GMT Subject: [csw-maintainers] stable release? In-Reply-To: <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> Message-ID: <20091015.8543400.2171942468@gyor.oxdrove.co.uk> On 14/10/09, 21:44:50, Peter Bonivart wrote regarding Re: [csw-maintainers] stable release?: > On Wed, Oct 14, 2009 at 10:32 PM, Philip Brown wrote: > > yes that is exactly what we used to do. we used to have a "quarterly > > freeze" time. > That freeze also affected unstable for some reason. We were basically > not being able to release anything for weeks. If were going to revive > this corpse we should still be able to release to current. This is really a practical consideration because it takes time to test and we rely on field experiences as part of verification. Unless a package is used we get no feed back, further it's the overall combination that matters so the combination needs field time. We need additions built against the unstable build as that's the build machine state. Hence we can't have new unstable releases during the stable consideration period. If there were 1,000s beta testers we'd be all right; in effect we are using unstable users as beta testers. > Is it really stability which we hardly can guarantee or is it > just a frozen state? It's not a frozen state, it's a QAed state. It's doesn't come with a guarantee but people pay jack shit for the process. James. From james at opencsw.org Thu Oct 15 10:51:31 2009 From: james at opencsw.org (James Lee) Date: Thu, 15 Oct 2009 08:51:31 GMT Subject: [csw-maintainers] stable release? In-Reply-To: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> Message-ID: <20091015.8513100.927409174@gyor.oxdrove.co.uk> On 14/10/09, 01:57:04, Ben Walton wrote regarding [csw-maintainers] stable release?: > Is there any progress in this area? What are the current stumbling > blocks? Should we set some sort of goal to work towards where we can > know that the current package set is 'clean' enough to mark as stable? > What would such a milestone look like? 0 critical bugs, bugs? Release when all the bdb stuff is sorted out? Release > 'sometime' next month? Yes BDB has been a blocker. > If we have some sort of defined goal, we'd all be able to work toward > it. Without a defined goal... I would hope no bugs was a goal anyway but historically we know we periodically create them. The difference is not creating new ones but there is no point in calling a freeze when there are known problems like BDB unresolved. (BDB isn't the only outstanding major bug.) James. From mwatters at opencsw.org Thu Oct 15 16:26:18 2009 From: mwatters at opencsw.org (Mike Watters) Date: Thu, 15 Oct 2009 09:26:18 -0500 Subject: [csw-maintainers] Where's my CSWpydistutils? In-Reply-To: References: Message-ID: <4AD7310A.7070307@opencsw.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Maciej (Matchek) Blizinski wrote: > The Python GAR Makefile refers to CSWpydistutils: > > PACKAGES = CSWidle CSWpython CSWpydistutils CSWpython-devel > CSWpython-rt CSWpython-tk > CATALOGNAME_CSWpydistutils = pydistutils > PKGFILES_CSWpydistutils += $(libdir)/.*/distutils/.* > > ...but the distutils package isn't there in the catalog! I can't build > Python packages with CSWpython and it makes me a sad panda... > > Maciej > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers if you are looking at the Makefile in gar, you are looking at the "new" one the existing distutils is part of CSWpython-devel. once bdb is out and I get a few minutes to finish the new build I will "fix" the split up of the packages. - -- ~Mike "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." --> Albert Einstein 1879 - 1955 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrXMQoACgkQLrhmsXMSLxfCGwCg31b1Y0JPFPRHIJk+8XyC1KHT zvIAnRa51Zq2GHnyolbh9wglylf97o3h =NpaP -----END PGP SIGNATURE----- From maciej at opencsw.org Thu Oct 15 16:36:59 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 15 Oct 2009 15:36:59 +0100 Subject: [csw-maintainers] Where's my CSWpydistutils? In-Reply-To: <4AD7310A.7070307@opencsw.org> References: <4AD7310A.7070307@opencsw.org> Message-ID: On Thu, Oct 15, 2009 at 3:26 PM, Mike Watters wrote: >> ...but the distutils package isn't there in the catalog! I can't build >> Python packages with CSWpython and it makes me a sad panda... I'd like to request including distutils in the main package (CSWpython). For languages such as Python, Ruby or Perl it's a common practice to install modules or packages specific to that language. I think would be nice to safe hassle of bumping into the missing module, and then looking for the right package. Human frustration cost is higher than disk space benefit. Maciej From phil at bolthole.com Thu Oct 15 18:29:29 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 15 Oct 2009 09:29:29 -0700 Subject: [csw-maintainers] stable release? In-Reply-To: <1255570524-sup-9234@ntdws12.chass.utoronto.ca> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> <1255570524-sup-9234@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Oct 14, 2009 at 6:35 PM, Ben Walton wrote: > > One thing I'd suggest is to only aim for 2 stable releases per year. > More than that and too much time is spent in freeze states, I think. > i agree. not to mention there's less burnout, etc. "only" 2 per year, is infinitely better than 0 per year. From james at opencsw.org Thu Oct 15 18:42:32 2009 From: james at opencsw.org (James Lee) Date: Thu, 15 Oct 2009 16:42:32 GMT Subject: [csw-maintainers] stable release? In-Reply-To: References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> <1255570524-sup-9234@ntdws12.chass.utoronto.ca> Message-ID: <20091015.16423200.157874866@gyor.oxdrove.co.uk> On 15/10/09, 17:29:29, Philip Brown wrote regarding Re: [csw-maintainers] stable release?: > > One thing I'd suggest is to only aim for 2 stable releases per year. > > More than that and too much time is spent in freeze states, I think. > > > i agree. not to mention there's less burnout, etc. Not necessarily, anything changed gets more rigourous test, (no change plus no depend change means no test is needed), the longer you leave it the more there is. It also get increasingly hard to stop-gap carry over. We are facing this now, eg, if BDB screws it's not practical to carry stuff over from 18 months - it needs fixing. James. From bonivart at opencsw.org Fri Oct 16 11:06:52 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 16 Oct 2009 11:06:52 +0200 Subject: [csw-maintainers] Fwd: [csw-users] i386 libraries in mercurial for Solaris sparc In-Reply-To: References: Message-ID: <625385e30910160206v1d5a0800x3b4a0807307e3d50@mail.gmail.com> >From the users list... ---------- Forwarded message ---------- From: Torsten Gollnick Date: Fri, Oct 16, 2009 at 10:15 AM Subject: [csw-users] i386 libraries in mercurial for Solaris sparc To: users at lists.opencsw.org Hello, mercurial does not work for me on Solaris Sparc due to i386 libs. I use url=http://ibiblio.org/pub/packages/solaris/opencsw/current did pkg-get -U and pkg-get -u The package version is ?mercurial 1.3.1,REV=2009.10.03 How can I brief the maintainer? Torsten starting hg gives $ hg Traceback (most recent call last): ?File "/opt/csw/bin/hg", line 27, in ? ?mercurial.dispatch.run() ?File "/opt/csw/lib/python/site-packages/mercurial/dispatch.py", line 16, in run ? ?sys.exit(dispatch(sys.argv[1:])) ?File "/opt/csw/lib/python/site-packages/mercurial/dispatch.py", line 21, in dispatch ? ?u = _ui.ui() ?File "/opt/csw/lib/python/site-packages/mercurial/ui.py", line 35, in __init__ ? ?for f in util.rcpath(): ?File "/opt/csw/lib/python/site-packages/mercurial/util.py", line 1217, in rcpath ? ?_rcpath = os_rcpath() ?File "/opt/csw/lib/python/site-packages/mercurial/util.py", line 1193, in os_rcpath ? ?path = system_rcpath() ?File "/opt/csw/lib/python/site-packages/mercurial/posix.py", line 41, in system_rcpath ? ?'/../etc/mercurial')) ?File "/opt/csw/lib/python/site-packages/mercurial/posix.py", line 30, in rcfiles ? ?for f, kind in osutil.listdir(rcdir) ?File "/opt/csw/lib/python/site-packages/mercurial/demandimport.py", line 75, in __getattribute__ ? ?self._load() ?File "/opt/csw/lib/python/site-packages/mercurial/demandimport.py", line 47, in _load ? ?mod = _origimport(head, globals, locals) ImportError: ld.so.1: python: fatal: /opt/csw/lib/python/site-packages/mercurial/osutil.so: wrong ELF data format: ELFDATA2LSB and ?file ?/opt/csw/lib/python/site-packages/mercurial/osutil.so /opt/csw/lib/python/site-packages/mercurial/osutil.so: ?ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped The packge is Processing package instance from _______________________________________________ users mailing list users at lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/users -- /peter From dam at opencsw.org Fri Oct 16 18:20:41 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 16 Oct 2009 18:20:41 +0200 Subject: [csw-maintainers] stable release? In-Reply-To: <20091015.16423200.157874866@gyor.oxdrove.co.uk> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> <1255570524-sup-9234@ntdws12.chass.utoronto.ca> <20091015.16423200.157874866@gyor.oxdrove.co.uk> Message-ID: <2B144D45-2F2D-4DC8-AA2C-534192D8A4A0@opencsw.org> Hi, Am 15.10.2009 um 18:42 schrieb James Lee: > On 15/10/09, 17:29:29, Philip Brown wrote > regarding Re: > [csw-maintainers] stable release?: > >>> One thing I'd suggest is to only aim for 2 stable releases per year. >>> More than that and too much time is spent in freeze states, I think. >> >> i agree. not to mention there's less burnout, etc. > > Not necessarily, anything changed gets more rigourous test, (no change > plus no depend change means no test is needed), the longer you leave > it the more there is. It also get increasingly hard to stop-gap carry > over. We are facing this now, eg, if BDB screws it's not practical to > carry stuff over from 18 months - it needs fixing. Yes. Hopefully this BDB thing gets fixed tomorrow. But I replied for another reason: It would be nice to note on a package which status it is in: - untested - tested, open bugs - tested, no open bugs - ready for stable If all the dependencies are "ready for stable" too it would be ok to release. That way it would be easy to see how far away we are from a release, not only for James who of course knows this, but for the rest of us :-) Maybe we can use a field in the database for this? Best regards -- Dago From phil at bolthole.com Fri Oct 16 18:53:22 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 16 Oct 2009 09:53:22 -0700 Subject: [csw-maintainers] stable release? In-Reply-To: <2B144D45-2F2D-4DC8-AA2C-534192D8A4A0@opencsw.org> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> <1255570524-sup-9234@ntdws12.chass.utoronto.ca> <20091015.16423200.157874866@gyor.oxdrove.co.uk> <2B144D45-2F2D-4DC8-AA2C-534192D8A4A0@opencsw.org> Message-ID: On Fri, Oct 16, 2009 at 9:20 AM, Dagobert Michelsen wrote: > .... > Yes. Hopefully this BDB thing gets fixed tomorrow. But I replied for > another reason: It would be nice to note on a package which status > it is in: ... doing stable is a huge undertaking. I dont think we should be throwing extra "requests" in there, before we even have someone officially volunteering to do the BASIC work. there's more than enough work there as is. From dam at opencsw.org Fri Oct 16 19:06:07 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 16 Oct 2009 19:06:07 +0200 Subject: [csw-maintainers] stable release? In-Reply-To: References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> <1255570524-sup-9234@ntdws12.chass.utoronto.ca> <20091015.16423200.157874866@gyor.oxdrove.co.uk> <2B144D45-2F2D-4DC8-AA2C-534192D8A4A0@opencsw.org> Message-ID: Hi Phil, Am 16.10.2009 um 18:53 schrieb Philip Brown: > On Fri, Oct 16, 2009 at 9:20 AM, Dagobert Michelsen > wrote: >> .... >> Yes. Hopefully this BDB thing gets fixed tomorrow. But I replied for >> another reason: It would be nice to note on a package which status >> it is in: ... > > doing stable is a huge undertaking. > I dont think we should be throwing extra "requests" in there, before > we even have someone officially volunteering to do the BASIC work. > there's more than enough work there as is. I can't remember that we even have defined this is, besides "Q/A", but what specifically? I know James has an infrastructure with cleanroom-install-depend-checks, ldd-inspection of libs and stuff. It would be good to formalize as much as feasible what a package must actually conform to to be good for stable. Currently at least I don't know how many, let alone what packages are really broken. If James already has all the tests we should apply them routinely on the farm for all packages. And: no, "somebody must have used the package" is not the only criterium for stable. Best regards -- Dago From james at opencsw.org Fri Oct 16 21:56:45 2009 From: james at opencsw.org (James Lee) Date: Fri, 16 Oct 2009 19:56:45 GMT Subject: [csw-maintainers] stable release? In-Reply-To: <2B144D45-2F2D-4DC8-AA2C-534192D8A4A0@opencsw.org> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> <1255570524-sup-9234@ntdws12.chass.utoronto.ca> <20091015.16423200.157874866@gyor.oxdrove.co.uk> <2B144D45-2F2D-4DC8-AA2C-534192D8A4A0@opencsw.org> Message-ID: <20091016.19564500.2186435010@gyor.oxdrove.co.uk> On 16/10/09, 17:20:41, Dagobert Michelsen wrote regarding Re: [csw-maintainers] stable release?: > It would be nice to note on a package which status > it is in: > - untested > - tested, open bugs > - tested, no open bugs > - ready for stable This isn't useful to users. Users know the possible state by the place they obtain. No package is untested because clearly the maintainer will have tested prior to unstable release, both arches. One can know the bug state from bug reports. Ready for stable isn't something judged in isolation but only as a whole so isn't the property of a package. From james at opencsw.org Fri Oct 16 21:56:46 2009 From: james at opencsw.org (James Lee) Date: Fri, 16 Oct 2009 19:56:46 GMT Subject: [csw-maintainers] stable release? In-Reply-To: References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> <1255570524-sup-9234@ntdws12.chass.utoronto.ca> <20091015.16423200.157874866@gyor.oxdrove.co.uk> <2B144D45-2F2D-4DC8-AA2C-534192D8A4A0@opencsw.org> Message-ID: <20091016.19564600.3546434106@gyor.oxdrove.co.uk> On 16/10/09, 18:06:07, Dagobert Michelsen wrote regarding Re: [csw-maintainers] stable release?: > I can't remember that we even have defined this is, Yes we defined it. > besides > "Q/A", but what specifically? I know James has an infrastructure > with cleanroom-install-depend-checks, ldd-inspection of libs and > stuff. It would be good to formalize as much as feasible what a > package must actually conform to to be good for stable. > Currently at least I don't know how many, let alone what packages > are really broken. If James already has all the tests we > should apply them routinely on the farm for all packages. > And: no, "somebody must have used the package" is not the > only criterium for stable. It's not far off. The criteria are: * It installs * It works * It can be removed No surprises there and nothing too taxing I trust. "It works" is difficult to judge and you are trying to apply a automatic test which isn't possible. What is possible is to test for the reverse state and ensure it doesn't exist. For this there are some automated checks. Then the are inferences from these such as "can be upgraded from previous", (means previous installed and not the previous version), which should work according the above if the previous can be removed. Doesn't clash with another packages. Blah, blah, I think it's been said before. Note the QA is of the packaging and not of the underlying software. Note it's possible to have 2 perfect packages that don't work together. James. From maciej at opencsw.org Sat Oct 17 13:16:13 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 17 Oct 2009 12:16:13 +0100 Subject: [csw-maintainers] pysvn and the other pysvn Message-ID: Looks like we have a package name collision. I'd like to build pysvn[1], but there already is a CSWpysvn package. What do we do with this name clash, any suggestions? Maciej [1] http://pysvn.tigris.org/ From mwatters at opencsw.org Sun Oct 18 05:05:30 2009 From: mwatters at opencsw.org (Mike Watters) Date: Sat, 17 Oct 2009 22:05:30 -0500 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: References: Message-ID: <4ADA85FA.7090506@opencsw.org> On 10/17/2009 06:16 AM, Macias (Matches) Brzezinski wrote: > Looks like we have a package name collision. I'd like to build > pysvn[1], but there already is a CSWpysvn package. What do we do with > this name clash, any suggestions? > > Maciej > > [1] http://pysvn.tigris.org/ > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers the existing pylon is the python module for subversion that comes with the source code. I have not yet looked at the difference, what are the main differences? if we are going to package them both, I think one should be python_subversion and one pylon but I am not sure which should be which without more investigation. -- Thanks, Mike "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." * Albert Einstein 1879 - 1955 US German-born Theoretical Physicist From maciej at opencsw.org Sun Oct 18 09:42:10 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 18 Oct 2009 08:42:10 +0100 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: <4ADA85FA.7090506@opencsw.org> References: <4ADA85FA.7090506@opencsw.org> Message-ID: On Sun, Oct 18, 2009 at 4:05 AM, Mike Watters wrote: > On 10/17/2009 06:16 AM, Macias (Matches) Brzezinski wrote: An eager spell correction? >> Looks like we have a package name collision. I'd like to build >> pysvn[1], but there already is a CSWpysvn package. What do we do with >> this name clash, any suggestions? >> >> Maciej >> >> [1] http://pysvn.tigris.org/ >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers > > the existing pylon is the python module for subversion that comes with the > source code. ?I have not yet looked at the difference, what are the main > differences? pysvn.tigris.org is an entirely different project. If you read Subvesion's core docs[1], you'll find that they say "Subversion's language bindings unfortunately tend to lack the level of attention given to the core Subversion modules. However, there have been significant efforts towards creating functional bindings for Python, Perl, and Java.". I think the one bundled with Subversion is not very useful. pysvn.tigris.org is the one I'd like to work with (once I get it to build). Maciej [1] http://svnbook.red-bean.com/en/1.1/ch08s02.html From maciej at opencsw.org Sun Oct 18 12:58:39 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 18 Oct 2009 11:58:39 +0100 Subject: [csw-maintainers] A request to remove CSWpyxml from the buildfarm Message-ID: CSWpyxml is a package providing XML support for Python. There is a problem with it: it breaks the build of pysvn[1]. Python 2.6 has XML functionality built in (xml.dom.minidom is there already), and there is CSWpylibxml2 to provide XML-related functionality. I'd like to request the removal of CSWpyxml from the buildfarm. There's only one package depending on CSWpyxml: CSWskencil. I tried to check whether it really needs CSWpyxml, but it fails on a missing symbol: $ skencil Traceback (most recent call last): File "/opt/csw/bin/skencil", line 57, in Sketch.UI.main(sys.argv) File "/opt/csw/lib/skencil-cvs/Sketch/UI/__init__.py", line 231, in main from skapp import SketchApplication File "/opt/csw/lib/skencil-cvs/Sketch/UI/skapp.py", line 21, in import gtk, gtk.keysyms File "/opt/csw/lib/python/site-packages/gtk-2.0/gtk/__init__.py", line 48, in from gtk import _gtk ImportError: ld.so.1: python: fatal: relocation error: file /opt/csw/lib/python/site-packages/gtk-2.0/gtk/_gtk.so: symbol PyUnicodeUCS2_DecodeUTF8: referenced symbol not found In conclusion, if there's only one package dependent package which doesn't work anyway, I see no downsides of the removal of this package from the buildfarm. (I'm aware that skencil doesn't work because current pygtk is broken and orphaned[3]. Yes, pygtk needs fixing, but it's a separate issue.) Maciej [1] http://pysvn.tigris.org/issues/show_bug.cgi?id=142 [2] http://www.opencsw.org/packages/CSWpyxml [3] http://www.opencsw.org/packages/CSWpygtk From dam at opencsw.org Sun Oct 18 13:04:40 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 18 Oct 2009 13:04:40 +0200 Subject: [csw-maintainers] [csw-buildfarm] A request to remove CSWpyxml from the buildfarm In-Reply-To: References: Message-ID: <595B53DB-5921-4915-89CF-FE2BC43C9813@opencsw.org> Hi, Am 18.10.2009 um 12:58 schrieb Maciej (Matchek) Blizinski: > A request to remove CSWpyxml from the buildfarm Doing this now. Best regards -- Dago From maciej at opencsw.org Sun Oct 18 18:35:53 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 18 Oct 2009 17:35:53 +0100 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: References: <4ADA85FA.7090506@opencsw.org> Message-ID: I got pysvn-1.7.1 to build. It's in testing. For the package name conflict, I suggest the following: 1. Replacing the subversion-provided pysvn with pysvn.tigris.org, preserving the both pkgname and catalog name. It will look like a version bounce from 1.6.2 to 1.7.1. (justification: pysvn is the name of the project, it's more specific than the generic notion of bindings between subversion and Python.) 2. Creating a new package with subversion-provided Python bindings to subversion_py CSWsubversion-py, or something similar. It will be clear that it belongs to packages such as CSWsubversion and CSWsubversion-devel. For instance: http://dpaste.com/108954/ (I know it breaks the py_* rule, but it's a good thing: it's not a very useful module, there's no harm in people not seeing it often when looking for Python subversion bindings) Thoughts? Maciej From ihsan at opencsw.org Sun Oct 18 18:43:28 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 18 Oct 2009 18:43:28 +0200 Subject: [csw-maintainers] Apache 2 Package Message-ID: <4ADB45B0.1000207@opencsw.org> Hello, The Apache 2 package needs to be reworked and I can't find any additional ressources at this time. Would be great if someone could take over this package. ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From maciej at opencsw.org Sun Oct 18 18:48:30 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 18 Oct 2009 17:48:30 +0100 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: <4ADB45B0.1000207@opencsw.org> References: <4ADB45B0.1000207@opencsw.org> Message-ID: On Sun, Oct 18, 2009 at 5:43 PM, Ihsan Dogan wrote: > The Apache 2 package needs to be reworked and I can't find any > additional ressources at this time. Would be great if someone could take > over this package. What is there to be done? (I'm not volunteering, I'm asking because I think that a description or a task list would be useful for potential volunteers.) Maciej From ihsan at opencsw.org Sun Oct 18 18:54:15 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 18 Oct 2009 18:54:15 +0200 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: References: <4ADB45B0.1000207@opencsw.org> Message-ID: <4ADB4837.9010404@opencsw.org> Am 18.10.2009 18:48 Uhr, Maciej (Matchek) Blizinski schrieb: >> The Apache 2 package needs to be reworked and I can't find any >> additional ressources at this time. Would be great if someone could take >> over this package. > > What is there to be done? The packaging has to be changed to dynamic prototype, gspec files has to be removed and maybe the packaging of the rt and c package has to be verified. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From bwalton at opencsw.org Sun Oct 18 19:31:59 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 18 Oct 2009 13:31:59 -0400 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: <4ADB4837.9010404@opencsw.org> References: <4ADB45B0.1000207@opencsw.org> <4ADB4837.9010404@opencsw.org> Message-ID: <1255887034-sup-5726@ntdws12.chass.utoronto.ca> Excerpts from Ihsan Dogan's message of Sun Oct 18 12:54:15 -0400 2009: > The packaging has to be changed to dynamic prototype, gspec files has to > be removed and maybe the packaging of the rt and c package has to be > verified. ...and sysconfdir -> /etc/opt/csw/apache2, localstatedir -> /var/opt/csw/apache2? [Just a personal wishlist item.] Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rupert at opencsw.org Sun Oct 18 20:00:17 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 18 Oct 2009 20:00:17 +0200 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: References: <4ADA85FA.7090506@opencsw.org> Message-ID: <6af4270910181100p304aad88w83fe974abfa2353f@mail.gmail.com> On Sun, Oct 18, 2009 at 18:35, Maciej (Matchek) Blizinski wrote: > I got pysvn-1.7.1 to build. It's in testing. > > For the package name conflict, I suggest the following: > > 1. Replacing the subversion-provided pysvn with pysvn.tigris.org, > preserving the both pkgname and catalog name. It will look like a > version bounce from 1.6.2 to 1.7.1. (justification: pysvn is the name > of the project, it's more specific than the generic notion of bindings > between subversion and Python.) > > 2. Creating a new package with subversion-provided Python bindings to > subversion_py CSWsubversion-py, or something similar. It will be clear > that it belongs to packages such as CSWsubversion and > CSWsubversion-devel. For instance: http://dpaste.com/108954/ (I know > it breaks the py_* rule, but it's a good thing: it's not a very useful > module, there's no harm in people not seeing it often when looking for > Python subversion bindings) > > Thoughts? would this mean existing dependencies would work out if one replaces the contents with something else? rupert From ihsan at opencsw.org Sun Oct 18 21:16:14 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 18 Oct 2009 21:16:14 +0200 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: <1255887034-sup-5726@ntdws12.chass.utoronto.ca> References: <4ADB45B0.1000207@opencsw.org> <4ADB4837.9010404@opencsw.org> <1255887034-sup-5726@ntdws12.chass.utoronto.ca> Message-ID: <4ADB697E.5060403@opencsw.org> Am 18.10.2009 19:31 Uhr, Ben Walton schrieb: > Excerpts from Ihsan Dogan's message of Sun Oct 18 12:54:15 -0400 2009: > >> The packaging has to be changed to dynamic prototype, gspec files has to >> be removed and maybe the packaging of the rt and c package has to be >> verified. > > ...and sysconfdir -> /etc/opt/csw/apache2, localstatedir -> > /var/opt/csw/apache2? [Just a personal wishlist item.] Of course, I've forgot that one. This would require coordination with other package maintainers. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From bwalton at opencsw.org Sun Oct 18 21:24:35 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 18 Oct 2009 15:24:35 -0400 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: <4ADB697E.5060403@opencsw.org> References: <4ADB45B0.1000207@opencsw.org> <4ADB4837.9010404@opencsw.org> <1255887034-sup-5726@ntdws12.chass.utoronto.ca> <4ADB697E.5060403@opencsw.org> Message-ID: <1255893828-sup-8764@ntdws12.chass.utoronto.ca> Excerpts from Ihsan Dogan's message of Sun Oct 18 15:16:14 -0400 2009: > Of course, I've forgot that one. This would require coordination with > other package maintainers. Yes, it won't be easy. It's a wishlist, but certainly not a must have in this case. If it was only the apache package itself that was affected, it'd be a much easier move. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Mon Oct 19 00:08:41 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 18 Oct 2009 23:08:41 +0100 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: <6af4270910181100p304aad88w83fe974abfa2353f@mail.gmail.com> References: <4ADA85FA.7090506@opencsw.org> <6af4270910181100p304aad88w83fe974abfa2353f@mail.gmail.com> Message-ID: On Sun, Oct 18, 2009 at 7:00 PM, rupert THURNER wrote: > would this mean existing dependencies would work out if one replaces > the contents with something else? Good point. Those packages provide different libraries; currently only Trac depends on CSWpysvn[1][2]. I guess it won't be hard to update its dependencies to the new package and release them together. Maciej [1] http://www.opencsw.org/packages/CSWpysvn [2] http://svn.edgewall.com/repos/trac/trunk/INSTALL From maciej at opencsw.org Mon Oct 19 01:39:45 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 19 Oct 2009 00:39:45 +0100 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4AAB32A6.5060305@opencsw.org> <64360.194.246.122.22.1253185698.squirrel@ssl.skayser.de> Message-ID: I've written the first version of cswmigrateconf, a class utility script which migrates configuration files from /opt/csw/etc to /etc/opt/csw. It works the way Sebastian has suggested, i.e.: It makes an intermediate copy in /opt/csw/etc/migration-archive, and then uses it as a source to populate /etc/opt/csw. The change can be viewed here: http://sourceforge.net/apps/trac/gar/changeset/6899 http://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/cswclassutils/trunk/files/CSWcswclassutils.i.cswmigrateconf It also deals with a situation where there are symlinks from /etc/opt/csw/foo.conf go /opt/csw/etc/foo.conf -- or any (soon to be) dangling symlinks. To use the class utility script, one needs to create a configuration file for it and set the file class. Only one configuration file is allowed per package. An example of a simple configuration file: MIGRATE_FILES="odbc.ini odbcinst.ini" That's it. The migration script will do the rest. If one wanted to migrate odbc.ini to a different directory, here's how to do it: MIGRATE_FILES="odbc.ini odbcinst.ini" SOURCE_DIR_odbc_ini="opt/csw/etc/mysubdir" DEST_DIR_odbc_ini="etc/opt/csw/anotherplace" Leading slash won't hurt, but it's not necessary. If all the files share the same subdirectory, default source directory can be specified: SOURCE_DIR___default__="etc/opt/csw/mysubdir" It's been briefly tested on my workstation. I've built a package and put it into testing: http://mirror.opencsw.org/testing/cswclassutils-1.24,REV=2009.10.19-SunOS5.8-all-CSW.pkg.gz The code is somewhat complex; I did my best to make it readable. Comments and questions are appreciated. Maciej From maciej at opencsw.org Mon Oct 19 01:57:59 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 19 Oct 2009 00:57:59 +0100 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 Message-ID: I wrote a utility to automate the step of submitting a package to the release maintainer. It takes a comma-separated list of package names, copies the packages from the testing directory to newpkgs and formats an e-mail with the list of package files. Usage: submitpkg [options] Options: -h, --help show this help message and exit -p PKGNAMES, --pkgnames=PKGNAMES A comma-separated list of pkgnames -d, --debug Print debugging messages It doesn't send the e-mail. It only formats it and lets the user edit it. Upon exit, it tells how to send the e-mail (sendmail -t ). submitpkg is configurable. A system-wide configuration file is accepted: /etc/opt/csw/releases.ini -- the user-specific configuration file is in ~/.releases.ini. Example configuration: ; A configuration file for the release automation script [releases] sender name = Maciej Blizinski sender email = release manager name = Phil Brown release manager email = release cc = ; Usually it's /home/testing package dir = /home/testing target host = bender target dir = /home/newpkgs And... yes, it's not GAR-specific. :-) The source code is here: https://opencsw.svn.sourceforge.net/svnroot/opencsw/utilities/submit_to_newpkgs.py Any comments, thoughts or flames? Maciej From dam at opencsw.org Mon Oct 19 08:36:27 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 19 Oct 2009 08:36:27 +0200 Subject: [csw-maintainers] build8x and buid8xt currently down Message-ID: Hi, I just started to upgrade the farm with the latest packages and than a thought flashed my mind that I had to put autoenable_cswopenssh=yes in /etc/opt/csw/csw.conf or OpenSSH stays down on build8*. Needless to say that build8s, build8x and build8xt had already been updated, but not build8s.go.opencsw.org. So please be advised that build8x build8xt will stay down until a couple of hours when I get back to the office. The others machines will be upgraded at that time also. ...and I *will* insert that line now, before the next upgrade :-P Sorry for the inconvenience -- Dago From dam at opencsw.org Mon Oct 19 15:36:55 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 19 Oct 2009 15:36:55 +0200 Subject: [csw-maintainers] build8x* is available again Message-ID: <6CDDA8D3-409A-4265-8D13-2D4DA6B3F2E0@opencsw.org> Hi, the servers build8x and build8xt are available again. Sorry for the inconvenience -- Dago From phil at bolthole.com Mon Oct 19 17:33:08 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 19 Oct 2009 08:33:08 -0700 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: References: Message-ID: On Sun, Oct 18, 2009 at 4:57 PM, Maciej (Matchek) Blizinski wrote: > I wrote a utility to automate the step of submitting a package to the > release maintainer. It takes a comma-separated list of package names, > copies the packages from the testing directory to newpkgs and formats > an e-mail with the list of package files. > > Usage: submitpkg [options] Excellent!! we've needed this for a long time. When it's debugged some, it should go in cswutils. Thanks for writing this. > Any comments, thoughts or flames? did it HAVE to be written in python? :-( even perl would be better. Something as basic as this, would be nice to use without having to potentially download and install a whole new language package. From dam at opencsw.org Mon Oct 19 17:35:30 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 19 Oct 2009 17:35:30 +0200 Subject: [csw-maintainers] BerkeleyDB upgrade References: Message-ID: <4C32281F-89A3-4B57-B840-699CA6795EDB@opencsw.org> Dear maintainers, I have now finally assembled a new and complete rebuild of the Berkeley DB libraries. In the new schema every version of BDB is sitting in a separate subdirectory, that means Berkeley DB X.Y.Z is located at /opt/csw/bdbXY/(bin|lib|...) The repackaged versions contain 3.3, 4.2, 4.3, 4.4, 4.7 and 4.8. If necessary the legacy packages needed as dependencies have been replaced by stubs containing minimal links to the new locations with a respective dependency in the package. The following packages have been updated: CATALOGNAME PACKAGENAME berkeleydb CSWbdb berkeleydb3 CSWbdb3 berkeleydb3_devel CSWbdb3devel berkeleydb3_doc CSWbdb3doc berkeleydb4 CSWbdb4 berkeleydb42 CSWbdb42 berkeleydb42_devel CSWbdb42devel berkeleydb42_doc CSWbdb42doc berkeleydb43 CSWbdb43 berkeleydb43_devel CSWbdb43-devel berkeleydb43_doc CSWbdb43-doc berkeleydb44 CSWbdb44 berkeleydb44_devel CSWbdb44-devel berkeleydb44_doc CSWbdb44-doc berkeleydb47 CSWbdb47 berkeleydb47_devel CSWbdb47devel berkeleydb47_doc CSWbdb47doc berkeleydb48 CSWbdb48 berkeleydb48_devel CSWbdb48devel berkeleydb48_doc CSWbdb48doc The following packages are deprecated: - CSWbdb was newly introduced during the unification. It contains now only symlinks pointing inside CSWbdb47. The package will go away when all dependant packages habe been recompiled against CSWbdb47. /opt/csw/lib/amd64/libdb-4.7.so=../../bdb47/lib/amd64/libdb-4.7.so /opt/csw/lib/libdb-4.7.so=../bdb47/lib/libdb-4.7.so - CSWbdb4 contained the original Berkeley DB 4.2 in /opt/csw/bdb4. The package now contains /opt/csw/bdb4=bdb42 The following packages do not exist any more as the base packages are deprecated: - berkeleydb_doc CSWbdbdoc - berkeleydb_devel CSWbdbdevel - berkeleydb4_doc CSWbdb4-doc The following package names have been kept to match the existing naming. The package names will be adjusted at a later date with proper announcement: - berkeleydb43_devel CSWbdb43-devel - berkeleydb43_doc CSWbdb43-doc - berkeleydb44_devel CSWbdb44-devel - berkeleydb44_doc CSWbdb44-doc Should you encounter any issues please post to users@ as usual. Best regards -- Dago From phil at bolthole.com Mon Oct 19 17:43:01 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 19 Oct 2009 08:43:01 -0700 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: References: <4ADA85FA.7090506@opencsw.org> Message-ID: On Sun, Oct 18, 2009 at 9:35 AM, Maciej (Matchek) Blizinski wrote: > I got pysvn-1.7.1 to build. It's in testing. > > For the package name conflict, I suggest the following: >... > 2. Creating a new package with subversion-provided Python bindings to > subversion_py CSWsubversion-py, or something similar. Hmmm. well, to give more specifics subversion already provides multiple language bindings, such as javasvn (java language) rbsvn (ruby language) pysvn (python language) One issue here is that CSWpysnv pysvn potentially conflicts with our standard naming for python modules. Except that it doesnt technically, because python modules are normally named "py_" :-) But there is a more fundamental issue, that the subversion addons named above, should not have been abbreviated. java was not abbreviated. ruby and python should not have been either. They should really have been named rubysvn, and pythonsvn Now, as everyone knows, I am normally EXTREMELY AGAINST package renaming. But in this case, I think it both makes sense, AND will not be overly disruptive. the only thing depending on either of them, is CSWtrac. As long as that is repackaged at the same time, newly pointing to the new name, I think we can go ahead and do the rename. However, for our users' sake, I think that we should postpone reackaging of the new "pysvn", until at least a month AFTER the release of the renames have been done. That way, most people who already have trac installed, and do automatic updates, will probably have things nicely upgraded for them with no confusion. But this will still neccessitate announcements about it when released. Note to the pythonsvn and trac maintainers: To save time, please remind me, when you actually submit the packages. I have a lot to keep track of and may well forget by the time you submit them :-) From phil at bolthole.com Mon Oct 19 17:44:00 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 19 Oct 2009 08:44:00 -0700 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: References: <4ADA85FA.7090506@opencsw.org> Message-ID: Please note : this upgrade is complicated by tthe fact that normally on a pkg rename, we declare a conflict with the old name, which is then obsolete. But, since the old name of CSWpysvn will NOT be obsolete, we cannot declare a conflict to it. From phil at bolthole.com Mon Oct 19 17:45:41 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 19 Oct 2009 08:45:41 -0700 Subject: [csw-maintainers] BerkeleyDB upgrade In-Reply-To: <4C32281F-89A3-4B57-B840-699CA6795EDB@opencsw.org> References: <4C32281F-89A3-4B57-B840-699CA6795EDB@opencsw.org> Message-ID: And thank you, Dagobert, for demonstrating the RIGHT way to to important announcements: Doing a multi-post to "users" and "announce", but doing a SEPARATE email to the maintainers list :-) (and thank you also for doing the work, of course! :-) From phil at bolthole.com Mon Oct 19 19:26:14 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 19 Oct 2009 10:26:14 -0700 Subject: [csw-maintainers] caution: internal release tree tweaked Message-ID: Please note: all packages in newpkgs PRIOR to this email, have been either released, or commented on. that being said, I have just completed a bit of internal tweakage to release directory layout. This SHOULD be invisible... but wanted to give you guys a heads-up for any packages released in the next few days; please be a little extra-cautious and observant to see whether your packages make it all the way out to mirror sites cleanly within 48 hours of me saying i've publically pushed them. You guys still should copy packages to the same old newpkgs directory. As i said, this change "should be invisible" to you all ;-) From ihsan at opencsw.org Mon Oct 19 21:14:01 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Mon, 19 Oct 2009 21:14:01 +0200 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: References: Message-ID: <4ADCBA79.7050005@opencsw.org> Am 19.10.2009 17:33 Uhr, Philip Brown schrieb: >> I wrote a utility to automate the step of submitting a package to the >> release maintainer. It takes a comma-separated list of package names, >> copies the packages from the testing directory to newpkgs and formats >> an e-mail with the list of package files. >> >> Usage: submitpkg [options] > > Excellent!! we've needed this for a long time. When it's debugged > some, it should go in cswutils. Thanks for writing this. Thanks Maciej, great work. >> Any comments, thoughts or flames? > > did it HAVE to be written in python? :-( > even perl would be better. Something as basic as this, would be nice > to use without having to potentially download and install a whole new > language package. I don't see a problem here. Python comes already with Solaris 10. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From phil at bolthole.com Mon Oct 19 22:40:31 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 19 Oct 2009 13:40:31 -0700 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: <4ADCBA79.7050005@opencsw.org> References: <4ADCBA79.7050005@opencsw.org> Message-ID: On Mon, Oct 19, 2009 at 12:14 PM, Ihsan Dogan wrote: > >> >> did it HAVE to be written in python? :-( >> even perl would be better. Something as basic as this, would be nice >> to use without having to potentially download and install a whole new >> language package. > > I don't see a problem here. Python comes already with Solaris 10. > > I think it "comes with" sol9 too. But it isnt exactly part of SUNWCreq, in either 9 OR 10. perl IS, btw. From bwalton at opencsw.org Tue Oct 20 01:33:24 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 19 Oct 2009 19:33:24 -0400 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: References: <4ADCBA79.7050005@opencsw.org> Message-ID: <1255994929-sup-3@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Oct 19 16:40:31 -0400 2009: > But it isnt exactly part of SUNWCreq, in either 9 OR 10. Restricting language choice for tools that are used to bootstrap makes sense. Relying on things that aren't available wouldn't get you very far. For things that already depend on CSWcommon, it should be up to the implementer to a) choose the right tool for the job and b) choose something they're comfortable with. There is no indication that python isn't the right tool for this job. Perl would be equally right, but not more so. So, in this case, Maciej's comfort level with said tool would get more weight in the selection criteria...plus, it's already done, and re-coding it serves no purpose. My 2 cents from the sidelines. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Tue Oct 20 14:56:48 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 20 Oct 2009 13:56:48 +0100 Subject: [csw-maintainers] GAR: rebuilding after modifying a file in software's sources Message-ID: I've modified a source file and I want to tell gmake to rebuild the necessary binaries. I'm trying: maciej at build8s [build8s]:~/src/opencsw/pkg/cups/branches/cups-1.4.0 > gmake build [build] complete for cups. ...it says everything has been built. But it hasn't, I modified http.c and it should trigger the rebuild of some binaries. cd'ing into the source and issuing 'gmake' doesn't work: a - util.o ar: writing libcups.a gmake[1]: ranlib: Command not found gmake[1]: *** [libcups.a] Error 127 gmake[1]: *** Waiting for unfinished jobs.... gmake: *** [all] Error 1 How can I tell GAR to rebuild the source? Maciej From dam at opencsw.org Tue Oct 20 15:13:20 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 20 Oct 2009 15:13:20 +0200 Subject: [csw-maintainers] GAR: rebuilding after modifying a file in software's sources In-Reply-To: References: Message-ID: Hi Maciej, Am 20.10.2009 um 14:56 schrieb Maciej (Matchek) Blizinski: > I've modified a source file and I want to tell gmake to rebuild the > necessary binaries. I'm trying: > > maciej at build8s [build8s]:~/src/opencsw/pkg/cups/branches/cups-1.4.0 > > gmake build > [build] complete for cups. > > ...it says everything has been built. But it hasn't, I modified http.c > and it should trigger the rebuild of some binaries. > > cd'ing into the source and issuing 'gmake' doesn't work: a - util.o > ar: writing libcups.a > gmake[1]: ranlib: Command not found > gmake[1]: *** [libcups.a] Error 127 > gmake[1]: *** Waiting for unfinished jobs.... > gmake: *** [all] Error 1 > > How can I tell GAR to rebuild the source? gmake rebuild ;-) There are also remerge and repackage. Best regards -- Dago From maciej at opencsw.org Tue Oct 20 15:30:29 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 20 Oct 2009 14:30:29 +0100 Subject: [csw-maintainers] GAR: rebuilding after modifying a file in software's sources In-Reply-To: References: Message-ID: On Tue, Oct 20, 2009 at 2:13 PM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 20.10.2009 um 14:56 schrieb Maciej (Matchek) Blizinski: >> >> I've modified a source file and I want to tell gmake to rebuild the >> necessary binaries. I'm trying: >> >> maciej at build8s [build8s]:~/src/opencsw/pkg/cups/branches/cups-1.4.0 > >> gmake build >> ? ? ? [build] complete for cups. >> >> ...it says everything has been built. But it hasn't, I modified http.c >> and it should trigger the rebuild of some binaries. >> >> cd'ing into the source and issuing 'gmake' doesn't work: a - util.o >> ar: writing libcups.a >> gmake[1]: ranlib: Command not found >> gmake[1]: *** [libcups.a] Error 127 >> gmake[1]: *** Waiting for unfinished jobs.... >> gmake: *** [all] Error 1 >> >> How can I tell GAR to rebuild the source? > > gmake rebuild ;-) I've tried that already: maciej at build8s [build8s]:~/src/opencsw/pkg/cups/branches/cups-1.4.0 > gmake rebuild gmake: *** No rule to make target `rebuild'. Stop. I'm using the latest v2: maciej at build8s [build8s]:~/src/opencsw/pkg/cups/branches/cups-1.4.0 > gmake rebuild gmake: *** No rule to make target `rebuild'. Stop. maciej at build8s [build8s]:~/src/opencsw/pkg/cups/branches/cups-1.4.0 > (cd gar && svn info) Path: . URL: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/v2 Repository Root: https://gar.svn.sourceforge.net/svnroot/gar Repository UUID: d3b55034-1cff-0310-a425-aefe953e1e90 Revision: 6914 Node Kind: directory Schedule: normal From dam at opencsw.org Tue Oct 20 15:40:09 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 20 Oct 2009 15:40:09 +0200 Subject: [csw-maintainers] GAR: rebuilding after modifying a file in software's sources In-Reply-To: References: Message-ID: <1CA6E612-12C3-4508-A7F0-944D9B990D67@opencsw.org> Hi Maciej, Am 20.10.2009 um 15:30 schrieb Maciej (Matchek) Blizinski: >> gmake rebuild ;-) > > I've tried that already: Umh, my mistake. There is none. Seems like I intended but never did it. Sorry. For the moment please use gmake clean && gmake build or go to the source dir manually and issue gmake there. Would you mind opening a bug? Best regards -- Dago From maciej at opencsw.org Tue Oct 20 15:52:30 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 20 Oct 2009 14:52:30 +0100 Subject: [csw-maintainers] GAR: rebuilding after modifying a file in software's sources In-Reply-To: <1CA6E612-12C3-4508-A7F0-944D9B990D67@opencsw.org> References: <1CA6E612-12C3-4508-A7F0-944D9B990D67@opencsw.org> Message-ID: On Tue, Oct 20, 2009 at 2:40 PM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 20.10.2009 um 15:30 schrieb Maciej (Matchek) Blizinski: >>> >>> gmake rebuild ;-) >> >> I've tried that already: > > Umh, my mistake. There is none. Seems like I intended but never did it. > Sorry. For the moment please use > ?gmake clean && gmake build This one I don't want to use, because the source in work/ is a git-controlled local repository to which I'm making changes. > or go to the source dir manually and issue gmake there. This doesn't work, it says that ranlib was not found. Yes, I'll open a bug. From dam at opencsw.org Tue Oct 20 16:12:06 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 20 Oct 2009 16:12:06 +0200 Subject: [csw-maintainers] GAR: rebuilding after modifying a file in software's sources In-Reply-To: References: <1CA6E612-12C3-4508-A7F0-944D9B990D67@opencsw.org> Message-ID: <2DFDAFF3-1031-4AB5-A7C7-02E29982911E@opencsw.org> Hi Maciej, Am 20.10.2009 um 15:52 schrieb Maciej (Matchek) Blizinski: > On Tue, Oct 20, 2009 at 2:40 PM, Dagobert Michelsen > wrote: >> Hi Maciej, >> >> Am 20.10.2009 um 15:30 schrieb Maciej (Matchek) Blizinski: >>>> >>>> gmake rebuild ;-) >>> >>> I've tried that already: >> >> Umh, my mistake. There is none. Seems like I intended but never did >> it. >> Sorry. For the moment please use >> gmake clean && gmake build > > This one I don't want to use, because the source in work/ is a > git-controlled local repository to which I'm making changes. > >> or go to the source dir manually and issue gmake there. > > This doesn't work, it says that ranlib was not found. > > Yes, I'll open a bug. I see. It may be a good idea to review the whole patch-process, maybe some kind of "maintainer mode" unpacking stuff to a local git repo allowing branching, delivering patches to files/ and checking out to WORKSRC would be useful... A thing for some cold nights to come ;-) Best regards -- Dago From maciej at opencsw.org Tue Oct 20 16:23:39 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 20 Oct 2009 15:23:39 +0100 Subject: [csw-maintainers] GAR: rebuilding after modifying a file in software's sources In-Reply-To: <2DFDAFF3-1031-4AB5-A7C7-02E29982911E@opencsw.org> References: <1CA6E612-12C3-4508-A7F0-944D9B990D67@opencsw.org> <2DFDAFF3-1031-4AB5-A7C7-02E29982911E@opencsw.org> Message-ID: On Tue, Oct 20, 2009 at 3:12 PM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 20.10.2009 um 15:52 schrieb Maciej (Matchek) Blizinski: >> >> On Tue, Oct 20, 2009 at 2:40 PM, Dagobert Michelsen >> wrote: >>> >>> Hi Maciej, >>> >>> Am 20.10.2009 um 15:30 schrieb Maciej (Matchek) Blizinski: >>>>> >>>>> gmake rebuild ;-) >>>> >>>> I've tried that already: >>> >>> Umh, my mistake. There is none. Seems like I intended but never did it. >>> Sorry. For the moment please use >>> ?gmake clean && gmake build >> >> This one I don't want to use, because the source in work/ is a >> git-controlled local repository to which I'm making changes. >> >>> or go to the source dir manually and issue gmake there. >> >> This doesn't work, it says that ranlib was not found. >> >> Yes, I'll open a bug. > > I see. It may be a good idea to review the whole patch-process, > maybe some kind of "maintainer mode" unpacking stuff to a local > git repo allowing branching, delivering patches to files/ and > checking out to WORKSRC would be useful... A thing for some > cold nights to come ;-) I already have a half-broken prototype. It works, except it's hard to merge. I might start a new gar branch so you can see what my ideas are. Maciej From dam at opencsw.org Tue Oct 20 17:19:31 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 20 Oct 2009 17:19:31 +0200 Subject: [csw-maintainers] GAR: rebuilding after modifying a file in software's sources In-Reply-To: References: <1CA6E612-12C3-4508-A7F0-944D9B990D67@opencsw.org> <2DFDAFF3-1031-4AB5-A7C7-02E29982911E@opencsw.org> Message-ID: <9BD402DB-714E-460D-9973-FB28BA5D189C@opencsw.org> Hi Maciej, Am 20.10.2009 um 16:23 schrieb Maciej (Matchek) Blizinski: > On Tue, Oct 20, 2009 at 3:12 PM, Dagobert Michelsen > wrote: >> It may be a good idea to review the whole patch-process, >> maybe some kind of "maintainer mode" unpacking stuff to a local >> git repo allowing branching, delivering patches to files/ and >> checking out to WORKSRC would be useful... A thing for some >> cold nights to come ;-) > > I already have a half-broken prototype. It works, except it's hard to > merge. I might start a new gar branch so you can see what my ideas > are. Show me the code! Best regards -- Dago From maciej at opencsw.org Tue Oct 20 17:35:41 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 20 Oct 2009 16:35:41 +0100 Subject: [csw-maintainers] GAR: rebuilding after modifying a file in software's sources In-Reply-To: <9BD402DB-714E-460D-9973-FB28BA5D189C@opencsw.org> References: <1CA6E612-12C3-4508-A7F0-944D9B990D67@opencsw.org> <2DFDAFF3-1031-4AB5-A7C7-02E29982911E@opencsw.org> <9BD402DB-714E-460D-9973-FB28BA5D189C@opencsw.org> Message-ID: On Tue, Oct 20, 2009 at 4:19 PM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 20.10.2009 um 16:23 schrieb Maciej (Matchek) Blizinski: >> >> I already have a half-broken prototype. It works, except it's hard to >> merge. I might start a new gar branch so you can see what my ideas >> are. > > Show me the code! Dein Befehl ist mir Wunsch! Or the other way around, I can never remember. ;-) https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/v2-git Maciej From maciej at opencsw.org Tue Oct 20 17:48:50 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 20 Oct 2009 16:48:50 +0100 Subject: [csw-maintainers] GAR: rebuilding after modifying a file in software's sources In-Reply-To: References: <1CA6E612-12C3-4508-A7F0-944D9B990D67@opencsw.org> <2DFDAFF3-1031-4AB5-A7C7-02E29982911E@opencsw.org> <9BD402DB-714E-460D-9973-FB28BA5D189C@opencsw.org> Message-ID: On Tue, Oct 20, 2009 at 4:35 PM, Maciej (Matchek) Blizinski wrote: > https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/v2-git I think I should elaborate a little on how this is supposed to work. The idea is that the changes must survive make clean; the git repository has to be cloned somewhere outside the work/ directory. The directory to store cloned git repos needs to be defined in ~/.garrc. It should be also possible to set it per-package, because we might not want to create cloned git repos for every package we're building. In conclusion: $ grep GIT ~/.garrc ENABLE_GIT_pysvn = 1 ENABLE_GIT_pygobject = 1 GIT_DIR = /export/home/blizinski/src The first time the sources are unpacked and patched, the git repository is stored in GIT_DIR. All the following unpacks, it's going to be cloned back. It's currently being done by the means of rsync, which is generally a bad idea and I need to fix it, but I don't know how. Perhaps the git repository should be cloned back into work/ in the pre-extract stage. That's the current state of affairs. I won't be able to hack much more until the 2nd of November. Maciej From maciej at opencsw.org Tue Oct 20 18:23:30 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 20 Oct 2009 17:23:30 +0100 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: References: <4ADA85FA.7090506@opencsw.org> Message-ID: On Mon, Oct 19, 2009 at 4:44 PM, Philip Brown wrote: > Please note : this upgrade is complicated by tthe fact that normally > on a pkg rename, we declare a conflict with the old name, which is > then obsolete. > > But, since the old name of CSWpysvn will NOT be obsolete, we cannot > declare a conflict to it. I've opened a bug with the subversion package about the rename: http://www.opencsw.org/bugtrack/view.php?id=3973 An idea for the change... from the perspective of the operating system, it won't be really a rename, there is still going to be a CSWpysvn package, only with a different content. How about this: 1. Create CSWpythonsvn with the subversion-core Python bindings 2. Update CSWpysvn by putting there files from pysvn.tigris org. 3. Declare a dependency: CSWpysvn is going to depend on CSWpythonsvn 4. Trac, which depends on the subversion-core bindings will still work, because it's going to get the right files from CSWpythonsvn (required by CSWpysvn) 5. Trac will be updated to depend on CSWpythonsvn 6. After a month or so, as Phil suggested, the dependency of CSWpysvn on CSWpythonsvn will be removed. In other words: CSWtrac --> CSWpysvn --> CSWpythonsvn could be the remedy. This way, the change can be done relatively smoothly, without the potential of breaking Trac, and with the possibility to release pysvn from pysvn.tigris.org relatively quickly. Thoughts? Maciej From phil at bolthole.com Tue Oct 20 21:07:54 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 20 Oct 2009 12:07:54 -0700 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: References: <4ADA85FA.7090506@opencsw.org> Message-ID: On Tue, Oct 20, 2009 at 9:23 AM, Maciej (Matchek) Blizinski wrote: > > An idea for the change... from the perspective of the operating > system, it won't be really a rename, there is still going to be a > CSWpysvn package, only with a different content. you say "only", but that is what makes it WORSE! :-/ I have said the order and timeline of what I think is the best path to take. That still stands. From maciej at opencsw.org Tue Oct 20 22:02:50 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 20 Oct 2009 21:02:50 +0100 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: References: <4ADA85FA.7090506@opencsw.org> Message-ID: On Tue, Oct 20, 2009 at 8:07 PM, Philip Brown wrote: > On Tue, Oct 20, 2009 at 9:23 AM, Maciej (Matchek) Blizinski > wrote: >> >> An idea for the change... from the perspective of the operating >> system, it won't be really a rename, there is still going to be a >> CSWpysvn package, only with a different content. > > > you say "only", but that is what makes it WORSE! :-/ Not necessarily. We ship library packages with multiple libraries in them. We potentially could ship both subversion-core and pysvn libraries in the same package. No renaming, but merging python-subversion libraries. It's a problem equivalent to the shared library problem, which is solved already. > I have said the order and timeline of what I think is the best path to take. > That still stands. Your timeline means that submitpkg won't be able to generate changelists for $time_to_build_new_subversion_packages + one month. I'd like to operate quicker than that. Any problems with this approach? Maciej From phil at bolthole.com Tue Oct 20 22:09:19 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 20 Oct 2009 13:09:19 -0700 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: References: <4ADA85FA.7090506@opencsw.org> Message-ID: On Tue, Oct 20, 2009 at 1:02 PM, Maciej (Matchek) Blizinski wrote: > > Your timeline means that submitpkg won't be able to generate > changelists for $time_to_build_new_subversion_packages + one month. > I'd like to operate quicker than that. Any problems with this > approach? I've already stated my reasons. The sooner the first wave gets put in, the sooner the 1 month will be completed From skayser at opencsw.org Wed Oct 21 00:38:38 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 21 Oct 2009 00:38:38 +0200 Subject: [csw-maintainers] Anyone wants to update wxWidgets? In-Reply-To: References: <625385e30908200922j40df818cn24ef7b7bda28c609@mail.gmail.com> <1251551183-sup-4494@ntdws12.chass.utoronto.ca> <1251678005-sup-226@ntdws12.chass.utoronto.ca> <20090923.11441600.3790365392@gyor.oxdrove.co.uk> Message-ID: <4ADE3BEE.90808@opencsw.org> Maciej (Matchek) Blizinski wrote on 14.10.2009 19:27: > One more problem: It doesn't compile it on build8s, while it does on > my local machine at work. Here's what happens on build8s: > > [...] > > Looking at config.log: > > configure:27183: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest > -erroff=E_NO_EXPLICIT_TYPE_GIVEN -xO3 -xarch=v8 -fast -xstrconst > -xnolibmopt -I/opt/csw/X11/include -I/usr/X11/include > -I/usr/openwin/share/include -I/opt/csw/include -D_REENTRANT > -D_PTHREADS -D__solaris__ -D_POSIX_PTHREAD_SEMANTICS > -I/opt/csw/include/gtk-2.0 -I/opt/csw/lib/gtk-2.0/include > -I/opt/csw/include/atk-1.0 -I/opt/csw/include/cairo > -I/opt/csw/include/pango-1.0 -I/opt/csw/include/glib-2.0 > -I/opt/csw/lib/glib-2.0/include -I/opt/csw/include/pixman-1 > -I/opt/csw/include/freetype2 -I/opt/csw/include > -I/opt/csw/include/libpng12 -I/opt/csw/X11/include > -I/opt/csw/X11/include -I/usr/X11/include -I/usr/openwin/share/include > -I/opt/csw/include -xarch=v8 -L/opt/csw/lib -L/opt/csw/X11/lib > conftest.c -lm -L/opt/csw/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 > -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo > -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 > -lgthread-2.0 -lpthread -lthread -lrt -lglib-2.0 -lintl >&5 > "conftest.c", line 74: warning: statement not reached > Undefined first referenced > symbol in file > XSolarisIASetProcessInfo /usr/openwin/lib/libX11.so.4 > ld: fatal: Symbol referencing errors. No output written to conftest > > Is it related to the recent discussions about X11 libs? Is it a common > problem, and are there any common fixes? I see a similar problem with mtr [1]. $ gmake clean configure-isa-i386-gui-enable ... checking for socket... no checking for socket in -lsocket... no configure: error: No socket library found gmake[1]: *** [configure-work/build-isa-i386-gui-enable/mtr-0.75/configure] Error 1 gmake[1]: Leaving directory `/home/skayser/mgar/pkg/mtr/trunk' gmake: *** [configure-isa-i386-gui-enable] Error 2 Looking at config.log configure:6739: checking for socket configure:6795: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -xO3 -xarch=386 -I/opt/csw/include -D__solaris__ -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -I/opt/csw/include/gtk-2.0 -I/opt/csw/lib/gtk-2.0/include -I/opt/csw/include/atk-1.0 -I/opt/csw/include/cairo -I/opt/csw/include/pango-1.0 -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -I/opt/csw/include/pixman-1 -I/opt/csw/include/freetype2 -I/opt/csw/include -I/opt/csw/include/libpng12 -I/opt/csw/X11/include -I/opt/csw/include -xarch=386 -L/opt/csw/lib conftest.c -lm -ltermcap -L/opt/csw/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -lm >&5 "conftest.c", line 67: warning: statement not reached Undefined first referenced symbol in file socket conftest.o (symbol belongs to implicit dependency /lib/libsocket.so.1) XSolarisIASetProcessInfo /usr/openwin/lib/libX11.so.4 Is there some sort of LD_DEBUG way to determine what is happening here? Which lib pulls in /usr/openwin/lib/libX11.so.4 (i can't see it mentioned on the command line) and why can't it resolve the XSolarisIASetProcessInfo symbol which belongs to one of it's dependencies, libXext. $ nm -p /usr/openwin/lib/libXext.so | grep XSolarisIASetProcessInfo 0000037148 T XSolarisIASetProcessInfo $ dump -Lv /usr/openwin/lib/libX11.so.4 | grep NEEDED [1] NEEDED libXext.so.0 ... Sebastian [1]https://gar.svn.sf.net/svnroot/gar/csw/mgar/pkg/mtr/trunk/Makefile From ihsan at opencsw.org Wed Oct 21 10:48:52 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 21 Oct 2009 10:48:52 +0200 (CEST) Subject: [csw-maintainers] Wikipedia article Message-ID: Hello, I've just noticed, that there is an article about OpenCSW on Wikipedia: http://en.wikipedia.org/wiki/OpenCSW Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ http://ihsan.dogan.ch/ From maciej at opencsw.org Wed Oct 21 11:53:58 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 21 Oct 2009 10:53:58 +0100 Subject: [csw-maintainers] Wikipedia article In-Reply-To: References: Message-ID: On Wed, Oct 21, 2009 at 9:48 AM, Ihsan Dogan wrote: > Hello, > > I've just noticed, that there is an article about OpenCSW on Wikipedia: > http://en.wikipedia.org/wiki/OpenCSW Yes, and these are my contributions: http://bit.ly/3Vyhhi Maciej From maciej at opencsw.org Wed Oct 21 12:47:07 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 21 Oct 2009 11:47:07 +0100 Subject: [csw-maintainers] Buildbot In-Reply-To: <20090731184245.GC76412@bolthole.com> References: <9C6FD617-8E9C-4649-9361-4525D8A68C98@opencsw.org> <20090731164757.GB30823@bolthole.com> <20090731.18151000.1268557623@gyor.oxdrove.co.uk> <20090731184245.GC76412@bolthole.com> Message-ID: On Fri, Jul 31, 2009 at 7:42 PM, Philip Brown wrote: > On Fri, Jul 31, 2009 at 06:15:10PM +0000, James Lee wrote: >> >> Go further, just have a single entry point per project (not package) per >> version that can be run with exec. ?i.e., don't use make as the first >> step. ?You can call make from a script if you want, I suppose so too >> could one call a script from make but it's not as pure and simplistic. > > in other words, debian style, have a "build" executable.... even though 99% > of the time, the debian "executable" is a script that starts with > > #!/bin/make > > :-) > > [ie: a makefile!] Looks good to me. Are others okay with this interface? (i.e. an executable script named 'build', with no arguments) Maciej From dam at opencsw.org Wed Oct 21 13:18:10 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 21 Oct 2009 13:18:10 +0200 Subject: [csw-maintainers] Buildbot In-Reply-To: References: <9C6FD617-8E9C-4649-9361-4525D8A68C98@opencsw.org> <20090731164757.GB30823@bolthole.com> <20090731.18151000.1268557623@gyor.oxdrove.co.uk> <20090731184245.GC76412@bolthole.com> Message-ID: <94BCC288-3326-47E6-9397-091D93A8771B@opencsw.org> Hi, Am 21.10.2009 um 12:47 schrieb Maciej (Matchek) Blizinski: > On Fri, Jul 31, 2009 at 7:42 PM, Philip Brown > wrote: >> On Fri, Jul 31, 2009 at 06:15:10PM +0000, James Lee wrote: >>> >>> Go further, just have a single entry point per project (not >>> package) per >>> version that can be run with exec. i.e., don't use make as the >>> first >>> step. You can call make from a script if you want, I suppose so too >>> could one call a script from make but it's not as pure and >>> simplistic. >> >> in other words, debian style, have a "build" executable.... even >> though 99% >> of the time, the debian "executable" is a script that starts with >> >> #!/bin/make >> >> :-) >> >> [ie: a makefile!] > > Looks good to me. Are others okay with this interface? (i.e. an > executable script named 'build', with no arguments) Sure. So no more excuses for James and Peter and Phil not to be "committed" ;-) Best regards -- Dagobert From william at wbonnet.net Wed Oct 21 17:58:48 2009 From: william at wbonnet.net (William Bonnet) Date: Wed, 21 Oct 2009 17:58:48 +0200 Subject: [csw-maintainers] X11 update on test machines Message-ID: <4ADF2FB8.2010602@wbonnet.net> Hi, Several missing X11 packages have been prepared, and ready to be tested. You may have already see a few *proto packages in testing. For consistency reasons, we plan to packages versions which are coherent with the X11R7.4 release. Latest stable release from X.org (packages added after this release, thus not included at all in R7.4, may have latest version if needed). I rebuild yesterday all the proto files with the good versions, and i am planning to install these packages on testing machines to rebuild the libs which are in GAR. Does any one see a problem to this ? . I will remove currently installed proto files, and replace them by th freshly rebuild packages . Then, i will rebuild and replace each lib, moving the libs to the individual versions defined by X11R7.4 release. This will be done *only* on test machines, not build ! cheers W. From phil at bolthole.com Wed Oct 21 18:27:37 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 21 Oct 2009 09:27:37 -0700 Subject: [csw-maintainers] Anyone wants to update wxWidgets? In-Reply-To: <4ADE3BEE.90808@opencsw.org> References: <625385e30908200922j40df818cn24ef7b7bda28c609@mail.gmail.com> <1251678005-sup-226@ntdws12.chass.utoronto.ca> <20090923.11441600.3790365392@gyor.oxdrove.co.uk> <4ADE3BEE.90808@opencsw.org> Message-ID: On Tue, Oct 20, 2009 at 3:38 PM, Sebastian Kayser wrote: > Undefined ? ? ? ? ? ? ? ? ? ? ? first referenced > ?symbol ? ? ? ? ? ? ? ? ? ? ? ? ? ? in file > socket ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?conftest.o ?(symbol belongs to implicit dependency /lib/libsocket.so.1) > XSolarisIASetProcessInfo ? ? ? ? ? ?/usr/openwin/lib/libX11.so.4 > I think some of the error output got mangled somehow. THIS error output seems pretty clear, that you are missing a -lsocket. USUALLY, configs/makefiles have some clause for [detect if lsocket is needed] So doing a grep for "lsocket" in assorted configure, etc shoudl help. > Is there some sort of LD_DEBUG way to determine what is happening > here? Which lib pulls in /usr/openwin/lib/libX11.so.4 (i can't see > it mentioned on the command line) LD_DEBUG=files is usually what I use. From phil at bolthole.com Wed Oct 21 18:47:33 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 21 Oct 2009 09:47:33 -0700 Subject: [csw-maintainers] Buildbot In-Reply-To: <94BCC288-3326-47E6-9397-091D93A8771B@opencsw.org> References: <9C6FD617-8E9C-4649-9361-4525D8A68C98@opencsw.org> <20090731164757.GB30823@bolthole.com> <20090731.18151000.1268557623@gyor.oxdrove.co.uk> <20090731184245.GC76412@bolthole.com> <94BCC288-3326-47E6-9397-091D93A8771B@opencsw.org> Message-ID: On Wed, Oct 21, 2009 at 4:18 AM, Dagobert Michelsen wrote: > Hi, > > Am 21.10.2009 um 12:47 schrieb Maciej (Matchek) Blizinski: >> >>... >>> in other words, debian style, have a "build" executable.... even though >>> 99% >>> of the time, the debian "executable" is a script that starts with >>> >>> #!/bin/make >>> >>> :-) >>> >>> [ie: a makefile!] >> >> Looks good to me. Are others okay with this interface? (i.e. an >> executable script named 'build', with no arguments) > > Sure. So no more excuses for James and Peter and Phil not to be "committed" > ;-) > > well there is a bit... this needs to be written up officially, and also specify what allowable arguments to "build" are. Also, it needs to be defined which arguments are "mandatory" to support, vs which are optional. We should have a new clean thread for this. Mr. secretary are you going to handle that, or shall I? :-) From william at wbonnet.net Wed Oct 21 21:44:25 2009 From: william at wbonnet.net (William Bonnet) Date: Wed, 21 Oct 2009 21:44:25 +0200 Subject: [csw-maintainers] Updating X11 proto on test machine Message-ID: <4ADF6499.8080907@wbonnet.net> Hi I'm starting to update packages on the test machines 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 william at wbonnet.net Wed Oct 21 21:52:08 2009 From: william at wbonnet.net (William Bonnet) Date: Wed, 21 Oct 2009 21:52:08 +0200 Subject: [csw-maintainers] Updating X11 proto on test machine In-Reply-To: <4ADF6499.8080907@wbonnet.net> References: <4ADF6499.8080907@wbonnet.net> Message-ID: <4ADF6668.9030904@wbonnet.net> Hi It's done on the test8{s,x} machines 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 william at wbonnet.net Thu Oct 22 00:21:23 2009 From: william at wbonnet.net (William Bonnet) Date: Thu, 22 Oct 2009 00:21:23 +0200 Subject: [csw-maintainers] Compilation of X11 libs Message-ID: <4ADF8963.3060003@wbonnet.net> Hi I have started to rebuild X11 according to individual libs versions defined in X11R7.4 Starting tomorrow morning ( GMT 7:00AM :) ) i'll start to rebuild this on the test machine, SPARC first. So i will remove any currently installed X11 package from test8s (aka build8st) and rebuild packages one by one. Please don't really expect it to be finish beforel GMT 7:00 PM. If it is a problem for some of you please let me know. 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 Thu Oct 22 01:04:04 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 22 Oct 2009 00:04:04 +0100 Subject: [csw-maintainers] GAR: Basic custom tests for packages Message-ID: Let's suppose I wanted to write some basic checks for a package. For instance, that I expect there to be a certain file in the prototype, with such and such name and such and such attributes (ownership, permissions, etc). I guess I would do something like: TEST_SCRIPTS = custom test-custom: test code here How do I access things like the prototype, or files at the location from where they're already merged? Maciej From bwalton at opencsw.org Thu Oct 22 04:44:00 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 21 Oct 2009 22:44:00 -0400 Subject: [csw-maintainers] GAR: Basic custom tests for packages In-Reply-To: References: Message-ID: <1256179371-sup-7948@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Wed Oct 21 19:04:04 -0400 2009: > TEST_SCRIPTS = custom > > test-custom: > test code here I think you'd want to work with the state of things after the merge. I don't think the stuff in build-global is guaranteed to be there until after that step. I don't know if there are pre/post merge targets though. HTH -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From daniel at opencsw.org Thu Oct 22 08:25:31 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Thu, 22 Oct 2009 07:25:31 +0100 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4ADFF85B.1040608@cmi.univ-mrs.fr> References: <4ADF312E.8050403@cmi.univ-mrs.fr> <4ADF333D.7010105@opencsw.org> <4ADF36BE.8000307@cmi.univ-mrs.fr> <4ADF378E.50108@opencsw.org> <4ADF3852.2060303@cmi.univ-mrs.fr> <4ADF39A6.7050702@opencsw.org> <4ADF3A08.5030900@cmi.univ-mrs.fr> <4ADF3D02.60207@opencsw.org> <4ADF3DAB.6030004@cmi.univ-mrs.fr> <4ADF48B7.7030200@opencsw.org> <4ADFF85B.1040608@cmi.univ-mrs.fr> Message-ID: <4ADFFADB.8010201@opencsw.org> gerard wrote: > hello daniel, > i'm trying to install ganglia_gmetad into a non global zone on > opensolaris machine (os2008.11), and here are the problems: > - it installs gmond (i never required it) gmond is not required for gmetad to work properly - however, - most people do want the gmond agent on their gmetad host anyway - the default configuration I have provided assumes that a gmond instance is running on the same host as the gmetad, this allows the Ganglia packages to work immediately with no manual configuration effort > - gmond failed to start: > [ Oct 22 07:33:48 Executing start method > ("/var/opt/csw/svc/method/svc-cswgmond start"). ] > ioctl error: No such device or address > [ Oct 22 07:33:48 Method "start" exited with status 0. ] > [ Oct 22 07:33:48 Stopping because all processes in service exited. ] > [ Oct 22 07:33:48 Executing stop method > ("/var/opt/csw/svc/method/svc-cswgmond stop"). ] > [ Oct 22 07:33:48 Method "stop" exited with status 0. ] > [ Oct 22 07:33:48 Restarting too quickly, changing state to maintenance. ] > > The install occurs in a non-global zone, is it forbidden? I haven't personally tested in zones, I know someone else who has tested it and found it doesn't work, the agent needs to be tweaked a little bit > if i want to unstall CSWgangliaagent: > bash-3.2# pkgrm CSWgangliaagent > ... > The package depends on the package > currently being removed. > Dependency checking failed. see above note about dependency > After finishing the install (ganglia_gmetad and ganglia_web), the web > page says that the host monitored is up, but it doesn't display any image!? > there are no errors in apache logs, but the web page at the url: > http://www2/ganglia/graph.php?g=load_report&z=large&c=latp&m=load_one&r=day&s=descending&hc=4&mc=2&st=1256191348 > Have you modified the configuration files, or are you using the configuration files I provide? What is the data_source line in gmetad.conf? Do any of the Ganglia pages work? > displays the following message: > The image > "http://www2/ganglia/graph.php?g=load_report&z=large&c=latp&m=load_one&r=day&s=descending&hc=4&mc=2&st=1256191348" > cannot be displayed, because it contains errors. Try and wget that URL to a file, and look at what is in the file - maybe PHP is spitting out error messages instead of a PNG file > I don't understand what's happen, because with my old releases of > ganglia, i never encountered these problems, only problems with stability. > As i said previously, i'm not using apache from CSW, but apache2 bundled > with the OS (imho, it's anot a good idea to install CSWapache2 when > apache is delivered with the OS). So the only thing i did to configure > the ganglia web is: > - cd /etc/apache2/2.2/conf.d/ > - ln -s /opt/csw/apache2/etc/extra/httpd-ganglia.conf > - svcadm disable cswapache2; svcadm restart apache22 That should probably work, but do make sure your apache2 has PHP support From dam at opencsw.org Thu Oct 22 10:12:02 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 22 Oct 2009 10:12:02 +0200 Subject: [csw-maintainers] GAR: Basic custom tests for packages In-Reply-To: <1256179371-sup-7948@ntdws12.chass.utoronto.ca> References: <1256179371-sup-7948@ntdws12.chass.utoronto.ca> Message-ID: <242BF313-F6AA-492A-BCAE-2F4FF1498BC9@opencsw.org> Hi Maciej, hi Ben, Am 22.10.2009 um 04:44 schrieb Ben Walton: > Am 22.10.2009 um 01:04 schrieb Maciej (Matchek) Blizinski: >> Let's suppose I wanted to write some basic checks for a package. For >> instance, that I expect there to be a certain file in the prototype, >> with such and such name and such and such attributes (ownership, >> permissions, etc). I guess I would do something like: >> >> TEST_SCRIPTS = custom >> >> test-custom: >> test code here >> >> How do I access things like the prototype, or files at the location >> from where they're already merged? > > I think you'd want to work with the state of things after the merge. > I don't think the stuff in build-global is guaranteed to be there > until after that step. I don't know if there are pre/post merge > targets though. Yes. Because the normal cycle for a software is configure compile test install the procedure is the same in GAR. Now to your questions: >> For instance, that I expect there to be a certain file in the >> prototype, >> with such and such name and such and such attributes (ownership, >> permissions, etc) The prototype (if dynamic) is built during 'package' and there is currently no hook in-between after dynamic creation of the packaging source files and the package creation. You could check after package-creation in post-package. >> How do I access things like the prototype, or files at the location >> from where they're already merged? From the global modulation the prototype can be accessed as $(WORKDIR)/prototype and the package specific prototypes as $(WORKDIR)/CSWmypkg.prototype The merge location is available during global or specific modulations as $(PKGROOT). I suggest you write your test as post-package to ensure it has been built correctly. However, if it proves useful we could also insert another step before package creation like pkgverify-CSWmypkg: Best regards -- Dago From phil at bolthole.com Thu Oct 22 18:38:43 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 22 Oct 2009 09:38:43 -0700 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion Message-ID: Ok, so we have previously had the issue raised, of a standard api for builds, to allow things to be checked into our subversion tree, that do NOT use the gar build system. I have now taken a step towards getting this official, by writing up the following: http://sourceforge.net/apps/trac/gar/wiki/RawAPI Please note that the prior suggestion on the mailing list, was to have the top entrypoint be "build". However, in order to avoid potential conflicts with "upstream", yet still keep it relatively short, I thought we should call it "cswbuild". I think the rest is fairly self-explanitory and obvious. There are a few things that most definately should be discussed. One is of course, if there are objections to that name. Another, is whether the "mandatory support" section is too small. Another, is the issue of "where does the result go"? I am not familiar with how "gar" does it. Perhaps people who are already familiar with gar, will suggest good ways to make the two somewhat consistent, while at the same time, resisting the urge to try to turn this into gar ;-) Please note, that the overall goal of this, is to encourage people whose source code is not in subversion, to migrate it into subversion with a minimum of change. Therefore, people in that category are the ones most strongly encouraged to take part in this discussion. From ihsan at opencsw.org Fri Oct 23 14:10:52 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Fri, 23 Oct 2009 14:10:52 +0200 (CEST) Subject: [csw-maintainers] Maintenance on the web & mail server Message-ID: <54eb55ed7972cd83d20154f64d9f7e74.squirrel@mail.opencsw.org> Hello, Tomorrow afternoon I will upgrade the T2000 to the latest Solaris version and migrate the root filesystem to ZFS. During this time mail and web services will be sporadically not available. Start: Saturday 24. October 2009, 10:00 UTC End: Saturday 24. October 2009, 16:00 UTC Please make sure that you are logged out (IMAP & SSH) at that time. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ http://ihsan.dogan.ch/ From maciej at opencsw.org Fri Oct 23 14:44:28 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 23 Oct 2009 13:44:28 +0100 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: References: Message-ID: On Thu, Oct 22, 2009 at 5:38 PM, Philip Brown wrote: > Ok, so we have previously had the issue raised, of a standard api for > builds, to allow things to be checked into our subversion tree, that > do NOT use the gar build system. > > I have now taken a step towards getting this official, by writing up > the following: > > http://sourceforge.net/apps/trac/gar/wiki/RawAPI Thanks for doing that! > Please note that the prior suggestion on the mailing list, was to have > the top entrypoint be "build". However, in order to avoid potential > conflicts with "upstream", yet still keep it relatively short, I > thought we should call it "cswbuild". Looks good to me. > I think the rest is fairly self-explanitory and obvious. There are a > few things that most definately should be discussed. > One is of course, if there are objections to that name. > Another, is whether the "mandatory support" section is too small. I that the main mandatory requirement should be that the packages which are sent to the release manager must be built using this api, on a clean filesystem, on the buildfarm: svn co http://repo-url/pkg/foo cd foo ./cswbuild > Another, is the issue of "where does the result go"? A couple of options: - the same directory as the script - a subdirectory with a standard name - a directory specified in an environment variable - a directory specified in a configuration file on disk > I am not familiar with how "gar" does it. Perhaps people who are > already familiar with gar, will suggest good ways to make the two > somewhat consistent, while at the same time, resisting the urge to try > to turn this into gar ;-) It's specified in ~/.garrc, I don't think it's a good location for the general solution. Perhaps a more general configuration file in the home directory would do the trick? > Please note, that the overall goal of this, is to encourage people > whose source code is not in subversion, to migrate it into subversion > with a minimum of change. > Therefore, people in that category are the ones most strongly > encouraged to take part in this discussion. Are there any other build systems in use in our project? If so, is their source code publicly available? Maciej From phil at bolthole.com Fri Oct 23 17:09:54 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 23 Oct 2009 08:09:54 -0700 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: References: Message-ID: On Fri, Oct 23, 2009 at 5:44 AM, Maciej (Matchek) Blizinski wrote: > On Thu, Oct 22, 2009 at 5:38 PM, Philip Brown wrote: >> >> Another, is the issue of "where does the result go"? >> I am not familiar with how "gar" does it. Perhaps people who are >> already familiar with gar, will suggest good ways to make the two >> somewhat consistent, while at the same time, resisting the urge to try >> to turn this into gar ;-) > > It's specified in ~/.garrc, I don't think it's a good location for the > general solution. what's the default, though? From maciej at opencsw.org Fri Oct 23 17:27:43 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 23 Oct 2009 16:27:43 +0100 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: References: Message-ID: On Fri, Oct 23, 2009 at 4:09 PM, Philip Brown wrote: > On Fri, Oct 23, 2009 at 5:44 AM, Maciej (Matchek) Blizinski > wrote: >> On Thu, Oct 22, 2009 at 5:38 PM, Philip Brown wrote: >>> >>> Another, is the issue of "where does the result go"? >>> I am not familiar with how "gar" does it. Perhaps people who are >>> already familiar with gar, will suggest good ways to make the two >>> somewhat consistent, while at the same time, resisting the urge to try >>> to turn this into gar ;-) >> >> It's specified in ~/.garrc, I don't think it's a good location for the >> general solution. > > what's the default, though? There's no default; you're supposed to create your own ~/.garrc, and the sample file contains: ${HOME}/staging/build-$(date '+%d.%b.%Y') I prefer ISO standards for dates, so I use: ${HOME}/staging/build-$(date '+%Y-%m-%d') (It sorts better.) Maciej From phil at bolthole.com Fri Oct 23 18:48:06 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 23 Oct 2009 09:48:06 -0700 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: References: Message-ID: On Fri, Oct 23, 2009 at 8:27 AM, Maciej (Matchek) Blizinski wrote: > > There's no default; you're supposed to create your own ~/.garrc, and > the sample file contains: > > ${HOME}/staging/build-$(date '+%d.%b.%Y') >[...] > I prefer ISO standards for dates[(it builds better)] definately :-) Hmmm. the non-deterministic nature of that, would make it slightly difficult to have any kind of automated, "Go autobuild 10 packages and add them" script at a customer site. How many people are using something else there, and if so, what? From bwalton at opencsw.org Fri Oct 23 18:59:38 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 23 Oct 2009 12:59:38 -0400 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: References: Message-ID: <1256317003-sup-428@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Oct 23 12:48:06 -0400 2009: > How many people are using something else there, and if so, what? I use ~/staging without any sub structure as I found that cumbersome. Due to the date boundary I often get files with different names than I expect and having the build- directory also have a different name made my tab completion harder if I hadn't cleaned up lately. I'm 100% open to changing my settings to an agreed upon location, or, even better, having GAR set the value irrespective of my local choice. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mwatters at opencsw.org Fri Oct 23 18:59:59 2009 From: mwatters at opencsw.org (Mike Watters) Date: Fri, 23 Oct 2009 11:59:59 -0500 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: References: Message-ID: <4AE1E10F.1070800@opencsw.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philip Brown wrote: > On Fri, Oct 23, 2009 at 8:27 AM, Maciej (Matchek) Blizinski > wrote: >> There's no default; you're supposed to create your own ~/.garrc, and >> the sample file contains: >> >> ${HOME}/staging/build-$(date '+%d.%b.%Y') >> [...] >> I prefer ISO standards for dates[(it builds better)] > > definately :-) > > Hmmm. the non-deterministic nature of that, would make it slightly > difficult to have any kind of automated, > "Go autobuild 10 packages and add them" > script at a customer site. > > How many people are using something else there, and if so, what? > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers Here is mine... I dropped the date as the package has a time stamp in the name. mwatters at login:~ $ cat .garring SPKG_PACKAGER = Mike Watters SPKG_EMAIL = mwatters at opencsw.org SPKG_EXPORT = $(HOME)/newpkgs/$(GARNAME) SPKG_SPOOLDIR = $(HOME)/spool/$(GAROSREL)-$(GARCH) GARCHIVEDIR = $(HOME)/src - -- ~Mike "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." --> Albert Einstein 1879 - 1955 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrh4Q4ACgkQLrhmsXMSLxcoXQCgtepXN1YKQoeEfVNpQ5+PCg6W fZYAnRqTqZogwB0Go1xASFA3d9rcSVWK =uCzD -----END PGP SIGNATURE----- From ihsan at opencsw.org Sat Oct 24 19:47:12 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sat, 24 Oct 2009 19:47:12 +0200 Subject: [csw-maintainers] Maintenance on the web & mail server In-Reply-To: <54eb55ed7972cd83d20154f64d9f7e74.squirrel@mail.opencsw.org> References: <54eb55ed7972cd83d20154f64d9f7e74.squirrel@mail.opencsw.org> Message-ID: <4AE33DA0.9010203@opencsw.org> Thanks for the patience. Everything is up and running again. Am 23.10.2009 14:10 Uhr, Ihsan Dogan schrieb: > Hello, > > Tomorrow afternoon I will upgrade the T2000 to the latest Solaris version > and migrate the root filesystem to ZFS. During this time mail and web > services will be sporadically not available. > > Start: Saturday 24. October 2009, 10:00 UTC > End: Saturday 24. October 2009, 16:00 UTC > > Please make sure that you are logged out (IMAP & SSH) at that time. > > > > Ihsan > -- ihsan at dogan.ch http://blog.dogan.ch/ From ghenry at cmi.univ-mrs.fr Thu Oct 22 08:14:51 2009 From: ghenry at cmi.univ-mrs.fr (gerard) Date: Thu, 22 Oct 2009 08:14:51 +0200 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4ADF48B7.7030200@opencsw.org> References: <4ADF312E.8050403@cmi.univ-mrs.fr> <4ADF333D.7010105@opencsw.org> <4ADF36BE.8000307@cmi.univ-mrs.fr> <4ADF378E.50108@opencsw.org> <4ADF3852.2060303@cmi.univ-mrs.fr> <4ADF39A6.7050702@opencsw.org> <4ADF3A08.5030900@cmi.univ-mrs.fr> <4ADF3D02.60207@opencsw.org> <4ADF3DAB.6030004@cmi.univ-mrs.fr> <4ADF48B7.7030200@opencsw.org> Message-ID: <4ADFF85B.1040608@cmi.univ-mrs.fr> hello daniel, i'm trying to install ganglia_gmetad into a non global zone on opensolaris machine (os2008.11), and here are the problems: - it installs gmond (i never required it) - gmond failed to start: [ Oct 22 07:33:48 Executing start method ("/var/opt/csw/svc/method/svc-cswgmond start"). ] ioctl error: No such device or address [ Oct 22 07:33:48 Method "start" exited with status 0. ] [ Oct 22 07:33:48 Stopping because all processes in service exited. ] [ Oct 22 07:33:48 Executing stop method ("/var/opt/csw/svc/method/svc-cswgmond stop"). ] [ Oct 22 07:33:48 Method "stop" exited with status 0. ] [ Oct 22 07:33:48 Restarting too quickly, changing state to maintenance. ] The install occurs in a non-global zone, is it forbidden? if i want to unstall CSWgangliaagent: bash-3.2# pkgrm CSWgangliaagent ... The package depends on the package currently being removed. Dependency checking failed. After finishing the install (ganglia_gmetad and ganglia_web), the web page says that the host monitored is up, but it doesn't display any image!? there are no errors in apache logs, but the web page at the url: http://www2/ganglia/graph.php?g=load_report&z=large&c=latp&m=load_one&r=day&s=descending&hc=4&mc=2&st=1256191348 displays the following message: The image "http://www2/ganglia/graph.php?g=load_report&z=large&c=latp&m=load_one&r=day&s=descending&hc=4&mc=2&st=1256191348" cannot be displayed, because it contains errors. I don't understand what's happen, because with my old releases of ganglia, i never encountered these problems, only problems with stability. As i said previously, i'm not using apache from CSW, but apache2 bundled with the OS (imho, it's anot a good idea to install CSWapache2 when apache is delivered with the OS). So the only thing i did to configure the ganglia web is: - cd /etc/apache2/2.2/conf.d/ - ln -s /opt/csw/apache2/etc/extra/httpd-ganglia.conf - svcadm disable cswapache2; svcadm restart apache22 thanks in advance for help, gerard From ghenry at cmi.univ-mrs.fr Thu Oct 22 16:33:19 2009 From: ghenry at cmi.univ-mrs.fr (Gerard Henry) Date: Thu, 22 Oct 2009 16:33:19 +0200 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4ADFFADB.8010201@opencsw.org> References: <4ADF312E.8050403@cmi.univ-mrs.fr> <4ADF333D.7010105@opencsw.org> <4ADF36BE.8000307@cmi.univ-mrs.fr> <4ADF378E.50108@opencsw.org> <4ADF3852.2060303@cmi.univ-mrs.fr> <4ADF39A6.7050702@opencsw.org> <4ADF3A08.5030900@cmi.univ-mrs.fr> <4ADF3D02.60207@opencsw.org> <4ADF3DAB.6030004@cmi.univ-mrs.fr> <4ADF48B7.7030200@opencsw.org> <4ADFF85B.1040608@cmi.univ-mrs.fr> <4ADFFADB.8010201@opencsw.org> Message-ID: <4AE06D2F.5030101@cmi.univ-mrs.fr> Daniel Pocock wrote: > > I haven't personally tested in zones, I know someone else who has tested > it and found it doesn't work, the agent needs to be tweaked a little bit > TRying to install all things in a non global zone on a sparc machine: Installing class ... Creating service script in /var/opt/csw/svc/method/svc-cswgmond ... ln: cannot create /var/opt/csw/svc/method/svc-cswgmond: No such file or directory chmod: WARNING: can't access /var/opt/csw/svc/method/svc-cswgmond chown: /var/opt/csw/svc/method/svc-cswgmond: No such file or directory Creating manifest ... egrep: can't open /var/opt/csw/svc/method/svc-cswgmond egrep: can't open /var/opt/csw/svc/method/svc-cswgmond Configuring service in SMF ... CSWgangliaagent is using Service Management Facility. The FMRI is svc:/network/cswgmond:default Enabling svc:/network/cswgmond ... ERROR: attribute verification of failed pathname does not exist unable to create symbolic link to [ verifying class ] Installation of was successful. > > Have you modified the configuration files, or are you using the > configuration files I provide? > the files are slihty modified, just the name of the machnie > What is the data_source line in gmetad.conf? > data_source "latp" 147.94.64.119 147.94.64.10 > Do any of the Ganglia pages work? > yes, all the pages except the graphics >> displays the following message: >> The image >> "http://www2/ganglia/graph.php?g=load_report&z=large&c=latp&m=load_one&r=day&s=descending&hc=4&mc=2&st=1256191348" >> cannot be displayed, because it contains errors. > > Try and wget that URL to a file, and look at what is in the file - maybe > PHP is spitting out error messages instead of a PNG file > >> I don't understand what's happen, because with my old releases of >> ganglia, i never encountered these problems, only problems with >> stability. >> As i said previously, i'm not using apache from CSW, but apache2 >> bundled with the OS (imho, it's anot a good idea to install CSWapache2 >> when apache is delivered with the OS). So the only thing i did to >> configure the ganglia web is: >> - cd /etc/apache2/2.2/conf.d/ >> - ln -s /opt/csw/apache2/etc/extra/httpd-ganglia.conf >> - svcadm disable cswapache2; svcadm restart apache22 > > That should probably work, but do make sure your apache2 has PHP support so to be sure, i re-install ganglia-web on another machine, a sparc, and into a non global zone, same proble as above: Installing class ... Creating service script in /var/opt/csw/svc/method/svc-cswgmetad ... ln: cannot create /var/opt/csw/svc/method/svc-cswgmetad: No such file or directory chmod: WARNING: can't access /var/opt/csw/svc/method/svc-cswgmetad chown: /var/opt/csw/svc/method/svc-cswgmetad: No such file or directory Creating manifest ... egrep: can't open /var/opt/csw/svc/method/svc-cswgmetad egrep: can't open /var/opt/csw/svc/method/svc-cswgmetad Configuring service in SMF ... CSWgangliagmetad is using Service Management Facility. The FMRI is svc:/network/cswgmetad:default Enabling svc:/network/cswgmetad ... ERROR: attribute verification of failed pathname does not exist unable to create symbolic link to [ verifying class ] Installation of was successful. gerard From dam at opencsw.org Sun Oct 25 21:07:21 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 25 Oct 2009 21:07:21 +0100 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> Message-ID: Hi Aubrey, Anfang der weitergeleiteten E-Mail: > Von: Aubrey Li > Datum: 25. Oktober 2009 13:22:02 MEZ > An: Dagobert Michelsen , "Maciej (Matchek) > Blizinski" > Betreff: Fwd: checkpkg problem on opensolaris distribution > > Hi Dago, > > It looks like I'm not on the maintainers' list, and my mail account > aubrey at opencsw.org is not valid any longer, could you please help > me to send this mail out? Fwd'ing to Ihsan. Aubrey has already contributed packages and had an account in the past. Ihsan: Would you mind having a look? Aubrey: To become a permanent member of the OpenCSW project you must apply for membership by writing to board at lists.opencsw.org. The current list of members can be seen at The bylaws can be read at > ---------- Forwarded message ---------- > From: Aubrey Li > Date: Sun, Oct 25, 2009 at 8:14 PM > Subject: checkpkg problem on opensolaris distribution > To: internal list for the CSW maintainers > Aubrey: You have posted to the wrong address. The new address is maintainers at lists.opencsw.org ;-) > I'm not sure how many developers are using OpenSolaris-snvXXX > distribution. > > I run into the following error when I try to build a new package by > "gmake package" > ==================================================== > ........snip........ > Examining 'depend' file > system CSWcommon common - common files and dirs for CSW packages > Cannot find package providing libc.so.1. Storing for delayed > validation. > Cannot find package providing libfl.so.1. Storing for delayed > validation. > SUGGESTION: you may want to add some or all of the following as > depends: > (Feel free to ignore SUNW or SPRO packages) >> CSWncurses > > Doing late evaluations of package library dependencies. > ERROR: Couldn't find a package providing libc.so.1 > gmake: *** [pkgcheck-CSWcscope] Error 2 > ===================================================== > After some investigation, I found the root cause is, checkpkg is using > the package > installation file /var/sadm/install/contents, which is not maintained > on opensolaris > (indiana) distribution. > > Can we enhance this script to support IPS package system? > I have a quick idea similarly like the following patch, > > Any thoughts? I really enjoy seeing progress towards OpenSolaris / IPS support. Hopefully the farm will soon be upgraded to OSOL build hosts. Ben: You have added the current checkpkg logic, would you consider adding the patch as safe? > ============================================== > --- checkpkg 2009-10-25 19:56:04.191980886 +0800 > +++ checkpkg.ips 2009-10-25 19:52:37.856050429 +0800 > @@ -547,11 +547,27 @@ > pkg=`echo $ldep | nawk '{print $2}'` > /usr/xpg4/bin/grep -q "[/=]$lib[ =]" $SETLIBS > if [ $? -ne 0 ]; then > - errmsg "Couldn't find a package providing $lib" > + print "Couldn't find a SVR4 package providing $lib, try > IPS pkg later" > + echo "$lib" >> $SETLIBS.svr4.missing > else > print "A package in the set being evaluated provides $lib" > fi > done < $SETLIBS.missing > fi > > +print "" > + > +if [ -s $SETLIBS.svr4.missing ]; then > + print "Doing late evaluation of IPS package library > dependencies." > + while read idep; do > + BUILD=`uname -v | sed s/snv_//` > + pkg search $idep | grep $BUILD > + if [ $? -ne 0 ]; then > + errmsg "Couldn't find a package providing $idep" > + else > + print "A package in the set being evaluated provides > $idep" > + fi > + done < $SETLIBS.svr4.missing > +fi > + > cleanupset Best regards -- Dago From ihsan at opencsw.org Sun Oct 25 22:46:52 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 25 Oct 2009 22:46:52 +0100 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution In-Reply-To: References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> Message-ID: <4AE4C74C.5050100@opencsw.org> Hello Aubrey, Am 25.10.2009 21:07 Uhr, Dagobert Michelsen schrieb: >> It looks like I'm not on the maintainers' list, and my mail account >> aubrey at opencsw.org is not valid any longer, could you please help >> me to send this mail out? > > Fwd'ing to Ihsan. Aubrey has already contributed packages and had > an account in the past. > > Ihsan: Would you mind having a look? Your Account is still active. What exactly does not work? Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From bwalton at opencsw.org Sun Oct 25 23:25:34 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 25 Oct 2009 18:25:34 -0400 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution In-Reply-To: References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> Message-ID: <1256504000-sup-6703@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Sun Oct 25 16:07:21 -0400 2009: A quick persual of the patch looks ok, but I'd have to actually test it. I don't use opensolaris at all and at this time have no plans to... Also, I'm working on a full replacement for the current checkpkg. My replacement isn't ready yet, but I'd be happy to have this type of stuff built in from the ground up. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From aubrey at opencsw.org Mon Oct 26 03:43:27 2009 From: aubrey at opencsw.org (Aubrey Li) Date: Mon, 26 Oct 2009 10:43:27 +0800 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution In-Reply-To: <1256504000-sup-6703@ntdws12.chass.utoronto.ca> References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> <1256504000-sup-6703@ntdws12.chass.utoronto.ca> Message-ID: <6d6a94c50910251943i3278fb0cq85d0330d52f92497@mail.gmail.com> On Mon, Oct 26, 2009 at 6:25 AM, Ben Walton wrote: > Excerpts from Dagobert Michelsen's message of Sun Oct 25 16:07:21 -0400 2009: > > A quick persual of the patch looks ok, but I'd have to actually test > it. ?I don't use opensolaris at all and at this time have no plans > to... > > Also, I'm working on a full replacement for the current checkpkg. ?My > replacement isn't ready yet, but I'd be happy to have this type of > stuff built in from the ground up. Thanks to take OSOL distro into account. -Aubrey > > -Ben > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu > Contact me to arrange for a CAcert assurance meeting. > From dam at opencsw.org Mon Oct 26 06:12:10 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 26 Oct 2009 06:12:10 +0100 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution In-Reply-To: <1256504000-sup-6703@ntdws12.chass.utoronto.ca> References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> <1256504000-sup-6703@ntdws12.chass.utoronto.ca> Message-ID: Hi Ben, Am 25.10.2009 um 23:25 schrieb Ben Walton: > A quick persual of the patch looks ok, but I'd have to actually test > it. I don't use opensolaris at all and at this time have no plans > to... > > Also, I'm working on a full replacement for the current checkpkg. My > replacement isn't ready yet, but I'd be happy to have this type of > stuff built in from the ground up. Sure, but as the patch only adds another step after it otherwise would have failed I guess it would be safe to apply until the new version is ready, yes? Best regards -- Dago From bwalton at opencsw.org Mon Oct 26 11:27:33 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 26 Oct 2009 06:27:33 -0400 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution In-Reply-To: References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> <1256504000-sup-6703@ntdws12.chass.utoronto.ca> Message-ID: <1256552824-sup-8760@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Mon Oct 26 01:12:10 -0400 2009: > Sure, but as the patch only adds another step after it otherwise > would have failed I guess it would be safe to apply until the > new version is ready, yes? Yes, I'm ok with it. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From aubrey at opencsw.org Mon Oct 26 13:44:08 2009 From: aubrey at opencsw.org (Aubrey Li) Date: Mon, 26 Oct 2009 20:44:08 +0800 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution In-Reply-To: <1256552824-sup-8760@ntdws12.chass.utoronto.ca> References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> <1256504000-sup-6703@ntdws12.chass.utoronto.ca> <1256552824-sup-8760@ntdws12.chass.utoronto.ca> Message-ID: <6d6a94c50910260544w286f80bbyea6ac7d87e27a30b@mail.gmail.com> On Mon, Oct 26, 2009 at 6:27 PM, Ben Walton wrote: > Excerpts from Dagobert Michelsen's message of Mon Oct 26 01:12:10 -0400 2009: > >> Sure, but as the patch only adds another step after it otherwise >> would have failed I guess it would be safe to apply until the >> new version is ready, yes? > > Yes, I'm ok with it. > > Thanks > -Ben please refine the patch and verify it on your side, in case I did something wrong, ;-) Thanks, -Aubrey From ihsan at opencsw.org Mon Oct 26 16:03:06 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Mon, 26 Oct 2009 16:03:06 +0100 (CET) Subject: [csw-maintainers] Apache 2 Package In-Reply-To: <4ADB45B0.1000207@opencsw.org> References: <4ADB45B0.1000207@opencsw.org> Message-ID: <6766af69195aabae43282f90adac196a.squirrel@mail.opencsw.org> > The Apache 2 package needs to be reworked and I can't find any > additional ressources at this time. Would be great if someone could take > over this package. Still no volunteer for this package? Ihsan -- ihsan at dogan.ch http://ihsan.dogan.ch/ From phil at bolthole.com Mon Oct 26 17:09:48 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 26 Oct 2009 09:09:48 -0700 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4AE06D2F.5030101@cmi.univ-mrs.fr> References: <4ADF312E.8050403@cmi.univ-mrs.fr> <4ADF3852.2060303@cmi.univ-mrs.fr> <4ADF39A6.7050702@opencsw.org> <4ADF3A08.5030900@cmi.univ-mrs.fr> <4ADF3D02.60207@opencsw.org> <4ADF3DAB.6030004@cmi.univ-mrs.fr> <4ADF48B7.7030200@opencsw.org> <4ADFF85B.1040608@cmi.univ-mrs.fr> <4ADFFADB.8010201@opencsw.org> <4AE06D2F.5030101@cmi.univ-mrs.fr> Message-ID: On Thu, Oct 22, 2009 at 7:33 AM, Gerard Henry wrote: > > Creating service script in /var/opt/csw/svc/method/svc-cswgmond ... > ln: cannot create /var/opt/csw/svc/method/svc-cswgmond: No such file or > directory So, the questions I would ask are: 1. where is it trying to ln FROM 2. does the directory /var/opt/csw/svc/method/ exist in that case? From phil at bolthole.com Mon Oct 26 17:14:09 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 26 Oct 2009 09:14:09 -0700 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution In-Reply-To: References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> Message-ID: > >> Can we enhance this script to support IPS package system? >> I have a quick idea similarly like the following patch, >>... I think that only really makes sense, when we start distributing packages in IPS format. at which point, we should have a related-but-separate utility, "checkips", I think :-) checkpkg is for creating packages. Right now, people should NOT be creating OpenCSW packages on opensolaris. Only Solaris(tm)(r)(...) For someone who wishes to tinker, but only runs opensolaris at the moment.. it should be easy enough to set up a solaris zone? They could use the "branded zone" type stuff, and install solaris 9 zone, I would think. From schwindt at dfki.uni-kl.de Mon Oct 26 17:14:38 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Mon, 26 Oct 2009 17:14:38 +0100 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: Your message of "Mon, 26 Oct 2009 16:03:06 +0100." <6766af69195aabae43282f90adac196a.squirrel@mail.opencsw.org> Message-ID: <200910261614.n9QGEcOv011294@dfki.uni-kl.de> > > > The Apache 2 package needs to be reworked and I can't find any > > additional ressources at this time. Would be great if someone could take > > over this package. > > Still no volunteer for this package? I would - but this would mean I needed much help on gar. As this would consume a larger amount of time as doing it yourself we have a deadlock .( Nicolai From dam at opencsw.org Mon Oct 26 17:35:02 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 26 Oct 2009 17:35:02 +0100 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: <200910261614.n9QGEcOv011294@dfki.uni-kl.de> References: <200910261614.n9QGEcOv011294@dfki.uni-kl.de> Message-ID: Hi Nicolai, Am 26.10.2009 um 17:14 schrieb Nicolai Schwindt: >>> The Apache 2 package needs to be reworked and I can't find any >>> additional ressources at this time. Would be great if someone >>> could take >>> over this package. >> >> Still no volunteer for this package? > > I would - but this would mean I needed much help on gar. > As this would consume a larger amount of time as doing it yourself > we have a deadlock .( It is not that difficult and the package is already in GAR and you get all the help from maintainers@ for sure :-) Best regards -- Dago From trygvis at opencsw.org Mon Oct 26 18:47:38 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Mon, 26 Oct 2009 18:47:38 +0100 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: References: <200910261614.n9QGEcOv011294@dfki.uni-kl.de> Message-ID: <4AE5E0BA.9000109@opencsw.org> Dagobert Michelsen wrote: > Hi Nicolai, > > Am 26.10.2009 um 17:14 schrieb Nicolai Schwindt: >>>> The Apache 2 package needs to be reworked and I can't find any >>>> additional ressources at this time. Would be great if someone could >>>> take >>>> over this package. >>> >>> Still no volunteer for this package? >> >> I would - but this would mean I needed much help on gar. >> As this would consume a larger amount of time as doing it yourself >> we have a deadlock .( > > It is not that difficult and the package is already in GAR and you > get all the help from maintainers@ for sure :-) There's also the #opencsw IRC channel, see info on out frontpage. -- Trygve From schwindt at dfki.uni-kl.de Mon Oct 26 19:54:42 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Mon, 26 Oct 2009 19:54:42 +0100 Subject: [csw-maintainers] pkginstall question Message-ID: <200910261854.n9QIsg6r014895@dfki.uni-kl.de> The errors on install packages I mentioned a while age still exist. Maybe now someone has an idea. My scenario : fresh install of solaris 10 x86 10u8 pkg-get -i clamav - gives : ... [ verifying class ] Copying sample config to /opt/csw/etc/clamav-milter.conf usage: chmod [-fR] file ... chmod [-fR] file ... chmod [-fR] file ... where is a comma-separated list of [ugoa]{+|-|=}[rwxXlstugo] where is one of the following A- A[number]- A[number]{+|=} where is a comma-separated list of ACEs Copying sample config to /opt/csw/etc/clamd.conf usage: chmod [-fR] file ... chmod [-fR] file ... chmod [-fR] file ... where is a comma-separated list of [ugoa]{+|-|=}[rwxXlstugo] where is one of the following A- A[number]- A[number]{+|=} where is a comma-separated list of ACEs Copying sample config to /opt/csw/etc/freshclam.conf usage: chmod [-fR] file ... chmod [-fR] file ... chmod [-fR] file ... where is a comma-separated list of [ugoa]{+|-|=}[rwxXlstugo] where is one of the following A- A[number]- A[number]{+|=} where is a comma-separated list of ACEs in the package one finds : 1 f cswcpsampleconf /opt/csw/etc/clamav-milter.conf.CSW 0644 root bin 7156 30995 1244712757 Taking a look at /usr/sadm/install/scripts/i.cswcpsampleconf gives the impression ( contents=`grep "^$dest" /var/sadm/install/contents` ) in /var/sadm/install/contents one should find the string "/opt/csw/etc/clamav-milter.conf". But it is not there, not untill after the installation finished. As it remains after pkgrm CSWclamav, from now on pkg-get -i clamav works as expected. You end up with : ll /opt/csw/etc/clamav-milter.conf -rw-r--r-- 1 root root 7156 Oct 26 19:53 /opt/csw/etc/clamav-milter.conf This is not limited to clamav - there are some other packages as well. i.e openssh-client, openssh. Nicolai From bonivart at opencsw.org Mon Oct 26 20:31:45 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 26 Oct 2009 20:31:45 +0100 Subject: [csw-maintainers] pkginstall question In-Reply-To: <200910261854.n9QIsg6r014895@dfki.uni-kl.de> References: <200910261854.n9QIsg6r014895@dfki.uni-kl.de> Message-ID: <625385e30910261231qca73d49xbb94f1e378062345@mail.gmail.com> On Mon, Oct 26, 2009 at 7:54 PM, Nicolai Schwindt wrote: > > The errors on install packages I mentioned a while age still exist. > Maybe now someone has an idea. > > My scenario : fresh install of solaris 10 x86 10u8 > > pkg-get -i clamav ?- gives : > ... > [ verifying class ] > Copying sample config to /opt/csw/etc/clamav-milter.conf > usage: ?chmod [-fR] file ... > ? ? ? ?chmod [-fR] file ... > ? ? ? ?chmod [-fR] file ... > where ? is a comma-separated list of > ? ? ? ?[ugoa]{+|-|=}[rwxXlstugo] > where ? is one of the following > ? ? ? ?A- > ? ? ? ?A[number]- > ? ? ? ?A[number]{+|=} > where ? is a comma-separated list of ACEs > Copying sample config to /opt/csw/etc/clamd.conf > usage: ?chmod [-fR] file ... > ? ? ? ?chmod [-fR] file ... > ? ? ? ?chmod [-fR] file ... > where ? is a comma-separated list of > ? ? ? ?[ugoa]{+|-|=}[rwxXlstugo] > where ? is one of the following > ? ? ? ?A- > ? ? ? ?A[number]- > ? ? ? ?A[number]{+|=} > where ? is a comma-separated list of ACEs > Copying sample config to /opt/csw/etc/freshclam.conf > usage: ?chmod [-fR] file ... > ? ? ? ?chmod [-fR] file ... > ? ? ? ?chmod [-fR] file ... > where ? is a comma-separated list of > ? ? ? ?[ugoa]{+|-|=}[rwxXlstugo] > where ? is one of the following > ? ? ? ?A- > ? ? ? ?A[number]- > ? ? ? ?A[number]{+|=} > where ? is a comma-separated list of ACEs > > > > > in the package one finds : > > 1 f cswcpsampleconf /opt/csw/etc/clamav-milter.conf.CSW 0644 root bin 7156 > 30995 1244712757 > > Taking a look at /usr/sadm/install/scripts/i.cswcpsampleconf gives the > impression > ?( contents=`grep "^$dest" /var/sadm/install/contents` ) ?in > /var/sadm/install/contents > one should find ?the string "/opt/csw/etc/clamav-milter.conf". > > But it is not there, not untill after the installation finished. As it remains > after pkgrm > CSWclamav, from now on pkg-get -i clamav works as expected. > > You end up with : > > ll /opt/csw/etc/clamav-milter.conf > -rw-r--r-- ? 1 root ? ? root ? ? ? ?7156 Oct 26 19:53 > /opt/csw/etc/clamav-milter.conf > > This is not limited to clamav - there are some other packages as well. i.e > openssh-client, > openssh. There's a bug for this: http://www.opencsw.org/mantis/view.php?id=3959 I'll add your notes to that bug. I haven't had much time to look at it. Anything special with your setup? Is this a sparse zone? Latest version of cswclassutils? -- /peter From schwindt at dfki.uni-kl.de Mon Oct 26 20:51:55 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Mon, 26 Oct 2009 20:51:55 +0100 Subject: [csw-maintainers] pkginstall question In-Reply-To: Your message of "Mon, 26 Oct 2009 20:31:45 +0100." <625385e30910261231qca73d49xbb94f1e378062345@mail.gmail.com> Message-ID: <200910261951.n9QJptiN015300@dfki.uni-kl.de> [...] > Anything special with your setup? Is this a sparse zone? Latest > version of cswclassutils? Nothing special - no zones. pkg-get -c cswclassutils # (From site http://serv-1500/blastwave/csw/unstable ) software localrev remoterev cswclassutils 1.22,REV=2009.10.14 SAME serv-1500 is a local mirror syncing once every night. Nicolai From phil at bolthole.com Mon Oct 26 22:12:43 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 26 Oct 2009 14:12:43 -0700 Subject: [csw-maintainers] pkginstall question In-Reply-To: <625385e30910261231qca73d49xbb94f1e378062345@mail.gmail.com> References: <200910261854.n9QIsg6r014895@dfki.uni-kl.de> <625385e30910261231qca73d49xbb94f1e378062345@mail.gmail.com> Message-ID: On Mon, Oct 26, 2009 at 12:31 PM, Peter Bonivart wrote: > >> This is not limited to clamav - there are some other packages as well. i.e >> openssh-client, >> openssh. > > There's a bug for this: http://www.opencsw.org/mantis/view.php?id=3959 > > I'll add your notes to that bug. I haven't had much time to look at it. > oh urg. i was supposed to look at that too, but ran out of time on my last weekend. I'll try to look at it this weekend :-( From aubrey at opensolaris.org Mon Oct 26 01:39:43 2009 From: aubrey at opensolaris.org (Aubrey Li) Date: Mon, 26 Oct 2009 08:39:43 +0800 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution In-Reply-To: <4AE4C74C.5050100@opencsw.org> References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> <4AE4C74C.5050100@opencsw.org> Message-ID: <6d6a94c50910251739n6fd2ce19td7bde4ad6826fc5a@mail.gmail.com> Hi Ihsan, On Mon, Oct 26, 2009 at 5:46 AM, Ihsan Dogan wrote: > Hello Aubrey, > > Am 25.10.2009 21:07 Uhr, Dagobert Michelsen schrieb: > >>> It looks like I'm not on the maintainers' list, and my mail account >>> aubrey at opencsw.org is not valid any longer, could you please help >>> me to send this mail out? >> >> Fwd'ing to Ihsan. Aubrey has already contributed packages and had >> an account in the past. >> >> Ihsan: Would you mind having a look? > > Your Account is still active. What exactly does not work? my mail address(aubrey AT opencsw.org) doesn't work, I can't receive any mail from it. So I think I can't post this mail to maintainers@ as well, could you please take a look? Thanks, -Aubrey > > > > Ihsan > > -- > ihsan at dogan.ch ? ? ? ? ?http://blog.dogan.ch/ > From bonivart at opencsw.org Mon Oct 26 22:38:01 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 26 Oct 2009 22:38:01 +0100 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution In-Reply-To: <6d6a94c50910251739n6fd2ce19td7bde4ad6826fc5a@mail.gmail.com> References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> <4AE4C74C.5050100@opencsw.org> <6d6a94c50910251739n6fd2ce19td7bde4ad6826fc5a@mail.gmail.com> Message-ID: <625385e30910261438n1e21d653k4dd348da4c27dc67@mail.gmail.com> On Mon, Oct 26, 2009 at 1:39 AM, Aubrey Li wrote: > my mail address(aubrey AT opencsw.org) doesn't work, I can't receive any > mail from it. How are you checking that? How do you access it? Are you redirecting it to another account? -- /peter From bonivart at opencsw.org Mon Oct 26 23:45:59 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 26 Oct 2009 23:45:59 +0100 Subject: [csw-maintainers] pkginstall question In-Reply-To: <200910261951.n9QJptiN015300@dfki.uni-kl.de> References: <625385e30910261231qca73d49xbb94f1e378062345@mail.gmail.com> <200910261951.n9QJptiN015300@dfki.uni-kl.de> Message-ID: <625385e30910261545y7abe549emde0ae64914b1ceb4@mail.gmail.com> On Mon, Oct 26, 2009 at 8:51 PM, Nicolai Schwindt wrote: > [...] >> Anything special with your setup? Is this a sparse zone? Latest >> version of cswclassutils? > > Nothing special - no zones. > > pkg-get -c cswclassutils > # (From site http://serv-1500/blastwave/csw/unstable ) > ? ? ? software ? ? ? ? ? ? ? ? ? ? ? ?localrev ? ? ? ? ? ? ? ? ? ? ?remoterev > ?cswclassutils ? ? ? ? ? ? 1.22,REV=2009.10.14 ? ? ? ? ? ? ? ? ? ? ? ? ? SAME Must be some difference between our systems, this is the same install: Installing class ... Group clamav has been added User clamav has been added [ verifying class ] /var/opt/csw/clamav/db/daily.cvd /var/opt/csw/clamav/db/main.cvd [ verifying class ] Copying sample config to /opt/csw/etc/clamav-milter.conf Copying sample config to /opt/csw/etc/clamd.conf Copying sample config to /opt/csw/etc/freshclam.conf [ verifying class ] Installing class ... Creating /var/opt/csw/svc/manifest/network ... Creating service script in /var/opt/csw/svc/method/svc-cswclamav-milter ... Creating manifest ... Configuring service in SMF ... CSWclamav is using Service Management Facility. The FMRI is svc:/network/cswclamav-milter:default Enabling svc:/network/cswclamav-milter ... Creating service script in /var/opt/csw/svc/method/svc-cswclamd ... Creating manifest ... Configuring service in SMF ... CSWclamav is using Service Management Facility. The FMRI is svc:/network/cswclamd:default Enabling svc:/network/cswclamd ... [ verifying class ] Installation of was successful. I also had cswclassutils 1.22 and no previous install of clamav. What could cause my contents file to be populated but not yours? -- /peter From aubrey at opencsw.org Tue Oct 27 02:30:02 2009 From: aubrey at opencsw.org (Aubrey Li) Date: Tue, 27 Oct 2009 09:30:02 +0800 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution In-Reply-To: <625385e30910261438n1e21d653k4dd348da4c27dc67@mail.gmail.com> References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> <4AE4C74C.5050100@opencsw.org> <6d6a94c50910251739n6fd2ce19td7bde4ad6826fc5a@mail.gmail.com> <625385e30910261438n1e21d653k4dd348da4c27dc67@mail.gmail.com> Message-ID: <6d6a94c50910261830vaa3641esb9aaecdef3049892@mail.gmail.com> Hi Ihsan, Peter, It works now, thanks! -Aubrey On Tue, Oct 27, 2009 at 5:38 AM, Peter Bonivart wrote: > On Mon, Oct 26, 2009 at 1:39 AM, Aubrey Li wrote: >> my mail address(aubrey AT opencsw.org) doesn't work, I can't receive any >> mail from it. > > How are you checking that? How do you access it? Are you redirecting > it to another account? > > -- > /peter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > From aubrey at opencsw.org Tue Oct 27 02:50:07 2009 From: aubrey at opencsw.org (Aubrey Li) Date: Tue, 27 Oct 2009 09:50:07 +0800 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution In-Reply-To: References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> Message-ID: <6d6a94c50910261850j15210e7crf5874283cf11dfc@mail.gmail.com> On Tue, Oct 27, 2009 at 12:14 AM, Philip Brown wrote: >> >>> Can we enhance this script to support IPS package system? >>> I have a quick idea similarly like the following patch, >>>... > > > I think that only really makes sense, when we start distributing > packages in IPS format. > > at which point, we should have a related-but-separate utility, > "checkips", I think :-) > > checkpkg is for creating packages. Right now, people should NOT be > creating OpenCSW packages on opensolaris. Only Solaris(tm)(r)(...) > > For someone who wishes to tinker, but only runs opensolaris at the > moment.. it should be easy enough to set up a solaris zone? > They could use the "branded zone" type stuff, and install solaris 9 > zone, I would think. solaris zone is a luxurious environment for me to do the development. opensolaris supports both SVR4 and IPS. I can use opencsw package on osol, for what reason we should NOT create package on osol? Sooner or later when SUN kill SXCE, osol will be my only choice to do the developement. When I digged into the scipt "checkpkg", I found the price is not high to support osol distribution. So, could you please give a shot on osol? It's really not bad, :-) Thanks, -Aubrey From aubrey at opencsw.org Tue Oct 27 06:57:49 2009 From: aubrey at opencsw.org (Aubrey Li) Date: Tue, 27 Oct 2009 13:57:49 +0800 Subject: [csw-maintainers] CSWcscope is in tesing Message-ID: <6d6a94c50910262257k1f90630j93ecbdbab725ca35@mail.gmail.com> Hi list, My first package CSWcscope is in testing, I really appreciate your testing and feedback. Thanks, -Aubrey From dam at opencsw.org Tue Oct 27 10:28:33 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 27 Oct 2009 10:28:33 +0100 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4AAB32A6.5060305@opencsw.org> <64360.194.246.122.22.1253185698.squirrel@ssl.skayser.de> Message-ID: Hi Maciej, Am 19.10.2009 um 01:39 schrieb Maciej (Matchek) Blizinski: > I've written the first version of cswmigrateconf, a class utility > script which migrates configuration files from /opt/csw/etc to > /etc/opt/csw. It works the way Sebastian has suggested, i.e.: It makes > an intermediate copy in /opt/csw/etc/migration-archive, and then uses > it as a source to populate /etc/opt/csw. This is very useful. Thanks! I guess I'll update all my packages needing migration with this. With this kind of tools packaging is fun :-) In addition to migrating single files is there the possibility to migrate complete directories? Like /opt/csw/var/postgresql/ to /var/opt/csw/posgresql/ ? Best regards -- Dago From phil at bolthole.com Tue Oct 27 17:16:46 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 27 Oct 2009 09:16:46 -0700 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution In-Reply-To: <6d6a94c50910261850j15210e7crf5874283cf11dfc@mail.gmail.com> References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> <6d6a94c50910261850j15210e7crf5874283cf11dfc@mail.gmail.com> Message-ID: On Mon, Oct 26, 2009 at 6:50 PM, Aubrey Li wrote: > > opensolaris supports both SVR4 and IPS. I can use opencsw package > on osol, for what reason we should NOT create package on osol? for the exact reason that was brought up: it's "different" :-) and reasonable, sane things that work on normal solaris, dont work on opensolaris. It is also quite likely, that you will end up doing things that work on opensolaris, that do NOT work on normal solaris. So, best not to do it. Please set up a zone on your own machines, or if not, use our opencsw build/test machines. that's what they are here for, after all. From dam at opencsw.org Tue Oct 27 18:00:03 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 27 Oct 2009 18:00:03 +0100 Subject: [csw-maintainers] checkpkg problem on opensolaris distribution In-Reply-To: References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> <6d6a94c50910261850j15210e7crf5874283cf11dfc@mail.gmail.com> Message-ID: <211F94FD-A92B-48FB-898C-8D439A394A55@opencsw.org> Hi, Am 27.10.2009 um 17:16 schrieb Philip Brown: > On Mon, Oct 26, 2009 at 6:50 PM, Aubrey Li wrote: >> >> opensolaris supports both SVR4 and IPS. I can use opencsw package >> on osol, for what reason we should NOT create package on osol? > > for the exact reason that was brought up: it's "different" :-) and > reasonable, sane things that work on normal solaris, dont work on > opensolaris. > It is also quite likely, that you will end up doing things that work > on opensolaris, that do NOT work on normal solaris. > > So, best not to do it. > > Please set up a zone on your own machines, or if not, use our opencsw > build/test machines. that's what they are here for, after all. To clarify this some more: This is for the official OpenCSW packages released to current/. However, work is being done to add a repository for IPS packages for OpenSolaris and you are very welcome to drive the work in that direction, especially package conversion (I heard Trygve has started work on this), porting of the cswutils to OpenSolaris and a naive GAR IPS backend. Best regards -- Dago From trygvis at opencsw.org Tue Oct 27 20:51:47 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Tue, 27 Oct 2009 20:51:47 +0100 Subject: [csw-maintainers] checkpkg problem on opensolaris distribution In-Reply-To: <211F94FD-A92B-48FB-898C-8D439A394A55@opencsw.org> References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> <6d6a94c50910261850j15210e7crf5874283cf11dfc@mail.gmail.com> <211F94FD-A92B-48FB-898C-8D439A394A55@opencsw.org> Message-ID: <4AE74F53.3050200@opencsw.org> Dagobert Michelsen wrote: > Hi, > > Am 27.10.2009 um 17:16 schrieb Philip Brown: >> On Mon, Oct 26, 2009 at 6:50 PM, Aubrey Li wrote: >>> >>> opensolaris supports both SVR4 and IPS. I can use opencsw package >>> on osol, for what reason we should NOT create package on osol? >> >> for the exact reason that was brought up: it's "different" :-) and >> reasonable, sane things that work on normal solaris, dont work on >> opensolaris. >> It is also quite likely, that you will end up doing things that work >> on opensolaris, that do NOT work on normal solaris. >> >> So, best not to do it. >> >> Please set up a zone on your own machines, or if not, use our opencsw >> build/test machines. that's what they are here for, after all. > > To clarify this some more: This is for the official OpenCSW > packages released to current/. However, work is being done > to add a repository for IPS packages for OpenSolaris and you > are very welcome to drive the work in that direction, especially > package conversion (I heard Trygve has started work on this), > porting of the cswutils to OpenSolaris and a naive GAR IPS > backend. The only thing I've work on is creating a useful tool to convert from .pkg to .ips instead of Sun's junk. It's in a working state and I've installed lots of OpenCSW packages from my converted repository. -- Trygve From phil at bolthole.com Tue Oct 27 21:30:23 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 27 Oct 2009 13:30:23 -0700 Subject: [csw-maintainers] checkpkg problem on opensolaris distribution In-Reply-To: <4AE74F53.3050200@opencsw.org> References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> <6d6a94c50910261850j15210e7crf5874283cf11dfc@mail.gmail.com> <211F94FD-A92B-48FB-898C-8D439A394A55@opencsw.org> <4AE74F53.3050200@opencsw.org> Message-ID: 2009/10/27 Trygve Laugst?l : > > The only thing I've work on is creating a useful tool to convert from > .pkg to .ips instead of Sun's junk. It's in a working state and I've > installed lots of OpenCSW packages from my converted repository. > wow, excellent! have you made, or do you plan to make, a "checkips" tool then? From trygvis at opencsw.org Tue Oct 27 22:33:51 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Tue, 27 Oct 2009 22:33:51 +0100 Subject: [csw-maintainers] checkpkg problem on opensolaris distribution In-Reply-To: References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> <6d6a94c50910261850j15210e7crf5874283cf11dfc@mail.gmail.com> <211F94FD-A92B-48FB-898C-8D439A394A55@opencsw.org> <4AE74F53.3050200@opencsw.org> Message-ID: <4AE7673F.5030507@opencsw.org> Philip Brown wrote: > 2009/10/27 Trygve Laugst?l : >> The only thing I've work on is creating a useful tool to convert from >> .pkg to .ips instead of Sun's junk. It's in a working state and I've >> installed lots of OpenCSW packages from my converted repository. >> > > wow, excellent! > > have you made, or do you plan to make, a "checkips" tool then? My tool only does a one to one convertion from a pkg file to a "ips file" so no, I just copy the "prototype", dependencies and most of the stuff from pkgmap. -- Trygve From bonivart at opencsw.org Wed Oct 28 10:59:34 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 28 Oct 2009 10:59:34 +0100 Subject: [csw-maintainers] pkginstall question In-Reply-To: <200910261951.n9QJptiN015300@dfki.uni-kl.de> References: <625385e30910261231qca73d49xbb94f1e378062345@mail.gmail.com> <200910261951.n9QJptiN015300@dfki.uni-kl.de> Message-ID: <625385e30910280259y77676329u8fc476812b82e5dc@mail.gmail.com> Dago found that people having well patched servers ;-) could run into this due to a new cool feature in Solaris 10 called turbo charged packages. Writes to the contents file are being delayed and synced regularly instead of written immediately which should give a significant performance boost. This is included in Solaris 10 update 8 (10/09) and you can also get it via patch 119254/199255. I have now added a sync which should flush all pending writes to the contents file before using it in cpsampleconf and preserveconf. I have tested it with and without the patch and it works for me but I want a few more to confirm so we can have a quick release. So please help test cswclassutils 1.27 in testing. Some packages to test with are: CSWclamav, CSWossh and CSWcacertificates. If you maintain packages that use cpsampleconf or preserveconf, please test them. http://mirror.opencsw.org/testing/cswclassutils-1.27,REV=2009.10.28-SunOS5.8-all-CSW.pkg.gz -- /peter From daniel at opencsw.org Wed Oct 28 18:04:25 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 28 Oct 2009 17:04:25 +0000 Subject: [csw-maintainers] Ganglia for sparcv9 Message-ID: <4AE87999.6020401@opencsw.org> I've added BUILD64 = 1 to my Ganglia package Makefile, so that I can build 64 bit support. This is important because Ganglia makes calls to kstat and that needs to be done from 64 bit code when running on a 64 bit kernel. However, I'm finding that some dependencies are not 64 bit. The key ones that I am currently stuck on: /opt/csw/apache2/lib/libapr-1.so.0 /opt/csw/lib/sparcv8/libsasl2.so.2 /opt/csw/lib/sparcv8/libnet.so Can anyone assist with this or make any comments on these issues? From ihsan at dogan.ch Wed Oct 28 18:04:08 2009 From: ihsan at dogan.ch (Ihsan Dogan) Date: Wed, 28 Oct 2009 18:04:08 +0100 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: <200910261614.n9QGEcOv011294@dfki.uni-kl.de> References: <200910261614.n9QGEcOv011294@dfki.uni-kl.de> Message-ID: <4AE87988.5070401@dogan.ch> On 26.10.2009 17:14, Nicolai Schwindt wrote: >>> The Apache 2 package needs to be reworked and I can't find any >>> additional ressources at this time. Would be great if someone could take >>> over this package. >> Still no volunteer for this package? > > I would - but this would mean I needed much help on gar. > As this would consume a larger amount of time as doing it yourself > we have a deadlock .( It would be really great if you could take over this package. As the others already mentioned, Gar is really not difficult and you can always ask here on the maintainers list. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From phil at bolthole.com Wed Oct 28 18:15:46 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 28 Oct 2009 10:15:46 -0700 Subject: [csw-maintainers] Ganglia for sparcv9 In-Reply-To: <4AE87999.6020401@opencsw.org> References: <4AE87999.6020401@opencsw.org> Message-ID: On Wed, Oct 28, 2009 at 10:04 AM, Daniel Pocock wrote: > > > However, I'm finding that some dependencies are not 64 bit. ?The key ones > that I am currently stuck on: > > /opt/csw/apache2/lib/libapr-1.so.0 ... > Can anyone assist with this or make any comments on these issues? > > comment: 1, we need an apache2 maintainer 2. we need a split-out "libapr" package Sorry, that's all I got :-} From dam at opencsw.org Wed Oct 28 18:24:51 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 28 Oct 2009 18:24:51 +0100 Subject: [csw-maintainers] Revision in package versions Message-ID: <061B3F7D-E261-483A-BF56-358F68524D0D@opencsw.org> Hi folks, Aubrey has just finished a nice new cscope package, thanks! :-) It has the version 15.7a: cscope-15.7a,REV=2009.10.27-SunOS5.8-i386-CSW.pkg.gz I remember that we introduced some kind of "sub revisions" like 15.7,REV=2009.10.27_rev=a Now that pkg-get has been converted to use REV-dates I guess the sub-revisions are no longer needed and can be thrown out of all the build manifests, yes? Best regards -- Dago From bwalton at opencsw.org Wed Oct 28 18:38:41 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 28 Oct 2009 13:38:41 -0400 Subject: [csw-maintainers] Revision in package versions In-Reply-To: <061B3F7D-E261-483A-BF56-358F68524D0D@opencsw.org> References: <061B3F7D-E261-483A-BF56-358F68524D0D@opencsw.org> Message-ID: <1256751287-sup-4952@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Oct 28 13:24:51 -0400 2009: > I remember that we introduced some kind of "sub revisions" like > 15.7,REV=2009.10.27_rev=a My ruby packages are using: 1.8.7,REV=%Y.%m.%d_rev=p$(patchlevel) In the case of ruby, at least, this $(patchlevel) portion is of significance to users in order to determine if the package has the lastest upstream security updates rolled in. > Now that pkg-get has been converted to use REV-dates I guess the > sub-revisions are no longer needed and can be thrown out of all the > build manifests, yes? For version comparison purposes, they're already ignored (at least in pkgutil). I'd vote to keep them around though, as they do convey important version information to humans and shouldn't hurt anything else. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Wed Oct 28 18:48:48 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 28 Oct 2009 18:48:48 +0100 Subject: [csw-maintainers] Revision in package versions In-Reply-To: <1256751287-sup-4952@ntdws12.chass.utoronto.ca> References: <061B3F7D-E261-483A-BF56-358F68524D0D@opencsw.org> <1256751287-sup-4952@ntdws12.chass.utoronto.ca> Message-ID: <625385e30910281048y29084745h29db443ee66bfea7@mail.gmail.com> On Wed, Oct 28, 2009 at 6:38 PM, Ben Walton wrote: > For version comparison purposes, they're already ignored (at least in > pkgutil). ?I'd vote to keep them around though, as they do convey > important version information to humans and shouldn't hurt anything > else. Yes, but couldn't you just change 1.8.7,REV=2009.08.06_rev=p174 into 1.8.7p174,REV=2009.08.06? Same info but looks nicer. :-) -- /peter From bwalton at opencsw.org Wed Oct 28 18:56:50 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 28 Oct 2009 13:56:50 -0400 Subject: [csw-maintainers] Revision in package versions In-Reply-To: <625385e30910281048y29084745h29db443ee66bfea7@mail.gmail.com> References: <061B3F7D-E261-483A-BF56-358F68524D0D@opencsw.org> <1256751287-sup-4952@ntdws12.chass.utoronto.ca> <625385e30910281048y29084745h29db443ee66bfea7@mail.gmail.com> Message-ID: <1256752566-sup-6151@ntdws12.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Wed Oct 28 13:48:48 -0400 2009: > Yes, but couldn't you just change 1.8.7,REV=2009.08.06_rev=p174 into > 1.8.7p174,REV=2009.08.06? Yes, I'd be happy to do that. I misunderstood what Dago was saying, if that was also his intended change. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Wed Oct 28 19:15:47 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 28 Oct 2009 19:15:47 +0100 Subject: [csw-maintainers] Revision in package versions In-Reply-To: <1256752566-sup-6151@ntdws12.chass.utoronto.ca> References: <061B3F7D-E261-483A-BF56-358F68524D0D@opencsw.org> <1256751287-sup-4952@ntdws12.chass.utoronto.ca> <625385e30910281048y29084745h29db443ee66bfea7@mail.gmail.com> <1256752566-sup-6151@ntdws12.chass.utoronto.ca> Message-ID: <5C066E93-C4E6-4012-853D-99581B8AD977@opencsw.org> Hi, Am 28.10.2009 um 18:56 schrieb Ben Walton: > Excerpts from Peter Bonivart's message of Wed Oct 28 13:48:48 -0400 > 2009: >> Yes, but couldn't you just change 1.8.7,REV=2009.08.06_rev=p174 into >> 1.8.7p174,REV=2009.08.06? > > Yes, I'd be happy to do that. I misunderstood what Dago was saying, > if that was also his intended change. Yes, that was my intended change. Peter is already ok with it. Phil: Can we ditch ",rev=" in favor of appending it to the version? Best regards -- Dago From phil at bolthole.com Wed Oct 28 19:22:12 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 28 Oct 2009 11:22:12 -0700 Subject: [csw-maintainers] Revision in package versions In-Reply-To: <5C066E93-C4E6-4012-853D-99581B8AD977@opencsw.org> References: <061B3F7D-E261-483A-BF56-358F68524D0D@opencsw.org> <1256751287-sup-4952@ntdws12.chass.utoronto.ca> <625385e30910281048y29084745h29db443ee66bfea7@mail.gmail.com> <1256752566-sup-6151@ntdws12.chass.utoronto.ca> <5C066E93-C4E6-4012-853D-99581B8AD977@opencsw.org> Message-ID: On Wed, Oct 28, 2009 at 11:15 AM, Dagobert Michelsen wrote: > > Phil: Can we ditch ",rev=" in favor of appending it to the version[-number, before the "REV" substring]? Yes. From dam at opencsw.org Wed Oct 28 19:42:17 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 28 Oct 2009 19:42:17 +0100 Subject: [csw-maintainers] Revision in package versions In-Reply-To: References: <061B3F7D-E261-483A-BF56-358F68524D0D@opencsw.org> <1256751287-sup-4952@ntdws12.chass.utoronto.ca> <625385e30910281048y29084745h29db443ee66bfea7@mail.gmail.com> <1256752566-sup-6151@ntdws12.chass.utoronto.ca> <5C066E93-C4E6-4012-853D-99581B8AD977@opencsw.org> Message-ID: Hi, Am 28.10.2009 um 19:22 schrieb Philip Brown: > On Wed, Oct 28, 2009 at 11:15 AM, Dagobert Michelsen > wrote: >> >> Phil: Can we ditch ",rev=" in favor of appending it to the version[- >> number, before the "REV" substring]? > > Yes. Ok then, I propose to officially deprecate the usage of the ,rev= string and append it to the version. That would mean the docs would state that it is deprecated and packages with _rev would be no longer accepted for release. Oppinions? Best regards -- Dago From bwalton at opencsw.org Wed Oct 28 19:46:12 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 28 Oct 2009 14:46:12 -0400 Subject: [csw-maintainers] Revision in package versions In-Reply-To: References: <061B3F7D-E261-483A-BF56-358F68524D0D@opencsw.org> <1256751287-sup-4952@ntdws12.chass.utoronto.ca> <625385e30910281048y29084745h29db443ee66bfea7@mail.gmail.com> <1256752566-sup-6151@ntdws12.chass.utoronto.ca> <5C066E93-C4E6-4012-853D-99581B8AD977@opencsw.org> Message-ID: <1256755551-sup-2441@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Oct 28 14:42:17 -0400 2009: > Oppinions? +1 -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From daniel at opencsw.org Wed Oct 28 20:43:17 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 28 Oct 2009 19:43:17 +0000 Subject: [csw-maintainers] Ganglia for sparcv9 In-Reply-To: References: <4AE87999.6020401@opencsw.org> Message-ID: <4AE89ED5.7050404@opencsw.org> Philip Brown wrote: > On Wed, Oct 28, 2009 at 10:04 AM, Daniel Pocock wrote: > >> However, I'm finding that some dependencies are not 64 bit. The key ones >> that I am currently stuck on: >> >> /opt/csw/apache2/lib/libapr-1.so.0 >> > ... > >> Can anyone assist with this or make any comments on these issues? >> >> >> > > comment: > > 1, we need an apache2 maintainer > 2. we need a split-out "libapr" package > split-out by the same maintainer, or completely independently packaged? should apache continue to use it's own apr package, and then we would have a separate apr too? > Sorry, that's all I got :-} > Anything helps - I've only built two packages so far, so there's a lot of background I have to catch up on From trygvis at opencsw.org Wed Oct 28 21:15:40 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Wed, 28 Oct 2009 21:15:40 +0100 Subject: [csw-maintainers] Revision in package versions In-Reply-To: References: <061B3F7D-E261-483A-BF56-358F68524D0D@opencsw.org> <1256751287-sup-4952@ntdws12.chass.utoronto.ca> <625385e30910281048y29084745h29db443ee66bfea7@mail.gmail.com> <1256752566-sup-6151@ntdws12.chass.utoronto.ca> <5C066E93-C4E6-4012-853D-99581B8AD977@opencsw.org> Message-ID: <4AE8A66C.9030803@opencsw.org> Dagobert Michelsen wrote: > Hi, > > Am 28.10.2009 um 19:22 schrieb Philip Brown: >> On Wed, Oct 28, 2009 at 11:15 AM, Dagobert Michelsen >> wrote: >>> >>> Phil: Can we ditch ",rev=" in favor of appending it to the >>> version[-number, before the "REV" substring]? >> >> Yes. > > Ok then, I propose to officially deprecate the usage of the ,rev= string > and append it to the version. That would mean the docs would state that it > is deprecated and packages with _rev would be no longer accepted for > release. +1 -- Trygve From william at wbonnet.net Wed Oct 28 22:39:58 2009 From: william at wbonnet.net (William Bonnet) Date: Wed, 28 Oct 2009 22:39:58 +0100 Subject: [csw-maintainers] Revision in package versions In-Reply-To: <4AE8A66C.9030803@opencsw.org> References: <061B3F7D-E261-483A-BF56-358F68524D0D@opencsw.org> <1256751287-sup-4952@ntdws12.chass.utoronto.ca> <625385e30910281048y29084745h29db443ee66bfea7@mail.gmail.com> <1256752566-sup-6151@ntdws12.chass.utoronto.ca> <5C066E93-C4E6-4012-853D-99581B8AD977@opencsw.org> <4AE8A66C.9030803@opencsw.org> Message-ID: <4AE8BA2E.2010404@wbonnet.net> Hi >> >> Ok then, I propose to officially deprecate the usage of the ,rev= string >> and append it to the version. That would mean the docs would state >> that it >> is deprecated and packages with _rev would be no longer accepted for >> release. > > +1 > +1 -- 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 Thu Oct 29 11:21:31 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 29 Oct 2009 11:21:31 +0100 Subject: [csw-maintainers] New library 'jack' wants to be build with 'waf' Message-ID: <47F4C2E7-7170-4DA0-B287-ED592FE6328C@opencsw.org> Hi, I just tried to build a dependency for libsndfile 'jack' which wants to be built with the waf build system: http://code.google.com/p/waf/ I haven't seen much of it, by I already hate it... Maybe someone has already gained some experience with it? I tried adding support for WAF to GAR and made preliminary makefile for jack, everything is in GAR. Comments welcome. Best regards -- Dago From phil at bolthole.com Thu Oct 29 18:55:44 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 29 Oct 2009 10:55:44 -0700 Subject: [csw-maintainers] Ganglia for sparcv9 In-Reply-To: <4AE89ED5.7050404@opencsw.org> References: <4AE87999.6020401@opencsw.org> <4AE89ED5.7050404@opencsw.org> Message-ID: On Wed, Oct 28, 2009 at 12:43 PM, Daniel Pocock wrote: > Philip Brown wrote: >> >> comment: >> >> ... >> 2. we need a split-out "libapr" package >> > > split-out by the same maintainer, or completely independently packaged? just as a splitout pacakge, so certain things can depend on that package instead of "apache" in general. apache itself should use this libapr package, I would think. From phil at bolthole.com Fri Oct 30 00:59:48 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 29 Oct 2009 16:59:48 -0700 Subject: [csw-maintainers] final request for samba Message-ID: Last call, for someone to be a samba maintainer. We've been lacking a modern samba maintainer for a Very Long Time. We NEED a recent samba. Because of the overwhelming need for this, if no-one steps up to do it right, I'm going to do a very rare thing, and make an exception for usual good practice. I'm going to just make one large huge ugly single package, dump it in testing for a while, and then release it. I'd really rather not do this. Firstly, because there are a whole bunch of other things I should be doing with my time :-/ (which is why I cant do it "nicely") But we need it done. From bwalton at opencsw.org Fri Oct 30 03:26:24 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 29 Oct 2009 22:26:24 -0400 Subject: [csw-maintainers] final request for samba In-Reply-To: References: Message-ID: <1256869503-sup-9699@ntdws12.chass.utoronto.ca> Where do the previously released build notes/scripts/magic incantations reside? I'll take a look at it. I can't guarantee a lot of time right now, but I can move it forward toward an easily splittable package in gar. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Oct 30 17:06:32 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 30 Oct 2009 09:06:32 -0700 Subject: [csw-maintainers] final request for samba In-Reply-To: <1256869503-sup-9699@ntdws12.chass.utoronto.ca> References: <1256869503-sup-9699@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Oct 29, 2009 at 7:26 PM, Ben Walton wrote: > Where do the previously released build notes/scripts/magic > incantations reside? > pretty much nonexistent. oh wait. I have some from when I put together my quick-n-dirty thing currently in testing, from 2008. login:~phil/pkgs/samba/BUILD.NOTES Its not exactly a trivial build. but I automated most of it with my notes and patchfile From bwalton at opencsw.org Fri Oct 30 17:09:46 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 30 Oct 2009 12:09:46 -0400 Subject: [csw-maintainers] final request for samba In-Reply-To: References: <1256869503-sup-9699@ntdws12.chass.utoronto.ca> Message-ID: <1256918919-sup-7569@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Oct 30 12:06:32 -0400 2009: > oh wait. I have some from when I put together my quick-n-dirty thing > currently in testing, from 2008. > > login:~phil/pkgs/samba/BUILD. It's a start. At the very least, a starting point for options to configure. > Its not exactly a trivial build. but I automated most of it with my > notes and patchfile ...I can't remember the last time I saw a ./configure take so long and run so many tests. Not trivial indeed. I'll see what I can do with your notes and patch. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Oct 30 17:47:12 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 30 Oct 2009 12:47:12 -0400 Subject: [csw-maintainers] cswcommon update request Message-ID: <1256921216-sup-7652@ntdws12.chass.utoronto.ca> Hi Phil, Can you add the following directories to cswcommon to support 4 new hooks? * preargproc: /etc/opt/csw/pkg-hooks/preargproc.d/ * postargproc: /etc/opt/csw/pkg-hooks/postargproc.d/ * prefetch: /etc/opt/csw/pkg-hooks/prefetch.d/ * postfetch: /etc/opt/csw/pkg-hooks/postfetch.d/ Could you ping the list when this hits current as William will have some tools waiting on this availability. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Oct 30 17:53:25 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 30 Oct 2009 09:53:25 -0700 Subject: [csw-maintainers] cswcommon update request In-Reply-To: <1256921216-sup-7652@ntdws12.chass.utoronto.ca> References: <1256921216-sup-7652@ntdws12.chass.utoronto.ca> Message-ID: cswcommon should almost NEVER be updated. Its a very user-freaky thing to change. I dont like making changes like this, for something that is apparently in flux. Last change to cswcommon was barely a month ago, and it was for hooks again. This is too soon to make another change. Please just put in the definitions, into whatever uses it for now. (ie: define the directories with appropriate permissions) there is no harm in having multiple packages define the directories. After 6 months to a year has gone by, and there are no further changes in "hooks" over that timeperiod, then please re-request a change at that time. On Fri, Oct 30, 2009 at 9:47 AM, Ben Walton wrote: > > Hi Phil, > > Can you add the following directories to cswcommon to support 4 new > hooks? > > * preargproc: /etc/opt/csw/pkg-hooks/preargproc.d/ > * postargproc: /etc/opt/csw/pkg-hooks/postargproc.d/ > * prefetch: /etc/opt/csw/pkg-hooks/prefetch.d/ > * postfetch: /etc/opt/csw/pkg-hooks/postfetch.d/ > > Could you ping the list when this hits current as William will have > some tools waiting on this availability. > PS: there is no reason to "wait", as i've just pointed out above. From bwalton at opencsw.org Fri Oct 30 18:00:39 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 30 Oct 2009 13:00:39 -0400 Subject: [csw-maintainers] cswcommon update request In-Reply-To: References: <1256921216-sup-7652@ntdws12.chass.utoronto.ca> Message-ID: <1256921785-sup-7145@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Oct 30 12:53:25 -0400 2009: > Please just put in the definitions, into whatever uses it for now. > (ie: define the directories with appropriate permissions) Maybe this is the better approach anyway? Any package containing hooks should include the required hook directories as part of it's prototype? I had thought cswcommon was a good spot for these since presumably there will be multiple implementations. > there is no harm in having multiple packages define the directories. Agreed. > After 6 months to a year has gone by, and there are no further changes > in "hooks" over that timeperiod, then please re-request a change at > that time. Ok. > PS: there is no reason to "wait", as i've just pointed out above. Roger that. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Oct 30 18:50:12 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 30 Oct 2009 10:50:12 -0700 Subject: [csw-maintainers] final request for samba In-Reply-To: <1256918919-sup-7569@ntdws12.chass.utoronto.ca> References: <1256869503-sup-9699@ntdws12.chass.utoronto.ca> <1256918919-sup-7569@ntdws12.chass.utoronto.ca> Message-ID: btw there's apparently a missing step in my directions somewhere.. it's missing "libtalloc.so.1" from the package I made at least. so maby the "make install" is broken or something libtalloc is from samba itself, and does get built. From phil at bolthole.com Fri Oct 30 18:52:37 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 30 Oct 2009 10:52:37 -0700 Subject: [csw-maintainers] final request for samba In-Reply-To: References: <1256869503-sup-9699@ntdws12.chass.utoronto.ca> <1256918919-sup-7569@ntdws12.chass.utoronto.ca> Message-ID: oh. also, apparently, libtdb.so.1 libwbclient.so.0 From dam at opencsw.org Thu Oct 1 09:23:53 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 1 Oct 2009 09:23:53 +0200 Subject: [csw-maintainers] Handling of devel package splits Message-ID: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> Hi, I am currently packaging up a load of X11 packages. Some of them have a load of development-stuff (headers, etc.) in them, some only a few header files. I tend to split off the development stuff for all of them in _devel-packages for consistency, but as we don't have an explicit policy on this I would like to open up a small discussion if you would consider it feasible to split even for a few files for consistency. The alternative would be to split on a "by case" basis where some packages with many header files would have a devel package and some would include them in the base package. After a brief discussion I would like to open a poll for this. Thoughts? Best regards -- Dago From maciej at opencsw.org Thu Oct 1 11:15:32 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 1 Oct 2009 10:15:32 +0100 Subject: [csw-maintainers] V8+ binaries produced by gcc on build10s In-Reply-To: References: Message-ID: I have a relatively straightforward build: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/urxvt/trunk/Makefile After building the package on build10s, I see this: urxvt: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, stripped urxvtc: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, stripped urxvtd: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, stripped I've added -mno-v8plus to the compiler flags. gmake modenv says: CFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include CXXFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include Why is gcc still producing V8+ binaries? Is there a way to influence it? Maciej From james at opencsw.org Thu Oct 1 11:21:49 2009 From: james at opencsw.org (James Lee) Date: Thu, 01 Oct 2009 09:21:49 GMT Subject: [csw-maintainers] V8+ binaries produced by gcc on build10s In-Reply-To: References: Message-ID: <20091001.9214900.2853304098@gyor.oxdrove.co.uk> On 01/10/09, 10:15:32, Maciej "(Matchek)" Blizinski wrote regarding Re: [csw-maintainers] V8+ binaries produced by gcc on build10s: > After building the package on build10s, I see this: > urxvt: ELF 32-bit MSB executable SPARC32PLUS Version 1, > V8+ Required, dynamically linked, stripped > Why is gcc still producing V8+ binaries? Solaris 10 is at least v8plus so it's the right thing to do anyway. James. From dam at opencsw.org Thu Oct 1 11:35:41 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 1 Oct 2009 11:35:41 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> Message-ID: <2CEA8E5F-75B6-4EC1-969B-680BD2875FB8@opencsw.org> Hi, Am 01.10.2009 um 09:23 schrieb Dagobert Michelsen: > I am currently packaging up a load of X11 packages. Some of them > have a load of development-stuff (headers, etc.) in them, some > only a few header files. I tend to split off the development stuff > for all of them in _devel-packages for consistency, but as we don't > have an explicit policy on this I would like to open up a small > discussion if you would consider it feasible to split even for > a few files for consistency. The alternative would be to split > on a "by case" basis where some packages with many header files > would have a devel package and some would include them in the > base package. > > After a brief discussion I would like to open a poll for this. As we already had some discussion on IRC, here is the poll: Best regards -- Dago From dam at opencsw.org Thu Oct 1 11:40:13 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 1 Oct 2009 11:40:13 +0200 Subject: [csw-maintainers] V8+ binaries produced by gcc on build10s In-Reply-To: References: Message-ID: <349006FB-5015-4EA1-93DB-30297CA6A587@opencsw.org> Am 01.10.2009 um 11:15 schrieb Maciej (Matchek) Blizinski: > I have a relatively straightforward build: > > https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/urxvt/trunk/Makefile > > After building the package on build10s, I see this: > > urxvt: ELF 32-bit MSB executable SPARC32PLUS Version 1, > V8+ Required, dynamically linked, stripped > urxvtc: ELF 32-bit MSB executable SPARC32PLUS Version 1, > V8+ Required, dynamically linked, stripped > urxvtd: ELF 32-bit MSB executable SPARC32PLUS Version 1, > V8+ Required, dynamically linked, stripped > > I've added -mno-v8plus to the compiler flags. gmake modenv says: > > CFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include > CXXFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include > > Why is gcc still producing V8+ binaries? Is there a way to influence > it? This seems like a bug. Is there something on the GCC lists? Best regards -- Dago From dam at opencsw.org Thu Oct 1 11:45:08 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 1 Oct 2009 11:45:08 +0200 Subject: [csw-maintainers] V8+ binaries produced by gcc on build10s In-Reply-To: <349006FB-5015-4EA1-93DB-30297CA6A587@opencsw.org> References: <349006FB-5015-4EA1-93DB-30297CA6A587@opencsw.org> Message-ID: <54D09782-36B2-4653-9CEC-8D3CCC82FB8E@opencsw.org> Hi Maciej, Am 01.10.2009 um 11:40 schrieb Dagobert Michelsen: > Am 01.10.2009 um 11:15 schrieb Maciej (Matchek) Blizinski: > >> I have a relatively straightforward build: >> >> https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/urxvt/trunk/Makefile >> >> After building the package on build10s, I see this: >> >> urxvt: ELF 32-bit MSB executable SPARC32PLUS Version 1, >> V8+ Required, dynamically linked, stripped >> urxvtc: ELF 32-bit MSB executable SPARC32PLUS Version 1, >> V8+ Required, dynamically linked, stripped >> urxvtd: ELF 32-bit MSB executable SPARC32PLUS Version 1, >> V8+ Required, dynamically linked, stripped >> >> I've added -mno-v8plus to the compiler flags. gmake modenv says: >> >> CFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include >> CXXFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include >> >> Why is gcc still producing V8+ binaries? Is there a way to >> influence it? > > This seems like a bug. Is there something on the GCC lists? It looks like the compilation is ok, but as the provided libs in Solaris 10 are sparcv8plus the resulting binary is also: rxvtd: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, not stripped rxvtd.o: ELF 32-bit MSB relocatable SPARC Version 1 The object files are compiled correctly. Best regards -- Dago From james at opencsw.org Thu Oct 1 11:57:29 2009 From: james at opencsw.org (James Lee) Date: Thu, 01 Oct 2009 09:57:29 GMT Subject: [csw-maintainers] V8+ binaries produced by gcc on build10s In-Reply-To: <54D09782-36B2-4653-9CEC-8D3CCC82FB8E@opencsw.org> References: <349006FB-5015-4EA1-93DB-30297CA6A587@opencsw.org> <54D09782-36B2-4653-9CEC-8D3CCC82FB8E@opencsw.org> Message-ID: <20091001.9572900.1429675141@gyor.oxdrove.co.uk> On 01/10/09, 10:45:08, Dagobert Michelsen wrote regarding Re: [csw-maintainers] V8+ binaries produced by gcc on build10s: > >> > >> I've added -mno-v8plus to the compiler flags. gmake modenv says: > >> > >> CFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include > >> CXXFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include > >> > >> Why is gcc still producing V8+ binaries? Is there a way to > >> influence it? > > > > This seems like a bug. Is there something on the GCC lists? > It looks like the compilation is ok, but as the provided libs in > Solaris 10 > are sparcv8plus the resulting binary is also: > rxvtd: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ > Required, dynamically linked, not stripped > rxvtd.o: ELF 32-bit MSB relocatable SPARC Version 1 Because Solaris 10 is. Don't target a processor that can't run the OS. Set the compile flags to target what Solaris 10 will run. James. From james at opencsw.org Thu Oct 1 11:53:32 2009 From: james at opencsw.org (James Lee) Date: Thu, 01 Oct 2009 09:53:32 GMT Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <2CEA8E5F-75B6-4EC1-969B-680BD2875FB8@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <2CEA8E5F-75B6-4EC1-969B-680BD2875FB8@opencsw.org> Message-ID: <20091001.9533200.3095871799@gyor.oxdrove.co.uk> On 01/10/09, 10:35:41, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Handling of devel package splits: > Am 01.10.2009 um 09:23 schrieb Dagobert Michelsen: > > I am currently packaging up a load of X11 packages. Some of them > > have a load of development-stuff (headers, etc.) in them, some > > only a few header files. I tend to split off the development stuff > > for all of them in _devel-packages for consistency, but as we don't > > have an explicit policy on this I would like to open up a small > > discussion if you would consider it feasible to split even for > > a few files for consistency. The alternative would be to split > > on a "by case" basis where some packages with many header files > > would have a devel package and some would include them in the > > base package. > > > > After a brief discussion I would like to open a poll for this. > As we already had some discussion on IRC, here is the poll: > You are missing an option. If foo is a distribution, I install foo and I get CSWfoo with all foo's files. How that is split doesn't matter, eg, comprises an rt sub package, is split into arch neutral and binary. Package depends can bring in the rt only but I think that installing a product by name should install that product, a 1:1 correspondence between upstream product and top level package with the same name. Expanding this packages are of 2 types: those one installs and those installed automatically because they are required by others. Where we install by choice the naming matters. When it's a installed as depend sub division is right. X11 packages are typical of things users don't explicitly install. James. From phil at bolthole.com Thu Oct 1 18:16:29 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 1 Oct 2009 09:16:29 -0700 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <2CEA8E5F-75B6-4EC1-969B-680BD2875FB8@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <2CEA8E5F-75B6-4EC1-969B-680BD2875FB8@opencsw.org> Message-ID: On Thu, Oct 1, 2009 at 2:35 AM, Dagobert Michelsen wrote: > >> After a brief discussion I would like to open a poll for this. > > As we already had some discussion on IRC, here is the poll: > ? > I think this is a very unfair way to handle things. Discussions for official packaging issues, should either be done on the mailing list, or at MINIMUM, the full irc logs need to be posted. I do not see any reference to irc logs. From phil at bolthole.com Thu Oct 1 18:29:45 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 1 Oct 2009 09:29:45 -0700 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> Message-ID: The poll is inadequately described. For such a critical, major policy change such as this, you must be more explicit. The poll should describe what "split off devel" means. First, (presuming this is your intent), you should explicitly say, "MUST split off _devel". then you need to describe everything that should go in there. ALSO, you did not adequately describe potential justifications for when things should be split off vs not, for the "case by case basis". For example, the criteria that I personally use, are the following: a) Any time a maintainer wishes to provide a static library, it should be done in a separate _devel package b) when there are excessive amounts of development specific documentation, that belong more in a _devel package, than a _doc package. (eg: if there is substantial user documentation, but also substantial development documentation), it MAY be a good idea to split off the devel docs. c) when there's a bunch of development-useful-only tools, it MAY be useful to split them off. Generally speaking, when splitting off devel stuff saves 20% of the package, or a megabyte or more of download size. HOWEVER, none of the above to me are really important, if the _devel package is going to be something silly like 20k in size. or if a single combined package is going to be "small" anyway. The particular case in point: Dago is interested in splitting up "xpm", into "libxpm", and "libxpm_devel". The entire package, if it were one package, is 155k for sparc, and 88k for x86. The "devel" package, is 5k. yes, 5830 bytes. From dam at opencsw.org Thu Oct 1 20:45:22 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 1 Oct 2009 20:45:22 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> Message-ID: <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> Hi, Am 01.10.2009 um 18:29 schrieb Philip Brown: > The particular case in point: > Dago is interested in splitting up "xpm", into "libxpm", and > "libxpm_devel". > > The entire package, if it were one package, is 155k for sparc, and > 88k for x86. > The "devel" package, is 5k. yes, 5830 bytes. I specifically didn't do it for size, but for clearness and consistency. And I think the tradeoff of having a clean split against one more package is IMHO worthwhile. Best regards -- Dago From phil at bolthole.com Thu Oct 1 21:15:45 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 1 Oct 2009 12:15:45 -0700 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> Message-ID: On Thu, Oct 1, 2009 at 11:45 AM, Dagobert Michelsen wrote: > Hi, > > Am 01.10.2009 um 18:29 schrieb Philip Brown: >> >> The entire package, if it were one package, is 155k for sparc, and 88k for >> x86. >> The "devel" package, is 5k. yes, 5830 bytes. > > I specifically didn't do it for size, but for clearness and consistency. And > I think the tradeoff of having a clean split against one more package is > IMHO worthwhile. And I understand that point. My own opinion, is that fewer packages, makes for better "clearness" for our users, when there isnt a noticable benefit from splitting them up into mulitple. I cant see us ever splitting ALL our packages up into CSWmain vs CSWmain-doc While it would be "consistent", it would also be insane overkill, in my opinion :) So for similar reasoning, I dont think we should split up ALL packages to be CSWmain vs CSWmain-devel Just in the cases where there is actual benefit. From dam at opencsw.org Thu Oct 1 21:29:01 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 1 Oct 2009 21:29:01 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> Message-ID: <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> Hi Phil, Am 01.10.2009 um 21:15 schrieb Philip Brown: > On Thu, Oct 1, 2009 at 11:45 AM, Dagobert Michelsen > wrote: >> Am 01.10.2009 um 18:29 schrieb Philip Brown: >>> >>> The entire package, if it were one package, is 155k for sparc, and >>> 88k for >>> x86. >>> The "devel" package, is 5k. yes, 5830 bytes. >> >> I specifically didn't do it for size, but for clearness and >> consistency. And >> I think the tradeoff of having a clean split against one more >> package is >> IMHO worthwhile. > > And I understand that point. My own opinion, is that fewer packages, > makes > for better "clearness" for our users, when there isnt a noticable > benefit from > splitting them up into mulitple. > I cant see us ever splitting ALL our packages up into > CSWmain vs CSWmain-doc Me neither, because many users need the docs. > While it would be "consistent", it would also be insane overkill, in > my opinion :) > So for similar reasoning, I dont think we should split up ALL > packages to be > CSWmain vs CSWmain-devel The question is: How many users actually need the development files? > Just in the cases where there is actual benefit. If you know devel is always split you know that you have to install it. If it is sometimes split you are on your own. It may be a nice thing to have a script which adds all *_devel packages for the installed packages, though. Or to define a policy in pkg*.conf if _devel-packages are to be installed by default along with the main package. Best regards -- Dago From skayser at opencsw.org Thu Oct 1 23:21:04 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 01 Oct 2009 23:21:04 +0200 Subject: [csw-maintainers] OpenCSW Winter Camp 2009, when/where? Feedback needed. In-Reply-To: <50728.194.246.122.22.1253811743.squirrel@ssl.skayser.de> References: <50728.194.246.122.22.1253811743.squirrel@ssl.skayser.de> Message-ID: <4AC51D40.7060007@opencsw.org> Sebastian Kayser wrote on 24.09.2009 19:02: > before we head to Toronto next year in summer :D, i would like to kick off > this year's winter camp preparations for Munich. Two votes need your > input. > > - Which weekend can you participate? > http://doodle.com/p3rvwqkx542cu4rx > > - Which venue would you prefer (city/nature)? > http://doodle.com/xwnhvxp274i8b3iv Thanks to those who already voted, looking forward to seeing you (again) in a couple of months. Anyone else interested in coming? If so, please take part in the above polls so that we can plan accordingly (i will try to fix a date and venue by the end of next week). I have updated the winter camp page with possible topics. Feel free to brainstorm and add additional ones. Anyone interested in doing a technical workshop of some sort? Schedule is preliminary. Like during the last summer camp, it will simply serve as a rough guideline. http://opencsw.wikidot.com/wintercamp-2009 Thanks Sebastian From skayser at opencsw.org Fri Oct 2 09:32:17 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 02 Oct 2009 09:32:17 +0200 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: <4AC5AC81.1070606@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 :). Independent of the ongoing discussion: the version on the mirror roots is still outdated. Would some be so kind to put pkgutil 1.7 there? The pkg-get version is also downrev btw. (4.1.3 vs. 4.2.1). > Furthermore, could pkgutil be made an ARCH=all package, so that there is > just _one_ direct link that one can point new users to and not a > platform specific one (i know about uname -p, still it just makes things > more straightforward)? > > I see, the package contains a wget which is platform specific. Couldn't > we just include two wgets (wget.i386, wget.sparc)? From what i remember, > that is the same approach Sun uses for its explorer package. To add some facts: # find /opt/SUNWexplo/ -name "*curl*" /opt/SUNWexplo/bin/curl.i386 /opt/SUNWexplo/bin/curl.sparc # pkgparam SUNWexplo ARCH VENDOR all Sun Microsystems Inc. So it is not something unthinkable that we are talking about here, but something that Sun does too. Sebastian [1]http://www.ibiblio.org/pub/packages/solaris/opencsw/pkgutil-i386.pkg [2]http://www.ibiblio.org/pub/packages/solaris/opencsw/pkgutil-sparc.pkg From dam at opencsw.org Fri Oct 2 09:56:53 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 2 Oct 2009 09:56:53 +0200 Subject: [csw-maintainers] pkgutil/pkg-get version updates on the mirror roots? In-Reply-To: <4AC5AC81.1070606@opencsw.org> References: <4AC10A87.1090205@opencsw.org> <4AC5AC81.1070606@opencsw.org> Message-ID: <07837C40-572E-455C-AA33-ABD8E9BDCDAA@opencsw.org> Hi Sebastian, Am 02.10.2009 um 09:32 schrieb Sebastian Kayser: > 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 :). > > Independent of the ongoing discussion: the version on the mirror roots > is still outdated. Would some be so kind to put pkgutil 1.7 there? > > The pkg-get version is also downrev btw. (4.1.3 vs. 4.2.1). AFAIK Phil and James are the only persons with write access there. Phil, James, would any of you gentlemen be so kind to update both? Best regards -- Dago From james at opencsw.org Fri Oct 2 10:28:44 2009 From: james at opencsw.org (James Lee) Date: Fri, 02 Oct 2009 08:28:44 GMT Subject: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all? In-Reply-To: <4AC5AC81.1070606@opencsw.org> References: <4AC10A87.1090205@opencsw.org> <4AC5AC81.1070606@opencsw.org> Message-ID: <20091002.8284400.4088717404@gyor.oxdrove.co.uk> On 02/10/09, 08:32:17, Sebastian Kayser wrote regarding Re: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all?: > Independent of the ongoing discussion: the version on the mirror roots > is still outdated. Would some be so kind to put pkgutil 1.7 there? > The pkg-get version is also downrev btw. (4.1.3 vs. 4.2.1). The first thing any package tool should do is update itself. No, make that "must do" because other packages are only required to be updated with a contemporary version of pkg-get. The first batch of updates before updating itself are done with an old version, potentially too old, it need not be the previous version, it will be whatever is there and that can be very old. Using the update self first principle the initial package installer need only update itself and might not need advanced perl nor wget. James. From dam at opencsw.org Fri Oct 2 10:47:35 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 2 Oct 2009 10:47:35 +0200 Subject: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all? In-Reply-To: <20091002.8284400.4088717404@gyor.oxdrove.co.uk> References: <4AC10A87.1090205@opencsw.org> <4AC5AC81.1070606@opencsw.org> <20091002.8284400.4088717404@gyor.oxdrove.co.uk> Message-ID: <47166A8E-ABE3-491E-A1D3-EBEF8FDD8627@opencsw.org> Hi James, Am 02.10.2009 um 10:28 schrieb James Lee: > On 02/10/09, 08:32:17, Sebastian Kayser wrote > regarding Re: [csw-maintainers] pkgutil version updates on the mirror > roots? Make pkgutil package ARCH=all?: > >> Independent of the ongoing discussion: the version on the mirror >> roots >> is still outdated. Would some be so kind to put pkgutil 1.7 there? > >> The pkg-get version is also downrev btw. (4.1.3 vs. 4.2.1). > > The first thing any package tool should do is update itself. > > No, make that "must do" because other packages are only required to be > updated with a contemporary version of pkg-get. The first batch of > updates before updating itself are done with an old version, > potentially > too old, it need not be the previous version, it will be whatever is > there and that can be very old. > > Using the update self first principle the initial package installer > need > only update itself and might not need advanced perl nor wget. True. And that is the reason why we should deliberately ship outdated versions? I think it is good style to update the tools on the frontpage from time to time. Not with every minor release maybe, but a few times a year. Best regards -- Dago From james at opencsw.org Fri Oct 2 11:26:34 2009 From: james at opencsw.org (James Lee) Date: Fri, 02 Oct 2009 09:26:34 GMT Subject: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all? In-Reply-To: <47166A8E-ABE3-491E-A1D3-EBEF8FDD8627@opencsw.org> References: <4AC10A87.1090205@opencsw.org> <4AC5AC81.1070606@opencsw.org> <20091002.8284400.4088717404@gyor.oxdrove.co.uk> <47166A8E-ABE3-491E-A1D3-EBEF8FDD8627@opencsw.org> Message-ID: <20091002.9263400.2659167788@gyor.oxdrove.co.uk> On 02/10/09, 09:47:35, Dagobert Michelsen wrote regarding Re: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all?: > > Using the update self first principle the initial package installer > > need only update itself and might not need advanced perl nor wget. > True. And that is the reason why we should deliberately ship > outdated versions? I think it is good style to update the tools > on the frontpage from time to time. Not with every minor release > maybe, but a few times a year. There are 2 questions in this thread: 1. The root pkg tools are out of date. I say it doesn't matter as they are tools that update themselves. There isn't a reason to not keep them up-to-date but it's not interesting here. 2. The form the root pkg tools should take. I suggest it need not be the same as the actual package and can be a bootstrap version. To force its own update it could use versioning and datestamp or with an internal flag in the code. The bootstrap package can contain two archs of static wget, the actual package can use depends. There are other options. James. From bonivart at opencsw.org Fri Oct 2 13:17:13 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 2 Oct 2009 13:17:13 +0200 Subject: [csw-maintainers] /testing nicstat 1.20 Message-ID: <625385e30910020417k2b32d65ayf42a70e8ebd1ab48@mail.gmail.com> "nicstat is to network interfaces as "iostat" is to disks, or "prstat" is to processes. It is designed as a much better version of "netstat -i". Its differences include: * Reports bytes in & out as well as packets. * Normalizes these values to per-second rates. * Reports on all interfaces (while iterating) * Reports Utilization (rough calculation as of now) * Reports Saturation (also rough) * Prefixes statistics with the current time" http://blogs.sun.com/timc/entry/nicstat_the_solaris_and_linux http://mirror.opencsw.org/testing/nicstat-1.20,REV=2009.10.02-SunOS5.8-i386-CSW.pkg.gz http://mirror.opencsw.org/testing/nicstat-1.20,REV=2009.10.02-SunOS5.8-sparc-CSW.pkg.gz -- /peter From phil at bolthole.com Fri Oct 2 18:55:07 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 2 Oct 2009 09:55:07 -0700 Subject: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all? In-Reply-To: <20091002.9263400.2659167788@gyor.oxdrove.co.uk> References: <4AC10A87.1090205@opencsw.org> <4AC5AC81.1070606@opencsw.org> <20091002.8284400.4088717404@gyor.oxdrove.co.uk> <47166A8E-ABE3-491E-A1D3-EBEF8FDD8627@opencsw.org> <20091002.9263400.2659167788@gyor.oxdrove.co.uk> Message-ID: On Fri, Oct 2, 2009 at 2:26 AM, James Lee wrote: > >... > 2. The form the root pkg tools should take. > > I suggest it need not be the same as the actual package and can be a > bootstrap version. ?To force its own update it could use versioning > and datestamp or with an internal flag in the code. ?The bootstrap > package can contain two archs of static wget, the actual package can > use depends. ?There are other options. > > Indeed. And one of the options could be as follows: Instead duplicating our normal "packages" at the root level, have an actual INSTALLER proggie for CSW. That proggie could be a pkg, or one of those funky sh-wrapper things. If it's not a normal package,it then is free from any and all of our "standards", and can do whatever it likes. Such an installer could help a user select a pkg downloading tool, select a mirror site,and other fun things like that. From phil at bolthole.com Fri Oct 2 18:57:54 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 2 Oct 2009 09:57:54 -0700 Subject: [csw-maintainers] pkgutil/pkg-get version updates on the mirror roots? In-Reply-To: <07837C40-572E-455C-AA33-ABD8E9BDCDAA@opencsw.org> References: <4AC10A87.1090205@opencsw.org> <4AC5AC81.1070606@opencsw.org> <07837C40-572E-455C-AA33-ABD8E9BDCDAA@opencsw.org> Message-ID: On Fri, Oct 2, 2009 at 12:56 AM, Dagobert Michelsen wrote: > >> Independent of the ongoing discussion: the version on the mirror roots >> is still outdated. Would some be so kind to put pkgutil 1.7 there? >> >> The pkg-get version is also downrev btw. (4.1.3 vs. 4.2.1). > > AFAIK Phil and James are the only persons with write access there. > Phil, James, would any of you gentlemen be so kind to update both? > > ok, done. From bonivart at opencsw.org Sat Oct 3 20:48:14 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Sat, 3 Oct 2009 20:48:14 +0200 Subject: [csw-maintainers] Typo in descriptions file Message-ID: <625385e30910031148qc687fb0pccb5bc6f2b847a0b@mail.gmail.com> The entry for cvsproxy in the descriptions file lacks a space as separator. cvsproxy -an easy to use CVS proxy should be cvsproxy - an easy to use CVS proxy Note " - " instead of " -". -- /peter From dam at opencsw.org Sat Oct 3 21:09:09 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 3 Oct 2009 21:09:09 +0200 Subject: [csw-maintainers] Package GAR status page broken? Message-ID: <9851A323-886F-4276-A366-2146F64E7DE8@opencsw.org> Hi, I noticed that the package GAR status page is broken. Is this intended? Best regards -- Dago From dam at opencsw.org Sat Oct 3 21:09:37 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 3 Oct 2009 21:09:37 +0200 Subject: [csw-maintainers] Typo in descriptions file In-Reply-To: <625385e30910031148qc687fb0pccb5bc6f2b847a0b@mail.gmail.com> References: <625385e30910031148qc687fb0pccb5bc6f2b847a0b@mail.gmail.com> Message-ID: <6DDB819C-B683-440B-BCA1-4DB37EC7799D@opencsw.org> Hi Peter, Am 03.10.2009 um 20:48 schrieb Peter Bonivart: > The entry for cvsproxy in the descriptions file lacks a space as > separator. > > cvsproxy -an easy to use CVS proxy > > should be > > cvsproxy - an easy to use CVS proxy > > Note " - " instead of " -". Mmhhhh, "orphaned". Want to give it a try in GAR? Best regards -- Dago From bonivart at opencsw.org Sat Oct 3 21:20:16 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Sat, 3 Oct 2009 21:20:16 +0200 Subject: [csw-maintainers] Typo in descriptions file In-Reply-To: <6DDB819C-B683-440B-BCA1-4DB37EC7799D@opencsw.org> References: <625385e30910031148qc687fb0pccb5bc6f2b847a0b@mail.gmail.com> <6DDB819C-B683-440B-BCA1-4DB37EC7799D@opencsw.org> Message-ID: <625385e30910031220s325403a3ge9fcd448060353d7@mail.gmail.com> On Sat, Oct 3, 2009 at 9:09 PM, Dagobert Michelsen wrote: > Mmhhhh, "orphaned". Want to give it a try in GAR? Looks like a dead project, no updates since 2002. I can move it to GAR so we're ready for the next release. :-) -- /peter From dam at opencsw.org Sat Oct 3 21:21:47 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 3 Oct 2009 21:21:47 +0200 Subject: [csw-maintainers] Typo in descriptions file In-Reply-To: <625385e30910031220s325403a3ge9fcd448060353d7@mail.gmail.com> References: <625385e30910031148qc687fb0pccb5bc6f2b847a0b@mail.gmail.com> <6DDB819C-B683-440B-BCA1-4DB37EC7799D@opencsw.org> <625385e30910031220s325403a3ge9fcd448060353d7@mail.gmail.com> Message-ID: <11E3EAC5-7A9E-474E-B6E7-03A0AACA7061@opencsw.org> Hi Peter, Am 03.10.2009 um 21:20 schrieb Peter Bonivart: > On Sat, Oct 3, 2009 at 9:09 PM, Dagobert Michelsen > wrote: >> Mmhhhh, "orphaned". Want to give it a try in GAR? > > Looks like a dead project, no updates since 2002. Similar to CVS :-) > I can move it to GAR so we're ready for the next release. :-) He he :-D Best regards -- Dago From william at wbonnet.net Sat Oct 3 21:26:57 2009 From: william at wbonnet.net (William Bonnet) Date: Sat, 03 Oct 2009 21:26:57 +0200 Subject: [csw-maintainers] Package GAR status page broken? In-Reply-To: <9851A323-886F-4276-A366-2146F64E7DE8@opencsw.org> References: <9851A323-886F-4276-A366-2146F64E7DE8@opencsw.org> Message-ID: <4AC7A581.20500@wbonnet.net> Hi Dago > I noticed that the package GAR status page is broken. Is this intended? Thanks for reporting this. It is not intended, nor a feature :( I try to fix this ASAP. It is broken since a few days. I have to add a check for this kind of error. 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 Sun Oct 4 10:47:35 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 4 Oct 2009 10:47:35 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> Message-ID: <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> Hi, I would like to proceed on the splitting of devel packages as a package of mine is pending release whether the decision on this topic. The current poll is - 5 maintainers for "split off devel" - 1 maintainer for "decide on case-by-case" Does anyone feel that there is need for more discussion? Has anyone (especially those who have voted) understood that the split will then be mandatory for package releases? Sebastian, would you be willing to unify the bugs and introduce the "bugs-package-link" you suggested once we have clarified this issue? Best regards -- Dago From trygvis at opencsw.org Sun Oct 4 11:09:25 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Sun, 04 Oct 2009 11:09:25 +0200 Subject: [csw-maintainers] pkgutil version updates on the mirror roots? Make pkgutil package ARCH=all? In-Reply-To: References: <4AC10A87.1090205@opencsw.org> <4AC5AC81.1070606@opencsw.org> <20091002.8284400.4088717404@gyor.oxdrove.co.uk> <47166A8E-ABE3-491E-A1D3-EBEF8FDD8627@opencsw.org> <20091002.9263400.2659167788@gyor.oxdrove.co.uk> Message-ID: <4AC86645.1040303@opencsw.org> Philip Brown wrote: > On Fri, Oct 2, 2009 at 2:26 AM, James Lee wrote: >> ... >> 2. The form the root pkg tools should take. >> >> I suggest it need not be the same as the actual package and can be a >> bootstrap version. To force its own update it could use versioning >> and datestamp or with an internal flag in the code. The bootstrap >> package can contain two archs of static wget, the actual package can >> use depends. There are other options. >> >> > > Indeed. And one of the options could be as follows: > > Instead duplicating our normal "packages" at the root level, have an > actual INSTALLER proggie for CSW. > That proggie could be a pkg, or one of those funky sh-wrapper things. > If it's not a normal package,it then is free from any and all of our > "standards", and can do whatever it likes. > > Such an installer could help a user select a pkg downloading tool, > select a mirror site,and other fun things like that. Something like that would be very nice. A nice touch is the ability to select a mirror, the Ibiblio mirror is always very slow from Europe.. -- Trygve From trygvis at opencsw.org Sun Oct 4 11:13:27 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Sun, 04 Oct 2009 11:13:27 +0200 Subject: [csw-maintainers] [csw-devel] SF.net SVN: gar:[6691] csw/mgar/pkg/git/trunk In-Reply-To: References: Message-ID: <4AC86737.5090300@opencsw.org> bdwalton at users.sourceforge.net wrote: > Revision: 6691 > http://gar.svn.sourceforge.net/gar/?rev=6691&view=rev > Author: bdwalton > Date: 2009-10-03 18:55:23 +0000 (Sat, 03 Oct 2009) > > Log Message: > ----------- > correct git registration in /etc/services postinstall > > Modified Paths: > -------------- > csw/mgar/pkg/git/trunk/checksums > csw/mgar/pkg/git/trunk/files/CSWgit.postinstall > > Modified: csw/mgar/pkg/git/trunk/checksums > =================================================================== > --- csw/mgar/pkg/git/trunk/checksums 2009-10-03 17:17:41 UTC (rev 6690) > +++ csw/mgar/pkg/git/trunk/checksums 2009-10-03 18:55:23 UTC (rev 6691) > @@ -1 +1 @@ > -6c2d8cf8dcdfc844ea32bc381f6a3bfd download/CSWgit.postinstall > +b2f8cba4fea2abc0cab666bb8a523a1a download/CSWgit.postinstall > > Modified: csw/mgar/pkg/git/trunk/files/CSWgit.postinstall > =================================================================== > --- csw/mgar/pkg/git/trunk/files/CSWgit.postinstall 2009-10-03 17:17:41 UTC (rev 6690) > +++ csw/mgar/pkg/git/trunk/files/CSWgit.postinstall 2009-10-03 18:55:23 UTC (rev 6691) > @@ -9,9 +9,9 @@ > cp -p "$GC_OLD" "$GC_NEW" > fi > > -/usr/xpg4/bin/grep -q CSWgit /etc/services > +/usr/xpg4/bin/grep -q CSWgit /etc/inet/services I think you should grep the output of "getent services git" here as people that does mass-hosting might include services in LDAP (or NIS?). -- Trygve From skayser at opencsw.org Sun Oct 4 11:37:31 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Sun, 4 Oct 2009 11:37:31 +0200 (CEST) Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> Message-ID: <49301.217.225.247.115.1254649051.squirrel@ssl.skayser.de> Dagobert Michelsen wrote: > I would like to proceed on the splitting of devel packages as a package > of mine is pending release whether the decision on this topic. > > The current poll is > - 5 maintainers for "split off devel" > - 1 maintainer for "decide on case-by-case" > > Does anyone feel that there is need for more discussion? > > Has anyone (especially those who have voted) understood that the split > will then be mandatory for package releases? Do we have a written out wording for what is subject to the _devel split then? > Sebastian, would you be willing to unify the bugs and introduce > the "bugs-package-link" you suggested once we have clarified this > issue? http://bugs.opencsw.org/ Yup, will develop this on my local box and then need Ihsan's help to implement it on the www box. What do you mean by "unify"? Sebastian From phil at bolthole.com Sun Oct 4 19:06:44 2009 From: phil at bolthole.com (Philip Brown) Date: Sun, 4 Oct 2009 10:06:44 -0700 Subject: [csw-maintainers] pkg-get in /testing Message-ID: <20091004170643.GA70566@bolthole.com> FYI: new pkg-get in testing. lots of bugs closed. including the one about, "use REV= as precedence over rest of name". 2nd party testing appreciated. From phil at bolthole.com Sun Oct 4 21:53:14 2009 From: phil at bolthole.com (Philip Brown) Date: Sun, 4 Oct 2009 12:53:14 -0700 Subject: [csw-maintainers] questions about GAR, history, and naming Message-ID: <20091004195314.GA33599@bolthole.com> SO.. I'm reading the front page blurb about GAR on http://sourceforge.net/apps/trac/gar/ A few questions and concerns come up, which I think would be best clarified and sorted out on the list here. "GAR is the build and packaging system used by OpenCSW. GAR is based on the GARNOME project" Err.. pardon? I thought it was based on "the linux BBC project"'s GAR build system. to remind people what THAT is/was all about: http://www.lnx-bbc.com/garticle.html I believe that GARNOME also forked off of that or something. and speaking of which.. I think that to do things cleanly, we need to EITHER have a "core, generic GAR" build system, and layer opencsw stuff on top of that (I think this is the cleanest thing to do) OR rename/rebrand "our" build system, as "cswgar", or "garcsw" or something. If we dont provide a generic "gar", then I think we need to migrate from gar.sourceforge.net, to something more specific. Otherwise, I think we do not deserve that namespace, and it should be ceeded to the ORIGINAL gar people at lnx-bbc.com From dam at opencsw.org Sun Oct 4 22:34:18 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 4 Oct 2009 22:34:18 +0200 Subject: [csw-maintainers] questions about GAR, history, and naming In-Reply-To: <20091004195314.GA33599@bolthole.com> References: <20091004195314.GA33599@bolthole.com> Message-ID: <719DE490-C858-436F-A1CC-A06029BA3D98@opencsw.org> Hi Phil, Am 04.10.2009 um 21:53 schrieb Philip Brown: > SO.. I'm reading the front page blurb about GAR on > > http://sourceforge.net/apps/trac/gar/ > > A few questions and concerns come up, which I think would be best > clarified > and sorted out on the list here. > > "GAR is the build and packaging system used by OpenCSW. GAR is > based on > the GARNOME project" > > Err.. pardon? I thought it was based on "the linux BBC project"'s > GAR build > system. Yes, and yes. It is more like Linux BBCs GAR -> GARNOME -> OpenCSW GAR So it is based on GARNOME, which itself is based on Linux BBC GAR. > to remind people what THAT is/was all about: > http://www.lnx-bbc.com/garticle.html > > I believe that GARNOME also forked off of that or something. True. But to be precise I guess we must ask Cory :-) > and speaking of which.. I think that to do things cleanly, we need to > EITHER have a "core, generic GAR" build system, and layer > opencsw stuff on top of that > (I think this is the cleanest thing to do) > OR rename/rebrand "our" build system, as "cswgar", or "garcsw" or > something. What do you mean by "generic GAR"? Of course we can split of the package descriptions, but also the rest has "csw" all over the place. > If we dont provide a generic "gar", then I think we need to migrate > from > gar.sourceforge.net, to something more specific. Otherwise, I think > we do > not deserve that namespace, and it should be ceeded to the ORIGINAL > gar > people at lnx-bbc.com I think moving to something more specific without being explicitly asked by someone wanting that project name on SourceForge is... quite a task. Changing URLs, switching all repos, all external references as they include the project name... everything not done quickly. Without a real need I don't want to do that now. Not just because another name is nicer. IMHO too many resources from too many people would be bound for something without immediate benefit. Just my 0,02? Best regards -- Dago From dam at opencsw.org Sun Oct 4 22:55:22 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 4 Oct 2009 22:55:22 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <49301.217.225.247.115.1254649051.squirrel@ssl.skayser.de> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <49301.217.225.247.115.1254649051.squirrel@ssl.skayser.de> Message-ID: Am 04.10.2009 um 11:37 schrieb Sebastian Kayser: > Dagobert Michelsen wrote: >> I would like to proceed on the splitting of devel packages as a >> package >> of mine is pending release whether the decision on this topic. >> >> The current poll is >> - 5 maintainers for "split off devel" >> - 1 maintainer for "decide on case-by-case" >> >> Does anyone feel that there is need for more discussion? >> >> Has anyone (especially those who have voted) understood that the >> split >> will then be mandatory for package releases? > > Do we have a written out wording for what is subject to the _devel > split > then? Like this: "Files related to developers must be split off in a separate developer package. Exceptions can be made when the primary target audience of the package are developers. When the base package is named CSW with the catalog name the developer package must be name CSWdevel with the catalog name _devel. The developer package should contain bin/*-config *.a (static libs, if at all included) pkgconfig/* include/* (header files) aclocal/* (for autoconf) man1/*-config.1* (man pages for *-config) man3/* (man pages for header files) It may contain other files not related to the normal functionality of the package only relevant for compiling or building programs not usually done by the user. This means that for packages primarily focused on developers like Perl do not have a separate devel package as the base module itself is already for developers. The developer package for Perl may include the libperl.a static lib only relevant when building new packages with an embedded Perl." >> Sebastian, would you be willing to unify the bugs and introduce >> the "bugs-package-link" you suggested once we have clarified this >> issue? > > http://bugs.opencsw.org/ > > Yup, will develop this on my local box and then need Ihsan's help to > implement it on the www box. What do you mean by "unify"? When we are going towards splitting up packages the package list in Mantis gets even longer and it is already very long. As the bugs are usually related to upstream packages it is feasible to put all bugs for packages produced for an upstream package together under its garname instead of having separate buglists for each individual package. That means you would e. g. have just "openssl" instead of "openssl_rt", "openssl_devel", "openssl_doc" etc. The change should only affect Mantis. The section in Mantis should then be accessed only with the URL syntax you described, so the abstraction is done at only one place. You can get the list of packages produced by a GAR description with gmake pkglist so the information for the mapping table is in there. Best regards -- Dago From dam at opencsw.org Sun Oct 4 22:59:51 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 4 Oct 2009 22:59:51 +0200 Subject: [csw-maintainers] pkgutil version updates on the mirror roots? In-Reply-To: <4AC86645.1040303@opencsw.org> References: <4AC10A87.1090205@opencsw.org> <4AC5AC81.1070606@opencsw.org> <20091002.8284400.4088717404@gyor.oxdrove.co.uk> <47166A8E-ABE3-491E-A1D3-EBEF8FDD8627@opencsw.org> <20091002.9263400.2659167788@gyor.oxdrove.co.uk> <4AC86645.1040303@opencsw.org> Message-ID: <96D34F16-1556-4399-8666-AFC9F7B8EFE5@opencsw.org> Hi Trygve, Am 04.10.2009 um 11:09 schrieb Trygve Laugst?l: > Something like that would be very nice. A nice touch is the ability > to select a mirror, the Ibiblio mirror is always very slow from > Europe.. Yes. Even better would be a redirection service to the next mirror. The would serve two purposes: - close statistics on mirror usage and performance - usually better-than-manual routing As we usually don't have access to the BGP data we can't use SuperSparrow [1], but something like mirrorbrain [2] could be used. Best regards -- Dago [1] http://www.supersparrow.org/ [2] http://mirrorbrain.org/ From james at opencsw.org Mon Oct 5 10:54:48 2009 From: james at opencsw.org (James Lee) Date: Mon, 05 Oct 2009 08:54:48 GMT Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> Message-ID: <20091005.8544800.2981934600@gyor.oxdrove.co.uk> On 04/10/09, 09:47:35, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Handling of devel package splits: > I would like to proceed on the splitting of devel packages as a package > of mine is pending release whether the decision on this topic. > The current poll is > - 5 maintainers for "split off devel" > - 1 maintainer for "decide on case-by-case" > Does anyone feel that there is need for more discussion? Yes since you are missing options and no justification is offered. > Has anyone (especially those who have voted) understood that the split > will then be mandatory for package releases? No. You have not made that clear. The poll lumps doc too but the thread subject says devel. Your poll is void. James. From dam at opencsw.org Mon Oct 5 11:05:49 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Oct 2009 11:05:49 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <20091005.8544800.2981934600@gyor.oxdrove.co.uk> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> Message-ID: <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> Hi James, Am 05.10.2009 um 10:54 schrieb James Lee: > On 04/10/09, 09:47:35, Dagobert Michelsen wrote > regarding > Re: [csw-maintainers] Handling of devel package splits: > >> I would like to proceed on the splitting of devel packages as a >> package >> of mine is pending release whether the decision on this topic. > >> The current poll is >> - 5 maintainers for "split off devel" >> - 1 maintainer for "decide on case-by-case" > >> Does anyone feel that there is need for more discussion? > > Yes since you are missing options and no justification is offered. And that missing options would be? The justification is that it is a Good Thing not to have headers on a deployment machine and that it is confusing for users to sometimes have the devel-files inside the main package and sometimes not. >> Has anyone (especially those who have voted) understood that the >> split >> will then be mandatory for package releases? > > No. You have not made that clear. > > The poll lumps doc too but the thread subject says devel. What does "lumps doc" mean? > Your poll is void. Ok then, do the maintainers who have already voted feel the same? Best regards -- Dago From james at opencsw.org Mon Oct 5 11:54:40 2009 From: james at opencsw.org (James Lee) Date: Mon, 05 Oct 2009 09:54:40 GMT Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> Message-ID: <20091005.9544000.198172607@gyor.oxdrove.co.uk> On 05/10/09, 10:05:49, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Handling of devel package splits: > >> I would like to proceed on the splitting of devel packages as a > >> package > >> of mine is pending release whether the decision on this topic. > > > >> The current poll is > >> - 5 maintainers for "split off devel" > >> - 1 maintainer for "decide on case-by-case" > > > >> Does anyone feel that there is need for more discussion? > > > > Yes since you are missing options and no justification is offered. > And that missing options would be? As previously communicated. The only addition I have it to version runtimes as it means only one version is needed at a time for a given depend. jpeg depends on jpeg7rt jpeg7rt - latest runtime jpeg62rt - legacy runtime packages depend on whichever rt version being used. > The justification is that it is a Good Thing not to have headers on > a deployment machine and that it is confusing for users to sometimes > have the devel-files inside the main package and sometimes not. Thank you, that's a start. Any proposal should start by stating the problem it's trying to solve. In the case of X11 packages (example at start) a user doesn't install (because only the libs are needed) so this problem does not exist. We have to balance the confusion of installing package foo and not getting product foo. It's traditional for Unix machines to come with headers. I agree a first time user thinks "what all this for?" but why is a user looking in /usr/include? It's not like they are the only headers on the system nor the only thing a user won't use. > >> Has anyone (especially those who have voted) understood that the > >> split > >> will then be mandatory for package releases? > > > > No. You have not made that clear. > > > > The poll lumps doc too but the thread subject says devel. > What does "lumps doc" mean? lump = "3. a collection of things; aggregate" doc = documentation combined with "too" you are ruling on the documentation files with the same action as developments files. James. From james at opencsw.org Mon Oct 5 12:11:47 2009 From: james at opencsw.org (James Lee) Date: Mon, 05 Oct 2009 10:11:47 GMT Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <20091005.9544000.198172607@gyor.oxdrove.co.uk> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> Message-ID: <20091005.10114700.540252802@gyor.oxdrove.co.uk> On 05/10/09, 10:54:40, James Lee wrote regarding Re: [csw-maintainers] Handling of devel package splits: > > > The poll lumps doc too but the thread subject says devel. > > What does "lumps doc" mean? > lump = "3. a collection of things; aggregate" > doc = documentation > combined with "too" you are ruling on the documentation files with the > same action as developments files. Applying the development split rational you must split user and development documentation. James. From dam at opencsw.org Mon Oct 5 14:32:26 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Oct 2009 14:32:26 +0200 Subject: [csw-maintainers] More checkpkg issues Message-ID: <9E57D892-7407-48CC-B294-A4DA33279A05@opencsw.org> Hi there, after the nice fix from Ben with checkpkg now knowing package depencies there is still one flaw left: When a package for Solaris x86 is assembled with 64 bit components from Solaris 10 in it the checkpkg on Solaris 8 fails with something like ERROR: Couldn't find a package providing libm.so.2 Maybe someone has a smart idea how to circumvent this? Best regards -- Dago From james at opencsw.org Mon Oct 5 14:41:15 2009 From: james at opencsw.org (James Lee) Date: Mon, 05 Oct 2009 12:41:15 GMT Subject: [csw-maintainers] More checkpkg issues In-Reply-To: <9E57D892-7407-48CC-B294-A4DA33279A05@opencsw.org> References: <9E57D892-7407-48CC-B294-A4DA33279A05@opencsw.org> Message-ID: <20091005.12411500.882653828@gyor.oxdrove.co.uk> On 05/10/09, 13:32:26, Dagobert Michelsen wrote regarding [csw-maintainers] More checkpkg issues: > after the nice fix from Ben with checkpkg now knowing package > depencies there is still one flaw left: When a package for Solaris > x86 is assembled with 64 bit components from Solaris 10 in it > the checkpkg on Solaris 8 fails with something like > ERROR: Couldn't find a package providing libm.so.2 > Maybe someone has a smart idea how to circumvent this? I have: [ "$lib" = "libm.so.2" ] && continue in the appropriate loop. Sorry, it's not smart. You have to note it will only execute on Solaris 10 for it to be smart. James. From dam at opencsw.org Mon Oct 5 14:56:55 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Oct 2009 14:56:55 +0200 Subject: [csw-maintainers] More checkpkg issues In-Reply-To: <20091005.12411500.882653828@gyor.oxdrove.co.uk> References: <9E57D892-7407-48CC-B294-A4DA33279A05@opencsw.org> <20091005.12411500.882653828@gyor.oxdrove.co.uk> Message-ID: Hi James, Am 05.10.2009 um 14:41 schrieb James Lee: > On 05/10/09, 13:32:26, Dagobert Michelsen wrote > regarding > [csw-maintainers] More checkpkg issues: > >> after the nice fix from Ben with checkpkg now knowing package >> depencies there is still one flaw left: When a package for Solaris >> x86 is assembled with 64 bit components from Solaris 10 in it >> the checkpkg on Solaris 8 fails with something like > >> ERROR: Couldn't find a package providing libm.so.2 > >> Maybe someone has a smart idea how to circumvent this? > > I have: > > [ "$lib" = "libm.so.2" ] && continue > > in the appropriate loop. > > > Sorry, it's not smart. You have to note it will only execute on > Solaris 10 for it to be smart. Well, it is better then my solution changing the error to a warning. Ben, if you agree I would like to add that to GARs checkpkg as default behaviour. Best regards -- Dago From bwalton at opencsw.org Mon Oct 5 15:25:22 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 05 Oct 2009 09:25:22 -0400 Subject: [csw-maintainers] More checkpkg issues In-Reply-To: References: <9E57D892-7407-48CC-B294-A4DA33279A05@opencsw.org> <20091005.12411500.882653828@gyor.oxdrove.co.uk> Message-ID: <1254749063-sup-2640@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Mon Oct 05 08:56:55 -0400 2009: > > [ "$lib" = "libm.so.2" ] && continue > > Sorry, it's not smart. You have to note it will only execute on > > Solaris 10 for it to be smart. It's smarter than dying for something that we know is typically correct. :) > Well, it is better then my solution changing the error to a warning. > Ben, if you agree I would like to add that to GARs checkpkg as default > behaviour. Yes, I'm all for making it as usable a tool as possible in the general case. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Mon Oct 5 16:08:45 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Oct 2009 16:08:45 +0200 Subject: [csw-maintainers] GAR Platform builds now open for testing Message-ID: <0F1DEF08-4D55-4224-ADFC-DE1DD712E9A7@opencsw.org> Hi folks, I have been able to finish up the pbuilds feature in GAR. The official naming is "GAR Platforms". The important features are: - Allows building of Sparc/x86 at the same time (Just issue "gmake package" on build8s / build8x) - Allows fully unattended builds for both Sparc and X86 suitable for buildbot use (Use "gmake platforms") - For the brave: build all ISAs for a package in parallel and watch the build with multitail. Watch out: Ctrl-C doesn't work too good yet during build (Activate this with "PARALLELMODULATIONS = 1" in your .garrc) It lives currently in mgar/gar/v2-pbuild, just link it in to your project for testing. I have used it for some packages now and it looks good to me, but I don't use all features of GAR ;-) So feedback is especially welcome here! After some positive feedback I would like to make this version the default for GAR. It will be the basis for the enhanced release process (tagging of build recipes to tags/ triggering automated builds which will be automatically installed on new "experimental" hosts. More on that later.) Best regards -- Dago From dam at opencsw.org Mon Oct 5 16:12:51 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Oct 2009 16:12:51 +0200 Subject: [csw-maintainers] GAR Platform builds now open for testing In-Reply-To: <0F1DEF08-4D55-4224-ADFC-DE1DD712E9A7@opencsw.org> References: <0F1DEF08-4D55-4224-ADFC-DE1DD712E9A7@opencsw.org> Message-ID: <05F1A42C-9047-4EBF-A531-3A2212A8DC19@opencsw.org> Hi folks, Am 05.10.2009 um 16:08 schrieb Dagobert Michelsen: > Hi folks, > > I have been able to finish up the pbuilds feature in GAR. The > official naming is "GAR Platforms". > > The important features are: > > - Allows building of Sparc/x86 at the same time > (Just issue "gmake package" on build8s / build8x) > > - Allows fully unattended builds for both Sparc and X86 suitable > for buildbot use > (Use "gmake platforms") > > - For the brave: build all ISAs for a package in parallel and > watch the build with multitail. > Watch out: Ctrl-C doesn't work too good yet during build > (Activate this with "PARALLELMODULATIONS = 1" in your .garrc) > > > It lives currently in mgar/gar/v2-pbuild, just link it in to > your project for testing. I have used it for some packages now > and it looks good to me, but I don't use all features of GAR ;-) > So feedback is especially welcome here! > > After some positive feedback I would like to make this version > the default for GAR. It will be the basis for the enhanced > release process (tagging of build recipes to tags/ triggering > automated builds which will be automatically installed on > new "experimental" hosts. More on that later.) Of course there is also documentation :-) http://sourceforge.net/apps/trac/gar/wiki/Platforms Best regards -- Dago From phil at bolthole.com Mon Oct 5 18:58:32 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 5 Oct 2009 09:58:32 -0700 Subject: [csw-maintainers] questions about GAR, history, and naming In-Reply-To: <719DE490-C858-436F-A1CC-A06029BA3D98@opencsw.org> References: <20091004195314.GA33599@bolthole.com> <719DE490-C858-436F-A1CC-A06029BA3D98@opencsw.org> Message-ID: On Sun, Oct 4, 2009 at 1:34 PM, Dagobert Michelsen wrote: > Hi Phil, *wave* > I think moving to something more specific without being explicitly asked > by someone wanting that project name on SourceForge is... quite a task. > Changing URLs, switching all repos, all external references as they > include the project name... everything not done quickly. Without a real > need I don't want to do that now. Not just because another name is > nicer. IMHO too many resources from too many people would be bound for > something without immediate benefit. > "doing the right thing", RARELY has "immediate benefit" :-P PS: renaming is not the only option that would be morally clean. The other option that I see, and mentioned, is to offer a "generic gar" package. Shouldnt be too difficult, relatively speaking? From maciej at opencsw.org Mon Oct 5 19:44:02 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 5 Oct 2009 18:44:02 +0100 Subject: [csw-maintainers] GAR Platform builds now open for testing In-Reply-To: <05F1A42C-9047-4EBF-A531-3A2212A8DC19@opencsw.org> References: <0F1DEF08-4D55-4224-ADFC-DE1DD712E9A7@opencsw.org> <05F1A42C-9047-4EBF-A531-3A2212A8DC19@opencsw.org> Message-ID: I took a look at the documentation and I have a questions: What about building packages outside the buildfarm. I use to work on a relatively powerful, local x86 machine. When I'm happy with the build files, I submit the changes to the repository, go to the buildfarm, log into build8s, launch the build and pray. What is the pbuild branch going to do on a machine outside the buildfarm, is it going to try to log into build8s, which isn't there? Maciej From dam at opencsw.org Mon Oct 5 20:54:49 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Oct 2009 20:54:49 +0200 Subject: [csw-maintainers] questions about GAR, history, and naming In-Reply-To: References: <20091004195314.GA33599@bolthole.com> <719DE490-C858-436F-A1CC-A06029BA3D98@opencsw.org> Message-ID: <9046596F-57B6-4AA0-9B36-60C9F1497A56@opencsw.org> Hi Phil, Am 05.10.2009 um 18:58 schrieb Philip Brown: >> I think moving to something more specific without being explicitly >> asked >> by someone wanting that project name on SourceForge is... quite a >> task. >> Changing URLs, switching all repos, all external references as they >> include the project name... everything not done quickly. Without a >> real >> need I don't want to do that now. Not just because another name is >> nicer. IMHO too many resources from too many people would be bound >> for >> something without immediate benefit. > > "doing the right thing", RARELY has "immediate benefit" :-P > > PS: renaming is not the only option that would be morally clean. > The other option that I see, and mentioned, is to offer a "generic > gar" package. > Shouldnt be too difficult, relatively speaking? Following your argumentation the "generic gar" would be the GAR from linuxbbc without changes as the generic name "GAR" belongs to them. Every fork could be thought of a takeover of the namespace. But anyway, I am against changing the name unless someone from linuxbbc is claiming the name on sourceforge. Best regards -- Dago From phil at bolthole.com Mon Oct 5 21:14:37 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 5 Oct 2009 12:14:37 -0700 Subject: [csw-maintainers] libtool, compiling shared lib Message-ID: Anyhone understand automake/libtool gobbldygook? I'm trying to compile something. It's libtool infested. I do a gmake. it builds something. but it only builds the libXXX.la It doesnt build the SHARED LIBRARY libXXX.so.x.y.z There are zero errors. it just doesnt build it. And I dont understand which target, out of the 100 or so in the stupid automake-generated-soup, to call for it. It makes the damn symlinks, .libs/libXXX.so.4 -> libXXX.so.4.0.0 but no actual shared lib ? !!! I've hit this in MULTIPLE software things now and am lost for words. From blizinski at google.com Thu Oct 1 10:16:42 2009 From: blizinski at google.com (Maciej (Matchek) Blizinski) Date: Thu, 1 Oct 2009 09:16:42 +0100 Subject: [csw-maintainers] V8+ binaries produced by gcc on build10s Message-ID: I have a relatively straightforward build: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/urxvt/trunk/Makefile After building the package on build10s, I see this: urxvt: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, stripped urxvtc: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, stripped urxvtd: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, stripped I added -mno-v8plus to the compiler flags. gmake modenv says: CFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include CXXFLAGS = -O2 -pipe -mcpu=v8 -mno-v8plus -I/opt/csw/include Why is gcc still producing V8+ binaries? Is there a way to influence it? Maciej From dam at baltic-online.de Fri Oct 2 22:17:19 2009 From: dam at baltic-online.de (Dagobert Michelsen) Date: Fri, 2 Oct 2009 22:17:19 +0200 Subject: [csw-maintainers] Page "Suggestions" edited at wiki.opencsw.org In-Reply-To: <9158b4aaa5a04a352c0847669ef7bd85@as2-1.s.wikidot.com> References: <9158b4aaa5a04a352c0847669ef7bd85@as2-1.s.wikidot.com> Message-ID: Hi folks, Am 02.10.2009 um 20:42 schrieb Philip Brown: > Philip Brown edited the page "Suggestions" at > http://wiki.opencsw.org/suggestions Am 02.10.2009 um 21:51 schrieb bonivart: > bonivart edited the page "Suggestions" at > http://wiki.opencsw.org/suggestions Gentlemen, if you have anything to discuss please do it on the list as I get spammed with the notifications ;-) Best regards -- Dago From phil at bolthole.com Mon Oct 5 21:20:38 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 5 Oct 2009 12:20:38 -0700 Subject: [csw-maintainers] questions about GAR, history, and naming In-Reply-To: <9046596F-57B6-4AA0-9B36-60C9F1497A56@opencsw.org> References: <20091004195314.GA33599@bolthole.com> <719DE490-C858-436F-A1CC-A06029BA3D98@opencsw.org> <9046596F-57B6-4AA0-9B36-60C9F1497A56@opencsw.org> Message-ID: On Mon, Oct 5, 2009 at 11:54 AM, Dagobert Michelsen wrote: > Hi Phil, > >> PS: renaming is not the only option that would be morally clean. >> The other option that I see, and mentioned, is to offer a "generic gar" >> package. >> Shouldnt be too difficult, relatively speaking? > > Following your argumentation the "generic gar" would be the GAR from > linuxbbc > without changes as the generic name "GAR" belongs to them. Every fork could > be thought of a takeover of the namespace. Not neccessarily the original one unchanged. It could be an "improved gar" in my opinion. I think that "gar.sourceforge.net", belongs most properly as a place where other people interested "in gar", could work on a common base. This would include linuxbbc, AND possibly GARNOME people. Or, if you just "take out all the opencsw bits" from what you have already, and make sure that what is left, is internally consistent for someone who might take it and build their own GAR-based build setup. That's all. I think we would be perfectly justified in keeping the opencsw gar addons, as also at gar.sourceforge.net Just so long as they are an *optional* addon. From dam at opencsw.org Mon Oct 5 21:28:08 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Oct 2009 21:28:08 +0200 Subject: [csw-maintainers] BerkeleyDB final call Message-ID: Hi, I have now finally assembled a new and complete rebuild of the Berkeley DB libraries. In the new schema every version of BDB is sitting in a separate subdirectory, that means Berkeley DB X.Y.Z is located at /opt/csw/bdbXY/(bin|lib|...) All versions have been packaged up from 4.2 to 4.8 (3.3 was included because there were existing packages needing it). This should allow building and testing for regression tests against every version available. If necessary the legacy packages needed as dependencies have been replaced by stubs containing minimal links to the new locations with a respective dependency in the package. The following packages have been updated: berkeleydb CSWbdb berkeleydb3 CSWbdb3 berkeleydb33 CSWbdb33 berkeleydb33_devel CSWbdb33devel berkeleydb33_doc CSWbdb33doc berkeleydb4 CSWbdb4 berkeleydb42 CSWbdb42 berkeleydb42_devel CSWbdb42devel berkeleydb42_doc CSWbdb42doc berkeleydb43 CSWbdb43 berkeleydb43_devel CSWbdb43devel berkeleydb43_doc CSWbdb43doc berkeleydb44 CSWbdb44 berkeleydb44_devel CSWbdb44devel berkeleydb44_doc CSWbdb44doc berkeleydb45 CSWbdb45 berkeleydb45_devel CSWbdb45devel berkeleydb45_doc CSWbdb45doc berkeleydb46 CSWbdb46 berkeleydb46_devel CSWbdb46devel berkeleydb46_doc CSWbdb46doc berkeleydb47 CSWbdb47 berkeleydb47_devel CSWbdb47devel berkeleydb47_doc CSWbdb47doc berkeleydb48 CSWbdb48 berkeleydb48_devel CSWbdb48devel berkeleydb48_doc CSWbdb48doc The following packages are deprecated: - CSWbdb was newly introduced during the unification. It contains /opt/csw/lib/amd64/libdb-4.7.so=../../bdb47/lib/amd64/libdb-4.7.so /opt/csw/lib/libdb-4.7.so=../bdb47/lib/libdb-4.7.so - CSWbdb3 contains the original Berkeley DB 3.3 version in /opt/csw/lib, which is now in /opt/csw/bdb33. It contains /opt/csw/lib/libdb-3.3.so=../bdb33/lib/libdb-3.3.so - CSWbdb4 contained the original Berkeley DB 4.2 in /opt/csw/bdb4. The package now contains /opt/csw/bdb4=bdb42 The following packages do not exist any more as the base packages are deprecated: - berkeleydb_doc CSWbdbdoc - berkeleydb_devel CSWbdbdevel - berkeleydb4_doc CSWbdb4-doc The following package names have been changed to match the general naming convetions: - berkeleydb43_devel CSWbdb43-devel -> CSWbdb43devel - berkeleydb43_doc CSWbdb43-doc -> CSWbdb43doc - berkeleydb44_devel CSWbdb44-devel -> CSWbdb44devel - berkeleydb44_doc CSWbdb44-doc -> CSWbdb44doc I know that package renames are always ugly, but I neither wanted to continue with the broken scheme nor wanted to have some package with the old and some with the new scheme. Additionally, the devel- and doc-packages shouldn't be in wide use and should not make much trouble. The packages are available from and there are subdirectories for Solaris 8 Sparc and x86 with catalogs which should allow direct updating with pkg-get/pkgutil. Additionally all packages have been installed on test8s and test8x. To make this transition less painful than the previous one please test the new packages in your environment, test them with the packages which failed last time and the packages you would consider most important. Thank you! -- Dago From dam at opencsw.org Mon Oct 5 21:29:49 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Oct 2009 21:29:49 +0200 Subject: [csw-maintainers] libtool, compiling shared lib In-Reply-To: References: Message-ID: <5D9255A8-5F8F-4DBE-9BD4-443075A9AC06@opencsw.org> Hi Phil, Am 05.10.2009 um 21:14 schrieb Philip Brown: > Anyhone understand automake/libtool gobbldygook? > > I'm trying to compile something. It's libtool infested. > > I do a gmake. it builds something. but it only builds the libXXX.la > It doesnt build the SHARED LIBRARY libXXX.so.x.y.z > > There are zero errors. it just doesnt build it. And I dont understand > which target, out of the 100 or so in the stupid > automake-generated-soup, to call for it. > > It makes the damn symlinks, .libs/libXXX.so.4 -> libXXX.so.4.0.0 > > but no actual shared lib ? !!! > > I've hit this in MULTIPLE software things now and am lost for words. If you were using SVN I would say "just commit your work and post the URL", now I say "where is the directory so I can have a look" ;-) Best regards -- Dago From dam at opencsw.org Mon Oct 5 21:31:24 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Oct 2009 21:31:24 +0200 Subject: [csw-maintainers] librsync 0.9.7 uploaded to testing In-Reply-To: <20090920221939.GA25482@vm-1.bch.net> References: <20090920221939.GA25482@vm-1.bch.net> Message-ID: Hi Brian, Am 21.09.2009 um 00:19 schrieb Brian Hill: > I have uploaded librsync for testing. It isn't all that useful > by itself, but it is needed for rdiff-backup, which is coming soon. > > Does the descriptions file update at regular intervals or is it > done by hand? A pkg-get of librsync from testing doesn't work yet. The catalog is updated every 10 minutes, so it should have been updated by now (ups, 21.09.2009?? Have you posted from a non-subscribed address?) Best regards -- Dago From wbonnet at opencsw.org Mon Oct 5 21:16:10 2009 From: wbonnet at opencsw.org (William Bonnet) Date: Mon, 05 Oct 2009 21:16:10 +0200 Subject: [csw-maintainers] Package GAR status page broken? In-Reply-To: <4AC7A581.20500@wbonnet.net> References: <9851A323-886F-4276-A366-2146F64E7DE8@opencsw.org> <4AC7A581.20500@wbonnet.net> Message-ID: <4ACA45FA.6070100@opencsw.org> Hi This should be fixed now (even if until tomorrow morning it is still broken...). The problem came from an upstream modification on the packages list i was parsing. I was not aware of the URL change, and i did not modified my code. cheers W. -- William Bonnet http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From dam at opencsw.org Mon Oct 5 21:34:49 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Oct 2009 21:34:49 +0200 Subject: [csw-maintainers] questions about GAR, history, and naming In-Reply-To: References: <20091004195314.GA33599@bolthole.com> <719DE490-C858-436F-A1CC-A06029BA3D98@opencsw.org> <9046596F-57B6-4AA0-9B36-60C9F1497A56@opencsw.org> Message-ID: <0315E28D-99D7-42DB-A144-8A6B4E85A771@opencsw.org> Hi Phil, Am 05.10.2009 um 21:20 schrieb Philip Brown: > On Mon, Oct 5, 2009 at 11:54 AM, Dagobert Michelsen > wrote: >>> PS: renaming is not the only option that would be morally clean. >>> The other option that I see, and mentioned, is to offer a "generic >>> gar" >>> package. >>> Shouldnt be too difficult, relatively speaking? >> >> Following your argumentation the "generic gar" would be the GAR from >> linuxbbc >> without changes as the generic name "GAR" belongs to them. Every >> fork could >> be thought of a takeover of the namespace. > > > Not neccessarily the original one unchanged. It could be an "improved > gar" in my opinion. > > I think that "gar.sourceforge.net", belongs most properly as a place > where other people interested "in gar", could work on a common base. > This would include linuxbbc, AND possibly GARNOME people. > > Or, if you just "take out all the opencsw bits" from what you have > already, and make sure that what is left, is internally consistent for > someone who might take it and build their own GAR-based build setup. > > That's all. > > I think we would be perfectly justified in keeping the opencsw gar > addons, as also at gar.sourceforge.net > Just so long as they are an *optional* addon. The problem is that the enhancements specific to Solaris can't cleanly be ripped out. Basically all I did was adding Solaris-specific stuff. If I take it out you have the original version again. Best regards -- Dago From phil at bolthole.com Mon Oct 5 21:45:11 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 5 Oct 2009 12:45:11 -0700 Subject: [csw-maintainers] libtool, compiling shared lib In-Reply-To: <5D9255A8-5F8F-4DBE-9BD4-443075A9AC06@opencsw.org> References: <5D9255A8-5F8F-4DBE-9BD4-443075A9AC06@opencsw.org> Message-ID: On Mon, Oct 5, 2009 at 12:29 PM, Dagobert Michelsen wrote: > >> It makes the damn symlinks, .libs/libXXX.so.4 -> libXXX.so.4.0.0 >> >> but no actual shared lib ? !!! >> >> I've hit this in MULTIPLE software things now and am lost for words. > > If you were using SVN I would say "just commit your work and post the URL", > now I say "where is the directory so I can have a look" ;-) > It's actually a not-for-csw compile. but I figure it is useful information so thought I would ask about it here :) It's also general principle knowlege, too. Take ANY shared lib,that is compiled with libtool. rm .libs/libFOOO.so.x.y.z (the "real" library) Now try to figure out what "make x" command to run, to recompile/relink the damn library. Figure it out with ANY libtool-subjugated package, and I bet we then have it figured out for all. I'm stumped on any of them :( There MAY be some magic "libtool libfoo.la" to relink/recreate the library instead of a make target command that I dont know. That would be just as nice to know, perhaps even nicer. From phil at bolthole.com Mon Oct 5 21:57:44 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 5 Oct 2009 12:57:44 -0700 Subject: [csw-maintainers] questions about GAR, history, and naming In-Reply-To: <0315E28D-99D7-42DB-A144-8A6B4E85A771@opencsw.org> References: <20091004195314.GA33599@bolthole.com> <719DE490-C858-436F-A1CC-A06029BA3D98@opencsw.org> <9046596F-57B6-4AA0-9B36-60C9F1497A56@opencsw.org> <0315E28D-99D7-42DB-A144-8A6B4E85A771@opencsw.org> Message-ID: On Mon, Oct 5, 2009 at 12:34 PM, Dagobert Michelsen wrote: > >> I think we would be perfectly justified in keeping the opencsw gar >> addons, as also at gar.sourceforge.net >> Just so long as they are an *optional* addon. > > The problem is that the enhancements specific to Solaris can't cleanly > be ripped out. Basically all I did was adding Solaris-specific stuff. > If I take it out you have the original version again. > well, that's not "opencsw specific". Can you not leave them in, but make it so that they only come into play if you run it on solaris? From dam at opencsw.org Mon Oct 5 22:05:13 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Oct 2009 22:05:13 +0200 Subject: [csw-maintainers] GAR Platform builds now open for testing In-Reply-To: References: <0F1DEF08-4D55-4224-ADFC-DE1DD712E9A7@opencsw.org> <05F1A42C-9047-4EBF-A531-3A2212A8DC19@opencsw.org> Message-ID: Hi Maciej, Am 05.10.2009 um 19:44 schrieb Maciej (Matchek) Blizinski: > I took a look at the documentation and I have a questions: What about > building packages outside the buildfarm. I use to work on a relatively > powerful, local x86 machine. When I'm happy with the build files, I > submit the changes to the repository, go to the buildfarm, log into > build8s, launch the build and pray. What is the pbuild branch going to > do on a machine outside the buildfarm, is it going to try to log into > build8s, which isn't there? If you don't set PACKAGING_HOST_* and BUILD_HOST_* it should behave similar to the regular GAR v2 - no hopping around, but with separete directory trees for Sparc and X86 allowing concurrent builds. Best regards -- Dago From ihsan at opencsw.org Mon Oct 5 22:08:53 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Mon, 05 Oct 2009 22:08:53 +0200 Subject: [csw-maintainers] OpenCSW Winter Camp 2009, when/where? Feedback needed. In-Reply-To: <50728.194.246.122.22.1253811743.squirrel@ssl.skayser.de> References: <50728.194.246.122.22.1253811743.squirrel@ssl.skayser.de> Message-ID: <4ACA5255.4000408@opencsw.org> Am 24.9.2009 19:02 Uhr, Sebastian Kayser schrieb: > before we head to Toronto next year in summer :D, i would like to kick off > this year's winter camp preparations for Munich. Two votes need your > input. > > - Which weekend can you participate? > http://doodle.com/p3rvwqkx542cu4rx > > - Which venue would you prefer (city/nature)? > http://doodle.com/xwnhvxp274i8b3iv > > Please participate so that we can proceed with the plannings. If you have > any questions or feedback, please let me know. Similar to the past camps, > i have created a wiki page on http://wiki.opencsw.org/wintercamp-2009 > which we can use for planning purposes and for gathering ideas. Thank you very much for organizing the winter camp. Currently, I really can't say if I'll be able to join or not - even I'm living closer to Munich than Dago. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From bwalton at opencsw.org Tue Oct 6 04:26:12 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 05 Oct 2009 22:26:12 -0400 Subject: [csw-maintainers] Fwd: big xml/docbook package update Message-ID: <1254795959-sup-260@ntdws12.chass.utoronto.ca> --- Begin forwarded message from Ben Walton --- From: Ben Walton To: users Date: Mon, 05 Oct 2009 22:24:43 -0400 Subject: big xml/docbook package update Hi All, I've just released a large set of interdependent packages[1] to the 'current' stream. This update will see several changes, but most importantly with respect to a clean update is that $sysconfdir is moving from /opt/csw/etc/ to /etc/opt/csw for all packages in this set. To smoothly handle the transition, I've provided a small script[2]. It will remove the packages (if found) in an order that won't upset the inter-dependencies and then reinstall them one by one. Other notable changes: docbook now provides 4.5 dtd's and sets this version as primary asciidoc is bumped to 8.4.5, which should fix a few bugs issues py_libxslt was formerly known as pylibxslt. renamed for consistency xmlto is bumped to 0.0.23 and should work better on solaris libxslt has a patch applied that corrects a segfault while debugging Sorry for any hassle this causes you. Thanks -Ben [1] List of updated packages: asciidoc-8.4.5,REV=2009.09.18-SunOS5.8-all-CSW.pkg.gz docbookdsssl-1.79,REV=2009.09.15-SunOS5.8-all-CSW.pkg.gz docbookdtds-4.5,REV=2009.09.16-SunOS5.8-all-CSW.pkg.gz docbookxsl-1.74.3,REV=2009.09.11-SunOS5.8-all-CSW.pkg.gz docbookxsldoc-1.74.3,REV=2009.09.11-SunOS5.8-all-CSW.pkg.gz libxml2-2.7.3,REV=2009.09.12-SunOS5.8-i386-CSW.pkg.gz libxml2-2.7.3,REV=2009.09.12-SunOS5.8-sparc-CSW.pkg.gz libxml2_devel-2.7.3,REV=2009.09.12-SunOS5.8-i386-CSW.pkg.gz libxml2_devel-2.7.3,REV=2009.09.12-SunOS5.8-sparc-CSW.pkg.gz libxslt-1.1.24,REV=2009.09.08-SunOS5.8-i386-CSW.pkg.gz libxslt-1.1.24,REV=2009.09.08-SunOS5.8-sparc-CSW.pkg.gz libxslt_devel-1.1.24,REV=2009.09.08-SunOS5.8-i386-CSW.pkg.gz libxslt_devel-1.1.24,REV=2009.09.08-SunOS5.8-sparc-CSW.pkg.gz openjade-1.3.2,REV=2009.09.11-SunOS5.8-i386-CSW.pkg.gz openjade-1.3.2,REV=2009.09.11-SunOS5.8-sparc-CSW.pkg.gz py_libxml2-2.7.3,REV=2009.09.12-SunOS5.8-i386-CSW.pkg.gz py_libxml2-2.7.3,REV=2009.09.12-SunOS5.8-sparc-CSW.pkg.gz py_libxslt-1.1.24,REV=2009.09.08-SunOS5.8-i386-CSW.pkg.gz py_libxslt-1.1.24,REV=2009.09.08-SunOS5.8-sparc-CSW.pkg.gz sgmlcommon-0.6.3,REV=2009.09.13-SunOS5.8-all-CSW.pkg.gz xmlcommon-0.6.3,REV=2009.09.13-SunOS5.8-all-CSW.pkg.gz xmlto-0.0.23,REV=2009.09.27-SunOS5.8-i386-CSW.pkg.gz xmlto-0.0.23,REV=2009.09.27-SunOS5.8-sparc-CSW.pkg.gz [2] http://mirror.opencsw.org/testing/update_xml_pkgs.sh --- End forwarded message --- -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Oct 6 09:48:10 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 6 Oct 2009 09:48:10 +0200 Subject: [csw-maintainers] questions about GAR, history, and naming In-Reply-To: References: <20091004195314.GA33599@bolthole.com> <719DE490-C858-436F-A1CC-A06029BA3D98@opencsw.org> <9046596F-57B6-4AA0-9B36-60C9F1497A56@opencsw.org> <0315E28D-99D7-42DB-A144-8A6B4E85A771@opencsw.org> Message-ID: <32973644-DFF4-4BD1-A760-90422E02A60A@opencsw.org> Hi Phil, Am 05.10.2009 um 21:57 schrieb Philip Brown: > On Mon, Oct 5, 2009 at 12:34 PM, Dagobert Michelsen > wrote: >> >>> I think we would be perfectly justified in keeping the opencsw gar >>> addons, as also at gar.sourceforge.net >>> Just so long as they are an *optional* addon. >> >> The problem is that the enhancements specific to Solaris can't >> cleanly >> be ripped out. Basically all I did was adding Solaris-specific stuff. >> If I take it out you have the original version again. >> > > well, that's not "opencsw specific". Can you not leave them in, but > make it so that they only come into play if you run it on solaris? The decision logic is already quite complex and inserting these switches would even increase it, making it unreadable for new GAR maintainers. And what for? If there are people from linux bbc or Garnome who want to work in a unified development tree I would certainly help in making it. If you really think the project needs this I won't stop you from doing work in that area ;-) Just to give you in impression: This separation would mean a complete restructuring of GAR which will take at least a week for me to do it. A week I would like to spend better on updating the farm and deploying automated builds. Best regards -- Dago From dam at opencsw.org Tue Oct 6 10:13:35 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 6 Oct 2009 10:13:35 +0200 Subject: [csw-maintainers] X11 woes Message-ID: <142A0DD9-4FB7-45D7-9092-6BA80999A7D1@opencsw.org> Hi, I am currently refreshing imlib/imlib2. On compilation they seem to pull in the old libx11 (and breaks!) as the depend on libungif which itself is compiled against the old X11. I guess it would be cleanest to go through all libraries which depend on X11 and recompile them against the new version or maybe someone has a better idea? Best regards -- Dago From maciej at opencsw.org Tue Oct 6 10:43:12 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 6 Oct 2009 09:43:12 +0100 Subject: [csw-maintainers] questions about GAR, history, and naming In-Reply-To: <32973644-DFF4-4BD1-A760-90422E02A60A@opencsw.org> References: <20091004195314.GA33599@bolthole.com> <719DE490-C858-436F-A1CC-A06029BA3D98@opencsw.org> <9046596F-57B6-4AA0-9B36-60C9F1497A56@opencsw.org> <0315E28D-99D7-42DB-A144-8A6B4E85A771@opencsw.org> <32973644-DFF4-4BD1-A760-90422E02A60A@opencsw.org> Message-ID: On Tue, Oct 6, 2009 at 8:48 AM, Dagobert Michelsen wrote: > The decision logic is already quite complex and inserting these switches > would even increase it, making it unreadable for new GAR maintainers. > And what for? If there are people from linux bbc or Garnome who want to > work in a unified development tree I would certainly help in making it. > If you really think the project needs this I won't stop you from doing > work in that area ;-) Just to give you in impression: This separation > would mean a complete restructuring of GAR which will take at least a > week for me to do it. A week I would like to spend better on updating > the farm and deploying automated builds. Is "to do things cleanly" the only reason, or are there more reasons? I think everyone would agree that, all other things equal, clean is better, nicer, and in the long term also useful. But there's also the cost. If software developer has time on their hands, they can spend time just polishing the code, making it more readable, structured, layered, functional, unit-tested, or whatever property they want it to have. However, in our case we're after very specific needs in GAR development: parallel builds and modulations. There are also other things that currently need attention. I'd like us to make development decisions based on current needs rather than aesthetics. The restructuring of GAR can be filed in an issue tracking system so the idea doesn't get lost or forgotten. Maciej From dam at opencsw.org Tue Oct 6 13:55:05 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 6 Oct 2009 13:55:05 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <20091005.9544000.198172607@gyor.oxdrove.co.uk> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> Message-ID: Hi James, Am 05.10.2009 um 11:54 schrieb James Lee: > On 05/10/09, 10:05:49, Dagobert Michelsen wrote > regarding > Re: [csw-maintainers] Handling of devel package splits: > >>>> I would like to proceed on the splitting of devel packages as a >>>> package >>>> of mine is pending release whether the decision on this topic. >>> >>>> The current poll is >>>> - 5 maintainers for "split off devel" >>>> - 1 maintainer for "decide on case-by-case" >>> >>>> Does anyone feel that there is need for more discussion? >>> >>> Yes since you are missing options and no justification is offered. >> >> And that missing options would be? > > As previously communicated. > > The only addition I have it to version runtimes as it means only one > version is needed at a time for a given depend. > > jpeg depends on jpeg7rt > jpeg7rt - latest runtime > jpeg62rt - legacy runtime > > packages depend on whichever rt version being used. I don't think this will work. It would mean that you know in advance which version is compatible to name it correctly, here you must know that jpeg62rt is the compatible version, and without naming it too strict like jpeg6203b2rt. At the same time you want the name of the package to be as easy as possible which contradicts specific naming in advance. I have written the rationale for this in the Wiki at If there are arguments for/against the split please note them there. As I haven't heard of the maintainers who have already voted I guess the votes are still valid? If not, please adjust your vote accordingly as I want to have some kind of decision to go ahead: Best regards -- Dago From trygvis at opencsw.org Tue Oct 6 14:57:06 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Tue, 06 Oct 2009 14:57:06 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> Message-ID: <4ACB3EA2.7050900@opencsw.org> Dagobert Michelsen wrote: > Hi James, > > Am 05.10.2009 um 10:54 schrieb James Lee: >> On 04/10/09, 09:47:35, Dagobert Michelsen wrote >> regarding >> Re: [csw-maintainers] Handling of devel package splits: >> >>> I would like to proceed on the splitting of devel packages as a package >>> of mine is pending release whether the decision on this topic. >> >>> The current poll is >>> - 5 maintainers for "split off devel" >>> - 1 maintainer for "decide on case-by-case" >> >>> Does anyone feel that there is need for more discussion? >> >> Yes since you are missing options and no justification is offered. > > And that missing options would be? > > The justification is that it is a Good Thing not to have headers on > a deployment machine and that it is confusing for users to sometimes > have the devel-files inside the main package and sometimes not. > >>> Has anyone (especially those who have voted) understood that the split >>> will then be mandatory for package releases? >> >> No. You have not made that clear. >> >> The poll lumps doc too but the thread subject says devel. > > What does "lumps doc" mean? > >> Your poll is void. > > Ok then, do the maintainers who have already voted feel the same? Being even more explicit in proposal might be good. In particular the point that James raised about developer vs user documentation would be good to specify. Is the "doc" package user documentation? If so, should the development documentation go into the "devel" package? It states a requirement for splitting up the package into "rt" and "devel" but where should the documentation go then? -- Trygve From maciej at opencsw.org Tue Oct 6 15:04:39 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 6 Oct 2009 14:04:39 +0100 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <49301.217.225.247.115.1254649051.squirrel@ssl.skayser.de> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <49301.217.225.247.115.1254649051.squirrel@ssl.skayser.de> Message-ID: On Sun, Oct 4, 2009 at 10:37 AM, Sebastian Kayser wrote: > Dagobert Michelsen wrote: >> I would like to proceed on the splitting of devel packages as a package >> of mine is pending release whether the decision on this topic. >> >> The current poll is >> - 5 maintainers for "split off devel" >> - 1 maintainer for "decide on case-by-case" >> >> Does anyone feel that there is need for more discussion? >> >> Has anyone (especially those who have voted) understood that the split >> will then be mandatory for package releases? > > Do we have a written out wording for what is subject to the _devel split > then? > >> Sebastian, would you be willing to unify the bugs and introduce >> the "bugs-package-link" you suggested once we have clarified this >> issue? > > ?http://bugs.opencsw.org/ I think the domain bugs.opencsw.org is too nice to use up its top-level namespace! Can we have use like bugs.opencsw.org/p/ instead? Otherwise, we could have an explicitly shortcut domain, say, b.opencsw.org for the purpose of deploying shortcuts: b.opencsw.org/, so if anybody had "search opencsw.org" in their resolv.conf, they could use http://b/ (apart from the really useful Firefox keyword shortcuts). Maciej From dam at opencsw.org Tue Oct 6 15:25:18 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 6 Oct 2009 15:25:18 +0200 Subject: [csw-maintainers] Draft of the new release process Message-ID: Hi, I have finally written down the updated release process we talked about in Oslo: It is mainly about the different uses of the experimental / testing catalogs and automated builds. Trygve: I couldn't figure out what we intended with csw-build and csw-release. As you have proposed that it would be nice if you could add that to the Wiki. I have added pictures of the slides to refresh your memory ;-) Best regards -- Dago From maciej at opencsw.org Tue Oct 6 15:29:46 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 6 Oct 2009 14:29:46 +0100 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <49301.217.225.247.115.1254649051.squirrel@ssl.skayser.de> Message-ID: I've added a note about the drawbacks of *_devel package splitting. (Note: I'm not saying that splitting overall bad. I'm saying it has drawbacks, and it's a good idea to minimize the negative impact.) Maciej From dam at opencsw.org Tue Oct 6 15:38:43 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 6 Oct 2009 15:38:43 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <4ACB3EA2.7050900@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <4ACB3EA2.7050900@opencsw.org> Message-ID: <6DFA4F1D-1B3A-4D1E-A5B0-80E7124C8118@opencsw.org> Hi, Am 06.10.2009 um 14:57 schrieb Trygve Laugst?l: > Being even more explicit in proposal might be good. Thanks for your feedback, Wiki has been clarified with your and Maciejs statements. Best regards -- Dago From maciej at opencsw.org Tue Oct 6 15:47:58 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 6 Oct 2009 14:47:58 +0100 Subject: [csw-maintainers] Draft of the new release process In-Reply-To: References: Message-ID: On Tue, Oct 6, 2009 at 2:25 PM, Dagobert Michelsen wrote: > Hi, > > I have finally written down the updated release process we > talked about in Oslo: > ? > It is mainly about the different uses of the experimental / testing > catalogs and automated builds. Yey! The mentioned script, cswrepo -- is it something that's planned or already implemented? > Trygve: I couldn't figure out what we intended with csw-build and > csw-release. As you have proposed that it would be nice if you could > add that to the Wiki. I have added pictures of the slides to refresh > your memory ;-) IIRC, There was talk about two scripts. One for the maintainers, something which would copy the ready packages into an appropriate place (bender:/home/newpkgs or equivalent) and format e-mails to the release manager. The one for the release manager would help the release manager do his thing, whatever that is. Trygve was interested in what steps are taken when a package is being released, in terms of updating information in various places (databases, files, etc). Maciej From james at opencsw.org Tue Oct 6 16:03:30 2009 From: james at opencsw.org (James Lee) Date: Tue, 06 Oct 2009 14:03:30 GMT Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> Message-ID: <20091006.14033000.2372649415@gyor.oxdrove.co.uk> On 06/10/09, 12:55:05, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Handling of devel package splits: > > The only addition I have it to version runtimes as it means only one > > version is needed at a time for a given depend. > > > > jpeg depends on jpeg7rt > > jpeg7rt - latest runtime > > jpeg62rt - legacy runtime > > > > packages depend on whichever rt version being used. > I don't think this will work. Don't think, watch the opposition. > It would mean that you know in advance > which > version is compatible to name it correctly, here you must know that > jpeg62rt > is the compatible version, and without naming it too strict like > jpeg6203b2rt. I know because of the SONAME. Example of potential saving. CSWlibicu 4.2.1,REV=2009.08.10 Package size: 14883205 installed size: 35943114 Contains libraries with 2 SONAMEs: .so.36 and .so.42 $ cat /opt/csw/lib/libicu*so.36.0 | wc -c 12916776 $ cat /opt/csw/lib/libicu*so.42.1 | wc -c 19310756 1 package uses .42 (CSWooocore), 2 use .36 (CSWtin, CSWx3270) Each could use just the rt that it needs. The best bit is when the 2 older packages are rebuilt to use the newer rt the combined package does not need rebuilding with only the used lib as the unused rt package can just be dropped. Potential savings are massive, far greater than some x lib headers. Package split: libiuc42rt - the .so.42 runtime used by CSWooocore, CSWlibicu libiuc36rt - the .so.36 runtime used by CSWtin, CSWx3270 libicu everything 4.2 except libiuc42rt No user will ever install libicu, only developers. > At the same time you want the name of the package to be as easy as > possible > which contradicts specific naming in advance. > I have written the rationale for this in the Wiki at > > Why are packages split? > There are multiple reasons why packages are split: I suppose two is "multiple" > To minimize the size of the installed software, both in terms of > megabytes and number of files In the case of the x libs (where this started) only the run time is installed for users so there are no extra development or documentation bytes. Minimising the number of package also has benefits. Quicker install. Shorter lists. Easier management. File storage is not that important. > To have a clean installation of the software (no developer files on > deployment machines) man filesytem(5). There is a handy established way of keeping the system tidy. Reasons not to split: + Many more packages to manage + No space saving when only runtimes used, which is in most cases. + It's a pain for the developer to know to install the -dev packages. Not all packages naturally have dev parts and it's not possible to tell if it's missing or never exists (oh great, lets have empty packages where none is needed to keep the system symmetric and avoid all confusion). + I always install "full" OS (because it's saves any effort when I later find something is missing) so there is no problem with finding headers on the system. + Solaris has lots of files that are never needed. Doesn't make it right but the user tolerates it, assuming a true user even notices. + CSW wastes space in many ways, this isn't the most significant. Packages are about package deals and a one size fits all approach might be best, ie, the user accepts extra bytes in exchange for a shared system. + It's pissing me off. James. From dam at opencsw.org Tue Oct 6 16:04:41 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 6 Oct 2009 16:04:41 +0200 Subject: [csw-maintainers] Draft of the new release process In-Reply-To: References: Message-ID: Hi Maciej, Am 06.10.2009 um 15:47 schrieb Maciej (Matchek) Blizinski: > On Tue, Oct 6, 2009 at 2:25 PM, Dagobert Michelsen > wrote: >> I have finally written down the updated release process we >> talked about in Oslo: >> >> It is mainly about the different uses of the experimental / testing >> catalogs and automated builds. > > Yey! > > The mentioned script, cswrepo -- is it something that's planned or > already implemented? Planned :) >> Trygve: I couldn't figure out what we intended with csw-build and >> csw-release. As you have proposed that it would be nice if you could >> add that to the Wiki. I have added pictures of the slides to refresh >> your memory ;-) > > IIRC, There was talk about two scripts. One for the maintainers, > something which would copy the ready packages into an appropriate > place (bender:/home/newpkgs or equivalent) and format e-mails to the > release manager. The one for the release manager would help the > release manager do his thing, whatever that is. Trygve was interested > in what steps are taken when a package is being released, in terms of > updating information in various places (databases, files, etc). As you see there is some more work to clarify this. Phil has already written down something of this: Best regards -- Dago From schwindt at dfki.uni-kl.de Tue Oct 6 16:16:41 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Tue, 06 Oct 2009 16:16:41 +0200 Subject: [csw-maintainers] Installation issues Message-ID: <200910061416.n96EGf18013821@dfki.uni-kl.de> Recently I do get some messages like this on installing packages. Here as an example openssh , but there are others. This could be observed on different machines, doing fresh installs or upgrades. [ verifying class ] Copying sample config to /opt/csw/etc/ssh/moduli usage: chmod [-fR] file ... chmod [-fR] file ... chmod [-fR] file ... where is a comma-separated list of [ugoa]{+|-|=}[rwxXlstugo] where is one of the following A- A[number]- A[number]{+|=} where is a comma-separated list of ACEs Copying sample config to /opt/csw/etc/ssh/sshd_config usage: chmod [-fR] file ... chmod [-fR] file ... chmod [-fR] file ... where is a comma-separated list of [ugoa]{+|-|=}[rwxXlstugo] where is one of the following A- A[number]- A[number]{+|=} where is a comma-separated list of ACEs [ verifying class ] Installing class ... This end up on disk : rw-r--r-- 1 root bin 125811 Jul 25 13:30 moduli.CSW -rwxr-xr-x 1 root root 125811 Oct 6 15:15 moduli Anyone else ? Nicolai From dam at opencsw.org Tue Oct 6 16:47:27 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 6 Oct 2009 16:47:27 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <20091006.14033000.2372649415@gyor.oxdrove.co.uk> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> <20091006.14033000.2372649415@gyor.oxdrove.co.uk> Message-ID: <3DBDD958-E508-4B74-BF39-03DD16B16BB3@opencsw.org> Hi James, Am 06.10.2009 um 16:03 schrieb James Lee: > On 06/10/09, 12:55:05, Dagobert Michelsen wrote > regarding > Re: [csw-maintainers] Handling of devel package splits: > >>> The only addition I have it to version runtimes as it means only one >>> version is needed at a time for a given depend. >>> >>> jpeg depends on jpeg7rt >>> jpeg7rt - latest runtime >>> jpeg62rt - legacy runtime >>> >>> packages depend on whichever rt version being used. > >> I don't think this will work. > > Don't think, watch the opposition. > > >> It would mean that you know in advance >> which >> version is compatible to name it correctly, here you must know that >> jpeg62rt >> is the compatible version, and without naming it too strict like >> jpeg6203b2rt. > > I know because of the SONAME. > > Example of potential saving. > > CSWlibicu 4.2.1,REV=2009.08.10 > > Package size: 14883205 > installed size: 35943114 > > Contains libraries with 2 SONAMEs: .so.36 and .so.42 > > $ cat /opt/csw/lib/libicu*so.36.0 | wc -c > 12916776 > $ cat /opt/csw/lib/libicu*so.42.1 | wc -c > 19310756 > > 1 package uses .42 (CSWooocore), 2 use .36 (CSWtin, CSWx3270) > > Each could use just the rt that it needs. > > The best bit is when the 2 older packages are rebuilt to use the > newer rt the combined package does not need rebuilding with only > the used lib as the unused rt package can just be dropped. > > Potential savings are massive, far greater than some x lib headers. > > Package split: > > libiuc42rt - the .so.42 runtime used by CSWooocore, CSWlibicu > libiuc36rt - the .so.36 runtime used by CSWtin, CSWx3270 > libicu everything 4.2 except libiuc42rt > > No user will ever install libicu, only developers. Ok, that means you look what is linked against and then decide how the rt is named? > At the same time you want the name of the package to be as easy as >> possible >> which contradicts specific naming in advance. > >> I have written the rationale for this in the Wiki at >> > >> Why are packages split? > >> There are multiple reasons why packages are split: > > I suppose two is "multiple" > > >> To minimize the size of the installed software, both in terms of >> megabytes and number of files > > In the case of the x libs (where this started) only the run time is > installed for users so there are no extra development or documentation > bytes. > > Minimising the number of package also has benefits. Quicker install. > Shorter lists. Easier management. > > File storage is not that important. > > >> To have a clean installation of the software (no developer files on >> deployment machines) > > man filesytem(5). There is a handy established way of keeping the > system tidy. Separating filesystems still gets them inside the tree. > Reasons not to split: > > + Many more packages to manage > > + No space saving when only runtimes used, which is in most cases. > > + It's a pain for the developer to know to install the -dev packages. > Not all packages naturally have dev parts and it's not possible to > tell if it's missing or never exists (oh great, lets have empty > packages where none is needed to keep the system symmetric and avoid > all confusion). > > + I always install "full" OS (because it's saves any effort when I > later find something is missing) so there is no problem with finding > headers on the system. > > + Solaris has lots of files that are never needed. Doesn't make it > right but the user tolerates it, assuming a true user even notices. > > + CSW wastes space in many ways, this isn't the most significant. > Packages are about package deals and a one size fits all approach > might be best, ie, the user accepts extra bytes in exchange for > a shared system. Added to the wiki for further discussion. > + It's pissing me off. Not added to the wiki. Best regards -- Dago From james at opencsw.org Tue Oct 6 17:17:47 2009 From: james at opencsw.org (James Lee) Date: Tue, 06 Oct 2009 15:17:47 GMT Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <3DBDD958-E508-4B74-BF39-03DD16B16BB3@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> <20091006.14033000.2372649415@gyor.oxdrove.co.uk> <3DBDD958-E508-4B74-BF39-03DD16B16BB3@opencsw.org> Message-ID: <20091006.15174700.2402857481@gyor.oxdrove.co.uk> On 06/10/09, 15:47:27, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Handling of devel package splits: > >>> The only addition I have it to version runtimes as it means only one > >>> version is needed at a time for a given depend. > >>> > >>> jpeg depends on jpeg7rt > >>> jpeg7rt - latest runtime > >>> jpeg62rt - legacy runtime > >>> > >>> packages depend on whichever rt version being used. > > > >> I don't think this will work. > > > > Don't think, watch the opposition. > > > > > >> It would mean that you know in advance > >> which > >> version is compatible to name it correctly, here you must know that > >> jpeg62rt > >> is the compatible version, and without naming it too strict like > >> jpeg6203b2rt. > > > > I know because of the SONAME. > > > > Example of potential saving. > > > > CSWlibicu 4.2.1,REV=2009.08.10 > > > > Package size: 14883205 > > installed size: 35943114 > > > > Contains libraries with 2 SONAMEs: .so.36 and .so.42 > > > > $ cat /opt/csw/lib/libicu*so.36.0 | wc -c > > 12916776 > > $ cat /opt/csw/lib/libicu*so.42.1 | wc -c > > 19310756 > > > > 1 package uses .42 (CSWooocore), 2 use .36 (CSWtin, CSWx3270) > > > > Each could use just the rt that it needs. > > > > The best bit is when the 2 older packages are rebuilt to use the > > newer rt the combined package does not need rebuilding with only > > the used lib as the unused rt package can just be dropped. > > > > Potential savings are massive, far greater than some x lib headers. > > > > Package split: > > > > libiuc42rt - the .so.42 runtime used by CSWooocore, CSWlibicu > > libiuc36rt - the .so.36 runtime used by CSWtin, CSWx3270 > > libicu everything 4.2 except libiuc42rt > > > > No user will ever install libicu, only developers. > Ok, that means you look what is linked against and then decide > how the rt is named? No, I look at the SONAME, this defines the library that is used. In the case of PNG there are 2 SONAMEs indicating version: libpng12.so.0 libpng.so.3 but rather than use the actual SONAME's number I'd assume that the major package version change mirrors the so changes, so for PNG I guess it would simply follow the package version. Either way it's just a name. Same SONAME, same RT package name. Bumped SONAME, new RT package name. James. From maciej at opencsw.org Tue Oct 6 17:55:51 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 6 Oct 2009 16:55:51 +0100 Subject: [csw-maintainers] GAR modulations questions Message-ID: I have two issues regarding modulations. One is a feature request. Suppose I have two extra modulators, foo and bar. If each has two values, I end up with four... um... modulations. The name for each modulation is foomod-foovar-barmod-barval. If I want to add my own merge rules, I need to enter: MERGE_foomod-fooval1-barmod-barval1 = ... MERGE_foomod-fooval1-barmod-barval2 = ... MERGE_foomod-fooval2-barmod-barval1 = ... MERGE_foomod-fooval2-barmod-barval2 = ... Suppose I have a merge rule that applies to both values of barmod. I would like then to say: MERGE_foomod-fooval1 = one thing MERGE_foomod-fooval2 = some other thing The desired effect is that "one thing" is included in both barval1 and barval2 modulations. Is it doable? The second thing, version-modulated distfiles. Can we, instead of creating the list and the filtering it, include only the right versions? For instance: DISTFILES_version-$(GARVERSION) = $(GARNAME)-$(GARVERSION).tar.gz ...and then have DISTFILES being assembled by GAR? Maciej From phil at bolthole.com Tue Oct 6 18:02:16 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 6 Oct 2009 09:02:16 -0700 Subject: [csw-maintainers] questions about GAR, history, and naming In-Reply-To: References: <20091004195314.GA33599@bolthole.com> <719DE490-C858-436F-A1CC-A06029BA3D98@opencsw.org> <9046596F-57B6-4AA0-9B36-60C9F1497A56@opencsw.org> <0315E28D-99D7-42DB-A144-8A6B4E85A771@opencsw.org> <32973644-DFF4-4BD1-A760-90422E02A60A@opencsw.org> Message-ID: On Tue, Oct 6, 2009 at 1:43 AM, Maciej (Matchek) Blizinski wrote: >I'd like us to make development > decisions based on current needs rather than aesthetics. The > restructuring of GAR can be filed in an issue tracking system so the > idea doesn't get lost or forgotten. Hmm. an idea that is filed away and never acted upon, may as well be forgotten. The idea of having a proper "gar package" that is a CSW package, has been lurking around for YEARS now, and never acted upon. > Is "to do things cleanly" the only reason, or are there more reasons? Well, to me, it is also somewhat of a branding issue. We cant really publicise our build system fairly. It's almost as bad as sun labelling everything they do, "sun java xxxx" :-) Claiming "we use gar", at this point,is very wrong. What we use is not "gar", but "gar++". And the longer we wait to fix this issue, the worse it gets. It would have been easier to fix this a year ago, than now, I think everyone can agree. It stands to reason it will be even more difficult to fix this a year in the future, than to fix this now. It bothers me to the point where I would do the work myself, but all my "free" time goes to package release issues, etc. From dam at opencsw.org Tue Oct 6 18:04:55 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 6 Oct 2009 18:04:55 +0200 Subject: [csw-maintainers] GAR modulations questions In-Reply-To: References: Message-ID: <5BC0D8E5-7CE6-4FE3-8BD3-942F5685FD72@opencsw.org> Hi Maciej, Am 06.10.2009 um 17:55 schrieb Maciej (Matchek) Blizinski: > I have two issues regarding modulations. One is a feature request. > Suppose I have two extra modulators, foo and bar. If each has two > values, I end up with four... um... modulations. The name for each > modulation is foomod-foovar-barmod-barval. If I want to add my own > merge rules, I need to enter: > > MERGE_foomod-fooval1-barmod-barval1 = ... > MERGE_foomod-fooval1-barmod-barval2 = ... > MERGE_foomod-fooval2-barmod-barval1 = ... > MERGE_foomod-fooval2-barmod-barval2 = ... > > Suppose I have a merge rule that applies to both values of barmod. I > would like then to say: > > MERGE_foomod-fooval1 = one thing > MERGE_foomod-fooval2 = some other thing > > The desired effect is that "one thing" is included in both barval1 and > barval2 modulations. Is it doable? Sure. But I don't see a usecase for this. Usually you take all from barval1 and only some specific things with renames from barval2. Additionally, the modulators grow long with the default ISA modulation and maybe the added version modulator. Some kind of sane defaults can make this much easier to use. Can I have a look at your Makefile? > The second thing, version-modulated distfiles. Can we, instead of > creating the list and the filtering it, include only the right > versions? For instance: > > DISTFILES_version-$(GARVERSION) = $(GARNAME)-$(GARVERSION).tar.gz > > ...and then have DISTFILES being assembled by GAR? I have already tought of something similar as you your left-hand side would expand during Makefile parsing. You would need some kind of definition like VDISTFILES = $$(GARNAME)-$$(VERSION).tar.gz which would then be expanded during evaluation. It would also allow automatic upstream watches with substituted $$(VERSION) for UWATCH and easier version modulations. But before I make more changes to GAR I would like to deploy v2-pbuild for general use, so please everyone test! Best regards -- Dago From maciej at opencsw.org Tue Oct 6 18:16:36 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 6 Oct 2009 17:16:36 +0100 Subject: [csw-maintainers] GAR modulations questions In-Reply-To: <5BC0D8E5-7CE6-4FE3-8BD3-942F5685FD72@opencsw.org> References: <5BC0D8E5-7CE6-4FE3-8BD3-942F5685FD72@opencsw.org> Message-ID: On Tue, Oct 6, 2009 at 5:04 PM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 06.10.2009 um 17:55 schrieb Maciej (Matchek) Blizinski: >> >> I have two issues regarding modulations. One is a feature request. >> Suppose I have two extra modulators, foo and bar. If each has two >> values, I end up with four... um... modulations. The name for each >> modulation is foomod-foovar-barmod-barval. If I want to add my own >> merge rules, I need to enter: >> >> MERGE_foomod-fooval1-barmod-barval1 = ... >> MERGE_foomod-fooval1-barmod-barval2 = ... >> MERGE_foomod-fooval2-barmod-barval1 = ... >> MERGE_foomod-fooval2-barmod-barval2 = ... >> >> Suppose I have a merge rule that applies to both values of barmod. I >> would like then to say: >> >> MERGE_foomod-fooval1 = one thing >> MERGE_foomod-fooval2 = some other thing >> >> The desired effect is that "one thing" is included in both barval1 and >> barval2 modulations. Is it doable? > > Sure. But I don't see a usecase for this. Usually you take all from > barval1 and only some specific things with renames from barval2. > Additionally, the modulators grow long with the default ISA modulation > and maybe the added version modulator. Some kind of sane defaults > can make this much easier to use. > Can I have a look at your Makefile? Here's my minimal example: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/examples/modulations/branches/minimal-version-modulation/Makefile > But before I make more changes to GAR I would like to deploy v2-pbuild > for general use, so please everyone test! Okay, I'm going to start using it with the packages I'm currently working on. Maciej From bwalton at opencsw.org Tue Oct 6 19:12:51 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 06 Oct 2009 13:12:51 -0400 Subject: [csw-maintainers] passwd -N Message-ID: <1254848861-sup-1353@ntdws12.chass.utoronto.ca> Is anyone aware of a clever alternative to solaris 10's `passwd -N` for munging the password field in a shadow file? Ultimately, I'd prefer not to twiddle the file with sed, but that seems to be the best option I've found. Any help is appreciated. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Oct 6 19:18:21 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 6 Oct 2009 19:18:21 +0200 Subject: [csw-maintainers] GAR modulations questions In-Reply-To: References: <5BC0D8E5-7CE6-4FE3-8BD3-942F5685FD72@opencsw.org> Message-ID: <2C186202-52BD-4D17-A1F8-B0CBD8727EFD@opencsw.org> Hi Maciej, Am 06.10.2009 um 18:16 schrieb Maciej (Matchek) Blizinski: > Here's my minimal example: > > https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/examples/modulations/branches/minimal-version-modulation/Makefile Ok. But allow me the comment that this is a real special case. I have exactly 1 (one) package that needs this (automake) and I do it with $(foreach VERSION,$(MODULATIONS_GARVERSION),$(eval MERGE_SCRIPTS_isa-$(ISA)-garversion-$(VERSION) = copy-all)) All other packages need different rules: expat flac libmm libtool neon openldap readline Usually you have something like this: MERGE_SCRIPTS_isa-i386-garversion-1.95.8 = copy-only MERGE_DIRS_isa-i386-garversion-1.95.8 = $(libdir) MERGE_SCRIPTS_isa-amd64-garversion-1.95.8 = copy-relocated-only MERGE_DIRS_isa-amd64-garversion-1.95.8 = $(libdir) MERGE_SCRIPTS_isa-i386-garversion-2.0.1 = copy-all MERGE_SCRIPTS_isa-amd64-garversion-2.0.1 = copy-relocated-only MERGE_DIRS_isa-amd64-garversion-2.0.1 = $(bindir) $(sbindir) $ (libexecdir) $(libdir) MERGE_SCRIPTS_isa-sparcv8-garversion-1.95.8 = copy-only MERGE_DIRS_isa-sparcv8-garversion-1.95.8 = $(libdir) MERGE_SCRIPTS_isa-sparcv9-garversion-1.95.8 = copy-relocated-only MERGE_DIRS_isa-sparcv9-garversion-1.95.8 = $(libdir) MERGE_SCRIPTS_isa-sparcv8-garversion-2.0.1 = copy-all MERGE_SCRIPTS_isa-sparcv9-garversion-2.0.1 = copy-relocated-only MERGE_DIRS_isa-sparcv9-garversion-2.0.1 = $(bindir) $(sbindir) $ (libexecdir) $(libdir) which could be collapsed with smart merge rules as MERGE_SCRIPTS_isa-default-garversion-extra = copy-only MERGE_DIRS_isa-default-garversion-extra = $(libdir) MERGE_SCRIPTS_isa-extra-garversion-extra = copy-relocated-only MERGE_DIRS_isa-extra-garversion-extra = $(libdir) MERGE_SCRIPTS_isa-default-garversion-default = copy-all MERGE_SCRIPTS_isa-extra-garversion-default = copy-relocated-only MERGE_DIRS_isa-extra-garversion-default = $(bindir) $(sbindir) $ (libexecdir) $(libdir) And this can be the default for version modulations if it were built-in. Best regards -- Dago From phil at bolthole.com Tue Oct 6 19:20:36 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 6 Oct 2009 10:20:36 -0700 Subject: [csw-maintainers] X11 woes In-Reply-To: <142A0DD9-4FB7-45D7-9092-6BA80999A7D1@opencsw.org> References: <142A0DD9-4FB7-45D7-9092-6BA80999A7D1@opencsw.org> Message-ID: On Tue, Oct 6, 2009 at 1:13 AM, Dagobert Michelsen wrote: > Hi, > > I am currently refreshing imlib/imlib2. On compilation they seem to pull > in the old libx11 (and breaks!) as the depend on libungif which itself > is compiled against the old X11. I guess it would be cleanest to go > through all libraries which depend on X11 and recompile them against the > new version or maybe someone has a better idea? > > that is a little overkill. Lets get more specific here: Since YOU "broke", you now need to ensure that everything that depends on it, gets recompiled. Either that, or provide an older compat version of libungif. Other stuf that still works, can be left alone, even if it uses standard "old libx11". From maciej at opencsw.org Tue Oct 6 19:33:35 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 6 Oct 2009 18:33:35 +0100 Subject: [csw-maintainers] GAR modulations questions In-Reply-To: <2C186202-52BD-4D17-A1F8-B0CBD8727EFD@opencsw.org> References: <5BC0D8E5-7CE6-4FE3-8BD3-942F5685FD72@opencsw.org> <2C186202-52BD-4D17-A1F8-B0CBD8727EFD@opencsw.org> Message-ID: On Tue, Oct 6, 2009 at 6:18 PM, Dagobert Michelsen wrote: > Ok. But allow me the comment that this is a real special case. OK, I understand. > MERGE_SCRIPTS_isa-i386-garversion-2.0.1 = copy-all > MERGE_SCRIPTS_isa-amd64-garversion-2.0.1 = copy-relocated-only > MERGE_DIRS_isa-amd64-garversion-2.0.1 = $(bindir) $(sbindir) $(libexecdir) > $(libdir) More questions are coming: Why are MERGE_DIRS needed? How do I make sure I have the right ones? From mwatters at opencsw.org Tue Oct 6 21:24:13 2009 From: mwatters at opencsw.org (Mike Watters) Date: Tue, 06 Oct 2009 14:24:13 -0500 Subject: [csw-maintainers] sendmail-8.14.3 in testing Message-ID: <4ACB995D.90707@opencsw.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 once Dago is done with berkeley DB it will be recompiled based on the "new" package names for bdb. please test and provide feedback. - -- ~Mike "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." --> Albert Einstein 1879 - 1955 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrLmV0ACgkQLrhmsXMSLxcCvwCfbD1K8s6MUG0qYU0SJBjTRNwY YfwAoIZKLWZm0FKSFVRrckthtfrwYnZc =aqI+ -----END PGP SIGNATURE----- From skayser at opencsw.org Tue Oct 6 22:09:34 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 6 Oct 2009 22:09:34 +0200 (CEST) Subject: [csw-maintainers] BerkeleyDB final call In-Reply-To: References: Message-ID: <52119.194.246.122.22.1254859774.squirrel@ssl.skayser.de> Dagobert Michelsen wrote: > The packages are available from > > and there are subdirectories for Solaris 8 Sparc and x86 with catalogs > which should allow direct updating with pkg-get/pkgutil. > Additionally all packages have been installed on test8s and test8x. > > To make this transition less painful than the previous one please > test the new packages in your environment, test them with the > packages which failed last time and the packages you would consider > most important. Thanks Dago for working towards the old status quo. Attached is a list of packages directly depending on CSWbdb* packages. If someone spots a package he is using regularly (best in a scenario with bdb involved), please help testing by updating your BDB packages. CSWap2modapreq2 CSWap2modphp4 CSWap2prefork CSWap2worker CSWapache CSWapache2c CSWapache2rt CSWcfengine CSWclaws-mail CSWcourierauth CSWcourierimap CSWcyrusimapd CSWcyrusimapdutils CSWdsniff CSWjavasvn CSWkdesdk CSWkdesdk CSWkdevelop CSWkdevelop CSWlibapreq2 CSWlibetpan CSWmaildrop CSWmodphp4 CSWoldap CSWooocore CSWperl CSWphp4cgi CSWphp4dba CSWphp5dba CSWpmapreq2 CSWpmberkeleydb CSWpmcyrus CSWpmsvn CSWpostfix CSWpysvn CSWpython CSWrbsvn CSWruby CSWsasl CSWsendmail CSWsquidguard CSWsqwebmail CSWsvn CSWwebalizer Dago has setup a separate subdirectory in testing/ where you can upgrade from, so you will only get BDB updates (and none of the possibly-in-development-pkgs from testing). Sebastian From mwatters at opencsw.org Tue Oct 6 22:17:09 2009 From: mwatters at opencsw.org (Mike Watters) Date: Tue, 06 Oct 2009 15:17:09 -0500 Subject: [csw-maintainers] libssh2 1.2.1 in testing Message-ID: <4ACBA5C5.5030804@opencsw.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Changes: upgraded to version 1.2.1 feedback welcome - -- ~Mike "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." --> Albert Einstein 1879 - 1955 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrLpcQACgkQLrhmsXMSLxczbwCdGL3niQV1rG6L7ECKYSTPt/ZP yjYAn3fUYad0TFKm/Kg5a57i8pqWxVmM =gL9w -----END PGP SIGNATURE----- From mwatters at opencsw.org Tue Oct 6 22:49:55 2009 From: mwatters at opencsw.org (Mike Watters) Date: Tue, 06 Oct 2009 15:49:55 -0500 Subject: [csw-maintainers] drupal 6.14 now in testing Message-ID: <4ACBAD73.2060905@opencsw.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Changes: updated to 6.14 - -- ~Mike "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." --> Albert Einstein 1879 - 1955 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrLrXMACgkQLrhmsXMSLxdK2gCeNtf1v6nNziHzQG9CtyH/TRka 32AAmgJWzM3fQa8sNJCjDt8ZeEr1QAjs =BD0J -----END PGP SIGNATURE----- From bchill at opencsw.org Wed Oct 7 07:54:48 2009 From: bchill at opencsw.org (Brian Hill) Date: Wed, 7 Oct 2009 05:54:48 +0000 Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <4ACB995D.90707@opencsw.org> References: <4ACB995D.90707@opencsw.org> Message-ID: <20091007055448.GA13472@vm-1.bch.net> Hi Mike, I assume that this should work with existing CSWberkeleydb package until you rebuild it with the new berk db package name. Am I missing something? ... Updated description file INTERNAL ERROR: cannot get remote version for CSWbdb Perhaps your catalog is out of date Error: dependancies for sendmail not up to date. You may call pkg-get again with '-v -u sendmail' to see which ones Or, call pkg-get with 'upgrade' to bring all installed pkgs up to date Brian ====================================================================== On Tue, Oct 06, 2009 at 02:24:13PM -0500, Mike Watters wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > once Dago is done with berkeley DB it will be recompiled based on the "new" > package names for bdb. > > please test and provide feedback. > > > - -- > ~Mike > "Any intelligent fool can make things bigger, more complex, > and more violent. It takes a touch of genius -- and a lot of courage -- > to move in the opposite direction." --> Albert Einstein 1879 - 1955 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (SunOS) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkrLmV0ACgkQLrhmsXMSLxcCvwCfbD1K8s6MUG0qYU0SJBjTRNwY > YfwAoIZKLWZm0FKSFVRrckthtfrwYnZc > =aqI+ > -----END PGP SIGNATURE----- > _______________________________________________ > users mailing list > users at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/users -- _____________________________________________________________________ / Brian C. Hill bchill at bch.net http://brian.bch.net \ | UNIX Specialist BCH Technical Services http://www.bch.net | From dam at opencsw.org Wed Oct 7 13:39:54 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 7 Oct 2009 13:39:54 +0200 Subject: [csw-maintainers] questions about GAR, history, and naming In-Reply-To: References: <20091004195314.GA33599@bolthole.com> <719DE490-C858-436F-A1CC-A06029BA3D98@opencsw.org> <9046596F-57B6-4AA0-9B36-60C9F1497A56@opencsw.org> <0315E28D-99D7-42DB-A144-8A6B4E85A771@opencsw.org> <32973644-DFF4-4BD1-A760-90422E02A60A@opencsw.org> Message-ID: <493A50BB-64A2-457D-A307-185096960F35@opencsw.org> Hi Phil, Am 06.10.2009 um 18:02 schrieb Philip Brown: > On Tue, Oct 6, 2009 at 1:43 AM, Maciej (Matchek) Blizinski > wrote: >> I'd like us to make development >> decisions based on current needs rather than aesthetics. The >> restructuring of GAR can be filed in an issue tracking system so the >> idea doesn't get lost or forgotten. > > Hmm. an idea that is filed away and never acted upon, may as well be > forgotten. > The idea of having a proper "gar package" that is a CSW package, has > been lurking around for YEARS now, and never acted upon. It is not forgotten. A GAR package is lurking around in newpkgs/ since May and you didn't want to release it ;-) To get something done there are two ways: either do it yourself or find someone to do it. I may have put more energy to source packages if you would show real interest in GAR by using it for your packages or at least to a level where you can reproduce a build without the demand that "someone writes up an interface for me that I can do 'gartool compile '". And now you are proposing a complete rewrite of GAR which means at least a week of work for me only for you to feel better about it. If you want a rewrite of GAR at least learn the basics on how to use it. >> Is "to do things cleanly" the only reason, or are there more reasons? > > Well, to me, it is also somewhat of a branding issue. We cant really > publicise our build system fairly. It's almost as bad as sun labelling > everything they do, "sun java xxxx" :-) > Claiming "we use gar", at this point,is very wrong. What we use is not > "gar", but "gar++". > And the longer we wait to fix this issue, the worse it gets. It is perfectly ok to say that we use "gar++" to build our packages. The sources are available at SF under the project name "gar". > It would have been easier to fix this a year ago, than now, I think > everyone can agree. > It stands to reason it will be even more difficult to fix this a year > in the future, than to fix this now. > > It bothers me to the point where I would do the work myself, but all > my "free" time goes to package release issues, etc. That is a real pitty as I don't have time for this either. Best regards -- Dago From dam at opencsw.org Wed Oct 7 14:36:01 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 7 Oct 2009 14:36:01 +0200 Subject: [csw-maintainers] Proposal for name of our GAR version Message-ID: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> Hi, I did some thinking about a name for our version of the GAR build system and ended up with "GARISOL". This is an anagram of girasol, which is italian for sunflower showing the affinity both to GAR and Solaris without being an actual word - this makes searching for it and reserving names easier. Feedback especially welcome! Best regards -- Dago From dam at opencsw.org Wed Oct 7 14:41:31 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 7 Oct 2009 14:41:31 +0200 Subject: [csw-maintainers] passwd -N In-Reply-To: <1254848861-sup-1353@ntdws12.chass.utoronto.ca> References: <1254848861-sup-1353@ntdws12.chass.utoronto.ca> Message-ID: <47474866-5DFA-48C5-8DA4-4D0CEFB5F373@opencsw.org> Hi Ben, Am 06.10.2009 um 19:12 schrieb Ben Walton: > Is anyone aware of a clever alternative to solaris 10's `passwd -N` > for munging the password field in a shadow file? Ultimately, I'd > prefer not to twiddle the file with sed, but that seems to be the best > option I've found. Yes. It may be a little clean with awk: awk -F: 'BEGIN { OFS=":" } $1 == "dam" { $2 = "NP" } { print }' < / etc/shadow Best regards -- Dago From maciej at opencsw.org Wed Oct 7 14:50:13 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 7 Oct 2009 13:50:13 +0100 Subject: [csw-maintainers] GAR Platform builds now open for testing In-Reply-To: References: <0F1DEF08-4D55-4224-ADFC-DE1DD712E9A7@opencsw.org> <05F1A42C-9047-4EBF-A531-3A2212A8DC19@opencsw.org> Message-ID: I've got a problem with building cups: $ ENABLE_CHECK=0 gmake platforms (...) mkp: exec( gzip -9 -f /tmp/cupsd-1.4.0,REV=2009.10.07.14.32-SunOS5.8-i386-CSW.pkg ) mkp: exec( mv /tmp/cupsd-1.4.0,REV=2009.10.07.14.32-SunOS5.8-i386-CSW.pkg.gz /home/maciej/staging/build-2009-10-07 ) mkp: exec( rm -rf /home/maciej/spool.5.8-i386/CSWcupsd ) ==> Checking compliance: CSWcupsd ERROR: /home/maciej/staging/build-2009-10-07/cupsd-1.4.0,REV=2009.10.07.14.33-SunOS5.8-i386-CSW.pkg.gz does not exist gmake: *** [pkgcheck-CSWcupsd] Error 2 gmake: Leaving directory `/home/maciej/src/opencsw/pkg/cups/branches/cups-1.4' Connection to build8x closed. gmake: *** [platforms] Error 2 Looks like it's the usual checkpkg problem, this only this time ENABLE_CHECK=0 doesn't work around the issue. Any ideas? It's the cups-1.4 branch. Maciej From dam at opencsw.org Wed Oct 7 14:51:56 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 7 Oct 2009 14:51:56 +0200 Subject: [csw-maintainers] GAR modulations questions In-Reply-To: References: <5BC0D8E5-7CE6-4FE3-8BD3-942F5685FD72@opencsw.org> <2C186202-52BD-4D17-A1F8-B0CBD8727EFD@opencsw.org> Message-ID: <6E5C90B7-073B-46FC-AD64-0897884DA807@opencsw.org> Hi Maciej, Am 06.10.2009 um 19:33 schrieb Maciej (Matchek) Blizinski: > On Tue, Oct 6, 2009 at 6:18 PM, Dagobert Michelsen > wrote: >> Ok. But allow me the comment that this is a real special case. > > OK, I understand. > >> MERGE_SCRIPTS_isa-i386-garversion-2.0.1 = copy-all >> MERGE_SCRIPTS_isa-amd64-garversion-2.0.1 = copy-relocated-only >> MERGE_DIRS_isa-amd64-garversion-2.0.1 = $(bindir) $(sbindir) $ >> (libexecdir) $(libdir) > > More questions are coming: > > Why are MERGE_DIRS needed? How do I make sure I have the right ones? Remember pages 46/47 from the Advanced GAR presentation: You need the dirs for the rules "copy-only" and "copy-relocated-only". They specify which directories from the installed files for that modulation will go into the package. Usually you use this for stuff which is somewhat "extra" to the package: extra (older) libraries, extra (64 bit) binaries etc. The default can be thought of $(bindir) $(sbindir) $(libexecdir) $(libdir) which basically means "everything sensible". If you want only libs (e. g. when doing 64 bits) and no executable you do $(libdir) I have started to write this up at (Don't look yet, I have *just* started ;-) Best regards -- Dago From bwalton at opencsw.org Wed Oct 7 15:16:48 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 07 Oct 2009 09:16:48 -0400 Subject: [csw-maintainers] Proposal for name of our GAR version In-Reply-To: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> References: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> Message-ID: <1254921389-sup-6432@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Oct 07 08:36:01 -0400 2009: > I did some thinking about a name for our version of the GAR build > system and ended up with "GARISOL". This is an anagram of girasol, > which is italian for sunflower showing the affinity both to GAR > and Solaris without being an actual word - this makes searching for > it and reserving names easier. I like it! -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Wed Oct 7 15:26:35 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 7 Oct 2009 14:26:35 +0100 Subject: [csw-maintainers] Proposal for name of our GAR version In-Reply-To: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> References: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> Message-ID: On Wed, Oct 7, 2009 at 1:36 PM, Dagobert Michelsen wrote: > Hi, > > I did some thinking about a name for our version of the GAR build > system and ended up with "GARISOL". This is an anagram of girasol, > which is italian for sunflower showing the affinity both to GAR > and Solaris without being an actual word - this makes searching for > it and reserving names easier. How about shortening it to "garis"? It's nicer to pronounce. It also makes me thing of tardis. http://en.wikipedia.org/wiki/TARDIS We could also have "gardis". (The time machine! Bigger inside than outside!) Maciej From bwalton at opencsw.org Wed Oct 7 15:28:56 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 07 Oct 2009 09:28:56 -0400 Subject: [csw-maintainers] passwd -N In-Reply-To: <47474866-5DFA-48C5-8DA4-4D0CEFB5F373@opencsw.org> References: <1254848861-sup-1353@ntdws12.chass.utoronto.ca> <47474866-5DFA-48C5-8DA4-4D0CEFB5F373@opencsw.org> Message-ID: <1254922080-sup-8462@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Oct 07 08:41:31 -0400 2009: > Yes. It may be a little clean with awk: > awk -F: 'BEGIN { OFS=":" } $1 == "dam" { $2 = "NP" } { print }' < / > etc/shadow Thanks Dago. I said 'sed' but meant 'some manual tool.' Manual it is. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Wed Oct 7 15:34:21 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 07 Oct 2009 09:34:21 -0400 Subject: [csw-maintainers] Proposal for name of our GAR version In-Reply-To: References: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> Message-ID: <1254922433-sup-411@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Wed Oct 07 09:26:35 -0400 2009: > How about shortening it to "garis"? It's nicer to pronounce. It also > makes me thing of tardis. I still prefer GARISOL, but great reference! :) -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Wed Oct 7 16:07:17 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 7 Oct 2009 16:07:17 +0200 Subject: [csw-maintainers] GAR Platform builds now open for testing In-Reply-To: References: <0F1DEF08-4D55-4224-ADFC-DE1DD712E9A7@opencsw.org> <05F1A42C-9047-4EBF-A531-3A2212A8DC19@opencsw.org> Message-ID: <32788F30-9EF8-4D54-8640-911A74FD7FA3@opencsw.org> Hi Maciej, Am 07.10.2009 um 14:50 schrieb Maciej (Matchek) Blizinski: > I've got a problem with building cups: > > $ ENABLE_CHECK=0 gmake platforms > (...) > mkp: exec( gzip -9 -f > /tmp/cupsd-1.4.0,REV=2009.10.07.14.32-SunOS5.8-i386-CSW.pkg ) > mkp: exec( mv /tmp/cupsd-1.4.0,REV=2009.10.07.14.32-SunOS5.8-i386- > CSW.pkg.gz > /home/maciej/staging/build-2009-10-07 ) > mkp: exec( rm -rf /home/maciej/spool.5.8-i386/CSWcupsd ) > ==> Checking compliance: CSWcupsd > ERROR: /home/maciej/staging/build-2009-10-07/ > cupsd-1.4.0,REV=2009.10.07.14.33-SunOS5.8-i386-CSW.pkg.gz > does not exist The problem is that you use high resolution timestamps which have changed during build: mkp: exec( mv /tmp/ cupsd-1.4.0,REV=2009.10.07.14.32-SunOS5.8-i386-CSW.pkg.gz ERROR: /home/maciej/staging/build-2009-10-07/ cupsd-1.4.0,REV=2009.10.07.14.33-SunOS5.8-i386-CSW.pkg.gz I have solved this with SETONCE magic, using recursively expanded variable as if they were simply expanded: SETONCE = $(eval $(1) ?= $(2)) $(call SETONCE,myvar,myvalue) Because it is only set once the value can not change during make, and if it is not used it is never expanded making its use also fast :-) > gmake: *** [pkgcheck-CSWcupsd] Error 2 > gmake: Leaving directory `/home/maciej/src/opencsw/pkg/cups/branches/ > cups-1.4' > Connection to build8x closed. > gmake: *** [platforms] Error 2 > > Looks like it's the usual checkpkg problem, this only this time > ENABLE_CHECK=0 doesn't work around the issue. Any ideas? > > It's the cups-1.4 branch. The following error persists: > Doing late evaluations of package library dependencies. > ERROR: Couldn't find a package providing libcupscgi.so.1 > gmake: *** [pkgcheck-CSWcupsd] Error 2 This however seems to be a bug in the file-distribution in PKGFILES as the library is generally there: > build8s% find . -name libcupscgi.so.1 > ./work/solaris8-sparc/pkgroot/opt/csw/lib/libcupscgi.so.1 > ./work/solaris8-sparc/build-isa-sparcv8/cups-1.4.0/cgi-bin/ > libcupscgi.so.1 > ./work/solaris8-sparc/install-isa-sparcv8/opt/csw/lib/libcupscgi.so.1 > build8s% grep libcupscgi.so.1 work/solaris8-sparc/build-global/ > *.prototype Best regards -- Dago From mwatters at opencsw.org Wed Oct 7 16:41:02 2009 From: mwatters at opencsw.org (Mike Watters) Date: Wed, 07 Oct 2009 09:41:02 -0500 Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <20091007055448.GA13472@vm-1.bch.net> References: <4ACB995D.90707@opencsw.org> <20091007055448.GA13472@vm-1.bch.net> Message-ID: <4ACCA87E.6080903@opencsw.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Hill wrote: > Hi Mike, > > I assume that this should work with existing CSWberkeleydb > package until you rebuild it with the new berk db package name. > > Am I missing something? > > ... > Updated description file > INTERNAL ERROR: cannot get remote version for CSWbdb > Perhaps your catalog is out of date > Error: dependancies for sendmail not up to date. > You may call pkg-get again with '-v -u sendmail' to see which ones > Or, call pkg-get with 'upgrade' to bring all installed pkgs up to date > > Brian > ====================================================================== > On Tue, Oct 06, 2009 at 02:24:13PM -0500, Mike Watters wrote: > once Dago is done with berkeley DB it will be recompiled based on the "new" > package names for bdb. > > please test and provide feedback. > > That error usually means it can't find the version in the "testing catalog" do a pkg-get -U -u bdb from the "current" catalog and you should get the right version. _______________________________________________ users mailing list users at lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/users - -- ~Mike "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." --> Albert Einstein 1879 - 1955 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrMqH0ACgkQLrhmsXMSLxfjCwCfdVKhX1OUccluozOex5FUOOy/ t4sAn1sBZdHcVgcICob08dKLD2ndcTHV =y8+r -----END PGP SIGNATURE----- From bchill at opencsw.org Wed Oct 7 17:33:25 2009 From: bchill at opencsw.org (Brian Hill) Date: Wed, 7 Oct 2009 15:33:25 +0000 Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <4ACCA87E.6080903@opencsw.org> References: <4ACB995D.90707@opencsw.org> <20091007055448.GA13472@vm-1.bch.net> <4ACCA87E.6080903@opencsw.org> Message-ID: <20091007153325.GA23587@vm-1.bch.net> On Wed, Oct 07, 2009 at 09:41:02AM -0500, Mike Watters wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Brian Hill wrote: > > Hi Mike, > > > > I assume that this should work with existing CSWberkeleydb > > package until you rebuild it with the new berk db package name. > > > > Am I missing something? > > > > ... > > Updated description file > > INTERNAL ERROR: cannot get remote version for CSWbdb > > Perhaps your catalog is out of date > > Error: dependancies for sendmail not up to date. > > You may call pkg-get again with '-v -u sendmail' to see which ones > > Or, call pkg-get with 'upgrade' to bring all installed pkgs up to date > > > > Brian > > ====================================================================== > > On Tue, Oct 06, 2009 at 02:24:13PM -0500, Mike Watters wrote: > > once Dago is done with berkeley DB it will be recompiled based on the "new" > > package names for bdb. > > > > please test and provide feedback. > > > > > > That error usually means it can't find the version in the "testing catalog" > do a pkg-get -U -u bdb from the "current" catalog and you should get the right > version. Hi Mike, That didn't help: # pkg-get -U -u bdb Getting catalog... --2009-10-07 15:31:57-- http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/catalog Resolving ibiblio.org... 152.46.7.80 Connecting to ibiblio.org|152.46.7.80|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 407617 (398K) [text/plain] Saving to: `catalog' 100%[================================================================>] 407,617 125K/s in 3.2s 2009-10-07 15:32:01 (125 KB/s) - `catalog' saved [407617/407617] Stripping off catalog signature without verifying Updating catalog file /var/pkg-get/catalog-ibiblio.org updated --2009-10-07 15:32:01-- http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/descriptions Resolving ibiblio.org... 152.46.7.80 Connecting to ibiblio.org|152.46.7.80|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 112691 (110K) [text/plain] Saving to: `descriptions' 100%[================================================================>] 112,691 215K/s in 0.5s 2009-10-07 15:32:02 (215 KB/s) - `descriptions' saved [112691/112691] Updated description file ERROR: bdb unrecognized Perhaps you need to run pkg-get -U From dam at opencsw.org Wed Oct 7 17:44:03 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 7 Oct 2009 17:44:03 +0200 Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <20091007153325.GA23587@vm-1.bch.net> References: <4ACB995D.90707@opencsw.org> <20091007055448.GA13472@vm-1.bch.net> <4ACCA87E.6080903@opencsw.org> <20091007153325.GA23587@vm-1.bch.net> Message-ID: <1E7DFDC6-AAAA-46F0-9C47-DECC534F88D6@opencsw.org> Hi Brian, Am 07.10.2009 um 17:33 schrieb Brian Hill: > On Wed, Oct 07, 2009 at 09:41:02AM -0500, Mike Watters wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Brian Hill wrote: >>> Hi Mike, >>> >>> I assume that this should work with existing CSWberkeleydb >>> package until you rebuild it with the new berk db package name. >>> >>> Am I missing something? >>> >>> ... >>> Updated description file >>> INTERNAL ERROR: cannot get remote version for CSWbdb >>> Perhaps your catalog is out of date >>> Error: dependancies for sendmail not up to date. >>> You may call pkg-get again with '-v -u sendmail' to see which ones >>> Or, call pkg-get with 'upgrade' to bring all installed pkgs up to >>> date >>> >>> Brian >>> = >>> = >>> ==================================================================== >>> On Tue, Oct 06, 2009 at 02:24:13PM -0500, Mike Watters wrote: >>> once Dago is done with berkeley DB it will be recompiled based on >>> the "new" >>> package names for bdb. >>> >>> please test and provide feedback. >>> >>> >> >> That error usually means it can't find the version in the "testing >> catalog" >> do a pkg-get -U -u bdb from the "current" catalog and you should >> get the right >> version. > > Hi Mike, > > That didn't help: > > # pkg-get -U -u bdb > Getting catalog... > --2009-10-07 15:31:57-- http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/catalog > Resolving ibiblio.org... 152.46.7.80 > Connecting to ibiblio.org|152.46.7.80|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 407617 (398K) [text/plain] > Saving to: `catalog' > > 100% > [================================================================>] > 407,617 125K/s in 3.2s > > 2009-10-07 15:32:01 (125 KB/s) - `catalog' saved [407617/407617] > > Stripping off catalog signature without verifying > Updating catalog file > /var/pkg-get/catalog-ibiblio.org updated > > --2009-10-07 15:32:01-- http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/descriptions > Resolving ibiblio.org... 152.46.7.80 > Connecting to ibiblio.org|152.46.7.80|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 112691 (110K) [text/plain] > Saving to: `descriptions' > > 100% > [================================================================>] > 112,691 215K/s in 0.5s > > 2009-10-07 15:32:02 (215 KB/s) - `descriptions' saved [112691/112691] > > Updated description file > ERROR: bdb unrecognized Sure :) Because the catalogname is berkeleydb and the package name is CSWbdb: berkeleydb 4.7.25,REV=2009.07.01 CSWbdb berkeleydb-4.7.25,REV=2009.07.01-SunOS5.8-sparc-CSW.pkg.gz dc8ecc49f6b324c54f6042a2cac60109 6138945 CSWcommon none So either update berkeleydb or CSWbdb. Best regards -- Dago From bchill at opencsw.org Wed Oct 7 17:52:11 2009 From: bchill at opencsw.org (Brian Hill) Date: Wed, 7 Oct 2009 15:52:11 +0000 Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <1E7DFDC6-AAAA-46F0-9C47-DECC534F88D6@opencsw.org> References: <4ACB995D.90707@opencsw.org> <20091007055448.GA13472@vm-1.bch.net> <4ACCA87E.6080903@opencsw.org> <20091007153325.GA23587@vm-1.bch.net> <1E7DFDC6-AAAA-46F0-9C47-DECC534F88D6@opencsw.org> Message-ID: <20091007155211.GA24940@vm-1.bch.net> On Wed, Oct 07, 2009 at 05:44:03PM +0200, Dagobert Michelsen wrote: > Hi Brian, > > > Hi Mike, > > > > That didn't help: > > > ># pkg-get -U -u bdb > >Getting catalog... > >--2009-10-07 15:31:57-- > >http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/catalog > >Resolving ibiblio.org... 152.46.7.80 > >Connecting to ibiblio.org|152.46.7.80|:80... connected. > >HTTP request sent, awaiting response... 200 OK > >Length: 407617 (398K) [text/plain] > >Saving to: `catalog' > > > >100% > >[================================================================>] > >407,617 125K/s in 3.2s > > > >2009-10-07 15:32:01 (125 KB/s) - `catalog' saved [407617/407617] > > > >Stripping off catalog signature without verifying > >Updating catalog file > >/var/pkg-get/catalog-ibiblio.org updated > > > >--2009-10-07 15:32:01-- > >http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/descriptions > >Resolving ibiblio.org... 152.46.7.80 > >Connecting to ibiblio.org|152.46.7.80|:80... connected. > >HTTP request sent, awaiting response... 200 OK > >Length: 112691 (110K) [text/plain] > >Saving to: `descriptions' > > > >100% > >[================================================================>] > >112,691 215K/s in 0.5s > > > >2009-10-07 15:32:02 (215 KB/s) - `descriptions' saved [112691/112691] > > > >Updated description file > >ERROR: bdb unrecognized > > Sure :) Because the catalogname is berkeleydb and the package name is > CSWbdb: > > berkeleydb 4.7.25,REV=2009.07.01 CSWbdb > berkeleydb-4.7.25,REV=2009.07.01-SunOS5.8-sparc-CSW.pkg.gz > dc8ecc49f6b324c54f6042a2cac60109 6138945 CSWcommon none > > So either update berkeleydb or CSWbdb. > > > Best regards > > -- Dago Still, no luck: # pkg-get -U -u CSWbdb Getting catalog... --2009-10-07 15:49:11-- http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/catalog Resolving ibiblio.org... 152.46.7.80 Connecting to ibiblio.org|152.46.7.80|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 407617 (398K) [text/plain] Saving to: `catalog' 100%[================================================================>] 407,617 336K/s in 1.2s 2009-10-07 15:49:13 (336 KB/s) - `catalog' saved [407617/407617] Stripping off catalog signature without verifying Updating catalog file /var/pkg-get/catalog-ibiblio.org updated --2009-10-07 15:49:13-- http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/descriptions Resolving ibiblio.org... 152.46.7.80 Connecting to ibiblio.org|152.46.7.80|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 112691 (110K) [text/plain] Saving to: `descriptions' 100%[================================================================>] 112,691 214K/s in 0.5s 2009-10-07 15:49:13 (214 KB/s) - `descriptions' saved [112691/112691] Updated description file No worries... you already have version 4.7.25,REV=2009.07.01 of berkeleydb If you doubt this message, run 'pkg-get -U', then run 'pkg-get upgrade berkeleydb' # pkg-get -s http://mirror.opencsw.org/opencsw/testing -v -U upgrade sendmail DEBUG-ONLY/VERBOSE MODE: level=1 Getting catalog... --2009-10-07 15:49:33-- http://mirror.opencsw.org/opencsw/testing/sparc/5.8/catalog Resolving mirror.opencsw.org... 213.178.77.176 Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 37272 (36K) [text/plain] Saving to: `catalog' 100%[================================================================>] 37,272 49.7K/s in 0.7s 2009-10-07 15:49:34 (49.7 KB/s) - `catalog' saved [37272/37272] Updating catalog file /var/pkg-get/catalog-mirror.opencsw.org updated --2009-10-07 15:49:34-- http://mirror.opencsw.org/opencsw/testing/sparc/5.8/descriptions Resolving mirror.opencsw.org... 213.178.77.176 Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 9040 (8.8K) [text/plain] Saving to: `descriptions' 100%[================================================================>] 9,040 29.8K/s in 0.3s 2009-10-07 15:49:35 (29.8 KB/s) - `descriptions' saved [9040/9040] Updated description file INTERNAL ERROR: cannot get remote version for CSWbdb Perhaps your catalog is out of date Error: dependancies for sendmail not up to date. Relevant packages needing download: INTERNAL ERROR: cannot get remote version for CSWbdb Perhaps your catalog is out of date CSWoldaprt openldap_rt 643862 bytes INTERNAL ERROR: cannot get remote version for CSWosslrt Perhaps your catalog is out of date INTERNAL ERROR: cannot get remote version for CSWsasl Perhaps your catalog is out of date INTERNAL ERROR: cannot get remote version for CSWcswclassutils Perhaps your catalog is out of date INTERNAL ERROR: cannot get remote version for CSWcommon Perhaps your catalog is out of date INTERNAL ERROR: cannot get remote version for CSWisaexec Perhaps your catalog is out of date INTERNAL ERROR: cannot get remote version for CSWlibnet Perhaps your catalog is out of date INTERNAL ERROR: cannot get remote version for CSWkrb5lib Perhaps your catalog is out of date CSWsendmail sendmail 2796157 bytes Brian From dam at opencsw.org Wed Oct 7 17:57:11 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 7 Oct 2009 17:57:11 +0200 Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <20091007155211.GA24940@vm-1.bch.net> References: <4ACB995D.90707@opencsw.org> <20091007055448.GA13472@vm-1.bch.net> <4ACCA87E.6080903@opencsw.org> <20091007153325.GA23587@vm-1.bch.net> <1E7DFDC6-AAAA-46F0-9C47-DECC534F88D6@opencsw.org> <20091007155211.GA24940@vm-1.bch.net> Message-ID: <9A4426DC-8953-4C7A-B367-F477FCF2246C@opencsw.org> Hi Brian, Am 07.10.2009 um 17:52 schrieb Brian Hill: > Still, no luck: > > # pkg-get -U -u CSWbdb > Getting catalog... > --2009-10-07 15:49:11-- http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/catalog > Resolving ibiblio.org... 152.46.7.80 > Connecting to ibiblio.org|152.46.7.80|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 407617 (398K) [text/plain] > Saving to: `catalog' > > 100% > [================================================================>] > 407,617 336K/s in 1.2s > > 2009-10-07 15:49:13 (336 KB/s) - `catalog' saved [407617/407617] > > Stripping off catalog signature without verifying > Updating catalog file > /var/pkg-get/catalog-ibiblio.org updated > > --2009-10-07 15:49:13-- http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/descriptions > Resolving ibiblio.org... 152.46.7.80 > Connecting to ibiblio.org|152.46.7.80|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 112691 (110K) [text/plain] > Saving to: `descriptions' > > 100% > [================================================================>] > 112,691 214K/s in 0.5s > > 2009-10-07 15:49:13 (214 KB/s) - `descriptions' saved [112691/112691] > > Updated description file > No worries... you already have version 4.7.25,REV=2009.07.01 of > berkeleydb > If you doubt this message, run 'pkg-get -U', then run > 'pkg-get upgrade berkeleydb' This is good. > # pkg-get -s http://mirror.opencsw.org/opencsw/testing -v -U upgrade > sendmail > DEBUG-ONLY/VERBOSE MODE: level=1 > Getting catalog... > --2009-10-07 15:49:33-- http://mirror.opencsw.org/opencsw/testing/sparc/5.8/catalog > Resolving mirror.opencsw.org... 213.178.77.176 > Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 37272 (36K) [text/plain] > Saving to: `catalog' > > 100% > [================================================================>] > 37,272 49.7K/s in 0.7s > > 2009-10-07 15:49:34 (49.7 KB/s) - `catalog' saved [37272/37272] > > Updating catalog file > /var/pkg-get/catalog-mirror.opencsw.org updated > > --2009-10-07 15:49:34-- http://mirror.opencsw.org/opencsw/testing/sparc/5.8/descriptions > Resolving mirror.opencsw.org... 213.178.77.176 > Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 9040 (8.8K) [text/plain] > Saving to: `descriptions' > > 100% > [================================================================>] > 9,040 29.8K/s in 0.3s > > 2009-10-07 15:49:35 (29.8 KB/s) - `descriptions' saved [9040/9040] > > Updated description file > INTERNAL ERROR: cannot get remote version for CSWbdb > Perhaps your catalog is out of date > Error: dependancies for sendmail not up to date. > Relevant packages needing download: > INTERNAL ERROR: cannot get remote version for CSWbdb > Perhaps your catalog is out of date > CSWoldaprt openldap_rt 643862 bytes > INTERNAL ERROR: cannot get remote version for CSWosslrt > Perhaps your catalog is out of date > INTERNAL ERROR: cannot get remote version for CSWsasl > Perhaps your catalog is out of date > INTERNAL ERROR: cannot get remote version for CSWcswclassutils > Perhaps your catalog is out of date > INTERNAL ERROR: cannot get remote version for CSWcommon > Perhaps your catalog is out of date > INTERNAL ERROR: cannot get remote version for CSWisaexec > Perhaps your catalog is out of date > INTERNAL ERROR: cannot get remote version for CSWlibnet > Perhaps your catalog is out of date > INTERNAL ERROR: cannot get remote version for CSWkrb5lib > Perhaps your catalog is out of date > CSWsendmail sendmail 2796157 bytes This is bad. It looks like a bug in pkg-get when dependencies are already installed on the local system but not in the catalog (which should be ok). Phil, how is this handled in pkg-get? Best regards -- Dago From mwatters at opencsw.org Wed Oct 7 18:04:34 2009 From: mwatters at opencsw.org (Mike Watters) Date: Wed, 07 Oct 2009 11:04:34 -0500 Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <9A4426DC-8953-4C7A-B367-F477FCF2246C@opencsw.org> References: <4ACB995D.90707@opencsw.org> <20091007055448.GA13472@vm-1.bch.net> <4ACCA87E.6080903@opencsw.org> <20091007153325.GA23587@vm-1.bch.net> <1E7DFDC6-AAAA-46F0-9C47-DECC534F88D6@opencsw.org> <20091007155211.GA24940@vm-1.bch.net> <9A4426DC-8953-4C7A-B367-F477FCF2246C@opencsw.org> Message-ID: <4ACCBC12.6040505@opencsw.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dagobert Michelsen wrote: > Hi Brian, > > Am 07.10.2009 um 17:52 schrieb Brian Hill: >> Still, no luck: >> >> # pkg-get -U -u CSWbdb >> Getting catalog... >> --2009-10-07 15:49:11-- >> http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/catalog >> Resolving ibiblio.org... 152.46.7.80 >> Connecting to ibiblio.org|152.46.7.80|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 407617 (398K) [text/plain] >> Saving to: `catalog' >> >> 100%[================================================================>] >> 407,617 336K/s in 1.2s >> >> 2009-10-07 15:49:13 (336 KB/s) - `catalog' saved [407617/407617] >> >> Stripping off catalog signature without verifying >> Updating catalog file >> /var/pkg-get/catalog-ibiblio.org updated >> >> --2009-10-07 15:49:13-- >> http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/descriptions >> >> Resolving ibiblio.org... 152.46.7.80 >> Connecting to ibiblio.org|152.46.7.80|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 112691 (110K) [text/plain] >> Saving to: `descriptions' >> >> 100%[================================================================>] >> 112,691 214K/s in 0.5s >> >> 2009-10-07 15:49:13 (214 KB/s) - `descriptions' saved [112691/112691] >> >> Updated description file >> No worries... you already have version 4.7.25,REV=2009.07.01 of >> berkeleydb >> If you doubt this message, run 'pkg-get -U', then run >> 'pkg-get upgrade berkeleydb' > > This is good. > >> # pkg-get -s http://mirror.opencsw.org/opencsw/testing -v -U upgrade >> sendmail >> DEBUG-ONLY/VERBOSE MODE: level=1 >> Getting catalog... >> --2009-10-07 15:49:33-- >> http://mirror.opencsw.org/opencsw/testing/sparc/5.8/catalog >> Resolving mirror.opencsw.org... 213.178.77.176 >> Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 37272 (36K) [text/plain] >> Saving to: `catalog' >> >> 100%[================================================================>] >> 37,272 49.7K/s in 0.7s >> >> 2009-10-07 15:49:34 (49.7 KB/s) - `catalog' saved [37272/37272] >> >> Updating catalog file >> /var/pkg-get/catalog-mirror.opencsw.org updated >> >> --2009-10-07 15:49:34-- >> http://mirror.opencsw.org/opencsw/testing/sparc/5.8/descriptions >> Resolving mirror.opencsw.org... 213.178.77.176 >> Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 9040 (8.8K) [text/plain] >> Saving to: `descriptions' >> >> 100%[================================================================>] >> 9,040 29.8K/s in 0.3s >> >> 2009-10-07 15:49:35 (29.8 KB/s) - `descriptions' saved [9040/9040] >> >> Updated description file >> INTERNAL ERROR: cannot get remote version for CSWbdb >> Perhaps your catalog is out of date >> Error: dependancies for sendmail not up to date. >> Relevant packages needing download: >> INTERNAL ERROR: cannot get remote version for CSWbdb >> Perhaps your catalog is out of date >> CSWoldaprt openldap_rt 643862 bytes >> INTERNAL ERROR: cannot get remote version for CSWosslrt >> Perhaps your catalog is out of date >> INTERNAL ERROR: cannot get remote version for CSWsasl >> Perhaps your catalog is out of date >> INTERNAL ERROR: cannot get remote version for CSWcswclassutils >> Perhaps your catalog is out of date >> INTERNAL ERROR: cannot get remote version for CSWcommon >> Perhaps your catalog is out of date >> INTERNAL ERROR: cannot get remote version for CSWisaexec >> Perhaps your catalog is out of date >> INTERNAL ERROR: cannot get remote version for CSWlibnet >> Perhaps your catalog is out of date >> INTERNAL ERROR: cannot get remote version for CSWkrb5lib >> Perhaps your catalog is out of date >> CSWsendmail sendmail 2796157 bytes > > This is bad. It looks like a bug in pkg-get when dependencies are > already installed on the local system but not in the catalog (which > should be ok). Phil, how is this handled in pkg-get? > > > Best regards > > -- Dago > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers I think you need to update your version of openldap_rt - -- ~Mike "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." --> Albert Einstein 1879 - 1955 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrMvBEACgkQLrhmsXMSLxe8uACfbEYWDBJXRfhZMbRVBbPQ3yDg wYcAnA3YtXgS42/4XgxEI4ZGEF0uzAGl =W/g6 -----END PGP SIGNATURE----- From bwalton at opencsw.org Wed Oct 7 18:08:25 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 07 Oct 2009 12:08:25 -0400 Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <4ACCBC12.6040505@opencsw.org> References: <4ACB995D.90707@opencsw.org> <20091007055448.GA13472@vm-1.bch.net> <4ACCA87E.6080903@opencsw.org> <20091007153325.GA23587@vm-1.bch.net> <1E7DFDC6-AAAA-46F0-9C47-DECC534F88D6@opencsw.org> <20091007155211.GA24940@vm-1.bch.net> <9A4426DC-8953-4C7A-B367-F477FCF2246C@opencsw.org> <4ACCBC12.6040505@opencsw.org> Message-ID: <1254931603-sup-107@ntdws12.chass.utoronto.ca> Excerpts from Mike Watters's message of Wed Oct 07 12:04:34 -0400 2009: > I think you need to update your version of openldap_rt The openldap_rt package in testing only has 2.4 libs. Things linked to 2.3 will break. I'd recommend not updating to that package from testing at this point in time. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Oct 7 18:12:16 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 7 Oct 2009 18:12:16 +0200 (CEST) Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <4ACCBC12.6040505@opencsw.org> References: <4ACB995D.90707@opencsw.org> <20091007055448.GA13472@vm-1.bch.net> <4ACCA87E.6080903@opencsw.org> <20091007153325.GA23587@vm-1.bch.net> <1E7DFDC6-AAAA-46F0-9C47-DECC534F88D6@opencsw.org> <20091007155211.GA24940@vm-1.bch.net> <9A4426DC-8953-4C7A-B367-F477FCF2246C@opencsw.org> <4ACCBC12.6040505@opencsw.org> Message-ID: <58883.194.246.122.22.1254931936.squirrel@ssl.skayser.de> Mike Watters wrote: > Dagobert Michelsen wrote: >> Am 07.10.2009 um 17:52 schrieb Brian Hill: >>> # pkg-get -s http://mirror.opencsw.org/opencsw/testing -v -U upgrade >>> sendmail >>> DEBUG-ONLY/VERBOSE MODE: level=1 >>> Getting catalog... >>> --2009-10-07 15:49:33-- >>> http://mirror.opencsw.org/opencsw/testing/sparc/5.8/catalog >>> Resolving mirror.opencsw.org... 213.178.77.176 >>> Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. >>> HTTP request sent, awaiting response... 200 OK >>> Length: 37272 (36K) [text/plain] >>> Saving to: `catalog' >>> >>> 100%[================================================================>] >>> 37,272 49.7K/s in 0.7s >>> >>> 2009-10-07 15:49:34 (49.7 KB/s) - `catalog' saved [37272/37272] >>> >>> Updating catalog file >>> /var/pkg-get/catalog-mirror.opencsw.org updated >>> >>> --2009-10-07 15:49:34-- >>> http://mirror.opencsw.org/opencsw/testing/sparc/5.8/descriptions >>> Resolving mirror.opencsw.org... 213.178.77.176 >>> Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. >>> HTTP request sent, awaiting response... 200 OK >>> Length: 9040 (8.8K) [text/plain] >>> Saving to: `descriptions' >>> >>> 100%[================================================================>] >>> 9,040 29.8K/s in 0.3s >>> >>> 2009-10-07 15:49:35 (29.8 KB/s) - `descriptions' saved [9040/9040] >>> >>> Updated description file >>> INTERNAL ERROR: cannot get remote version for CSWbdb >>> Perhaps your catalog is out of date >>> Error: dependancies for sendmail not up to date. >>> Relevant packages needing download: >>> INTERNAL ERROR: cannot get remote version for CSWbdb >>> Perhaps your catalog is out of date >>> CSWoldaprt openldap_rt 643862 bytes >>> INTERNAL ERROR: cannot get remote version for CSWosslrt >>> Perhaps your catalog is out of date >>> INTERNAL ERROR: cannot get remote version for CSWsasl >>> Perhaps your catalog is out of date >>> INTERNAL ERROR: cannot get remote version for CSWcswclassutils >>> Perhaps your catalog is out of date >>> INTERNAL ERROR: cannot get remote version for CSWcommon >>> Perhaps your catalog is out of date >>> INTERNAL ERROR: cannot get remote version for CSWisaexec >>> Perhaps your catalog is out of date >>> INTERNAL ERROR: cannot get remote version for CSWlibnet >>> Perhaps your catalog is out of date >>> INTERNAL ERROR: cannot get remote version for CSWkrb5lib >>> Perhaps your catalog is out of date >>> CSWsendmail sendmail 2796157 bytes >> >> This is bad. It looks like a bug in pkg-get when dependencies are >> already installed on the local system but not in the catalog (which >> should be ok). Phil, how is this handled in pkg-get? > > I think you need to update your version of openldap_rt Thanks for testing, Brian. I second Dago's impression, we have had pkg-get cope badly with testing (or any partial catalog) several times in the past. Did you try pkgutil? pkgutil -t http://mirror.opencsw.org/opencsw/testing -u sendmail When using -t, pkgutil automatically creates an internal overlay to the catalog configured via pkgutil.conf and thus can resolve dependencies which are not covered by testing alone. pkg-get doesn't do so IIRC. Could we point that out on the testing page? Sebastian From phil at bolthole.com Wed Oct 7 18:14:47 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 7 Oct 2009 09:14:47 -0700 Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <9A4426DC-8953-4C7A-B367-F477FCF2246C@opencsw.org> References: <4ACB995D.90707@opencsw.org> <20091007055448.GA13472@vm-1.bch.net> <4ACCA87E.6080903@opencsw.org> <20091007153325.GA23587@vm-1.bch.net> <1E7DFDC6-AAAA-46F0-9C47-DECC534F88D6@opencsw.org> <20091007155211.GA24940@vm-1.bch.net> <9A4426DC-8953-4C7A-B367-F477FCF2246C@opencsw.org> Message-ID: On Wed, Oct 7, 2009 at 8:57 AM, Dagobert Michelsen wrote: > >> # pkg-get -U -u CSWbdb >... >> ?http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/catalog > >> No worries... you already have version 4.7.25,REV=2009.07.01 of berkeleydb >> If you doubt this message, run 'pkg-get -U', then run >> 'pkg-get upgrade berkeleydb' > > This is good. > >> # pkg-get -s [testing] -v -U upgrade sendmail >> >> INTERNAL ERROR: cannot get remote version for CSWbdb >> Perhaps your catalog is out of date > > This is bad. It looks like a bug in pkg-get when dependencies are > already installed on the local system but not in the catalog (which > should be ok). Well, I dunno about that being "should be ok" :-} that might be a "feature" ;-) [to guard against broken catalogs/packages] That being said, I already have longer term plans to implement better handling of this sort of thing, by directly supporting dual-site in pkg-get. Unfortunately that is MAJOR work for pkg-get, and I did not have time during my updates last weekend. it will have to wait until I have another free weekend, to implement it. (odd though.. i thought pkg-get used to be a bit more forgiving about this sort of thing from testing) From skayser at opencsw.org Wed Oct 7 18:21:04 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 7 Oct 2009 18:21:04 +0200 (CEST) Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <1254931603-sup-107@ntdws12.chass.utoronto.ca> References: <4ACB995D.90707@opencsw.org> <20091007055448.GA13472@vm-1.bch.net> <4ACCA87E.6080903@opencsw.org> <20091007153325.GA23587@vm-1.bch.net> <1E7DFDC6-AAAA-46F0-9C47-DECC534F88D6@opencsw.org> <20091007155211.GA24940@vm-1.bch.net> <9A4426DC-8953-4C7A-B367-F477FCF2246C@opencsw.org> <4ACCBC12.6040505@opencsw.org> <1254931603-sup-107@ntdws12.chass.utoronto.ca> Message-ID: <53910.194.246.122.22.1254932464.squirrel@ssl.skayser.de> Ben Walton wrote: > Excerpts from Mike Watters's message of Wed Oct 07 12:04:34 -0400 2009: > >> I think you need to update your version of openldap_rt > > The openldap_rt package in testing only has 2.4 libs. Things linked > to 2.3 will break. I'd recommend not updating to that package from > testing at this point in time. True, testing needs to be handled with care (time to get the in-development-stuff out of testing, glad that Dago is working towards it). To only update the sendmail package you could do pkgutil -t http://mirror.opencsw.org/opencsw/testing -Nu sendmail Requires pkgutil version 1.7. Sebastian From phil at bolthole.com Wed Oct 7 18:23:50 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 7 Oct 2009 09:23:50 -0700 Subject: [csw-maintainers] questions about GAR, history, and naming In-Reply-To: <493A50BB-64A2-457D-A307-185096960F35@opencsw.org> References: <20091004195314.GA33599@bolthole.com> <9046596F-57B6-4AA0-9B36-60C9F1497A56@opencsw.org> <0315E28D-99D7-42DB-A144-8A6B4E85A771@opencsw.org> <32973644-DFF4-4BD1-A760-90422E02A60A@opencsw.org> <493A50BB-64A2-457D-A307-185096960F35@opencsw.org> Message-ID: On Wed, Oct 7, 2009 at 4:39 AM, Dagobert Michelsen wrote: > . I may have put more energy to source packages if you would > show real interest in GAR by using it for your packages or at > least to a level where you can reproduce a build without the > demand that "someone writes up an interface for me that I can > do 'gartool compile '". Well, then, we have a "catch 22". You dont wish to work on GAR in that direction until I use it, and I dont want to use it until GAR is more complete in that area :-} For the record though, I have not insisted that there actually be an INTERFACE WRITTEN to do all that, before I use it. What I have been more pushy about, is for our [gar-related source repository] to be completely flattened, so that it is then POSSIBLE for "someone" to write a simple interface to support "[cswtool compile pkg]", for any arbitrary package in our svn repository. *I* would even be willing to write that tool! But right now, there is no proper standardized namespace in our svn to support that cleanly. Also for the record, we have discussed on the mailing list that things could potentially be added into the repository that build without using gar. Which is why I specified above, [cswtool], rather than [gartool]. Such a tool, (which, again, I myself would be willing to write), would support building via gar, or other standard-compliant subtrees in our source tree. From william at wbonnet.net Wed Oct 7 20:59:25 2009 From: william at wbonnet.net (William Bonnet) Date: Wed, 07 Oct 2009 20:59:25 +0200 Subject: [csw-maintainers] Proposal for name of our GAR version In-Reply-To: <1254921389-sup-6432@ntdws12.chass.utoronto.ca> References: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> <1254921389-sup-6432@ntdws12.chass.utoronto.ca> Message-ID: <4ACCE50D.40801@wbonnet.net> Hi A few puns are coming to my mind like Gar-Age or Gar-Land :) Garrigue is cool also ... or Garvey ? 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 Wed Oct 7 22:26:15 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 7 Oct 2009 22:26:15 +0200 Subject: [csw-maintainers] Updating farm now Message-ID: Hi, I am updating the farm now with XML stuff and everything else. Sorry for the inconvenience -- Dago From ihsan at opencsw.org Wed Oct 7 22:33:04 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 07 Oct 2009 22:33:04 +0200 Subject: [csw-maintainers] BerkeleyDB final call In-Reply-To: <52119.194.246.122.22.1254859774.squirrel@ssl.skayser.de> References: <52119.194.246.122.22.1254859774.squirrel@ssl.skayser.de> Message-ID: <4ACCFB00.1020008@opencsw.org> Am 6.10.2009 22:09 Uhr, Sebastian Kayser schrieb: > Thanks Dago for working towards the old status quo. Attached is a list of > packages directly depending on CSWbdb* packages. If someone spots a > package he is using regularly (best in a scenario with bdb involved), > please help testing by updating your BDB packages. > > CSWap2prefork > CSWap2worker > CSWapache > CSWapache2c > CSWapache2rt > CSWpmberkeleydb These are my packages and I'm already working on a update, especially for Apache. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From skayser at opencsw.org Wed Oct 7 22:51:34 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 07 Oct 2009 22:51:34 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <20091006.14033000.2372649415@gyor.oxdrove.co.uk> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> <20091006.14033000.2372649415@gyor.oxdrove.co.uk> Message-ID: <4ACCFF56.3010901@opencsw.org> James Lee wrote on 06.10.2009 16:03: > Reasons not to split: > > + Many more packages to manage > > + No space saving when only runtimes used, which is in most cases. > > + It's a pain for the developer to know to install the -dev packages. > Not all packages naturally have dev parts and it's not possible to > tell if it's missing or never exists (oh great, lets have empty > packages where none is needed to keep the system symmetric and avoid > all confusion). This reminds me of when i started using Debian. It was always the one -devel package that was missing. You get used to it somehow, just in our case one doesn't even know whether there is a a -devel package at all. Would going back to don't have devel splits at all be an option? Sebastian From phil at bolthole.com Wed Oct 7 23:28:34 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 7 Oct 2009 14:28:34 -0700 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <4ACCFF56.3010901@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> <20091006.14033000.2372649415@gyor.oxdrove.co.uk> <4ACCFF56.3010901@opencsw.org> Message-ID: On Wed, Oct 7, 2009 at 1:51 PM, Sebastian Kayser wrote: > > > This reminds me of when i started using Debian. It was always the one > -devel package that was missing. You get used to it somehow, just in our > case one doesn't even know whether there is a a -devel package at all. > > Would going back to don't have devel splits at all be an option? > well, it sort of would be, if you voted for "case by case basis". Why did you not vote for that option, if you feel this way? http://doodle.com/2e8eakee997gtmmv From phil at bolthole.com Wed Oct 7 23:31:46 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 7 Oct 2009 14:31:46 -0700 Subject: [csw-maintainers] Proposal for name of our GAR version In-Reply-To: <4ACCE50D.40801@wbonnet.net> References: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> <1254921389-sup-6432@ntdws12.chass.utoronto.ca> <4ACCE50D.40801@wbonnet.net> Message-ID: On Wed, Oct 7, 2009 at 11:59 AM, William Bonnet wrote: > Hi > > A few puns are coming to my mind like Gar-Age or Gar-Land :) > > Garrigue is cool also ... or Garvey ? > Maybe something that implies storage, or putting things together... Garrison? :-) surprisingly, it would seen to NOT be taken by anything, according to freshmeat.net From skayser at opencsw.org Wed Oct 7 23:45:49 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 07 Oct 2009 23:45:49 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> <20091006.14033000.2372649415@gyor.oxdrove.co.uk> <4ACCFF56.3010901@opencsw.org> Message-ID: <4ACD0C0D.5040008@opencsw.org> Philip Brown wrote on 07.10.2009 23:28: > On Wed, Oct 7, 2009 at 1:51 PM, Sebastian Kayser wrote: >> >> This reminds me of when i started using Debian. It was always the one >> -devel package that was missing. You get used to it somehow, just in our >> case one doesn't even know whether there is a a -devel package at all. >> >> Would going back to don't have devel splits at all be an option? >> > > well, it sort of would be, if you voted for "case by case basis". > Why did you not vote for that option, if you feel this way? > > http://doodle.com/2e8eakee997gtmmv Simply rethinking my opinion after the input in this thread. Was used to the -devel split from other platforms, we started introducing more -devel packages. Consistent user experience makes great sense to me, so why not go all the way. Thinking about the contrary, like James suggested ("I think that installing a product by name should install that product, a 1:1 correspondence between upstream product and top level package with the same name"), also makes sense to me. It is just as consistent as strict _devel splits. That's why i was asking: Would going back to don't have devel splits *at all* also be an option? Sebastian From phil at bolthole.com Wed Oct 7 23:58:38 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 7 Oct 2009 14:58:38 -0700 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <4ACD0C0D.5040008@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> <20091006.14033000.2372649415@gyor.oxdrove.co.uk> <4ACCFF56.3010901@opencsw.org> <4ACD0C0D.5040008@opencsw.org> Message-ID: On Wed, Oct 7, 2009 at 2:45 PM, Sebastian Kayser wrote: > .... > That's why i was asking: > Would going back to don't have devel splits *at all* also be an option? > That would result in certain packages quadrupling in size, I think. Mostly this is to do with the libfoo.a splitout. download size IS an issue for some set of our users. That is after all, why we split out _rt packages. I will say this, as something to ruminate on: Having 100% consistency, purely for consistency's sake alone, is not a good thing, in my opinion. It is not the greatest benefit to the greatest amount of users. Dago's arguments for always splitting, are "consistency, and security". I have just addressed the first here, and the second I think is fallacious. Come on now, how does it really lower security, to have header files on the system, for completely public software? !!! even if it did... it wouldnt do any good unless you have a COMPILER on the system. Dont want people to compile stuff on your system? Remove the compiler. Simple. Then it doesnt matter if there are header files, or any other development paraphernalia on the system. If a potential attacker can somehow install their own compiler.. they can sure install their own header files too!!! From dam at opencsw.org Thu Oct 8 09:45:46 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 8 Oct 2009 09:45:46 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> <20091006.14033000.2372649415@gyor.oxdrove.co.uk> <4ACCFF56.3010901@opencsw.org> <4ACD0C0D.5040008@opencsw.org> Message-ID: <16EB4321-3E1C-48CC-9D05-10D8F4C0DFCA@opencsw.org> Hi Phil, Am 07.10.2009 um 23:58 schrieb Philip Brown: > On Wed, Oct 7, 2009 at 2:45 PM, Sebastian Kayser > wrote: >> .... >> That's why i was asking: >> Would going back to don't have devel splits *at all* also be an >> option? > > That would result in certain packages quadrupling in size, I think. > Mostly this is to do with the libfoo.a splitout. > > download size IS an issue for some set of our users. That is after > all, why we split out _rt packages. > > I will say this, as something to ruminate on: > Having 100% consistency, purely for consistency's sake alone, is not a > good thing, in my opinion. > It is not the greatest benefit to the greatest amount of users. So, what does the user want? The users eithers wants headers or not. It would be fairly easy to add a flag "wants_devel = 1" to pkg-get.conf or pkgutil.conf which additionally tries to install _devel when is requested. There could also be a command to add _devel for every package installed. So, for the usability is doesn't matter if _devel is split of or not. It may even be better to split it off and automate it this way. PS: Same goes for _doc. Best regards -- Dago From james at opencsw.org Thu Oct 8 10:27:13 2009 From: james at opencsw.org (James Lee) Date: Thu, 08 Oct 2009 08:27:13 GMT Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <4ACCFF56.3010901@opencsw.org> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <39625CFE-FAD5-4A98-A011-F8EF917198B4@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> <20091006.14033000.2372649415@gyor.oxdrove.co.uk> <4ACCFF56.3010901@opencsw.org> Message-ID: <20091008.8271300.4238381744@gyor.oxdrove.co.uk> On 07/10/09, 21:51:34, Sebastian Kayser wrote regarding Re: [csw-maintainers] Handling of devel package splits: > > + It's a pain for the developer to know to install the -dev packages. > > Not all packages naturally have dev parts and it's not possible to > > tell if it's missing or never exists (oh great, lets have empty > > packages where none is needed to keep the system symmetric and avoid > > all confusion). > This reminds me of when i started using Debian. It was always the one > -devel package that was missing. You get used to it somehow, just in our > case one doesn't even know whether there is a a -devel package at all. I don't know Debian but am I right in thinking it's both an OS and user software distribution? In which case it's more like the user software that come with Solaris. Consider an OS supplied supplementary package: $ pkginfo | grep SUNWjpg GNOME2 SUNWjpg jpeg - The Independent JPEG Groups JPEG software GNOME2 SUNWjpg-devel jpeg - The Independent JPEG Groups JPEG software - development files GNOME2 SUNWjpg-devel-share jpeg - The Independent JPEG Groups JPEG software - development files - /usr/share It's split into 3 parts. First notice that although it is split I have all three parts so without looking at the packaging it's no different to having a single package. Reasons to install a full distribution at OS install: (1) It avoids decided what is needed and what is not. At first install I defy anyone to know what every package does. (2) Can patch the system and then use a patch version of something I later found I needed. If only some OS packages are installed and the system is patched and later more OS packages are add the additions are unpatched. Best to add them in the first place. (3) The hassle of adding later - it's not as easy as pkg-get. So I accept that a system has bits I don't need for reasons I don't need to know. There are cases when a bare system install is right but think how that is achieved. Not by naming each packages on the command line of pkg-get but by a single selection made at install time. If there was an install option such that when I install foo I get foo-dev or not than it would make managing the shadow development set easier. James. From james at opencsw.org Thu Oct 8 10:27:16 2009 From: james at opencsw.org (James Lee) Date: Thu, 08 Oct 2009 08:27:16 GMT Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> <20091006.14033000.2372649415@gyor.oxdrove.co.uk> <4ACCFF56.3010901@opencsw.org> <4ACD0C0D.5040008@opencsw.org> Message-ID: <20091008.8271600.282988649@gyor.oxdrove.co.uk> On 07/10/09, 22:58:38, Philip Brown wrote regarding Re: [csw-maintainers] Handling of devel package splits: > That would result in certain packages quadrupling in size, I think. > Mostly this is to do with the libfoo.a splitout. Why do we ship static libs at all? (Excepting a few obvious cases, gcc) James. From dam at opencsw.org Thu Oct 8 10:38:28 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 8 Oct 2009 10:38:28 +0200 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <20091008.8271600.282988649@gyor.oxdrove.co.uk> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> <20091006.14033000.2372649415@gyor.oxdrove.co.uk> <4ACCFF56.3010901@opencsw.org> <4ACD0C0D.5040008@opencsw.org> <20091008.8271600.282988649@gyor.oxdrove.co.uk> Message-ID: <6314D9FE-F00F-4162-9F53-C69728786223@opencsw.org> Hi James, Am 08.10.2009 um 10:27 schrieb James Lee: > On 07/10/09, 22:58:38, Philip Brown wrote > regarding Re: > [csw-maintainers] Handling of devel package splits: > >> That would result in certain packages quadrupling in size, I think. >> Mostly this is to do with the libfoo.a splitout. > > Why do we ship static libs at all? > (Excepting a few obvious cases, gcc) Because there are some cases where you need it. Perls DynaLoader.a for FFI comes to my mind which bit us lately. But you are right: Usually static libs should be avoided even in devel packages. GAR already excludes them by default for all packages. Best regards -- Dago From maciej at opencsw.org Thu Oct 8 16:16:22 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 8 Oct 2009 15:16:22 +0100 Subject: [csw-maintainers] Submitting a package to the release manager Message-ID: I'm writing a script to automate bits of the release process from the package maintainer side, and I'd like to learn more about how people do things currently, so I can write something that fits reasonably well with the current practices. When a maintainer decides to release a package, they need to remove the package from testing/ and copy it to newpkgs/ on bender. However, the maintainer needs to retain a copy of the package for future reference. I have a directory ~/to-release, in which I keep the packages I intend to send to the release maintainer. I also have ~/to-release/released where I keep copies of the packages that have been released. Do other people do it similarly? Where do you store the copies of packages being currently in the release process? Maciej From bwalton at opencsw.org Thu Oct 8 16:28:04 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 08 Oct 2009 10:28:04 -0400 Subject: [csw-maintainers] Submitting a package to the release manager In-Reply-To: References: Message-ID: <1255011826-sup-4723@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Thu Oct 08 10:16:22 -0400 2009: > been released. Do other people do it similarly? Where do you store the > copies of packages being currently in the release process? I bounce my packages through my own boxes here, as I haven't setup a shared key between the buildfarm and bender. I maintain a local ~/csw which houses packages that I've pushed over to bender. HTH. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Oct 8 16:41:54 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 8 Oct 2009 15:41:54 +0100 Subject: [csw-maintainers] Submitting a package to the release manager In-Reply-To: <1255011826-sup-4723@ntdws12.chass.utoronto.ca> References: <1255011826-sup-4723@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Oct 8, 2009 at 3:28 PM, Ben Walton wrote: > Excerpts from Maciej (Matchek) Blizinski's message of Thu Oct 08 10:16:22 -0400 2009: > >> been released. Do other people do it similarly? Where do you store the >> copies of packages being currently in the release process? > > I bounce my packages through my own boxes here, as I haven't setup a > shared key between the buildfarm and bender. ?I maintain a local ~/csw > which houses packages that I've pushed over to bender. I think I'll make the directory names configurable, with the defaults set to ~/csw/pending-release and ~/csw/released. I guess people will agree that the two directories are needed in the release process (from the maintainer perspective). Maciej From dam at opencsw.org Thu Oct 8 16:43:59 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 8 Oct 2009 16:43:59 +0200 Subject: [csw-maintainers] Submitting a package to the release manager In-Reply-To: References: Message-ID: Hi Maciej, Am 08.10.2009 um 16:16 schrieb Maciej (Matchek) Blizinski: > When a maintainer decides to release a package, they need to remove > the package from testing/ and copy it to newpkgs/ on bender. However, > the maintainer needs to retain a copy of the package for future > reference. I have a directory ~/to-release, in which I keep the > packages I intend to send to the release maintainer. I also have > ~/to-release/released where I keep copies of the packages that have > been released. Do other people do it similarly? Where do you store the > copies of packages being currently in the release process? I leave them in testing/. An automated tool could fingerprint the pkgs and remove it automatically from testing if there has been a package with the same fingerprint released. Best regards -- Dago From bonivart at opencsw.org Thu Oct 8 16:46:50 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 8 Oct 2009 16:46:50 +0200 Subject: [csw-maintainers] Submitting a package to the release manager In-Reply-To: References: Message-ID: <625385e30910080746o5d6aca4fv96bea1401427a934@mail.gmail.com> On Thu, Oct 8, 2009 at 4:43 PM, Dagobert Michelsen wrote: > I leave them in testing/. An automated tool could fingerprint the pkgs > and remove it automatically from testing if there has been a package with > the same fingerprint released. +1 It's nice to be able to easily get the packages during the package release cycle. -- /peter From bwalton at opencsw.org Thu Oct 8 16:52:22 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 08 Oct 2009 10:52:22 -0400 Subject: [csw-maintainers] Submitting a package to the release manager In-Reply-To: <625385e30910080746o5d6aca4fv96bea1401427a934@mail.gmail.com> References: <625385e30910080746o5d6aca4fv96bea1401427a934@mail.gmail.com> Message-ID: <1255013505-sup-9288@ntdws12.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Thu Oct 08 10:46:50 -0400 2009: > +1 I'll see your +1 and raise it another +1. I think this is the most convenient approach from the human interaction point of view. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Oct 8 17:06:35 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 8 Oct 2009 16:06:35 +0100 Subject: [csw-maintainers] Submitting a package to the release manager In-Reply-To: References: <1255011826-sup-4723@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Oct 8, 2009 at 3:41 PM, Maciej (Matchek) Blizinski wrote: > On Thu, Oct 8, 2009 at 3:28 PM, Ben Walton wrote: >> Excerpts from Maciej (Matchek) Blizinski's message of Thu Oct 08 10:16:22 -0400 2009: >> >>> been released. Do other people do it similarly? Where do you store the >>> copies of packages being currently in the release process? >> >> I bounce my packages through my own boxes here, as I haven't setup a >> shared key between the buildfarm and bender. ?I maintain a local ~/csw >> which houses packages that I've pushed over to bender. > > I think I'll make the directory names configurable, with the defaults > set to ~/csw/pending-release and ~/csw/released. I guess people will > agree that the two directories are needed in the release process (from > the maintainer perspective). I would like to discuss the configuration file. For the current needs, it's going to be the configuration file for the release process, but in principle it could be a maintainer-specific configuration file for other csw-related scripts. Python provides a configuration parser which deals with the .ini format, and I'm tempted to use it.. I like to use readily available components where I can. Another option would be to reuse ~/.garrc, but I don't know how to reliably extract information from this file. I don't want to write a lame Makefile parser in Python, and I can't write a decent one in my allocated time. Also, I don't want my tool to be GAR-dependent. So, a separate config file. What do people think is a good configuration file name? The first name which comes to my mind is ~/.csw.ini or ~/.opencsw.ini. (I somehow like ~/.opencsw.ini better, because it's less ambiguous.) The format would be something along the lines of: [release] statedir: /home/maciej/csw/state releasedpkgs: /home/maciej/csw/released releasemgr: ... at opencsw.org releasecc: ... at opencsw.org Thoughts? Maciej From maciej at opencsw.org Thu Oct 8 17:08:23 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 8 Oct 2009 16:08:23 +0100 Subject: [csw-maintainers] Submitting a package to the release manager In-Reply-To: <625385e30910080746o5d6aca4fv96bea1401427a934@mail.gmail.com> References: <625385e30910080746o5d6aca4fv96bea1401427a934@mail.gmail.com> Message-ID: On Thu, Oct 8, 2009 at 3:46 PM, Peter Bonivart wrote: > On Thu, Oct 8, 2009 at 4:43 PM, Dagobert Michelsen wrote: >> I leave them in testing/. An automated tool could fingerprint the pkgs >> and remove it automatically from testing if there has been a package with >> the same fingerprint released. > > +1 > > It's nice to be able to easily get the packages during the package > release cycle. I thought the same way, but there was a thread on this list (I couldn't find it in the archives) in which somebody said that the package file should be removed from testing when it's being send to the release manager. Intuitively, I would think that it's best if the files stays in testing/ until it's released, to avoid a gap in the file availability. Maciej From bwalton at opencsw.org Thu Oct 8 17:14:22 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 08 Oct 2009 11:14:22 -0400 Subject: [csw-maintainers] Submitting a package to the release manager In-Reply-To: References: <625385e30910080746o5d6aca4fv96bea1401427a934@mail.gmail.com> Message-ID: <1255014771-sup-2482@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Thu Oct 08 11:08:23 -0400 2009: > I thought the same way, but there was a thread on this list (I > couldn't find it in the archives) in which somebody said that the > package file should be removed from testing when it's being send to > the release manager. Intuitively, I would think that it's best if the > files stays in testing/ until it's released, to avoid a gap in the > file availability. The tool that pushes files to the mirrors and registers it in the DB should also reach in an rm the file iff the filename and md5sum match. That gets the best of both worlds. The release script is then simply a wrapper around an email (or other trigger) to the release system. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: not available URL: From maciej at opencsw.org Thu Oct 8 17:23:57 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 8 Oct 2009 16:23:57 +0100 Subject: [csw-maintainers] Submitting a package to the release manager In-Reply-To: <1255014771-sup-2482@ntdws12.chass.utoronto.ca> References: <625385e30910080746o5d6aca4fv96bea1401427a934@mail.gmail.com> <1255014771-sup-2482@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Oct 8, 2009 at 4:14 PM, Ben Walton wrote: > Excerpts from Maciej (Matchek) Blizinski's message of Thu Oct 08 11:08:23 -0400 2009: > >> I thought the same way, but there was a thread on this list (I >> couldn't find it in the archives) in which somebody said that the >> package file should be removed from testing when it's being send to >> the release manager. Intuitively, I would think that it's best if the >> files stays in testing/ until it's released, to avoid a gap in the >> file availability. > > The tool that pushes files to the mirrors and registers it in the DB > should also reach in an rm the file iff the filename and md5sum match. > That gets the best of both worlds. ?The release script is then simply > a wrapper around an email (or other trigger) to the release system. Yes, primarily it would be a wrapper around e-mail. I also thought about making it move files around a little. For instance, copy files from testing/ to newpkgs/ and store state, or log the activity for future reference. (When did I send this? What were the checksums? etc.) Maciej From bonivart at opencsw.org Thu Oct 8 17:33:01 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 8 Oct 2009 17:33:01 +0200 Subject: [csw-maintainers] Submitting a package to the release manager In-Reply-To: References: <1255011826-sup-4723@ntdws12.chass.utoronto.ca> Message-ID: <625385e30910080833y763d4e7ar4e6741436b30a68d@mail.gmail.com> On Thu, Oct 8, 2009 at 5:06 PM, Maciej (Matchek) Blizinski wrote: > What do people think is a good configuration file name? The first name > which comes to my mind is ~/.csw.ini or ~/.opencsw.ini. (I somehow > like ~/.opencsw.ini better, because it's less ambiguous.) I think those are too generic. I usually use the script name itself so .ini in your case. -- /peter From maciej at opencsw.org Thu Oct 8 18:07:38 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 8 Oct 2009 17:07:38 +0100 Subject: [csw-maintainers] UTF-8 on the buildfarm Message-ID: Is anyone able to edit files in UTF-8 on the buildfarm? Say, on the 'login' host. On my Solaris boxen, I only need to specify two environment variables: > set | grep UTF LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 Once they're set, I'm able to type the unicode characters in the shell and in vim. In Solaris 10, that is. For instance $ uname -a SunOS sunbox 5.10 Generic_138888-03 sun4u sparc SUNW,Sun-Fire-V215 $ echo ????????? ????????? On 'login' I can't type these characters at all. Any ideas? Maciej From phil at bolthole.com Thu Oct 8 18:10:05 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 8 Oct 2009 09:10:05 -0700 Subject: [csw-maintainers] Handling of devel package splits In-Reply-To: <20091008.8271300.4238381744@gyor.oxdrove.co.uk> References: <0265A4F8-714D-469A-8481-5B8DE2A357B5@opencsw.org> <5E10B46C-BFEE-422C-BD7F-CAE38ABCAAF9@opencsw.org> <20CF7060-3173-4BC4-873F-3E490AEE6BB2@opencsw.org> <20091005.8544800.2981934600@gyor.oxdrove.co.uk> <912E4546-D1E2-4DCA-B0B6-A6F14EE9AFD0@opencsw.org> <20091005.9544000.198172607@gyor.oxdrove.co.uk> <20091006.14033000.2372649415@gyor.oxdrove.co.uk> <4ACCFF56.3010901@opencsw.org> <20091008.8271300.4238381744@gyor.oxdrove.co.uk> Message-ID: On Thu, Oct 8, 2009 at 1:27 AM, James Lee wrote: > ... ?Consider an OS supplied supplementary package: > > $ pkginfo | grep SUNWjpg > GNOME2 ? ? ?SUNWjpg ? ? ? ? ? ? ? ? ? ? ? ? ?jpeg - The Independent JPEG > Groups JPEG software > GNOME2 ? ? ?SUNWjpg-devel ? ? ? ? ? ? ? ? ? ?jpeg - The Independent JPEG > Groups JPEG software - development files Consider also, that sun does NOT consistently do things this way. SOME things are split into SUNWfoo and SUNWfoo-devel OTHER things, have their "devel" bits lumped together with other things. For example, a recent "hot button" issue: xpm.h There is no separate xpmdevel for it. it is in SUNWxwinc. (mind you, thats because libxpm itself isnt in its own package, it's in SUNWxwplt But it's still something to think about; having more consolidation of certain development files, rather than the "one tarfile, one package" approach for everything. > There are cases when a bare system install is right but think how that > is achieved. ?Not by naming each packages on the command line of pkg-get > but by a single selection made at install time. ?If there was an install > option such that when I install foo I get foo-dev or not than it would > make managing the shadow development set easier. the interesting part comes when someone previously had a non-devel system, then decides they want to compile packge "A", and so needs to install the devel for it.. but does NOT want to download/install the devel stuff for "B", "C", "D", "E", ... From maciej at opencsw.org Thu Oct 8 18:12:28 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 8 Oct 2009 17:12:28 +0100 Subject: [csw-maintainers] UTF-8 on the buildfarm In-Reply-To: References: Message-ID: One more thing: Perl complains: ------------8<------------- maciej at login [login]:~ > pkgutil -h perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL = "en_US.UTF-8", LANG = "en_US.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). Pkgutil 1.5, install Solaris packages the easy way. Usage: pkgutil [option]... [package](-[version])... ------------8<------------- On my boxes, it doesn't complain at all. Maciej From trygvis at opencsw.org Thu Oct 8 18:22:29 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Thu, 08 Oct 2009 18:22:29 +0200 Subject: [csw-maintainers] Submitting a package to the release manager In-Reply-To: References: Message-ID: <4ACE11C5.5020902@opencsw.org> Maciej (Matchek) Blizinski wrote: > I'm writing a script to automate bits of the release process from the > package maintainer side, and I'd like to learn more about how people > do things currently, so I can write something that fits reasonably > well with the current practices. > > When a maintainer decides to release a package, they need to remove > the package from testing/ and copy it to newpkgs/ on bender. However, > the maintainer needs to retain a copy of the package for future > reference. I have a directory ~/to-release, in which I keep the > packages I intend to send to the release maintainer. I also have > ~/to-release/released where I keep copies of the packages that have > been released. Do other people do it similarly? Where do you store the > copies of packages being currently in the release process? Gar always put it in ~/gar/pkgs which I use to copy to testing/ and to newpkgs/ when I'm ready for a release. -- Trygve From bchill at opencsw.org Thu Oct 8 18:42:01 2009 From: bchill at opencsw.org (Brian Hill) Date: Thu, 8 Oct 2009 16:42:01 +0000 Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <58883.194.246.122.22.1254931936.squirrel@ssl.skayser.de> References: <4ACB995D.90707@opencsw.org> <20091007055448.GA13472@vm-1.bch.net> <4ACCA87E.6080903@opencsw.org> <20091007153325.GA23587@vm-1.bch.net> <1E7DFDC6-AAAA-46F0-9C47-DECC534F88D6@opencsw.org> <20091007155211.GA24940@vm-1.bch.net> <9A4426DC-8953-4C7A-B367-F477FCF2246C@opencsw.org> <4ACCBC12.6040505@opencsw.org> <58883.194.246.122.22.1254931936.squirrel@ssl.skayser.de> Message-ID: <20091008164201.GC8715@vm-1.bch.net> Thanks everyone! Peter Bonivart's and Sebastian Kayser's suggestion to use pkgutil worked to install the sendmail from testing. This worked: # pkgutil -t http://mirror.opencsw.org/opencsw/testing -iN sendmail Brian ====================================================================== On Wed, Oct 07, 2009 at 06:12:16PM +0200, Sebastian Kayser wrote: > Mike Watters wrote: > > Dagobert Michelsen wrote: > >> Am 07.10.2009 um 17:52 schrieb Brian Hill: > >>> # pkg-get -s http://mirror.opencsw.org/opencsw/testing -v -U upgrade > >>> sendmail > >>> DEBUG-ONLY/VERBOSE MODE: level=1 > >>> Getting catalog... > >>> --2009-10-07 15:49:33-- > >>> http://mirror.opencsw.org/opencsw/testing/sparc/5.8/catalog > >>> Resolving mirror.opencsw.org... 213.178.77.176 > >>> Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. > >>> HTTP request sent, awaiting response... 200 OK > >>> Length: 37272 (36K) [text/plain] > >>> Saving to: `catalog' > >>> > >>> 100%[================================================================>] > >>> 37,272 49.7K/s in 0.7s > >>> > >>> 2009-10-07 15:49:34 (49.7 KB/s) - `catalog' saved [37272/37272] > >>> > >>> Updating catalog file > >>> /var/pkg-get/catalog-mirror.opencsw.org updated > >>> > >>> --2009-10-07 15:49:34-- > >>> http://mirror.opencsw.org/opencsw/testing/sparc/5.8/descriptions > >>> Resolving mirror.opencsw.org... 213.178.77.176 > >>> Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. > >>> HTTP request sent, awaiting response... 200 OK > >>> Length: 9040 (8.8K) [text/plain] > >>> Saving to: `descriptions' > >>> > >>> 100%[================================================================>] > >>> 9,040 29.8K/s in 0.3s > >>> > >>> 2009-10-07 15:49:35 (29.8 KB/s) - `descriptions' saved [9040/9040] > >>> > >>> Updated description file > >>> INTERNAL ERROR: cannot get remote version for CSWbdb > >>> Perhaps your catalog is out of date > >>> Error: dependancies for sendmail not up to date. > >>> Relevant packages needing download: > >>> INTERNAL ERROR: cannot get remote version for CSWbdb > >>> Perhaps your catalog is out of date > >>> CSWoldaprt openldap_rt 643862 bytes > >>> INTERNAL ERROR: cannot get remote version for CSWosslrt > >>> Perhaps your catalog is out of date > >>> INTERNAL ERROR: cannot get remote version for CSWsasl > >>> Perhaps your catalog is out of date > >>> INTERNAL ERROR: cannot get remote version for CSWcswclassutils > >>> Perhaps your catalog is out of date > >>> INTERNAL ERROR: cannot get remote version for CSWcommon > >>> Perhaps your catalog is out of date > >>> INTERNAL ERROR: cannot get remote version for CSWisaexec > >>> Perhaps your catalog is out of date > >>> INTERNAL ERROR: cannot get remote version for CSWlibnet > >>> Perhaps your catalog is out of date > >>> INTERNAL ERROR: cannot get remote version for CSWkrb5lib > >>> Perhaps your catalog is out of date > >>> CSWsendmail sendmail 2796157 bytes > >> > >> This is bad. It looks like a bug in pkg-get when dependencies are > >> already installed on the local system but not in the catalog (which > >> should be ok). Phil, how is this handled in pkg-get? > > > > I think you need to update your version of openldap_rt > > Thanks for testing, Brian. I second Dago's impression, we have had pkg-get > cope badly with testing (or any partial catalog) several times in the > past. > > Did you try pkgutil? > > pkgutil -t http://mirror.opencsw.org/opencsw/testing -u sendmail > > When using -t, pkgutil automatically creates an internal overlay to the > catalog configured via pkgutil.conf and thus can resolve dependencies > which are not covered by testing alone. pkg-get doesn't do so IIRC. > > Could we point that out on the testing page? > > Sebastian > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers -- _____________________________________________________________________ / Brian C. Hill bchill at bch.net http://brian.bch.net \ | UNIX Specialist BCH Technical Services http://www.bch.net | From bchill at opencsw.org Thu Oct 8 18:52:27 2009 From: bchill at opencsw.org (Brian Hill) Date: Thu, 8 Oct 2009 16:52:27 +0000 Subject: [csw-maintainers] [csw-users] sendmail-8.14.3 in testing In-Reply-To: <4ACCBC12.6040505@opencsw.org> References: <4ACB995D.90707@opencsw.org> <20091007055448.GA13472@vm-1.bch.net> <4ACCA87E.6080903@opencsw.org> <20091007153325.GA23587@vm-1.bch.net> <1E7DFDC6-AAAA-46F0-9C47-DECC534F88D6@opencsw.org> <20091007155211.GA24940@vm-1.bch.net> <9A4426DC-8953-4C7A-B367-F477FCF2246C@opencsw.org> <4ACCBC12.6040505@opencsw.org> Message-ID: <20091008165227.GD8715@vm-1.bch.net> Hi Mike, sendmail-8.14.3 is running without an issue using /etc/mail/sendmai.cf (which I sort of prefer over /opt/csw/etc/mail or /etc/opt/csw/mail). I had to do a few changes myself (added to my cfengine shadow tree repo): * add some ifelf/sinclude handling to my sendmail.mc to find the /opt/csw/share/mail/cf files * symlink /usr/lib/sendmail -> /opt/csw/lib/sendmail * symlink /etc/mail/submit.cf -> /opt/csw/etc/mail/submit.cf * create a /var/spool/mail/clientmqueue (smmsp:smmsp) * add smmsp login/group to my supplementary passwd/group files (I think that's it) I guess the Sun conversion script included in the package would have taken care of these, but I wanted to add this all to my CFE repo anyway - better to understand the details intimately. Thanks! Brian ====================================================================== On Wed, Oct 07, 2009 at 11:04:34AM -0500, Mike Watters wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dagobert Michelsen wrote: > > Hi Brian, > > > > Am 07.10.2009 um 17:52 schrieb Brian Hill: > >> Still, no luck: > >> > >> # pkg-get -U -u CSWbdb > >> Getting catalog... > >> --2009-10-07 15:49:11-- > >> http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/catalog > >> Resolving ibiblio.org... 152.46.7.80 > >> Connecting to ibiblio.org|152.46.7.80|:80... connected. > >> HTTP request sent, awaiting response... 200 OK > >> Length: 407617 (398K) [text/plain] > >> Saving to: `catalog' > >> > >> 100%[================================================================>] > >> 407,617 336K/s in 1.2s > >> > >> 2009-10-07 15:49:13 (336 KB/s) - `catalog' saved [407617/407617] > >> > >> Stripping off catalog signature without verifying > >> Updating catalog file > >> /var/pkg-get/catalog-ibiblio.org updated > >> > >> --2009-10-07 15:49:13-- > >> http://ibiblio.org/pub/packages/solaris/opencsw/current/sparc/5.8/descriptions > >> > >> Resolving ibiblio.org... 152.46.7.80 > >> Connecting to ibiblio.org|152.46.7.80|:80... connected. > >> HTTP request sent, awaiting response... 200 OK > >> Length: 112691 (110K) [text/plain] > >> Saving to: `descriptions' > >> > >> 100%[================================================================>] > >> 112,691 214K/s in 0.5s > >> > >> 2009-10-07 15:49:13 (214 KB/s) - `descriptions' saved [112691/112691] > >> > >> Updated description file > >> No worries... you already have version 4.7.25,REV=2009.07.01 of > >> berkeleydb > >> If you doubt this message, run 'pkg-get -U', then run > >> 'pkg-get upgrade berkeleydb' > > > > This is good. > > > >> # pkg-get -s http://mirror.opencsw.org/opencsw/testing -v -U upgrade > >> sendmail > >> DEBUG-ONLY/VERBOSE MODE: level=1 > >> Getting catalog... > >> --2009-10-07 15:49:33-- > >> http://mirror.opencsw.org/opencsw/testing/sparc/5.8/catalog > >> Resolving mirror.opencsw.org... 213.178.77.176 > >> Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. > >> HTTP request sent, awaiting response... 200 OK > >> Length: 37272 (36K) [text/plain] > >> Saving to: `catalog' > >> > >> 100%[================================================================>] > >> 37,272 49.7K/s in 0.7s > >> > >> 2009-10-07 15:49:34 (49.7 KB/s) - `catalog' saved [37272/37272] > >> > >> Updating catalog file > >> /var/pkg-get/catalog-mirror.opencsw.org updated > >> > >> --2009-10-07 15:49:34-- > >> http://mirror.opencsw.org/opencsw/testing/sparc/5.8/descriptions > >> Resolving mirror.opencsw.org... 213.178.77.176 > >> Connecting to mirror.opencsw.org|213.178.77.176|:80... connected. > >> HTTP request sent, awaiting response... 200 OK > >> Length: 9040 (8.8K) [text/plain] > >> Saving to: `descriptions' > >> > >> 100%[================================================================>] > >> 9,040 29.8K/s in 0.3s > >> > >> 2009-10-07 15:49:35 (29.8 KB/s) - `descriptions' saved [9040/9040] > >> > >> Updated description file > >> INTERNAL ERROR: cannot get remote version for CSWbdb > >> Perhaps your catalog is out of date > >> Error: dependancies for sendmail not up to date. > >> Relevant packages needing download: > >> INTERNAL ERROR: cannot get remote version for CSWbdb > >> Perhaps your catalog is out of date > >> CSWoldaprt openldap_rt 643862 bytes > >> INTERNAL ERROR: cannot get remote version for CSWosslrt > >> Perhaps your catalog is out of date > >> INTERNAL ERROR: cannot get remote version for CSWsasl > >> Perhaps your catalog is out of date > >> INTERNAL ERROR: cannot get remote version for CSWcswclassutils > >> Perhaps your catalog is out of date > >> INTERNAL ERROR: cannot get remote version for CSWcommon > >> Perhaps your catalog is out of date > >> INTERNAL ERROR: cannot get remote version for CSWisaexec > >> Perhaps your catalog is out of date > >> INTERNAL ERROR: cannot get remote version for CSWlibnet > >> Perhaps your catalog is out of date > >> INTERNAL ERROR: cannot get remote version for CSWkrb5lib > >> Perhaps your catalog is out of date > >> CSWsendmail sendmail 2796157 bytes > > > > This is bad. It looks like a bug in pkg-get when dependencies are > > already installed on the local system but not in the catalog (which > > should be ok). Phil, how is this handled in pkg-get? > > > > > > Best regards > > > > -- Dago > > _______________________________________________ > > maintainers mailing list > > maintainers at lists.opencsw.org > > https://lists.opencsw.org/mailman/listinfo/maintainers > > I think you need to update your version of openldap_rt > > - -- > ~Mike > "Any intelligent fool can make things bigger, more complex, > and more violent. It takes a touch of genius -- and a lot of courage -- > to move in the opposite direction." --> Albert Einstein 1879 - 1955 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (SunOS) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkrMvBEACgkQLrhmsXMSLxe8uACfbEYWDBJXRfhZMbRVBbPQ3yDg > wYcAnA3YtXgS42/4XgxEI4ZGEF0uzAGl > =W/g6 > -----END PGP SIGNATURE----- -- _____________________________________________________________________ / Brian C. Hill bchill at bch.net http://brian.bch.net \ | UNIX Specialist BCH Technical Services http://www.bch.net | From skayser at opencsw.org Thu Oct 8 19:11:25 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Thu, 08 Oct 2009 19:11:25 +0200 Subject: [csw-maintainers] UTF-8 on the buildfarm In-Reply-To: References: Message-ID: <4ACE1D3D.3010602@opencsw.org> Hi Maciej, Maciej (Matchek) Blizinski wrote on 08.10.2009 18:12: > One more thing: Perl complains: > > ------------8<------------- > maciej at login [login]:~ > pkgutil -h > perl: warning: Setting locale failed. > perl: warning: Please check that your locale settings: > LC_ALL = "en_US.UTF-8", > LANG = "en_US.UTF-8" > are supported and installed on your system. > perl: warning: Falling back to the standard locale ("C"). > Pkgutil 1.5, install Solaris packages the easy way. > > Usage: pkgutil [option]... [package](-[version])... > ------------8<------------- > > On my boxes, it doesn't complain at all. that's a matter of the installed (available) locales. The requested UTF-8 locales are currently just not installed on the login box. $ locale -a C POSIX iso_8859_1 localeadm can be used on Solaris 10 to install the missing locales from the installation medium. As a side note: LC_ALL and LANG is IMHO more than you would need. Both are responsible for setting locale category settings (LC_*). LC_ALL overrides all LC_* categories, while LANG is a fallback for those that are undefined. An example: $ LC_CTYPE=en_US.UTF-8 locale LANG= LC_CTYPE=en_US.UTF-8 LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_ALL= The locale values enclosed in double quotes are the ones derived by LANG or LC_ALL (default C), those without double quotes are explicit ones. Another example, use a fallback via LANG, set LC_CTYPE explicitly. $ LANG=en_US LC_CTYPE=en_US.UTF-8 locale LANG=en_US LC_CTYPE=en_US.UTF-8 LC_NUMERIC="en_US" LC_TIME="en_US" LC_COLLATE="en_US" LC_MONETARY="en_US" LC_MESSAGES="en_US" LC_ALL= Now if we set LC_ALL, it has priority over LANG as well as over the explicit LC_CTYPE. $ LANG=en_US LC_CTYPE=en_US.UTF-8 LC_ALL=C locale LANG=en_US LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_ALL=C Makes sense? Sebastian From bwalton at opencsw.org Thu Oct 8 19:15:32 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 08 Oct 2009 13:15:32 -0400 Subject: [csw-maintainers] Submitting a package to the release manager In-Reply-To: <4ACE11C5.5020902@opencsw.org> References: <4ACE11C5.5020902@opencsw.org> Message-ID: <1255022101-sup-6594@ntdws12.chass.utoronto.ca> Excerpts from Trygve Laugst?l's message of Thu Oct 08 12:22:29 -0400 2009: > Gar always put it in ~/gar/pkgs which I use to copy to testing/ and to > newpkgs/ when I'm ready for a release. I have gar dump output package files into ~/staging (set in my .garrc). -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Oct 8 19:54:22 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 8 Oct 2009 19:54:22 +0200 Subject: [csw-maintainers] UTF-8 on the buildfarm In-Reply-To: <4ACE1D3D.3010602@opencsw.org> References: <4ACE1D3D.3010602@opencsw.org> Message-ID: <05534EA6-6BB0-453C-895F-435ACCEC172A@opencsw.org> Hi, Am 08.10.2009 um 19:11 schrieb Sebastian Kayser: > Hi Maciej, > > Maciej (Matchek) Blizinski wrote on 08.10.2009 18:12: >> One more thing: Perl complains: >> >> ------------8<------------- >> maciej at login [login]:~ > pkgutil -h >> perl: warning: Setting locale failed. >> perl: warning: Please check that your locale settings: >> LC_ALL = "en_US.UTF-8", >> LANG = "en_US.UTF-8" >> are supported and installed on your system. >> perl: warning: Falling back to the standard locale ("C"). >> Pkgutil 1.5, install Solaris packages the easy way. >> >> Usage: pkgutil [option]... [package](-[version])... >> ------------8<------------- >> >> On my boxes, it doesn't complain at all. > > that's a matter of the installed (available) locales. The requested > UTF-8 locales are currently just not installed on the login box. Maciej, do you need UTF8? Than I'll install it, but I tend to keep the installed languages not longer than necessary. Best regards -- Dago From Joerg.Schilling at fokus.fraunhofer.de Thu Oct 8 20:15:53 2009 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Thu, 08 Oct 2009 20:15:53 +0200 Subject: [csw-maintainers] UTF-8 on the buildfarm In-Reply-To: <05534EA6-6BB0-453C-895F-435ACCEC172A@opencsw.org> References: <4ACE1D3D.3010602@opencsw.org> <05534EA6-6BB0-453C-895F-435ACCEC172A@opencsw.org> Message-ID: <4ace2c59.0WiemAQFOzPNkwIP%Joerg.Schilling@fokus.fraunhofer.de> Dagobert Michelsen wrote: > > that's a matter of the installed (available) locales. The requested > > UTF-8 locales are currently just not installed on the login box. > > Maciej, do you need UTF8? Than I'll install it, but I tend to > keep the installed languages not longer than necessary. Don't forget: If you like to avoid make or autoconf failures, you need to set the locale to "C". J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From dam at opencsw.org Thu Oct 8 20:46:01 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 8 Oct 2009 20:46:01 +0200 Subject: [csw-maintainers] Archived catalogs Message-ID: <12235AB2-958C-46C1-82E9-A5B9C3FDB854@opencsw.org> Hi, has someone (Phil?) archived the old catalogs? Alternatively the newpkgs list would also be good. Ihsan, can you send me them as mbox? I would like to run some statistics and hack on generational catalogs and repo views. Best regards -- Dago From william at wbonnet.net Thu Oct 8 22:01:57 2009 From: william at wbonnet.net (William Bonnet) Date: Thu, 08 Oct 2009 22:01:57 +0200 Subject: [csw-maintainers] Archived catalogs In-Reply-To: <12235AB2-958C-46C1-82E9-A5B9C3FDB854@opencsw.org> References: <12235AB2-958C-46C1-82E9-A5B9C3FDB854@opencsw.org> Message-ID: <4ACE4535.3040103@wbonnet.net> Hi Dago > has someone (Phil?) archived the old catalogs? Alternatively the newpkgs > list would also be good. Ihsan, can you send me them as mbox? You'll find a few catalogs in the working folder of uwatch 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 Thu Oct 8 22:05:13 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 8 Oct 2009 22:05:13 +0200 Subject: [csw-maintainers] Archived catalogs In-Reply-To: <4ACE4535.3040103@wbonnet.net> References: <12235AB2-958C-46C1-82E9-A5B9C3FDB854@opencsw.org> <4ACE4535.3040103@wbonnet.net> Message-ID: Hi William, Am 08.10.2009 um 22:01 schrieb William Bonnet: >> has someone (Phil?) archived the old catalogs? Alternatively the >> newpkgs >> list would also be good. Ihsan, can you send me them as mbox? > You'll find a few catalogs in the working folder of uwatch Umh, not in /home/uwatch... And may you have a look at http://www.opencsw.org/package-gar-status.html again? Best regards -- Dago From maciej at opencsw.org Fri Oct 9 00:11:04 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 8 Oct 2009 23:11:04 +0100 Subject: [csw-maintainers] /var/opt/csw/run in the CSWcommon package Message-ID: Do people think it makes sense to include it? It looks like a shared directory. 5 packages use it already, and another 6 use /opt/csw/var/run, which is going to be ported. This makes 11 packages. Is it enough? Maciej From phil at bolthole.com Fri Oct 9 00:18:36 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 8 Oct 2009 15:18:36 -0700 Subject: [csw-maintainers] /var/opt/csw/run in the CSWcommon package In-Reply-To: References: Message-ID: On Thu, Oct 8, 2009 at 3:11 PM, Maciej (Matchek) Blizinski wrote: > Do people think it makes sense to include it? It looks like a shared > directory. 5 packages use it already, and another 6 use > /opt/csw/var/run, which is going to be ported. This makes 11 packages. > Is it enough? > errr.. there's also the issue of, should we actually be USING "/opt/csw/var/run"? it is rather different from the standard system version of /var/run, in that the system one is tmpfs, and nuked after every reboot. also.. why would we not use /var/run directly? we would just need to be careful about the naming of what goes in there. From bchill at opencsw.org Fri Oct 9 00:28:57 2009 From: bchill at opencsw.org (Brian Hill) Date: Thu, 8 Oct 2009 22:28:57 +0000 Subject: [csw-maintainers] /var/opt/csw/run in the CSWcommon package In-Reply-To: References: Message-ID: <20091008222857.GA3041@vm-1.bch.net> On Thu, Oct 08, 2009 at 03:18:36PM -0700, Philip Brown wrote: > On Thu, Oct 8, 2009 at 3:11 PM, Maciej (Matchek) Blizinski > wrote: > > Do people think it makes sense to include it? It looks like a shared > > directory. 5 packages use it already, and another 6 use > > /opt/csw/var/run, which is going to be ported. This makes 11 packages. > > Is it enough? > > > > errr.. there's also the issue of, should we actually be USING > "/opt/csw/var/run"? > > it is rather different from the standard system version of /var/run, > in that the system one is tmpfs, and nuked after every reboot. > > also.. why would we not use /var/run directly? we would just need to > be careful about the naming of what goes in there. I have to agree with Phillip. This ties into the discussion of /etc/opt/csw vs /opt/csw/etc somewhat. PID files should go in /var/run. Even if there are perceived namespace collisions, how often would you run, for example, Sun's bundled sendmail and CSW's sendmail at the same time? Brian From maciej at opencsw.org Fri Oct 9 00:54:00 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 8 Oct 2009 23:54:00 +0100 Subject: [csw-maintainers] /var/opt/csw/run in the CSWcommon package In-Reply-To: References: Message-ID: On Thu, Oct 8, 2009 at 11:18 PM, Philip Brown wrote: > it is rather different from the standard system version of /var/run, > in that the system one is tmpfs, and nuked after every reboot. > > also.. why would we not use /var/run directly? we would just need to > be careful about the naming of what goes in there. All right, I'm updating syslog-ng to use /var/run. Here's also a bit of a documentation update: diff --git a/htdocs/standards/layout.shtml b/htdocs/standards/layout.shtml index 7f8a1f1..7bfb709 100644 --- a/htdocs/standards/layout.shtml +++ b/htdocs/standards/layout.shtml @@ -156,8 +156,15 @@ on configuration of complex packages
var
-
Dont use this. Use /var/opt/csw instead. -

+
Don't use this. Use /var/opt/csw instead. +

+ There's an exception with relation to the pid + files. The /var/run directory is a tmpfs, + purged after each system restart. CSW packages should place + their pid files in /var/run rather + than /var/opt/csw/run, provided that there are + no file name clashes. +

X11
Maciej From phil at bolthole.com Fri Oct 9 02:57:58 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 8 Oct 2009 17:57:58 -0700 Subject: [csw-maintainers] /var/opt/csw/run in the CSWcommon package In-Reply-To: <20091008222857.GA3041@vm-1.bch.net> References: <20091008222857.GA3041@vm-1.bch.net> Message-ID: On Thu, Oct 8, 2009 at 3:28 PM, Brian Hill wrote: >> PID files should go in /var/run. > Even if there are perceived namespace collisions, how often would you run, > for example, Sun's bundled sendmail and CSW's sendmail at the same time? > not the point; you should be allowed to. just rename the pid file to cswsendmail.pid or whatever. Use whatever would be used in the SMF "short" definition for the demon. From phil at bolthole.com Fri Oct 9 03:00:28 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 8 Oct 2009 18:00:28 -0700 Subject: [csw-maintainers] /var/opt/csw/run in the CSWcommon package In-Reply-To: References: Message-ID: On Thu, Oct 8, 2009 at 3:54 PM, Maciej (Matchek) Blizinski wrote: > All right, I'm updating syslog-ng to use /var/run. Here's also a bit > of a documentation update: > > diff --git a/htdocs/standards/layout.shtml b/htdocs/standards/layout.shtml > ... I dont think that belongs in that section. However, I did now add a specific mention of /var/run higher up on the page. From maciej at opencsw.org Fri Oct 9 09:01:57 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 9 Oct 2009 08:01:57 +0100 Subject: [csw-maintainers] /var/opt/csw/run in the CSWcommon package In-Reply-To: References: Message-ID: On Fri, Oct 9, 2009 at 2:00 AM, Philip Brown wrote: > On Thu, Oct 8, 2009 at 3:54 PM, Maciej (Matchek) Blizinski > wrote: > >> All right, I'm updating syslog-ng to use /var/run. Here's also a bit >> of a documentation update: >> >> diff --git a/htdocs/standards/layout.shtml b/htdocs/standards/layout.shtml >> ... > > > I dont think that belongs in that section. > However, I did now add a specific mention of /var/run higher up on the page. How about this existing bit: var: Dont use this. Use /var/opt/csw instead. ...it seems to be in contradiction with "use /var/run" above. You could say "well, it's talking about /var, and not /var/run, it's not the same thing", to which I'm going to reply "do you mean it's okay if csw files are scattered across subdirectories, just because /var/whatever is not the same thing as /var?" I think the best way to put it is: "The rule of thumb is to do X. One of the known exceptions is case Y, in which you need to do Z, because of W." -- giving the rule and the exception in the same place/paragraph. Maciej From maciej at opencsw.org Fri Oct 9 10:44:29 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 9 Oct 2009 09:44:29 +0100 Subject: [csw-maintainers] Page "CSW class action utilities" edited at wiki.opencsw.org In-Reply-To: <7660c51054bd7dacc5b850f7caeddd8d@as2-1.s.wikidot.com> References: <7660c51054bd7dacc5b850f7caeddd8d@as2-1.s.wikidot.com> Message-ID: On Fri, Oct 9, 2009 at 9:12 AM, bonivart wrote: > bonivart edited the page "CSW class action utilities" at > http://wiki.opencsw.org/cswclassutils-package You updated cswclassutils to use the catalog names for files such as opt/csw/etc/pkg/foo/cswusergroup? From which version? Can we have some sort of a check so that package installs don't break? Or, is it backwards compatible? Maciej From bonivart at opencsw.org Fri Oct 9 10:54:56 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 9 Oct 2009 10:54:56 +0200 Subject: [csw-maintainers] Page "CSW class action utilities" edited at wiki.opencsw.org In-Reply-To: References: <7660c51054bd7dacc5b850f7caeddd8d@as2-1.s.wikidot.com> Message-ID: <625385e30910090154j49d457am6a5c72f91af79bd3@mail.gmail.com> On Fri, Oct 9, 2009 at 10:44 AM, Maciej (Matchek) Blizinski wrote: > On Fri, Oct 9, 2009 at 9:12 AM, bonivart wrote: >> bonivart edited the page "CSW class action utilities" at >> http://wiki.opencsw.org/cswclassutils-package > > You updated cswclassutils to use the catalog names for files such as > opt/csw/etc/pkg/foo/cswusergroup? From which version? Can we have some > sort of a check so that package installs don't break? Or, is it > backwards compatible? I only changed the /recommended/ path to use for cswusergroup configuration files. I didn't change any code in the class action script. What problems do you see? The change was to be more consistent with other use of the common name instead of the package name and that it's easily available in GAR with $(GARNAME). -- /peter From dam at opencsw.org Fri Oct 9 11:14:43 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 9 Oct 2009 11:14:43 +0200 Subject: [csw-maintainers] FYI: For your reference Message-ID: <4B161726-3FB8-459D-9BDC-E36ADF93BFEA@opencsw.org> Hi, I now mirror SpecFileExtra on the farm at /export/mirror/sfe It may give some insights when looking at the Specfiles or patches. They have other useful stuff too, like scripts/copyright-extractor which is under CDDL and may be useful for OpenCSW. And they have some interesting tweaks on CFLAGS in inlude/arch64.inc which look pretty good too. And that is the exact reason why OpenCSW must also have an open repository: For others to look and learn and not make hard patches a second time! Best regards -- Dago From dam at opencsw.org Fri Oct 9 14:05:22 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 9 Oct 2009 14:05:22 +0200 Subject: [csw-maintainers] GAR Major Change: Platform feature now activated Message-ID: <4F4D02E7-39FC-482F-AA2F-4DEB35592C14@opencsw.org> Hi, I just activated the new Platform build feature ("v2-pbuild") in GAR. It is available under the regular name gar/v2 in the repository, the old experimental branch gar/v2-build has been deleted. A simple svn update --ignore externals should be sufficient to update your tree. The new features have been documented at (see "Prototype Modifiers"). Let me know if you encounter anything unusual or feel the docs need some clarification :-) Best regards -- Dago From dam at opencsw.org Fri Oct 9 15:15:57 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 9 Oct 2009 15:15:57 +0200 Subject: [csw-maintainers] BDBs (hopefully) last update Message-ID: Hi, I got no negative feedback on BDB (apart from James who complained about db.jar in both 32/64 bit which I have removed now). If there are no complaints I will release tomorrow. If anyone forgot, here are the latest builds: Best regards -- Dago From dam at opencsw.org Fri Oct 9 15:18:36 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 9 Oct 2009 15:18:36 +0200 Subject: [csw-maintainers] Flex twice? Message-ID: <50B68BC5-E0AC-406D-9841-171BADAD936F@opencsw.org> Hi, I noticed that we have two versions of Flex: CSWflex flex CSWoflex oflex Both are 2.5.4 and from 2005 before my time. Maybe some of the old-timers remembers or is this just an artifact to be dropped? Best regards -- Dago From phil at bolthole.com Fri Oct 9 17:41:34 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 9 Oct 2009 08:41:34 -0700 Subject: [csw-maintainers] /var/opt/csw/run in the CSWcommon package In-Reply-To: References: Message-ID: On Fri, Oct 9, 2009 at 12:01 AM, Maciej (Matchek) Blizinski wrote: > On Fri, Oct 9, 2009 at 2:00 AM, Philip Brown wrote: >> On Thu, Oct 8, 2009 at 3:54 PM, Maciej (Matchek) Blizinski >> wrote: >> >>> All right, I'm updating syslog-ng to use /var/run. Here's also a bit >>> of a documentation update: >>> >>> diff --git a/htdocs/standards/layout.shtml b/htdocs/standards/layout.shtml >>> ... >> >> >> I dont think that belongs in that section. >> However, I did now add a specific mention of /var/run higher up on the page. > > How about this existing bit: > > var: Dont use this. Use /var/opt/csw instead. > > ...it seems to be in contradiction with "use /var/run" above. > > You could say "well, it's talking about /var, and not /var/run, No, it's in the subsection of "things under /opt/csw". /opt/csw/var is not /var that being said, I dont see why anyone would default to using /opt/csw/var/run. am I missing something? Things usually default to using /var/run. you have to go out of your way to force it to translate to /opt/csw/var/run ? From maciej at opencsw.org Fri Oct 9 18:28:25 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 9 Oct 2009 17:28:25 +0100 Subject: [csw-maintainers] /var/opt/csw/run in the CSWcommon package In-Reply-To: References: Message-ID: On Fri, Oct 9, 2009 at 4:41 PM, Philip Brown wrote: > On Fri, Oct 9, 2009 at 12:01 AM, Maciej (Matchek) Blizinski > wrote: >> On Fri, Oct 9, 2009 at 2:00 AM, Philip Brown wrote: >>> On Thu, Oct 8, 2009 at 3:54 PM, Maciej (Matchek) Blizinski >>> wrote: >>> >>>> All right, I'm updating syslog-ng to use /var/run. Here's also a bit >>>> of a documentation update: >>>> >>>> diff --git a/htdocs/standards/layout.shtml b/htdocs/standards/layout.shtml >>>> ... >>> >>> >>> I dont think that belongs in that section. >>> However, I did now add a specific mention of /var/run higher up on the page. >> >> How about this existing bit: >> >> var: Dont use this. Use /var/opt/csw instead. >> >> ...it seems to be in contradiction with "use /var/run" above. >> >> You could say "well, it's talking about /var, and not /var/run, > > No, it's in the subsection of "things under /opt/csw". > > /opt/csw/var is not /var I see. Perhaps it would make sense to write /opt/csw/var, when you mean /opt/csw/var. (I know it's written at the top. It's about how easy it is to read and understand.) > that being said, I dont see why anyone would default to using > /opt/csw/var/run. am I missing something? Because of the "everything is under /opt/csw" rule. > Things usually default to using /var/run. you have to go out of your > way to force it to translate to /opt/csw/var/run ? syslog-ng defaults to /var/run, but I usually don't allow packages to install anything outside /opt/csw, so I wouldn't let it use the default without a reason. Maciej From phil at bolthole.com Fri Oct 9 19:24:16 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 9 Oct 2009 10:24:16 -0700 Subject: [csw-maintainers] /var/opt/csw/run in the CSWcommon package In-Reply-To: References: Message-ID: FYI: I updated the first few pargraphs of http://www.opencsw.org/standards/layout so hopefully it is even clearer now. From phil at bolthole.com Fri Oct 9 19:26:16 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 9 Oct 2009 10:26:16 -0700 Subject: [csw-maintainers] Flex twice? In-Reply-To: <50B68BC5-E0AC-406D-9841-171BADAD936F@opencsw.org> References: <50B68BC5-E0AC-406D-9841-171BADAD936F@opencsw.org> Message-ID: On Fri, Oct 9, 2009 at 6:18 AM, Dagobert Michelsen wrote: > Hi, > > I noticed that we have two versions of Flex: > ?CSWflex ? flex > ?CSWoflex ?oflex > Both are 2.5.4 and from 2005 before my time. Maybe some of the > old-timers remembers or is this just an artifact to be dropped? huh. wierd. I thought there were two actual separate versions. But they both list the same source url. so i guess not. From james at opencsw.org Sun Oct 11 10:57:47 2009 From: james at opencsw.org (James Lee) Date: Sun, 11 Oct 2009 08:57:47 GMT Subject: [csw-maintainers] Flex twice? In-Reply-To: <50B68BC5-E0AC-406D-9841-171BADAD936F@opencsw.org> References: <50B68BC5-E0AC-406D-9841-171BADAD936F@opencsw.org> Message-ID: <20091011.8574700.2930021673@gyor.oxdrove.co.uk> On 09/10/09, 14:18:36, Dagobert Michelsen wrote regarding [csw-maintainers] Flex twice?: > I noticed that we have two versions of Flex: > CSWflex flex > CSWoflex oflex There are three. Dagobert, see if you can notify the maintainer of CSWflex-new by kicking him in the nuts. > Both are 2.5.4 and from 2005 before my time. Maybe some of the > old-timers remembers or is this just an artifact to be dropped? oflex, flex and flex_new were supposed to be because of compatibility versioning. Why I don't know, there was talk on the maintainers' list and the history of release can be see in oldpkgs. I wish for only one version that works. James. From dam at opencsw.org Sun Oct 11 11:10:06 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 11 Oct 2009 11:10:06 +0200 Subject: [csw-maintainers] Flex twice? In-Reply-To: <20091011.8574700.2930021673@gyor.oxdrove.co.uk> References: <50B68BC5-E0AC-406D-9841-171BADAD936F@opencsw.org> <20091011.8574700.2930021673@gyor.oxdrove.co.uk> Message-ID: <31EC969D-8780-4784-9B11-CB1599515370@opencsw.org> Hi James, Am 11.10.2009 um 10:57 schrieb James Lee: > On 09/10/09, 14:18:36, Dagobert Michelsen wrote > regarding > [csw-maintainers] Flex twice?: > >> I noticed that we have two versions of Flex: >> CSWflex flex >> CSWoflex oflex > > There are three. Dagobert, see if you can notify the maintainer of > CSWflex-new by kicking him in the nuts. Done. *OUCH* >> Both are 2.5.4 and from 2005 before my time. Maybe some of the >> old-timers remembers or is this just an artifact to be dropped? > > oflex, flex and flex_new were supposed to be because of compatibility > versioning. Why I don't know, there was talk on the maintainers' list > and the history of release can be see in oldpkgs. I wish for only one > version that works. I can understand why there is flex and flex_new, but I can not understand why there are two identical versions flex and oflex. The old maintainers list is closed now that the new list became public. Ihsan, could you please send me the old mails in some format I can import? I don't want to make the same errors twice, usually... Best regards -- Dago From james at opencsw.org Sun Oct 11 11:21:23 2009 From: james at opencsw.org (James Lee) Date: Sun, 11 Oct 2009 09:21:23 GMT Subject: [csw-maintainers] Flex twice? In-Reply-To: <31EC969D-8780-4784-9B11-CB1599515370@opencsw.org> References: <50B68BC5-E0AC-406D-9841-171BADAD936F@opencsw.org> <20091011.8574700.2930021673@gyor.oxdrove.co.uk> <31EC969D-8780-4784-9B11-CB1599515370@opencsw.org> Message-ID: <20091011.9212300.1497987078@gyor.oxdrove.co.uk> On 11/10/09, 10:10:06, Dagobert Michelsen wrote regarding Re: [csw-maintainers] Flex twice?: > >> I noticed that we have two versions of Flex: > >> CSWflex flex > >> CSWoflex oflex > > > > There are three. Dagobert, see if you can notify the maintainer of > > CSWflex-new by kicking him in the nuts. > Done. *OUCH* Impressive, you are truly a flex expert. James. From dam at opencsw.org Sun Oct 11 11:50:19 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 11 Oct 2009 11:50:19 +0200 Subject: [csw-maintainers] Flex twice? In-Reply-To: References: <50B68BC5-E0AC-406D-9841-171BADAD936F@opencsw.org> Message-ID: <3A48863F-0D0D-4D29-B6AD-B2361BE569F6@opencsw.org> Hi Phil, Am 09.10.2009 um 19:26 schrieb Philip Brown: > On Fri, Oct 9, 2009 at 6:18 AM, Dagobert Michelsen > wrote: >> I noticed that we have two versions of Flex: >> CSWflex flex >> CSWoflex oflex >> Both are 2.5.4 and from 2005 before my time. Maybe some of the >> old-timers remembers or is this just an artifact to be dropped? > > huh. wierd. I thought there were two actual separate versions. > But they both list the same source url. so i guess not. Ok then, please remove the package CSWoflex from the catalog and the mirrors. Best regards -- Dago From ihsan at opencsw.org Sun Oct 11 13:22:42 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 11 Oct 2009 13:22:42 +0200 Subject: [csw-maintainers] GAR Major Change: Platform feature now activated In-Reply-To: <4F4D02E7-39FC-482F-AA2F-4DEB35592C14@opencsw.org> References: <4F4D02E7-39FC-482F-AA2F-4DEB35592C14@opencsw.org> Message-ID: <4AD1C002.1050409@opencsw.org> Am 9.10.2009 14:05 Uhr, Dagobert Michelsen schrieb: > Let me know if you encounter anything unusual or feel the docs > need some clarification :-) I have two packages, ldns and unbound, which are build with gcc on Solaris 8, while the Solaris 10 version is built with Studio 12. Does this change has any influence to this very specific case? Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Sun Oct 11 14:00:02 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 11 Oct 2009 14:00:02 +0200 Subject: [csw-maintainers] GAR Major Change: Platform feature now activated In-Reply-To: <4AD1C002.1050409@opencsw.org> References: <4F4D02E7-39FC-482F-AA2F-4DEB35592C14@opencsw.org> <4AD1C002.1050409@opencsw.org> Message-ID: <7D96D3D3-FA0A-40E1-9549-9114E56174DC@opencsw.org> Hi Ihsan, Am 11.10.2009 um 13:22 schrieb Ihsan Dogan: > Am 9.10.2009 14:05 Uhr, Dagobert Michelsen schrieb: > >> Let me know if you encounter anything unusual or feel the docs >> need some clarification :-) > > I have two packages, ldns and unbound, which are build with gcc on > Solaris 8, while the Solaris 10 version is built with Studio 12. > > Does this change has any influence to this very specific case? Yes! Please add PACKAGING_PLATFORMS = solaris8-sparc solaris8-i386 solaris10-sparc solaris10-i386 to you Makefile. This tells GAR about all platforms you want packages built on. It may needs additional tweaking. Have you committed all your local changes? Than I'd love to take a look and allow gmake platforms to automatically build packages for all 4 platforms without intervention. Best regards -- Dago From william at wbonnet.net Sun Oct 11 18:11:32 2009 From: william at wbonnet.net (William Bonnet) Date: Sun, 11 Oct 2009 18:11:32 +0200 Subject: [csw-maintainers] Looking for old catalogs Message-ID: <4AD203B4.3090700@wbonnet.net> Hi, I have replaced the previous solution (sending email to the list with some stats) by a mysql database, and a web page displaying graphics. But i need some data to populate it. So I am looking for olds packages catalog in order to populate a statistic database. Does any of you have some ? i would need a few per month starting december 2008 (or older if i cannot found some from december). I would like to prefer to get the full catalog, bu just a list of available packages would be ok (i already all the lists starting from march, so no need to resend it). Thanks in advance cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From bonivart at opencsw.org Sun Oct 11 20:40:29 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 11 Oct 2009 20:40:29 +0200 Subject: [csw-maintainers] cswclassutils/initsmf defaults Message-ID: <625385e30910111140m4d564cb0qb1aab34bb351dbf3@mail.gmail.com> I'm glad many of you use the cswclassutils package but I notice that you often specify the defaults in the init script you provide. These are the defaults and they do not need to be specified: #RC_KNUM 20 # Number used for kill script symlink, e.g. K20cswfoo #RC_SNUM 80 # Number used for start script symlink, e.g. S80cswfoo #RC_KLEV 0,1,2,S # Run levels that should have a kill script symlink #RC_SLEV 3 # Run levels that should have a start script symlink #FMRI network # FMRI path for service (S10+), default is /network. # # Changing the value here, yields a generated FMRI of # # "svc:/somethingelse/cswfoo:default" #AUTOENABLE yes # If set to no will not enable service regardless of # local csw.conf, use when a package needs setup before # being useful, would otherwise leave service in # maintenance mode #MANIFEST /absolute/path/to/manifest # If set, use this manifest instead # of autogenerating one (default) You only need to specify those options where you want something different than the default. It's of course (technically) OK to specify the defaults anyway if you think it makes it more clear. Wiki: http://wiki.opencsw.org/cswclassutils-package -- /peter From maciej at opencsw.org Mon Oct 12 15:10:18 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 12 Oct 2009 14:10:18 +0100 Subject: [csw-maintainers] GAR: building a package from loose files, with checksumming Message-ID: I was trying to create a GAR build which would be done from loose files, with checksumming. Image this existing directory structure: $ tree . `-- opt `-- csw |-- bin | `-- foo `-- share `-- foo |-- README `-- examples `-- doing-it-right.conf (In other words: loose files which are already in the corresponding directories.) Suppose I'd like to create a GAR package from such files. I'd like to calculate a checksum of each single file. I was thinking about doing something like this, although it only allows to create a single checksum for all the files: - create a fake download file in DESTDIR - override its download target: $(DOWNLOADDIR)/fakefile: ...copy the tree structure... ...touch $(DOWNLOADDIR)/fakefile to make GAR happy; optionally put the checksums of all the copied files in there. - in the extract step, copy the tree structure from $(DOWNLOADDIR) to $(WORKSRC). - skip the build step - in the install step, copy files once again from $(WORKSRC) to $(DESTDIR) That's my take, and it hardly works. Dago, how would you go about it? Maciej From phil at bolthole.com Mon Oct 12 17:17:20 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 12 Oct 2009 08:17:20 -0700 Subject: [csw-maintainers] Flex twice? In-Reply-To: <3A48863F-0D0D-4D29-B6AD-B2361BE569F6@opencsw.org> References: <50B68BC5-E0AC-406D-9841-171BADAD936F@opencsw.org> <3A48863F-0D0D-4D29-B6AD-B2361BE569F6@opencsw.org> Message-ID: On Sun, Oct 11, 2009 at 2:50 AM, Dagobert Michelsen wrote: > > > Ok then, please remove the package CSWoflex from the catalog and the > mirrors. > change batched. From dam at opencsw.org Mon Oct 12 17:21:40 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 12 Oct 2009 17:21:40 +0200 Subject: [csw-maintainers] Flex twice? In-Reply-To: References: <50B68BC5-E0AC-406D-9841-171BADAD936F@opencsw.org> <3A48863F-0D0D-4D29-B6AD-B2361BE569F6@opencsw.org> Message-ID: <0058D8D8-059C-4CD6-983B-471F200374DD@opencsw.org> Hi Phil, Am 12.10.2009 um 17:17 schrieb Philip Brown: > On Sun, Oct 11, 2009 at 2:50 AM, Dagobert Michelsen > wrote: >> Ok then, please remove the package CSWoflex from the catalog and the >> mirrors. > > change batched. I hope you also merged in the bugs from oflex, yes? Best regards -- Dago From phil at bolthole.com Mon Oct 12 17:23:07 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 12 Oct 2009 08:23:07 -0700 Subject: [csw-maintainers] GAR: building a package from loose files, with checksumming In-Reply-To: References: Message-ID: On Mon, Oct 12, 2009 at 6:10 AM, Maciej (Matchek) Blizinski wrote: > I was trying to create a GAR build which would be done from loose > files, with checksumming. > [....] > > Suppose I'd like to create a GAR package from such files. I'd like to > calculate a checksum of each single file. eeeesh.. why would you want to do this with the gar "build" framework? The easiest way to do this otherwise, (if you already know the locations), is to pre-generate a prototype file, and then use createpkg. Or even if you want to do it "dynamically"... (echo "i pkginfo" ; [output file list] | pkgproto) >prototype createpkg -r / (or if appropriate, createpkg -b /opt/csw for relocatable pkg) Apologies if I dont get the syntax EXACTLY right; the above is typed from memory without testing. but it shoudl be pretty much what is needed. From phil at bolthole.com Mon Oct 12 17:27:07 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 12 Oct 2009 08:27:07 -0700 Subject: [csw-maintainers] Flex twice? In-Reply-To: <0058D8D8-059C-4CD6-983B-471F200374DD@opencsw.org> References: <50B68BC5-E0AC-406D-9841-171BADAD936F@opencsw.org> <3A48863F-0D0D-4D29-B6AD-B2361BE569F6@opencsw.org> <0058D8D8-059C-4CD6-983B-471F200374DD@opencsw.org> Message-ID: On Mon, Oct 12, 2009 at 8:21 AM, Dagobert Michelsen wrote: > > I hope you also merged in the bugs from oflex, yes? > > Bah. no i just made it hidden. didnt check for bugs. but.. there doesnt seem to be any. From dam at opencsw.org Mon Oct 12 20:10:20 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 12 Oct 2009 20:10:20 +0200 Subject: [csw-maintainers] GAR: building a package from loose files, with checksumming In-Reply-To: References: Message-ID: <141D5D6D-9C60-4F95-BC9D-A593E81E6F77@opencsw.org> Hi Maciej, Am 12.10.2009 um 15:10 schrieb Maciej (Matchek) Blizinski: > I was trying to create a GAR build which would be done from loose > files, with checksumming. Image this existing directory structure: > > $ tree > . > `-- opt > `-- csw > |-- bin > | `-- foo > `-- share > `-- foo > |-- README > `-- examples > `-- doing-it-right.conf > > (In other words: loose files which are already in the corresponding > directories.) Ok, for now I'll stick to /usr/bin/ls and /usr/share/man/man1/ls.1, ok? > Suppose I'd like to create a GAR package from such files. I'd like to > calculate a checksum of each single file. > > I was thinking about doing something like this, although it only > allows to create a single checksum for all the files: > > - create a fake download file in DESTDIR > - override its download target: > $(DOWNLOADDIR)/fakefile: > ...copy the tree structure... > ...touch $(DOWNLOADDIR)/fakefile to make GAR happy; optionally put > the checksums of all the copied files in there. These steps are very valid and useful. I use it in automake to put the list of versions in the README: > $(DOWNLOADDIR)/README.CSW: > @echo " ==> Generating README.CSW" > @(exec > > $@; \ > echo "This package contains the following automake > versions:"; \ > for VERSION in $(MODULATIONS_GARVERSION); > do \ > echo " automake-$ > $VERSION"; \ > done) However, as the files are already there you can use a more elegant method wel'll see below. > - in the extract step, copy the tree structure from $(DOWNLOADDIR) to > $(WORKSRC). > - skip the build step > - in the install step, copy files once again from $(WORKSRC) to $ > (DESTDIR) > > That's my take, and it hardly works. Dago, how would you go about it? Here's my small example: > GARNAME = example > GARVERSION = 1.0 > CATEGORIES = apps > > DESCRIPTION = An example > > FILES = /usr/bin/ls /usr/share/man/man1/ls.1 This is the list of files you want. > MASTER_SITES = $(sort $(addprefix file://,$(dir $(FILES)))) Every data source from MASTER_SITES is searched for the files in DISTFILES. It is in URL syntax, the sort is only to make the dirs unique if you have multiple files from one dir (essentially not needed here). > DISTFILES = $(notdir $(FILES)) There files get downloaded. Only the files as the data sources are multiplexed as above. It would be nice to specify a location per file, but historically it is not in there. AFAIK Ben requested that for his zillion XML-sources-sites. > CONFIGURE_SCRIPTS = > BUILD_SCRIPTS = > INSTALL_SCRIPTS = custom > TEST_SCRIPTS = > > include gar/category.mk > > install-custom: > $(foreach F,$(FILES),ginstall -d $(DESTDIR)$(dir $F) && > ginstall $(WORKDIR)/$(notdir $F) $(DESTDIR)$(dir $F);) > @$(MAKECOOKIE) The install is pretty straight. Please note that install should *always* copy from WORKDIR (or WORKSRC) to DESTDIR because that is the flow of the data, instead of taking from DOWNLOADDIR and installing to PKGROOT or something! Best regards -- Dago From trygvis at opencsw.org Tue Oct 13 13:02:53 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Tue, 13 Oct 2009 13:02:53 +0200 Subject: [csw-maintainers] ncmpc-0.15 in testing Message-ID: <4AD45E5D.6080106@opencsw.org> Changes: o Upgrading to 0.15 which is a significant jump from 0.11.1 o Fixing bug #3382: "Depend on CSWggettextrt" -- Trygve From maciej at opencsw.org Tue Oct 13 14:58:20 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 13 Oct 2009 13:58:20 +0100 Subject: [csw-maintainers] GAR: building a package from loose files, with checksumming In-Reply-To: <141D5D6D-9C60-4F95-BC9D-A593E81E6F77@opencsw.org> References: <141D5D6D-9C60-4F95-BC9D-A593E81E6F77@opencsw.org> Message-ID: Thanks Dago! Your example works. I bumped against another problem: umask setting. My default umask setting is 027. I think it influences GAR somehow, take a look at this. I have an install directory with the correct permissions: $ ls -l (...)/loose-files/trunk/work/install-isa-i386/opt/csw/include/curses.h -rwxr-xr-x 1 blizinski eng 41408 Oct 13 13:40 (...)/loose-files/trunk/work/install-isa-i386/opt/csw/include/curses.h This is OK: The file is world-readable. Let's take a look at the prototype: $ cat work/build-global/CSWloosefilesexa.prototype-i386 f none /opt/csw/include/curses.h 0750 root bin i depend=CSWloosefilesexa.depend i pkginfo=CSWloosefilesexa.pkginfo The file isn't world-readable! Are there any intermediate file copying steps involved? If so, perhaps "gcp --preserve" could be used to prevent umask from affecting the outcome? Maciej From maciej at opencsw.org Tue Oct 13 15:46:01 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 13 Oct 2009 14:46:01 +0100 Subject: [csw-maintainers] GAR: building a package from loose files, with checksumming In-Reply-To: <141D5D6D-9C60-4F95-BC9D-A593E81E6F77@opencsw.org> References: <141D5D6D-9C60-4F95-BC9D-A593E81E6F77@opencsw.org> Message-ID: On Mon, Oct 12, 2009 at 7:10 PM, Dagobert Michelsen wrote: > Here's my small example: > >> GARNAME = example >> GARVERSION = 1.0 >> CATEGORIES = apps >> >> DESCRIPTION = An example >> >> FILES = /usr/bin/ls /usr/share/man/man1/ls.1 > > This is the list of files you want. > >> MASTER_SITES = $(sort $(addprefix file://,$(dir $(FILES)))) > > Every data source from MASTER_SITES is searched for the files in DISTFILES. > It is in URL syntax, the sort is only to make the dirs unique if you have > multiple files from one dir (essentially not needed here). > >> DISTFILES = $(notdir $(FILES)) What if there are two files with the same name, in different directories? Say: /opt/csw/share/foo/foo.conf /opt/csw/share/foo/examples/foo.conf My guess is that one of the files will be duplicated. Maciej From dam at opencsw.org Tue Oct 13 17:54:14 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 13 Oct 2009 17:54:14 +0200 Subject: [csw-maintainers] GAR: building a package from loose files, with checksumming In-Reply-To: References: <141D5D6D-9C60-4F95-BC9D-A593E81E6F77@opencsw.org> Message-ID: <7097ACF4-6EBD-4068-840B-7E1A342E0ADD@opencsw.org> Hi Maciej, Am 13.10.2009 um 15:46 schrieb Maciej (Matchek) Blizinski: > On Mon, Oct 12, 2009 at 7:10 PM, Dagobert Michelsen > wrote: >> Here's my small example: >> >>> GARNAME = example >>> GARVERSION = 1.0 >>> CATEGORIES = apps >>> >>> DESCRIPTION = An example >>> >>> FILES = /usr/bin/ls /usr/share/man/man1/ls.1 >> >> This is the list of files you want. >> >>> MASTER_SITES = $(sort $(addprefix file://,$(dir $(FILES)))) >> >> Every data source from MASTER_SITES is searched for the files in >> DISTFILES. >> It is in URL syntax, the sort is only to make the dirs unique if >> you have >> multiple files from one dir (essentially not needed here). >> >>> DISTFILES = $(notdir $(FILES)) > > What if there are two files with the same name, in different > directories? Say: > > /opt/csw/share/foo/foo.conf > /opt/csw/share/foo/examples/foo.conf > > My guess is that one of the files will be duplicated. Yes. And it must be that way because the files are checksummed without path. If you want that you should really think about making a tar.gz first and just copy that over. Best regards -- Dago From dam at opencsw.org Tue Oct 13 18:03:03 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 13 Oct 2009 18:03:03 +0200 Subject: [csw-maintainers] GAR: building a package from loose files, with checksumming In-Reply-To: References: <141D5D6D-9C60-4F95-BC9D-A593E81E6F77@opencsw.org> Message-ID: Hi Maciej, Am 13.10.2009 um 14:58 schrieb Maciej (Matchek) Blizinski: > I bumped against another problem: umask setting. My default umask > setting is 027. I think it influences GAR somehow, take a look at > this. I have an install directory with the correct permissions: > > $ ls -l (...)/loose-files/trunk/work/install-isa-i386/opt/csw/ > include/curses.h > -rwxr-xr-x 1 blizinski eng 41408 Oct 13 13:40 > (...)/loose-files/trunk/work/install-isa-i386/opt/csw/include/curses.h > > This is OK: The file is world-readable. Let's take a look at the > prototype: > > $ cat work/build-global/CSWloosefilesexa.prototype-i386 > f none /opt/csw/include/curses.h 0750 root bin > i depend=CSWloosefilesexa.depend > i pkginfo=CSWloosefilesexa.pkginfo > > The file isn't world-readable! Are there any intermediate file copying > steps involved? If so, perhaps "gcp --preserve" could be used to > prevent umask from affecting the outcome? The problem was caused by pax applying the umask. I have now changed this by adding '-p e' (preserve everything) to all pax invocations on r6854. Thanks for the report! -- Dago From maciej at opencsw.org Tue Oct 13 18:20:45 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 13 Oct 2009 17:20:45 +0100 Subject: [csw-maintainers] GAR: Checking for certain variables inside a category file Message-ID: I'm implementing a new category for gar, to create packages from loose files. The usage is going to be: CATEGORIES = loose FILES = ... LOCAL_SRC = ... include gar/category.mk I'd like to implement checks for FILES and LOCAL_SRC: if undefined, I want GAR to display an error with an explanation. I need to do this inside a target. Which target to use? Maciej From dam at opencsw.org Tue Oct 13 18:28:18 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 13 Oct 2009 18:28:18 +0200 Subject: [csw-maintainers] GAR: Checking for certain variables inside a category file In-Reply-To: References: Message-ID: <8E8DD0EF-5E7A-4F06-8EE6-3A5320CE279D@opencsw.org> Hi Maciej, Am 13.10.2009 um 18:20 schrieb Maciej (Matchek) Blizinski: > I'm implementing a new category for gar, to create packages from loose > files. The usage is going to be: > > CATEGORIES = loose > FILES = ... > LOCAL_SRC = ... > > include gar/category.mk > > I'd like to implement checks for FILES and LOCAL_SRC: if undefined, I > want GAR to display an error with an explanation. I need to do this > inside a target. Which target to use? No. You can just put ifeq ($(FILES),) $(error Please set FILE to ...) endif in your categories/loose/category.mk. Or are there other reasons you want to do that inside a target? Best regards -- Dago From maciej at opencsw.org Tue Oct 13 18:38:55 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 13 Oct 2009 17:38:55 +0100 Subject: [csw-maintainers] GAR: Checking for certain variables inside a category file In-Reply-To: <8E8DD0EF-5E7A-4F06-8EE6-3A5320CE279D@opencsw.org> References: <8E8DD0EF-5E7A-4F06-8EE6-3A5320CE279D@opencsw.org> Message-ID: On Tue, Oct 13, 2009 at 5:28 PM, Dagobert Michelsen wrote: >> I'd like to implement checks for FILES and LOCAL_SRC: if undefined, I >> want GAR to display an error with an explanation. I need to do this >> inside a target. Which target to use? > > No. You can just put > > ifeq ($(FILES),) > $(error Please set FILE to ...) > endif > > in your categories/loose/category.mk. Or are there other reasons > you want to do that inside a target? No, no other reasons. My code looks like this: http://dpaste.com/106704/ I'm getting this error: gar/categories/loose/category.mk:12: *** commands commence before first target. Stop. Maciej From maciej at opencsw.org Tue Oct 13 18:52:01 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 13 Oct 2009 17:52:01 +0100 Subject: [csw-maintainers] GAR: Checking for certain variables inside a category file In-Reply-To: References: <8E8DD0EF-5E7A-4F06-8EE6-3A5320CE279D@opencsw.org> Message-ID: On Tue, Oct 13, 2009 at 5:38 PM, Maciej (Matchek) Blizinski wrote: > On Tue, Oct 13, 2009 at 5:28 PM, Dagobert Michelsen wrote: >>> I'd like to implement checks for FILES and LOCAL_SRC: if undefined, I >>> want GAR to display an error with an explanation. I need to do this >>> inside a target. Which target to use? >> >> No. You can just put >> >> ifeq ($(FILES),) >> $(error Please set FILE to ...) >> endif >> >> in your categories/loose/category.mk. Or are there other reasons >> you want to do that inside a target? > > No, no other reasons. My code looks like this: > > http://dpaste.com/106704/ > > I'm getting this error: > > gar/categories/loose/category.mk:12: *** commands commence before > first target. ?Stop. This code works correctly: http://dpaste.com/106711/ ...but I'd rather avoid overriding the pre-fetch target inside a category file. I suspect that pre-fetch is meant to be set inside the package-specific Makefile. Maciej From dam at opencsw.org Tue Oct 13 19:03:29 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 13 Oct 2009 19:03:29 +0200 Subject: [csw-maintainers] GAR: Checking for certain variables inside a category file In-Reply-To: References: <8E8DD0EF-5E7A-4F06-8EE6-3A5320CE279D@opencsw.org> Message-ID: <6571CF03-1DFF-428B-92A8-0DB97B30B687@opencsw.org> Hi Maciej, Am 13.10.2009 um 18:38 schrieb Maciej (Matchek) Blizinski: > On Tue, Oct 13, 2009 at 5:28 PM, Dagobert Michelsen > wrote: >>> I'd like to implement checks for FILES and LOCAL_SRC: if >>> undefined, I >>> want GAR to display an error with an explanation. I need to do this >>> inside a target. Which target to use? >> >> No. You can just put >> >> ifeq ($(FILES),) >> $(error Please set FILE to ...) >> endif >> >> in your categories/loose/category.mk. Or are there other reasons >> you want to do that inside a target? > > No, no other reasons. My code looks like this: > > http://dpaste.com/106704/ > > I'm getting this error: > > gar/categories/loose/category.mk:12: *** commands commence before > first target. Stop. It means > This means the first thing in the makefile seems to be part of a > command script: it begins with a TAB character and doesn't appear to > be a legal make command (such as a variable assignment). Command > scripts must always be associated with a target. You have plenty of rules before this in your included gar.mk. Just remove the tab before the $(error). Take a look at gar.mk where I do exact what you want: > ifneq ($(abspath /),/) > $(error Your version of 'make' is too old: $(MAKE_VERSION). Please > make sure you are using at least 3.81) > endif Best regards -- Dago From maciej at opencsw.org Tue Oct 13 21:21:59 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 13 Oct 2009 20:21:59 +0100 Subject: [csw-maintainers] GAR: Adding own modifications to the categories Message-ID: I'm working on building in-house packages using GAR. There are bits of the local configuration that my packages could share, for instance common prefix (different from /opt/csw or /usr or /usr/local). I would like to do something along the lines of creating a category, but I don't think you can assign two categories to one package. Dago, how would you go about it? Create an additional include file and add a reference in each Makefile? For instance: (...) include /opt/csw/src/gar/v2/category.mk include /opt/myown/src/gar/localtweaks.mk ...or do something else? Maciej From maciej at opencsw.org Tue Oct 13 21:25:19 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 13 Oct 2009 20:25:19 +0100 Subject: [csw-maintainers] Packaged version of GAR Message-ID: There is a GAR build for GAR, it currently builds gar-6856,REV=2009.10.13.19.17-SunOS5.10-all-CSW.pkg.gz, I've built that and I'm using it to distribute GAR internally. But it bothers me that it hasn't been released yet, I'd like it to be in the official repository, if possible. Can we have it released? Maciej From phil at bolthole.com Tue Oct 13 22:10:54 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 13 Oct 2009 13:10:54 -0700 Subject: [csw-maintainers] Packaged version of GAR In-Reply-To: References: Message-ID: On Tue, Oct 13, 2009 at 12:25 PM, Maciej (Matchek) Blizinski wrote: > There is a GAR build for GAR, it currently builds > gar-6856,REV=2009.10.13.19.17-SunOS5.10-all-CSW.pkg.gz, I've built > that and I'm using it to distribute GAR internally. But it bothers me > that it hasn't been released yet, I'd like it to be in the official > repository, if possible. Can we have it released? > well, that's kinda difficult, when you have not submitted it through the usual proceedures for release... please do so? (whats up with that "REV" though? wiierd...) also, perhaps it should use the new name... wait did we decide on a proper name for it yet? :-) From skayser at opencsw.org Tue Oct 13 22:37:53 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 13 Oct 2009 22:37:53 +0200 Subject: [csw-maintainers] Proposal for name of our GAR version In-Reply-To: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> References: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> Message-ID: <4AD4E521.3000706@opencsw.org> Dagobert Michelsen wrote on 07.10.2009 14:36: > I did some thinking about a name for our version of the GAR build > system and ended up with "GARISOL". This is an anagram of girasol, > which is italian for sunflower showing the affinity both to GAR > and Solaris without being an actual word - this makes searching for > it and reserving names easier. > > Feedback especially welcome! What i noticed during summer camp is that short names are handy when it comes to something that you talk about very often. OpenCSW was almost too long to pronounce in every second sentence. "GAR" equals to one syllable, "GA-RI-SOL" to three of them. Sorry, no alternative option from my side for now. Sebastian From skayser at opencsw.org Tue Oct 13 23:06:54 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Tue, 13 Oct 2009 23:06:54 +0200 Subject: [csw-maintainers] Proposal for name of our GAR version In-Reply-To: <4AD4E521.3000706@opencsw.org> References: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> <4AD4E521.3000706@opencsw.org> Message-ID: <4AD4EBEE.6060201@opencsw.org> Sebastian Kayser wrote on 13.10.2009 22:37: > Dagobert Michelsen wrote on 07.10.2009 14:36: >> I did some thinking about a name for our version of the GAR build >> system and ended up with "GARISOL". This is an anagram of girasol, >> which is italian for sunflower showing the affinity both to GAR >> and Solaris without being an actual word - this makes searching for >> it and reserving names easier. >> >> Feedback especially welcome! > > What i noticed during summer camp is that short names are handy when it > comes to something that you talk about very often. OpenCSW was almost > too long to pronounce in every second sentence. > > "GAR" equals to one syllable, "GA-RI-SOL" to three of them. As an idea "garcel: Putting together your SVR4/IPS/... parcel" With a bit of imagination the pronunciation even comes close to GARISOL (or the SOL part of it) and it is one syllable less: GAR-CEL. Sebastian From mwatters at opencsw.org Tue Oct 13 23:13:49 2009 From: mwatters at opencsw.org (Mike Watters) Date: Tue, 13 Oct 2009 16:13:49 -0500 Subject: [csw-maintainers] Proposal for name of our GAR version In-Reply-To: <4AD4E521.3000706@opencsw.org> References: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> <4AD4E521.3000706@opencsw.org> Message-ID: <4AD4ED8D.4070508@opencsw.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sebastian Kayser wrote: > Dagobert Michelsen wrote on 07.10.2009 14:36: >> I did some thinking about a name for our version of the GAR build >> system and ended up with "GARISOL". This is an anagram of girasol, >> which is italian for sunflower showing the affinity both to GAR >> and Solaris without being an actual word - this makes searching for >> it and reserving names easier. >> >> Feedback especially welcome! > > What i noticed during summer camp is that short names are handy when it > comes to something that you talk about very often. OpenCSW was almost > too long to pronounce in every second sentence. > > "GAR" equals to one syllable, "GA-RI-SOL" to three of them. > > Sorry, no alternative option from my side for now. > > Sebastian > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers I vote for mGAR short, sweet, easy to type or PBC ( Package Builder - CSW) - -- ~Mike "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." --> Albert Einstein 1879 - 1955 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrU7Y0ACgkQLrhmsXMSLxfbHQCgv4vPgPcqn5i+FAoO4dWn90Lm ZnEAoIOlm/M3bc3E37w9SesnNEjauQaG =0/R1 -----END PGP SIGNATURE----- From maciej at opencsw.org Tue Oct 13 23:34:57 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 13 Oct 2009 22:34:57 +0100 Subject: [csw-maintainers] Proposal for name of our GAR version In-Reply-To: <4AD4ED8D.4070508@opencsw.org> References: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> <4AD4E521.3000706@opencsw.org> <4AD4ED8D.4070508@opencsw.org> Message-ID: To sum up, we've got (in alphabetical order): Garcel Gardis Garis Garisol Garland Garrigue Garrison Garvey mGAR PBC (Package Builder for CSW) How about putting it to the vote? From william at wbonnet.net Wed Oct 14 00:28:42 2009 From: william at wbonnet.net (William Bonnet) Date: Wed, 14 Oct 2009 00:28:42 +0200 Subject: [csw-maintainers] Proposal for name of our GAR version In-Reply-To: References: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> <4AD4E521.3000706@opencsw.org> <4AD4ED8D.4070508@opencsw.org> Message-ID: <4AD4FF1A.3020603@wbonnet.net> Hi > To sum up, we've got (in alphabetical order): > > Garcel > Gardis > Garis > Garisol > Garland > Garrigue > Garrison > Garvey > mGAR > PBC (Package Builder for CSW) > > How about putting it to the vote? > Sure I suppose something like TBSFKAG ? (The Build System Formerly Known As Gar) cannot take part to the constest ;) Yep it's time to go to bed ! cheers W. -- William http://www.wbonnet.net http://www.sunwizard.net Le site fran?ais des amateurs de stations Unix http://www.opencsw.org Community SoftWare for Solaris http://www.guses.org French speaking Solaris User Group From bwalton at opencsw.org Wed Oct 14 02:57:04 2009 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 13 Oct 2009 20:57:04 -0400 Subject: [csw-maintainers] stable release? Message-ID: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> Hi All, I haven't been involved with the drum banging for a stable release (or the discussions surrounding it). For the most part, I'm able and happy to run from current/ on my systems. I have a friend that isn't so fortunate and is locked to stable releases for his boxes. Is there any progress in this area? What are the current stumbling blocks? Should we set some sort of goal to work towards where we can know that the current package set is 'clean' enough to mark as stable? What would such a milestone look like? 0 critical bugs, From bwalton at opencsw.org Wed Oct 14 16:34:42 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 14 Oct 2009 10:34:42 -0400 Subject: [csw-maintainers] GAR tweak Message-ID: <1255530405-sup-7736@ntdws12.chass.utoronto.ca> Hi All, I just committed a change to GAR (garisol, tbsfkag ) that adds support for two new variables: ETCSERVICES: a list of files that contain entries destined to be added to /etc/services INETDCONF: a list of files that define (one per file) services that should be added to inetd.conf (or svcs on 10+). Documentation is available on the wiki: http://wiki.opencsw.org/cswclassutils-package The support in cswclassutils is pending still, but should be available soon. I also rearranged the order in which SPKG_CLASSES is handled to see cswinitsmf get its place at the end of the list as it once had. cswinetd is second last. Both of these could depend on having binaries and configs in place before they get enabled (depending on csw.conf), and as such need to be at the end. Please let me know if you encounter any issues with this change. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Wed Oct 14 17:11:30 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 14 Oct 2009 16:11:30 +0100 Subject: [csw-maintainers] stable release? In-Reply-To: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Oct 14, 2009 at 1:57 AM, Ben Walton wrote: > Is there any progress in this area? ?What are the current stumbling > blocks? ?Should we set some sort of goal to work towards where we can > know that the current package set is 'clean' enough to mark as stable? > What would such a milestone look like? ?0 critical bugs, bugs? ?Release when all the bdb stuff is sorted out? ?Release > 'sometime' next month? There is a wiki page which describes proposed automated release and 4 proposed tiers: http://wiki.opencsw.org/automated-release-process - experimental (like in debian) - testing (equiv. to debian unstable) - current (equiv. to debian testing) - stable (like in debian) I suggested that promotions from testing to current and from current to stable could be done periodically (quarterly?), as snapshots. Bug and security fixed would be promoted bypassing the periodic schedule. Thoughts? Maciej From maciej at opencsw.org Wed Oct 14 17:24:04 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 14 Oct 2009 16:24:04 +0100 Subject: [csw-maintainers] Anyone wants to update wxWidgets? In-Reply-To: <20090923.11441600.3790365392@gyor.oxdrove.co.uk> References: <625385e30908200922j40df818cn24ef7b7bda28c609@mail.gmail.com> <1251551183-sup-4494@ntdws12.chass.utoronto.ca> <1251678005-sup-226@ntdws12.chass.utoronto.ca> <20090923.11441600.3790365392@gyor.oxdrove.co.uk> Message-ID: On Wed, Sep 23, 2009 at 12:44 PM, James Lee wrote: > On 23/09/09, 12:38:15, Maciej "(Matchek)" Blizinski > wrote regarding Re: [csw-maintainers] Anyone wants to update wxWidgets?: > >> One more question: If two versions of a library are installed on one >> system, which one is being used during linking? > > The one pointed to by (or that is) .so > > /opt/csw/lib/libjpeg.so.62.0.0 > /opt/csw/lib/libjpeg.so.62=libjpeg.so.62.0.0 > /opt/csw/lib/libjpeg.so.7.0.0 > /opt/csw/lib/libjpeg.so.7=libjpeg.so.7.0.0 > /opt/csw/lib/libjpeg.so=libjpeg.so.7.0.0 > > at link libjpeg.so uses .so.7 not .62 > > > SONAME is used at run time. Thanks for the clarification. It makes sense to me now. I've got a package with both 0.2.0 and 0.6.0 in it. I compared it with the 2.8.5 version of the package: http://dpaste.com/107154/ It doesn't seem right. There are three files that are missing from my 2.8.5, that are present in the 2.8.5 from the current catalog: -/opt/csw/lib/libwx_gtk2u-2.8.so --> libwx_gtk2u-2.8.so.0 -/opt/csw/lib/libwx_gtk2u-2.8.so.0 --> libwx_gtk2u-2.8.so.0.2.0 -/opt/csw/lib/libwx_gtk2u-2.8.so.0.2.0 I checked it -- those files don't get created in my 2.8.5. After the compilation is finished, they just aren't there. There are also additional shared objects: http://dpaste.com/107157/ +/opt/csw/lib/libwx_baseu-2.8.so --> libwx_baseu-2.8.so.0 +/opt/csw/lib/libwx_baseu-2.8.so.0 --> libwx_baseu-2.8.so.0.6.0 +/opt/csw/lib/libwx_baseu-2.8.so.0.2.0 +/opt/csw/lib/libwx_baseu-2.8.so.0.6.0 +/opt/csw/lib/libwx_baseu_net-2.8.so --> libwx_baseu_net-2.8.so.0 +/opt/csw/lib/libwx_baseu_net-2.8.so.0 --> libwx_baseu_net-2.8.so.0.6.0 +/opt/csw/lib/libwx_baseu_net-2.8.so.0.2.0 +/opt/csw/lib/libwx_baseu_net-2.8.so.0.6.0 +/opt/csw/lib/libwx_baseu_xml-2.8.so --> libwx_baseu_xml-2.8.so.0 +/opt/csw/lib/libwx_baseu_xml-2.8.so.0 --> libwx_baseu_xml-2.8.so.0.6.0 +/opt/csw/lib/libwx_baseu_xml-2.8.so.0.2.0 +/opt/csw/lib/libwx_baseu_xml-2.8.so.0.6.0 ...which aren't there in 2.8.5. Is my 2.8.5 from the original maintainer's 2.8.5? Or is it something in the compilation options? (wxwidgets have a lot of them). * * * It looks like it might be the question of setting --enable-monolithic. It isn't the default for wxwidgets. Should should be used: the library default or the previous package's setting? Maciej From bwalton at opencsw.org Wed Oct 14 18:38:19 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 14 Oct 2009 12:38:19 -0400 Subject: [csw-maintainers] stable release? In-Reply-To: References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> Message-ID: <1255538113-sup-8465@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Wed Oct 14 11:11:30 -0400 2009: > I suggested that promotions from testing to current and from current > to stable could be done periodically (quarterly?), as snapshots. Bug > and security fixed would be promoted bypassing the periodic schedule. > > Thoughts? Overall, I like this, and I think that my only hesitations on the current draft are related to technical workflow issues (eg: tagging a release and then having it rejected leads to...?). These can certainly be handled. The overall plan/flow looks sound. So, apart from the automation tools required, what is preventing us from implementing this with manual methods now? Can we agree on a point at which we'd be happy to carve off a new stable and begin this process? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Wed Oct 14 18:59:19 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 14 Oct 2009 09:59:19 -0700 Subject: [csw-maintainers] stable release? In-Reply-To: <1255538113-sup-8465@ntdws12.chass.utoronto.ca> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Oct 14, 2009 at 9:38 AM, Ben Walton wrote: > > So, apart from the automation tools required, what is preventing us > from implementing this with manual methods now? responsability. It takes someone, or sometimes, with both a large chunk of time to commit, AND someone who is incredibly quality concious, to commit to taking on responsability for this. Otherwise, the result is not "stable", but merely a snapshot. We have not had anyone fitting that description speak up to volunteer taking on that responsability. From bwalton at opencsw.org Wed Oct 14 19:08:05 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 14 Oct 2009 13:08:05 -0400 Subject: [csw-maintainers] stable release? In-Reply-To: References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> Message-ID: <1255539893-sup-1957@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Wed Oct 14 12:59:19 -0400 2009: > Otherwise, the result is not "stable", but merely a snapshot. Your point is taken, but I'm more interested in defining our criteria for what separates 'stable' from 'snapshot' for the purposes of advancing the discussion. When we've agreed what our basis of quality is, people will be in a better situation to determine if they (or a small group) can tackle the responsibility of enforcing the quality we've defined as our benchmark. An elderly relative used to say (paraphrased): "Only people in the army volunteer for missions before they know what the mission consists of." -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Wed Oct 14 19:27:08 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 14 Oct 2009 18:27:08 +0100 Subject: [csw-maintainers] Anyone wants to update wxWidgets? In-Reply-To: References: <625385e30908200922j40df818cn24ef7b7bda28c609@mail.gmail.com> <1251551183-sup-4494@ntdws12.chass.utoronto.ca> <1251678005-sup-226@ntdws12.chass.utoronto.ca> <20090923.11441600.3790365392@gyor.oxdrove.co.uk> Message-ID: One more problem: It doesn't compile it on build8s, while it does on my local machine at work. Here's what happens on build8s: checking for GTK+ - version >= 2.0.0... no *** Could not run GTK+ test program, checking why... *** The test program failed to compile or link. See the file config.log for the *** exact error that occured. This usually means GTK+ is incorrectly installed. configure: error: The development files for GTK+ were not found. For GTK+ 2, please ensure that pkg-config is in the path and that gtk+-2.0.pc is installed. For GTK+ 1.2 please check that gtk-config is in the path, and that the version is 1.2.3 or above. Also check that the libraries returned by 'pkg-config gtk+-2.0 --libs' or 'gtk-config --libs' are in the LD_LIBRARY_PATH or equivalent. gmake[1]: *** [configure-work/solaris8-sparc/build-isa-sparcv8-garversion-2.8.5/wxWidgets-2.8.5/configure] Error 1 gmake[1]: Leaving directory `/home/maciej/src/opencsw/pkg/wxwidgets/trunk' gmake: *** [merge-isa-sparcv8-garversion-2.8.5] Error 2 Let's see what is my PKG_CONFIG_PATH: maciej at build8s [build8s]:~/src/opencsw/pkg/wxwidgets/trunk > gmake modenv | grep PKG_CONFIG PKG_CONFIG_PATH = /opt/csw/lib/pkgconfig:/opt/csw/X11/lib/pkgconfig PKG_CONFIG_PATH = /opt/csw/lib/pkgconfig:/opt/csw/X11/lib/pkgconfig Using this PKG_CONFIG_PATH to check the command that looks for gtk+2.0.pc: maciej at build8s [build8s]:~/src/opencsw/pkg/wxwidgets/trunk > PKG_CONFIG_PATH=/opt/csw/lib/pkgconfig:/opt/csw/X11/lib/pkgconfig pkg-config gtk+-2.0 --libs -L/opt/csw/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl It works. Strange. Looking at config.log: configure:27183: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -erroff=E_NO_EXPLICIT_TYPE_GIVEN -xO3 -xarch=v8 -fast -xstrconst -xnolibmopt -I/opt/csw/X11/include -I/usr/X11/include -I/usr/openwin/share/include -I/opt/csw/include -D_REENTRANT -D_PTHREADS -D__solaris__ -D_POSIX_PTHREAD_SEMANTICS -I/opt/csw/include/gtk-2.0 -I/opt/csw/lib/gtk-2.0/include -I/opt/csw/include/atk-1.0 -I/opt/csw/include/cairo -I/opt/csw/include/pango-1.0 -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -I/opt/csw/include/pixman-1 -I/opt/csw/include/freetype2 -I/opt/csw/include -I/opt/csw/include/libpng12 -I/opt/csw/X11/include -I/opt/csw/X11/include -I/usr/X11/include -I/usr/openwin/share/include -I/opt/csw/include -xarch=v8 -L/opt/csw/lib -L/opt/csw/X11/lib conftest.c -lm -L/opt/csw/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lpthread -lthread -lrt -lglib-2.0 -lintl >&5 "conftest.c", line 74: warning: statement not reached Undefined first referenced symbol in file XSolarisIASetProcessInfo /usr/openwin/lib/libX11.so.4 ld: fatal: Symbol referencing errors. No output written to conftest Is it related to the recent discussions about X11 libs? Is it a common problem, and are there any common fixes? Maciej From phil at bolthole.com Wed Oct 14 20:58:08 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 14 Oct 2009 11:58:08 -0700 Subject: [csw-maintainers] stable release? In-Reply-To: <1255539893-sup-1957@ntdws12.chass.utoronto.ca> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Oct 14, 2009 at 10:08 AM, Ben Walton wrote: > > Your point is taken, but I'm more interested in defining our criteria > for what separates 'stable' from 'snapshot' for the purposes of > advancing the discussion. ?When we've agreed what our basis of quality > is, ... ok. here is, approximately stated, our historical definition of quality for stable. (which technically should be archived somewhere in the oooold archives, but here 'tis again :-) A package qualifies for stable, when ALL of the following conditions are met: 1. package has been publically released for more than T time. (T usually defined as 30 days) 2. package has no significant bugs filed against it 3. All its dependancies also meet criteria 1 and 2. This sounds simple. But in practice, it has in the past, involved a large chunk of packages sitting in "current", not actually making it into a particular date's "stable" release. Then, the more packages that are excluded, then make a potential for other packages being excluded because of dependancies, which make for more headaches for the stable release manager. Not to mention the additional headaches of going around bugging people, "Hey, fix your bugs so we can have your package released to stable"! This is not a popular position to have, to put it mildly ;-) From phil at bolthole.com Wed Oct 14 21:01:23 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 14 Oct 2009 12:01:23 -0700 Subject: [csw-maintainers] stable release? In-Reply-To: References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> Message-ID: I should mention that, when you have packages in current that have been excluded from 'stable' release,so you have to use older versions of things.... a thorough "stable release manager" then gets stuck with *TESTING* whether these older package combinations still work. Consider the following proposition: Software S, depends on Library L. It is discovered that "current" L, is not qualified for stable. So, we potentially need to release with the prior version of L. Which in theory, is binary compatible with the more recent one, so it "should" be fine. But this is supposed to be "stable". So we need to actually VERIFY that it works, rather than just make guesses and shove it out to the public. From bwalton at opencsw.org Wed Oct 14 21:15:58 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 14 Oct 2009 15:15:58 -0400 Subject: [csw-maintainers] stable release? In-Reply-To: References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> Message-ID: <1255547752-sup-1532@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Wed Oct 14 14:58:08 -0400 2009: > This sounds simple. But in practice, it has in the past, involved a > large chunk of packages sitting in "current", not actually making it > into a particular date's "stable" release. So then, for purposes of a starting marker, a helpful thing to do would be to say: as of date X, any new packages are not eligible for transition from current/ to stable/ in the next release. This would be similar to the Debian release freeze, I believe. Bug fixes are the only eligible changes to packages after the freeze. Without this freeze, there is no chance of making a stable release where all packages meet the criteria. If we were to set October 31st as the date after which new packages couldn't enter the next stable, record the current list of packages in current/ and then look at the bug list, would this be a good start? > Then, the more packages that are excluded, then make a potential for > other packages being excluded because of dependancies, which make for > more headaches for the stable release manager. Are we relying on mantis for this info? > Not to mention the additional headaches of going around bugging > people, "Hey, fix your bugs so we can have your package released to > stable"! Having users jump ship because we've Debianized our release process to a glacial pace isn't fun either! :) I don't have numbers, but I bet there are lots of shops really wondering where the stable release is at this point... I could dedicate some cycles to whip cracking if it would help. I can't (and don't want to) shoulder the entire load myself, so help from others would be appreciated. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Wed Oct 14 22:32:17 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 14 Oct 2009 13:32:17 -0700 Subject: [csw-maintainers] stable release? In-Reply-To: <1255547752-sup-1532@ntdws12.chass.utoronto.ca> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Oct 14, 2009 at 12:15 PM, Ben Walton wrote: > > > So then, for purposes of a starting marker, a helpful thing to do > would be to say: as of date X, any new packages are not eligible for > transition from current/ to stable/ in the next release. yes that is exactly what we used to do. we used to have a "quarterly freeze" time. > If we were to set October 31st as the date after which new packages > couldn't enter the next stable, record the current list of packages in > current/ and then look at the bug list, would this be a good start? yes > Are we relying on mantis for this info? yes From bonivart at opencsw.org Wed Oct 14 22:44:50 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 14 Oct 2009 22:44:50 +0200 Subject: [csw-maintainers] stable release? In-Reply-To: References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> Message-ID: <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> On Wed, Oct 14, 2009 at 10:32 PM, Philip Brown wrote: > yes that is exactly what we used to do. we used to have a "quarterly > freeze" time. That freeze also affected unstable for some reason. We were basically not being able to release anything for weeks. If were going to revive this corpse we should still be able to release to current. Also, we should ask ourselves what's the most important thing for the users? Is it really stability which we hardly can guarantee or is it just a frozen state? Many sync our mirrors from time to time with no interest in having the latest and greatest, most important to them is that every machine gets the same version. We're a small organization and to put all the work James did onto someone else, even if shared by a few, is not time well spent in my opinion. We should rethink this, not just start it up again. It died for a reason. -- /peter From phil at bolthole.com Thu Oct 15 00:57:34 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 14 Oct 2009 15:57:34 -0700 Subject: [csw-maintainers] stable release? In-Reply-To: <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> Message-ID: On Wed, Oct 14, 2009 at 1:44 PM, Peter Bonivart wrote: > > Also, we should ask ourselves what's the most important thing for the > users? Is it really stability which we hardly can guarantee or is it > just a frozen state? Different users, have different scales of importance. To some users, it is important. Ben, specifically, knows of a set of users to whom it is very important. > We're a small organization and to put all the work James did onto > someone else, even if shared by a few, is not time well spent in my > opinion. We should rethink this, not just start it up again. It died > for a reason. The only "reason" it died, is that James got tired of doing the work. Not that it isnt important to do in the first place. but to address what you also wrote: it should be possible to also allow continued release to current, during the [stable release freeze phase]. It's just a matter of implementation choices. In the last round or two, we were actually allowing it. From bwalton at opencsw.org Thu Oct 15 03:35:53 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 14 Oct 2009 21:35:53 -0400 Subject: [csw-maintainers] stable release? In-Reply-To: <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> Message-ID: <1255570524-sup-9234@ntdws12.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Wed Oct 14 16:44:50 -0400 2009: > That freeze also affected unstable for some reason. We were > basically not being able to release anything for weeks. If were > going to revive this corpse we should still be able to release to > current. I agree that a freeze shouldn't be a 'stop the world' event. You're using 'current' as we commonly do now, as in 'where Phil puts packages'? If this is still open for business during a freeze then there would need to be some intermediary (a staging area) between stable and current. It should start as a snapshot of current. Updates to the snapshot should be of only two types: 1. Update to fix open bugs on the package so it can be moved into stable. 2. Removal so packages don't go to stable. > Also, we should ask ourselves what's the most important thing for > the users? Is it really stability which we hardly can guarantee or > is it just a frozen state? Many sync our mirrors from time to time > with no interest in having the latest and greatest, most important > to them is that every machine gets the same version. I think there is merit to this view, but I also think that Phil is right too. It will be dependent on the user/site. Even though I run current/ on my own boxes, I'm always a little nervous of large updates. We've seen some fairly high visibility breakages recently that would really stink on production machines. > We're a small organization and to put all the work James did onto > someone else, even if shared by a few, is not time well spent in my > opinion. We should rethink this, not just start it up again. It died > for a reason. Suggestions? I haven't been through this before, so I'm a fresh slate in this regard. Personally, if I knew that stable/ was moving forward at a regular interval, I'd probably run most of my boxes from it, leaning toward the stability side rather than the standardized versions side. As it is, I run current since that's where I can get lots of things that I want on all my machines that aren't part of stable. One thing I'd suggest is to only aim for 2 stable releases per year. More than that and too much time is spent in freeze states, I think. As a quick straw poll, what sort of major issues are people dealing with in their packages right now that would see you personally withhold the package from a stable release? [I'm considering Phil's "offer" of pushing this forward...] Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Oct 15 09:21:35 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 15 Oct 2009 08:21:35 +0100 Subject: [csw-maintainers] GAR tweak In-Reply-To: <1255530405-sup-7736@ntdws12.chass.utoronto.ca> References: <1255530405-sup-7736@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Oct 14, 2009 at 3:34 PM, Ben Walton wrote: > I just committed a change to GAR (garisol, tbsfkag ) that adds > support for two new variables: > > ETCSERVICES: a list of files that contain entries destined to be added > ? ? ? ? ? ? to /etc/services > INETDCONF: a list of files that define (one per file) services that > ? ? ? ? ? ? should be added to inetd.conf (or svcs on 10+). > > Documentation is available on the wiki: > http://wiki.opencsw.org/cswclassutils-package Would you mind adding references to those variables in the GAR template? (pkg/template/trunk/Makefile) Maciej From maciej at opencsw.org Thu Oct 15 09:40:06 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 15 Oct 2009 08:40:06 +0100 Subject: [csw-maintainers] Where's my CSWpydistutils? Message-ID: The Python GAR Makefile refers to CSWpydistutils: PACKAGES = CSWidle CSWpython CSWpydistutils CSWpython-devel CSWpython-rt CSWpython-tk CATALOGNAME_CSWpydistutils = pydistutils PKGFILES_CSWpydistutils += $(libdir)/.*/distutils/.* ...but the distutils package isn't there in the catalog! I can't build Python packages with CSWpython and it makes me a sad panda... Maciej From bonivart at opencsw.org Thu Oct 15 10:04:21 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 15 Oct 2009 10:04:21 +0200 Subject: [csw-maintainers] stable release? In-Reply-To: <1255570524-sup-9234@ntdws12.chass.utoronto.ca> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> <1255570524-sup-9234@ntdws12.chass.utoronto.ca> Message-ID: <625385e30910150104qc228e79wc6dc249a19a63cfe@mail.gmail.com> On Thu, Oct 15, 2009 at 3:35 AM, Ben Walton wrote: > One thing I'd suggest is to only aim for 2 stable releases per year. > More than that and too much time is spent in freeze states, I think. If we can still release to current during the freeze and limit it to two per year then we have gotten somewhere. To me it's more interesting to put an extra layer before current and implement more/better testing, that should raise the quality of current. > [I'm considering Phil's "offer" of pushing this forward...] Overworked and underpaid...great offer! ;-) -- /peter From james at opencsw.org Thu Oct 15 10:50:05 2009 From: james at opencsw.org (James Lee) Date: Thu, 15 Oct 2009 08:50:05 GMT Subject: [csw-maintainers] Proposal for name of our GAR version In-Reply-To: References: <74953B2E-1424-44C3-B166-A192A273329B@opencsw.org> <4AD4E521.3000706@opencsw.org> <4AD4ED8D.4070508@opencsw.org> Message-ID: <20091015.8500500.1788570355@gyor.oxdrove.co.uk> On 13/10/09, 22:34:57, Maciej "(Matchek)" Blizinski wrote regarding Re: [csw-maintainers] Proposal for name of our GAR version: > Garisol Sounds like ointment for a private area. From james at opencsw.org Thu Oct 15 10:52:11 2009 From: james at opencsw.org (James Lee) Date: Thu, 15 Oct 2009 08:52:11 GMT Subject: [csw-maintainers] stable release? In-Reply-To: References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> Message-ID: <20091015.8521100.2971713327@gyor.oxdrove.co.uk> On 14/10/09, 16:11:30, Maciej "(Matchek)" Blizinski wrote regarding Re: [csw-maintainers] stable release?: > There is a wiki page which describes proposed automated releas Automated release is not the idea. The value of stable is the QA process. From james at opencsw.org Thu Oct 15 10:53:14 2009 From: james at opencsw.org (James Lee) Date: Thu, 15 Oct 2009 08:53:14 GMT Subject: [csw-maintainers] stable release? In-Reply-To: <1255538113-sup-8465@ntdws12.chass.utoronto.ca> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> Message-ID: <20091015.8531400.1289568934@gyor.oxdrove.co.uk> On 14/10/09, 17:38:19, Ben Walton wrote regarding Re: [csw-maintainers] stable release?: > So, apart from the automation tools required, what is preventing us > from implementing this with manual methods now? Can we agree on a > point at which we'd be happy to carve off a new stable and begin this > process? It would fail and the main players already know what to do (look at your mantis reports). James. From james at opencsw.org Thu Oct 15 10:54:34 2009 From: james at opencsw.org (James Lee) Date: Thu, 15 Oct 2009 08:54:34 GMT Subject: [csw-maintainers] stable release? In-Reply-To: <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> Message-ID: <20091015.8543400.2171942468@gyor.oxdrove.co.uk> On 14/10/09, 21:44:50, Peter Bonivart wrote regarding Re: [csw-maintainers] stable release?: > On Wed, Oct 14, 2009 at 10:32 PM, Philip Brown wrote: > > yes that is exactly what we used to do. we used to have a "quarterly > > freeze" time. > That freeze also affected unstable for some reason. We were basically > not being able to release anything for weeks. If were going to revive > this corpse we should still be able to release to current. This is really a practical consideration because it takes time to test and we rely on field experiences as part of verification. Unless a package is used we get no feed back, further it's the overall combination that matters so the combination needs field time. We need additions built against the unstable build as that's the build machine state. Hence we can't have new unstable releases during the stable consideration period. If there were 1,000s beta testers we'd be all right; in effect we are using unstable users as beta testers. > Is it really stability which we hardly can guarantee or is it > just a frozen state? It's not a frozen state, it's a QAed state. It's doesn't come with a guarantee but people pay jack shit for the process. James. From james at opencsw.org Thu Oct 15 10:51:31 2009 From: james at opencsw.org (James Lee) Date: Thu, 15 Oct 2009 08:51:31 GMT Subject: [csw-maintainers] stable release? In-Reply-To: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> Message-ID: <20091015.8513100.927409174@gyor.oxdrove.co.uk> On 14/10/09, 01:57:04, Ben Walton wrote regarding [csw-maintainers] stable release?: > Is there any progress in this area? What are the current stumbling > blocks? Should we set some sort of goal to work towards where we can > know that the current package set is 'clean' enough to mark as stable? > What would such a milestone look like? 0 critical bugs, bugs? Release when all the bdb stuff is sorted out? Release > 'sometime' next month? Yes BDB has been a blocker. > If we have some sort of defined goal, we'd all be able to work toward > it. Without a defined goal... I would hope no bugs was a goal anyway but historically we know we periodically create them. The difference is not creating new ones but there is no point in calling a freeze when there are known problems like BDB unresolved. (BDB isn't the only outstanding major bug.) James. From mwatters at opencsw.org Thu Oct 15 16:26:18 2009 From: mwatters at opencsw.org (Mike Watters) Date: Thu, 15 Oct 2009 09:26:18 -0500 Subject: [csw-maintainers] Where's my CSWpydistutils? In-Reply-To: References: Message-ID: <4AD7310A.7070307@opencsw.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Maciej (Matchek) Blizinski wrote: > The Python GAR Makefile refers to CSWpydistutils: > > PACKAGES = CSWidle CSWpython CSWpydistutils CSWpython-devel > CSWpython-rt CSWpython-tk > CATALOGNAME_CSWpydistutils = pydistutils > PKGFILES_CSWpydistutils += $(libdir)/.*/distutils/.* > > ...but the distutils package isn't there in the catalog! I can't build > Python packages with CSWpython and it makes me a sad panda... > > Maciej > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers if you are looking at the Makefile in gar, you are looking at the "new" one the existing distutils is part of CSWpython-devel. once bdb is out and I get a few minutes to finish the new build I will "fix" the split up of the packages. - -- ~Mike "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." --> Albert Einstein 1879 - 1955 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrXMQoACgkQLrhmsXMSLxfCGwCg31b1Y0JPFPRHIJk+8XyC1KHT zvIAnRa51Zq2GHnyolbh9wglylf97o3h =NpaP -----END PGP SIGNATURE----- From maciej at opencsw.org Thu Oct 15 16:36:59 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 15 Oct 2009 15:36:59 +0100 Subject: [csw-maintainers] Where's my CSWpydistutils? In-Reply-To: <4AD7310A.7070307@opencsw.org> References: <4AD7310A.7070307@opencsw.org> Message-ID: On Thu, Oct 15, 2009 at 3:26 PM, Mike Watters wrote: >> ...but the distutils package isn't there in the catalog! I can't build >> Python packages with CSWpython and it makes me a sad panda... I'd like to request including distutils in the main package (CSWpython). For languages such as Python, Ruby or Perl it's a common practice to install modules or packages specific to that language. I think would be nice to safe hassle of bumping into the missing module, and then looking for the right package. Human frustration cost is higher than disk space benefit. Maciej From phil at bolthole.com Thu Oct 15 18:29:29 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 15 Oct 2009 09:29:29 -0700 Subject: [csw-maintainers] stable release? In-Reply-To: <1255570524-sup-9234@ntdws12.chass.utoronto.ca> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> <1255570524-sup-9234@ntdws12.chass.utoronto.ca> Message-ID: On Wed, Oct 14, 2009 at 6:35 PM, Ben Walton wrote: > > One thing I'd suggest is to only aim for 2 stable releases per year. > More than that and too much time is spent in freeze states, I think. > i agree. not to mention there's less burnout, etc. "only" 2 per year, is infinitely better than 0 per year. From james at opencsw.org Thu Oct 15 18:42:32 2009 From: james at opencsw.org (James Lee) Date: Thu, 15 Oct 2009 16:42:32 GMT Subject: [csw-maintainers] stable release? In-Reply-To: References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> <1255570524-sup-9234@ntdws12.chass.utoronto.ca> Message-ID: <20091015.16423200.157874866@gyor.oxdrove.co.uk> On 15/10/09, 17:29:29, Philip Brown wrote regarding Re: [csw-maintainers] stable release?: > > One thing I'd suggest is to only aim for 2 stable releases per year. > > More than that and too much time is spent in freeze states, I think. > > > i agree. not to mention there's less burnout, etc. Not necessarily, anything changed gets more rigourous test, (no change plus no depend change means no test is needed), the longer you leave it the more there is. It also get increasingly hard to stop-gap carry over. We are facing this now, eg, if BDB screws it's not practical to carry stuff over from 18 months - it needs fixing. James. From bonivart at opencsw.org Fri Oct 16 11:06:52 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 16 Oct 2009 11:06:52 +0200 Subject: [csw-maintainers] Fwd: [csw-users] i386 libraries in mercurial for Solaris sparc In-Reply-To: References: Message-ID: <625385e30910160206v1d5a0800x3b4a0807307e3d50@mail.gmail.com> >From the users list... ---------- Forwarded message ---------- From: Torsten Gollnick Date: Fri, Oct 16, 2009 at 10:15 AM Subject: [csw-users] i386 libraries in mercurial for Solaris sparc To: users at lists.opencsw.org Hello, mercurial does not work for me on Solaris Sparc due to i386 libs. I use url=http://ibiblio.org/pub/packages/solaris/opencsw/current did pkg-get -U and pkg-get -u The package version is ?mercurial 1.3.1,REV=2009.10.03 How can I brief the maintainer? Torsten starting hg gives $ hg Traceback (most recent call last): ?File "/opt/csw/bin/hg", line 27, in ? ?mercurial.dispatch.run() ?File "/opt/csw/lib/python/site-packages/mercurial/dispatch.py", line 16, in run ? ?sys.exit(dispatch(sys.argv[1:])) ?File "/opt/csw/lib/python/site-packages/mercurial/dispatch.py", line 21, in dispatch ? ?u = _ui.ui() ?File "/opt/csw/lib/python/site-packages/mercurial/ui.py", line 35, in __init__ ? ?for f in util.rcpath(): ?File "/opt/csw/lib/python/site-packages/mercurial/util.py", line 1217, in rcpath ? ?_rcpath = os_rcpath() ?File "/opt/csw/lib/python/site-packages/mercurial/util.py", line 1193, in os_rcpath ? ?path = system_rcpath() ?File "/opt/csw/lib/python/site-packages/mercurial/posix.py", line 41, in system_rcpath ? ?'/../etc/mercurial')) ?File "/opt/csw/lib/python/site-packages/mercurial/posix.py", line 30, in rcfiles ? ?for f, kind in osutil.listdir(rcdir) ?File "/opt/csw/lib/python/site-packages/mercurial/demandimport.py", line 75, in __getattribute__ ? ?self._load() ?File "/opt/csw/lib/python/site-packages/mercurial/demandimport.py", line 47, in _load ? ?mod = _origimport(head, globals, locals) ImportError: ld.so.1: python: fatal: /opt/csw/lib/python/site-packages/mercurial/osutil.so: wrong ELF data format: ELFDATA2LSB and ?file ?/opt/csw/lib/python/site-packages/mercurial/osutil.so /opt/csw/lib/python/site-packages/mercurial/osutil.so: ?ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped The packge is Processing package instance from _______________________________________________ users mailing list users at lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/users -- /peter From dam at opencsw.org Fri Oct 16 18:20:41 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 16 Oct 2009 18:20:41 +0200 Subject: [csw-maintainers] stable release? In-Reply-To: <20091015.16423200.157874866@gyor.oxdrove.co.uk> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> <1255570524-sup-9234@ntdws12.chass.utoronto.ca> <20091015.16423200.157874866@gyor.oxdrove.co.uk> Message-ID: <2B144D45-2F2D-4DC8-AA2C-534192D8A4A0@opencsw.org> Hi, Am 15.10.2009 um 18:42 schrieb James Lee: > On 15/10/09, 17:29:29, Philip Brown wrote > regarding Re: > [csw-maintainers] stable release?: > >>> One thing I'd suggest is to only aim for 2 stable releases per year. >>> More than that and too much time is spent in freeze states, I think. >> >> i agree. not to mention there's less burnout, etc. > > Not necessarily, anything changed gets more rigourous test, (no change > plus no depend change means no test is needed), the longer you leave > it the more there is. It also get increasingly hard to stop-gap carry > over. We are facing this now, eg, if BDB screws it's not practical to > carry stuff over from 18 months - it needs fixing. Yes. Hopefully this BDB thing gets fixed tomorrow. But I replied for another reason: It would be nice to note on a package which status it is in: - untested - tested, open bugs - tested, no open bugs - ready for stable If all the dependencies are "ready for stable" too it would be ok to release. That way it would be easy to see how far away we are from a release, not only for James who of course knows this, but for the rest of us :-) Maybe we can use a field in the database for this? Best regards -- Dago From phil at bolthole.com Fri Oct 16 18:53:22 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 16 Oct 2009 09:53:22 -0700 Subject: [csw-maintainers] stable release? In-Reply-To: <2B144D45-2F2D-4DC8-AA2C-534192D8A4A0@opencsw.org> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> <1255570524-sup-9234@ntdws12.chass.utoronto.ca> <20091015.16423200.157874866@gyor.oxdrove.co.uk> <2B144D45-2F2D-4DC8-AA2C-534192D8A4A0@opencsw.org> Message-ID: On Fri, Oct 16, 2009 at 9:20 AM, Dagobert Michelsen wrote: > .... > Yes. Hopefully this BDB thing gets fixed tomorrow. But I replied for > another reason: It would be nice to note on a package which status > it is in: ... doing stable is a huge undertaking. I dont think we should be throwing extra "requests" in there, before we even have someone officially volunteering to do the BASIC work. there's more than enough work there as is. From dam at opencsw.org Fri Oct 16 19:06:07 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 16 Oct 2009 19:06:07 +0200 Subject: [csw-maintainers] stable release? In-Reply-To: References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> <1255570524-sup-9234@ntdws12.chass.utoronto.ca> <20091015.16423200.157874866@gyor.oxdrove.co.uk> <2B144D45-2F2D-4DC8-AA2C-534192D8A4A0@opencsw.org> Message-ID: Hi Phil, Am 16.10.2009 um 18:53 schrieb Philip Brown: > On Fri, Oct 16, 2009 at 9:20 AM, Dagobert Michelsen > wrote: >> .... >> Yes. Hopefully this BDB thing gets fixed tomorrow. But I replied for >> another reason: It would be nice to note on a package which status >> it is in: ... > > doing stable is a huge undertaking. > I dont think we should be throwing extra "requests" in there, before > we even have someone officially volunteering to do the BASIC work. > there's more than enough work there as is. I can't remember that we even have defined this is, besides "Q/A", but what specifically? I know James has an infrastructure with cleanroom-install-depend-checks, ldd-inspection of libs and stuff. It would be good to formalize as much as feasible what a package must actually conform to to be good for stable. Currently at least I don't know how many, let alone what packages are really broken. If James already has all the tests we should apply them routinely on the farm for all packages. And: no, "somebody must have used the package" is not the only criterium for stable. Best regards -- Dago From james at opencsw.org Fri Oct 16 21:56:45 2009 From: james at opencsw.org (James Lee) Date: Fri, 16 Oct 2009 19:56:45 GMT Subject: [csw-maintainers] stable release? In-Reply-To: <2B144D45-2F2D-4DC8-AA2C-534192D8A4A0@opencsw.org> References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255538113-sup-8465@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> <1255570524-sup-9234@ntdws12.chass.utoronto.ca> <20091015.16423200.157874866@gyor.oxdrove.co.uk> <2B144D45-2F2D-4DC8-AA2C-534192D8A4A0@opencsw.org> Message-ID: <20091016.19564500.2186435010@gyor.oxdrove.co.uk> On 16/10/09, 17:20:41, Dagobert Michelsen wrote regarding Re: [csw-maintainers] stable release?: > It would be nice to note on a package which status > it is in: > - untested > - tested, open bugs > - tested, no open bugs > - ready for stable This isn't useful to users. Users know the possible state by the place they obtain. No package is untested because clearly the maintainer will have tested prior to unstable release, both arches. One can know the bug state from bug reports. Ready for stable isn't something judged in isolation but only as a whole so isn't the property of a package. From james at opencsw.org Fri Oct 16 21:56:46 2009 From: james at opencsw.org (James Lee) Date: Fri, 16 Oct 2009 19:56:46 GMT Subject: [csw-maintainers] stable release? In-Reply-To: References: <1255481568-sup-8052@ntdws12.chass.utoronto.ca> <1255539893-sup-1957@ntdws12.chass.utoronto.ca> <1255547752-sup-1532@ntdws12.chass.utoronto.ca> <625385e30910141344x23ca3d5eo5dac71a29ac7c848@mail.gmail.com> <1255570524-sup-9234@ntdws12.chass.utoronto.ca> <20091015.16423200.157874866@gyor.oxdrove.co.uk> <2B144D45-2F2D-4DC8-AA2C-534192D8A4A0@opencsw.org> Message-ID: <20091016.19564600.3546434106@gyor.oxdrove.co.uk> On 16/10/09, 18:06:07, Dagobert Michelsen wrote regarding Re: [csw-maintainers] stable release?: > I can't remember that we even have defined this is, Yes we defined it. > besides > "Q/A", but what specifically? I know James has an infrastructure > with cleanroom-install-depend-checks, ldd-inspection of libs and > stuff. It would be good to formalize as much as feasible what a > package must actually conform to to be good for stable. > Currently at least I don't know how many, let alone what packages > are really broken. If James already has all the tests we > should apply them routinely on the farm for all packages. > And: no, "somebody must have used the package" is not the > only criterium for stable. It's not far off. The criteria are: * It installs * It works * It can be removed No surprises there and nothing too taxing I trust. "It works" is difficult to judge and you are trying to apply a automatic test which isn't possible. What is possible is to test for the reverse state and ensure it doesn't exist. For this there are some automated checks. Then the are inferences from these such as "can be upgraded from previous", (means previous installed and not the previous version), which should work according the above if the previous can be removed. Doesn't clash with another packages. Blah, blah, I think it's been said before. Note the QA is of the packaging and not of the underlying software. Note it's possible to have 2 perfect packages that don't work together. James. From maciej at opencsw.org Sat Oct 17 13:16:13 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sat, 17 Oct 2009 12:16:13 +0100 Subject: [csw-maintainers] pysvn and the other pysvn Message-ID: Looks like we have a package name collision. I'd like to build pysvn[1], but there already is a CSWpysvn package. What do we do with this name clash, any suggestions? Maciej [1] http://pysvn.tigris.org/ From mwatters at opencsw.org Sun Oct 18 05:05:30 2009 From: mwatters at opencsw.org (Mike Watters) Date: Sat, 17 Oct 2009 22:05:30 -0500 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: References: Message-ID: <4ADA85FA.7090506@opencsw.org> On 10/17/2009 06:16 AM, Macias (Matches) Brzezinski wrote: > Looks like we have a package name collision. I'd like to build > pysvn[1], but there already is a CSWpysvn package. What do we do with > this name clash, any suggestions? > > Maciej > > [1] http://pysvn.tigris.org/ > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers the existing pylon is the python module for subversion that comes with the source code. I have not yet looked at the difference, what are the main differences? if we are going to package them both, I think one should be python_subversion and one pylon but I am not sure which should be which without more investigation. -- Thanks, Mike "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." * Albert Einstein 1879 - 1955 US German-born Theoretical Physicist From maciej at opencsw.org Sun Oct 18 09:42:10 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 18 Oct 2009 08:42:10 +0100 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: <4ADA85FA.7090506@opencsw.org> References: <4ADA85FA.7090506@opencsw.org> Message-ID: On Sun, Oct 18, 2009 at 4:05 AM, Mike Watters wrote: > On 10/17/2009 06:16 AM, Macias (Matches) Brzezinski wrote: An eager spell correction? >> Looks like we have a package name collision. I'd like to build >> pysvn[1], but there already is a CSWpysvn package. What do we do with >> this name clash, any suggestions? >> >> Maciej >> >> [1] http://pysvn.tigris.org/ >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers > > the existing pylon is the python module for subversion that comes with the > source code. ?I have not yet looked at the difference, what are the main > differences? pysvn.tigris.org is an entirely different project. If you read Subvesion's core docs[1], you'll find that they say "Subversion's language bindings unfortunately tend to lack the level of attention given to the core Subversion modules. However, there have been significant efforts towards creating functional bindings for Python, Perl, and Java.". I think the one bundled with Subversion is not very useful. pysvn.tigris.org is the one I'd like to work with (once I get it to build). Maciej [1] http://svnbook.red-bean.com/en/1.1/ch08s02.html From maciej at opencsw.org Sun Oct 18 12:58:39 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 18 Oct 2009 11:58:39 +0100 Subject: [csw-maintainers] A request to remove CSWpyxml from the buildfarm Message-ID: CSWpyxml is a package providing XML support for Python. There is a problem with it: it breaks the build of pysvn[1]. Python 2.6 has XML functionality built in (xml.dom.minidom is there already), and there is CSWpylibxml2 to provide XML-related functionality. I'd like to request the removal of CSWpyxml from the buildfarm. There's only one package depending on CSWpyxml: CSWskencil. I tried to check whether it really needs CSWpyxml, but it fails on a missing symbol: $ skencil Traceback (most recent call last): File "/opt/csw/bin/skencil", line 57, in Sketch.UI.main(sys.argv) File "/opt/csw/lib/skencil-cvs/Sketch/UI/__init__.py", line 231, in main from skapp import SketchApplication File "/opt/csw/lib/skencil-cvs/Sketch/UI/skapp.py", line 21, in import gtk, gtk.keysyms File "/opt/csw/lib/python/site-packages/gtk-2.0/gtk/__init__.py", line 48, in from gtk import _gtk ImportError: ld.so.1: python: fatal: relocation error: file /opt/csw/lib/python/site-packages/gtk-2.0/gtk/_gtk.so: symbol PyUnicodeUCS2_DecodeUTF8: referenced symbol not found In conclusion, if there's only one package dependent package which doesn't work anyway, I see no downsides of the removal of this package from the buildfarm. (I'm aware that skencil doesn't work because current pygtk is broken and orphaned[3]. Yes, pygtk needs fixing, but it's a separate issue.) Maciej [1] http://pysvn.tigris.org/issues/show_bug.cgi?id=142 [2] http://www.opencsw.org/packages/CSWpyxml [3] http://www.opencsw.org/packages/CSWpygtk From dam at opencsw.org Sun Oct 18 13:04:40 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 18 Oct 2009 13:04:40 +0200 Subject: [csw-maintainers] [csw-buildfarm] A request to remove CSWpyxml from the buildfarm In-Reply-To: References: Message-ID: <595B53DB-5921-4915-89CF-FE2BC43C9813@opencsw.org> Hi, Am 18.10.2009 um 12:58 schrieb Maciej (Matchek) Blizinski: > A request to remove CSWpyxml from the buildfarm Doing this now. Best regards -- Dago From maciej at opencsw.org Sun Oct 18 18:35:53 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 18 Oct 2009 17:35:53 +0100 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: References: <4ADA85FA.7090506@opencsw.org> Message-ID: I got pysvn-1.7.1 to build. It's in testing. For the package name conflict, I suggest the following: 1. Replacing the subversion-provided pysvn with pysvn.tigris.org, preserving the both pkgname and catalog name. It will look like a version bounce from 1.6.2 to 1.7.1. (justification: pysvn is the name of the project, it's more specific than the generic notion of bindings between subversion and Python.) 2. Creating a new package with subversion-provided Python bindings to subversion_py CSWsubversion-py, or something similar. It will be clear that it belongs to packages such as CSWsubversion and CSWsubversion-devel. For instance: http://dpaste.com/108954/ (I know it breaks the py_* rule, but it's a good thing: it's not a very useful module, there's no harm in people not seeing it often when looking for Python subversion bindings) Thoughts? Maciej From ihsan at opencsw.org Sun Oct 18 18:43:28 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 18 Oct 2009 18:43:28 +0200 Subject: [csw-maintainers] Apache 2 Package Message-ID: <4ADB45B0.1000207@opencsw.org> Hello, The Apache 2 package needs to be reworked and I can't find any additional ressources at this time. Would be great if someone could take over this package. ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From maciej at opencsw.org Sun Oct 18 18:48:30 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 18 Oct 2009 17:48:30 +0100 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: <4ADB45B0.1000207@opencsw.org> References: <4ADB45B0.1000207@opencsw.org> Message-ID: On Sun, Oct 18, 2009 at 5:43 PM, Ihsan Dogan wrote: > The Apache 2 package needs to be reworked and I can't find any > additional ressources at this time. Would be great if someone could take > over this package. What is there to be done? (I'm not volunteering, I'm asking because I think that a description or a task list would be useful for potential volunteers.) Maciej From ihsan at opencsw.org Sun Oct 18 18:54:15 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 18 Oct 2009 18:54:15 +0200 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: References: <4ADB45B0.1000207@opencsw.org> Message-ID: <4ADB4837.9010404@opencsw.org> Am 18.10.2009 18:48 Uhr, Maciej (Matchek) Blizinski schrieb: >> The Apache 2 package needs to be reworked and I can't find any >> additional ressources at this time. Would be great if someone could take >> over this package. > > What is there to be done? The packaging has to be changed to dynamic prototype, gspec files has to be removed and maybe the packaging of the rt and c package has to be verified. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From bwalton at opencsw.org Sun Oct 18 19:31:59 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 18 Oct 2009 13:31:59 -0400 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: <4ADB4837.9010404@opencsw.org> References: <4ADB45B0.1000207@opencsw.org> <4ADB4837.9010404@opencsw.org> Message-ID: <1255887034-sup-5726@ntdws12.chass.utoronto.ca> Excerpts from Ihsan Dogan's message of Sun Oct 18 12:54:15 -0400 2009: > The packaging has to be changed to dynamic prototype, gspec files has to > be removed and maybe the packaging of the rt and c package has to be > verified. ...and sysconfdir -> /etc/opt/csw/apache2, localstatedir -> /var/opt/csw/apache2? [Just a personal wishlist item.] Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rupert at opencsw.org Sun Oct 18 20:00:17 2009 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 18 Oct 2009 20:00:17 +0200 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: References: <4ADA85FA.7090506@opencsw.org> Message-ID: <6af4270910181100p304aad88w83fe974abfa2353f@mail.gmail.com> On Sun, Oct 18, 2009 at 18:35, Maciej (Matchek) Blizinski wrote: > I got pysvn-1.7.1 to build. It's in testing. > > For the package name conflict, I suggest the following: > > 1. Replacing the subversion-provided pysvn with pysvn.tigris.org, > preserving the both pkgname and catalog name. It will look like a > version bounce from 1.6.2 to 1.7.1. (justification: pysvn is the name > of the project, it's more specific than the generic notion of bindings > between subversion and Python.) > > 2. Creating a new package with subversion-provided Python bindings to > subversion_py CSWsubversion-py, or something similar. It will be clear > that it belongs to packages such as CSWsubversion and > CSWsubversion-devel. For instance: http://dpaste.com/108954/ (I know > it breaks the py_* rule, but it's a good thing: it's not a very useful > module, there's no harm in people not seeing it often when looking for > Python subversion bindings) > > Thoughts? would this mean existing dependencies would work out if one replaces the contents with something else? rupert From ihsan at opencsw.org Sun Oct 18 21:16:14 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 18 Oct 2009 21:16:14 +0200 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: <1255887034-sup-5726@ntdws12.chass.utoronto.ca> References: <4ADB45B0.1000207@opencsw.org> <4ADB4837.9010404@opencsw.org> <1255887034-sup-5726@ntdws12.chass.utoronto.ca> Message-ID: <4ADB697E.5060403@opencsw.org> Am 18.10.2009 19:31 Uhr, Ben Walton schrieb: > Excerpts from Ihsan Dogan's message of Sun Oct 18 12:54:15 -0400 2009: > >> The packaging has to be changed to dynamic prototype, gspec files has to >> be removed and maybe the packaging of the rt and c package has to be >> verified. > > ...and sysconfdir -> /etc/opt/csw/apache2, localstatedir -> > /var/opt/csw/apache2? [Just a personal wishlist item.] Of course, I've forgot that one. This would require coordination with other package maintainers. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From bwalton at opencsw.org Sun Oct 18 21:24:35 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 18 Oct 2009 15:24:35 -0400 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: <4ADB697E.5060403@opencsw.org> References: <4ADB45B0.1000207@opencsw.org> <4ADB4837.9010404@opencsw.org> <1255887034-sup-5726@ntdws12.chass.utoronto.ca> <4ADB697E.5060403@opencsw.org> Message-ID: <1255893828-sup-8764@ntdws12.chass.utoronto.ca> Excerpts from Ihsan Dogan's message of Sun Oct 18 15:16:14 -0400 2009: > Of course, I've forgot that one. This would require coordination with > other package maintainers. Yes, it won't be easy. It's a wishlist, but certainly not a must have in this case. If it was only the apache package itself that was affected, it'd be a much easier move. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Mon Oct 19 00:08:41 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Sun, 18 Oct 2009 23:08:41 +0100 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: <6af4270910181100p304aad88w83fe974abfa2353f@mail.gmail.com> References: <4ADA85FA.7090506@opencsw.org> <6af4270910181100p304aad88w83fe974abfa2353f@mail.gmail.com> Message-ID: On Sun, Oct 18, 2009 at 7:00 PM, rupert THURNER wrote: > would this mean existing dependencies would work out if one replaces > the contents with something else? Good point. Those packages provide different libraries; currently only Trac depends on CSWpysvn[1][2]. I guess it won't be hard to update its dependencies to the new package and release them together. Maciej [1] http://www.opencsw.org/packages/CSWpysvn [2] http://svn.edgewall.com/repos/trac/trunk/INSTALL From maciej at opencsw.org Mon Oct 19 01:39:45 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 19 Oct 2009 00:39:45 +0100 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4AAB32A6.5060305@opencsw.org> <64360.194.246.122.22.1253185698.squirrel@ssl.skayser.de> Message-ID: I've written the first version of cswmigrateconf, a class utility script which migrates configuration files from /opt/csw/etc to /etc/opt/csw. It works the way Sebastian has suggested, i.e.: It makes an intermediate copy in /opt/csw/etc/migration-archive, and then uses it as a source to populate /etc/opt/csw. The change can be viewed here: http://sourceforge.net/apps/trac/gar/changeset/6899 http://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/cswclassutils/trunk/files/CSWcswclassutils.i.cswmigrateconf It also deals with a situation where there are symlinks from /etc/opt/csw/foo.conf go /opt/csw/etc/foo.conf -- or any (soon to be) dangling symlinks. To use the class utility script, one needs to create a configuration file for it and set the file class. Only one configuration file is allowed per package. An example of a simple configuration file: MIGRATE_FILES="odbc.ini odbcinst.ini" That's it. The migration script will do the rest. If one wanted to migrate odbc.ini to a different directory, here's how to do it: MIGRATE_FILES="odbc.ini odbcinst.ini" SOURCE_DIR_odbc_ini="opt/csw/etc/mysubdir" DEST_DIR_odbc_ini="etc/opt/csw/anotherplace" Leading slash won't hurt, but it's not necessary. If all the files share the same subdirectory, default source directory can be specified: SOURCE_DIR___default__="etc/opt/csw/mysubdir" It's been briefly tested on my workstation. I've built a package and put it into testing: http://mirror.opencsw.org/testing/cswclassutils-1.24,REV=2009.10.19-SunOS5.8-all-CSW.pkg.gz The code is somewhat complex; I did my best to make it readable. Comments and questions are appreciated. Maciej From maciej at opencsw.org Mon Oct 19 01:57:59 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Mon, 19 Oct 2009 00:57:59 +0100 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 Message-ID: I wrote a utility to automate the step of submitting a package to the release maintainer. It takes a comma-separated list of package names, copies the packages from the testing directory to newpkgs and formats an e-mail with the list of package files. Usage: submitpkg [options] Options: -h, --help show this help message and exit -p PKGNAMES, --pkgnames=PKGNAMES A comma-separated list of pkgnames -d, --debug Print debugging messages It doesn't send the e-mail. It only formats it and lets the user edit it. Upon exit, it tells how to send the e-mail (sendmail -t ). submitpkg is configurable. A system-wide configuration file is accepted: /etc/opt/csw/releases.ini -- the user-specific configuration file is in ~/.releases.ini. Example configuration: ; A configuration file for the release automation script [releases] sender name = Maciej Blizinski sender email = release manager name = Phil Brown release manager email = release cc = ; Usually it's /home/testing package dir = /home/testing target host = bender target dir = /home/newpkgs And... yes, it's not GAR-specific. :-) The source code is here: https://opencsw.svn.sourceforge.net/svnroot/opencsw/utilities/submit_to_newpkgs.py Any comments, thoughts or flames? Maciej From dam at opencsw.org Mon Oct 19 08:36:27 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 19 Oct 2009 08:36:27 +0200 Subject: [csw-maintainers] build8x and buid8xt currently down Message-ID: Hi, I just started to upgrade the farm with the latest packages and than a thought flashed my mind that I had to put autoenable_cswopenssh=yes in /etc/opt/csw/csw.conf or OpenSSH stays down on build8*. Needless to say that build8s, build8x and build8xt had already been updated, but not build8s.go.opencsw.org. So please be advised that build8x build8xt will stay down until a couple of hours when I get back to the office. The others machines will be upgraded at that time also. ...and I *will* insert that line now, before the next upgrade :-P Sorry for the inconvenience -- Dago From dam at opencsw.org Mon Oct 19 15:36:55 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 19 Oct 2009 15:36:55 +0200 Subject: [csw-maintainers] build8x* is available again Message-ID: <6CDDA8D3-409A-4265-8D13-2D4DA6B3F2E0@opencsw.org> Hi, the servers build8x and build8xt are available again. Sorry for the inconvenience -- Dago From phil at bolthole.com Mon Oct 19 17:33:08 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 19 Oct 2009 08:33:08 -0700 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: References: Message-ID: On Sun, Oct 18, 2009 at 4:57 PM, Maciej (Matchek) Blizinski wrote: > I wrote a utility to automate the step of submitting a package to the > release maintainer. It takes a comma-separated list of package names, > copies the packages from the testing directory to newpkgs and formats > an e-mail with the list of package files. > > Usage: submitpkg [options] Excellent!! we've needed this for a long time. When it's debugged some, it should go in cswutils. Thanks for writing this. > Any comments, thoughts or flames? did it HAVE to be written in python? :-( even perl would be better. Something as basic as this, would be nice to use without having to potentially download and install a whole new language package. From dam at opencsw.org Mon Oct 19 17:35:30 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 19 Oct 2009 17:35:30 +0200 Subject: [csw-maintainers] BerkeleyDB upgrade References: Message-ID: <4C32281F-89A3-4B57-B840-699CA6795EDB@opencsw.org> Dear maintainers, I have now finally assembled a new and complete rebuild of the Berkeley DB libraries. In the new schema every version of BDB is sitting in a separate subdirectory, that means Berkeley DB X.Y.Z is located at /opt/csw/bdbXY/(bin|lib|...) The repackaged versions contain 3.3, 4.2, 4.3, 4.4, 4.7 and 4.8. If necessary the legacy packages needed as dependencies have been replaced by stubs containing minimal links to the new locations with a respective dependency in the package. The following packages have been updated: CATALOGNAME PACKAGENAME berkeleydb CSWbdb berkeleydb3 CSWbdb3 berkeleydb3_devel CSWbdb3devel berkeleydb3_doc CSWbdb3doc berkeleydb4 CSWbdb4 berkeleydb42 CSWbdb42 berkeleydb42_devel CSWbdb42devel berkeleydb42_doc CSWbdb42doc berkeleydb43 CSWbdb43 berkeleydb43_devel CSWbdb43-devel berkeleydb43_doc CSWbdb43-doc berkeleydb44 CSWbdb44 berkeleydb44_devel CSWbdb44-devel berkeleydb44_doc CSWbdb44-doc berkeleydb47 CSWbdb47 berkeleydb47_devel CSWbdb47devel berkeleydb47_doc CSWbdb47doc berkeleydb48 CSWbdb48 berkeleydb48_devel CSWbdb48devel berkeleydb48_doc CSWbdb48doc The following packages are deprecated: - CSWbdb was newly introduced during the unification. It contains now only symlinks pointing inside CSWbdb47. The package will go away when all dependant packages habe been recompiled against CSWbdb47. /opt/csw/lib/amd64/libdb-4.7.so=../../bdb47/lib/amd64/libdb-4.7.so /opt/csw/lib/libdb-4.7.so=../bdb47/lib/libdb-4.7.so - CSWbdb4 contained the original Berkeley DB 4.2 in /opt/csw/bdb4. The package now contains /opt/csw/bdb4=bdb42 The following packages do not exist any more as the base packages are deprecated: - berkeleydb_doc CSWbdbdoc - berkeleydb_devel CSWbdbdevel - berkeleydb4_doc CSWbdb4-doc The following package names have been kept to match the existing naming. The package names will be adjusted at a later date with proper announcement: - berkeleydb43_devel CSWbdb43-devel - berkeleydb43_doc CSWbdb43-doc - berkeleydb44_devel CSWbdb44-devel - berkeleydb44_doc CSWbdb44-doc Should you encounter any issues please post to users@ as usual. Best regards -- Dago From phil at bolthole.com Mon Oct 19 17:43:01 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 19 Oct 2009 08:43:01 -0700 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: References: <4ADA85FA.7090506@opencsw.org> Message-ID: On Sun, Oct 18, 2009 at 9:35 AM, Maciej (Matchek) Blizinski wrote: > I got pysvn-1.7.1 to build. It's in testing. > > For the package name conflict, I suggest the following: >... > 2. Creating a new package with subversion-provided Python bindings to > subversion_py CSWsubversion-py, or something similar. Hmmm. well, to give more specifics subversion already provides multiple language bindings, such as javasvn (java language) rbsvn (ruby language) pysvn (python language) One issue here is that CSWpysnv pysvn potentially conflicts with our standard naming for python modules. Except that it doesnt technically, because python modules are normally named "py_" :-) But there is a more fundamental issue, that the subversion addons named above, should not have been abbreviated. java was not abbreviated. ruby and python should not have been either. They should really have been named rubysvn, and pythonsvn Now, as everyone knows, I am normally EXTREMELY AGAINST package renaming. But in this case, I think it both makes sense, AND will not be overly disruptive. the only thing depending on either of them, is CSWtrac. As long as that is repackaged at the same time, newly pointing to the new name, I think we can go ahead and do the rename. However, for our users' sake, I think that we should postpone reackaging of the new "pysvn", until at least a month AFTER the release of the renames have been done. That way, most people who already have trac installed, and do automatic updates, will probably have things nicely upgraded for them with no confusion. But this will still neccessitate announcements about it when released. Note to the pythonsvn and trac maintainers: To save time, please remind me, when you actually submit the packages. I have a lot to keep track of and may well forget by the time you submit them :-) From phil at bolthole.com Mon Oct 19 17:44:00 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 19 Oct 2009 08:44:00 -0700 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: References: <4ADA85FA.7090506@opencsw.org> Message-ID: Please note : this upgrade is complicated by tthe fact that normally on a pkg rename, we declare a conflict with the old name, which is then obsolete. But, since the old name of CSWpysvn will NOT be obsolete, we cannot declare a conflict to it. From phil at bolthole.com Mon Oct 19 17:45:41 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 19 Oct 2009 08:45:41 -0700 Subject: [csw-maintainers] BerkeleyDB upgrade In-Reply-To: <4C32281F-89A3-4B57-B840-699CA6795EDB@opencsw.org> References: <4C32281F-89A3-4B57-B840-699CA6795EDB@opencsw.org> Message-ID: And thank you, Dagobert, for demonstrating the RIGHT way to to important announcements: Doing a multi-post to "users" and "announce", but doing a SEPARATE email to the maintainers list :-) (and thank you also for doing the work, of course! :-) From phil at bolthole.com Mon Oct 19 19:26:14 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 19 Oct 2009 10:26:14 -0700 Subject: [csw-maintainers] caution: internal release tree tweaked Message-ID: Please note: all packages in newpkgs PRIOR to this email, have been either released, or commented on. that being said, I have just completed a bit of internal tweakage to release directory layout. This SHOULD be invisible... but wanted to give you guys a heads-up for any packages released in the next few days; please be a little extra-cautious and observant to see whether your packages make it all the way out to mirror sites cleanly within 48 hours of me saying i've publically pushed them. You guys still should copy packages to the same old newpkgs directory. As i said, this change "should be invisible" to you all ;-) From ihsan at opencsw.org Mon Oct 19 21:14:01 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Mon, 19 Oct 2009 21:14:01 +0200 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: References: Message-ID: <4ADCBA79.7050005@opencsw.org> Am 19.10.2009 17:33 Uhr, Philip Brown schrieb: >> I wrote a utility to automate the step of submitting a package to the >> release maintainer. It takes a comma-separated list of package names, >> copies the packages from the testing directory to newpkgs and formats >> an e-mail with the list of package files. >> >> Usage: submitpkg [options] > > Excellent!! we've needed this for a long time. When it's debugged > some, it should go in cswutils. Thanks for writing this. Thanks Maciej, great work. >> Any comments, thoughts or flames? > > did it HAVE to be written in python? :-( > even perl would be better. Something as basic as this, would be nice > to use without having to potentially download and install a whole new > language package. I don't see a problem here. Python comes already with Solaris 10. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From phil at bolthole.com Mon Oct 19 22:40:31 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 19 Oct 2009 13:40:31 -0700 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: <4ADCBA79.7050005@opencsw.org> References: <4ADCBA79.7050005@opencsw.org> Message-ID: On Mon, Oct 19, 2009 at 12:14 PM, Ihsan Dogan wrote: > >> >> did it HAVE to be written in python? :-( >> even perl would be better. Something as basic as this, would be nice >> to use without having to potentially download and install a whole new >> language package. > > I don't see a problem here. Python comes already with Solaris 10. > > I think it "comes with" sol9 too. But it isnt exactly part of SUNWCreq, in either 9 OR 10. perl IS, btw. From bwalton at opencsw.org Tue Oct 20 01:33:24 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 19 Oct 2009 19:33:24 -0400 Subject: [csw-maintainers] submitpkg in cswutils-1.14.5 In-Reply-To: References: <4ADCBA79.7050005@opencsw.org> Message-ID: <1255994929-sup-3@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Mon Oct 19 16:40:31 -0400 2009: > But it isnt exactly part of SUNWCreq, in either 9 OR 10. Restricting language choice for tools that are used to bootstrap makes sense. Relying on things that aren't available wouldn't get you very far. For things that already depend on CSWcommon, it should be up to the implementer to a) choose the right tool for the job and b) choose something they're comfortable with. There is no indication that python isn't the right tool for this job. Perl would be equally right, but not more so. So, in this case, Maciej's comfort level with said tool would get more weight in the selection criteria...plus, it's already done, and re-coding it serves no purpose. My 2 cents from the sidelines. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From maciej at opencsw.org Tue Oct 20 14:56:48 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 20 Oct 2009 13:56:48 +0100 Subject: [csw-maintainers] GAR: rebuilding after modifying a file in software's sources Message-ID: I've modified a source file and I want to tell gmake to rebuild the necessary binaries. I'm trying: maciej at build8s [build8s]:~/src/opencsw/pkg/cups/branches/cups-1.4.0 > gmake build [build] complete for cups. ...it says everything has been built. But it hasn't, I modified http.c and it should trigger the rebuild of some binaries. cd'ing into the source and issuing 'gmake' doesn't work: a - util.o ar: writing libcups.a gmake[1]: ranlib: Command not found gmake[1]: *** [libcups.a] Error 127 gmake[1]: *** Waiting for unfinished jobs.... gmake: *** [all] Error 1 How can I tell GAR to rebuild the source? Maciej From dam at opencsw.org Tue Oct 20 15:13:20 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 20 Oct 2009 15:13:20 +0200 Subject: [csw-maintainers] GAR: rebuilding after modifying a file in software's sources In-Reply-To: References: Message-ID: Hi Maciej, Am 20.10.2009 um 14:56 schrieb Maciej (Matchek) Blizinski: > I've modified a source file and I want to tell gmake to rebuild the > necessary binaries. I'm trying: > > maciej at build8s [build8s]:~/src/opencsw/pkg/cups/branches/cups-1.4.0 > > gmake build > [build] complete for cups. > > ...it says everything has been built. But it hasn't, I modified http.c > and it should trigger the rebuild of some binaries. > > cd'ing into the source and issuing 'gmake' doesn't work: a - util.o > ar: writing libcups.a > gmake[1]: ranlib: Command not found > gmake[1]: *** [libcups.a] Error 127 > gmake[1]: *** Waiting for unfinished jobs.... > gmake: *** [all] Error 1 > > How can I tell GAR to rebuild the source? gmake rebuild ;-) There are also remerge and repackage. Best regards -- Dago From maciej at opencsw.org Tue Oct 20 15:30:29 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 20 Oct 2009 14:30:29 +0100 Subject: [csw-maintainers] GAR: rebuilding after modifying a file in software's sources In-Reply-To: References: Message-ID: On Tue, Oct 20, 2009 at 2:13 PM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 20.10.2009 um 14:56 schrieb Maciej (Matchek) Blizinski: >> >> I've modified a source file and I want to tell gmake to rebuild the >> necessary binaries. I'm trying: >> >> maciej at build8s [build8s]:~/src/opencsw/pkg/cups/branches/cups-1.4.0 > >> gmake build >> ? ? ? [build] complete for cups. >> >> ...it says everything has been built. But it hasn't, I modified http.c >> and it should trigger the rebuild of some binaries. >> >> cd'ing into the source and issuing 'gmake' doesn't work: a - util.o >> ar: writing libcups.a >> gmake[1]: ranlib: Command not found >> gmake[1]: *** [libcups.a] Error 127 >> gmake[1]: *** Waiting for unfinished jobs.... >> gmake: *** [all] Error 1 >> >> How can I tell GAR to rebuild the source? > > gmake rebuild ;-) I've tried that already: maciej at build8s [build8s]:~/src/opencsw/pkg/cups/branches/cups-1.4.0 > gmake rebuild gmake: *** No rule to make target `rebuild'. Stop. I'm using the latest v2: maciej at build8s [build8s]:~/src/opencsw/pkg/cups/branches/cups-1.4.0 > gmake rebuild gmake: *** No rule to make target `rebuild'. Stop. maciej at build8s [build8s]:~/src/opencsw/pkg/cups/branches/cups-1.4.0 > (cd gar && svn info) Path: . URL: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/v2 Repository Root: https://gar.svn.sourceforge.net/svnroot/gar Repository UUID: d3b55034-1cff-0310-a425-aefe953e1e90 Revision: 6914 Node Kind: directory Schedule: normal From dam at opencsw.org Tue Oct 20 15:40:09 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 20 Oct 2009 15:40:09 +0200 Subject: [csw-maintainers] GAR: rebuilding after modifying a file in software's sources In-Reply-To: References: Message-ID: <1CA6E612-12C3-4508-A7F0-944D9B990D67@opencsw.org> Hi Maciej, Am 20.10.2009 um 15:30 schrieb Maciej (Matchek) Blizinski: >> gmake rebuild ;-) > > I've tried that already: Umh, my mistake. There is none. Seems like I intended but never did it. Sorry. For the moment please use gmake clean && gmake build or go to the source dir manually and issue gmake there. Would you mind opening a bug? Best regards -- Dago From maciej at opencsw.org Tue Oct 20 15:52:30 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 20 Oct 2009 14:52:30 +0100 Subject: [csw-maintainers] GAR: rebuilding after modifying a file in software's sources In-Reply-To: <1CA6E612-12C3-4508-A7F0-944D9B990D67@opencsw.org> References: <1CA6E612-12C3-4508-A7F0-944D9B990D67@opencsw.org> Message-ID: On Tue, Oct 20, 2009 at 2:40 PM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 20.10.2009 um 15:30 schrieb Maciej (Matchek) Blizinski: >>> >>> gmake rebuild ;-) >> >> I've tried that already: > > Umh, my mistake. There is none. Seems like I intended but never did it. > Sorry. For the moment please use > ?gmake clean && gmake build This one I don't want to use, because the source in work/ is a git-controlled local repository to which I'm making changes. > or go to the source dir manually and issue gmake there. This doesn't work, it says that ranlib was not found. Yes, I'll open a bug. From dam at opencsw.org Tue Oct 20 16:12:06 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 20 Oct 2009 16:12:06 +0200 Subject: [csw-maintainers] GAR: rebuilding after modifying a file in software's sources In-Reply-To: References: <1CA6E612-12C3-4508-A7F0-944D9B990D67@opencsw.org> Message-ID: <2DFDAFF3-1031-4AB5-A7C7-02E29982911E@opencsw.org> Hi Maciej, Am 20.10.2009 um 15:52 schrieb Maciej (Matchek) Blizinski: > On Tue, Oct 20, 2009 at 2:40 PM, Dagobert Michelsen > wrote: >> Hi Maciej, >> >> Am 20.10.2009 um 15:30 schrieb Maciej (Matchek) Blizinski: >>>> >>>> gmake rebuild ;-) >>> >>> I've tried that already: >> >> Umh, my mistake. There is none. Seems like I intended but never did >> it. >> Sorry. For the moment please use >> gmake clean && gmake build > > This one I don't want to use, because the source in work/ is a > git-controlled local repository to which I'm making changes. > >> or go to the source dir manually and issue gmake there. > > This doesn't work, it says that ranlib was not found. > > Yes, I'll open a bug. I see. It may be a good idea to review the whole patch-process, maybe some kind of "maintainer mode" unpacking stuff to a local git repo allowing branching, delivering patches to files/ and checking out to WORKSRC would be useful... A thing for some cold nights to come ;-) Best regards -- Dago From maciej at opencsw.org Tue Oct 20 16:23:39 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 20 Oct 2009 15:23:39 +0100 Subject: [csw-maintainers] GAR: rebuilding after modifying a file in software's sources In-Reply-To: <2DFDAFF3-1031-4AB5-A7C7-02E29982911E@opencsw.org> References: <1CA6E612-12C3-4508-A7F0-944D9B990D67@opencsw.org> <2DFDAFF3-1031-4AB5-A7C7-02E29982911E@opencsw.org> Message-ID: On Tue, Oct 20, 2009 at 3:12 PM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 20.10.2009 um 15:52 schrieb Maciej (Matchek) Blizinski: >> >> On Tue, Oct 20, 2009 at 2:40 PM, Dagobert Michelsen >> wrote: >>> >>> Hi Maciej, >>> >>> Am 20.10.2009 um 15:30 schrieb Maciej (Matchek) Blizinski: >>>>> >>>>> gmake rebuild ;-) >>>> >>>> I've tried that already: >>> >>> Umh, my mistake. There is none. Seems like I intended but never did it. >>> Sorry. For the moment please use >>> ?gmake clean && gmake build >> >> This one I don't want to use, because the source in work/ is a >> git-controlled local repository to which I'm making changes. >> >>> or go to the source dir manually and issue gmake there. >> >> This doesn't work, it says that ranlib was not found. >> >> Yes, I'll open a bug. > > I see. It may be a good idea to review the whole patch-process, > maybe some kind of "maintainer mode" unpacking stuff to a local > git repo allowing branching, delivering patches to files/ and > checking out to WORKSRC would be useful... A thing for some > cold nights to come ;-) I already have a half-broken prototype. It works, except it's hard to merge. I might start a new gar branch so you can see what my ideas are. Maciej From dam at opencsw.org Tue Oct 20 17:19:31 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 20 Oct 2009 17:19:31 +0200 Subject: [csw-maintainers] GAR: rebuilding after modifying a file in software's sources In-Reply-To: References: <1CA6E612-12C3-4508-A7F0-944D9B990D67@opencsw.org> <2DFDAFF3-1031-4AB5-A7C7-02E29982911E@opencsw.org> Message-ID: <9BD402DB-714E-460D-9973-FB28BA5D189C@opencsw.org> Hi Maciej, Am 20.10.2009 um 16:23 schrieb Maciej (Matchek) Blizinski: > On Tue, Oct 20, 2009 at 3:12 PM, Dagobert Michelsen > wrote: >> It may be a good idea to review the whole patch-process, >> maybe some kind of "maintainer mode" unpacking stuff to a local >> git repo allowing branching, delivering patches to files/ and >> checking out to WORKSRC would be useful... A thing for some >> cold nights to come ;-) > > I already have a half-broken prototype. It works, except it's hard to > merge. I might start a new gar branch so you can see what my ideas > are. Show me the code! Best regards -- Dago From maciej at opencsw.org Tue Oct 20 17:35:41 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 20 Oct 2009 16:35:41 +0100 Subject: [csw-maintainers] GAR: rebuilding after modifying a file in software's sources In-Reply-To: <9BD402DB-714E-460D-9973-FB28BA5D189C@opencsw.org> References: <1CA6E612-12C3-4508-A7F0-944D9B990D67@opencsw.org> <2DFDAFF3-1031-4AB5-A7C7-02E29982911E@opencsw.org> <9BD402DB-714E-460D-9973-FB28BA5D189C@opencsw.org> Message-ID: On Tue, Oct 20, 2009 at 4:19 PM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 20.10.2009 um 16:23 schrieb Maciej (Matchek) Blizinski: >> >> I already have a half-broken prototype. It works, except it's hard to >> merge. I might start a new gar branch so you can see what my ideas >> are. > > Show me the code! Dein Befehl ist mir Wunsch! Or the other way around, I can never remember. ;-) https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/v2-git Maciej From maciej at opencsw.org Tue Oct 20 17:48:50 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 20 Oct 2009 16:48:50 +0100 Subject: [csw-maintainers] GAR: rebuilding after modifying a file in software's sources In-Reply-To: References: <1CA6E612-12C3-4508-A7F0-944D9B990D67@opencsw.org> <2DFDAFF3-1031-4AB5-A7C7-02E29982911E@opencsw.org> <9BD402DB-714E-460D-9973-FB28BA5D189C@opencsw.org> Message-ID: On Tue, Oct 20, 2009 at 4:35 PM, Maciej (Matchek) Blizinski wrote: > https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/v2-git I think I should elaborate a little on how this is supposed to work. The idea is that the changes must survive make clean; the git repository has to be cloned somewhere outside the work/ directory. The directory to store cloned git repos needs to be defined in ~/.garrc. It should be also possible to set it per-package, because we might not want to create cloned git repos for every package we're building. In conclusion: $ grep GIT ~/.garrc ENABLE_GIT_pysvn = 1 ENABLE_GIT_pygobject = 1 GIT_DIR = /export/home/blizinski/src The first time the sources are unpacked and patched, the git repository is stored in GIT_DIR. All the following unpacks, it's going to be cloned back. It's currently being done by the means of rsync, which is generally a bad idea and I need to fix it, but I don't know how. Perhaps the git repository should be cloned back into work/ in the pre-extract stage. That's the current state of affairs. I won't be able to hack much more until the 2nd of November. Maciej From maciej at opencsw.org Tue Oct 20 18:23:30 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 20 Oct 2009 17:23:30 +0100 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: References: <4ADA85FA.7090506@opencsw.org> Message-ID: On Mon, Oct 19, 2009 at 4:44 PM, Philip Brown wrote: > Please note : this upgrade is complicated by tthe fact that normally > on a pkg rename, we declare a conflict with the old name, which is > then obsolete. > > But, since the old name of CSWpysvn will NOT be obsolete, we cannot > declare a conflict to it. I've opened a bug with the subversion package about the rename: http://www.opencsw.org/bugtrack/view.php?id=3973 An idea for the change... from the perspective of the operating system, it won't be really a rename, there is still going to be a CSWpysvn package, only with a different content. How about this: 1. Create CSWpythonsvn with the subversion-core Python bindings 2. Update CSWpysvn by putting there files from pysvn.tigris org. 3. Declare a dependency: CSWpysvn is going to depend on CSWpythonsvn 4. Trac, which depends on the subversion-core bindings will still work, because it's going to get the right files from CSWpythonsvn (required by CSWpysvn) 5. Trac will be updated to depend on CSWpythonsvn 6. After a month or so, as Phil suggested, the dependency of CSWpysvn on CSWpythonsvn will be removed. In other words: CSWtrac --> CSWpysvn --> CSWpythonsvn could be the remedy. This way, the change can be done relatively smoothly, without the potential of breaking Trac, and with the possibility to release pysvn from pysvn.tigris.org relatively quickly. Thoughts? Maciej From phil at bolthole.com Tue Oct 20 21:07:54 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 20 Oct 2009 12:07:54 -0700 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: References: <4ADA85FA.7090506@opencsw.org> Message-ID: On Tue, Oct 20, 2009 at 9:23 AM, Maciej (Matchek) Blizinski wrote: > > An idea for the change... from the perspective of the operating > system, it won't be really a rename, there is still going to be a > CSWpysvn package, only with a different content. you say "only", but that is what makes it WORSE! :-/ I have said the order and timeline of what I think is the best path to take. That still stands. From maciej at opencsw.org Tue Oct 20 22:02:50 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Tue, 20 Oct 2009 21:02:50 +0100 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: References: <4ADA85FA.7090506@opencsw.org> Message-ID: On Tue, Oct 20, 2009 at 8:07 PM, Philip Brown wrote: > On Tue, Oct 20, 2009 at 9:23 AM, Maciej (Matchek) Blizinski > wrote: >> >> An idea for the change... from the perspective of the operating >> system, it won't be really a rename, there is still going to be a >> CSWpysvn package, only with a different content. > > > you say "only", but that is what makes it WORSE! :-/ Not necessarily. We ship library packages with multiple libraries in them. We potentially could ship both subversion-core and pysvn libraries in the same package. No renaming, but merging python-subversion libraries. It's a problem equivalent to the shared library problem, which is solved already. > I have said the order and timeline of what I think is the best path to take. > That still stands. Your timeline means that submitpkg won't be able to generate changelists for $time_to_build_new_subversion_packages + one month. I'd like to operate quicker than that. Any problems with this approach? Maciej From phil at bolthole.com Tue Oct 20 22:09:19 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 20 Oct 2009 13:09:19 -0700 Subject: [csw-maintainers] pysvn and the other pysvn In-Reply-To: References: <4ADA85FA.7090506@opencsw.org> Message-ID: On Tue, Oct 20, 2009 at 1:02 PM, Maciej (Matchek) Blizinski wrote: > > Your timeline means that submitpkg won't be able to generate > changelists for $time_to_build_new_subversion_packages + one month. > I'd like to operate quicker than that. Any problems with this > approach? I've already stated my reasons. The sooner the first wave gets put in, the sooner the 1 month will be completed From skayser at opencsw.org Wed Oct 21 00:38:38 2009 From: skayser at opencsw.org (Sebastian Kayser) Date: Wed, 21 Oct 2009 00:38:38 +0200 Subject: [csw-maintainers] Anyone wants to update wxWidgets? In-Reply-To: References: <625385e30908200922j40df818cn24ef7b7bda28c609@mail.gmail.com> <1251551183-sup-4494@ntdws12.chass.utoronto.ca> <1251678005-sup-226@ntdws12.chass.utoronto.ca> <20090923.11441600.3790365392@gyor.oxdrove.co.uk> Message-ID: <4ADE3BEE.90808@opencsw.org> Maciej (Matchek) Blizinski wrote on 14.10.2009 19:27: > One more problem: It doesn't compile it on build8s, while it does on > my local machine at work. Here's what happens on build8s: > > [...] > > Looking at config.log: > > configure:27183: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest > -erroff=E_NO_EXPLICIT_TYPE_GIVEN -xO3 -xarch=v8 -fast -xstrconst > -xnolibmopt -I/opt/csw/X11/include -I/usr/X11/include > -I/usr/openwin/share/include -I/opt/csw/include -D_REENTRANT > -D_PTHREADS -D__solaris__ -D_POSIX_PTHREAD_SEMANTICS > -I/opt/csw/include/gtk-2.0 -I/opt/csw/lib/gtk-2.0/include > -I/opt/csw/include/atk-1.0 -I/opt/csw/include/cairo > -I/opt/csw/include/pango-1.0 -I/opt/csw/include/glib-2.0 > -I/opt/csw/lib/glib-2.0/include -I/opt/csw/include/pixman-1 > -I/opt/csw/include/freetype2 -I/opt/csw/include > -I/opt/csw/include/libpng12 -I/opt/csw/X11/include > -I/opt/csw/X11/include -I/usr/X11/include -I/usr/openwin/share/include > -I/opt/csw/include -xarch=v8 -L/opt/csw/lib -L/opt/csw/X11/lib > conftest.c -lm -L/opt/csw/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 > -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo > -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 > -lgthread-2.0 -lpthread -lthread -lrt -lglib-2.0 -lintl >&5 > "conftest.c", line 74: warning: statement not reached > Undefined first referenced > symbol in file > XSolarisIASetProcessInfo /usr/openwin/lib/libX11.so.4 > ld: fatal: Symbol referencing errors. No output written to conftest > > Is it related to the recent discussions about X11 libs? Is it a common > problem, and are there any common fixes? I see a similar problem with mtr [1]. $ gmake clean configure-isa-i386-gui-enable ... checking for socket... no checking for socket in -lsocket... no configure: error: No socket library found gmake[1]: *** [configure-work/build-isa-i386-gui-enable/mtr-0.75/configure] Error 1 gmake[1]: Leaving directory `/home/skayser/mgar/pkg/mtr/trunk' gmake: *** [configure-isa-i386-gui-enable] Error 2 Looking at config.log configure:6739: checking for socket configure:6795: /opt/studio/SOS11/SUNWspro/bin/cc -o conftest -xO3 -xarch=386 -I/opt/csw/include -D__solaris__ -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -I/opt/csw/include/gtk-2.0 -I/opt/csw/lib/gtk-2.0/include -I/opt/csw/include/atk-1.0 -I/opt/csw/include/cairo -I/opt/csw/include/pango-1.0 -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -I/opt/csw/include/pixman-1 -I/opt/csw/include/freetype2 -I/opt/csw/include -I/opt/csw/include/libpng12 -I/opt/csw/X11/include -I/opt/csw/include -xarch=386 -L/opt/csw/lib conftest.c -lm -ltermcap -L/opt/csw/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -lm >&5 "conftest.c", line 67: warning: statement not reached Undefined first referenced symbol in file socket conftest.o (symbol belongs to implicit dependency /lib/libsocket.so.1) XSolarisIASetProcessInfo /usr/openwin/lib/libX11.so.4 Is there some sort of LD_DEBUG way to determine what is happening here? Which lib pulls in /usr/openwin/lib/libX11.so.4 (i can't see it mentioned on the command line) and why can't it resolve the XSolarisIASetProcessInfo symbol which belongs to one of it's dependencies, libXext. $ nm -p /usr/openwin/lib/libXext.so | grep XSolarisIASetProcessInfo 0000037148 T XSolarisIASetProcessInfo $ dump -Lv /usr/openwin/lib/libX11.so.4 | grep NEEDED [1] NEEDED libXext.so.0 ... Sebastian [1]https://gar.svn.sf.net/svnroot/gar/csw/mgar/pkg/mtr/trunk/Makefile From ihsan at opencsw.org Wed Oct 21 10:48:52 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Wed, 21 Oct 2009 10:48:52 +0200 (CEST) Subject: [csw-maintainers] Wikipedia article Message-ID: Hello, I've just noticed, that there is an article about OpenCSW on Wikipedia: http://en.wikipedia.org/wiki/OpenCSW Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ http://ihsan.dogan.ch/ From maciej at opencsw.org Wed Oct 21 11:53:58 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 21 Oct 2009 10:53:58 +0100 Subject: [csw-maintainers] Wikipedia article In-Reply-To: References: Message-ID: On Wed, Oct 21, 2009 at 9:48 AM, Ihsan Dogan wrote: > Hello, > > I've just noticed, that there is an article about OpenCSW on Wikipedia: > http://en.wikipedia.org/wiki/OpenCSW Yes, and these are my contributions: http://bit.ly/3Vyhhi Maciej From maciej at opencsw.org Wed Oct 21 12:47:07 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 21 Oct 2009 11:47:07 +0100 Subject: [csw-maintainers] Buildbot In-Reply-To: <20090731184245.GC76412@bolthole.com> References: <9C6FD617-8E9C-4649-9361-4525D8A68C98@opencsw.org> <20090731164757.GB30823@bolthole.com> <20090731.18151000.1268557623@gyor.oxdrove.co.uk> <20090731184245.GC76412@bolthole.com> Message-ID: On Fri, Jul 31, 2009 at 7:42 PM, Philip Brown wrote: > On Fri, Jul 31, 2009 at 06:15:10PM +0000, James Lee wrote: >> >> Go further, just have a single entry point per project (not package) per >> version that can be run with exec. ?i.e., don't use make as the first >> step. ?You can call make from a script if you want, I suppose so too >> could one call a script from make but it's not as pure and simplistic. > > in other words, debian style, have a "build" executable.... even though 99% > of the time, the debian "executable" is a script that starts with > > #!/bin/make > > :-) > > [ie: a makefile!] Looks good to me. Are others okay with this interface? (i.e. an executable script named 'build', with no arguments) Maciej From dam at opencsw.org Wed Oct 21 13:18:10 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 21 Oct 2009 13:18:10 +0200 Subject: [csw-maintainers] Buildbot In-Reply-To: References: <9C6FD617-8E9C-4649-9361-4525D8A68C98@opencsw.org> <20090731164757.GB30823@bolthole.com> <20090731.18151000.1268557623@gyor.oxdrove.co.uk> <20090731184245.GC76412@bolthole.com> Message-ID: <94BCC288-3326-47E6-9397-091D93A8771B@opencsw.org> Hi, Am 21.10.2009 um 12:47 schrieb Maciej (Matchek) Blizinski: > On Fri, Jul 31, 2009 at 7:42 PM, Philip Brown > wrote: >> On Fri, Jul 31, 2009 at 06:15:10PM +0000, James Lee wrote: >>> >>> Go further, just have a single entry point per project (not >>> package) per >>> version that can be run with exec. i.e., don't use make as the >>> first >>> step. You can call make from a script if you want, I suppose so too >>> could one call a script from make but it's not as pure and >>> simplistic. >> >> in other words, debian style, have a "build" executable.... even >> though 99% >> of the time, the debian "executable" is a script that starts with >> >> #!/bin/make >> >> :-) >> >> [ie: a makefile!] > > Looks good to me. Are others okay with this interface? (i.e. an > executable script named 'build', with no arguments) Sure. So no more excuses for James and Peter and Phil not to be "committed" ;-) Best regards -- Dagobert From william at wbonnet.net Wed Oct 21 17:58:48 2009 From: william at wbonnet.net (William Bonnet) Date: Wed, 21 Oct 2009 17:58:48 +0200 Subject: [csw-maintainers] X11 update on test machines Message-ID: <4ADF2FB8.2010602@wbonnet.net> Hi, Several missing X11 packages have been prepared, and ready to be tested. You may have already see a few *proto packages in testing. For consistency reasons, we plan to packages versions which are coherent with the X11R7.4 release. Latest stable release from X.org (packages added after this release, thus not included at all in R7.4, may have latest version if needed). I rebuild yesterday all the proto files with the good versions, and i am planning to install these packages on testing machines to rebuild the libs which are in GAR. Does any one see a problem to this ? . I will remove currently installed proto files, and replace them by th freshly rebuild packages . Then, i will rebuild and replace each lib, moving the libs to the individual versions defined by X11R7.4 release. This will be done *only* on test machines, not build ! cheers W. From phil at bolthole.com Wed Oct 21 18:27:37 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 21 Oct 2009 09:27:37 -0700 Subject: [csw-maintainers] Anyone wants to update wxWidgets? In-Reply-To: <4ADE3BEE.90808@opencsw.org> References: <625385e30908200922j40df818cn24ef7b7bda28c609@mail.gmail.com> <1251678005-sup-226@ntdws12.chass.utoronto.ca> <20090923.11441600.3790365392@gyor.oxdrove.co.uk> <4ADE3BEE.90808@opencsw.org> Message-ID: On Tue, Oct 20, 2009 at 3:38 PM, Sebastian Kayser wrote: > Undefined ? ? ? ? ? ? ? ? ? ? ? first referenced > ?symbol ? ? ? ? ? ? ? ? ? ? ? ? ? ? in file > socket ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?conftest.o ?(symbol belongs to implicit dependency /lib/libsocket.so.1) > XSolarisIASetProcessInfo ? ? ? ? ? ?/usr/openwin/lib/libX11.so.4 > I think some of the error output got mangled somehow. THIS error output seems pretty clear, that you are missing a -lsocket. USUALLY, configs/makefiles have some clause for [detect if lsocket is needed] So doing a grep for "lsocket" in assorted configure, etc shoudl help. > Is there some sort of LD_DEBUG way to determine what is happening > here? Which lib pulls in /usr/openwin/lib/libX11.so.4 (i can't see > it mentioned on the command line) LD_DEBUG=files is usually what I use. From phil at bolthole.com Wed Oct 21 18:47:33 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 21 Oct 2009 09:47:33 -0700 Subject: [csw-maintainers] Buildbot In-Reply-To: <94BCC288-3326-47E6-9397-091D93A8771B@opencsw.org> References: <9C6FD617-8E9C-4649-9361-4525D8A68C98@opencsw.org> <20090731164757.GB30823@bolthole.com> <20090731.18151000.1268557623@gyor.oxdrove.co.uk> <20090731184245.GC76412@bolthole.com> <94BCC288-3326-47E6-9397-091D93A8771B@opencsw.org> Message-ID: On Wed, Oct 21, 2009 at 4:18 AM, Dagobert Michelsen wrote: > Hi, > > Am 21.10.2009 um 12:47 schrieb Maciej (Matchek) Blizinski: >> >>... >>> in other words, debian style, have a "build" executable.... even though >>> 99% >>> of the time, the debian "executable" is a script that starts with >>> >>> #!/bin/make >>> >>> :-) >>> >>> [ie: a makefile!] >> >> Looks good to me. Are others okay with this interface? (i.e. an >> executable script named 'build', with no arguments) > > Sure. So no more excuses for James and Peter and Phil not to be "committed" > ;-) > > well there is a bit... this needs to be written up officially, and also specify what allowable arguments to "build" are. Also, it needs to be defined which arguments are "mandatory" to support, vs which are optional. We should have a new clean thread for this. Mr. secretary are you going to handle that, or shall I? :-) From william at wbonnet.net Wed Oct 21 21:44:25 2009 From: william at wbonnet.net (William Bonnet) Date: Wed, 21 Oct 2009 21:44:25 +0200 Subject: [csw-maintainers] Updating X11 proto on test machine Message-ID: <4ADF6499.8080907@wbonnet.net> Hi I'm starting to update packages on the test machines 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 william at wbonnet.net Wed Oct 21 21:52:08 2009 From: william at wbonnet.net (William Bonnet) Date: Wed, 21 Oct 2009 21:52:08 +0200 Subject: [csw-maintainers] Updating X11 proto on test machine In-Reply-To: <4ADF6499.8080907@wbonnet.net> References: <4ADF6499.8080907@wbonnet.net> Message-ID: <4ADF6668.9030904@wbonnet.net> Hi It's done on the test8{s,x} machines 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 william at wbonnet.net Thu Oct 22 00:21:23 2009 From: william at wbonnet.net (William Bonnet) Date: Thu, 22 Oct 2009 00:21:23 +0200 Subject: [csw-maintainers] Compilation of X11 libs Message-ID: <4ADF8963.3060003@wbonnet.net> Hi I have started to rebuild X11 according to individual libs versions defined in X11R7.4 Starting tomorrow morning ( GMT 7:00AM :) ) i'll start to rebuild this on the test machine, SPARC first. So i will remove any currently installed X11 package from test8s (aka build8st) and rebuild packages one by one. Please don't really expect it to be finish beforel GMT 7:00 PM. If it is a problem for some of you please let me know. 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 Thu Oct 22 01:04:04 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Thu, 22 Oct 2009 00:04:04 +0100 Subject: [csw-maintainers] GAR: Basic custom tests for packages Message-ID: Let's suppose I wanted to write some basic checks for a package. For instance, that I expect there to be a certain file in the prototype, with such and such name and such and such attributes (ownership, permissions, etc). I guess I would do something like: TEST_SCRIPTS = custom test-custom: test code here How do I access things like the prototype, or files at the location from where they're already merged? Maciej From bwalton at opencsw.org Thu Oct 22 04:44:00 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 21 Oct 2009 22:44:00 -0400 Subject: [csw-maintainers] GAR: Basic custom tests for packages In-Reply-To: References: Message-ID: <1256179371-sup-7948@ntdws12.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Wed Oct 21 19:04:04 -0400 2009: > TEST_SCRIPTS = custom > > test-custom: > test code here I think you'd want to work with the state of things after the merge. I don't think the stuff in build-global is guaranteed to be there until after that step. I don't know if there are pre/post merge targets though. HTH -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From daniel at opencsw.org Thu Oct 22 08:25:31 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Thu, 22 Oct 2009 07:25:31 +0100 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4ADFF85B.1040608@cmi.univ-mrs.fr> References: <4ADF312E.8050403@cmi.univ-mrs.fr> <4ADF333D.7010105@opencsw.org> <4ADF36BE.8000307@cmi.univ-mrs.fr> <4ADF378E.50108@opencsw.org> <4ADF3852.2060303@cmi.univ-mrs.fr> <4ADF39A6.7050702@opencsw.org> <4ADF3A08.5030900@cmi.univ-mrs.fr> <4ADF3D02.60207@opencsw.org> <4ADF3DAB.6030004@cmi.univ-mrs.fr> <4ADF48B7.7030200@opencsw.org> <4ADFF85B.1040608@cmi.univ-mrs.fr> Message-ID: <4ADFFADB.8010201@opencsw.org> gerard wrote: > hello daniel, > i'm trying to install ganglia_gmetad into a non global zone on > opensolaris machine (os2008.11), and here are the problems: > - it installs gmond (i never required it) gmond is not required for gmetad to work properly - however, - most people do want the gmond agent on their gmetad host anyway - the default configuration I have provided assumes that a gmond instance is running on the same host as the gmetad, this allows the Ganglia packages to work immediately with no manual configuration effort > - gmond failed to start: > [ Oct 22 07:33:48 Executing start method > ("/var/opt/csw/svc/method/svc-cswgmond start"). ] > ioctl error: No such device or address > [ Oct 22 07:33:48 Method "start" exited with status 0. ] > [ Oct 22 07:33:48 Stopping because all processes in service exited. ] > [ Oct 22 07:33:48 Executing stop method > ("/var/opt/csw/svc/method/svc-cswgmond stop"). ] > [ Oct 22 07:33:48 Method "stop" exited with status 0. ] > [ Oct 22 07:33:48 Restarting too quickly, changing state to maintenance. ] > > The install occurs in a non-global zone, is it forbidden? I haven't personally tested in zones, I know someone else who has tested it and found it doesn't work, the agent needs to be tweaked a little bit > if i want to unstall CSWgangliaagent: > bash-3.2# pkgrm CSWgangliaagent > ... > The package depends on the package > currently being removed. > Dependency checking failed. see above note about dependency > After finishing the install (ganglia_gmetad and ganglia_web), the web > page says that the host monitored is up, but it doesn't display any image!? > there are no errors in apache logs, but the web page at the url: > http://www2/ganglia/graph.php?g=load_report&z=large&c=latp&m=load_one&r=day&s=descending&hc=4&mc=2&st=1256191348 > Have you modified the configuration files, or are you using the configuration files I provide? What is the data_source line in gmetad.conf? Do any of the Ganglia pages work? > displays the following message: > The image > "http://www2/ganglia/graph.php?g=load_report&z=large&c=latp&m=load_one&r=day&s=descending&hc=4&mc=2&st=1256191348" > cannot be displayed, because it contains errors. Try and wget that URL to a file, and look at what is in the file - maybe PHP is spitting out error messages instead of a PNG file > I don't understand what's happen, because with my old releases of > ganglia, i never encountered these problems, only problems with stability. > As i said previously, i'm not using apache from CSW, but apache2 bundled > with the OS (imho, it's anot a good idea to install CSWapache2 when > apache is delivered with the OS). So the only thing i did to configure > the ganglia web is: > - cd /etc/apache2/2.2/conf.d/ > - ln -s /opt/csw/apache2/etc/extra/httpd-ganglia.conf > - svcadm disable cswapache2; svcadm restart apache22 That should probably work, but do make sure your apache2 has PHP support From dam at opencsw.org Thu Oct 22 10:12:02 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 22 Oct 2009 10:12:02 +0200 Subject: [csw-maintainers] GAR: Basic custom tests for packages In-Reply-To: <1256179371-sup-7948@ntdws12.chass.utoronto.ca> References: <1256179371-sup-7948@ntdws12.chass.utoronto.ca> Message-ID: <242BF313-F6AA-492A-BCAE-2F4FF1498BC9@opencsw.org> Hi Maciej, hi Ben, Am 22.10.2009 um 04:44 schrieb Ben Walton: > Am 22.10.2009 um 01:04 schrieb Maciej (Matchek) Blizinski: >> Let's suppose I wanted to write some basic checks for a package. For >> instance, that I expect there to be a certain file in the prototype, >> with such and such name and such and such attributes (ownership, >> permissions, etc). I guess I would do something like: >> >> TEST_SCRIPTS = custom >> >> test-custom: >> test code here >> >> How do I access things like the prototype, or files at the location >> from where they're already merged? > > I think you'd want to work with the state of things after the merge. > I don't think the stuff in build-global is guaranteed to be there > until after that step. I don't know if there are pre/post merge > targets though. Yes. Because the normal cycle for a software is configure compile test install the procedure is the same in GAR. Now to your questions: >> For instance, that I expect there to be a certain file in the >> prototype, >> with such and such name and such and such attributes (ownership, >> permissions, etc) The prototype (if dynamic) is built during 'package' and there is currently no hook in-between after dynamic creation of the packaging source files and the package creation. You could check after package-creation in post-package. >> How do I access things like the prototype, or files at the location >> from where they're already merged? From the global modulation the prototype can be accessed as $(WORKDIR)/prototype and the package specific prototypes as $(WORKDIR)/CSWmypkg.prototype The merge location is available during global or specific modulations as $(PKGROOT). I suggest you write your test as post-package to ensure it has been built correctly. However, if it proves useful we could also insert another step before package creation like pkgverify-CSWmypkg: Best regards -- Dago From phil at bolthole.com Thu Oct 22 18:38:43 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 22 Oct 2009 09:38:43 -0700 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion Message-ID: Ok, so we have previously had the issue raised, of a standard api for builds, to allow things to be checked into our subversion tree, that do NOT use the gar build system. I have now taken a step towards getting this official, by writing up the following: http://sourceforge.net/apps/trac/gar/wiki/RawAPI Please note that the prior suggestion on the mailing list, was to have the top entrypoint be "build". However, in order to avoid potential conflicts with "upstream", yet still keep it relatively short, I thought we should call it "cswbuild". I think the rest is fairly self-explanitory and obvious. There are a few things that most definately should be discussed. One is of course, if there are objections to that name. Another, is whether the "mandatory support" section is too small. Another, is the issue of "where does the result go"? I am not familiar with how "gar" does it. Perhaps people who are already familiar with gar, will suggest good ways to make the two somewhat consistent, while at the same time, resisting the urge to try to turn this into gar ;-) Please note, that the overall goal of this, is to encourage people whose source code is not in subversion, to migrate it into subversion with a minimum of change. Therefore, people in that category are the ones most strongly encouraged to take part in this discussion. From ihsan at opencsw.org Fri Oct 23 14:10:52 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Fri, 23 Oct 2009 14:10:52 +0200 (CEST) Subject: [csw-maintainers] Maintenance on the web & mail server Message-ID: <54eb55ed7972cd83d20154f64d9f7e74.squirrel@mail.opencsw.org> Hello, Tomorrow afternoon I will upgrade the T2000 to the latest Solaris version and migrate the root filesystem to ZFS. During this time mail and web services will be sporadically not available. Start: Saturday 24. October 2009, 10:00 UTC End: Saturday 24. October 2009, 16:00 UTC Please make sure that you are logged out (IMAP & SSH) at that time. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ http://ihsan.dogan.ch/ From maciej at opencsw.org Fri Oct 23 14:44:28 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 23 Oct 2009 13:44:28 +0100 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: References: Message-ID: On Thu, Oct 22, 2009 at 5:38 PM, Philip Brown wrote: > Ok, so we have previously had the issue raised, of a standard api for > builds, to allow things to be checked into our subversion tree, that > do NOT use the gar build system. > > I have now taken a step towards getting this official, by writing up > the following: > > http://sourceforge.net/apps/trac/gar/wiki/RawAPI Thanks for doing that! > Please note that the prior suggestion on the mailing list, was to have > the top entrypoint be "build". However, in order to avoid potential > conflicts with "upstream", yet still keep it relatively short, I > thought we should call it "cswbuild". Looks good to me. > I think the rest is fairly self-explanitory and obvious. There are a > few things that most definately should be discussed. > One is of course, if there are objections to that name. > Another, is whether the "mandatory support" section is too small. I that the main mandatory requirement should be that the packages which are sent to the release manager must be built using this api, on a clean filesystem, on the buildfarm: svn co http://repo-url/pkg/foo cd foo ./cswbuild > Another, is the issue of "where does the result go"? A couple of options: - the same directory as the script - a subdirectory with a standard name - a directory specified in an environment variable - a directory specified in a configuration file on disk > I am not familiar with how "gar" does it. Perhaps people who are > already familiar with gar, will suggest good ways to make the two > somewhat consistent, while at the same time, resisting the urge to try > to turn this into gar ;-) It's specified in ~/.garrc, I don't think it's a good location for the general solution. Perhaps a more general configuration file in the home directory would do the trick? > Please note, that the overall goal of this, is to encourage people > whose source code is not in subversion, to migrate it into subversion > with a minimum of change. > Therefore, people in that category are the ones most strongly > encouraged to take part in this discussion. Are there any other build systems in use in our project? If so, is their source code publicly available? Maciej From phil at bolthole.com Fri Oct 23 17:09:54 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 23 Oct 2009 08:09:54 -0700 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: References: Message-ID: On Fri, Oct 23, 2009 at 5:44 AM, Maciej (Matchek) Blizinski wrote: > On Thu, Oct 22, 2009 at 5:38 PM, Philip Brown wrote: >> >> Another, is the issue of "where does the result go"? >> I am not familiar with how "gar" does it. Perhaps people who are >> already familiar with gar, will suggest good ways to make the two >> somewhat consistent, while at the same time, resisting the urge to try >> to turn this into gar ;-) > > It's specified in ~/.garrc, I don't think it's a good location for the > general solution. what's the default, though? From maciej at opencsw.org Fri Oct 23 17:27:43 2009 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 23 Oct 2009 16:27:43 +0100 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: References: Message-ID: On Fri, Oct 23, 2009 at 4:09 PM, Philip Brown wrote: > On Fri, Oct 23, 2009 at 5:44 AM, Maciej (Matchek) Blizinski > wrote: >> On Thu, Oct 22, 2009 at 5:38 PM, Philip Brown wrote: >>> >>> Another, is the issue of "where does the result go"? >>> I am not familiar with how "gar" does it. Perhaps people who are >>> already familiar with gar, will suggest good ways to make the two >>> somewhat consistent, while at the same time, resisting the urge to try >>> to turn this into gar ;-) >> >> It's specified in ~/.garrc, I don't think it's a good location for the >> general solution. > > what's the default, though? There's no default; you're supposed to create your own ~/.garrc, and the sample file contains: ${HOME}/staging/build-$(date '+%d.%b.%Y') I prefer ISO standards for dates, so I use: ${HOME}/staging/build-$(date '+%Y-%m-%d') (It sorts better.) Maciej From phil at bolthole.com Fri Oct 23 18:48:06 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 23 Oct 2009 09:48:06 -0700 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: References: Message-ID: On Fri, Oct 23, 2009 at 8:27 AM, Maciej (Matchek) Blizinski wrote: > > There's no default; you're supposed to create your own ~/.garrc, and > the sample file contains: > > ${HOME}/staging/build-$(date '+%d.%b.%Y') >[...] > I prefer ISO standards for dates[(it builds better)] definately :-) Hmmm. the non-deterministic nature of that, would make it slightly difficult to have any kind of automated, "Go autobuild 10 packages and add them" script at a customer site. How many people are using something else there, and if so, what? From bwalton at opencsw.org Fri Oct 23 18:59:38 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 23 Oct 2009 12:59:38 -0400 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: References: Message-ID: <1256317003-sup-428@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Oct 23 12:48:06 -0400 2009: > How many people are using something else there, and if so, what? I use ~/staging without any sub structure as I found that cumbersome. Due to the date boundary I often get files with different names than I expect and having the build- directory also have a different name made my tab completion harder if I hadn't cleaned up lately. I'm 100% open to changing my settings to an agreed upon location, or, even better, having GAR set the value irrespective of my local choice. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mwatters at opencsw.org Fri Oct 23 18:59:59 2009 From: mwatters at opencsw.org (Mike Watters) Date: Fri, 23 Oct 2009 11:59:59 -0500 Subject: [csw-maintainers] raw "build" api for our subversion tree now up for discussion In-Reply-To: References: Message-ID: <4AE1E10F.1070800@opencsw.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philip Brown wrote: > On Fri, Oct 23, 2009 at 8:27 AM, Maciej (Matchek) Blizinski > wrote: >> There's no default; you're supposed to create your own ~/.garrc, and >> the sample file contains: >> >> ${HOME}/staging/build-$(date '+%d.%b.%Y') >> [...] >> I prefer ISO standards for dates[(it builds better)] > > definately :-) > > Hmmm. the non-deterministic nature of that, would make it slightly > difficult to have any kind of automated, > "Go autobuild 10 packages and add them" > script at a customer site. > > How many people are using something else there, and if so, what? > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers Here is mine... I dropped the date as the package has a time stamp in the name. mwatters at login:~ $ cat .garring SPKG_PACKAGER = Mike Watters SPKG_EMAIL = mwatters at opencsw.org SPKG_EXPORT = $(HOME)/newpkgs/$(GARNAME) SPKG_SPOOLDIR = $(HOME)/spool/$(GAROSREL)-$(GARCH) GARCHIVEDIR = $(HOME)/src - -- ~Mike "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." --> Albert Einstein 1879 - 1955 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrh4Q4ACgkQLrhmsXMSLxcoXQCgtepXN1YKQoeEfVNpQ5+PCg6W fZYAnRqTqZogwB0Go1xASFA3d9rcSVWK =uCzD -----END PGP SIGNATURE----- From ihsan at opencsw.org Sat Oct 24 19:47:12 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sat, 24 Oct 2009 19:47:12 +0200 Subject: [csw-maintainers] Maintenance on the web & mail server In-Reply-To: <54eb55ed7972cd83d20154f64d9f7e74.squirrel@mail.opencsw.org> References: <54eb55ed7972cd83d20154f64d9f7e74.squirrel@mail.opencsw.org> Message-ID: <4AE33DA0.9010203@opencsw.org> Thanks for the patience. Everything is up and running again. Am 23.10.2009 14:10 Uhr, Ihsan Dogan schrieb: > Hello, > > Tomorrow afternoon I will upgrade the T2000 to the latest Solaris version > and migrate the root filesystem to ZFS. During this time mail and web > services will be sporadically not available. > > Start: Saturday 24. October 2009, 10:00 UTC > End: Saturday 24. October 2009, 16:00 UTC > > Please make sure that you are logged out (IMAP & SSH) at that time. > > > > Ihsan > -- ihsan at dogan.ch http://blog.dogan.ch/ From ghenry at cmi.univ-mrs.fr Thu Oct 22 08:14:51 2009 From: ghenry at cmi.univ-mrs.fr (gerard) Date: Thu, 22 Oct 2009 08:14:51 +0200 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4ADF48B7.7030200@opencsw.org> References: <4ADF312E.8050403@cmi.univ-mrs.fr> <4ADF333D.7010105@opencsw.org> <4ADF36BE.8000307@cmi.univ-mrs.fr> <4ADF378E.50108@opencsw.org> <4ADF3852.2060303@cmi.univ-mrs.fr> <4ADF39A6.7050702@opencsw.org> <4ADF3A08.5030900@cmi.univ-mrs.fr> <4ADF3D02.60207@opencsw.org> <4ADF3DAB.6030004@cmi.univ-mrs.fr> <4ADF48B7.7030200@opencsw.org> Message-ID: <4ADFF85B.1040608@cmi.univ-mrs.fr> hello daniel, i'm trying to install ganglia_gmetad into a non global zone on opensolaris machine (os2008.11), and here are the problems: - it installs gmond (i never required it) - gmond failed to start: [ Oct 22 07:33:48 Executing start method ("/var/opt/csw/svc/method/svc-cswgmond start"). ] ioctl error: No such device or address [ Oct 22 07:33:48 Method "start" exited with status 0. ] [ Oct 22 07:33:48 Stopping because all processes in service exited. ] [ Oct 22 07:33:48 Executing stop method ("/var/opt/csw/svc/method/svc-cswgmond stop"). ] [ Oct 22 07:33:48 Method "stop" exited with status 0. ] [ Oct 22 07:33:48 Restarting too quickly, changing state to maintenance. ] The install occurs in a non-global zone, is it forbidden? if i want to unstall CSWgangliaagent: bash-3.2# pkgrm CSWgangliaagent ... The package depends on the package currently being removed. Dependency checking failed. After finishing the install (ganglia_gmetad and ganglia_web), the web page says that the host monitored is up, but it doesn't display any image!? there are no errors in apache logs, but the web page at the url: http://www2/ganglia/graph.php?g=load_report&z=large&c=latp&m=load_one&r=day&s=descending&hc=4&mc=2&st=1256191348 displays the following message: The image "http://www2/ganglia/graph.php?g=load_report&z=large&c=latp&m=load_one&r=day&s=descending&hc=4&mc=2&st=1256191348" cannot be displayed, because it contains errors. I don't understand what's happen, because with my old releases of ganglia, i never encountered these problems, only problems with stability. As i said previously, i'm not using apache from CSW, but apache2 bundled with the OS (imho, it's anot a good idea to install CSWapache2 when apache is delivered with the OS). So the only thing i did to configure the ganglia web is: - cd /etc/apache2/2.2/conf.d/ - ln -s /opt/csw/apache2/etc/extra/httpd-ganglia.conf - svcadm disable cswapache2; svcadm restart apache22 thanks in advance for help, gerard From ghenry at cmi.univ-mrs.fr Thu Oct 22 16:33:19 2009 From: ghenry at cmi.univ-mrs.fr (Gerard Henry) Date: Thu, 22 Oct 2009 16:33:19 +0200 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4ADFFADB.8010201@opencsw.org> References: <4ADF312E.8050403@cmi.univ-mrs.fr> <4ADF333D.7010105@opencsw.org> <4ADF36BE.8000307@cmi.univ-mrs.fr> <4ADF378E.50108@opencsw.org> <4ADF3852.2060303@cmi.univ-mrs.fr> <4ADF39A6.7050702@opencsw.org> <4ADF3A08.5030900@cmi.univ-mrs.fr> <4ADF3D02.60207@opencsw.org> <4ADF3DAB.6030004@cmi.univ-mrs.fr> <4ADF48B7.7030200@opencsw.org> <4ADFF85B.1040608@cmi.univ-mrs.fr> <4ADFFADB.8010201@opencsw.org> Message-ID: <4AE06D2F.5030101@cmi.univ-mrs.fr> Daniel Pocock wrote: > > I haven't personally tested in zones, I know someone else who has tested > it and found it doesn't work, the agent needs to be tweaked a little bit > TRying to install all things in a non global zone on a sparc machine: Installing class ... Creating service script in /var/opt/csw/svc/method/svc-cswgmond ... ln: cannot create /var/opt/csw/svc/method/svc-cswgmond: No such file or directory chmod: WARNING: can't access /var/opt/csw/svc/method/svc-cswgmond chown: /var/opt/csw/svc/method/svc-cswgmond: No such file or directory Creating manifest ... egrep: can't open /var/opt/csw/svc/method/svc-cswgmond egrep: can't open /var/opt/csw/svc/method/svc-cswgmond Configuring service in SMF ... CSWgangliaagent is using Service Management Facility. The FMRI is svc:/network/cswgmond:default Enabling svc:/network/cswgmond ... ERROR: attribute verification of failed pathname does not exist unable to create symbolic link to [ verifying class ] Installation of was successful. > > Have you modified the configuration files, or are you using the > configuration files I provide? > the files are slihty modified, just the name of the machnie > What is the data_source line in gmetad.conf? > data_source "latp" 147.94.64.119 147.94.64.10 > Do any of the Ganglia pages work? > yes, all the pages except the graphics >> displays the following message: >> The image >> "http://www2/ganglia/graph.php?g=load_report&z=large&c=latp&m=load_one&r=day&s=descending&hc=4&mc=2&st=1256191348" >> cannot be displayed, because it contains errors. > > Try and wget that URL to a file, and look at what is in the file - maybe > PHP is spitting out error messages instead of a PNG file > >> I don't understand what's happen, because with my old releases of >> ganglia, i never encountered these problems, only problems with >> stability. >> As i said previously, i'm not using apache from CSW, but apache2 >> bundled with the OS (imho, it's anot a good idea to install CSWapache2 >> when apache is delivered with the OS). So the only thing i did to >> configure the ganglia web is: >> - cd /etc/apache2/2.2/conf.d/ >> - ln -s /opt/csw/apache2/etc/extra/httpd-ganglia.conf >> - svcadm disable cswapache2; svcadm restart apache22 > > That should probably work, but do make sure your apache2 has PHP support so to be sure, i re-install ganglia-web on another machine, a sparc, and into a non global zone, same proble as above: Installing class ... Creating service script in /var/opt/csw/svc/method/svc-cswgmetad ... ln: cannot create /var/opt/csw/svc/method/svc-cswgmetad: No such file or directory chmod: WARNING: can't access /var/opt/csw/svc/method/svc-cswgmetad chown: /var/opt/csw/svc/method/svc-cswgmetad: No such file or directory Creating manifest ... egrep: can't open /var/opt/csw/svc/method/svc-cswgmetad egrep: can't open /var/opt/csw/svc/method/svc-cswgmetad Configuring service in SMF ... CSWgangliagmetad is using Service Management Facility. The FMRI is svc:/network/cswgmetad:default Enabling svc:/network/cswgmetad ... ERROR: attribute verification of failed pathname does not exist unable to create symbolic link to [ verifying class ] Installation of was successful. gerard From dam at opencsw.org Sun Oct 25 21:07:21 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 25 Oct 2009 21:07:21 +0100 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> Message-ID: Hi Aubrey, Anfang der weitergeleiteten E-Mail: > Von: Aubrey Li > Datum: 25. Oktober 2009 13:22:02 MEZ > An: Dagobert Michelsen , "Maciej (Matchek) > Blizinski" > Betreff: Fwd: checkpkg problem on opensolaris distribution > > Hi Dago, > > It looks like I'm not on the maintainers' list, and my mail account > aubrey at opencsw.org is not valid any longer, could you please help > me to send this mail out? Fwd'ing to Ihsan. Aubrey has already contributed packages and had an account in the past. Ihsan: Would you mind having a look? Aubrey: To become a permanent member of the OpenCSW project you must apply for membership by writing to board at lists.opencsw.org. The current list of members can be seen at The bylaws can be read at > ---------- Forwarded message ---------- > From: Aubrey Li > Date: Sun, Oct 25, 2009 at 8:14 PM > Subject: checkpkg problem on opensolaris distribution > To: internal list for the CSW maintainers > Aubrey: You have posted to the wrong address. The new address is maintainers at lists.opencsw.org ;-) > I'm not sure how many developers are using OpenSolaris-snvXXX > distribution. > > I run into the following error when I try to build a new package by > "gmake package" > ==================================================== > ........snip........ > Examining 'depend' file > system CSWcommon common - common files and dirs for CSW packages > Cannot find package providing libc.so.1. Storing for delayed > validation. > Cannot find package providing libfl.so.1. Storing for delayed > validation. > SUGGESTION: you may want to add some or all of the following as > depends: > (Feel free to ignore SUNW or SPRO packages) >> CSWncurses > > Doing late evaluations of package library dependencies. > ERROR: Couldn't find a package providing libc.so.1 > gmake: *** [pkgcheck-CSWcscope] Error 2 > ===================================================== > After some investigation, I found the root cause is, checkpkg is using > the package > installation file /var/sadm/install/contents, which is not maintained > on opensolaris > (indiana) distribution. > > Can we enhance this script to support IPS package system? > I have a quick idea similarly like the following patch, > > Any thoughts? I really enjoy seeing progress towards OpenSolaris / IPS support. Hopefully the farm will soon be upgraded to OSOL build hosts. Ben: You have added the current checkpkg logic, would you consider adding the patch as safe? > ============================================== > --- checkpkg 2009-10-25 19:56:04.191980886 +0800 > +++ checkpkg.ips 2009-10-25 19:52:37.856050429 +0800 > @@ -547,11 +547,27 @@ > pkg=`echo $ldep | nawk '{print $2}'` > /usr/xpg4/bin/grep -q "[/=]$lib[ =]" $SETLIBS > if [ $? -ne 0 ]; then > - errmsg "Couldn't find a package providing $lib" > + print "Couldn't find a SVR4 package providing $lib, try > IPS pkg later" > + echo "$lib" >> $SETLIBS.svr4.missing > else > print "A package in the set being evaluated provides $lib" > fi > done < $SETLIBS.missing > fi > > +print "" > + > +if [ -s $SETLIBS.svr4.missing ]; then > + print "Doing late evaluation of IPS package library > dependencies." > + while read idep; do > + BUILD=`uname -v | sed s/snv_//` > + pkg search $idep | grep $BUILD > + if [ $? -ne 0 ]; then > + errmsg "Couldn't find a package providing $idep" > + else > + print "A package in the set being evaluated provides > $idep" > + fi > + done < $SETLIBS.svr4.missing > +fi > + > cleanupset Best regards -- Dago From ihsan at opencsw.org Sun Oct 25 22:46:52 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Sun, 25 Oct 2009 22:46:52 +0100 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution In-Reply-To: References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> Message-ID: <4AE4C74C.5050100@opencsw.org> Hello Aubrey, Am 25.10.2009 21:07 Uhr, Dagobert Michelsen schrieb: >> It looks like I'm not on the maintainers' list, and my mail account >> aubrey at opencsw.org is not valid any longer, could you please help >> me to send this mail out? > > Fwd'ing to Ihsan. Aubrey has already contributed packages and had > an account in the past. > > Ihsan: Would you mind having a look? Your Account is still active. What exactly does not work? Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From bwalton at opencsw.org Sun Oct 25 23:25:34 2009 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 25 Oct 2009 18:25:34 -0400 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution In-Reply-To: References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> Message-ID: <1256504000-sup-6703@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Sun Oct 25 16:07:21 -0400 2009: A quick persual of the patch looks ok, but I'd have to actually test it. I don't use opensolaris at all and at this time have no plans to... Also, I'm working on a full replacement for the current checkpkg. My replacement isn't ready yet, but I'd be happy to have this type of stuff built in from the ground up. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From aubrey at opencsw.org Mon Oct 26 03:43:27 2009 From: aubrey at opencsw.org (Aubrey Li) Date: Mon, 26 Oct 2009 10:43:27 +0800 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution In-Reply-To: <1256504000-sup-6703@ntdws12.chass.utoronto.ca> References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> <1256504000-sup-6703@ntdws12.chass.utoronto.ca> Message-ID: <6d6a94c50910251943i3278fb0cq85d0330d52f92497@mail.gmail.com> On Mon, Oct 26, 2009 at 6:25 AM, Ben Walton wrote: > Excerpts from Dagobert Michelsen's message of Sun Oct 25 16:07:21 -0400 2009: > > A quick persual of the patch looks ok, but I'd have to actually test > it. ?I don't use opensolaris at all and at this time have no plans > to... > > Also, I'm working on a full replacement for the current checkpkg. ?My > replacement isn't ready yet, but I'd be happy to have this type of > stuff built in from the ground up. Thanks to take OSOL distro into account. -Aubrey > > -Ben > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu > Contact me to arrange for a CAcert assurance meeting. > From dam at opencsw.org Mon Oct 26 06:12:10 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 26 Oct 2009 06:12:10 +0100 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution In-Reply-To: <1256504000-sup-6703@ntdws12.chass.utoronto.ca> References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> <1256504000-sup-6703@ntdws12.chass.utoronto.ca> Message-ID: Hi Ben, Am 25.10.2009 um 23:25 schrieb Ben Walton: > A quick persual of the patch looks ok, but I'd have to actually test > it. I don't use opensolaris at all and at this time have no plans > to... > > Also, I'm working on a full replacement for the current checkpkg. My > replacement isn't ready yet, but I'd be happy to have this type of > stuff built in from the ground up. Sure, but as the patch only adds another step after it otherwise would have failed I guess it would be safe to apply until the new version is ready, yes? Best regards -- Dago From bwalton at opencsw.org Mon Oct 26 11:27:33 2009 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 26 Oct 2009 06:27:33 -0400 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution In-Reply-To: References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> <1256504000-sup-6703@ntdws12.chass.utoronto.ca> Message-ID: <1256552824-sup-8760@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Mon Oct 26 01:12:10 -0400 2009: > Sure, but as the patch only adds another step after it otherwise > would have failed I guess it would be safe to apply until the > new version is ready, yes? Yes, I'm ok with it. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From aubrey at opencsw.org Mon Oct 26 13:44:08 2009 From: aubrey at opencsw.org (Aubrey Li) Date: Mon, 26 Oct 2009 20:44:08 +0800 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution In-Reply-To: <1256552824-sup-8760@ntdws12.chass.utoronto.ca> References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> <1256504000-sup-6703@ntdws12.chass.utoronto.ca> <1256552824-sup-8760@ntdws12.chass.utoronto.ca> Message-ID: <6d6a94c50910260544w286f80bbyea6ac7d87e27a30b@mail.gmail.com> On Mon, Oct 26, 2009 at 6:27 PM, Ben Walton wrote: > Excerpts from Dagobert Michelsen's message of Mon Oct 26 01:12:10 -0400 2009: > >> Sure, but as the patch only adds another step after it otherwise >> would have failed I guess it would be safe to apply until the >> new version is ready, yes? > > Yes, I'm ok with it. > > Thanks > -Ben please refine the patch and verify it on your side, in case I did something wrong, ;-) Thanks, -Aubrey From ihsan at opencsw.org Mon Oct 26 16:03:06 2009 From: ihsan at opencsw.org (Ihsan Dogan) Date: Mon, 26 Oct 2009 16:03:06 +0100 (CET) Subject: [csw-maintainers] Apache 2 Package In-Reply-To: <4ADB45B0.1000207@opencsw.org> References: <4ADB45B0.1000207@opencsw.org> Message-ID: <6766af69195aabae43282f90adac196a.squirrel@mail.opencsw.org> > The Apache 2 package needs to be reworked and I can't find any > additional ressources at this time. Would be great if someone could take > over this package. Still no volunteer for this package? Ihsan -- ihsan at dogan.ch http://ihsan.dogan.ch/ From phil at bolthole.com Mon Oct 26 17:09:48 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 26 Oct 2009 09:09:48 -0700 Subject: [csw-maintainers] ganglia unofficial 3.1.3 RC in testing In-Reply-To: <4AE06D2F.5030101@cmi.univ-mrs.fr> References: <4ADF312E.8050403@cmi.univ-mrs.fr> <4ADF3852.2060303@cmi.univ-mrs.fr> <4ADF39A6.7050702@opencsw.org> <4ADF3A08.5030900@cmi.univ-mrs.fr> <4ADF3D02.60207@opencsw.org> <4ADF3DAB.6030004@cmi.univ-mrs.fr> <4ADF48B7.7030200@opencsw.org> <4ADFF85B.1040608@cmi.univ-mrs.fr> <4ADFFADB.8010201@opencsw.org> <4AE06D2F.5030101@cmi.univ-mrs.fr> Message-ID: On Thu, Oct 22, 2009 at 7:33 AM, Gerard Henry wrote: > > Creating service script in /var/opt/csw/svc/method/svc-cswgmond ... > ln: cannot create /var/opt/csw/svc/method/svc-cswgmond: No such file or > directory So, the questions I would ask are: 1. where is it trying to ln FROM 2. does the directory /var/opt/csw/svc/method/ exist in that case? From phil at bolthole.com Mon Oct 26 17:14:09 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 26 Oct 2009 09:14:09 -0700 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution In-Reply-To: References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> Message-ID: > >> Can we enhance this script to support IPS package system? >> I have a quick idea similarly like the following patch, >>... I think that only really makes sense, when we start distributing packages in IPS format. at which point, we should have a related-but-separate utility, "checkips", I think :-) checkpkg is for creating packages. Right now, people should NOT be creating OpenCSW packages on opensolaris. Only Solaris(tm)(r)(...) For someone who wishes to tinker, but only runs opensolaris at the moment.. it should be easy enough to set up a solaris zone? They could use the "branded zone" type stuff, and install solaris 9 zone, I would think. From schwindt at dfki.uni-kl.de Mon Oct 26 17:14:38 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Mon, 26 Oct 2009 17:14:38 +0100 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: Your message of "Mon, 26 Oct 2009 16:03:06 +0100." <6766af69195aabae43282f90adac196a.squirrel@mail.opencsw.org> Message-ID: <200910261614.n9QGEcOv011294@dfki.uni-kl.de> > > > The Apache 2 package needs to be reworked and I can't find any > > additional ressources at this time. Would be great if someone could take > > over this package. > > Still no volunteer for this package? I would - but this would mean I needed much help on gar. As this would consume a larger amount of time as doing it yourself we have a deadlock .( Nicolai From dam at opencsw.org Mon Oct 26 17:35:02 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 26 Oct 2009 17:35:02 +0100 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: <200910261614.n9QGEcOv011294@dfki.uni-kl.de> References: <200910261614.n9QGEcOv011294@dfki.uni-kl.de> Message-ID: Hi Nicolai, Am 26.10.2009 um 17:14 schrieb Nicolai Schwindt: >>> The Apache 2 package needs to be reworked and I can't find any >>> additional ressources at this time. Would be great if someone >>> could take >>> over this package. >> >> Still no volunteer for this package? > > I would - but this would mean I needed much help on gar. > As this would consume a larger amount of time as doing it yourself > we have a deadlock .( It is not that difficult and the package is already in GAR and you get all the help from maintainers@ for sure :-) Best regards -- Dago From trygvis at opencsw.org Mon Oct 26 18:47:38 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Mon, 26 Oct 2009 18:47:38 +0100 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: References: <200910261614.n9QGEcOv011294@dfki.uni-kl.de> Message-ID: <4AE5E0BA.9000109@opencsw.org> Dagobert Michelsen wrote: > Hi Nicolai, > > Am 26.10.2009 um 17:14 schrieb Nicolai Schwindt: >>>> The Apache 2 package needs to be reworked and I can't find any >>>> additional ressources at this time. Would be great if someone could >>>> take >>>> over this package. >>> >>> Still no volunteer for this package? >> >> I would - but this would mean I needed much help on gar. >> As this would consume a larger amount of time as doing it yourself >> we have a deadlock .( > > It is not that difficult and the package is already in GAR and you > get all the help from maintainers@ for sure :-) There's also the #opencsw IRC channel, see info on out frontpage. -- Trygve From schwindt at dfki.uni-kl.de Mon Oct 26 19:54:42 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Mon, 26 Oct 2009 19:54:42 +0100 Subject: [csw-maintainers] pkginstall question Message-ID: <200910261854.n9QIsg6r014895@dfki.uni-kl.de> The errors on install packages I mentioned a while age still exist. Maybe now someone has an idea. My scenario : fresh install of solaris 10 x86 10u8 pkg-get -i clamav - gives : ... [ verifying class ] Copying sample config to /opt/csw/etc/clamav-milter.conf usage: chmod [-fR] file ... chmod [-fR] file ... chmod [-fR] file ... where is a comma-separated list of [ugoa]{+|-|=}[rwxXlstugo] where is one of the following A- A[number]- A[number]{+|=} where is a comma-separated list of ACEs Copying sample config to /opt/csw/etc/clamd.conf usage: chmod [-fR] file ... chmod [-fR] file ... chmod [-fR] file ... where is a comma-separated list of [ugoa]{+|-|=}[rwxXlstugo] where is one of the following A- A[number]- A[number]{+|=} where is a comma-separated list of ACEs Copying sample config to /opt/csw/etc/freshclam.conf usage: chmod [-fR] file ... chmod [-fR] file ... chmod [-fR] file ... where is a comma-separated list of [ugoa]{+|-|=}[rwxXlstugo] where is one of the following A- A[number]- A[number]{+|=} where is a comma-separated list of ACEs in the package one finds : 1 f cswcpsampleconf /opt/csw/etc/clamav-milter.conf.CSW 0644 root bin 7156 30995 1244712757 Taking a look at /usr/sadm/install/scripts/i.cswcpsampleconf gives the impression ( contents=`grep "^$dest" /var/sadm/install/contents` ) in /var/sadm/install/contents one should find the string "/opt/csw/etc/clamav-milter.conf". But it is not there, not untill after the installation finished. As it remains after pkgrm CSWclamav, from now on pkg-get -i clamav works as expected. You end up with : ll /opt/csw/etc/clamav-milter.conf -rw-r--r-- 1 root root 7156 Oct 26 19:53 /opt/csw/etc/clamav-milter.conf This is not limited to clamav - there are some other packages as well. i.e openssh-client, openssh. Nicolai From bonivart at opencsw.org Mon Oct 26 20:31:45 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 26 Oct 2009 20:31:45 +0100 Subject: [csw-maintainers] pkginstall question In-Reply-To: <200910261854.n9QIsg6r014895@dfki.uni-kl.de> References: <200910261854.n9QIsg6r014895@dfki.uni-kl.de> Message-ID: <625385e30910261231qca73d49xbb94f1e378062345@mail.gmail.com> On Mon, Oct 26, 2009 at 7:54 PM, Nicolai Schwindt wrote: > > The errors on install packages I mentioned a while age still exist. > Maybe now someone has an idea. > > My scenario : fresh install of solaris 10 x86 10u8 > > pkg-get -i clamav ?- gives : > ... > [ verifying class ] > Copying sample config to /opt/csw/etc/clamav-milter.conf > usage: ?chmod [-fR] file ... > ? ? ? ?chmod [-fR] file ... > ? ? ? ?chmod [-fR] file ... > where ? is a comma-separated list of > ? ? ? ?[ugoa]{+|-|=}[rwxXlstugo] > where ? is one of the following > ? ? ? ?A- > ? ? ? ?A[number]- > ? ? ? ?A[number]{+|=} > where ? is a comma-separated list of ACEs > Copying sample config to /opt/csw/etc/clamd.conf > usage: ?chmod [-fR] file ... > ? ? ? ?chmod [-fR] file ... > ? ? ? ?chmod [-fR] file ... > where ? is a comma-separated list of > ? ? ? ?[ugoa]{+|-|=}[rwxXlstugo] > where ? is one of the following > ? ? ? ?A- > ? ? ? ?A[number]- > ? ? ? ?A[number]{+|=} > where ? is a comma-separated list of ACEs > Copying sample config to /opt/csw/etc/freshclam.conf > usage: ?chmod [-fR] file ... > ? ? ? ?chmod [-fR] file ... > ? ? ? ?chmod [-fR] file ... > where ? is a comma-separated list of > ? ? ? ?[ugoa]{+|-|=}[rwxXlstugo] > where ? is one of the following > ? ? ? ?A- > ? ? ? ?A[number]- > ? ? ? ?A[number]{+|=} > where ? is a comma-separated list of ACEs > > > > > in the package one finds : > > 1 f cswcpsampleconf /opt/csw/etc/clamav-milter.conf.CSW 0644 root bin 7156 > 30995 1244712757 > > Taking a look at /usr/sadm/install/scripts/i.cswcpsampleconf gives the > impression > ?( contents=`grep "^$dest" /var/sadm/install/contents` ) ?in > /var/sadm/install/contents > one should find ?the string "/opt/csw/etc/clamav-milter.conf". > > But it is not there, not untill after the installation finished. As it remains > after pkgrm > CSWclamav, from now on pkg-get -i clamav works as expected. > > You end up with : > > ll /opt/csw/etc/clamav-milter.conf > -rw-r--r-- ? 1 root ? ? root ? ? ? ?7156 Oct 26 19:53 > /opt/csw/etc/clamav-milter.conf > > This is not limited to clamav - there are some other packages as well. i.e > openssh-client, > openssh. There's a bug for this: http://www.opencsw.org/mantis/view.php?id=3959 I'll add your notes to that bug. I haven't had much time to look at it. Anything special with your setup? Is this a sparse zone? Latest version of cswclassutils? -- /peter From schwindt at dfki.uni-kl.de Mon Oct 26 20:51:55 2009 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Mon, 26 Oct 2009 20:51:55 +0100 Subject: [csw-maintainers] pkginstall question In-Reply-To: Your message of "Mon, 26 Oct 2009 20:31:45 +0100." <625385e30910261231qca73d49xbb94f1e378062345@mail.gmail.com> Message-ID: <200910261951.n9QJptiN015300@dfki.uni-kl.de> [...] > Anything special with your setup? Is this a sparse zone? Latest > version of cswclassutils? Nothing special - no zones. pkg-get -c cswclassutils # (From site http://serv-1500/blastwave/csw/unstable ) software localrev remoterev cswclassutils 1.22,REV=2009.10.14 SAME serv-1500 is a local mirror syncing once every night. Nicolai From phil at bolthole.com Mon Oct 26 22:12:43 2009 From: phil at bolthole.com (Philip Brown) Date: Mon, 26 Oct 2009 14:12:43 -0700 Subject: [csw-maintainers] pkginstall question In-Reply-To: <625385e30910261231qca73d49xbb94f1e378062345@mail.gmail.com> References: <200910261854.n9QIsg6r014895@dfki.uni-kl.de> <625385e30910261231qca73d49xbb94f1e378062345@mail.gmail.com> Message-ID: On Mon, Oct 26, 2009 at 12:31 PM, Peter Bonivart wrote: > >> This is not limited to clamav - there are some other packages as well. i.e >> openssh-client, >> openssh. > > There's a bug for this: http://www.opencsw.org/mantis/view.php?id=3959 > > I'll add your notes to that bug. I haven't had much time to look at it. > oh urg. i was supposed to look at that too, but ran out of time on my last weekend. I'll try to look at it this weekend :-( From aubrey at opensolaris.org Mon Oct 26 01:39:43 2009 From: aubrey at opensolaris.org (Aubrey Li) Date: Mon, 26 Oct 2009 08:39:43 +0800 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution In-Reply-To: <4AE4C74C.5050100@opencsw.org> References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> <4AE4C74C.5050100@opencsw.org> Message-ID: <6d6a94c50910251739n6fd2ce19td7bde4ad6826fc5a@mail.gmail.com> Hi Ihsan, On Mon, Oct 26, 2009 at 5:46 AM, Ihsan Dogan wrote: > Hello Aubrey, > > Am 25.10.2009 21:07 Uhr, Dagobert Michelsen schrieb: > >>> It looks like I'm not on the maintainers' list, and my mail account >>> aubrey at opencsw.org is not valid any longer, could you please help >>> me to send this mail out? >> >> Fwd'ing to Ihsan. Aubrey has already contributed packages and had >> an account in the past. >> >> Ihsan: Would you mind having a look? > > Your Account is still active. What exactly does not work? my mail address(aubrey AT opencsw.org) doesn't work, I can't receive any mail from it. So I think I can't post this mail to maintainers@ as well, could you please take a look? Thanks, -Aubrey > > > > Ihsan > > -- > ihsan at dogan.ch ? ? ? ? ?http://blog.dogan.ch/ > From bonivart at opencsw.org Mon Oct 26 22:38:01 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 26 Oct 2009 22:38:01 +0100 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution In-Reply-To: <6d6a94c50910251739n6fd2ce19td7bde4ad6826fc5a@mail.gmail.com> References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> <4AE4C74C.5050100@opencsw.org> <6d6a94c50910251739n6fd2ce19td7bde4ad6826fc5a@mail.gmail.com> Message-ID: <625385e30910261438n1e21d653k4dd348da4c27dc67@mail.gmail.com> On Mon, Oct 26, 2009 at 1:39 AM, Aubrey Li wrote: > my mail address(aubrey AT opencsw.org) doesn't work, I can't receive any > mail from it. How are you checking that? How do you access it? Are you redirecting it to another account? -- /peter From bonivart at opencsw.org Mon Oct 26 23:45:59 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 26 Oct 2009 23:45:59 +0100 Subject: [csw-maintainers] pkginstall question In-Reply-To: <200910261951.n9QJptiN015300@dfki.uni-kl.de> References: <625385e30910261231qca73d49xbb94f1e378062345@mail.gmail.com> <200910261951.n9QJptiN015300@dfki.uni-kl.de> Message-ID: <625385e30910261545y7abe549emde0ae64914b1ceb4@mail.gmail.com> On Mon, Oct 26, 2009 at 8:51 PM, Nicolai Schwindt wrote: > [...] >> Anything special with your setup? Is this a sparse zone? Latest >> version of cswclassutils? > > Nothing special - no zones. > > pkg-get -c cswclassutils > # (From site http://serv-1500/blastwave/csw/unstable ) > ? ? ? software ? ? ? ? ? ? ? ? ? ? ? ?localrev ? ? ? ? ? ? ? ? ? ? ?remoterev > ?cswclassutils ? ? ? ? ? ? 1.22,REV=2009.10.14 ? ? ? ? ? ? ? ? ? ? ? ? ? SAME Must be some difference between our systems, this is the same install: Installing class ... Group clamav has been added User clamav has been added [ verifying class ] /var/opt/csw/clamav/db/daily.cvd /var/opt/csw/clamav/db/main.cvd [ verifying class ] Copying sample config to /opt/csw/etc/clamav-milter.conf Copying sample config to /opt/csw/etc/clamd.conf Copying sample config to /opt/csw/etc/freshclam.conf [ verifying class ] Installing class ... Creating /var/opt/csw/svc/manifest/network ... Creating service script in /var/opt/csw/svc/method/svc-cswclamav-milter ... Creating manifest ... Configuring service in SMF ... CSWclamav is using Service Management Facility. The FMRI is svc:/network/cswclamav-milter:default Enabling svc:/network/cswclamav-milter ... Creating service script in /var/opt/csw/svc/method/svc-cswclamd ... Creating manifest ... Configuring service in SMF ... CSWclamav is using Service Management Facility. The FMRI is svc:/network/cswclamd:default Enabling svc:/network/cswclamd ... [ verifying class ] Installation of was successful. I also had cswclassutils 1.22 and no previous install of clamav. What could cause my contents file to be populated but not yours? -- /peter From aubrey at opencsw.org Tue Oct 27 02:30:02 2009 From: aubrey at opencsw.org (Aubrey Li) Date: Tue, 27 Oct 2009 09:30:02 +0800 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution In-Reply-To: <625385e30910261438n1e21d653k4dd348da4c27dc67@mail.gmail.com> References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> <4AE4C74C.5050100@opencsw.org> <6d6a94c50910251739n6fd2ce19td7bde4ad6826fc5a@mail.gmail.com> <625385e30910261438n1e21d653k4dd348da4c27dc67@mail.gmail.com> Message-ID: <6d6a94c50910261830vaa3641esb9aaecdef3049892@mail.gmail.com> Hi Ihsan, Peter, It works now, thanks! -Aubrey On Tue, Oct 27, 2009 at 5:38 AM, Peter Bonivart wrote: > On Mon, Oct 26, 2009 at 1:39 AM, Aubrey Li wrote: >> my mail address(aubrey AT opencsw.org) doesn't work, I can't receive any >> mail from it. > > How are you checking that? How do you access it? Are you redirecting > it to another account? > > -- > /peter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > From aubrey at opencsw.org Tue Oct 27 02:50:07 2009 From: aubrey at opencsw.org (Aubrey Li) Date: Tue, 27 Oct 2009 09:50:07 +0800 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution In-Reply-To: References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> Message-ID: <6d6a94c50910261850j15210e7crf5874283cf11dfc@mail.gmail.com> On Tue, Oct 27, 2009 at 12:14 AM, Philip Brown wrote: >> >>> Can we enhance this script to support IPS package system? >>> I have a quick idea similarly like the following patch, >>>... > > > I think that only really makes sense, when we start distributing > packages in IPS format. > > at which point, we should have a related-but-separate utility, > "checkips", I think :-) > > checkpkg is for creating packages. Right now, people should NOT be > creating OpenCSW packages on opensolaris. Only Solaris(tm)(r)(...) > > For someone who wishes to tinker, but only runs opensolaris at the > moment.. it should be easy enough to set up a solaris zone? > They could use the "branded zone" type stuff, and install solaris 9 > zone, I would think. solaris zone is a luxurious environment for me to do the development. opensolaris supports both SVR4 and IPS. I can use opencsw package on osol, for what reason we should NOT create package on osol? Sooner or later when SUN kill SXCE, osol will be my only choice to do the developement. When I digged into the scipt "checkpkg", I found the price is not high to support osol distribution. So, could you please give a shot on osol? It's really not bad, :-) Thanks, -Aubrey From aubrey at opencsw.org Tue Oct 27 06:57:49 2009 From: aubrey at opencsw.org (Aubrey Li) Date: Tue, 27 Oct 2009 13:57:49 +0800 Subject: [csw-maintainers] CSWcscope is in tesing Message-ID: <6d6a94c50910262257k1f90630j93ecbdbab725ca35@mail.gmail.com> Hi list, My first package CSWcscope is in testing, I really appreciate your testing and feedback. Thanks, -Aubrey From dam at opencsw.org Tue Oct 27 10:28:33 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 27 Oct 2009 10:28:33 +0100 Subject: [csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update In-Reply-To: References: <4AAB32A6.5060305@opencsw.org> <64360.194.246.122.22.1253185698.squirrel@ssl.skayser.de> Message-ID: Hi Maciej, Am 19.10.2009 um 01:39 schrieb Maciej (Matchek) Blizinski: > I've written the first version of cswmigrateconf, a class utility > script which migrates configuration files from /opt/csw/etc to > /etc/opt/csw. It works the way Sebastian has suggested, i.e.: It makes > an intermediate copy in /opt/csw/etc/migration-archive, and then uses > it as a source to populate /etc/opt/csw. This is very useful. Thanks! I guess I'll update all my packages needing migration with this. With this kind of tools packaging is fun :-) In addition to migrating single files is there the possibility to migrate complete directories? Like /opt/csw/var/postgresql/ to /var/opt/csw/posgresql/ ? Best regards -- Dago From phil at bolthole.com Tue Oct 27 17:16:46 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 27 Oct 2009 09:16:46 -0700 Subject: [csw-maintainers] Fwd: checkpkg problem on opensolaris distribution In-Reply-To: <6d6a94c50910261850j15210e7crf5874283cf11dfc@mail.gmail.com> References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> <6d6a94c50910261850j15210e7crf5874283cf11dfc@mail.gmail.com> Message-ID: On Mon, Oct 26, 2009 at 6:50 PM, Aubrey Li wrote: > > opensolaris supports both SVR4 and IPS. I can use opencsw package > on osol, for what reason we should NOT create package on osol? for the exact reason that was brought up: it's "different" :-) and reasonable, sane things that work on normal solaris, dont work on opensolaris. It is also quite likely, that you will end up doing things that work on opensolaris, that do NOT work on normal solaris. So, best not to do it. Please set up a zone on your own machines, or if not, use our opencsw build/test machines. that's what they are here for, after all. From dam at opencsw.org Tue Oct 27 18:00:03 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 27 Oct 2009 18:00:03 +0100 Subject: [csw-maintainers] checkpkg problem on opensolaris distribution In-Reply-To: References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> <6d6a94c50910261850j15210e7crf5874283cf11dfc@mail.gmail.com> Message-ID: <211F94FD-A92B-48FB-898C-8D439A394A55@opencsw.org> Hi, Am 27.10.2009 um 17:16 schrieb Philip Brown: > On Mon, Oct 26, 2009 at 6:50 PM, Aubrey Li wrote: >> >> opensolaris supports both SVR4 and IPS. I can use opencsw package >> on osol, for what reason we should NOT create package on osol? > > for the exact reason that was brought up: it's "different" :-) and > reasonable, sane things that work on normal solaris, dont work on > opensolaris. > It is also quite likely, that you will end up doing things that work > on opensolaris, that do NOT work on normal solaris. > > So, best not to do it. > > Please set up a zone on your own machines, or if not, use our opencsw > build/test machines. that's what they are here for, after all. To clarify this some more: This is for the official OpenCSW packages released to current/. However, work is being done to add a repository for IPS packages for OpenSolaris and you are very welcome to drive the work in that direction, especially package conversion (I heard Trygve has started work on this), porting of the cswutils to OpenSolaris and a naive GAR IPS backend. Best regards -- Dago From trygvis at opencsw.org Tue Oct 27 20:51:47 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Tue, 27 Oct 2009 20:51:47 +0100 Subject: [csw-maintainers] checkpkg problem on opensolaris distribution In-Reply-To: <211F94FD-A92B-48FB-898C-8D439A394A55@opencsw.org> References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> <6d6a94c50910261850j15210e7crf5874283cf11dfc@mail.gmail.com> <211F94FD-A92B-48FB-898C-8D439A394A55@opencsw.org> Message-ID: <4AE74F53.3050200@opencsw.org> Dagobert Michelsen wrote: > Hi, > > Am 27.10.2009 um 17:16 schrieb Philip Brown: >> On Mon, Oct 26, 2009 at 6:50 PM, Aubrey Li wrote: >>> >>> opensolaris supports both SVR4 and IPS. I can use opencsw package >>> on osol, for what reason we should NOT create package on osol? >> >> for the exact reason that was brought up: it's "different" :-) and >> reasonable, sane things that work on normal solaris, dont work on >> opensolaris. >> It is also quite likely, that you will end up doing things that work >> on opensolaris, that do NOT work on normal solaris. >> >> So, best not to do it. >> >> Please set up a zone on your own machines, or if not, use our opencsw >> build/test machines. that's what they are here for, after all. > > To clarify this some more: This is for the official OpenCSW > packages released to current/. However, work is being done > to add a repository for IPS packages for OpenSolaris and you > are very welcome to drive the work in that direction, especially > package conversion (I heard Trygve has started work on this), > porting of the cswutils to OpenSolaris and a naive GAR IPS > backend. The only thing I've work on is creating a useful tool to convert from .pkg to .ips instead of Sun's junk. It's in a working state and I've installed lots of OpenCSW packages from my converted repository. -- Trygve From phil at bolthole.com Tue Oct 27 21:30:23 2009 From: phil at bolthole.com (Philip Brown) Date: Tue, 27 Oct 2009 13:30:23 -0700 Subject: [csw-maintainers] checkpkg problem on opensolaris distribution In-Reply-To: <4AE74F53.3050200@opencsw.org> References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> <6d6a94c50910261850j15210e7crf5874283cf11dfc@mail.gmail.com> <211F94FD-A92B-48FB-898C-8D439A394A55@opencsw.org> <4AE74F53.3050200@opencsw.org> Message-ID: 2009/10/27 Trygve Laugst?l : > > The only thing I've work on is creating a useful tool to convert from > .pkg to .ips instead of Sun's junk. It's in a working state and I've > installed lots of OpenCSW packages from my converted repository. > wow, excellent! have you made, or do you plan to make, a "checkips" tool then? From trygvis at opencsw.org Tue Oct 27 22:33:51 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Tue, 27 Oct 2009 22:33:51 +0100 Subject: [csw-maintainers] checkpkg problem on opensolaris distribution In-Reply-To: References: <6d6a94c50910250522u25642a1axf028c1fb94458a79@mail.gmail.com> <6d6a94c50910261850j15210e7crf5874283cf11dfc@mail.gmail.com> <211F94FD-A92B-48FB-898C-8D439A394A55@opencsw.org> <4AE74F53.3050200@opencsw.org> Message-ID: <4AE7673F.5030507@opencsw.org> Philip Brown wrote: > 2009/10/27 Trygve Laugst?l : >> The only thing I've work on is creating a useful tool to convert from >> .pkg to .ips instead of Sun's junk. It's in a working state and I've >> installed lots of OpenCSW packages from my converted repository. >> > > wow, excellent! > > have you made, or do you plan to make, a "checkips" tool then? My tool only does a one to one convertion from a pkg file to a "ips file" so no, I just copy the "prototype", dependencies and most of the stuff from pkgmap. -- Trygve From bonivart at opencsw.org Wed Oct 28 10:59:34 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 28 Oct 2009 10:59:34 +0100 Subject: [csw-maintainers] pkginstall question In-Reply-To: <200910261951.n9QJptiN015300@dfki.uni-kl.de> References: <625385e30910261231qca73d49xbb94f1e378062345@mail.gmail.com> <200910261951.n9QJptiN015300@dfki.uni-kl.de> Message-ID: <625385e30910280259y77676329u8fc476812b82e5dc@mail.gmail.com> Dago found that people having well patched servers ;-) could run into this due to a new cool feature in Solaris 10 called turbo charged packages. Writes to the contents file are being delayed and synced regularly instead of written immediately which should give a significant performance boost. This is included in Solaris 10 update 8 (10/09) and you can also get it via patch 119254/199255. I have now added a sync which should flush all pending writes to the contents file before using it in cpsampleconf and preserveconf. I have tested it with and without the patch and it works for me but I want a few more to confirm so we can have a quick release. So please help test cswclassutils 1.27 in testing. Some packages to test with are: CSWclamav, CSWossh and CSWcacertificates. If you maintain packages that use cpsampleconf or preserveconf, please test them. http://mirror.opencsw.org/testing/cswclassutils-1.27,REV=2009.10.28-SunOS5.8-all-CSW.pkg.gz -- /peter From daniel at opencsw.org Wed Oct 28 18:04:25 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 28 Oct 2009 17:04:25 +0000 Subject: [csw-maintainers] Ganglia for sparcv9 Message-ID: <4AE87999.6020401@opencsw.org> I've added BUILD64 = 1 to my Ganglia package Makefile, so that I can build 64 bit support. This is important because Ganglia makes calls to kstat and that needs to be done from 64 bit code when running on a 64 bit kernel. However, I'm finding that some dependencies are not 64 bit. The key ones that I am currently stuck on: /opt/csw/apache2/lib/libapr-1.so.0 /opt/csw/lib/sparcv8/libsasl2.so.2 /opt/csw/lib/sparcv8/libnet.so Can anyone assist with this or make any comments on these issues? From ihsan at dogan.ch Wed Oct 28 18:04:08 2009 From: ihsan at dogan.ch (Ihsan Dogan) Date: Wed, 28 Oct 2009 18:04:08 +0100 Subject: [csw-maintainers] Apache 2 Package In-Reply-To: <200910261614.n9QGEcOv011294@dfki.uni-kl.de> References: <200910261614.n9QGEcOv011294@dfki.uni-kl.de> Message-ID: <4AE87988.5070401@dogan.ch> On 26.10.2009 17:14, Nicolai Schwindt wrote: >>> The Apache 2 package needs to be reworked and I can't find any >>> additional ressources at this time. Would be great if someone could take >>> over this package. >> Still no volunteer for this package? > > I would - but this would mean I needed much help on gar. > As this would consume a larger amount of time as doing it yourself > we have a deadlock .( It would be really great if you could take over this package. As the others already mentioned, Gar is really not difficult and you can always ask here on the maintainers list. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From phil at bolthole.com Wed Oct 28 18:15:46 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 28 Oct 2009 10:15:46 -0700 Subject: [csw-maintainers] Ganglia for sparcv9 In-Reply-To: <4AE87999.6020401@opencsw.org> References: <4AE87999.6020401@opencsw.org> Message-ID: On Wed, Oct 28, 2009 at 10:04 AM, Daniel Pocock wrote: > > > However, I'm finding that some dependencies are not 64 bit. ?The key ones > that I am currently stuck on: > > /opt/csw/apache2/lib/libapr-1.so.0 ... > Can anyone assist with this or make any comments on these issues? > > comment: 1, we need an apache2 maintainer 2. we need a split-out "libapr" package Sorry, that's all I got :-} From dam at opencsw.org Wed Oct 28 18:24:51 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 28 Oct 2009 18:24:51 +0100 Subject: [csw-maintainers] Revision in package versions Message-ID: <061B3F7D-E261-483A-BF56-358F68524D0D@opencsw.org> Hi folks, Aubrey has just finished a nice new cscope package, thanks! :-) It has the version 15.7a: cscope-15.7a,REV=2009.10.27-SunOS5.8-i386-CSW.pkg.gz I remember that we introduced some kind of "sub revisions" like 15.7,REV=2009.10.27_rev=a Now that pkg-get has been converted to use REV-dates I guess the sub-revisions are no longer needed and can be thrown out of all the build manifests, yes? Best regards -- Dago From bwalton at opencsw.org Wed Oct 28 18:38:41 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 28 Oct 2009 13:38:41 -0400 Subject: [csw-maintainers] Revision in package versions In-Reply-To: <061B3F7D-E261-483A-BF56-358F68524D0D@opencsw.org> References: <061B3F7D-E261-483A-BF56-358F68524D0D@opencsw.org> Message-ID: <1256751287-sup-4952@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Oct 28 13:24:51 -0400 2009: > I remember that we introduced some kind of "sub revisions" like > 15.7,REV=2009.10.27_rev=a My ruby packages are using: 1.8.7,REV=%Y.%m.%d_rev=p$(patchlevel) In the case of ruby, at least, this $(patchlevel) portion is of significance to users in order to determine if the package has the lastest upstream security updates rolled in. > Now that pkg-get has been converted to use REV-dates I guess the > sub-revisions are no longer needed and can be thrown out of all the > build manifests, yes? For version comparison purposes, they're already ignored (at least in pkgutil). I'd vote to keep them around though, as they do convey important version information to humans and shouldn't hurt anything else. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Wed Oct 28 18:48:48 2009 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 28 Oct 2009 18:48:48 +0100 Subject: [csw-maintainers] Revision in package versions In-Reply-To: <1256751287-sup-4952@ntdws12.chass.utoronto.ca> References: <061B3F7D-E261-483A-BF56-358F68524D0D@opencsw.org> <1256751287-sup-4952@ntdws12.chass.utoronto.ca> Message-ID: <625385e30910281048y29084745h29db443ee66bfea7@mail.gmail.com> On Wed, Oct 28, 2009 at 6:38 PM, Ben Walton wrote: > For version comparison purposes, they're already ignored (at least in > pkgutil). ?I'd vote to keep them around though, as they do convey > important version information to humans and shouldn't hurt anything > else. Yes, but couldn't you just change 1.8.7,REV=2009.08.06_rev=p174 into 1.8.7p174,REV=2009.08.06? Same info but looks nicer. :-) -- /peter From bwalton at opencsw.org Wed Oct 28 18:56:50 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 28 Oct 2009 13:56:50 -0400 Subject: [csw-maintainers] Revision in package versions In-Reply-To: <625385e30910281048y29084745h29db443ee66bfea7@mail.gmail.com> References: <061B3F7D-E261-483A-BF56-358F68524D0D@opencsw.org> <1256751287-sup-4952@ntdws12.chass.utoronto.ca> <625385e30910281048y29084745h29db443ee66bfea7@mail.gmail.com> Message-ID: <1256752566-sup-6151@ntdws12.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Wed Oct 28 13:48:48 -0400 2009: > Yes, but couldn't you just change 1.8.7,REV=2009.08.06_rev=p174 into > 1.8.7p174,REV=2009.08.06? Yes, I'd be happy to do that. I misunderstood what Dago was saying, if that was also his intended change. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Wed Oct 28 19:15:47 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 28 Oct 2009 19:15:47 +0100 Subject: [csw-maintainers] Revision in package versions In-Reply-To: <1256752566-sup-6151@ntdws12.chass.utoronto.ca> References: <061B3F7D-E261-483A-BF56-358F68524D0D@opencsw.org> <1256751287-sup-4952@ntdws12.chass.utoronto.ca> <625385e30910281048y29084745h29db443ee66bfea7@mail.gmail.com> <1256752566-sup-6151@ntdws12.chass.utoronto.ca> Message-ID: <5C066E93-C4E6-4012-853D-99581B8AD977@opencsw.org> Hi, Am 28.10.2009 um 18:56 schrieb Ben Walton: > Excerpts from Peter Bonivart's message of Wed Oct 28 13:48:48 -0400 > 2009: >> Yes, but couldn't you just change 1.8.7,REV=2009.08.06_rev=p174 into >> 1.8.7p174,REV=2009.08.06? > > Yes, I'd be happy to do that. I misunderstood what Dago was saying, > if that was also his intended change. Yes, that was my intended change. Peter is already ok with it. Phil: Can we ditch ",rev=" in favor of appending it to the version? Best regards -- Dago From phil at bolthole.com Wed Oct 28 19:22:12 2009 From: phil at bolthole.com (Philip Brown) Date: Wed, 28 Oct 2009 11:22:12 -0700 Subject: [csw-maintainers] Revision in package versions In-Reply-To: <5C066E93-C4E6-4012-853D-99581B8AD977@opencsw.org> References: <061B3F7D-E261-483A-BF56-358F68524D0D@opencsw.org> <1256751287-sup-4952@ntdws12.chass.utoronto.ca> <625385e30910281048y29084745h29db443ee66bfea7@mail.gmail.com> <1256752566-sup-6151@ntdws12.chass.utoronto.ca> <5C066E93-C4E6-4012-853D-99581B8AD977@opencsw.org> Message-ID: On Wed, Oct 28, 2009 at 11:15 AM, Dagobert Michelsen wrote: > > Phil: Can we ditch ",rev=" in favor of appending it to the version[-number, before the "REV" substring]? Yes. From dam at opencsw.org Wed Oct 28 19:42:17 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 28 Oct 2009 19:42:17 +0100 Subject: [csw-maintainers] Revision in package versions In-Reply-To: References: <061B3F7D-E261-483A-BF56-358F68524D0D@opencsw.org> <1256751287-sup-4952@ntdws12.chass.utoronto.ca> <625385e30910281048y29084745h29db443ee66bfea7@mail.gmail.com> <1256752566-sup-6151@ntdws12.chass.utoronto.ca> <5C066E93-C4E6-4012-853D-99581B8AD977@opencsw.org> Message-ID: Hi, Am 28.10.2009 um 19:22 schrieb Philip Brown: > On Wed, Oct 28, 2009 at 11:15 AM, Dagobert Michelsen > wrote: >> >> Phil: Can we ditch ",rev=" in favor of appending it to the version[- >> number, before the "REV" substring]? > > Yes. Ok then, I propose to officially deprecate the usage of the ,rev= string and append it to the version. That would mean the docs would state that it is deprecated and packages with _rev would be no longer accepted for release. Oppinions? Best regards -- Dago From bwalton at opencsw.org Wed Oct 28 19:46:12 2009 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 28 Oct 2009 14:46:12 -0400 Subject: [csw-maintainers] Revision in package versions In-Reply-To: References: <061B3F7D-E261-483A-BF56-358F68524D0D@opencsw.org> <1256751287-sup-4952@ntdws12.chass.utoronto.ca> <625385e30910281048y29084745h29db443ee66bfea7@mail.gmail.com> <1256752566-sup-6151@ntdws12.chass.utoronto.ca> <5C066E93-C4E6-4012-853D-99581B8AD977@opencsw.org> Message-ID: <1256755551-sup-2441@ntdws12.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Oct 28 14:42:17 -0400 2009: > Oppinions? +1 -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From daniel at opencsw.org Wed Oct 28 20:43:17 2009 From: daniel at opencsw.org (Daniel Pocock) Date: Wed, 28 Oct 2009 19:43:17 +0000 Subject: [csw-maintainers] Ganglia for sparcv9 In-Reply-To: References: <4AE87999.6020401@opencsw.org> Message-ID: <4AE89ED5.7050404@opencsw.org> Philip Brown wrote: > On Wed, Oct 28, 2009 at 10:04 AM, Daniel Pocock wrote: > >> However, I'm finding that some dependencies are not 64 bit. The key ones >> that I am currently stuck on: >> >> /opt/csw/apache2/lib/libapr-1.so.0 >> > ... > >> Can anyone assist with this or make any comments on these issues? >> >> >> > > comment: > > 1, we need an apache2 maintainer > 2. we need a split-out "libapr" package > split-out by the same maintainer, or completely independently packaged? should apache continue to use it's own apr package, and then we would have a separate apr too? > Sorry, that's all I got :-} > Anything helps - I've only built two packages so far, so there's a lot of background I have to catch up on From trygvis at opencsw.org Wed Oct 28 21:15:40 2009 From: trygvis at opencsw.org (=?ISO-8859-1?Q?Trygve_Laugst=F8l?=) Date: Wed, 28 Oct 2009 21:15:40 +0100 Subject: [csw-maintainers] Revision in package versions In-Reply-To: References: <061B3F7D-E261-483A-BF56-358F68524D0D@opencsw.org> <1256751287-sup-4952@ntdws12.chass.utoronto.ca> <625385e30910281048y29084745h29db443ee66bfea7@mail.gmail.com> <1256752566-sup-6151@ntdws12.chass.utoronto.ca> <5C066E93-C4E6-4012-853D-99581B8AD977@opencsw.org> Message-ID: <4AE8A66C.9030803@opencsw.org> Dagobert Michelsen wrote: > Hi, > > Am 28.10.2009 um 19:22 schrieb Philip Brown: >> On Wed, Oct 28, 2009 at 11:15 AM, Dagobert Michelsen >> wrote: >>> >>> Phil: Can we ditch ",rev=" in favor of appending it to the >>> version[-number, before the "REV" substring]? >> >> Yes. > > Ok then, I propose to officially deprecate the usage of the ,rev= string > and append it to the version. That would mean the docs would state that it > is deprecated and packages with _rev would be no longer accepted for > release. +1 -- Trygve From william at wbonnet.net Wed Oct 28 22:39:58 2009 From: william at wbonnet.net (William Bonnet) Date: Wed, 28 Oct 2009 22:39:58 +0100 Subject: [csw-maintainers] Revision in package versions In-Reply-To: <4AE8A66C.9030803@opencsw.org> References: <061B3F7D-E261-483A-BF56-358F68524D0D@opencsw.org> <1256751287-sup-4952@ntdws12.chass.utoronto.ca> <625385e30910281048y29084745h29db443ee66bfea7@mail.gmail.com> <1256752566-sup-6151@ntdws12.chass.utoronto.ca> <5C066E93-C4E6-4012-853D-99581B8AD977@opencsw.org> <4AE8A66C.9030803@opencsw.org> Message-ID: <4AE8BA2E.2010404@wbonnet.net> Hi >> >> Ok then, I propose to officially deprecate the usage of the ,rev= string >> and append it to the version. That would mean the docs would state >> that it >> is deprecated and packages with _rev would be no longer accepted for >> release. > > +1 > +1 -- 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 Thu Oct 29 11:21:31 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 29 Oct 2009 11:21:31 +0100 Subject: [csw-maintainers] New library 'jack' wants to be build with 'waf' Message-ID: <47F4C2E7-7170-4DA0-B287-ED592FE6328C@opencsw.org> Hi, I just tried to build a dependency for libsndfile 'jack' which wants to be built with the waf build system: http://code.google.com/p/waf/ I haven't seen much of it, by I already hate it... Maybe someone has already gained some experience with it? I tried adding support for WAF to GAR and made preliminary makefile for jack, everything is in GAR. Comments welcome. Best regards -- Dago From phil at bolthole.com Thu Oct 29 18:55:44 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 29 Oct 2009 10:55:44 -0700 Subject: [csw-maintainers] Ganglia for sparcv9 In-Reply-To: <4AE89ED5.7050404@opencsw.org> References: <4AE87999.6020401@opencsw.org> <4AE89ED5.7050404@opencsw.org> Message-ID: On Wed, Oct 28, 2009 at 12:43 PM, Daniel Pocock wrote: > Philip Brown wrote: >> >> comment: >> >> ... >> 2. we need a split-out "libapr" package >> > > split-out by the same maintainer, or completely independently packaged? just as a splitout pacakge, so certain things can depend on that package instead of "apache" in general. apache itself should use this libapr package, I would think. From phil at bolthole.com Fri Oct 30 00:59:48 2009 From: phil at bolthole.com (Philip Brown) Date: Thu, 29 Oct 2009 16:59:48 -0700 Subject: [csw-maintainers] final request for samba Message-ID: Last call, for someone to be a samba maintainer. We've been lacking a modern samba maintainer for a Very Long Time. We NEED a recent samba. Because of the overwhelming need for this, if no-one steps up to do it right, I'm going to do a very rare thing, and make an exception for usual good practice. I'm going to just make one large huge ugly single package, dump it in testing for a while, and then release it. I'd really rather not do this. Firstly, because there are a whole bunch of other things I should be doing with my time :-/ (which is why I cant do it "nicely") But we need it done. From bwalton at opencsw.org Fri Oct 30 03:26:24 2009 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 29 Oct 2009 22:26:24 -0400 Subject: [csw-maintainers] final request for samba In-Reply-To: References: Message-ID: <1256869503-sup-9699@ntdws12.chass.utoronto.ca> Where do the previously released build notes/scripts/magic incantations reside? I'll take a look at it. I can't guarantee a lot of time right now, but I can move it forward toward an easily splittable package in gar. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Oct 30 17:06:32 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 30 Oct 2009 09:06:32 -0700 Subject: [csw-maintainers] final request for samba In-Reply-To: <1256869503-sup-9699@ntdws12.chass.utoronto.ca> References: <1256869503-sup-9699@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Oct 29, 2009 at 7:26 PM, Ben Walton wrote: > Where do the previously released build notes/scripts/magic > incantations reside? > pretty much nonexistent. oh wait. I have some from when I put together my quick-n-dirty thing currently in testing, from 2008. login:~phil/pkgs/samba/BUILD.NOTES Its not exactly a trivial build. but I automated most of it with my notes and patchfile From bwalton at opencsw.org Fri Oct 30 17:09:46 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 30 Oct 2009 12:09:46 -0400 Subject: [csw-maintainers] final request for samba In-Reply-To: References: <1256869503-sup-9699@ntdws12.chass.utoronto.ca> Message-ID: <1256918919-sup-7569@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Oct 30 12:06:32 -0400 2009: > oh wait. I have some from when I put together my quick-n-dirty thing > currently in testing, from 2008. > > login:~phil/pkgs/samba/BUILD. It's a start. At the very least, a starting point for options to configure. > Its not exactly a trivial build. but I automated most of it with my > notes and patchfile ...I can't remember the last time I saw a ./configure take so long and run so many tests. Not trivial indeed. I'll see what I can do with your notes and patch. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Oct 30 17:47:12 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 30 Oct 2009 12:47:12 -0400 Subject: [csw-maintainers] cswcommon update request Message-ID: <1256921216-sup-7652@ntdws12.chass.utoronto.ca> Hi Phil, Can you add the following directories to cswcommon to support 4 new hooks? * preargproc: /etc/opt/csw/pkg-hooks/preargproc.d/ * postargproc: /etc/opt/csw/pkg-hooks/postargproc.d/ * prefetch: /etc/opt/csw/pkg-hooks/prefetch.d/ * postfetch: /etc/opt/csw/pkg-hooks/postfetch.d/ Could you ping the list when this hits current as William will have some tools waiting on this availability. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Oct 30 17:53:25 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 30 Oct 2009 09:53:25 -0700 Subject: [csw-maintainers] cswcommon update request In-Reply-To: <1256921216-sup-7652@ntdws12.chass.utoronto.ca> References: <1256921216-sup-7652@ntdws12.chass.utoronto.ca> Message-ID: cswcommon should almost NEVER be updated. Its a very user-freaky thing to change. I dont like making changes like this, for something that is apparently in flux. Last change to cswcommon was barely a month ago, and it was for hooks again. This is too soon to make another change. Please just put in the definitions, into whatever uses it for now. (ie: define the directories with appropriate permissions) there is no harm in having multiple packages define the directories. After 6 months to a year has gone by, and there are no further changes in "hooks" over that timeperiod, then please re-request a change at that time. On Fri, Oct 30, 2009 at 9:47 AM, Ben Walton wrote: > > Hi Phil, > > Can you add the following directories to cswcommon to support 4 new > hooks? > > * preargproc: /etc/opt/csw/pkg-hooks/preargproc.d/ > * postargproc: /etc/opt/csw/pkg-hooks/postargproc.d/ > * prefetch: /etc/opt/csw/pkg-hooks/prefetch.d/ > * postfetch: /etc/opt/csw/pkg-hooks/postfetch.d/ > > Could you ping the list when this hits current as William will have > some tools waiting on this availability. > PS: there is no reason to "wait", as i've just pointed out above. From bwalton at opencsw.org Fri Oct 30 18:00:39 2009 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 30 Oct 2009 13:00:39 -0400 Subject: [csw-maintainers] cswcommon update request In-Reply-To: References: <1256921216-sup-7652@ntdws12.chass.utoronto.ca> Message-ID: <1256921785-sup-7145@ntdws12.chass.utoronto.ca> Excerpts from Philip Brown's message of Fri Oct 30 12:53:25 -0400 2009: > Please just put in the definitions, into whatever uses it for now. > (ie: define the directories with appropriate permissions) Maybe this is the better approach anyway? Any package containing hooks should include the required hook directories as part of it's prototype? I had thought cswcommon was a good spot for these since presumably there will be multiple implementations. > there is no harm in having multiple packages define the directories. Agreed. > After 6 months to a year has gone by, and there are no further changes > in "hooks" over that timeperiod, then please re-request a change at > that time. Ok. > PS: there is no reason to "wait", as i've just pointed out above. Roger that. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- 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 Oct 30 18:50:12 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 30 Oct 2009 10:50:12 -0700 Subject: [csw-maintainers] final request for samba In-Reply-To: <1256918919-sup-7569@ntdws12.chass.utoronto.ca> References: <1256869503-sup-9699@ntdws12.chass.utoronto.ca> <1256918919-sup-7569@ntdws12.chass.utoronto.ca> Message-ID: btw there's apparently a missing step in my directions somewhere.. it's missing "libtalloc.so.1" from the package I made at least. so maby the "make install" is broken or something libtalloc is from samba itself, and does get built. From phil at bolthole.com Fri Oct 30 18:52:37 2009 From: phil at bolthole.com (Philip Brown) Date: Fri, 30 Oct 2009 10:52:37 -0700 Subject: [csw-maintainers] final request for samba In-Reply-To: References: <1256869503-sup-9699@ntdws12.chass.utoronto.ca> <1256918919-sup-7569@ntdws12.chass.utoronto.ca> Message-ID: oh. also, apparently, libtdb.so.1 libwbclient.so.0