From pfelecan at opencsw.org Fri Jun 1 09:25:16 2012 From: pfelecan at opencsw.org (pfelecan at opencsw.org) Date: Fri, 1 Jun 2012 09:25:16 +0200 (CEST) Subject: [csw-maintainers] GAR: DISTFILES documentation (continued) Message-ID: <38071dfca374f9d9732e6eebebb18980.squirrel@mail.opencsw.org> I discovered (by reading the source Luke) that adding a file of the form CSWfoo.postinstall to DISTFILES uses it as a postinstall script for the foo package. This feature is not documented... Are there some other magic related to DISTFILES? In the affirmative, it should be documented by the knowledgeable persons (among which I'm not). TIA From maciej at opencsw.org Fri Jun 1 10:44:32 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 1 Jun 2012 09:44:32 +0100 Subject: [csw-maintainers] GAR: DISTFILES documentation (continued) In-Reply-To: <38071dfca374f9d9732e6eebebb18980.squirrel@mail.opencsw.org> References: <38071dfca374f9d9732e6eebebb18980.squirrel@mail.opencsw.org> Message-ID: 2012/6/1 > I discovered (by reading the source Luke) that adding a file of the form > CSWfoo.postinstall to DISTFILES uses it as a postinstall script for the > foo package. Yes, I find it a bit silly. I understand that there needs to be a way to declare that there's a postinstall script, but the current way is strange. By the way, this is an excellent example of why people who already use GAR are next to useless at documenting. When I asked myself ?what's there to be told about DISTFILES?, I only thought ?it's just the file you want to unpack?, and I forgot about the postinstall thing altogether. If I asked myself ?how do I create a postinstall script??, I would immediately say: ?You put it in files/ and you add it to DISTFILES?. But if you ask from the DISTFILES direction, the postinstall issue doesn't come up. This is how indexing works in the brain, I guess. > This feature is not documented... Are there some other magic related to > DISTFILES? In the affirmative, it should be documented by the > knowledgeable persons (among which I'm not). I just added the information about CSWfoo.postinstall. If there's more magic, I'm not sure, I can't think of anything right now. Maciej From dam at opencsw.org Fri Jun 1 14:49:51 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 1 Jun 2012 14:49:51 +0200 Subject: [csw-maintainers] how to express dependencies on alternatives? In-Reply-To: References: Message-ID: Hi Peter, Am 31.05.2012 um 10:25 schrieb pfelecan at opencsw.org: > Emacs new packaging uses the alternatives system. > > There are packages, such as auctex, depending on the generic Emacs at > run-time and/or build time. > > How can I express such dependencies? > > Concretely: auctex depends (build and run-time) on emacs (the X11 > Athena based widget) or emacs_gtk or emacs_nox. There is another possibility I use for https://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/gnuplot/trunk/Makefile There is a base package with basic dependencies and a more features one like gnuplot_wx which has alternatives with higher priority which only contains the more enhanced binaries. You can depend and run the basic one and the more featurefull is used when installed. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From pfelecan at opencsw.org Fri Jun 1 15:25:08 2012 From: pfelecan at opencsw.org (pfelecan at opencsw.org) Date: Fri, 1 Jun 2012 15:25:08 +0200 (CEST) Subject: [csw-maintainers] GAR: PKGFILES value to obtain an empty package Message-ID: <2684685e5dbb317f7b2ec3afd1c3691b.squirrel@mail.opencsw.org> What can I put in the PKGFILES_CSWfoo to obtain a empty foo package; I wish to use this package as a "meta-package" for dependencies purpose. What's strange is that when I set PKGFILES_CSWfoo to empty it gathers all the remaining files even tough there is a first package in PACKAGES which get them also... Me confused From dam at opencsw.org Fri Jun 1 15:26:49 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 1 Jun 2012 15:26:49 +0200 Subject: [csw-maintainers] GAR: PKGFILES value to obtain an empty package In-Reply-To: <2684685e5dbb317f7b2ec3afd1c3691b.squirrel@mail.opencsw.org> References: <2684685e5dbb317f7b2ec3afd1c3691b.squirrel@mail.opencsw.org> Message-ID: <4BAEBEE3-21B2-4A90-B649-B5F071B2D85D@opencsw.org> Hi Peter, Am 01.06.2012 um 15:25 schrieb pfelecan at opencsw.org: > What can I put in the PKGFILES_CSWfoo to obtain a empty foo package; I > wish to use this package as a "meta-package" for dependencies purpose. > > What's strange is that when I set PKGFILES_CSWfoo to empty it gathers all > the remaining files even tough there is a first package in PACKAGES which > get them also... Yes, that means "catchall". You can add something not matching, I usually use PKGFILE_CSWfoo = NOFILES Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From bwalton at opencsw.org Fri Jun 1 15:28:25 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 01 Jun 2012 09:28:25 -0400 Subject: [csw-maintainers] GAR: PKGFILES value to obtain an empty package In-Reply-To: <2684685e5dbb317f7b2ec3afd1c3691b.squirrel@mail.opencsw.org> References: <2684685e5dbb317f7b2ec3afd1c3691b.squirrel@mail.opencsw.org> Message-ID: <1338557259-sup-2126@pinkfloyd.chass.utoronto.ca> Excerpts from pfelecan's message of Fri Jun 01 09:25:08 -0400 2012: Hi Peter, > What can I put in the PKGFILES_CSWfoo to obtain a empty foo package; > I wish to use this package as a "meta-package" for dependencies > purpose. You can set it to the special value NOFILES. > What's strange is that when I set PKGFILES_CSWfoo to empty it > gathers all the remaining files even tough there is a first package > in PACKAGES which get them also... This can happen depending on what the GARNAME variable is in relation to CSWfoo. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Sat Jun 2 10:31:15 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 02 Jun 2012 10:31:15 +0200 Subject: [csw-maintainers] GAR: DISTFILES documentation In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Thu, 31 May 2012 21:43:28 +0100") References: <74da55a4f38db9d79419fddb6d488adb.squirrel@mail.opencsw.org> Message-ID: "Maciej (Matchek) Blizi?ski" writes: > Alright, I've put in a short description and removed the obsolete information. Tx > I'm not sure what more would you like there to be. It's usually just > one file, the tarball, not much philosophy in there. If you have more > than one source file, then there's a lot more you have to do, like > custom unpack targets. That would be best described via an example. Is > that what you're looking for? What's your use case? Yes, a rich example please! My use case is solved and can be seen in the Emacs recipe. -- Peter From pfelecan at opencsw.org Sat Jun 2 10:34:01 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 02 Jun 2012 10:34:01 +0200 Subject: [csw-maintainers] how to express dependencies on alternatives? In-Reply-To: (Dagobert Michelsen's message of "Fri, 1 Jun 2012 14:49:51 +0200") References: Message-ID: Dagobert Michelsen writes: > Hi Peter, > > Am 31.05.2012 um 10:25 schrieb pfelecan at opencsw.org: >> Emacs new packaging uses the alternatives system. >> >> There are packages, such as auctex, depending on the generic Emacs at >> run-time and/or build time. >> >> How can I express such dependencies? >> >> Concretely: auctex depends (build and run-time) on emacs (the X11 >> Athena based widget) or emacs_gtk or emacs_nox. > > There is another possibility I use for > https://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/gnuplot/trunk/Makefile > There is a base package with basic dependencies and a more features one like > gnuplot_wx > which has alternatives with higher priority which only contains the more enhanced > binaries. You can depend and run the basic one and the more featurefull is used > when installed. Thank you. Finally I'm using Joerg and Ben proposed solution as it fits well with my use case. -- Peter From pfelecan at opencsw.org Sat Jun 2 10:36:34 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 02 Jun 2012 10:36:34 +0200 Subject: [csw-maintainers] GAR: PKGFILES value to obtain an empty package In-Reply-To: <4BAEBEE3-21B2-4A90-B649-B5F071B2D85D@opencsw.org> (Dagobert Michelsen's message of "Fri, 1 Jun 2012 15:26:49 +0200") References: <2684685e5dbb317f7b2ec3afd1c3691b.squirrel@mail.opencsw.org> <4BAEBEE3-21B2-4A90-B649-B5F071B2D85D@opencsw.org> Message-ID: Dagobert Michelsen writes: > Hi Peter, > > Am 01.06.2012 um 15:25 schrieb pfelecan at opencsw.org: >> What can I put in the PKGFILES_CSWfoo to obtain a empty foo package; I >> wish to use this package as a "meta-package" for dependencies purpose. >> >> What's strange is that when I set PKGFILES_CSWfoo to empty it gathers all >> the remaining files even tough there is a first package in PACKAGES which >> get them also... > > Yes, that means "catchall". You can add something not matching, I usually use > PKGFILE_CSWfoo = NOFILES Alright. But the documentation says that the first package in the list contained by PACKAGES variable gets all the non "catched" files. In my case, the first *and* the empty valued PKGFILE_CSWfoo got all those files resulting in 2 packages having the same files! Funny, isn't it? -- Peter From pfelecan at opencsw.org Sat Jun 2 10:38:51 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 02 Jun 2012 10:38:51 +0200 Subject: [csw-maintainers] GAR: PKGFILES value to obtain an empty package In-Reply-To: <1338557259-sup-2126@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Fri, 01 Jun 2012 09:28:25 -0400") References: <2684685e5dbb317f7b2ec3afd1c3691b.squirrel@mail.opencsw.org> <1338557259-sup-2126@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > Excerpts from pfelecan's message of Fri Jun 01 09:25:08 -0400 2012: > > Hi Peter, > >> What can I put in the PKGFILES_CSWfoo to obtain a empty foo package; >> I wish to use this package as a "meta-package" for dependencies >> purpose. > > You can set it to the special value NOFILES. Tx. I used this solution to my satisfaction. >> What's strange is that when I set PKGFILES_CSWfoo to empty it >> gathers all the remaining files even tough there is a first package >> in PACKAGES which get them also... > > This can happen depending on what the GARNAME variable is in relation > to CSWfoo. This is probably the case as the empty package is named CSWemacs, the firs package in the PACKAGES is CSWemacs-common and GARNAME is emacs. Fits your hypothesis but fuzz the documentation... -- Peter From dam at opencsw.org Sat Jun 2 16:48:39 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 2 Jun 2012 16:48:39 +0200 Subject: [csw-maintainers] GAR: PKGFILES value to obtain an empty package In-Reply-To: References: <2684685e5dbb317f7b2ec3afd1c3691b.squirrel@mail.opencsw.org> <4BAEBEE3-21B2-4A90-B649-B5F071B2D85D@opencsw.org> Message-ID: <5504EBC1-FC4E-4912-80A1-946332B14B6F@opencsw.org> Hi Peter, Am 02.06.2012 um 10:36 schrieb Peter FELECAN: > Dagobert Michelsen writes: >> Am 01.06.2012 um 15:25 schrieb pfelecan at opencsw.org: >>> What can I put in the PKGFILES_CSWfoo to obtain a empty foo package; I >>> wish to use this package as a "meta-package" for dependencies purpose. >>> >>> What's strange is that when I set PKGFILES_CSWfoo to empty it gathers all >>> the remaining files even tough there is a first package in PACKAGES which >>> get them also... >> >> Yes, that means "catchall". You can add something not matching, I usually use >> PKGFILE_CSWfoo = NOFILES > > Alright. But the documentation says that the first package in the list > contained by PACKAGES variable gets all the non "catched" files. In my > case, the first *and* the empty valued PKGFILE_CSWfoo got all those > files resulting in 2 packages having the same files! Funny, isn't it? Thanks for pointing this out. The documentation was wrong, I fixed it so it correctly resembles the internals in the GAR Variable Reference. Best regards -- Dago From rupert at opencsw.org Sat Jun 2 20:26:48 2012 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 2 Jun 2012 20:26:48 +0200 Subject: [csw-maintainers] getting rid of lib..._devel_stub ? Message-ID: hi, after what timeframe do you think one might get rid of transitional packages like: libserf_devel_stub-1.0.3,REV=2012.06.02-SunOS5.9-all-CSW.pkg.gz rupert. From bwalton at opencsw.org Sat Jun 2 20:29:15 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 02 Jun 2012 14:29:15 -0400 Subject: [csw-maintainers] getting rid of lib..._devel_stub ? In-Reply-To: References: Message-ID: <1338661689-sup-7230@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Sat Jun 02 14:26:48 -0400 2012: Hi Rupert, > after what timeframe do you think one might get rid of transitional > packages like: > libserf_devel_stub-1.0.3,REV=2012.06.02-SunOS5.9-all-CSW.pkg.gz They should stay in the catalog until we transition through releases (eg: if it's in dublin, it could be dropped from kiel). But...you can drop it from your recipe once it's been released. Or if you want to keep it as a marker (I do this in my recipes), you can simply omit them from the push via csw-upload-pkg. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sun Jun 3 19:41:01 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 3 Jun 2012 18:41:01 +0100 Subject: [csw-maintainers] dublin* build hosts ready In-Reply-To: <4FC732C6.5010405@opencsw.org> References: <5739176F-BCA6-4403-89F9-69C736CE014D@opencsw.org> <4FC732C6.5010405@opencsw.org> Message-ID: 2012/5/31 Jan Holzhueter > I think it might be a good thing to just allow a few people to push > stuff into dublin/names releases directly. (Some kind of review/fix > integration board). > > I know it might delay stuff but I think it's worth it. I would be generally loathing to add human-based middle steps between maintainers and catalogs. > Second thought would be to have another catalog like named-staging. > Where everyone can add stuff to this is then pushed to named-release. We potentially could do something like it. It would introduce more complexity to the way we operate catalogs. What I'm mostly concerned here is that maintainers can inadvertently push packages to dublin. We only need some safety mechanism so the risk is minimized and we'll be grand. From maciej at opencsw.org Sun Jun 3 21:13:27 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 3 Jun 2012 20:13:27 +0100 Subject: [csw-maintainers] GAR: DISTFILES documentation In-Reply-To: References: <74da55a4f38db9d79419fddb6d488adb.squirrel@mail.opencsw.org> Message-ID: 2012/6/2 Peter FELECAN : >> I'm not sure what more would you like there to be. It's usually just >> one file, the tarball, not much philosophy in there. If you have more >> than one source file, then there's a lot more you have to do, like >> custom unpack targets. That would be best described via an example. Is >> that what you're looking for? What's your use case? > > Yes, a rich example please! My use case is solved and can be seen in the > Emacs recipe. docbook-dtds is a package with multiple sources. http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/docbook-dtds/trunk/Makefile There are custom extractors in the recipe. From bwalton at opencsw.org Sun Jun 3 21:16:32 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 03 Jun 2012 15:16:32 -0400 Subject: [csw-maintainers] GAR: DISTFILES documentation In-Reply-To: References: <74da55a4f38db9d79419fddb6d488adb.squirrel@mail.opencsw.org> Message-ID: <1338750931-sup-4957@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Sun Jun 03 15:13:27 -0400 2012: > 2012/6/2 Peter FELECAN : > >> I'm not sure what more would you like there to be. It's usually > >> just one file, the tarball, not much philosophy in there. If you > >> have more than one source file, then there's a lot more you have > >> to do, like custom unpack targets. That would be best described > >> via an example. Is that what you're looking for? What's your use > >> case? > > > > Yes, a rich example please! My use case is solved and can be seen > > in the Emacs recipe. > > docbook-dtds is a package with multiple sources. > > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/docbook-dtds/trunk/Makefile > > There are custom extractors in the recipe. ...I'd completely forgotten about that one. That was one of my first packages, too. Lots of fun! :) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Jun 4 02:04:24 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 03 Jun 2012 20:04:24 -0400 Subject: [csw-maintainers] dublin* build hosts ready In-Reply-To: References: <5739176F-BCA6-4403-89F9-69C736CE014D@opencsw.org> <4FC732C6.5010405@opencsw.org> Message-ID: <1338768076-sup-4251@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Sun Jun 03 13:41:01 -0400 2012: > 2012/5/31 Jan Holzhueter > > I think it might be a good thing to just allow a few people to > > push stuff into dublin/names releases directly. (Some kind of > > review/fix integration board). > > > > I know it might delay stuff but I think it's worth it. > > I would be generally loathing to add human-based middle steps between > maintainers and catalogs. I agree with this. We really don't want to inject the spof that we had previously. But we do need a sane mechanism for this. I wonder if some sort of shadow catalog (dublin-shadow) that allowed direct push might work. Then, a publish mechanism like we have for unstable -> dublin could be used. > We potentially could do something like it. It would introduce more > complexity to the way we operate catalogs. What I'm mostly concerned > here is that maintainers can inadvertently push packages to > dublin. We only need some safety mechanism so the risk is minimized > and we'll be grand. Yes, this is good. We don't (ever, I think) want a direct push to a published 'stable' catalog. There should always be a level of indirection and the ability to have all changes to a stable catalog publicly vetted. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Jun 4 02:16:48 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 03 Jun 2012 20:16:48 -0400 Subject: [csw-maintainers] Killing the stable release In-Reply-To: References: <41A15E2D-E4AF-478F-8857-7EBF174A094D@opencsw.org> <20120317202421.GA6624@quince.home.blizinski.pl> <1164597C-ECF0-43CC-81C5-0652AD58A223@opencsw.org> Message-ID: <1338768971-sup-6632@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Wed May 23 09:47:26 -0400 2012: > This needs to be implemented, and unless someone takes it on, we > won't have it. If no one can implement this, I suggest we revert to > the simpler plan of: > > mv stable stable-dead > > This is something we can easily do, and it will accomplish the > primary goal: communicating to users that stable is dead. I vote for stable-dead. Lets kill this zombie. We can always implement the nicer mechanism later. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Tue Jun 5 10:21:35 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 5 Jun 2012 09:21:35 +0100 Subject: [csw-maintainers] GCC-4.7 on the buildfarm Message-ID: I've pushed GCC-4.7 to unstable some time ago. What do people think of installing 4.7 on the buildfarm and bumping GAR settings to use it? We'd also need to make the GCC version variable, e.g. dublin build hosts would use 4.6 and unstable hosts would use 4.7. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfelecan at opencsw.org Tue Jun 5 20:01:30 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 05 Jun 2012 20:01:30 +0200 Subject: [csw-maintainers] GCC-4.7 on the buildfarm In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Tue, 5 Jun 2012 09:21:35 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > I've pushed GCC-4.7 to unstable some time ago. What do people think of > installing 4.7 on the buildfarm and bumping GAR settings to use it? +1 as I requested its installation. If you wish I can test Emacs packaging with the 4.7 in my build-farm. > We'd also need to make the GCC version variable, e.g. dublin build hosts > would use 4.6 and unstable hosts would use 4.7. Yes, these steps are required. -- Peter From bwalton at opencsw.org Tue Jun 5 20:30:15 2012 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 05 Jun 2012 14:30:15 -0400 Subject: [csw-maintainers] GCC-4.7 on the buildfarm In-Reply-To: References: Message-ID: <1338920931-sup-8127@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Tue Jun 05 14:01:30 -0400 2012: > > I've pushed GCC-4.7 to unstable some time ago. What do people > > think of installing 4.7 on the buildfarm and bumping GAR settings > > to use it? > > +1 as I requested its installation. If you wish I can test Emacs > packaging with the 4.7 in my build-farm. > > > We'd also need to make the GCC version variable, e.g. dublin build hosts > > would use 4.6 and unstable hosts would use 4.7. > > Yes, these steps are required. +1 for me too. We should definitely make use of it. Will there be any issue with libgcc_s.so versions between unstable/dublin? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Tue Jun 5 22:27:55 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 5 Jun 2012 21:27:55 +0100 Subject: [csw-maintainers] GCC-4.7 on the buildfarm In-Reply-To: <1338920931-sup-8127@pinkfloyd.chass.utoronto.ca> References: <1338920931-sup-8127@pinkfloyd.chass.utoronto.ca> Message-ID: 2012/6/5 Ben Walton > +1 for me too. ?We should definitely make use of it. ?Will there be > any issue with libgcc_s.so versions between unstable/dublin? I don't expect any issues. As long as the soname is the same, it will work fine. From romeotheriault at opencsw.org Wed Jun 6 05:49:57 2012 From: romeotheriault at opencsw.org (Romeo Theriault) Date: Tue, 05 Jun 2012 17:49:57 -1000 Subject: [csw-maintainers] Greetings Message-ID: Hi, I'm a new opencsw package maintainer. I wanted to send out a quick email to introduce myself. My name is Romeo Theriault. I'm a Systems/SAN administrator for the University of Hawaii System. Prior to this I was a SA/SAN admin for the University of Maine System. With both of these jobs I've been working with Solaris. I've created a few custom solaris packages over the years but am by no means a expert packager. So I have some learning to do in this area, which I'm looking forward to. I requested to become a opencsw package maintainer for the following piece of software: Salt (http://saltstack.org/) Salt is a remote execution and configuration management tool, in a similar vein of puppet and chef. Currently their solaris support is very weak and I'd like to help them get stronger solaris support. First thing to do is make installing it on solaris an easy thing to do. This is my primary motivation to become a opencsw package maintainer. Salt has the following package dependecies: Python 2.6 ZeroMQ >= 2.1.9 pyzmq >= 2.1.9 - ZeroMQ Python bindings PyCrypto - The Python cryptography toolkit msgpack-python - High-performance message interchange format YAML - Python YAML bindings some of which are already maintained in opencsw, which is great. The following don't appear to be: zeromq pyzmq msgpack-python so I'm planning to package and maintain these packages as well. Thank you, Romeo Theriault From maciej at opencsw.org Wed Jun 6 08:07:32 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 6 Jun 2012 07:07:32 +0100 Subject: [csw-maintainers] Greetings In-Reply-To: References: Message-ID: 2012/6/6 Romeo Theriault : > My name is Romeo Theriault. I'm a Systems/SAN administrator for the > University of Hawaii System. Prior to this I was a SA/SAN admin for > the University of Maine System. With both of these jobs I've been > working with Solaris. I've created a few custom solaris packages over > the years but am by no means a expert packager. So I have some > learning to do in this area, which I'm looking forward to. I requested > to become a opencsw package maintainer for the following piece of > software: Salt (http://saltstack.org/) Welcome aboard, Romeo! Packaging Salt is a very cool undertaking. Also, ZeroMQ is a very interesting project which I wanted us to have in the catalog. Something I always ask for when a new member joins the project, is feedback on the documentation. We know that it's outdated, unclear or plain wrong, but we don't see it, because we have all the knowledge ready in our brains, and we don't notice. Only a new member actually sees when something is unclear or missing. So please do point out places where documentation needs to be updated or corrected. If you can, feel free to correct the docs yourself (do you have an account on wiki.opencsw.org?) or write to maintainers@ with your comments. You're also welcome on the IRC channel for quick help. I'm not sure how time zones will work out ? most people are in CEST, with some people in EST and some in PST. I see that your evenings overlap with CEST mornings, so this might be the best time to meet online. Maciej From grzemba at contac-dt.de Wed Jun 6 14:40:11 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Wed, 06 Jun 2012 14:40:11 +0200 Subject: [csw-maintainers] Please install on Buildfarm (Solaris10) QT4-gxx Message-ID: <7430aa423077.4fcf6bcb@contac-dt.de> for build package LibreCAD (successor of QCAD) please install on buildfarm * gt4_gxx_dev * qt4_gxx_doc Thanks -- Carsten Grzemba -------------- next part -------------- An HTML attachment was scrubbed... URL: From grzemba at contac-dt.de Wed Jun 6 17:16:41 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Wed, 06 Jun 2012 17:16:41 +0200 Subject: [csw-maintainers] Please install on Buildfarm (Solaris10) QT4-gxx In-Reply-To: <74309cdf447d.4fcf741f@contac-dt.de> References: <74309cdf447d.4fcf741f@contac-dt.de> Message-ID: <7430c74225ee.4fcf9079@contac-dt.de> Its a little bit crazy sparc needs this, i386 hates this dependencies: CHECKPKG_OVERRIDES_CSWqt4-gxx-dev += surplus-dependency|CSWlibfreetype6 CHECKPKG_OVERRIDES_CSWqt4-gxx-dev += surplus-dependency|CSWlibfontconfig1 CHECKPKG_OVERRIDES_CSWlibqtgui4-gxx += surplus-dependency|CSWlibfontconfig1 CHECKPKG_OVERRIDES_CSWlibqtgui4-gxx += surplus-dependency|CSWlibgobject2-0-0 CHECKPKG_OVERRIDES_CSWlibqtgui4-gxx += surplus-dependency|CSWlibfreetype6 CHECKPKG_OVERRIDES_CSWlibqtopengl4-gxx += surplus-dependency|CSWlibfontconfig1 CHECKPKG_OVERRIDES_CSWlibqtopengl4-gxx += surplus-dependency|CSWlibfreetype6 ??? Am 06.06.12, schrieb Ben Walton : > Excerpts from Carsten Grzemba's message of Wed Jun 06 08:40:11 -0400 2012: > > Hi Carsten, > > [+buildfarm, -maintainers] > > > for build package LibreCAD (successor of QCAD) please install on buildfarm > > > > * gt4_gxx_dev > > * qt4_gxx_doc > > These aren't visible in the catalog.? Did you just push them recently? > > Thanks > -Ben > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > > -- Carsten Grzemba Tel.:?? +49 3677 64740 Mobil: +49 171 9749479 Fax::?? +49 3677 6474111 Email: carsten.grzemba at contac-dt.de contac Datentechnik GmbH -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Wed Jun 6 19:31:28 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 6 Jun 2012 18:31:28 +0100 Subject: [csw-maintainers] Please install on Buildfarm (Solaris10) QT4-gxx In-Reply-To: <7430c74225ee.4fcf9079@contac-dt.de> References: <74309cdf447d.4fcf741f@contac-dt.de> <7430c74225ee.4fcf9079@contac-dt.de> Message-ID: 2012/6/6 Carsten Grzemba > > Its a little bit crazy sparc needs this, i386 hates this dependencies: > > CHECKPKG_OVERRIDES_CSWqt4-gxx-dev += surplus-dependency|CSWlibfreetype6 > CHECKPKG_OVERRIDES_CSWqt4-gxx-dev += surplus-dependency|CSWlibfontconfig1 > CHECKPKG_OVERRIDES_CSWlibqtgui4-gxx += surplus-dependency|CSWlibfontconfig1 > CHECKPKG_OVERRIDES_CSWlibqtgui4-gxx += surplus-dependency|CSWlibgobject2-0-0 > CHECKPKG_OVERRIDES_CSWlibqtgui4-gxx += surplus-dependency|CSWlibfreetype6 > CHECKPKG_OVERRIDES_CSWlibqtopengl4-gxx += surplus-dependency|CSWlibfontconfig1 > CHECKPKG_OVERRIDES_CSWlibqtopengl4-gxx += surplus-dependency|CSWlibfreetype6 > > ??? A couple of ideas what could be going on: - header files not installed on sparc - header files installed but not found - header files installed and found but broken because of compiler flag differences (studio vs gcc) Try to see which one is taking place. From pfelecan at opencsw.org Wed Jun 6 19:55:39 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 06 Jun 2012 19:55:39 +0200 Subject: [csw-maintainers] GCC-4.7 on the buildfarm In-Reply-To: (Peter FELECAN's message of "Tue, 05 Jun 2012 20:01:30 +0200") References: Message-ID: Peter FELECAN writes: > +1 as I requested its installation. If you wish I can test Emacs > packaging with the 4.7 in my build-farm. FYI: building Emacs with 4.7 didn't raise any issues. -- Peter From bwalton at opencsw.org Thu Jun 7 00:47:59 2012 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 06 Jun 2012 18:47:59 -0400 Subject: [csw-maintainers] board elections 2012 In-Reply-To: <1337265633-sup-8553@pinkfloyd.chass.utoronto.ca> References: <1337265633-sup-8553@pinkfloyd.chass.utoronto.ca> Message-ID: <1339022795-sup-1395@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Thu May 17 10:45:53 -0400 2012: Hi All, > We can leave the nomination page open for a few weeks and evaluate > what that ballot would look like then. If there isn't enough > sign-up interest, I'll stir the pot some more. :) So far we've got two nominees to form the new board. Is anyone else planning to step up but hasn't done so yet? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Jun 7 03:19:24 2012 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 06 Jun 2012 21:19:24 -0400 Subject: [csw-maintainers] openssl relinking effort Message-ID: <1339031740-sup-6645@pinkfloyd.chass.utoronto.ca> Hi All, If you're maintaining a package the links with openssl and you haven't re-rolled your package to use the newly released 1.0.0, I'd like to solicit a few of your cycles to do so. We currently have a situation where many programs will end up pulling in both library versions (0.9.8 and 1.0.0) at runtime causing some of them to explode. I was thinking that we could organize a somewhat informal hack-a-thon and do a G+ hangout while we batch update lots of these packages. It's getting into vacation time so this might be hard to organize, but is there interest? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From romeotheriault at opencsw.org Thu Jun 7 04:19:37 2012 From: romeotheriault at opencsw.org (Romeo Theriault) Date: Wed, 06 Jun 2012 16:19:37 -1000 Subject: [csw-maintainers] Greetings In-Reply-To: References: Message-ID: On Tue, Jun 5, 2012 at 8:07 PM, Maciej (Matchek) Blizi?ski wrote: > Welcome aboard, Romeo! Packaging Salt is a very cool undertaking. > Also, ZeroMQ is a very interesting project which I wanted us to have > in the catalog. Hi Maciej, Thanks! Glad I'll be bringing some software that others have some interest in as well. > Something I always ask for when a new member joins the project, is > feedback on the documentation. We know that it's outdated, unclear or > plain wrong, but we don't see it, because we have all the knowledge > ready in our brains, and we don't notice. Only a new member actually > sees when something is unclear or missing. So please do point out > places where documentation needs to be updated or corrected. If you > can, feel free to correct the docs yourself (do you have an account on > wiki.opencsw.org?) or write to maintainers@ with your comments. Ok, this makes sense. I just created an account on the wiki and will try to update things or create pages that I think are relevant for newcomers. I'll wait a little while, until I feel confident I won't make matters worse before I start making any changes though :) > You're also welcome on the IRC channel for quick help. Thanks. > I'm not sure > how time zones will work out ? most people are in CEST, with some > people in EST and some in PST. I see that your evenings overlap with > CEST mornings, so this might be the best time to meet online. Good to know. Yeah, I was wondering about the timezones issue. Romeo > > Maciej > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From yann at pleiades.fr.eu.org Thu Jun 7 09:42:40 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Thu, 7 Jun 2012 09:42:40 +0200 Subject: [csw-maintainers] openssl relinking effort In-Reply-To: <1339031740-sup-6645@pinkfloyd.chass.utoronto.ca> References: <1339031740-sup-6645@pinkfloyd.chass.utoronto.ca> Message-ID: Hi Ben, That's a really good idea ! However relinking all the packages can take some times (hey there are still 3 packages linked with openssl 0.9.7), maybe it might be more efficient to focus first on the ones that really cause some problems. Until now, I only know about libneon (which explicitely checks for ssl version mismatch): https://www.opencsw.org/mantis/view.php?id=4947 I suppose we should look first for every package linked with openssl which depend on a library also linked with openssl. Can we easily extract that information from the database ? Yann 2012/6/7 Ben Walton > > Hi All, > > If you're maintaining a package the links with openssl and you haven't > re-rolled your package to use the newly released 1.0.0, I'd like to > solicit a few of your cycles to do so. > > We currently have a situation where many programs will end up pulling > in both library versions (0.9.8 and 1.0.0) at runtime causing some of > them to explode. > > I was thinking that we could organize a somewhat informal hack-a-thon > and do a G+ hangout while we batch update lots of these packages. > It's getting into vacation time so this might be hard to organize, but > is there interest? > > Thanks > -Ben > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Thu Jun 7 09:54:23 2012 From: dam at opencsw.org (dam at opencsw.org) Date: Thu, 7 Jun 2012 09:54:23 +0200 (CEST) Subject: [csw-maintainers] openssl relinking effort In-Reply-To: References: <1339031740-sup-6645@pinkfloyd.chass.utoronto.ca> Message-ID: <91d5760096d0fc856fa5d86ac534c3c2.squirrel@mail.opencsw.org> Hi Yann, > That's a really good idea ! > However relinking all the packages can take some times (hey there are > still > 3 packages linked with openssl 0.9.7), maybe it might be more efficient to > focus first on the ones that really cause some problems. > Until now, I only know about libneon (which explicitely checks for ssl > version mismatch): > https://www.opencsw.org/mantis/view.php?id=4947 Already done and pushed 10 days ago :-) http://www.opencsw.org/packages/libneon27/ I just forgot to close the bug. > I suppose we should look first for every package linked with openssl which > depend on a library also linked with openssl. > Can we easily extract that information from the database ? I set up a wiki page to track progress with basic information. We can enhance that while the project makes progress: http://wiki.opencsw.org/project-openssl Best regards -- Dago From pfelecan at opencsw.org Thu Jun 7 09:54:27 2012 From: pfelecan at opencsw.org (pfelecan at opencsw.org) Date: Thu, 7 Jun 2012 09:54:27 +0200 (CEST) Subject: [csw-maintainers] GAR: BUILD_ARGS when custom build scripts Message-ID: <2e6bfc3c7101024f2d3ec2944a8b4e7a.squirrel@mail.opencsw.org> I'm using a custom build and wish to pass specific arguments to all or some of the specific scripts. I know that using BUILD_ARGS works for standard build. How can I use a similar feature for the following: BUILD_SCRIPTS = nominal BUILD_SCRIPTS += add1 BUILD_SCRIPTS += add2 BUILD_SCRIPTS += add3 in the case that I wish to have different additional arguments? IMHO, modulations are not an option. Note that the same issue arises with other phases, such as install. TIA From maciej at opencsw.org Thu Jun 7 10:04:56 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 7 Jun 2012 09:04:56 +0100 Subject: [csw-maintainers] GAR: BUILD_ARGS when custom build scripts In-Reply-To: <2e6bfc3c7101024f2d3ec2944a8b4e7a.squirrel@mail.opencsw.org> References: <2e6bfc3c7101024f2d3ec2944a8b4e7a.squirrel@mail.opencsw.org> Message-ID: 2012/6/7 > > I'm using a custom build and wish to pass specific arguments to all or > some of the specific scripts. > > I know that using BUILD_ARGS works for standard build. > > How can I use a similar feature for the following: > > BUILD_SCRIPTS ? = ? ? ? nominal > BUILD_SCRIPTS ? += ? ? ?add1 > BUILD_SCRIPTS ? += ? ? ?add2 > BUILD_SCRIPTS ? += ? ? ?add3 > > in the case that I wish to have different additional arguments? IMHO, > modulations are not an option. > > Note that the same issue arises with other phases, such as install. I always thought that the *_SCRIPTS variable names are misnomers, referring to Make targets, and not any scripts. When you say that you're using a custom build and you wish to pass specific arguments to all or some of the specific scripts, what do you mean by 'a script'? From bonivart at opencsw.org Thu Jun 7 10:46:47 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 7 Jun 2012 10:46:47 +0200 Subject: [csw-maintainers] Greetings In-Reply-To: References: Message-ID: On Thu, Jun 7, 2012 at 4:19 AM, Romeo Theriault wrote: > I just created an account on the wiki and will > try to update things or create pages that I think are relevant for > newcomers. I'll wait a little while, until I feel confident I won't > make matters worse before I start making any changes though :) Hi, have you also applied to join the OpenCSW wiki? The wikidot account is for general access to their system, then you need to join the separate wikis. If you apply I can approve it or if you tell me your wikidot handle I can add it to our wiki. /peter From jh at opencsw.org Thu Jun 7 16:21:43 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Thu, 07 Jun 2012 16:21:43 +0200 Subject: [csw-maintainers] Default Sun Studio Compiler In-Reply-To: References: Message-ID: <4FD0B8F7.8000701@opencsw.org> Hi, if I see this correct the default Sun Studio Compiler still seems to be Sun Studio 11. What is the reason behind it? As we build Solaris 9 and mostly only 10 shouldn't we rise it to Sun Studio 12? If we rise gcc to 4.6 or soon 4.7 we should do the same for sun studio. Greetings Jan From jh at opencsw.org Thu Jun 7 16:35:16 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Thu, 07 Jun 2012 16:35:16 +0200 Subject: [csw-maintainers] Wireshark package rebuild In-Reply-To: <4FD0B8F7.8000701@opencsw.org> References: <4FD0B8F7.8000701@opencsw.org> Message-ID: <4FD0BC24.1060101@opencsw.org> Hi, I started to rebuild wireshark to use new openssl libs. The problem with wireshark is the it uses glib2. We have a never Version on solaris 10. It does build with the older version on solaris 9. So should I build an extra Version for solaris 9? How do I handle the differed dependencies in the Makefile then? Or should I just build for solaris 10? This would leave the old package on Solaris 9 in the unsure state. Thoughts? Greetings Jan From maciej at opencsw.org Thu Jun 7 17:18:58 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 7 Jun 2012 16:18:58 +0100 Subject: [csw-maintainers] Messages from non-opencsw.org addresses Message-ID: We currently have a setup in which emails sent to maintainers@ from non-opencsw addresses are held for moderation. Every now and then Ihsan looks at the queue and moderates it. Sometimes it causes old and duplicate emails to show on the mailing list. I suggest we change the configuration to such that emails are hard-bounced right away, so the sender immediately knows that the email needs to be re-sent from @opencsw.org. Any objections or thoughts? Maciej From bonivart at opencsw.org Thu Jun 7 17:22:04 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 7 Jun 2012 17:22:04 +0200 Subject: [csw-maintainers] Messages from non-opencsw.org addresses In-Reply-To: References: Message-ID: On Thu, Jun 7, 2012 at 5:18 PM, Maciej (Matchek) Blizi?ski wrote: > We currently have a setup in which emails sent to maintainers@ from > non-opencsw addresses are held for moderation. Every now and then > Ihsan looks at the queue and moderates it. Sometimes it causes old and > duplicate emails to show on the mailing list. I suggest we change the > configuration to such that emails are hard-bounced right away, so the > sender immediately knows that the email needs to be re-sent from > @opencsw.org. > > Any objections or thoughts? If that's possible I like that too. Less work for Ihsan. /peter From bwalton at opencsw.org Thu Jun 7 17:31:31 2012 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 07 Jun 2012 11:31:31 -0400 Subject: [csw-maintainers] Messages from non-opencsw.org addresses In-Reply-To: References: Message-ID: <1339083059-sup-2361@pinkfloyd.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Thu Jun 07 11:22:04 -0400 2012: > > Any objections or thoughts? > > If that's possible I like that too. Less work for Ihsan. +1. I should be able to make this reconfig if nobody disagrees. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From yann at pleiades.fr.eu.org Thu Jun 7 22:25:35 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Thu, 7 Jun 2012 22:25:35 +0200 Subject: [csw-maintainers] openssl relinking effort In-Reply-To: <91d5760096d0fc856fa5d86ac534c3c2.squirrel@mail.opencsw.org> References: <1339031740-sup-6645@pinkfloyd.chass.utoronto.ca> <91d5760096d0fc856fa5d86ac534c3c2.squirrel@mail.opencsw.org> Message-ID: 2012/6/7 > > > I suppose we should look first for every package linked with openssl > which > > depend on a library also linked with openssl. > > Can we easily extract that information from the database ? > > I set up a wiki page to track progress with basic information. We can > enhance that while the project makes progress: > http://wiki.opencsw.org/project-openssl Nice, I updated the page to highlight packages which are more likely to have problems. These are reverse dependancies of libcurl4 as it the only package I detected which currently causes some dual linking at runtime. However, we shouldn't blindly recompile libraries linked with ssl. We have to check first if their reverse dependancies are linked with openssl and in that case, we have to do a coordinated upload. BTW, does someone know under what conditions the dual linked binaries will not work ? Yann > > > > Best regards > > -- Dago > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From romeotheriault at opencsw.org Thu Jun 7 22:31:23 2012 From: romeotheriault at opencsw.org (Romeo Theriault) Date: Thu, 07 Jun 2012 10:31:23 -1000 Subject: [csw-maintainers] Greetings In-Reply-To: References: Message-ID: On Wed, Jun 6, 2012 at 10:46 PM, Peter Bonivart wrote: > Hi, have you also applied to join the OpenCSW wiki? The wikidot > account is for general access to their system, then you need to join > the separate wikis. If you apply I can approve it or if you tell me > your wikidot handle I can add it to our wiki. Thanks Peter, I did notice that after I tried to "login", after creating my wikidot account. If you could add me that'd be great. My wikidot username is 'romeotheriault'. Thank you, Romeo From bonivart at opencsw.org Thu Jun 7 22:49:27 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 7 Jun 2012 22:49:27 +0200 Subject: [csw-maintainers] Greetings In-Reply-To: References: Message-ID: On Thu, Jun 7, 2012 at 10:31 PM, Romeo Theriault wrote: > On Wed, Jun 6, 2012 at 10:46 PM, Peter Bonivart wrote: >> Hi, have you also applied to join the OpenCSW wiki? The wikidot >> account is for general access to their system, then you need to join >> the separate wikis. If you apply I can approve it or if you tell me >> your wikidot handle I can add it to our wiki. > > Thanks Peter, I did notice that after I tried to "login", after > creating my wikidot account. If you could add me that'd be great. My > wikidot username is 'romeotheriault'. I sent you an invite, if you accept that you're a member. /peter From bwalton at opencsw.org Fri Jun 8 04:44:03 2012 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 07 Jun 2012 22:44:03 -0400 Subject: [csw-maintainers] openssl relinking effort In-Reply-To: References: <1339031740-sup-6645@pinkfloyd.chass.utoronto.ca> Message-ID: <1339123346-sup-3285@pinkfloyd.chass.utoronto.ca> Excerpts from Yann Rouillard's message of Thu Jun 07 03:42:40 -0400 2012: Hi Yann, > I suppose we should look first for every package linked with openssl > which depend on a library also linked with openssl. Can we easily > extract that information from the database ? Yes, we should target packages that can lead to double-inclusion first. Anything else could be 'as needed.' Exim is another example of a package where both versions of the library are included. The double-include there is via openldap. In my own personal use of exim this won't hurt, but anyone doing ldap lookups could expect some problems, I think. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From romeotheriault at opencsw.org Fri Jun 8 05:26:10 2012 From: romeotheriault at opencsw.org (Romeo Theriault) Date: Thu, 07 Jun 2012 17:26:10 -1000 Subject: [csw-maintainers] Greetings In-Reply-To: References: Message-ID: On Thu, Jun 7, 2012 at 10:49 AM, Peter Bonivart wrote: > I sent you an invite, if you accept that you're a member. Thank you, accepted. Romeo From bonivart at opencsw.org Fri Jun 8 09:40:16 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 8 Jun 2012 09:40:16 +0200 Subject: [csw-maintainers] Greetings In-Reply-To: References: Message-ID: On Fri, Jun 8, 2012 at 5:26 AM, Romeo Theriault wrote: > On Thu, Jun 7, 2012 at 10:49 AM, Peter Bonivart wrote: > >> I sent you an invite, if you accept that you're a member. > > Thank you, accepted. Now I see you listed as a member so you should be able to add/edit pages. /peter From jeff at cjsa.com Fri Jun 8 10:14:39 2012 From: jeff at cjsa.com (Jeffery Small) Date: Fri, 8 Jun 2012 08:14:39 GMT Subject: [csw-maintainers] New version of Gimp out Message-ID: Gimp 2.8 is now out. It would be nice to update to the new version when possible. The website says that Phil Brown is the maintainer, so this package may get dead-ended unless someone else picks it up. Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From maciej at opencsw.org Fri Jun 8 10:40:14 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 8 Jun 2012 09:40:14 +0100 Subject: [csw-maintainers] New version of Gimp out In-Reply-To: References: Message-ID: 2012/6/8 Jeffery Small : > Gimp 2.8 is now out. ?It would be nice to update to the new version when > possible. ?The website says that Phil Brown is the maintainer, so this > package may get dead-ended unless someone else picks it up. As a team, we focus more on server software these days. We mostly do efforts if there are specific requests for new packages or updates. There was once an idea to form a desktop team[1], but it didn't take off. People who use specific software are best maintainers, because they can tell if something works well or not. I'm curious, who here is actually using desktop applications on Solaris? (I'm not.) Maciej [1] http://lists.opencsw.org/pipermail/maintainers/2010-June/012358.html From yann at pleiades.fr.eu.org Fri Jun 8 11:11:34 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Fri, 8 Jun 2012 11:11:34 +0200 Subject: [csw-maintainers] openssl relinking effort In-Reply-To: <1339123346-sup-3285@pinkfloyd.chass.utoronto.ca> References: <1339031740-sup-6645@pinkfloyd.chass.utoronto.ca> <1339123346-sup-3285@pinkfloyd.chass.utoronto.ca> Message-ID: 2012/6/8 Ben Walton > Excerpts from Yann Rouillard's message of Thu Jun 07 03:42:40 -0400 2012: > > Hi Yann, > > > I suppose we should look first for every package linked with openssl > > which depend on a library also linked with openssl. Can we easily > > extract that information from the database ? > > Yes, we should target packages that can lead to double-inclusion > first. Anything else could be 'as needed.' > > Exim is another example of a package where both versions of the > library are included. The double-include there is via openldap. In > my own personal use of exim this won't hurt, but anyone doing ldap > lookups could expect some problems, I think. > Currently, both are linked with openssl 0.9.8, so you need to coordinate the upload of the new package with the upload of the new libldap2_4_2 package. I think we should rather re-arrange the wiki page to group packages which need to be uploaded together. I will try to do this. Yann > > Thanks > -Ben > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfelecan at opencsw.org Fri Jun 8 13:47:51 2012 From: pfelecan at opencsw.org (pfelecan at opencsw.org) Date: Fri, 8 Jun 2012 13:47:51 +0200 (CEST) Subject: [csw-maintainers] GAR: documentation: STRIP_LIBTOOL Message-ID: <550d3d5afb8b1b7e6b4a522e73d5af60.squirrel@mail.opencsw.org> I discovered the STRIP_LIBTOOL variable. I used it successfully but I think that it should be documented by those who implemented its usage. TIA From bwalton at opencsw.org Fri Jun 8 13:47:55 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 08 Jun 2012 07:47:55 -0400 Subject: [csw-maintainers] openssl relinking effort In-Reply-To: References: <1339031740-sup-6645@pinkfloyd.chass.utoronto.ca> <1339123346-sup-3285@pinkfloyd.chass.utoronto.ca> Message-ID: <1339155965-sup-1860@pinkfloyd.chass.utoronto.ca> Excerpts from Yann Rouillard's message of Fri Jun 08 05:11:34 -0400 2012: Hi Yann, > Currently, both are linked with openssl 0.9.8, so you need to > coordinate the upload of the new package with the upload of the new > libldap2_4_2 package. Yes, I forgot to mention that I was using my packages in experimental as my reference. Should we simply collect these updated packages in an experimental project named openssl-relinking or something? That would make them all visible in one place and easy to install as a group. > I think we should rather re-arrange the wiki page to group packages > which need to be uploaded together. I will try to do this. This is a good idea too. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Fri Jun 8 13:55:03 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 8 Jun 2012 13:55:03 +0200 Subject: [csw-maintainers] openssl relinking effort In-Reply-To: <1339155965-sup-1860@pinkfloyd.chass.utoronto.ca> References: <1339031740-sup-6645@pinkfloyd.chass.utoronto.ca> <1339123346-sup-3285@pinkfloyd.chass.utoronto.ca> <1339155965-sup-1860@pinkfloyd.chass.utoronto.ca> Message-ID: <0C42B21B-EA86-4E76-B6F6-D404BE9096A1@opencsw.org> Hi Ben, Am 08.06.2012 um 13:47 schrieb Ben Walton: > Excerpts from Yann Rouillard's message of Fri Jun 08 05:11:34 -0400 2012: >> Currently, both are linked with openssl 0.9.8, so you need to >> coordinate the upload of the new package with the upload of the new >> libldap2_4_2 package. > > Yes, I forgot to mention that I was using my packages in experimental > as my reference. Should we simply collect these updated packages in > an experimental project named openssl-relinking or something? That > would make them all visible in one place and easy to install as a > group. Done. Best regards -- Dago From maciej at opencsw.org Fri Jun 8 14:53:47 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 8 Jun 2012 13:53:47 +0100 Subject: [csw-maintainers] openssl relinking effort In-Reply-To: <0C42B21B-EA86-4E76-B6F6-D404BE9096A1@opencsw.org> References: <1339031740-sup-6645@pinkfloyd.chass.utoronto.ca> <1339123346-sup-3285@pinkfloyd.chass.utoronto.ca> <1339155965-sup-1860@pinkfloyd.chass.utoronto.ca> <0C42B21B-EA86-4E76-B6F6-D404BE9096A1@opencsw.org> Message-ID: I noticed that the package libssl1_0_0 contains not one, but two shared objects: http://buildfarm.opencsw.org/pkgdb/srv4/b60e3199428815622085fb93557a669f/files/ File: /opt/csw/lib/libcrypto.so.1.0.0 File: /opt/csw/lib/libssl.so.1.0.0 Since we're doing a larger rebuild effort right now, we should look at it now and think if it's better to have them together or separately. Here's a compiled list of sonames and numbers of dependent packages: libssl.so.0.9.7 => 5 libssl.so.0.9.8 => 167 libssl.so.1.0.0 => 1 libcrypto.so.0.9.7 => 6 libcrypto.so.0.9.8 => 197 libcrypto.so.1.0.0 => 2 So there are packages that depend on libcrypto but don't depend on libssl. If we separated libcrypto from libssl, we'd reduce the dependency footprint of ~30 packages (197 - 167) by 1 package. Thoughts? From yann at pleiades.fr.eu.org Fri Jun 8 15:28:04 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Fri, 8 Jun 2012 15:28:04 +0200 Subject: [csw-maintainers] openssl relinking effort In-Reply-To: References: <1339031740-sup-6645@pinkfloyd.chass.utoronto.ca> <1339123346-sup-3285@pinkfloyd.chass.utoronto.ca> <1339155965-sup-1860@pinkfloyd.chass.utoronto.ca> <0C42B21B-EA86-4E76-B6F6-D404BE9096A1@opencsw.org> Message-ID: Traditionnally, these two libraries are always shipped in one package in all distributions I saw, but don't see a real disadvantage to separate them in two packages. I don't see neither a strong advantage in practice. As libssl depend on libcrypto and libssl is a dependancy of a lot of common packages, I think users will seldom benefit from the reduction of the dependancy footprint and they will very often have both libraries installed (but I don't have real numbers on user installation to support that). So I am interested in hearing other opinions, but for now I am ready to follow whatever the consensus is. Yann 2012/6/8 Maciej (Matchek) Blizi?ski > I noticed that the package libssl1_0_0 contains not one, but two shared > objects: > > > http://buildfarm.opencsw.org/pkgdb/srv4/b60e3199428815622085fb93557a669f/files/ > > File: /opt/csw/lib/libcrypto.so.1.0.0 > File: /opt/csw/lib/libssl.so.1.0.0 > > Since we're doing a larger rebuild effort right now, we should look at > it now and think if it's better to have them together or separately. > > Here's a compiled list of sonames and numbers of dependent packages: > > libssl.so.0.9.7 => 5 > libssl.so.0.9.8 => 167 > libssl.so.1.0.0 => 1 > libcrypto.so.0.9.7 => 6 > libcrypto.so.0.9.8 => 197 > libcrypto.so.1.0.0 => 2 > > So there are packages that depend on libcrypto but don't depend on > libssl. If we separated libcrypto from libssl, we'd reduce the > dependency footprint of ~30 packages (197 - 167) by 1 package. > > Thoughts? > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Fri Jun 8 15:40:51 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Fri, 8 Jun 2012 15:40:51 +0200 Subject: [csw-maintainers] openssl relinking effort In-Reply-To: References: <1339031740-sup-6645@pinkfloyd.chass.utoronto.ca> <1339123346-sup-3285@pinkfloyd.chass.utoronto.ca> <1339155965-sup-1860@pinkfloyd.chass.utoronto.ca> <0C42B21B-EA86-4E76-B6F6-D404BE9096A1@opencsw.org> Message-ID: 2012/6/8 Maciej (Matchek) Blizi?ski > > So there are packages that depend on libcrypto but don't depend on > libssl. If we separated libcrypto from libssl, we'd reduce the > dependency footprint of ~30 packages (197 - 167) by 1 package. > In fact, you won't reduce the dependancy footprint in terms of numbers of packages. For the 30 packages you mentioned, the libssl dependancy will be changed in a libcrypto dependancy, but the number of dependancies will stay the same. However it will increase the dependancy footprint of the 167 packages which will depend on one additional package. But of course this will reduce the total size of the dependancies installed (by more than 1 Mb) for the ~30 packages. Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Fri Jun 8 15:50:21 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 8 Jun 2012 14:50:21 +0100 Subject: [csw-maintainers] openssl relinking effort In-Reply-To: References: <1339031740-sup-6645@pinkfloyd.chass.utoronto.ca> <1339123346-sup-3285@pinkfloyd.chass.utoronto.ca> <1339155965-sup-1860@pinkfloyd.chass.utoronto.ca> <0C42B21B-EA86-4E76-B6F6-D404BE9096A1@opencsw.org> Message-ID: 2012/6/8 Yann Rouillard : > > > 2012/6/8 Maciej (Matchek) Blizi?ski >> >> >> So there are packages that depend on libcrypto but don't depend on >> libssl. If we separated libcrypto from libssl, we'd reduce the >> dependency footprint of ~30 packages (197 - 167) by 1 package. > > > In fact, you won't reduce the dependancy footprint in terms of numbers of > packages. > For the 30 packages you mentioned, the libssl dependancy will be changed in > a libcrypto dependancy, but the number of dependancies will stay the same. > However it will increase the dependancy footprint of the 167 packages which > will depend on one additional package. Yes, I was thinking of files and bytes footprint, not package numbers. You're right that 167 packages will have an additional dependency of libcrypto. > But of course this will reduce the total size of the dependancies installed > (by more than 1 Mb) for the ~30 packages. Right, that's what I had in mind. These are the packages that depend (in terms of actual binaries, not in terms of declared 'depend' files) on libcrypto but not on libssl: CSWlibarchive2 CSWwireshark CSWlibldns1 CSWcfengine3server CSWcfengine CSWlibbind CSWldnsdrill CSWcfengine3client CSWossh CSWntp CSWrdesktop CSWbind CSWtcpdump CSWpmcryptosslbignum CSWsaslauthd CSWcfengine3utils CSWlibslp1 CSWsasl CSWlibwireshark0 CSWbindutils CSWopenslp CSWlibarchive-utils CSWcvs CSWunbound-host CSWlibtorrent CSWyapet CSWlibfbopenssl0 CSWnsd CSWosshclient It turns out to be 29 packages, because libssl itself does not count. Maciej P.S. Carsten, your code came in handy again! Thanks! From yann at pleiades.fr.eu.org Fri Jun 8 16:35:20 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Fri, 8 Jun 2012 16:35:20 +0200 Subject: [csw-maintainers] openssl relinking effort In-Reply-To: <1339155965-sup-1860@pinkfloyd.chass.utoronto.ca> References: <1339031740-sup-6645@pinkfloyd.chass.utoronto.ca> <1339123346-sup-3285@pinkfloyd.chass.utoronto.ca> <1339155965-sup-1860@pinkfloyd.chass.utoronto.ca> Message-ID: 2012/6/8 Ben Walton > > > I think we should rather re-arrange the wiki page to group packages > > which need to be uploaded together. I will try to do this. > > This is a good idea too. > This is done: http://wiki.opencsw.org/project-openssl However, the resultat is that there is a group of 80 packages which should be released together to avoid a dual linking runtime situation for any of them or for their reverse dependancies. Hmm, this will be hard to do and in fact, as libcurl4 has already been rebuilt, there are already a lot of packages which have that problem (more than the ones I highlighted in bold in fact). What are the cases of breakage that have already been found for this dual linking problem ? Yann > > Thanks > -Ben > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Fri Jun 8 18:24:00 2012 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Fri, 8 Jun 2012 17:24:00 +0100 Subject: [csw-maintainers] Distrowatch Message-ID: I just realized that we aren't listed on Distrowatch and I don't really see a reason why we shouldn't be. That we don't provide the kernel or a standalone bootable CD shouldn't disqualify us. Does anyone know of any history, did we apply in the past and have been rejected, or did we simply not apply? http://distrowatch.com/dwres.php?resource=submit Maciej From ihsan at opencsw.org Fri Jun 8 21:12:13 2012 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Fri, 08 Jun 2012 21:12:13 +0200 Subject: [csw-maintainers] At least Openssl 1.0 ! In-Reply-To: References: Message-ID: <4FD24E8D.4070007@opencsw.org> Hi Yann, Am 12.05.2012 19:50, schrieb Yann Rouillard: > Unbelievable ! Openssl 1.0 packages are close to be on their way to the > OpenCSW repository. Thank you very much for updated packages and especially for the pkcs11 support. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Fri Jun 8 21:22:42 2012 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Fri, 08 Jun 2012 21:22:42 +0200 Subject: [csw-maintainers] board elections 2012 In-Reply-To: <1339022795-sup-1395@pinkfloyd.chass.utoronto.ca> References: <1337265633-sup-8553@pinkfloyd.chass.utoronto.ca> <1339022795-sup-1395@pinkfloyd.chass.utoronto.ca> Message-ID: <4FD25102.2050102@opencsw.org> Hi, Am 07.06.2012 00:47, schrieb Ben Walton: >> We can leave the nomination page open for a few weeks and evaluate >> what that ballot would look like then. If there isn't enough >> sign-up interest, I'll stir the pot some more. :) > > So far we've got two nominees to form the new board. Is anyone else > planning to step up but hasn't done so yet? I'm stepping back as a board member and someone new should take my place. I'm in the board since the beginning and it's time for someone new. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From romeotheriault at opencsw.org Fri Jun 8 21:33:55 2012 From: romeotheriault at opencsw.org (Romeo Theriault) Date: Fri, 08 Jun 2012 09:33:55 -1000 Subject: [csw-maintainers] New version of Gimp out In-Reply-To: References: Message-ID: On Thu, Jun 7, 2012 at 10:40 PM, Maciej (Matchek) Blizi?ski wrote: > I'm curious, who here is > actually using desktop applications on Solaris? (I'm not.) Not I. Romeo From bwalton at opencsw.org Fri Jun 8 21:36:07 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 08 Jun 2012 15:36:07 -0400 Subject: [csw-maintainers] New version of Gimp out In-Reply-To: References: Message-ID: <1339184154-sup-7425@pinkfloyd.chass.utoronto.ca> Excerpts from Romeo Theriault's message of Fri Jun 08 15:33:55 -0400 2012: > > I'm curious, who here is actually using desktop applications on > > Solaris? (I'm not.) > > Not I. *crickets* Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Sat Jun 9 13:51:30 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 09 Jun 2012 13:51:30 +0200 Subject: [csw-maintainers] GAR: BUILD_ARGS when custom build scripts In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Thu, 7 Jun 2012 09:04:56 +0100") References: <2e6bfc3c7101024f2d3ec2944a8b4e7a.squirrel@mail.opencsw.org> Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2012/6/7 >> >> I'm using a custom build and wish to pass specific arguments to all or >> some of the specific scripts. >> >> I know that using BUILD_ARGS works for standard build. >> >> How can I use a similar feature for the following: >> >> BUILD_SCRIPTS ? = ? ? ? nominal >> BUILD_SCRIPTS ? += ? ? ?add1 >> BUILD_SCRIPTS ? += ? ? ?add2 >> BUILD_SCRIPTS ? += ? ? ?add3 >> >> in the case that I wish to have different additional arguments? IMHO, >> modulations are not an option. >> >> Note that the same issue arises with other phases, such as install. > > I always thought that the *_SCRIPTS variable names are misnomers, > referring to Make targets, and not any scripts. Agree. > When you say that you're using a custom build and you wish to pass > specific arguments to all or some of the specific scripts, what do you > mean by 'a script'? I mean 'target'. See autogen's recipe where the build is split in 4 targets, 3 of them having additional PATH set. -- Peter From pfelecan at opencsw.org Sat Jun 9 13:53:28 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 09 Jun 2012 13:53:28 +0200 Subject: [csw-maintainers] New version of Gimp out In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Fri, 8 Jun 2012 09:40:14 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > People who use specific software are best maintainers, because they > can tell if something works well or not. I'm curious, who here is > actually using desktop applications on Solaris? (I'm not.) I'm maintaining and using some, e.g., Emacs, grip, &c. -- Peter From maciej at opencsw.org Sat Jun 9 15:50:17 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 9 Jun 2012 14:50:17 +0100 Subject: [csw-maintainers] GAR: BUILD_ARGS when custom build scripts In-Reply-To: References: <2e6bfc3c7101024f2d3ec2944a8b4e7a.squirrel@mail.opencsw.org> Message-ID: 2012/6/9 Peter FELECAN > > > When you say that you're using a custom build and you wish to pass > > specific arguments to all or some of the specific scripts, what do you > > mean by 'a script'? > > I mean 'target'. See autogen's recipe where the build is split in 4 > targets, 3 of them having additional PATH set. Right, so you need custom build-* targets to do that. BUILD_SCRIPTS += foo build-foo: (cd $(WORKSRC); PATH=... gmake ...) @$(MAKECOOKIE) From pfelecan at opencsw.org Sat Jun 9 18:54:02 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 09 Jun 2012 18:54:02 +0200 Subject: [csw-maintainers] GAR: BUILD_ARGS when custom build scripts References: <2e6bfc3c7101024f2d3ec2944a8b4e7a.squirrel@mail.opencsw.org> Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2012/6/9 Peter FELECAN >> >> > When you say that you're using a custom build and you wish to pass >> > specific arguments to all or some of the specific scripts, what do you >> > mean by 'a script'? >> >> I mean 'target'. See autogen's recipe where the build is split in 4 >> targets, 3 of them having additional PATH set. > > Right, so you need custom build-* targets to do that. > > BUILD_SCRIPTS += foo > > build-foo: > (cd $(WORKSRC); PATH=... gmake ...) > @$(MAKECOOKIE) This is what I've done. But there is the BUILD_ARGS variable which can add extra arguments to the default build. My question is related to this: how to add custom arguments to custom builds? BTW, I use the following construct: build-foo: PATH="/opt/csw/gnu:$$PATH" $(MAKE) -C $(WORKSRC) $(MAKECOOKIE) which, for me, is a little bit more readable, but that is a question of taste... -- Peter From bwalton at opencsw.org Sat Jun 9 20:12:34 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 09 Jun 2012 14:12:34 -0400 Subject: [csw-maintainers] GAR: BUILD_ARGS when custom build scripts In-Reply-To: References: <2e6bfc3c7101024f2d3ec2944a8b4e7a.squirrel@mail.opencsw.org> Message-ID: <1339265455-sup-8232@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Sat Jun 09 12:54:02 -0400 2012: Hi Peter, > This is what I've done. But there is the BUILD_ARGS variable which can > add extra arguments to the default build. My question is related to > this: how to add custom arguments to custom builds? > > BTW, I use the following construct: > > build-foo: > PATH="/opt/csw/gnu:$$PATH" $(MAKE) -C $(WORKSRC) > $(MAKECOOKIE) So if I understand what your recipe might be, you'd have: BUILD_SCRIPTS = foo BUILD_SCRIPTS += bar BUILD_SCRIPTS += baz build-foo: ... build-bar: ... build-baz: ... If you have multiple targets, wouldn't you just use custom options in the custom targets, factoring any commonality into a variable that they all reference? Maybe I'm still missing what you're attempting to do though... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Sun Jun 10 12:57:03 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 10 Jun 2012 12:57:03 +0200 Subject: [csw-maintainers] GAR: BUILD_ARGS when custom build scripts In-Reply-To: References: <2e6bfc3c7101024f2d3ec2944a8b4e7a.squirrel@mail.opencsw.org> Message-ID: Hi Peter, Am 09.06.2012 um 18:54 schrieb Peter FELECAN: > "Maciej (Matchek) Blizi?ski" writes: >> 2012/6/9 Peter FELECAN >>>> When you say that you're using a custom build and you wish to pass >>>> specific arguments to all or some of the specific scripts, what do you >>>> mean by 'a script'? >>> >>> I mean 'target'. See autogen's recipe where the build is split in 4 >>> targets, 3 of them having additional PATH set. >> >> Right, so you need custom build-* targets to do that. >> >> BUILD_SCRIPTS += foo >> >> build-foo: >> (cd $(WORKSRC); PATH=... gmake ...) >> @$(MAKECOOKIE) > > This is what I've done. But there is the BUILD_ARGS variable which can > add extra arguments to the default build. My question is related to > this: how to add custom arguments to custom builds? > > BTW, I use the following construct: > > build-foo: > PATH="/opt/csw/gnu:$$PATH" $(MAKE) -C $(WORKSRC) > $(MAKECOOKIE) > > which, for me, is a little bit more readable, but that is a question of > taste... There is no such automatic build in right now, but I see this is useful and have opened a ticket for it so it is not forgotten: https://sourceforge.net/apps/trac/gar/ticket/72 Best regards -- Dago From dam at opencsw.org Sun Jun 10 23:54:34 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 10 Jun 2012 23:54:34 +0200 Subject: [csw-maintainers] [csw-buildfarm] libldns1 on the buildfarm In-Reply-To: <9E43AE69-3F3E-4ABD-98AC-ADFD4A47C35D@opencsw.org> References: <4FD50623.4040602@opencsw.org> <9E43AE69-3F3E-4ABD-98AC-ADFD4A47C35D@opencsw.org> Message-ID: <50678B5C-2BA4-415A-A5F0-F6F8D0E11103@opencsw.org> Fellow maintainers, Am 10.06.2012 um 23:24 schrieb Dagobert Michelsen: > Am 10.06.2012 um 22:40 schrieb ?hsan Do?an: >> Please update libldns1 to libldns1-1.6.13 on the buildfarm. >> I've commited libldns1-1.6.13 this evening to unstable. > > Updating unstable* now (67 packages total), please stand by. During the update the filesystem of unstable10x filled up, I will clean this up tomorrow. Please stand by. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From pfelecan at opencsw.org Mon Jun 11 14:17:57 2012 From: pfelecan at opencsw.org (pfelecan at opencsw.org) Date: Mon, 11 Jun 2012 14:17:57 +0200 (CEST) Subject: [csw-maintainers] please review new emacs_template recipe Message-ID: I'm continuing the migration of my private recipes toward GAR based ones. Doing that for emacs_template raises some not yet encountered issues that I cannot debug. Consequently, if some GAR veterans can review my recipe, they will advance my craftsmanship... Here are the issues: 1. when I add to the DESTFILES a README.CSW file, the prototype contains these additional and, in my opinion, incorrect entries: d none /opt/csw/share/doc/emacs_template/emacs_template 0755 root bin f none /opt/csw/share/doc/emacs_template/emacs_template/README.CSW 0644 root bin d none /opt/csw/share/doc/emacs_template/emacs_template_stub 0755 root bin f none /opt/csw/share/doc/emacs_template/emacs_template_stub/README.CSW 0644 root bin note the duplication of the package name in the documentation directory 2. the checkpkg suggested overrides are incomprehensible by a common mortal as myself: CHECKPKG_OVERRIDES_CSWemacs-template += license-missing|/opt/csw/share/doc/emacs_template/license CHECKPKG_OVERRIDES_CSWemacstemplate += action-class-only-in-pkginfo|none CHECKPKG_OVERRIDES_CSWemacstemplate += license-missing|/opt/csw/share/doc/emacs_template_stub/license TIA From dam at opencsw.org Mon Jun 11 14:36:27 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 11 Jun 2012 14:36:27 +0200 Subject: [csw-maintainers] please review new emacs_template recipe In-Reply-To: References: Message-ID: <6DFA6942-F46A-408E-978A-ED636C131C2D@opencsw.org> Hi Peter, Am 11.06.2012 um 14:17 schrieb pfelecan at opencsw.org: > I'm continuing the migration of my private recipes toward GAR based ones. > > Doing that for emacs_template raises some not yet encountered issues that > I cannot debug. Consequently, if some GAR veterans can review my recipe, > they will advance my craftsmanship... > > Here are the issues: > > 1. when I add to the DESTFILES a README.CSW file, the prototype contains > these additional and, in my opinion, incorrect entries: > > d none /opt/csw/share/doc/emacs_template/emacs_template 0755 root bin > f none /opt/csw/share/doc/emacs_template/emacs_template/README.CSW 0644 > root bin > d none /opt/csw/share/doc/emacs_template/emacs_template_stub 0755 root bin > f none /opt/csw/share/doc/emacs_template/emacs_template_stub/README.CSW > 0644 root bin > > note the duplication of the package name in the documentation directory This is an automatic thing, a file README.CSW will be added to all build packages of this recipe to announce general changes etc. I guess it should be added to the variable reference. Any other name apart from README.CSW will not have this behaviour. > 2. the checkpkg suggested overrides are incomprehensible by a common > mortal as myself: > > CHECKPKG_OVERRIDES_CSWemacs-template += > license-missing|/opt/csw/share/doc/emacs_template/license > CHECKPKG_OVERRIDES_CSWemacstemplate += action-class-only-in-pkginfo|none > CHECKPKG_OVERRIDES_CSWemacstemplate += > license-missing|/opt/csw/share/doc/emacs_template_stub/license I just added the description in http://wiki.opencsw.org/checkpkg-error-tags#license-missing Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Mon Jun 11 15:53:44 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 11 Jun 2012 15:53:44 +0200 Subject: [csw-maintainers] [csw-buildfarm] cannot svn checkout on Solaris 9 SPARC In-Reply-To: <98c73c8a114328414cc120eeb85f876d.squirrel@mail.opencsw.org> References: <98c73c8a114328414cc120eeb85f876d.squirrel@mail.opencsw.org> Message-ID: <74947474-B171-4688-A87F-907F78139917@opencsw.org> Hi Peter, Am 11.06.2012 um 13:56 schrieb pfelecan at opencsw.org: > I'm trying to checkout a package recipe on unstable9s and obtain the > following error message: > > pfelecan at unstable9s :~ > svn checkout > https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/emacs_template > opencsw/emacs_template > svn: E175002: Unable to connect to a repository at URL > 'https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/emacs_template' > svn: E175002: OPTIONS of > 'https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/emacs_template': > SSL handshake failed: SSL disabled due to library version mismatch > (https://gar.svn.sourceforge.net) > > On Solaris 10 the checkout works without any issues. The problem is that subversion has been rebuild against openssl 1.0 on Solaris 10 only, but the underlying libneon has been updated on Solaris 9 and 10 causing the mismatch. There are three options: - rollback the openssl update for Solaris 9 - compile subversion and everything else linked to neon also on Solaris 9 - rollback the neon update on Solaris 9 Thoughts? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From jh at opencsw.org Mon Jun 11 16:00:24 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Mon, 11 Jun 2012 16:00:24 +0200 Subject: [csw-maintainers] [csw-buildfarm] cannot svn checkout on Solaris 9 SPARC In-Reply-To: <74947474-B171-4688-A87F-907F78139917@opencsw.org> References: <98c73c8a114328414cc120eeb85f876d.squirrel@mail.opencsw.org> <74947474-B171-4688-A87F-907F78139917@opencsw.org> Message-ID: <4FD5F9F8.7080601@opencsw.org> Am 11.06.12 15:53, schrieb Dagobert Michelsen: > - rollback the openssl update for Solaris 9 > - compile subversion and everything else linked to neon also on Solaris 9 > - rollback the neon update on Solaris 9 > > Thoughts? Solaris 9 is a mess atm anyway. I would think the best way is not to push the openssl update to Solaris 9 at all and stay with 0.9.8. This fixes the mess I have e.g. with wireshark. This needs a rebuild but can't be rebuild on Solaris 9 because of newer glib on Solaris 10. So I would need separate build. Which I have not decided yet if I do that. Greetings Jan From yann at pleiades.fr.eu.org Mon Jun 11 16:31:03 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Mon, 11 Jun 2012 16:31:03 +0200 Subject: [csw-maintainers] [csw-buildfarm] cannot svn checkout on Solaris 9 SPARC In-Reply-To: <4FD5F9F8.7080601@opencsw.org> References: <98c73c8a114328414cc120eeb85f876d.squirrel@mail.opencsw.org> <74947474-B171-4688-A87F-907F78139917@opencsw.org> <4FD5F9F8.7080601@opencsw.org> Message-ID: 2012/6/11 Jan Holzhueter > Am 11.06.12 15:53, schrieb Dagobert Michelsen: > > > - rollback the openssl update for Solaris 9 > > - compile subversion and everything else linked to neon also on Solaris 9 > > - rollback the neon update on Solaris 9 > > > > Thoughts? > > Solaris 9 is a mess atm anyway. > I would think the best way is not to push the openssl update to Solaris > 9 at all and stay with 0.9.8. > If we don't push library upgrades to Solaris 9, but we still allow package to be built under it, I think it will be more complicated to maintain a Solaris 9 build environment. - packages will have to be linked to different library versions depending on the solaris version, that could lead to more potential problems and cases to debug, - concerning openssl 0.9.8, I will have to a different set of packages depending on the solaris version: library only for Solaris >= 10, library + binary + development files for Solaris 9. I suppose this can be done with GAR but it's an additionnal complexity (openssl is now builded 15 times I think to be able to provide packages for Solaris 9, 10 & 11 with various architecture-optimised build). So if we go that way, I think we should rather simply really drop Solaris 9. If we don't go that way, I think the best way would be to rollback neon and wait for the all related packages to be build before releasing them together. However, that's a lot of package ! http://wiki.opencsw.org/project-openssl If neon is the only one to cause problem because of an explicit version check, maybe we could focus on neon linked libraries and binaries. Yann > > This fixes the mess I have e.g. with wireshark. This needs a rebuild but > can't be rebuild on Solaris 9 because of newer glib on Solaris 10. > So I would need separate build. Which I have not decided yet if I do that. > > Greetings > Jan > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Mon Jun 11 17:29:44 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 11 Jun 2012 17:29:44 +0200 Subject: [csw-maintainers] Distrowatch In-Reply-To: References: Message-ID: Hi Maciej, Am 08.06.2012 um 18:24 schrieb Maciej (Matchek) Blizinski: > I just realized that we aren't listed on Distrowatch and I don't > really see a reason why we shouldn't be. That we don't provide the > kernel or a standalone bootable CD shouldn't disqualify us. > > Does anyone know of any history, did we apply in the past and have > been rejected, or did we simply not apply? > > http://distrowatch.com/dwres.php?resource=submit We just never applied IIRC. But it would be nice if we would be listed, feel free to take a stab. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From bwalton at opencsw.org Mon Jun 11 17:35:48 2012 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 11 Jun 2012 11:35:48 -0400 Subject: [csw-maintainers] [csw-buildfarm] cannot svn checkout on Solaris 9 SPARC In-Reply-To: References: <98c73c8a114328414cc120eeb85f876d.squirrel@mail.opencsw.org> <74947474-B171-4688-A87F-907F78139917@opencsw.org> <4FD5F9F8.7080601@opencsw.org> Message-ID: <1339428902-sup-1946@pinkfloyd.chass.utoronto.ca> Excerpts from Yann Rouillard's message of Mon Jun 11 10:31:03 -0400 2012: > So if we go that way, I think we should rather simply really drop > Solaris 9. This is the point I'm getting to now as well. It's already best effort only, so if it starts to make life actively difficult, we should walk away entirely, I think. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From Joerg.Schilling at fokus.fraunhofer.de Mon Jun 11 17:31:18 2012 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Mon, 11 Jun 2012 17:31:18 +0200 Subject: [csw-maintainers] Distrowatch In-Reply-To: References: Message-ID: <4fd60f46.D7KTCRLcyXrG7AlA%Joerg.Schilling@fokus.fraunhofer.de> Dagobert Michelsen wrote: > > > > http://distrowatch.com/dwres.php?resource=submit > > We just never applied IIRC. But it would be nice if we would be listed, feel > free to take a stab. I did never "apply" and SchilliX at least was in... 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 pfelecan at opencsw.org Mon Jun 11 19:18:44 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 11 Jun 2012 19:18:44 +0200 Subject: [csw-maintainers] please review new emacs_template recipe In-Reply-To: <6DFA6942-F46A-408E-978A-ED636C131C2D@opencsw.org> (Dagobert Michelsen's message of "Mon, 11 Jun 2012 14:36:27 +0200") References: <6DFA6942-F46A-408E-978A-ED636C131C2D@opencsw.org> Message-ID: Dagobert Michelsen writes: > This is an automatic thing, a file README.CSW will be added to all build packages > of this recipe to announce general changes etc. I guess it should be added to > the variable reference. Any other name apart from README.CSW will not have this > behaviour. And how do you add the README.CSW file only to a given package? You did remark that the "other" package is a stub used because the original package name changes. This is quite annoying even though I see a solution by using another mechanism to add the file, e.g. in post-install-modulated. -- Peter From pfelecan at opencsw.org Mon Jun 11 19:21:04 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 11 Jun 2012 19:21:04 +0200 Subject: [csw-maintainers] [csw-buildfarm] cannot svn checkout on Solaris 9 SPARC In-Reply-To: <74947474-B171-4688-A87F-907F78139917@opencsw.org> (Dagobert Michelsen's message of "Mon, 11 Jun 2012 15:53:44 +0200") References: <98c73c8a114328414cc120eeb85f876d.squirrel@mail.opencsw.org> <74947474-B171-4688-A87F-907F78139917@opencsw.org> Message-ID: Dagobert Michelsen writes: > Hi Peter, > > Am 11.06.2012 um 13:56 schrieb pfelecan at opencsw.org: >> I'm trying to checkout a package recipe on unstable9s and obtain the >> following error message: >> >> pfelecan at unstable9s :~ > svn checkout >> https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/emacs_template >> opencsw/emacs_template >> svn: E175002: Unable to connect to a repository at URL >> 'https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/emacs_template' >> svn: E175002: OPTIONS of >> 'https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/emacs_template': >> SSL handshake failed: SSL disabled due to library version mismatch >> (https://gar.svn.sourceforge.net) >> >> On Solaris 10 the checkout works without any issues. > > The problem is that subversion has been rebuild against openssl 1.0 on Solaris 10 > only, but the underlying libneon has been updated on Solaris 9 and 10 causing > the mismatch. There are three options: > > - rollback the openssl update for Solaris 9 > - compile subversion and everything else linked to neon also on Solaris 9 > - rollback the neon update on Solaris 9 For the moment I can do all my subversion operations on Solaris 10 and build on Solaris 9. But, if it gets worse I'd join the chorus: drop the clunker! -- Peter From dam at opencsw.org Mon Jun 11 20:18:23 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 11 Jun 2012 20:18:23 +0200 Subject: [csw-maintainers] please review new emacs_template recipe In-Reply-To: References: <6DFA6942-F46A-408E-978A-ED636C131C2D@opencsw.org> Message-ID: <3BD09A0A-71B3-4219-B04E-5E86E026828F@opencsw.org> Hi Peter, Am 11.06.2012 um 19:18 schrieb Peter FELECAN: > Dagobert Michelsen writes: >> This is an automatic thing, a file README.CSW will be added to all build packages >> of this recipe to announce general changes etc. I guess it should be added to >> the variable reference. Any other name apart from README.CSW will not have this >> behaviour. > > And how do you add the README.CSW file only to a given package? You did > remark that the "other" package is a stub used because the original > package name changes. This is quite annoying even though I see a > solution by using another mechanism to add the file, e.g. in > post-install-modulated. That "feature" was introduced after a discussion on IRC in februar 2011 AFAIR. Now that I think it over it may not be as clean as it should be. To be in line it probably should be DISTFILES += CSWmypkg.README.CSW or even better DISTFILES += README.CSW EXTRA_DOCS_CSWmypkg += README.CSW EXTRA_DOCS_CSWmypkg += morestuff.txt EXTRA_DOCS += this-goes-to-all-pkgs.txt Would that be ok? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From bwalton at opencsw.org Tue Jun 12 03:31:58 2012 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 11 Jun 2012 21:31:58 -0400 Subject: [csw-maintainers] [csw-buildfarm] cannot svn checkout on Solaris 9 SPARC In-Reply-To: References: <98c73c8a114328414cc120eeb85f876d.squirrel@mail.opencsw.org> <74947474-B171-4688-A87F-907F78139917@opencsw.org> Message-ID: <1339464638-sup-6531@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Mon Jun 11 13:21:04 -0400 2012: > For the moment I can do all my subversion operations on Solaris 10 > and build on Solaris 9. But, if it gets worse I'd join the chorus: > drop the clunker! If we do move to completely abandon solaris 9, we should likely try to back out a few of the recent things so that anyone wanting to continue using the packages there could at least have a usable set. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Tue Jun 12 09:25:56 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 12 Jun 2012 08:25:56 +0100 Subject: [csw-maintainers] GCC versions on the buildfarm Message-ID: We now have different GCC versions on Solaris 9 and Solaris 10 hosts. This means, that we can't have a common OS-release-independent setting in GAR that will work for both systems. Perhaps we need something like this? diff --git a/gar/v2/gar.conf.mk b/gar/v2/gar.conf.mk index 6f3fc18..112cbdc 100644 --- a/gar/v2/gar.conf.mk +++ b/gar/v2/gar.conf.mk @@ -539,7 +539,9 @@ SOS12U1_CC_HOME ?= /opt/studio/sunstudio12.1 SOS12U2_CC_HOME ?= /opt/solstudio12.2 SOS12U3_CC_HOME ?= /opt/solarisstudio12.3 - GCC4_VERSION ?= 4.6 + GCC4_VERSION_5.9 ?= 4.6 + GCC4_VERSION_5.10 ?= 4.7 + GCC4_VERSION = $(GCC4_VERSION_$(GAROSREL)) GCC3_CC ?= $(GCC3_CC_HOME)/bin/gcc GCC4_CC ?= $(GCC4_CC_HOME)/bin/gcc-$(GCC4_VERSION) In ?real life? we'd also need to handle the 5.11 case. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Tue Jun 12 09:32:59 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 12 Jun 2012 09:32:59 +0200 Subject: [csw-maintainers] GCC versions on the buildfarm In-Reply-To: References: Message-ID: <1098EA0E-CA71-4D87-9966-8D30B1CB80DA@opencsw.org> Hi Maciej, Am 12.06.2012 um 09:25 schrieb Maciej (Matchek) Blizi?ski: > We now have different GCC versions on Solaris 9 and Solaris 10 hosts. This means, that we can't have a common OS-release-independent setting in GAR that will work for both systems. > > Perhaps we need something like this? > > diff --git a/gar/v2/gar.conf.mk b/gar/v2/gar.conf.mk > index 6f3fc18..112cbdc 100644 > --- a/gar/v2/gar.conf.mk > +++ b/gar/v2/gar.conf.mk > @@ -539,7 +539,9 @@ SOS12U1_CC_HOME ?= /opt/studio/sunstudio12.1 > SOS12U2_CC_HOME ?= /opt/solstudio12.2 > SOS12U3_CC_HOME ?= /opt/solarisstudio12.3 > > - GCC4_VERSION ?= 4.6 > + GCC4_VERSION_5.9 ?= 4.6 > + GCC4_VERSION_5.10 ?= 4.7 > + GCC4_VERSION = $(GCC4_VERSION_$(GAROSREL)) You should always have GCC4_VERSION ?= $(GCC4_VERSION_$(GAROSREL)) to allow local overrides. > > GCC3_CC ?= $(GCC3_CC_HOME)/bin/gcc > GCC4_CC ?= $(GCC4_CC_HOME)/bin/gcc-$(GCC4_VERSION) > > In ?real life? we'd also need to handle the 5.11 case. Alternatively you could have in /etc/opt/csw/garrc GCC4_VERSION = 4.6 on Solaris 9 and GCC4_VERSION = 4.7 on Solaris 10 defaulting to 4.7 in GAR itself. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From romeotheriault at opencsw.org Tue Jun 12 09:37:42 2012 From: romeotheriault at opencsw.org (Romeo Theriault) Date: Mon, 11 Jun 2012 21:37:42 -1000 Subject: [csw-maintainers] Newbie first packaging questions Message-ID: Hello, First I'd like to start off by saying that mgar/gar is really cool. This is a much more automated process than I'm used to dealing with when building packages. (Not that I've built that many... still I'm impressed!) So thank you to the folks that are working on these pieces of software, I appreciate it. I'm new to building packages with mgar/gar, am new to "Makefiles" so please be patient with me. :) The first package I'm trying to build is 'zeromq'. I've been following the gperf example install [1] guide on unstable10s, but using zeromq instead. This has all gone fine until I get to the 'mgar package' step. Then I receive this error: -bash-4.2$ mgar package /home/romeotheriault/opencsw/.buildsys/v2/gar//gar.pkg.mk:902: *** You are building this package on a non-requested platform host 'unstable10s'. The following platforms were requested: /home/romeotheriault/opencsw/.buildsys/v2/gar//gar.pkg.mk:902: *** - solaris9-sparc to be build on host 'unstable9s' /home/romeotheriault/opencsw/.buildsys/v2/gar//gar.pkg.mk:902: *** - solaris9-i386 to be build on host 'unstable9x' /home/romeotheriault/opencsw/.buildsys/v2/gar//gar.pkg.mk:902: *** You can execute 'gmake platforms' to automatically build on all necessary platforms.. Stop. Sounds like it only wants to build for solaris9... If this is the case, how do I make solaris 10 a 'necessary platform'? On a slightly different topic, does the 'category' in the package Makefile influence the build in anyway, or is this just a way to categorize packages? Would a package like zeromq fall under the 'lib' category? Here is what it's install looks like on RHEL: $ rpm -ql zeromq /usr/lib64/libzmq.so.1 /usr/lib64/libzmq.so.1.0.0 /usr/share/doc/zeromq-2.1.9 /usr/share/doc/zeromq-2.1.9/AUTHORS /usr/share/doc/zeromq-2.1.9/COPYING /usr/share/doc/zeromq-2.1.9/COPYING.LESSER /usr/share/doc/zeromq-2.1.9/ChangeLog /usr/share/doc/zeromq-2.1.9/NEWS /usr/share/doc/zeromq-2.1.9/README Thank you, Romeo [1] http://sourceforge.net/apps/trac/gar/wiki/ExplainedGperf From dam at opencsw.org Tue Jun 12 09:55:27 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 12 Jun 2012 09:55:27 +0200 Subject: [csw-maintainers] Newbie first packaging questions In-Reply-To: References: Message-ID: <89085544-E74A-4A90-BBD6-3CA67CC43550@opencsw.org> Hi Romeo, Am 12.06.2012 um 09:37 schrieb Romeo Theriault: > Hello, First I'd like to start off by saying that mgar/gar is really > cool. This is a much more automated process than I'm used to dealing > with when building packages. (Not that I've built that many... still > I'm impressed!) So thank you to the folks that are working on these > pieces of software, I appreciate it. :-) > I'm new to building packages with mgar/gar, am new to "Makefiles" so > please be patient with me. :) Sure. > Sounds like it only wants to build for solaris9... If this is the > case, how do I make solaris 10 a 'necessary platform'? This is explained here: http://sourceforge.net/apps/trac/gar/wiki/Platforms > On a slightly different topic, does the 'category' in the package > Makefile influence the build in anyway, or is this just a way to > categorize packages? Unfortunately it is a combination of both. Some categories are just groupings (like "apps" and "lib") which are not used further on, some are real "flavors" which change the behaviour (like "cpan"). See here for details: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/categories Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From pfelecan at opencsw.org Tue Jun 12 13:20:05 2012 From: pfelecan at opencsw.org (pfelecan at opencsw.org) Date: Tue, 12 Jun 2012 13:20:05 +0200 (CEST) Subject: [csw-maintainers] GAR: adding /opt/csw/gnu to PATH and gettext issues Message-ID: <767c21c1ce541b31cb84eee712d47424.squirrel@mail.opencsw.org> When configuring a project which uses gettext I have the following: checking for xgettext... /usr/bin/xgettext checking for msgmerge... no checking for msgfmt... /usr/bin/msgfmt checking for gmsgfmt... /opt/csw/bin/gmsgfmt which raises the following issues: 1. some utilities are taken from the base Solaris supply 2. other utilities are taken from Open CSW supply 3. and some utilities are not found... quite a mess; it is very probable that the gettext package has some incoherent transforms of the binaries names, some with the 'g' prefix, some without. All these issues are solved by adding the /opt/csw/gnu path to the PATH environment variable: checking for xgettext... /opt/csw/gnu/xgettext checking for msgmerge... /opt/csw/gnu/msgmerge checking for msgfmt... /opt/csw/gnu/msgfmt checking for gmsgfmt... /opt/csw/bin/gmsgfmt This is not the first time that I encounter issues that are solved by this addition. Moreover, I think that in many cases, such as the one described above, we have a higher coherency. Unfortunately, in the configure step of mGAR it is not clear how can we enrich the PATH. The only way to do it, from my point of view, is to modify its definition in gar.conf.mk I remember that there was such a suggestion in the near past but with no consequence. What do you think? From dam at opencsw.org Tue Jun 12 13:25:09 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 12 Jun 2012 13:25:09 +0200 Subject: [csw-maintainers] GAR: adding /opt/csw/gnu to PATH and gettext issues In-Reply-To: <767c21c1ce541b31cb84eee712d47424.squirrel@mail.opencsw.org> References: <767c21c1ce541b31cb84eee712d47424.squirrel@mail.opencsw.org> Message-ID: Hi Peter, Am 12.06.2012 um 13:20 schrieb pfelecan at opencsw.org: > When configuring a project which uses gettext I have the following: > > checking for xgettext... /usr/bin/xgettext > checking for msgmerge... no > checking for msgfmt... /usr/bin/msgfmt > checking for gmsgfmt... /opt/csw/bin/gmsgfmt > > which raises the following issues: > > 1. some utilities are taken from the base Solaris supply > 2. other utilities are taken from Open CSW supply > 3. and some utilities are not found... > > quite a mess; it is very probable that the gettext package has some > incoherent transforms of the binaries names, some with the 'g' prefix, > some without. > > All these issues are solved by adding the /opt/csw/gnu path to the > PATH environment variable: > > checking for xgettext... /opt/csw/gnu/xgettext > checking for msgmerge... /opt/csw/gnu/msgmerge > checking for msgfmt... /opt/csw/gnu/msgfmt > checking for gmsgfmt... /opt/csw/bin/gmsgfmt > > This is not the first time that I encounter issues that are solved by > this addition. Moreover, I think that in many cases, such as the one > described above, we have a higher coherency. Yes. Unfortunately adding it by default breaks other recipes which require the Sun tools which are confused by prepending /opt/csw/gnu. > Unfortunately, in the configure step of mGAR it is not clear how can > we enrich the PATH. The only way to do it, from my point of view, is > to modify its definition in gar.conf.mk > > I remember that there was such a suggestion in the near past but with > no consequence. > > What do you think? The idiom to add the path to a specific phase is CONFIGURE_ENV_PATH = /opt/csw/gnu:$(PATH) There are similar variables for the other phases: BUILD_ENV_PATH TEST_ENV_PATH INSTALL_ENV_PATH To unconditionally add it to all phases you use PATH := /opt/csw/gnu:$(PATH) *after* the include category.mk PS: What do you think about my other suggestion about modifying the README.CSW handling? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From bwalton at opencsw.org Tue Jun 12 13:24:56 2012 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 12 Jun 2012 07:24:56 -0400 Subject: [csw-maintainers] =?utf-8?q?GAR=3A_adding_/opt/csw/gnu_to_PATH_an?= =?utf-8?q?d_gettext=09issues?= In-Reply-To: <767c21c1ce541b31cb84eee712d47424.squirrel@mail.opencsw.org> References: <767c21c1ce541b31cb84eee712d47424.squirrel@mail.opencsw.org> Message-ID: Hi Peter, Personally I'd be ok with changing that default but it may have consequences I haven't considered. To fix it for a specific recipe, add the following line after thee include statement that pulls in gar: PATH := /opt/csw/gnu:$(PATH) Thanks -Ben pfelecan at opencsw.org wrote: When configuring a project which uses gettext I have the following: checking for xgettext... /usr/bin/xgettext checking for msgmerge... no checking for msgfmt... /usr/bin/msgfmt checking for gmsgfmt... /opt/csw/bin/gmsgfmt which raises the following issues: 1. some utilities are taken from the base Solaris supply 2. other utilities are taken from Open CSW supply 3. and some utilities are not found... quite a mess; it is very probable that the gettext package has some incoherent transforms of the binaries names, some with the 'g' prefix, some without. All these issues are solved by adding the /opt/csw/gnu path to the PATH environment variable: checking for xgettext... /opt/csw/gnu/xgettext checking for msgmerge... /opt/csw/gnu/msgmerge checking for msgfmt... /opt/csw/gnu/msgfmt checking for gmsgfmt... /opt/csw/bin/gmsgfmt This is not the first time that I encounter issues that are solved by this addition. Moreover, I think that in many cases, such as the one described above, we have a higher coherency. Unfortunately, in the configure step of mGAR it is not clear how can we enrich the PATH. The only way to do it, from my point of view, is to modify its definition in gar.conf.mk I remember that there was such a suggestion in the near past but with no consequence. What do you think? _____________________________________________ maintainers mailing list maintainers at lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfelecan at opencsw.org Tue Jun 12 19:17:11 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 12 Jun 2012 19:17:11 +0200 Subject: [csw-maintainers] please review new emacs_template recipe In-Reply-To: <3BD09A0A-71B3-4219-B04E-5E86E026828F@opencsw.org> (Dagobert Michelsen's message of "Mon, 11 Jun 2012 20:18:23 +0200") References: <6DFA6942-F46A-408E-978A-ED636C131C2D@opencsw.org> <3BD09A0A-71B3-4219-B04E-5E86E026828F@opencsw.org> Message-ID: Dagobert Michelsen writes: > Hi Peter, > > Am 11.06.2012 um 19:18 schrieb Peter FELECAN: >> Dagobert Michelsen writes: >>> This is an automatic thing, a file README.CSW will be added to all build packages >>> of this recipe to announce general changes etc. I guess it should be added to >>> the variable reference. Any other name apart from README.CSW will not have this >>> behaviour. >> >> And how do you add the README.CSW file only to a given package? You did >> remark that the "other" package is a stub used because the original >> package name changes. This is quite annoying even though I see a >> solution by using another mechanism to add the file, e.g. in >> post-install-modulated. > > That "feature" was introduced after a discussion on IRC in februar 2011 AFAIR. > Now that I think it over it may not be as clean as it should be. To be in line it > probably should be > DISTFILES += CSWmypkg.README.CSW > or even better > DISTFILES += README.CSW > EXTRA_DOCS_CSWmypkg += README.CSW > EXTRA_DOCS_CSWmypkg += morestuff.txt > EXTRA_DOCS += this-goes-to-all-pkgs.txt > > Would that be ok? I think that the second form is more in line with the other package specific variables. Note that my issue included README.CSW in 2 subdirectories of the package's doc, i.e. /opt/csw/share/doc/emacs_template/emacs_template and /opt/csw/share/doc/emacs_template/emacs_template_stub -- Peter From pfelecan at opencsw.org Tue Jun 12 19:18:50 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 12 Jun 2012 19:18:50 +0200 Subject: [csw-maintainers] GCC versions on the buildfarm In-Reply-To: <1098EA0E-CA71-4D87-9966-8D30B1CB80DA@opencsw.org> (Dagobert Michelsen's message of "Tue, 12 Jun 2012 09:32:59 +0200") References: <1098EA0E-CA71-4D87-9966-8D30B1CB80DA@opencsw.org> Message-ID: Dagobert Michelsen writes: > Alternatively you could have in /etc/opt/csw/garrc > GCC4_VERSION = 4.6 > on Solaris 9 and > GCC4_VERSION = 4.7 > on Solaris 10 defaulting to 4.7 in GAR itself. This is probably the best way to manage it. -- Peter From pfelecan at opencsw.org Tue Jun 12 19:20:08 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 12 Jun 2012 19:20:08 +0200 Subject: [csw-maintainers] GAR: adding /opt/csw/gnu to PATH and gettext issues In-Reply-To: (Dagobert Michelsen's message of "Tue, 12 Jun 2012 13:25:09 +0200") References: <767c21c1ce541b31cb84eee712d47424.squirrel@mail.opencsw.org> Message-ID: Dagobert Michelsen writes: > The idiom to add the path to a specific phase is > CONFIGURE_ENV_PATH = /opt/csw/gnu:$(PATH) > > There are similar variables for the other phases: > BUILD_ENV_PATH > TEST_ENV_PATH > INSTALL_ENV_PATH Nice. They are in great need of documentation... > To unconditionally add it to all phases you use > > PATH := /opt/csw/gnu:$(PATH) > > *after* the include category.mk This is what I used succesfully. Than you. -- Peter From bwalton at opencsw.org Tue Jun 12 19:22:37 2012 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 12 Jun 2012 13:22:37 -0400 Subject: [csw-maintainers] GCC versions on the buildfarm In-Reply-To: References: <1098EA0E-CA71-4D87-9966-8D30B1CB80DA@opencsw.org> Message-ID: <1339521703-sup-3854@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Tue Jun 12 13:18:50 -0400 2012: > Dagobert Michelsen writes: > > > Alternatively you could have in /etc/opt/csw/garrc > > GCC4_VERSION = 4.6 > > on Solaris 9 and > > GCC4_VERSION = 4.7 > > on Solaris 10 defaulting to 4.7 in GAR itself. > > This is probably the best way to manage it. Agreed. That's the nicest fix. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From romeotheriault at opencsw.org Wed Jun 13 00:46:18 2012 From: romeotheriault at opencsw.org (Romeo Theriault) Date: Tue, 12 Jun 2012 12:46:18 -1000 Subject: [csw-maintainers] Newbie first packaging questions In-Reply-To: <89085544-E74A-4A90-BBD6-3CA67CC43550@opencsw.org> References: <89085544-E74A-4A90-BBD6-3CA67CC43550@opencsw.org> Message-ID: On Mon, Jun 11, 2012 at 9:55 PM, Dagobert Michelsen wrote: > Hi Romeo, > > Am 12.06.2012 um 09:37 schrieb Romeo Theriault: >> Hello, First I'd like to start off by saying that mgar/gar is really >> cool. This is a much more automated process than I'm used to dealing >> with when building packages. (Not that I've built that many... still >> I'm impressed!) So thank you to the folks that are working on these >> pieces of software, I appreciate it. > > :-) > >> I'm new to building packages with mgar/gar, am new to "Makefiles" so >> please be patient with me. :) > > Sure. > >> Sounds like it only wants to build for solaris9... If this is the >> case, how do I make solaris 10 a 'necessary platform'? > > This is explained here: > ?http://sourceforge.net/apps/trac/gar/wiki/Platforms > >> On a slightly different topic, does the 'category' in the package >> Makefile influence the build in anyway, or is this just a way to >> categorize packages? > > Unfortunately it is a combination of both. Some categories are just > groupings (like "apps" and "lib") which are not used further on, > some are real "flavors" which change the behaviour (like "cpan"). > > See here for details: > ?http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/categories Thank you for the pointers. That's what I was looking for. Romeo From bwalton at opencsw.org Wed Jun 13 03:56:24 2012 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 12 Jun 2012 21:56:24 -0400 Subject: [csw-maintainers] openssl relinking effort In-Reply-To: References: <1339031740-sup-6645@pinkfloyd.chass.utoronto.ca> <1339123346-sup-3285@pinkfloyd.chass.utoronto.ca> <1339155965-sup-1860@pinkfloyd.chass.utoronto.ca> Message-ID: <1339552426-sup-2945@pinkfloyd.chass.utoronto.ca> Excerpts from Yann Rouillard's message of Fri Jun 08 10:35:20 -0400 2012: > This is done: > http://wiki.opencsw.org/project-openssl > > However, the resultat is that there is a group of 80 packages which > should be released together to avoid a dual linking runtime > situation for any of them or for their reverse dependancies. I think we're making good progress. As I have cycles, I'm tackling packages from retired maintainers that still look useful... Is anyone up for rebuilding the gnome/gtk stuff that's been orphaned? If not, we may need to make some hard choices about the future of this package set... Peter F: Is it something you'd consider? You're one of the few still building things that care about a desktop. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Wed Jun 13 17:14:24 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 13 Jun 2012 17:14:24 +0200 Subject: [csw-maintainers] GAR: adding /opt/csw/gnu to PATH and gettext issues In-Reply-To: References: <767c21c1ce541b31cb84eee712d47424.squirrel@mail.opencsw.org> Message-ID: Hi Peter, Am 12.06.2012 um 19:20 schrieb Peter FELECAN: > Dagobert Michelsen writes: >> The idiom to add the path to a specific phase is >> CONFIGURE_ENV_PATH = /opt/csw/gnu:$(PATH) >> >> There are similar variables for the other phases: >> BUILD_ENV_PATH >> TEST_ENV_PATH >> INSTALL_ENV_PATH > > Nice. They are in great need of documentation... I added and linked the respective docs under https://sourceforge.net/apps/trac/gar/wiki/Environment It would be nice if you could review them for understandability. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Wed Jun 13 17:17:27 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 13 Jun 2012 17:17:27 +0200 Subject: [csw-maintainers] GCC versions on the buildfarm In-Reply-To: References: <1098EA0E-CA71-4D87-9966-8D30B1CB80DA@opencsw.org> Message-ID: Hi, Am 12.06.2012 um 19:18 schrieb Peter FELECAN: > Dagobert Michelsen writes: >> Alternatively you could have in /etc/opt/csw/garrc >> GCC4_VERSION = 4.6 >> on Solaris 9 and >> GCC4_VERSION = 4.7 >> on Solaris 10 defaulting to 4.7 in GAR itself. > > This is probably the best way to manage it. Done. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From pfelecan at opencsw.org Wed Jun 13 19:13:40 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 13 Jun 2012 19:13:40 +0200 Subject: [csw-maintainers] openssl relinking effort In-Reply-To: <1339552426-sup-2945@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Tue, 12 Jun 2012 21:56:24 -0400") References: <1339031740-sup-6645@pinkfloyd.chass.utoronto.ca> <1339123346-sup-3285@pinkfloyd.chass.utoronto.ca> <1339155965-sup-1860@pinkfloyd.chass.utoronto.ca> <1339552426-sup-2945@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > Excerpts from Yann Rouillard's message of Fri Jun 08 10:35:20 -0400 2012: > >> This is done: >> http://wiki.opencsw.org/project-openssl >> >> However, the resultat is that there is a group of 80 packages which >> should be released together to avoid a dual linking runtime >> situation for any of them or for their reverse dependancies. > > I think we're making good progress. As I have cycles, I'm tackling > packages from retired maintainers that still look useful... > > Is anyone up for rebuilding the gnome/gtk stuff that's been orphaned? > If not, we may need to make some hard choices about the future of this > package set... > > Peter F: Is it something you'd consider? You're one of the few still > building things that care about a desktop. I was quite sure that saying that I was putting my finger in the wheels... For the moment I'm slowly migrating from private recipes to GAR based ones. If my time permits I can look in gtk and then gnome. What about glib? -- Peter From raos at opencsw.org Wed Jun 13 19:49:02 2012 From: raos at opencsw.org (Rafael Ostertag) Date: Wed, 13 Jun 2012 19:49:02 +0200 Subject: [csw-maintainers] openssl relinking effort In-Reply-To: References: <1339031740-sup-6645@pinkfloyd.chass.utoronto.ca> <1339123346-sup-3285@pinkfloyd.chass.utoronto.ca> <1339155965-sup-1860@pinkfloyd.chass.utoronto.ca> <1339552426-sup-2945@pinkfloyd.chass.utoronto.ca> Message-ID: <20120613174902.GD13695@bender.opencsw.org> Hi Peter On Wed, Jun 13, 2012 at 07:13:40PM +0200, Peter FELECAN wrote: > Ben Walton writes: > > > Excerpts from Yann Rouillard's message of Fri Jun 08 10:35:20 -0400 2012: > > > >> This is done: > >> http://wiki.opencsw.org/project-openssl > >> > >> However, the resultat is that there is a group of 80 packages which > >> should be released together to avoid a dual linking runtime > >> situation for any of them or for their reverse dependancies. > > > > I think we're making good progress. As I have cycles, I'm tackling > > packages from retired maintainers that still look useful... > > > > Is anyone up for rebuilding the gnome/gtk stuff that's been orphaned? > > If not, we may need to make some hard choices about the future of this > > package set... > > > > Peter F: Is it something you'd consider? You're one of the few still > > building things that care about a desktop. > > I was quite sure that saying that I was putting my finger in the > wheels... For the moment I'm slowly migrating from private recipes to > GAR based ones. If my time permits I can look in gtk and then > gnome. What about glib? You don't need to bother with (lib)gtk+2, I will take care of that. As for glib2, there is no dependency of ssl, so no worries. cheers rafi > -- > Peter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From bwalton at opencsw.org Thu Jun 14 02:53:12 2012 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 13 Jun 2012 20:53:12 -0400 Subject: [csw-maintainers] openssl relinking effort In-Reply-To: <20120613174902.GD13695@bender.opencsw.org> References: <1339031740-sup-6645@pinkfloyd.chass.utoronto.ca> <1339123346-sup-3285@pinkfloyd.chass.utoronto.ca> <1339155965-sup-1860@pinkfloyd.chass.utoronto.ca> <1339552426-sup-2945@pinkfloyd.chass.utoronto.ca> <20120613174902.GD13695@bender.opencsw.org> Message-ID: <1339635143-sup-2140@pinkfloyd.chass.utoronto.ca> Excerpts from Rafael Ostertag's message of Wed Jun 13 13:49:02 -0400 2012: > > I was quite sure that saying that I was putting my finger in the > > wheels... For the moment I'm slowly migrating from private recipes > > to GAR based ones. If my time permits I can look in gtk and then > > gnome. What about glib? > > You don't need to bother with (lib)gtk+2, I will take care of > that. As for glib2, there is no dependency of ssl, so no worries. This is great. Thanks to both of you! Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From romeotheriault at opencsw.org Thu Jun 14 04:48:10 2012 From: romeotheriault at opencsw.org (Romeo Theriault) Date: Wed, 13 Jun 2012 16:48:10 -1000 Subject: [csw-maintainers] Include additional files in package from source download Message-ID: I'd like to include some additional files (e.g. AUTHORS, Changelog, NEWS, README ) that are included in the source download, in the /opt/csw/share/doc/libzmq/ directory of the package. Right now they are not being included in the package. I noticed that the license file is put in this directory by default. How would I go about specifying in the Makefile that I want these additional files included in the package in that directory. I looked through the GAR variables wiki page and at least to my newbie eye's don't immediately see how to do this. Any pointers are much appreciated. Thanks, Romeo From romeotheriault at opencsw.org Thu Jun 14 06:03:32 2012 From: romeotheriault at opencsw.org (Romeo Theriault) Date: Wed, 13 Jun 2012 18:03:32 -1000 Subject: [csw-maintainers] Include additional files in package from source download In-Reply-To: References: Message-ID: On Wed, Jun 13, 2012 at 4:48 PM, Romeo Theriault wrote: > I'd like to include some additional files (e.g. AUTHORS, Changelog, > NEWS, README ) that are included in the source download, in the > /opt/csw/share/doc/libzmq/ directory of the package. Right now they > are not being included in the package. I noticed that the license file > is put in this directory by default. How would I go about specifying > in the Makefile that I want these additional files included in the > package in that directory. I looked through the GAR variables wiki > page and at least to my newbie eye's don't immediately see how to do > this. I think I should include some additional info. I'm trying to build the zeromq package; and split it into two packages, libzmq and libzmq-dev. This all works just fine (see Makefile below), but I'd like to additionally include a few files from the source in the libzmq package. Is this possible without resorting to custom INSTALL_SCRIPTS? NAME = zeromq VERSION = 2.2.0 GARTYPE = v2 CATEGORIES = lib DESCRIPTION = Software library for fast, message-based applications define BLURB The 0MQ lightweight messaging kernel is a library which extends the standard socket interfaces with features traditionally provided by specialized messaging middle-ware products. 0MQ sockets provide an abstraction of asynchronous message queues, multiple messaging patterns, message filtering (subscriptions), seamless access to multiple transport protocols and more. This package contains the ZeroMQ shared library. endef MASTER_SITES = http://download.zeromq.org/ DISTFILES = $(DISTNAME).tar.gz PACKAGES += CSWlibzmq SPKG_DESC_CSWlibzmq = Software library for fast, message-based applications PACKAGES += CSWlibzmq-dev CATALOGNAME_CSWlibzmq-dev = libzmq_dev SPKG_DESC_CSWlibzmq-dev += ZeroMQ development files RUNTIME_DEP_PKGS_CSWlibzmq-dev += CSWlibzmq CONFIGURE_ARGS = $(DIRPATHS) PKGFILES_CSWlibzmq-dev = $(PKGFILES_DEVEL) PKGFILES_CSWlibzmq-dev += .*\.7 include gar/category.mk Thank you, Romeo From dam at opencsw.org Thu Jun 14 07:55:16 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 14 Jun 2012 07:55:16 +0200 Subject: [csw-maintainers] Include additional files in package from source download In-Reply-To: References: Message-ID: <90CFE696-DE19-4209-9D45-66F9D5D36F91@opencsw.org> Hi Romeo, Am 14.06.2012 um 06:03 schrieb Romeo Theriault: > On Wed, Jun 13, 2012 at 4:48 PM, Romeo Theriault > wrote: >> I'd like to include some additional files (e.g. AUTHORS, Changelog, >> NEWS, README ) that are included in the source download, in the >> /opt/csw/share/doc/libzmq/ directory of the package. Right now they >> are not being included in the package. I noticed that the license file >> is put in this directory by default. How would I go about specifying >> in the Makefile that I want these additional files included in the >> package in that directory. I looked through the GAR variables wiki >> page and at least to my newbie eye's don't immediately see how to do >> this. > > I think I should include some additional info. I'm trying to build the > zeromq package; and split it into two packages, libzmq and libzmq-dev. > This all works just fine (see Makefile below), but I'd like to > additionally include a few files from the source in the libzmq > package. Is this possible without resorting to custom INSTALL_SCRIPTS? Not yet :-) I just talked with Peter about this: http://lists.opencsw.org/pipermail/maintainers/2012-June/016738.html > NAME = zeromq > VERSION = 2.2.0 > GARTYPE = v2 > CATEGORIES = lib > > DESCRIPTION = Software library for fast, message-based applications > define BLURB > The 0MQ lightweight messaging kernel is a library which extends the > standard socket interfaces with features traditionally provided by > specialized messaging middle-ware products. 0MQ sockets provide an > abstraction of asynchronous message queues, multiple messaging > patterns, message filtering (subscriptions), seamless access to > multiple transport protocols and more. > > This package contains the ZeroMQ shared library. > endef > > MASTER_SITES = http://download.zeromq.org/ > DISTFILES = $(DISTNAME).tar.gz > > PACKAGES += CSWlibzmq > SPKG_DESC_CSWlibzmq = Software library for fast, message-based applications > > PACKAGES += CSWlibzmq-dev > CATALOGNAME_CSWlibzmq-dev = libzmq_dev I would recommend only setting CATALOGNAME when it differs from the canonical one derived from the package name (which is stripping of CSW prefix and replacing - by _). > SPKG_DESC_CSWlibzmq-dev += ZeroMQ development files > RUNTIME_DEP_PKGS_CSWlibzmq-dev += CSWlibzmq > > CONFIGURE_ARGS = $(DIRPATHS) > > PKGFILES_CSWlibzmq-dev = $(PKGFILES_DEVEL) It is usually a good idea to always use += as this allows reordering of lines without, umh, "forgetting" to add/remove the "+" :-) > PKGFILES_CSWlibzmq-dev += .*\.7 I suggest grouping PKGFILES with the respective package after SPKG_DESC. Additionally, I would assume that CSWlibzmq contains a shared library with a specific soname. If this is the case there is a rule to name the package by the soname, like e.g. CSWlibzmq1-3 for libzmq-1.so.3 For this you would use PKGFILES_CSWlibzmq1-3 += $(call pkgfiles_lib,libzmq-1.so.3) Best regards -- Dago From romeotheriault at opencsw.org Thu Jun 14 11:14:27 2012 From: romeotheriault at opencsw.org (Romeo Theriault) Date: Wed, 13 Jun 2012 23:14:27 -1000 Subject: [csw-maintainers] Include additional files in package from source download In-Reply-To: <90CFE696-DE19-4209-9D45-66F9D5D36F91@opencsw.org> References: <90CFE696-DE19-4209-9D45-66F9D5D36F91@opencsw.org> Message-ID: Hi Dago, On Wed, Jun 13, 2012 at 7:55 PM, Dagobert Michelsen wrote: > Hi Romeo, > > Am 14.06.2012 um 06:03 schrieb Romeo Theriault: > Is this possible without resorting to custom INSTALL_SCRIPTS? > > Not yet :-) I just talked with Peter about this: > ?http://lists.opencsw.org/pipermail/maintainers/2012-June/016738.html Ahhh, yeah, I remember reading that. :) It was too early in my GAR understanding to know what was really being said though. I do like what you were suggesting though: > EXTRA_DOCS_CSWmypkg += README.CSW > EXTRA_DOCS_CSWmypkg += morestuff.txt > EXTRA_DOCS += this-goes-to-all-pkgs.txt This seems very useful. If this would allow one to pull files from the source distribution that would perfectly fit what I'm trying to accomplish. Assuming I need to create custom INSTALL_SCRIPT target to get the files I want in the pkg I have a few questions. * Does INSTALL_SCRIPT accept the '+=' assignment? In other words can I have the Makefile use it's default target but also use this new custom target? (I may not be using the correct terminology.) What I'm trying to determine is if I need to now completely manage which files go in which package or if I can keep the current defaults and just add the few extra files I want. * Does the INSTALL_SCRIPT variable allow me to do 'INSTALL_SCRIPT_CSWlibzmq' so the custom install scripts only get executed for the 'libzmq' package and not the 'libzmq-dev' package? >> NAME = zeromq >> VERSION = 2.2.0 >> GARTYPE = v2 >> CATEGORIES = lib >> >> DESCRIPTION = Software library for fast, message-based applications >> define BLURB >> ? ? ? ?The 0MQ lightweight messaging kernel is a library which extends the >> ? ? ? ?standard socket interfaces with features traditionally provided by >> ? ? ? ?specialized messaging middle-ware products. 0MQ sockets provide an >> ? ? ? ?abstraction of asynchronous message queues, multiple messaging >> ? ? ? ?patterns, message filtering (subscriptions), seamless access to >> ? ? ? ?multiple transport protocols and more. >> >> ? ? ? ?This package contains the ZeroMQ shared library. >> endef >> >> MASTER_SITES = http://download.zeromq.org/ >> DISTFILES ?= $(DISTNAME).tar.gz >> >> PACKAGES += CSWlibzmq >> SPKG_DESC_CSWlibzmq = Software library for fast, message-based applications >> >> PACKAGES += CSWlibzmq-dev >> CATALOGNAME_CSWlibzmq-dev = libzmq_dev > > I would recommend only setting CATALOGNAME when it differs from the canonical > one derived from the package name (which is stripping of CSW prefix and replacing > - by _). Ok, that makes sense; I'll remove that line. > >> SPKG_DESC_CSWlibzmq-dev += ZeroMQ development files >> RUNTIME_DEP_PKGS_CSWlibzmq-dev += CSWlibzmq >> >> CONFIGURE_ARGS = $(DIRPATHS) >> >> PKGFILES_CSWlibzmq-dev = $(PKGFILES_DEVEL) > > It is usually a good idea to always use += as this allows reordering of lines > without, umh, "forgetting" to add/remove the "+" :-) Thanks, that makes sense. I'll add the '+'. > >> PKGFILES_CSWlibzmq-dev += .*\.7 > > I suggest grouping PKGFILES with the respective package after SPKG_DESC. Will do. > > Additionally, I would assume that CSWlibzmq contains a shared library with a specific soname. > If this is the case there is a rule to name the package by the soname, like e.g. > ?CSWlibzmq1-3 > for libzmq-1.so.3 > For this you would use > ?PKGFILES_CSWlibzmq1-3 += $(call pkgfiles_lib,libzmq-1.so.3) Ok, I'll rename the package and give it a try. Thanks for pointing these out. Thank you very much for the help, Romeo > > > Best regards > > ?-- Dago > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From maciej at opencsw.org Thu Jun 14 17:56:32 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 14 Jun 2012 16:56:32 +0100 Subject: [csw-maintainers] amds64/libz.so.1 problem on unstable10x Message-ID: Heads up: A serious issue with the libz library was reported by raos yesterday. The issue was linking related. Under the risk of being excommunicated, I've rebuilt the library with GCC and using the GNU linker, pushed to unstable, and installed on unstable10x. Let's talk about a proper fix. Rafael, could you repeat your investigation results so far? Maciej From dam at opencsw.org Thu Jun 14 19:20:55 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 14 Jun 2012 19:20:55 +0200 Subject: [csw-maintainers] amds64/libz.so.1 problem on unstable10x In-Reply-To: References: Message-ID: <4530252D-28DF-4B9C-9FFA-A1440D179F0D@opencsw.org> Hi Maciej, Am 14.06.2012 um 17:56 schrieb Maciej (Matchek) Blizi?ski: > Heads up: A serious issue with the libz library was reported by raos > yesterday. The issue was linking related. Under the risk of being > excommunicated, I've rebuilt the library with GCC and using the GNU > linker, pushed to unstable, and installed on unstable10x. > > Let's talk about a proper fix. Rafael, could you repeat your > investigation results so far? I had the same issue with jbig and adjusted the build flags accordingly: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/jbigkit/trunk/Makefile I'm underway and earliest would be tomorrow for me to investigate. Bestz regards -- DFago From maciej at opencsw.org Thu Jun 14 19:25:08 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 14 Jun 2012 18:25:08 +0100 Subject: [csw-maintainers] amds64/libz.so.1 problem on unstable10x In-Reply-To: <4530252D-28DF-4B9C-9FFA-A1440D179F0D@opencsw.org> References: <4530252D-28DF-4B9C-9FFA-A1440D179F0D@opencsw.org> Message-ID: No dia 14 de Jun de 2012 18:21, "Dagobert Michelsen" escreveu: > > Hi Maciej, > > Am 14.06.2012 um 17:56 schrieb Maciej (Matchek) Blizi?ski: > > Heads up: A serious issue with the libz library was reported by raos > > yesterday. The issue was linking related. Under the risk of being > > excommunicated, I've rebuilt the library with GCC and using the GNU > > linker, pushed to unstable, and installed on unstable10x. > > > > Let's talk about a proper fix. Rafael, could you repeat your > > investigation results so far? > > I had the same issue with jbig and adjusted the build flags accordingly: > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/jbigkit/trunk/Makefile > > I'm underway and earliest would be tomorrow for me to investigate. Could be the same issue. Sound like a good candidate for a porting FAQ item. -------------- next part -------------- An HTML attachment was scrubbed... URL: From raos at opencsw.org Thu Jun 14 19:54:27 2012 From: raos at opencsw.org (Rafael Ostertag) Date: Thu, 14 Jun 2012 19:54:27 +0200 Subject: [csw-maintainers] amds64/libz.so.1 problem on unstable10x In-Reply-To: References: Message-ID: <20120614175427.GA15615@bender.opencsw.org> On Thu, Jun 14, 2012 at 04:56:32PM +0100, Maciej (Matchek) Blizi??ski wrote: > Heads up: A serious issue with the libz library was reported by raos > yesterday. The issue was linking related. Under the risk of being > excommunicated, I've rebuilt the library with GCC and using the GNU > linker, pushed to unstable, and installed on unstable10x. > > Let's talk about a proper fix. Rafael, could you repeat your > investigation results so far? while building libz for amd64, the compiler emitted code that cannot be relocated properly when the library is mapped into the address space of the executable, resulting in error messages like ld.so.1: conftest: fatal: relocation error: R_AMD64_32: file /opt/csw/lib/amd64/libz.so.1: symbol (unknown): value 0xfffffd7fff040000 does not fit Inspecting libz using elfdump(1) (`elfdump -r`) shows many /opt/csw/lib/amd64/libz.so.1: bad relocation entry: R_AMD64_32: relocation requires symbol messages. Also, the relocation section has many R_AMD64_PC32 0xb9ae 0xfffffffffffffffc .rela.text where the value (addend) 0xfffffffffffffffc is out of bounds, since R_AMD64_PC32 is 32bit (see [1]; please correct me if I'm wrong on this), thus resulting in the dynamic linker error message ... value 0x<64bit value> does not fit Long story short, libz on amd64 is fubar.o If that's ok, I can dig into the problem tonight... cheers rafi [1] http://www.x86-64.org/documentation/abi.pdf > > Maciej > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From raos at opencsw.org Thu Jun 14 19:57:35 2012 From: raos at opencsw.org (Rafael Ostertag) Date: Thu, 14 Jun 2012 19:57:35 +0200 Subject: [csw-maintainers] amds64/libz.so.1 problem on unstable10x In-Reply-To: References: <4530252D-28DF-4B9C-9FFA-A1440D179F0D@opencsw.org> Message-ID: <20120614175735.GB15615@bender.opencsw.org> Hi Guys On Thu, Jun 14, 2012 at 06:25:08PM +0100, Maciej (Matchek) Blizi??ski wrote: > No dia 14 de Jun de 2012 18:21, "Dagobert Michelsen" > escreveu: > > > > Hi Maciej, > > > > Am 14.06.2012 um 17:56 schrieb Maciej (Matchek) Blizi??ski: > > > Heads up: A serious issue with the libz library was reported by raos > > > yesterday. The issue was linking related. Under the risk of being > > > excommunicated, I've rebuilt the library with GCC and using the GNU > > > linker, pushed to unstable, and installed on unstable10x. > > > > > > Let's talk about a proper fix. Rafael, could you repeat your > > > investigation results so far? > > > > I had the same issue with jbig and adjusted the build flags accordingly: > > > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/jbigkit/trunk/Makefile > > > > I'm underway and earliest would be tomorrow for me to investigate. > > Could be the same issue. Sound like a good candidate for a porting FAQ > item. Yes, omitting -Kpic on amd64 is by far the best candidate to create broken shared objects. cheers rafi > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From raos at opencsw.org Fri Jun 15 00:48:54 2012 From: raos at opencsw.org (Rafael Ostertag) Date: Fri, 15 Jun 2012 00:48:54 +0200 Subject: [csw-maintainers] [SOLVED] amds64/libz.so.1 problem on unstable10x In-Reply-To: <20120614175735.GB15615@bender.opencsw.org> References: <4530252D-28DF-4B9C-9FFA-A1440D179F0D@opencsw.org> <20120614175735.GB15615@bender.opencsw.org> Message-ID: <20120614224854.GG11861@bender.opencsw.org> Hi All On Thu, Jun 14, 2012 at 07:57:35PM +0200, Rafael Ostertag wrote: > Hi Guys > > On Thu, Jun 14, 2012 at 06:25:08PM +0100, Maciej (Matchek) Blizi??ski wrote: > > No dia 14 de Jun de 2012 18:21, "Dagobert Michelsen" > > escreveu: > > > > > > Hi Maciej, > > > > > > Am 14.06.2012 um 17:56 schrieb Maciej (Matchek) Blizi??ski: > > > > Heads up: A serious issue with the libz library was reported by raos > > > > yesterday. The issue was linking related. Under the risk of being > > > > excommunicated, I've rebuilt the library with GCC and using the GNU > > > > linker, pushed to unstable, and installed on unstable10x. > > > > > > > > Let's talk about a proper fix. Rafael, could you repeat your > > > > investigation results so far? > > > > > > I had the same issue with jbig and adjusted the build flags accordingly: > > > > > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/jbigkit/trunk/Makefile > > > > > > I'm underway and earliest would be tomorrow for me to investigate. Adding the proper build flags, i.e. -Kpic for x86, solved the issue. The package has been rebuilt using Sun Studio and is already installed on unstable10x. cheers rafi From romeotheriault at opencsw.org Fri Jun 15 03:40:14 2012 From: romeotheriault at opencsw.org (Romeo Theriault) Date: Thu, 14 Jun 2012 15:40:14 -1000 Subject: [csw-maintainers] Include additional files in package from source download In-Reply-To: References: <90CFE696-DE19-4209-9D45-66F9D5D36F91@opencsw.org> Message-ID: On Wed, Jun 13, 2012 at 11:14 PM, Romeo Theriault < romeotheriault at opencsw.org> wrote: > Hi Dago, > > On Wed, Jun 13, 2012 at 7:55 PM, Dagobert Michelsen > wrote: > > Hi Romeo, > > > > Am 14.06.2012 um 06:03 schrieb Romeo Theriault: > > Is this possible without resorting to custom INSTALL_SCRIPTS? > > > > Not yet :-) I just talked with Peter about this: > > http://lists.opencsw.org/pipermail/maintainers/2012-June/016738.html > Just to follow up on this thread, after a bunch of looking at other Makefiles and testing things out I finally got what I wanted by adding a 'post-install-modulated' target in my Makefile. This did the trick: post-install-modulated: DOCDEST = $(DESTDIR)$(docdir)/libzmq1 post-install-modulated: DOCS = AUTHORS ChangeLog COPYING.LESSER MAINTAINERS README post-install-modulated: # Copy documentation (upstream) ginstall -d $(DOCDEST) cp $(addprefix $(WORKSRC)/,$(DOCS)) $(DOCDEST) @$(MAKECOOKIE) Romeo -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Fri Jun 15 03:58:09 2012 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 14 Jun 2012 21:58:09 -0400 Subject: [csw-maintainers] Include additional files in package from source download In-Reply-To: References: <90CFE696-DE19-4209-9D45-66F9D5D36F91@opencsw.org> Message-ID: <1339725459-sup-6846@pinkfloyd.chass.utoronto.ca> Excerpts from Romeo Theriault's message of Thu Jun 14 21:40:14 -0400 2012: Hi Romeo, > post-install-modulated: DOCDEST = $(DESTDIR)$(docdir)/libzmq1 > post-install-modulated: DOCS = AUTHORS ChangeLog COPYING.LESSER MAINTAINERS > README > post-install-modulated: > > # Copy documentation (upstream) > ginstall -d $(DOCDEST) > cp $(addprefix $(WORKSRC)/,$(DOCS)) $(DOCDEST) > > @$(MAKECOOKIE) That looks perfect! Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Fri Jun 15 10:32:22 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 15 Jun 2012 09:32:22 +0100 Subject: [csw-maintainers] openssl relinking effort In-Reply-To: <1339635143-sup-2140@pinkfloyd.chass.utoronto.ca> References: <1339031740-sup-6645@pinkfloyd.chass.utoronto.ca> <1339123346-sup-3285@pinkfloyd.chass.utoronto.ca> <1339155965-sup-1860@pinkfloyd.chass.utoronto.ca> <1339552426-sup-2945@pinkfloyd.chass.utoronto.ca> <20120613174902.GD13695@bender.opencsw.org> <1339635143-sup-2140@pinkfloyd.chass.utoronto.ca> Message-ID: Just found that there's still one symlink to 1.0.0: maciej at unstable10x [unstable10x]:~ $ ls -l /opt/csw/lib/libcrypto.so lrwxrwxrwx 1 root root 18 May 17 15:22 /opt/csw/lib/libcrypto.so -> libcrypto.so.1.0.0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Fri Jun 15 10:37:50 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 15 Jun 2012 09:37:50 +0100 Subject: [csw-maintainers] openssl relinking effort In-Reply-To: References: <1339031740-sup-6645@pinkfloyd.chass.utoronto.ca> <1339123346-sup-3285@pinkfloyd.chass.utoronto.ca> <1339155965-sup-1860@pinkfloyd.chass.utoronto.ca> <1339552426-sup-2945@pinkfloyd.chass.utoronto.ca> <20120613174902.GD13695@bender.opencsw.org> <1339635143-sup-2140@pinkfloyd.chass.utoronto.ca> Message-ID: 2012/6/15 Maciej (Matchek) Blizi?ski > > Just found that there's still one symlink to 1.0.0: > > maciej at unstable10x [unstable10x]:~ $ ls -l /opt/csw/lib/libcrypto.so > lrwxrwxrwx ? 1 root ? ? root ? ? ? ? ?18 May 17 15:22 /opt/csw/lib/libcrypto.so -> libcrypto.so.1.0.0 When I saw libssl_dev-0.9.8 on the buildfarm, I assumed that it's been downgraded in the catalogs, and the buildfarm install is in sync, but it turned out not to be the case. So I downgraded libssl_dev to the version from the dublin catalog. From grzemba at contac-dt.de Fri Jun 15 12:28:59 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Fri, 15 Jun 2012 12:28:59 +0200 Subject: [csw-maintainers] docdir and datadir for gxx packages Message-ID: <7460965a637b.4fdb2a8b@contac-dt.de> Hi, there are gcc packages which use prefix /opt/csw/gxx. mgar handles this in a kind that docdir and datadir also are located below this prefix (except license file) Im my opinion we should not establish a new subpath /opt/csw/gxx/share instead put all the doc and data? stuff below /opt/csw/share. What think the others. -- Carsten Grzemba -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Fri Jun 15 13:36:03 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 15 Jun 2012 07:36:03 -0400 Subject: [csw-maintainers] docdir and datadir for gxx packages In-Reply-To: <7460965a637b.4fdb2a8b@contac-dt.de> References: <7460965a637b.4fdb2a8b@contac-dt.de> Message-ID: <0f95f609-2570-4391-8085-43850f939226@email.android.com> Hi Carsten, I she with you. We should preserve the traditional locations for data and doc directories when building gxx packages. Thanks -Ben Carsten Grzemba wrote: Hi, there are gcc packages which use prefix /opt/csw/gxx. mgar handles this in a kind that docdir and datadir also are located below this prefix (except license file) Im my opinion we should not establish a new subpath /opt/csw/gxx/share instead put all the doc and data stuff below /opt/csw/share. What think the others. -- Carsten Grzemba -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Fri Jun 15 18:34:29 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 15 Jun 2012 12:34:29 -0400 Subject: [csw-maintainers] docdir and datadir for gxx packages In-Reply-To: <0f95f609-2570-4391-8085-43850f939226@email.android.com> References: <7460965a637b.4fdb2a8b@contac-dt.de> <0f95f609-2570-4391-8085-43850f939226@email.android.com> Message-ID: <1339778039-sup-4108@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Fri Jun 15 07:36:03 -0400 2012: > I she with you. We should preserve the traditional locations for s/she/agree/; Damn you auto-correct (and my lack of proof reading). Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From ihsan at opencsw.org Fri Jun 15 19:10:44 2012 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Fri, 15 Jun 2012 19:10:44 +0200 Subject: [csw-maintainers] [csw-buildfarm] libldns1 on the buildfarm In-Reply-To: <50678B5C-2BA4-415A-A5F0-F6F8D0E11103@opencsw.org> References: <4FD50623.4040602@opencsw.org> <9E43AE69-3F3E-4ABD-98AC-ADFD4A47C35D@opencsw.org> <50678B5C-2BA4-415A-A5F0-F6F8D0E11103@opencsw.org> Message-ID: <4FDB6C94.2020309@opencsw.org> Hi Dago, Am 10.06.2012 23:54, schrieb Dagobert Michelsen: >> Am 10.06.2012 um 22:40 schrieb ?hsan Do?an: >>> Please update libldns1 to libldns1-1.6.13 on the buildfarm. >>> I've commited libldns1-1.6.13 this evening to unstable. >> >> Updating unstable* now (67 packages total), please stand by. > > During the update the filesystem of unstable10x filled up, I will clean this up > tomorrow. Please stand by. Have you been able to look at this already? Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Fri Jun 15 21:25:47 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 15 Jun 2012 21:25:47 +0200 Subject: [csw-maintainers] openssl relinking effort In-Reply-To: References: <1339031740-sup-6645@pinkfloyd.chass.utoronto.ca> <1339123346-sup-3285@pinkfloyd.chass.utoronto.ca> <1339155965-sup-1860@pinkfloyd.chass.utoronto.ca> <1339552426-sup-2945@pinkfloyd.chass.utoronto.ca> <20120613174902.GD13695@bender.opencsw.org> <1339635143-sup-2140@pinkfloyd.chass.utoronto.ca> Message-ID: <924B8874-9E01-458B-8614-65649A5AD7CA@opencsw.org> Hi Maciej, Am 15.06.2012 um 10:37 schrieb Maciej (Matchek) Blizi?ski: > 2012/6/15 Maciej (Matchek) Blizi?ski >> >> Just found that there's still one symlink to 1.0.0: >> >> maciej at unstable10x [unstable10x]:~ $ ls -l /opt/csw/lib/libcrypto.so >> lrwxrwxrwx 1 root root 18 May 17 15:22 /opt/csw/lib/libcrypto.so -> libcrypto.so.1.0.0 > > When I saw libssl_dev-0.9.8 on the buildfarm, I assumed that it's been > downgraded in the catalogs, and the buildfarm install is in sync, but > it turned out not to be the case. So I downgraded libssl_dev to the > version from the dublin catalog. Just to make sure: - Solaris 9 keeps 0.9.8 - Solaris 10 has 1.0.0 Right? Best regards -- Dago From dam at opencsw.org Fri Jun 15 21:31:39 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 15 Jun 2012 21:31:39 +0200 Subject: [csw-maintainers] docdir and datadir for gxx packages In-Reply-To: <0f95f609-2570-4391-8085-43850f939226@email.android.com> References: <7460965a637b.4fdb2a8b@contac-dt.de> <0f95f609-2570-4391-8085-43850f939226@email.android.com> Message-ID: <4F679A72-6631-41B0-AC6C-EA84DE46C0B0@opencsw.org> Hi, Am 15.06.2012 um 13:36 schrieb Ben Walton: > I agree with you. We should preserve the traditional locations for data and doc directories when building gxx packages. The problem is when we have packages compiled both with Sun Studio and gxx competing for the files. For licenses it is easy as the docdir contains the catalogname of the package in the path which is unique. This is not true for datadir. Best regards -- Dago > Thanks > -Ben > > Carsten Grzemba wrote: > Hi, > > there are gcc packages which use prefix /opt/csw/gxx. mgar handles this in a kind that docdir and datadir also are located below this prefix (except license file) > Im my opinion we should not establish a new subpath /opt/csw/gxx/share instead put all the doc and data stuff below /opt/csw/share. > > What think the others. > -- > Carsten Grzemba > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Fri Jun 15 21:33:53 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 15 Jun 2012 21:33:53 +0200 Subject: [csw-maintainers] [csw-buildfarm] libldns1 on the buildfarm In-Reply-To: <4FDB6C94.2020309@opencsw.org> References: <4FD50623.4040602@opencsw.org> <9E43AE69-3F3E-4ABD-98AC-ADFD4A47C35D@opencsw.org> <50678B5C-2BA4-415A-A5F0-F6F8D0E11103@opencsw.org> <4FDB6C94.2020309@opencsw.org> Message-ID: Hi Ihsan, Am 15.06.2012 um 19:10 schrieb ?hsan Do?an: > Am 10.06.2012 23:54, schrieb Dagobert Michelsen: > >>> Am 10.06.2012 um 22:40 schrieb ?hsan Do?an: >>>> Please update libldns1 to libldns1-1.6.13 on the buildfarm. >>>> I've commited libldns1-1.6.13 this evening to unstable. >>> >>> Updating unstable* now (67 packages total), please stand by. >> >> During the update the filesystem of unstable10x filled up, I will clean this up >> tomorrow. Please stand by. > > Have you been able to look at this already? Ah yes, on the same evening. I forgot to drop a note about the status, sorry. If there are any problems left please let me know. Best regards -- Dago From bwalton at opencsw.org Fri Jun 15 21:51:04 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 15 Jun 2012 15:51:04 -0400 Subject: [csw-maintainers] docdir and datadir for gxx packages In-Reply-To: <4F679A72-6631-41B0-AC6C-EA84DE46C0B0@opencsw.org> References: <7460965a637b.4fdb2a8b@contac-dt.de> <0f95f609-2570-4391-8085-43850f939226@email.android.com> <4F679A72-6631-41B0-AC6C-EA84DE46C0B0@opencsw.org> Message-ID: <1339789706-sup-1227@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Fri Jun 15 15:31:39 -0400 2012: > The problem is when we have packages compiled both with Sun Studio > and gxx competing for the files. For licenses it is easy as the > docdir contains the catalogname of the package in the path which is > unique. This is not true for datadir. If we're building with both compilers, this would be via modulation, right? The merge should just land one version over the other and we then split that out into something both package depend on. If we only build with one compiler or the other, it wouldn't be a problem. The only problem I could see is if for some reason the data in those directories isn't agnostic about what uses it and embeds paths to the gxx directory...that shouldn't happen but I wouldn't be that it doesn't. :) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sat Jun 16 01:24:16 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 16 Jun 2012 00:24:16 +0100 Subject: [csw-maintainers] openssl relinking effort In-Reply-To: <924B8874-9E01-458B-8614-65649A5AD7CA@opencsw.org> References: <1339031740-sup-6645@pinkfloyd.chass.utoronto.ca> <1339123346-sup-3285@pinkfloyd.chass.utoronto.ca> <1339155965-sup-1860@pinkfloyd.chass.utoronto.ca> <1339552426-sup-2945@pinkfloyd.chass.utoronto.ca> <20120613174902.GD13695@bender.opencsw.org> <1339635143-sup-2140@pinkfloyd.chass.utoronto.ca> <924B8874-9E01-458B-8614-65649A5AD7CA@opencsw.org> Message-ID: 2012/6/15 Dagobert Michelsen > Just to make sure: > - Solaris 9 keeps 0.9.8 > - Solaris 10 has 1.0.0 > > Right? > OK, so if this is the case, then we need to upload the dev package from 1.0 to the 5.10 catalog. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Sat Jun 16 01:35:46 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 15 Jun 2012 19:35:46 -0400 Subject: [csw-maintainers] openssl relinking effort In-Reply-To: References: <1339031740-sup-6645@pinkfloyd.chass.utoronto.ca> <1339123346-sup-3285@pinkfloyd.chass.utoronto.ca> <1339155965-sup-1860@pinkfloyd.chass.utoronto.ca> <1339552426-sup-2945@pinkfloyd.chass.utoronto.ca> <20120613174902.GD13695@bender.opencsw.org> <1339635143-sup-2140@pinkfloyd.chass.utoronto.ca> <924B8874-9E01-458B-8614-65649A5AD7CA@opencsw.org> Message-ID: <1339803316-sup-8738@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Fri Jun 15 19:24:16 -0400 2012: > > - Solaris 9 keeps 0.9.8 > > - Solaris 10 has 1.0.0 > > OK, so if this is the case, then we need to upload the dev package > from 1.0 to the 5.10 catalog. This is what I thought was happening. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From ihsan at opencsw.org Sat Jun 16 10:38:26 2012 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Sat, 16 Jun 2012 10:38:26 +0200 Subject: [csw-maintainers] [csw-buildfarm] libldns1 on the buildfarm In-Reply-To: References: <4FD50623.4040602@opencsw.org> <9E43AE69-3F3E-4ABD-98AC-ADFD4A47C35D@opencsw.org> <50678B5C-2BA4-415A-A5F0-F6F8D0E11103@opencsw.org> <4FDB6C94.2020309@opencsw.org> Message-ID: <4FDC4602.9050301@opencsw.org> Hi Dago, Am 15.06.2012 21:33, schrieb Dagobert Michelsen: >>>>> Please update libldns1 to libldns1-1.6.13 on the buildfarm. >>>>> I've commited libldns1-1.6.13 this evening to unstable. >>>> >>>> Updating unstable* now (67 packages total), please stand by. >>> >>> During the update the filesystem of unstable10x filled up, I will clean this up >>> tomorrow. Please stand by. >> >> Have you been able to look at this already? > > Ah yes, on the same evening. I forgot to drop a note about the > status, sorry. If there are any problems left please let me know. Oh, thanks. Could you please also update libldns1? BTW, why is the buildfarm so slow these days? Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Sat Jun 16 17:55:19 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 16 Jun 2012 17:55:19 +0200 Subject: [csw-maintainers] [csw-buildfarm] libldns1 on the buildfarm In-Reply-To: <4FDC4602.9050301@opencsw.org> References: <4FD50623.4040602@opencsw.org> <9E43AE69-3F3E-4ABD-98AC-ADFD4A47C35D@opencsw.org> <50678B5C-2BA4-415A-A5F0-F6F8D0E11103@opencsw.org> <4FDB6C94.2020309@opencsw.org> <4FDC4602.9050301@opencsw.org> Message-ID: <393B2E5E-683D-479C-9694-436B173C784C@opencsw.org> Hi Ihsan, Am 16.06.2012 um 10:38 schrieb ?hsan Do?an: > Am 15.06.2012 21:33, schrieb Dagobert Michelsen: > >>>>>> Please update libldns1 to libldns1-1.6.13 on the buildfarm. >>>>>> I've commited libldns1-1.6.13 this evening to unstable. >>>>> >>>>> Updating unstable* now (67 packages total), please stand by. >>>> >>>> During the update the filesystem of unstable10x filled up, I will clean this up >>>> tomorrow. Please stand by. >>> >>> Have you been able to look at this already? >> >> Ah yes, on the same evening. I forgot to drop a note about the >> status, sorry. If there are any problems left please let me know. > > Oh, thanks. > > Could you please also update libldns1? Done on unstable* > BTW, why is the buildfarm so slow these days? The rpool became too full. I did some cleanup, but probably I need to relocate some zones to another pool later on. Please let me know if there are still performance problems. Best regards -- Dago From dam at opencsw.org Sat Jun 16 17:57:42 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 16 Jun 2012 17:57:42 +0200 Subject: [csw-maintainers] [csw-buildfarm] request to install CSWlibglib2-dev In-Reply-To: References: <1339591245-sup-3313@pinkfloyd.chass.utoronto.ca> <1588A1B7-41F5-4975-9E54-BDAC60C27169@opencsw.org> Message-ID: <24751389-86C5-4722-9F90-ECFE378EFF83@opencsw.org> Hi Peter, Am 16.06.2012 um 10:40 schrieb Peter FELECAN: > Dagobert Michelsen writes: >> Am 13.06.2012 um 19:21 schrieb Peter FELECAN : >>> Ben Walton writes: >>>> Excerpts from pfelecan's message of Wed Jun 13 07:19:24 -0400 2012: >>>>> Please install CSWlibglib2-dev on unstable9* >>>> >>>> Doing this now. >>> >>> pfelecan at unstable9s :~/opencsw/libgnet/trunk > pkginfo CSWlibglib2-dev >>> ERROR: information for "CSWlibglib2-dev" was not found >>> >>> pfelecan at login [login]:~ > ssh unstable9x >>> Last login: Tue Jun 12 10:08:19 2012 from login.bo.opencs >>> Sun Microsystems Inc. SunOS 5.9 Generic January 2003 >>> -bash-4.2$ pkginfo CSWlibglib2-dev >>> ERROR: information for "CSWlibglib2-dev" was not found >>> >>> What gets? >> >> Iirc the glib update was done on Solaris 10 only. > > I asked this alreade but got no answers: is there a reason? Yes. A recent glib/gtk2 is almost unbuildable on Solaris 9 as half of the testsuite fails (because features are missing). Maybe Rafi can shed some more light on it. > Should I package this only for Solaris 10? If it links to glib/gtk2: yes. > I'm more and more tempted to package only for Solaris 10 given the > increasing amount of issues that I encounter. Advice welcome! Solaris 9 is already deprecated. The rule is like: If it builds out of the box on Solaris 9, then fine, if there are any issues just move on to Solaris 10 only. Best regards -- Dago From pfelecan at opencsw.org Sat Jun 16 20:07:16 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 16 Jun 2012 20:07:16 +0200 Subject: [csw-maintainers] [csw-buildfarm] request to install CSWlibglib2-dev In-Reply-To: <24751389-86C5-4722-9F90-ECFE378EFF83@opencsw.org> (Dagobert Michelsen's message of "Sat, 16 Jun 2012 17:57:42 +0200") References: <1339591245-sup-3313@pinkfloyd.chass.utoronto.ca> <1588A1B7-41F5-4975-9E54-BDAC60C27169@opencsw.org> <24751389-86C5-4722-9F90-ECFE378EFF83@opencsw.org> Message-ID: Dagobert Michelsen writes: > Yes. A recent glib/gtk2 is almost unbuildable on Solaris 9 as half of the > testsuite fails (because features are missing). Maybe Rafi can shed some more > light on it. > >> Should I package this only for Solaris 10? > > If it links to glib/gtk2: yes. In the case of libgnet2, the package for which I'm requesting this, links only to glib, not to gtk; consequently I think that this is not an issue and the glib development package can be installed on unstable9*. What do you think? -- Peter From maciej at opencsw.org Sat Jun 16 20:23:26 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 16 Jun 2012 19:23:26 +0100 Subject: [csw-maintainers] [csw-buildfarm] request to install CSWlibglib2-dev In-Reply-To: References: <1339591245-sup-3313@pinkfloyd.chass.utoronto.ca> <1588A1B7-41F5-4975-9E54-BDAC60C27169@opencsw.org> <24751389-86C5-4722-9F90-ECFE378EFF83@opencsw.org> Message-ID: 2012/6/16 Peter FELECAN : > In the case of libgnet2, the package for which I'm requesting this, > links only to glib, not to gtk; consequently I think that this is not an > issue and the glib development package can be installed on > unstable9*. What do you think? glib is currently Solaris 10 only. There were some non-trivial build issues on Solaris 9. Rafael knows the details. From maciej at opencsw.org Sat Jun 16 20:23:57 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 16 Jun 2012 19:23:57 +0100 Subject: [csw-maintainers] [csw-buildfarm] libldns1 on the buildfarm In-Reply-To: <393B2E5E-683D-479C-9694-436B173C784C@opencsw.org> References: <4FD50623.4040602@opencsw.org> <9E43AE69-3F3E-4ABD-98AC-ADFD4A47C35D@opencsw.org> <50678B5C-2BA4-415A-A5F0-F6F8D0E11103@opencsw.org> <4FDB6C94.2020309@opencsw.org> <4FDC4602.9050301@opencsw.org> <393B2E5E-683D-479C-9694-436B173C784C@opencsw.org> Message-ID: 2012/6/16 Dagobert Michelsen : > The rpool became too full. gcc-4.7.1 came out... ;-) From dam at opencsw.org Sat Jun 16 21:32:35 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 16 Jun 2012 21:32:35 +0200 Subject: [csw-maintainers] [csw-buildfarm] libldns1 on the buildfarm In-Reply-To: References: <4FD50623.4040602@opencsw.org> <9E43AE69-3F3E-4ABD-98AC-ADFD4A47C35D@opencsw.org> <50678B5C-2BA4-415A-A5F0-F6F8D0E11103@opencsw.org> <4FDB6C94.2020309@opencsw.org> <4FDC4602.9050301@opencsw.org> <393B2E5E-683D-479C-9694-436B173C784C@opencsw.org> Message-ID: <8DD17A50-7795-4614-ACAB-99A6E8EE37D7@opencsw.org> Hi Maciej, Am 16.06.2012 um 20:23 schrieb Maciej (Matchek) Blizi?ski: > 2012/6/16 Dagobert Michelsen : >> The rpool became too full. > > gcc-4.7.1 came out... ;-) I hope you build it on your home directory. That pool should have 1 TB free :-) Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Sat Jun 16 22:02:55 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 16 Jun 2012 21:02:55 +0100 Subject: [csw-maintainers] ld: fatal: relocations remain against allocatable but non-writable sections Message-ID: When building gcc-4.7.1, I ran against this error: ld: fatal: relocations remain against allocatable but non-writable sections collect2: error: ld returned 1 exit status It happens when linking the libgnat shared object. It's reproducible, try a gcc4 build from the repository and you'll see it. I found an old discussion about the problem, and Mike's workaround was to use the GNU linker. A blog post I found[1] was to add ?-mimpure-text -lrt? to LDFLAGS. In case of GCC it's not that easy, because of nested builds with redefined environments. Does anyone have any insight about this problem? Maciej [1] http://blogs.everycity.co.uk/alasdair/2009/05/text-relocation-remains-against-symbol-libx264/ From raos at opencsw.org Sat Jun 16 22:20:20 2012 From: raos at opencsw.org (Rafael Ostertag) Date: Sat, 16 Jun 2012 22:20:20 +0200 Subject: [csw-maintainers] [csw-buildfarm] request to install CSWlibglib2-dev In-Reply-To: <24751389-86C5-4722-9F90-ECFE378EFF83@opencsw.org> References: <1339591245-sup-3313@pinkfloyd.chass.utoronto.ca> <1588A1B7-41F5-4975-9E54-BDAC60C27169@opencsw.org> <24751389-86C5-4722-9F90-ECFE378EFF83@opencsw.org> Message-ID: <20120616202020.GD15615@bender.opencsw.org> On Sat, Jun 16, 2012 at 05:57:42PM +0200, Dagobert Michelsen wrote: > Hi Peter, > > Am 16.06.2012 um 10:40 schrieb Peter FELECAN: > > Dagobert Michelsen writes: > >> Am 13.06.2012 um 19:21 schrieb Peter FELECAN : > >>> Ben Walton writes: > >>>> Excerpts from pfelecan's message of Wed Jun 13 07:19:24 -0400 2012: > >>>>> Please install CSWlibglib2-dev on unstable9* > >>>> > >>>> Doing this now. > >>> > >>> pfelecan at unstable9s :~/opencsw/libgnet/trunk > pkginfo CSWlibglib2-dev > >>> ERROR: information for "CSWlibglib2-dev" was not found > >>> > >>> pfelecan at login [login]:~ > ssh unstable9x > >>> Last login: Tue Jun 12 10:08:19 2012 from login.bo.opencs > >>> Sun Microsystems Inc. SunOS 5.9 Generic January 2003 > >>> -bash-4.2$ pkginfo CSWlibglib2-dev > >>> ERROR: information for "CSWlibglib2-dev" was not found > >>> > >>> What gets? > >> > >> Iirc the glib update was done on Solaris 10 only. > > > > I asked this alreade but got no answers: is there a reason? > > Yes. A recent glib/gtk2 is almost unbuildable on Solaris 9 as half of the > testsuite fails (because features are missing). Maybe Rafi can shed some more > light on it. There are some parts that require to be built with -xc99 which is not available on Sol9. This is the biggest show stopper for glib2 on Sol9. Cheers rafi From raos at opencsw.org Sat Jun 16 22:26:30 2012 From: raos at opencsw.org (Rafael Ostertag) Date: Sat, 16 Jun 2012 22:26:30 +0200 Subject: [csw-maintainers] ld: fatal: relocations remain against allocatable but non-writable sections In-Reply-To: References: Message-ID: <20120616202630.GE15615@bender.opencsw.org> Hi Maciej On Sat, Jun 16, 2012 at 09:02:55PM +0100, Maciej (Matchek) Blizi??ski wrote: > When building gcc-4.7.1, I ran against this error: > > ld: fatal: relocations remain against allocatable but non-writable sections > collect2: error: ld returned 1 exit status > > It happens when linking the libgnat shared object. It's reproducible, > try a gcc4 build from the repository and you'll see it. SPARC or x86? If x86, 32bit or 64bit? My first bet would be a missing -pic cheers rafi From maciej at opencsw.org Sat Jun 16 22:37:48 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 16 Jun 2012 21:37:48 +0100 Subject: [csw-maintainers] openssl relinking effort In-Reply-To: <1339803316-sup-8738@pinkfloyd.chass.utoronto.ca> References: <1339031740-sup-6645@pinkfloyd.chass.utoronto.ca> <1339123346-sup-3285@pinkfloyd.chass.utoronto.ca> <1339155965-sup-1860@pinkfloyd.chass.utoronto.ca> <1339552426-sup-2945@pinkfloyd.chass.utoronto.ca> <20120613174902.GD13695@bender.opencsw.org> <1339635143-sup-2140@pinkfloyd.chass.utoronto.ca> <924B8874-9E01-458B-8614-65649A5AD7CA@opencsw.org> <1339803316-sup-8738@pinkfloyd.chass.utoronto.ca> Message-ID: 2012/6/16 Ben Walton : > Excerpts from Maciej (Matchek) Blizi?ski's message of Fri Jun 15 19:24:16 -0400 2012: > >> > - Solaris 9 keeps 0.9.8 >> > - Solaris 10 has 1.0.0 >> >> OK, so if this is the case, then we need to upload the dev package >> from 1.0 to the 5.10 catalog. > > This is what I thought was happening. Alright, so we have libssl_dev 1.0.0c in unstable-5.10. This means that we can no longer build just on Solaris 9 and link against openssl, because we need different dependencies in 5.9 and 5.10 catalogs. As time goes but, I wish more and more that we have some sort of GAR recipe validator. In this case, it would check for libssl dependencies, and if any were found, it would suggest expanding PACKAGING_PLATFORMS to Solaris 10. Maciej From maciej at opencsw.org Sat Jun 16 22:39:08 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 16 Jun 2012 21:39:08 +0100 Subject: [csw-maintainers] ld: fatal: relocations remain against allocatable but non-writable sections In-Reply-To: <20120616202630.GE15615@bender.opencsw.org> References: <20120616202630.GE15615@bender.opencsw.org> Message-ID: 2012/6/16 Rafael Ostertag : > On Sat, Jun 16, 2012 at 09:02:55PM +0100, Maciej (Matchek) Blizi??ski wrote: >> When building gcc-4.7.1, I ran against this error: >> >> ld: fatal: relocations remain against allocatable but non-writable sections >> collect2: error: ld returned 1 exit status >> >> It happens when linking the libgnat shared object. It's reproducible, >> try a gcc4 build from the repository and you'll see it. > > SPARC or x86? If x86, 32bit or 64bit? > > My first bet would be a missing -pic Just checked, sparc 32-bit (sparcv8+). From raos at opencsw.org Sat Jun 16 23:55:15 2012 From: raos at opencsw.org (Rafael Ostertag) Date: Sat, 16 Jun 2012 23:55:15 +0200 Subject: [csw-maintainers] ld: fatal: relocations remain against allocatable but non-writable sections In-Reply-To: References: <20120616202630.GE15615@bender.opencsw.org> Message-ID: <20120616215515.GF15615@bender.opencsw.org> Hi Maciej On Sat, Jun 16, 2012 at 09:39:08PM +0100, Maciej (Matchek) Blizi??ski wrote: > 2012/6/16 Rafael Ostertag : > > On Sat, Jun 16, 2012 at 09:02:55PM +0100, Maciej (Matchek) Blizi??ski wrote: > >> When building gcc-4.7.1, I ran against this error: > >> > >> ld: fatal: relocations remain against allocatable but non-writable sections > >> collect2: error: ld returned 1 exit status > >> > >> It happens when linking the libgnat shared object. It's reproducible, > >> try a gcc4 build from the repository and you'll see it. > > > > SPARC or x86? If x86, 32bit or 64bit? > > > > My first bet would be a missing -pic > > Just checked, sparc 32-bit (sparcv8+). Ok, it's still building and I'm tuning out. However, I can show how you reproduce the error, which helps to understand what's wrong: 1. Create a C source file with this content: static int c = 1; int f(int a) { return a+c; } and name it liba.c 2. Create a shared object out of it like this gcc -shared -o liba.so liba.c 3. You will immediately receive Text relocation remains referenced against symbol offset in file c 0x4 /var/tmp//ccqHaWcX.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status So, what's wrong? If you do gcc -fpic -shared -o liba.so liba.c everything works. With the first call to gcc without -fpic, you told the compiler and linker to create a shareable object, but it is not position independent, i.e. during load time the text section (where the code is) will be adjusted. Using -fpic, the text section won't be touched, but code is inserted to get the address of the symbol 'c' during runtime (in depth discussion about this can be found in [1] and [2]). Maybe this shed some light on the issue at hand, and you can fix it. Else I'll be glad to help tomorrow. cheers rafi [1] http://eli.thegreenplace.net/2011/08/25/load-time-relocation-of-shared-libraries/ [2] http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/ > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From pfelecan at opencsw.org Sun Jun 17 09:01:21 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 17 Jun 2012 09:01:21 +0200 Subject: [csw-maintainers] [csw-buildfarm] request to install CSWlibglib2-dev In-Reply-To: <20120616202020.GD15615@bender.opencsw.org> (Rafael Ostertag's message of "Sat, 16 Jun 2012 22:20:20 +0200") References: <1339591245-sup-3313@pinkfloyd.chass.utoronto.ca> <1588A1B7-41F5-4975-9E54-BDAC60C27169@opencsw.org> <24751389-86C5-4722-9F90-ECFE378EFF83@opencsw.org> <20120616202020.GD15615@bender.opencsw.org> Message-ID: Rafael Ostertag writes: >> Yes. A recent glib/gtk2 is almost unbuildable on Solaris 9 as half of the >> testsuite fails (because features are missing). Maybe Rafi can shed some more >> light on it. > > There are some parts that require to be built with -xc99 which is not available > on Sol9. This is the biggest show stopper for glib2 on Sol9. Compiling with gcc is not an option? Just curious... -- Peter From bwalton at opencsw.org Sun Jun 17 17:27:07 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 17 Jun 2012 11:27:07 -0400 Subject: [csw-maintainers] openssl relinking effort In-Reply-To: References: <1339031740-sup-6645@pinkfloyd.chass.utoronto.ca> <1339123346-sup-3285@pinkfloyd.chass.utoronto.ca> <1339155965-sup-1860@pinkfloyd.chass.utoronto.ca> <1339552426-sup-2945@pinkfloyd.chass.utoronto.ca> <20120613174902.GD13695@bender.opencsw.org> <1339635143-sup-2140@pinkfloyd.chass.utoronto.ca> <924B8874-9E01-458B-8614-65649A5AD7CA@opencsw.org> <1339803316-sup-8738@pinkfloyd.chass.utoronto.ca> Message-ID: <1339946754-sup-6690@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Sat Jun 16 16:37:48 -0400 2012: > As time goes but, I wish more and more that we have some sort of GAR > recipe validator. In this case, it would check for libssl > dependencies, and if any were found, it would suggest expanding > PACKAGING_PLATFORMS to Solaris 10. It would be easy enough to add this check directly in GAR, but that would be single purpose and not the type of generic tool you're proposing. What you're talking about would need to be catalog aware so that any library package with differing versions between 9 and 10 would trigger the addition. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sun Jun 17 22:39:33 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 17 Jun 2012 21:39:33 +0100 Subject: [csw-maintainers] =?utf-8?q?MySQL_built_with_GCC_=E2=86=92_mysql?= =?utf-8?q?=5Fconfig_vs_bindings?= Message-ID: I've pushed MySQL 5.5 to unstable and it's now on the buildfarm. It's built with GCC, and mysql_config returns GCC specific flags: $ mysql_config --cflags -I/opt/csw/include/mysql -pipe -m32 -fPIC -g -static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing This has just caused trouble for Juergen when building Nagios plugins. One fix would be to build MySQL 5.5 with Solaris Studio. The latest attempt: "/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.5.x/work/solaris10-sparc/build-isa-sparcv8plus/mysql-5.5.25/libmysqld/../sql/rpl_utility.h", line 274: Warning: extra ";" ignored. "/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.5.x/work/solaris10-sparc/build-isa-sparcv8plus/mysql-5.5.25/libmysqld/../sql/mysqld.cc", line 3255: Error: The function "getpagesizes" must have a prototype. "/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.5.x/work/solaris10-sparc/build-isa-sparcv8plus/mysql-5.5.25/libmysqld/../sql/mysqld.cc", line 3259: Error: The function "getpagesizes" must have a prototype. "/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.5.x/work/solaris10-sparc/build-isa-sparcv8plus/mysql-5.5.25/libmysqld/../sql/mysqld.cc", line 3276: Error: The function "memcntl" must have a prototype. "/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.5.x/work/solaris10-sparc/build-isa-sparcv8plus/mysql-5.5.25/libmysqld/../sql/mysqld.cc", line 3278: Error: The function "memcntl" must have a prototype. 4 Error(s) and 1 Warning(s) detected. I'm thinking what's the best way to go about it. Spend time on porting it to Studio? (It's less and less fun as time goes by.) Patch mysql_config and remove the GCC related flags? Thoughts? Maciej From raos at opencsw.org Mon Jun 18 07:54:29 2012 From: raos at opencsw.org (Rafael Ostertag) Date: Mon, 18 Jun 2012 07:54:29 +0200 Subject: [csw-maintainers] MySQL built with GCC ??? mysql_config vs bindings In-Reply-To: References: Message-ID: <20120618055429.GI15615@bender.opencsw.org> On Sun, Jun 17, 2012 at 09:39:33PM +0100, Maciej (Matchek) Blizi??ski wrote: > I've pushed MySQL 5.5 to unstable and it's now on the buildfarm. It's > built with GCC, and mysql_config returns GCC specific flags: > > $ mysql_config --cflags > -I/opt/csw/include/mysql -pipe -m32 -fPIC -g -static-libgcc > -fno-omit-frame-pointer -fno-strict-aliasing > > This has just caused trouble for Juergen when building Nagios plugins. > > One fix would be to build MySQL 5.5 with Solaris Studio. The latest attempt: > > "/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.5.x/work/solaris10-sparc/build-isa-sparcv8plus/mysql-5.5.25/libmysqld/../sql/rpl_utility.h", > line 274: Warning: extra ";" ignored. > "/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.5.x/work/solaris10-sparc/build-isa-sparcv8plus/mysql-5.5.25/libmysqld/../sql/mysqld.cc", > line 3255: Error: The function "getpagesizes" must have a prototype. > "/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.5.x/work/solaris10-sparc/build-isa-sparcv8plus/mysql-5.5.25/libmysqld/../sql/mysqld.cc", > line 3259: Error: The function "getpagesizes" must have a prototype. > "/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.5.x/work/solaris10-sparc/build-isa-sparcv8plus/mysql-5.5.25/libmysqld/../sql/mysqld.cc", > line 3276: Error: The function "memcntl" must have a prototype. > "/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.5.x/work/solaris10-sparc/build-isa-sparcv8plus/mysql-5.5.25/libmysqld/../sql/mysqld.cc", > line 3278: Error: The function "memcntl" must have a prototype. > 4 Error(s) and 1 Warning(s) detected. > > I'm thinking what's the best way to go about it. Spend time on porting > it to Studio? (It's less and less fun as time goes by.) Patch > mysql_config and remove the GCC related flags? Thoughts? As long as it is only including missing header files, I personally would walk that path. When it reaches the state of patching code, because, e.g. functions are missing or not behaving the way developers expect them to behave, I would give moving away from SunStudio a more thorough thought. cheers rafi From ihsan at opencsw.org Mon Jun 18 10:23:26 2012 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuIERvxJ9hbg==?=) Date: Mon, 18 Jun 2012 10:23:26 +0200 Subject: [csw-maintainers] [csw-buildfarm] libldns1 on the buildfarm In-Reply-To: <393B2E5E-683D-479C-9694-436B173C784C@opencsw.org> References: <4FD50623.4040602@opencsw.org> <9E43AE69-3F3E-4ABD-98AC-ADFD4A47C35D@opencsw.org> <50678B5C-2BA4-415A-A5F0-F6F8D0E11103@opencsw.org> <4FDB6C94.2020309@opencsw.org> <4FDC4602.9050301@opencsw.org> <393B2E5E-683D-479C-9694-436B173C784C@opencsw.org> Message-ID: <4FDEE57E.3050603@opencsw.org> Hi Dago, On 06/16/2012 05:55 PM, Dagobert Michelsen wrote: >> Could you please also update libldns1? > > Done on unstable* > >> BTW, why is the buildfarm so slow these days? > > The rpool became too full. I did some cleanup, but probably I need to relocate some > zones to another pool later on. Please let me know if there are still performance > problems. Thanks for taking care. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From grzemba at contac-dt.de Mon Jun 18 11:27:33 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Mon, 18 Jun 2012 11:27:33 +0200 Subject: [csw-maintainers] freeradius 2.1 Message-ID: <7460886660d2.4fdf10a5@contac-dt.de> Hi, It is possible to push freeradius2.1.12 to unstable? Thanks -- Carsten Grzemba Tel.:?? +49 3677 64740 Mobil: +49 171 9749479 Fax::?? +49 3677 6474111 Email: carsten.grzemba at contac-dt.de contac Datentechnik GmbH -------------- next part -------------- An HTML attachment was scrubbed... URL: From raos at opencsw.org Mon Jun 18 12:29:00 2012 From: raos at opencsw.org (Rafael Ostertag) Date: Mon, 18 Jun 2012 12:29:00 +0200 Subject: [csw-maintainers] ld: fatal: relocations remain against allocatable but non-writable sections In-Reply-To: References: Message-ID: <20120618102900.GJ15615@bender.opencsw.org> Hi Maciej On Sat, Jun 16, 2012 at 09:02:55PM +0100, Maciej (Matchek) Blizi??ski wrote: > When building gcc-4.7.1, I ran against this error: > > ld: fatal: relocations remain against allocatable but non-writable sections > collect2: error: ld returned 1 exit status > > It happens when linking the libgnat shared object. It's reproducible, > try a gcc4 build from the repository and you'll see it. > > I found an old discussion about the problem, and Mike's workaround was > to use the GNU linker. A blog post I found[1] was to add > ???-mimpure-text -lrt??? to LDFLAGS. In case of GCC it's not that easy, > because of nested builds with redefined environments. > > Does anyone have any insight about this problem? I let the build run in script(1) and searched the output for an object file that is causing the error (I took adaint.o). I found no -fPIC anywhere, where adaint.o has been compiled. On the other hand, when they create libgnat-4.7.so, they specify -fPIC. The way I see it, it is a case for the GCC Devs, perhaps it is a bug in the build system... I even did a build today which has explicitely passed `--enable-shared' to configure, to no avail. Same error occurred. Cheers rafi P.S.: The entire output of the build can be found in /home/raos/mgar/gcc4/trunk/typescript From dam at opencsw.org Mon Jun 18 12:35:05 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 18 Jun 2012 12:35:05 +0200 Subject: [csw-maintainers] freeradius 2.1 In-Reply-To: <7460886660d2.4fdf10a5@contac-dt.de> References: <7460886660d2.4fdf10a5@contac-dt.de> Message-ID: <6421973F-5ECC-444E-A691-434545E4B37E@opencsw.org> Hi Carsten, Am 18.06.2012 um 11:27 schrieb Carsten Grzemba: > It is possible to push freeradius2.1.12 to unstable? I hope all known issues have been fixed. The last feedback I was waiting for is https://www.opencsw.org/mantis/view.php?id=4940 but I guess I'll just push it now. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From ja at opencsw.org Mon Jun 18 19:06:34 2012 From: ja at opencsw.org (Juergen Arndt) Date: Mon, 18 Jun 2012 19:06:34 +0200 Subject: [csw-maintainers] =?utf-8?q?MySQL_built_with_GCC_=E2=86=92_mysql?= =?utf-8?q?=5Fconfig_vs_bindings?= In-Reply-To: References: Message-ID: <113DCAD0-9822-4938-993A-1EA6D4039287@opencsw.org> On 17.06.2012, at 22:39, Maciej (Matchek) Blizi?ski wrote: > I've pushed MySQL 5.5 to unstable and it's now on the buildfarm. It's > built with GCC, and mysql_config returns GCC specific flags: > > $ mysql_config --cflags > -I/opt/csw/include/mysql -pipe -m32 -fPIC -g -static-libgcc > -fno-omit-frame-pointer -fno-strict-aliasing > > This has just caused trouble for Juergen when building Nagios plugins. As already shortly discussed with Maciej yesterday, this seems to be a general problem and not only concerning the Nagios plugins. In my opinion a lot of packages which have to be compiled with SunStudio and needs MySQL support will run into these issues. Regards Juergen -- Juergen Arndt From maciej at opencsw.org Mon Jun 18 20:15:30 2012 From: maciej at opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?=) Date: Mon, 18 Jun 2012 19:15:30 +0100 Subject: [csw-maintainers] ld: fatal: relocations remain against allocatable but non-writable sections In-Reply-To: <20120618102900.GJ15615@bender.opencsw.org> References: <20120618102900.GJ15615@bender.opencsw.org> Message-ID: <20120618181530.GA19735@quince.home.blizinski.pl> On Mon, Jun 18, 2012 at 12:29:00PM +0200, Rafael Ostertag wrote: > Hi Maciej > On Sat, Jun 16, 2012 at 09:02:55PM +0100, Maciej (Matchek) Blizi??ski wrote: > > When building gcc-4.7.1, I ran against this error: > > > > ld: fatal: relocations remain against allocatable but non-writable sections > > collect2: error: ld returned 1 exit status > > > > It happens when linking the libgnat shared object. It's reproducible, > > try a gcc4 build from the repository and you'll see it. > > > > I found an old discussion about the problem, and Mike's workaround was > > to use the GNU linker. A blog post I found[1] was to add > > ???-mimpure-text -lrt??? to LDFLAGS. In case of GCC it's not that easy, > > because of nested builds with redefined environments. > > > > Does anyone have any insight about this problem? > > I let the build run in script(1) and searched the output for an object file > that is causing the error (I took adaint.o). > > I found no -fPIC anywhere, where adaint.o has been compiled. On the other hand, > when they create libgnat-4.7.so, they specify -fPIC. The way I see it, it is a > case for the GCC Devs, perhaps it is a bug in the build system... > > I even did a build today which has explicitely passed `--enable-shared' to configure, > to no avail. Same error occurred. Thanks for the research. I sent a question to gcc-help. It's a high traffic list so I try to keep unsubscribed, but in this case I decided to subscribe again. I used your log file, I hope you don't mind. I'm kinda reluctant to dive into the gcc build scripts, because of the multi-level builds, where the top-level Makefile calls multiple configure scripts with different options to build different targets. I mean, you can debug it if you really want, but it takes a long time and you have to keep a lot of state in your head. I'll wait for a response from gcc-help, guys over there have always been helpful (and also think I'm crazy, but that's another issue). Maciej From maciej at opencsw.org Mon Jun 18 20:55:59 2012 From: maciej at opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?=) Date: Mon, 18 Jun 2012 19:55:59 +0100 Subject: [csw-maintainers] =?utf-8?q?MySQL_built_with_GCC_=E2=86=92_mysql?= =?utf-8?q?=5Fconfig_vs_bindings?= In-Reply-To: <113DCAD0-9822-4938-993A-1EA6D4039287@opencsw.org> References: <113DCAD0-9822-4938-993A-1EA6D4039287@opencsw.org> Message-ID: <20120618185559.GB19735@quince.home.blizinski.pl> On Mon, Jun 18, 2012 at 07:06:34PM +0200, Juergen Arndt wrote: > As already shortly discussed with Maciej yesterday, this seems to be > a general problem and not only concerning the Nagios plugins. In my > opinion a lot of packages which have to be compiled with SunStudio and > needs MySQL support will run into these issues. Building MySQL with Studio would resolve these problems. It might be still the least amount of work required to get things back into order. I'm currently saturated with the compilers course at coursera, so don't expect a huge output from me the nearest weeks. If anyone's interested in porting, here are the changes you need to make to pkg/mysql5/branches/mysql-5.5.x/Makefile to get going with Studio: Index: Makefile =================================================================== --- Makefile (revision 18435) +++ Makefile (working copy) @@ -21,6 +21,8 @@ # Useful when making a series of builds on the same day # GARFLAVOR ?= DBG +PACKAGING_PLATFORMS = solaris10-sparc solaris10-i386 + # There is some assembler code, which doesn't work on sparcv8, and I don't see # an easy way to switch it off. ISA_DEFAULT_sparc-5.9 = sparcv8plus @@ -36,9 +38,9 @@ # There are problems with the build using Sun Studio. # GARCOMPILER = SOS12 -# EXTRA_CFLAGS = -mt -D_POSIX_C_SOURCE=199506L -D__EXTENSIONS__ -# EXTRA_CXXFLAGS = -mt -D_POSIX_C_SOURCE=199506L -D__EXTENSIONS__ -GARCOMPILER = GNU +EXTRA_CFLAGS += -mt -D_POSIX_C_SOURCE=199506L -D__EXTENSIONS__ +EXTRA_CXXFLAGS += -mt -D_POSIX_C_SOURCE=199506L -D__EXTENSIONS__ +# GARCOMPILER = GNU INITSMF = $(sysconfdir)/init\.d/csw$(NAME) Maciej From bwalton at opencsw.org Tue Jun 19 01:54:03 2012 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 18 Jun 2012 19:54:03 -0400 Subject: [csw-maintainers] =?utf-8?q?Re:__MySQL_built_with_GCC_=E2=86=92_mysql=96config_vs_bindings?= In-Reply-To: <113DCAD0-9822-4938-993A-1EA6D4039287@opencsw.org> References: <113DCAD0-9822-4938-993A-1EA6D4039287@opencsw.org> Message-ID: <1340063281-sup-9735@pinkfloyd.chass.utoronto.ca> Excerpts from Juergen Arndt's message of Mon Jun 18 13:06:34 -0400 2012: > As already shortly discussed with Maciej yesterday, this seems to be > a general problem and not only concerning the Nagios plugins. In my > opinion a lot of packages which have to be compiled with SunStudio > and needs MySQL support will run into these issues. Anything that is a target of language bindings (pretty much all common libraries) would benefit from a mechanism that allowed building it with either compiler. We'd need a nice way to make this as transparent to the users (maintainers included) to easily pick the right compiler to get the right options returned from the pkg-config tools. A generic pkg-config tool that detected $CC from the environment and forked an appropriate sub-command ($pkg-config.$compiler) to provide the appropriate values would work. It may be required to build things with both compilers though...at least enough to know what the tool would spit out for --libs, --cflags, etc. In some cases this might be guessed and then provided with a simple shell script. Unless we make a hard standardization on one compiler, this problem won't be easily solved, I don't think. What do others think? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From romeotheriault at opencsw.org Tue Jun 19 06:24:11 2012 From: romeotheriault at opencsw.org (Romeo Theriault) Date: Mon, 18 Jun 2012 18:24:11 -1000 Subject: [csw-maintainers] zeromq build failing on i386: Too many open files (signaler.cpp:300) Message-ID: Hi, I'm trying to build zeromq[1]. It builds fine and runs through all it's tests successfully on sparc 9 and 10 but when building on i386, both 9 and 10, it fails on a specific test with a "Too many open files (signaler.cpp:330)" error. Here is the excerpt where it fails: PASS: test_reqrep_inproc PASS: test_reqrep_tcp PASS: test_hwm Too many open files (signaler.cpp:330) /bin/bash: line 5: 15412 Abort (core dumped) ${dir}$tst FAIL: test_shutdown_stress PASS: test_pair_ipc I figured this would be a simple fix, by increasing the file descriptors, which I did by putting the following in my ~/.bash_profile: ulimit -S -n 10000 but the build still fails on the same test during the build. I've verified that if I login to unstable10x (for example) that the ulimit for my user is indeed increased. Odd thing is, is that the file descriptor limits on unstable10x and unstable10s look almost the same.... Has anyone run into a similar issue and found a work-around? Or is this likely more of a problem with the code? Any tips appreciated, Thanks - Romeo [1] Makefile: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/zeromq/trunk/Makefile From maciej at opencsw.org Tue Jun 19 06:42:30 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 19 Jun 2012 05:42:30 +0100 Subject: [csw-maintainers] zeromq build failing on i386: Too many open files (signaler.cpp:300) In-Reply-To: References: Message-ID: 2012/6/19 Romeo Theriault : > Odd thing is, is that the file descriptor limits on unstable10x and > unstable10s look almost the same.... > > Has anyone run into a similar issue and found a work-around? Or is > this likely more of a problem with the code? The first thought I have is: 32-bit vs 64-bit. I remember that 32-bit applications have a lower limit on the number of files open. Page 63 of http://docs.oracle.com/cd/E19253-01/816-5138/816-5138.pdf mentions 256 max streams in 32-bit applications. If you build the amd64 version, what happens? Maciej From raos at opencsw.org Tue Jun 19 07:36:08 2012 From: raos at opencsw.org (Rafael Ostertag) Date: Tue, 19 Jun 2012 07:36:08 +0200 Subject: [csw-maintainers] MySQL built with GCC ??? mysql_config vs bindings In-Reply-To: <20120618185559.GB19735@quince.home.blizinski.pl> References: <113DCAD0-9822-4938-993A-1EA6D4039287@opencsw.org> <20120618185559.GB19735@quince.home.blizinski.pl> Message-ID: <20120619053608.GK15615@bender.opencsw.org> Hi Maciej On Mon, Jun 18, 2012 at 07:55:59PM +0100, Maciej Blizi??ski wrote: > On Mon, Jun 18, 2012 at 07:06:34PM +0200, Juergen Arndt wrote: > > As already shortly discussed with Maciej yesterday, this seems to be > > a general problem and not only concerning the Nagios plugins. In my > > opinion a lot of packages which have to be compiled with SunStudio and > > needs MySQL support will run into these issues. > > Building MySQL with Studio would resolve these problems. It might be > still the least amount of work required to get things back into order. > I'm currently saturated with the compilers course at coursera, so don't > expect a huge output from me the nearest weeks. If anyone's interested > in porting, here are the changes you need to make to > pkg/mysql5/branches/mysql-5.5.x/Makefile to get going with Studio: I'll give it a shot. cheers rafi From maciej at opencsw.org Tue Jun 19 11:12:51 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 19 Jun 2012 10:12:51 +0100 Subject: [csw-maintainers] Building MySQL with Studio Message-ID: I poked it a little. The missing prototype is missing. I think the reason why it's missing is because __EXTENSIONS__ is not set. But it's set! I've configured CMake to display the commands it's running, and yet, it doesn't display the failing command. It looks like there's a subinvocation of make which ignores CFLAGS. The next step will be to identify, what exact invocation is run that produces this error: "/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.5.x/work/solaris10-sparc/build-isa-sparcv8plus/mysql-5.5.25/libmysqld/../sql/mysqld.cc", line 3255: Error: The function "getpagesizes" must have a prototype. Maciej From pfelecan at opencsw.org Tue Jun 19 14:00:34 2012 From: pfelecan at opencsw.org (pfelecan at opencsw.org) Date: Tue, 19 Jun 2012 14:00:34 +0200 (CEST) Subject: [csw-maintainers] need update to pilotlink Message-ID: As I wish to update JPilot package I need an update of a dependency: pilotlink. I filled a report asking for upgrade to no avail; as the other reports are old and not assigned I'm asking if the maintainer is still active and wiling to update his package. TIA From raos at opencsw.org Tue Jun 19 14:13:06 2012 From: raos at opencsw.org (Rafael Ostertag) Date: Tue, 19 Jun 2012 14:13:06 +0200 Subject: [csw-maintainers] Building MySQL with Studio In-Reply-To: References: Message-ID: <20120619121306.GL15615@bender.opencsw.org> Hi Maciej On Tue, Jun 19, 2012 at 10:12:51AM +0100, Maciej (Matchek) Blizi??ski wrote: > I poked it a little. The missing prototype is missing. I think the > reason why it's missing is because __EXTENSIONS__ is not set. > > But it's set! > > I've configured CMake to display the commands it's running, and yet, > it doesn't display the failing command. It looks like there's a > subinvocation of make which ignores CFLAGS. > > The next step will be to identify, what exact invocation is run that > produces this error: > "/home/maciej/src/opencsw/pkg/mysql5/branches/mysql-5.5.x/work/solaris10-sparc/build-isa-sparcv8plus/mysql-5.5.25/libmysqld/../sql/mysqld.cc", > line 3255: Error: The function "getpagesizes" must have a prototype. The passage from /usr/include/sys/mman.h looks like: #if (_POSIX_C_SOURCE > 2) || defined(_XPG4_2) [...] #else /* (_POSIX_C_SOURCE > 2) || defined(_XPG4_2) */ [...] #if !defined(_XOPEN_SOURCE) && !defined(_POSIX_C_SOURCE) || \ defined(__EXTENSIONS__) extern int getpagesizes(size_t *, int); /* <<== That, we want */ [...] #endif /* !defined(_XOPEN_SOURCE) && !defined(_POSIX_C_SOURCE)... */ [...] In the recipe, you specify EXTRA_CFLAGS = -mt -D_POSIX_C_SOURCE=199506L -D__EXTENSIONS__ Hence _POSIX_C_SOURCE > 2, and getpagesizes() will not be declared. Is there any particular reason for defining _POSIX_C_SOURCE? I just built it successfully without _POSIX_C_SOURCE for sparcv8plus on unstable9s. cheers rafi From maciej at opencsw.org Tue Jun 19 14:47:09 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 19 Jun 2012 13:47:09 +0100 Subject: [csw-maintainers] Building MySQL with Studio In-Reply-To: <20120619121306.GL15615@bender.opencsw.org> References: <20120619121306.GL15615@bender.opencsw.org> Message-ID: 2012/6/19 Rafael Ostertag : > Is there any particular reason for defining _POSIX_C_SOURCE? Maybe there was one when building on Solaris 8 or something like that. I removed it and I'm trying the build. > I just built it > successfully without _POSIX_C_SOURCE for sparcv8plus on unstable9s. Very cool. I'll give it a go and if it builds, I'll push it to unstable. From dam at opencsw.org Tue Jun 19 15:01:42 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 19 Jun 2012 15:01:42 +0200 Subject: [csw-maintainers] need update to pilotlink In-Reply-To: References: Message-ID: <8FE048BA-BAC7-4E69-A95E-A6DD65237607@opencsw.org> Hi Peter, Am 19.06.2012 um 14:00 schrieb pfelecan at opencsw.org: > As I wish to update JPilot package I need an update of a dependency: > pilotlink. > > I filled a report asking for upgrade to no avail; as the other reports are > old and not assigned I'm asking if the maintainer is still active and > wiling to update his package. Murray Jensen has no more time to work on the project. I guess you need to rebuild pilotlink yourself, but Murray is willing to help or offer his recipes. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From pfelecan at opencsw.org Tue Jun 19 19:14:14 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 19 Jun 2012 19:14:14 +0200 Subject: [csw-maintainers] =?gb2312?b?TXlTUUwgYnVpbHQgd2l0aCBHQ0MgofogIG15?= =?gb2312?b?c3FsIGNvbmZpZyB2cyBiaW5kaW5ncw==?= In-Reply-To: <1340063281-sup-9735@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Mon, 18 Jun 2012 19:54:03 -0400") References: <113DCAD0-9822-4938-993A-1EA6D4039287@opencsw.org> <1340063281-sup-9735@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > Unless we make a hard standardization on one compiler, this problem > won't be easily solved, I don't think. > > What do others think? For the majority of projects coming from the GNU and associates, using gcc is the best thing that we can do. To simplify thing, all libraries and development tools should be built with gcc; as a side effect we avoid /opt/csw/gxx and other horrors. Using studio can be an option for end user applications, i.e. on which there are no dependencies; of course, for those application written in C++ it becomes mandatory to use gcc. These were my 2 drachmas of evening wisdom -- Peter From pfelecan at opencsw.org Tue Jun 19 19:16:25 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 19 Jun 2012 19:16:25 +0200 Subject: [csw-maintainers] need update to pilotlink In-Reply-To: <8FE048BA-BAC7-4E69-A95E-A6DD65237607@opencsw.org> (Dagobert Michelsen's message of "Tue, 19 Jun 2012 15:01:42 +0200") References: <8FE048BA-BAC7-4E69-A95E-A6DD65237607@opencsw.org> Message-ID: Dagobert Michelsen writes: > Am 19.06.2012 um 14:00 schrieb pfelecan at opencsw.org: >> As I wish to update JPilot package I need an update of a dependency: >> pilotlink. >> >> I filled a report asking for upgrade to no avail; as the other reports are >> old and not assigned I'm asking if the maintainer is still active and >> wiling to update his package. > > Murray Jensen has no more time to work on the project. I guess you need to rebuild > pilotlink yourself, but Murray is willing to help or offer his recipes. Alright then. I'm taking up this package as the sole user, packaging wise. Expect to have a Solaris 10 release soon. -- Peter From romeotheriault at opencsw.org Wed Jun 20 05:02:24 2012 From: romeotheriault at opencsw.org (Romeo Theriault) Date: Tue, 19 Jun 2012 17:02:24 -1000 Subject: [csw-maintainers] zeromq build failing on i386: Too many open files (signaler.cpp:300) In-Reply-To: References: Message-ID: On Mon, Jun 18, 2012 at 6:42 PM, Maciej (Matchek) Blizi?ski wrote: > If you build the amd64 version, what happens? Hi Maciej, thanks for the response. I tried setting BUILD64_LIBS_ONLY = 1 in my Makefile and rebuilding but it still seems to be building the 32bit version, because all the CFLAGS, LDFLAGS are still showing "-m32 -xarch=pentium_pro", etc... during the build process output. I also tried setting: EXTRA_CFLAGS += -xarch=amd64 and it then shows up in the build_process output with "-m32 -xarch=pentium_pro"... but still fails on the test. Is there a better way I should be trying to build this as amd64? Also, assuming it does build as 64bit it seems that all applications that would need to link against it would need to be 64bit as well, right? If that's the case I'm not sure building as 64bit is the best solution. Just thinking aloud here, any education on the topic would be gladly accepted :) Thanks, Romeo From grzemba at contac-dt.de Wed Jun 20 08:01:44 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Wed, 20 Jun 2012 08:01:44 +0200 Subject: [csw-maintainers] zeromq build failing on i386: Too many open files (signaler.cpp:300) In-Reply-To: <7400c3c55913.4fe16734@contac-dt.de> References: <7400c3c55913.4fe16734@contac-dt.de> Message-ID: <740085ac3aa9.4fe18368@contac-dt.de> Am 20.06.12, schrieb Romeo Theriault : > On Mon, Jun 18, 2012 at 6:42 PM, Maciej (Matchek) Blizi?ski > wrote: > > If you build the amd64 version, what happens? > > Hi Maciej, thanks for the response. I tried setting > > > BUILD64_LIBS_ONLY = 1 > This builds only libs 64-bit for other applications, client API etc. see http://sourceforge.net/apps/trac/gar/wiki/GAR%20Variable%20Reference so you need BUILD64 = 1 > > > in my Makefile and rebuilding but it still seems to be building the > 32bit version, because all the CFLAGS, LDFLAGS are still showing "-m32 > -xarch=pentium_pro", etc... during the build process output. > > I also tried setting: > > EXTRA_CFLAGS += -xarch=amd64 > > and it then shows up in the build_process output with "-m32 > -xarch=pentium_pro"... but still fails on the test. > > Is there a better way I should be trying to build this as amd64? > > Also, assuming it does build as 64bit it seems that all applications > that would need to link against it would need to be 64bit as well, > right?? If that's the case I'm not sure building as 64bit is the best > solution. > > Just thinking aloud here, any education on the topic would be gladly accepted :) > > Thanks, > Romeo > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -- Carsten Grzemba -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Wed Jun 20 09:06:26 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 20 Jun 2012 09:06:26 +0200 Subject: [csw-maintainers] zeromq build failing on i386: Too many open files (signaler.cpp:300) In-Reply-To: <740085ac3aa9.4fe18368@contac-dt.de> References: <7400c3c55913.4fe16734@contac-dt.de> <740085ac3aa9.4fe18368@contac-dt.de> Message-ID: <2E567B0F-9528-46DF-9DDC-DF49F698D3FA@opencsw.org> Hi, Am 20.06.2012 um 08:01 schrieb Carsten Grzemba: > Am 20.06.12, schrieb Romeo Theriault : >> On Mon, Jun 18, 2012 at 6:42 PM, Maciej (Matchek) Blizi?ski >> wrote: >> > If you build the amd64 version, what happens? >> >> Hi Maciej, thanks for the response. I tried setting >> BUILD64_LIBS_ONLY = 1 > > This builds only libs 64-bit for other applications, client API etc. > > see http://sourceforge.net/apps/trac/gar/wiki/GAR%20Variable%20Reference > so you need > > BUILD64 = 1 The variable reference lacked a description of BUILD64_ONLY = 1 which means to build only the 64 bit version. I guess this is what you need to verify the assumption on 64 bit. >> in my Makefile and rebuilding but it still seems to be building the >> 32bit version, because all the CFLAGS, LDFLAGS are still showing "-m32 >> -xarch=pentium_pro", etc... during the build process output. You can see what flags are passed by using mgar modenv >> I also tried setting: >> >> EXTRA_CFLAGS += -xarch=amd64 Setting flags about optimization, ISA, memorymodel manually in CFLAGS is extremely dangerous as it interferes with the flags GAR sets for you. If you want to make changes please override/adjust the respective compile-specific variables: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/gar.conf.mk#L224 Usually this means selecting the correct ISA and then adding things as necessary. >> Also, assuming it does build as 64bit it seems that all applications >> that would need to link against it would need to be 64bit as well, >> right? Right. To go back to your initial problem: Does the increased filehandles make it to the process? Please inspect with plimit or gcore/mdb. If yes you need investigate why it still fails, if no you need to investigate why it is not passed correctly. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Wed Jun 20 10:36:45 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 20 Jun 2012 10:36:45 +0200 Subject: [csw-maintainers] OpenSSL project task order Message-ID: <5A063A52-E8A1-4044-AD95-0FF0B096AC31@opencsw.org> Hi Yann, you carefully splitted the tasks into different groups in http://wiki.opencsw.org/project-openssl Which order would you recommend? Can I talk you into taking the stab at project lead and ask people to do specific things? What should I do first from that list? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From wilbury at opencsw.org Wed Jun 20 10:40:19 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Wed, 20 Jun 2012 10:40:19 +0200 Subject: [csw-maintainers] OpenSSL project task order In-Reply-To: <5A063A52-E8A1-4044-AD95-0FF0B096AC31@opencsw.org> References: <5A063A52-E8A1-4044-AD95-0FF0B096AC31@opencsw.org> Message-ID: <4FE18C73.3080602@opencsw.org> On 06/20/2012 10:36 AM, Dagobert Michelsen wrote: > Hi Yann, > > you carefully splitted the tasks into different groups in > http://wiki.opencsw.org/project-openssl > > Which order would you recommend? Can I talk you into taking the stab at project > lead and ask people to do specific things? What should I do first from that list? I can have a look at Courier IMAP as I will need updated version very soon :-) -- Juraj Lutter From yann at pleiades.fr.eu.org Wed Jun 20 11:43:07 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Wed, 20 Jun 2012 11:43:07 +0200 Subject: [csw-maintainers] OpenSSL project task order In-Reply-To: <5A063A52-E8A1-4044-AD95-0FF0B096AC31@opencsw.org> References: <5A063A52-E8A1-4044-AD95-0FF0B096AC31@opencsw.org> Message-ID: Hi Dago, 2012/6/20 Dagobert Michelsen > Hi Yann, > > you carefully splitted the tasks into different groups in > http://wiki.opencsw.org/project-openssl > > Which order would you recommend? There are no order to follow between groups, they are independant. There are no order inside groups, they just must be released together (except if one program refuse to compile because one of its dependancy is still linked with openssl 0.9.8, I am not aware if that can happens). For exemple, you can't release gnomesysmon and courier_imap separately, because gnomesysmon is linked several times with openssl at runtime: directly and indirectly by the way of a dependancy on libldap2_4_2. So you need to recompile both gnomesysmon and libldap2_4_2 at the same time to avoid a runtime linking with both version. But as courier_imap is also directly linked with openssl and indirectly linked through libldap2_4_2, you also need to recompile courier_imap at the same time to avoid to create a new dual runtime linking situation with courier_imap. As said before, it would be helpful to know when the dual runtime linking is really a problem, this would maybe help to significantly simplify the coordination work. Does someone know what happens exactly when a program is linked with two different libraries at runtime by the way of one of its dependancy ? > Can I talk you into taking the stab at project > lead and ask people to do specific things? Yes, I intented to do it but I will not be able to do it until next week. The fact that some maintainers are retired will make things complicated. I've some seen mails about stopping to support desktop apps. Is there some consensus about this ? That would remove a lot of unmaintained packages from group 1. Some of these packages may even not lack a GAR recipe, don't they ? (BTW, I am not sure we should even keep packages that are not maintained anymore. At best, it may be a good idea to move them to a separate catalog) > What should I do first from that list? > I would recommend to first work on group 1 because this is the biggest group and one missing updated package prevents all the other to be updated. Yann > > > Best regards > > -- Dago > > -- > "You don't become great by trying to be great, you become great by wanting > to do something, > and then doing it so hard that you become great in the process." - xkcd > #896 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Wed Jun 20 12:14:02 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 20 Jun 2012 12:14:02 +0200 Subject: [csw-maintainers] OpenSSL project task order In-Reply-To: References: <5A063A52-E8A1-4044-AD95-0FF0B096AC31@opencsw.org> Message-ID: Hi Yann, Am 20.06.2012 um 11:43 schrieb Yann Rouillard: > 2012/6/20 Dagobert Michelsen >> you carefully splitted the tasks into different groups in >> http://wiki.opencsw.org/project-openssl >> >> Which order would you recommend? > > There are no order to follow between groups, they are independant. > There are no order inside groups, they just must be released together (except if one program refuse to compile because one of its dependancy is still linked with openssl 0.9.8, I am not aware if that can happens). > > For exemple, you can't release gnomesysmon and courier_imap separately, because gnomesysmon is linked several times with openssl at runtime: directly and indirectly by the way of a dependancy on libldap2_4_2. > > So you need to recompile both gnomesysmon and libldap2_4_2 at the same time to avoid a runtime linking with both version. > > But as courier_imap is also directly linked with openssl and indirectly linked through libldap2_4_2, you also need to recompile courier_imap at the same time to avoid to create a new dual runtime linking situation with courier_imap. > > As said before, it would be helpful to know when the dual runtime linking is really a problem, this would maybe help to significantly simplify the coordination work. > > Does someone know what happens exactly when a program is linked with two different libraries at runtime by the way of one of its dependancy ? The worst thing would be having two sets of global variables saving state for the different versions. >> Can I talk you into taking the stab at project >> lead and ask people to do specific things? > > Yes, I intented to do it but I will not be able to do it until next week. Cool, NP. > The fact that some maintainers are retired will make things complicated. I've some seen mails about stopping to support desktop apps. Is there some consensus about this ? That would remove a lot of unmaintained packages from group 1. If it is a problem and nobody is willing to take it over they will be dropped. > Some of these packages may even not lack a GAR recipe, don't they ? Most certainly the orphaned ones do not have a GAR recipe. > (BTW, I am not sure we should even keep packages that are not maintained anymore. At best, it may be a good idea to move them to a separate catalog) This is exactly what we have planned for the "Kiel"-release: http://wiki.opencsw.org/package-tiering http://wiki.opencsw.org/release-kiel >> What should I do first from that list? > > I would recommend to first work on group 1 because this is the biggest group and one missing updated package prevents all the other to be updated. Ok. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Wed Jun 20 13:00:01 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 20 Jun 2012 13:00:01 +0200 Subject: [csw-maintainers] OpenSSL project task order In-Reply-To: References: <5A063A52-E8A1-4044-AD95-0FF0B096AC31@opencsw.org> Message-ID: Hi Yann, Am 20.06.2012 um 12:14 schrieb Dagobert Michelsen: > Am 20.06.2012 um 11:43 schrieb Yann Rouillard: >> The fact that some maintainers are retired will make things complicated. I've some seen mails about stopping to support desktop apps. Is there some consensus about this ? That would remove a lot of unmaintained packages from group 1. > > If it is a problem and nobody is willing to take it over they will be dropped. I have made group-specific directories in /home/experimental: openssl-relinking-group1 openssl-relinking-group2 openssl-relinking-group3 openssl-relinking-group4 openssl-relinking-group5 Please everyone drop the package in the respective directory so they can easily be released together. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From pfelecan at opencsw.org Wed Jun 20 14:12:57 2012 From: pfelecan at opencsw.org (pfelecan at opencsw.org) Date: Wed, 20 Jun 2012 14:12:57 +0200 (CEST) Subject: [csw-maintainers] request to review ps2eps recipe Message-ID: I have a strange issue with the license definition for this recipe: - the WORKSRC must be redefined as the extracted source tree doesn't have a canonical name - the LICENSE is defined as LICENSE.txt which is in the source tree root However, the process ends with the following message: *** Cannot find license file for package CSWps2eps Tried to debug but to no avail... If someone can review the recipe and hopefully find the root cause of the issue. TIA From dam at opencsw.org Wed Jun 20 14:24:02 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 20 Jun 2012 14:24:02 +0200 Subject: [csw-maintainers] request to review ps2eps recipe In-Reply-To: References: Message-ID: Hi Peter, Am 20.06.2012 um 14:12 schrieb pfelecan at opencsw.org: > I have a strange issue with the license definition for this recipe: > > - the WORKSRC must be redefined as the extracted source tree doesn't have > a canonical name Please don't change WORKSRC, but adjust DISTNAME. > - the LICENSE is defined as LICENSE.txt which is in the source tree root LICENSE is relative to WORKSRC, so if you change WORKSRC you need to change LICENSE (and other variables) also, so best is to leave WORKSRC as it and just fix DISTNAME. > However, the process ends with the following message: > > *** Cannot find license file for package CSWps2eps > > Tried to debug but to no avail... If someone can review the recipe and > hopefully find the root cause of the issue. Done and commited. The docs location should contain the catalog name. I have adjusted this in http://sourceforge.net/apps/trac/gar/changeset/18470 Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From bwalton at opencsw.org Wed Jun 20 15:42:57 2012 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 20 Jun 2012 09:42:57 -0400 Subject: [csw-maintainers] OpenSSL project task order In-Reply-To: References: <5A063A52-E8A1-4044-AD95-0FF0B096AC31@opencsw.org> Message-ID: <1340199645-sup-433@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Jun 20 07:00:01 -0400 2012: Hi Dago, > openssl-relinking-group5 I've just been pushing anything from this group directly to unstable. There are no inter-dependencies among this set. I'll move the other things I've re-rolled around tonight. My current openssl project is gdal/libgdal which is part of group 1. I can do a re-roll with c++ but got hung up trying to make it build with studio so that I could test a patch I submitted. Several additional patches later, I'm stuck with a c99/stdbool.h vs c++ issue. I'll detail that in another email later to see if someone can help me over that hurdle. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Wed Jun 20 16:44:19 2012 From: pfelecan at opencsw.org (pfelecan at opencsw.org) Date: Wed, 20 Jun 2012 16:44:19 +0200 (CEST) Subject: [csw-maintainers] request to review pilotlink recipe Message-ID: Well, I'm stuck in the patching of sources... I'm following the usual process of patching: - mgar clean - mgar extract - changing the files in the source tree - addint the new patch to the PATCHFILE macro - mgar makepatch - mgar makesums - mgar spotless patch But the patch is never applied. What I'm doing wrong ? TIA From dam at opencsw.org Wed Jun 20 16:45:34 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 20 Jun 2012 16:45:34 +0200 Subject: [csw-maintainers] request to review pilotlink recipe In-Reply-To: References: Message-ID: <214902D3-96DB-48EF-ADFE-1D8AA421FA70@opencsw.org> Hi Peter, Am 20.06.2012 um 16:44 schrieb pfelecan at opencsw.org: > Well, I'm stuck in the patching of sources... > > I'm following the usual process of patching: > - mgar clean > - mgar extract > - changing the files in the source tree > - addint the new patch to the PATCHFILE macro > - mgar makepatch > - mgar makesums > - mgar spotless patch > > But the patch is never applied. > > What I'm doing wrong ? Because it is called PATCHFILES ? If my guess is wrong please commit and post the repo path. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From bwalton at opencsw.org Wed Jun 20 16:48:24 2012 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 20 Jun 2012 10:48:24 -0400 Subject: [csw-maintainers] request to review pilotlink recipe In-Reply-To: References: Message-ID: <1340203616-sup-4461@pinkfloyd.chass.utoronto.ca> Excerpts from pfelecan's message of Wed Jun 20 10:44:19 -0400 2012: Hi Peter, > I'm following the usual process of patching: > - mgar clean > - mgar extract Do mgar patch here instead. You should create new patches only after existing patches are applied. > - changing the files in the source tree > - addint the new patch to the PATCHFILE macro > - mgar makepatch Reverse these two steps > - mgar makesums > - mgar spotless patch This should work then. Let me know if it's not. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Wed Jun 20 19:17:14 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 20 Jun 2012 19:17:14 +0200 Subject: [csw-maintainers] Problem inserting into unstable 5.11 i386 because libXaw.so.5 is missing References: <8A10A753-68D1-431B-AA57-DCB69D36A405@baltic-online.de> Message-ID: <40502028-D0E4-494C-8629-0DBD14BBD67C@opencsw.org> Hi, I just wanted to upload the latest x3270 and received an error on upload for 5.11 i386: > dam at login [login]:/home/dam/staging/build-20.Jun.2012 > csw-upload-pkg x3270-3.3.12ga7,REV=2012.06.20-SunOS5.10-* > Processing 2 file(s). Please wait. > Uploading 'x3270-3.3.12ga7,REV=2012.06.20-SunOS5.10-i386-CSW.pkg.gz' > Uploading 'x3270-3.3.12ga7,REV=2012.06.20-SunOS5.10-sparc-CSW.pkg.gz' > Checking 1 package(s) against catalog unstable i386 SunOS5.10 > Checking 1 package(s) against catalog unstable sparc SunOS5.10 > Checking 1 package(s) against catalog unstable i386 SunOS5.11 > Checking 1 package(s) against catalog unstable sparc SunOS5.11 > Checks failed for catalogs: > - i386 SunOS5.11 > x3270-3.3.12ga7,REV=2012.06.20-SunOS5.10-i386-CSW.pkg.gz > To see errors, run: > /home/dam/bin/checkpkg --catalog-release unstable --os-release SunOS5.11 --architecture i386 7e15f57688ff5e36b95c65e25315adca > Packages have not been submitted to the unstable catalog. > dam at login [login]:/home/dam/staging/build-20.Jun.2012 > /home/dam/bin/checkpkg --catalog-release unstable --os-release SunOS5.11 --architecture i386 7e15f57688ff5e36b95c65e25315adca > INFO:root:Unwrapping candies... > 100% |########################################################################################################################################################################################################| > INFO:root:Tasting candies one by one... > 100% |########################################################################################################################################################################################################| > INFO:root:Tasting them all at once... > INFO:root:Stuffing the candies under the pillow... > 100% |########################################################################################################################################################################################################| > CSWx3270: > * File root/opt/csw/share/doc/x3270/pr3287/README contains bad content: > '/usr/local'. If it's a legacy file you can't modify, or if you > investigated the issue and the string does not pose a real issue, you can > override this error. > * File root/opt/csw/share/doc/x3270/pr3287/html/Build.html contains bad > content: '/usr/local'. If it's a legacy file you can't modify, or if you > investigated the issue and the string does not pose a real issue, you can > override this error. > * File root/opt/csw/share/doc/x3270/c3270/html/Build.html contains bad > content: '/usr/local'. If it's a legacy file you can't modify, or if you > investigated the issue and the string does not pose a real issue, you can > override this error. > * File root/opt/csw/share/doc/x3270/c3270/html/Resources.html contains bad > content: '/usr/local'. If it's a legacy file you can't modify, or if you > investigated the issue and the string does not pose a real issue, you can > override this error. > * File root/opt/csw/share/doc/x3270/c3270/html/c3270-man.html contains bad > content: '/usr/local'. If it's a legacy file you can't modify, or if you > investigated the issue and the string does not pose a real issue, you can > override this error. > * File root/opt/csw/share/doc/x3270/x3270/html/FAQ.html contains bad content: > '/usr/local'. If it's a legacy file you can't modify, or if you > investigated the issue and the string does not pose a real issue, you can > override this error. > * File root/opt/csw/share/doc/x3270/x3270/html/Build.html contains bad > content: '/usr/local'. If it's a legacy file you can't modify, or if you > investigated the issue and the string does not pose a real issue, you can > override this error. > * File root/opt/csw/share/doc/x3270/x3270/html/Resources.html contains bad > content: '/usr/local'. If it's a legacy file you can't modify, or if you > investigated the issue and the string does not pose a real issue, you can > override this error. > * File root/opt/csw/share/doc/x3270/tcl3270/html/Resources.html contains bad > content: '/usr/local'. If it's a legacy file you can't modify, or if you > investigated the issue and the string does not pose a real issue, you can > override this error. > * File root/opt/csw/share/doc/x3270/tcl3270/html/Build.html contains bad > content: '/usr/local'. If it's a legacy file you can't modify, or if you > investigated the issue and the string does not pose a real issue, you can > override this error. > * File root/opt/csw/share/doc/x3270/s3270/html/Resources.html contains bad > content: '/usr/local'. If it's a legacy file you can't modify, or if you > investigated the issue and the string does not pose a real issue, you can > override this error. > * File root/opt/csw/share/doc/x3270/s3270/html/s3270-man.html contains bad > content: '/usr/local'. If it's a legacy file you can't modify, or if you > investigated the issue and the string does not pose a real issue, you can > override this error. > * File root/opt/csw/share/doc/x3270/s3270/html/Build.html contains bad > content: '/usr/local'. If it's a legacy file you can't modify, or if you > investigated the issue and the string does not pose a real issue, you can > override this error. > * File root/opt/csw/share/man/man1/c3270.1 contains bad content: > '/usr/local'. If it's a legacy file you can't modify, or if you > investigated the issue and the string does not pose a real issue, you can > override this error. > * File root/opt/csw/share/man/man1/s3270.1 contains bad content: > '/usr/local'. If it's a legacy file you can't modify, or if you > investigated the issue and the string does not pose a real issue, you can > override this error. > * libXaw.so.5 could not be resolved for opt/csw/bin/x3270, with rpath > ('/opt/csw/lib/$ISALIST', '/opt/csw/lib', '/usr/lib/$ISALIST', '/usr/lib', > '/lib/$ISALIST', '/lib'), expanded to ['/opt/csw/lib', > '/opt/csw/lib/amd64', '/opt/csw/lib/pentium+mmx', '/opt/csw/lib/pentium', > '/opt/csw/lib/i486', '/opt/csw/lib/i386', '/opt/csw/lib/pentium_pro', > '/opt/csw/lib/i86', '/opt/csw/lib/pentium_pro+mmx', '/opt/csw/lib', > '/usr/lib', '/usr/lib/amd64', '/usr/lib/pentium+mmx', '/usr/lib/pentium', > '/usr/lib/i486', '/usr/lib/i386', '/usr/lib/pentium_pro', '/usr/lib/i86', > '/usr/lib/pentium_pro+mmx', '/usr/lib', '/lib', '/lib/amd64', > '/lib/pentium+mmx', '/lib/pentium', '/lib/i486', '/lib/i386', > '/lib/pentium_pro', '/lib/i86', '/lib/pentium_pro+mmx', '/lib'], while the > file was not present on the filesystem, nor in the packages under > examination. > If any of the reported errors were false positives, you can override them > pasting the lines below to the GAR recipe. > CHECKPKG_OVERRIDES_CSWx3270 += soname-not-found|libXaw.so.5|is|needed|by|opt/csw/bin/x3270 > Please note that checkpkg isn't suggesting you should simply add these overrides > to the Makefile. It only informs what the overrides could look like. You need > to understand what are the reported issues about and use your best judgement to > decide whether to fix the underlying problems or override them. For more > information, scroll up and read the detailed messages. To easily inspect > packages you've just built, visit: http://buildfarm.opencsw.org/pkgdb/srv4/ > zsh: 23558 exit 1 /home/dam/bin/checkpkg --catalog-release unstable --os-release SunOS5.11 i38 Maciej, do you have an idea why this is missing? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Wed Jun 20 19:19:26 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 20 Jun 2012 18:19:26 +0100 Subject: [csw-maintainers] Problem inserting into unstable 5.11 i386 because libXaw.so.5 is missing In-Reply-To: <40502028-D0E4-494C-8629-0DBD14BBD67C@opencsw.org> References: <8A10A753-68D1-431B-AA57-DCB69D36A405@baltic-online.de> <40502028-D0E4-494C-8629-0DBD14BBD67C@opencsw.org> Message-ID: 2012/6/20 Dagobert Michelsen > Maciej, do you have an idea why this is missing? I don't know... Oracle didn't put it there? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Wed Jun 20 19:22:45 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 20 Jun 2012 19:22:45 +0200 Subject: [csw-maintainers] Problem inserting into unstable 5.11 i386 because libXaw.so.5 is missing In-Reply-To: References: <8A10A753-68D1-431B-AA57-DCB69D36A405@baltic-online.de> <40502028-D0E4-494C-8629-0DBD14BBD67C@opencsw.org> Message-ID: Hi Maciej, Am 20.06.2012 um 19:19 schrieb Maciej (Matchek) Blizi?ski: > 2012/6/20 Dagobert Michelsen > Maciej, do you have an idea why this is missing? > > I don't know... Oracle didn't put it there? It is in pkg:/x11/library/toolkit/libxaw5 which was not installed on unstable11x. I did this now, how can I reregister the packages from IPS? BTW, shouldn't the file list come from the IPS repo instead of the installed things? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfelecan at opencsw.org Wed Jun 20 19:41:47 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 20 Jun 2012 19:41:47 +0200 Subject: [csw-maintainers] request to review ps2eps recipe In-Reply-To: (Dagobert Michelsen's message of "Wed, 20 Jun 2012 14:24:02 +0200") References: Message-ID: Dagobert Michelsen writes: >> Tried to debug but to no avail... If someone can review the recipe and >> hopefully find the root cause of the issue. > > Done and commited. Thank you for the correction and useful information. -- Peter From maciej at opencsw.org Wed Jun 20 19:41:58 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 20 Jun 2012 18:41:58 +0100 Subject: [csw-maintainers] Problem inserting into unstable 5.11 i386 because libXaw.so.5 is missing In-Reply-To: References: <8A10A753-68D1-431B-AA57-DCB69D36A405@baltic-online.de> <40502028-D0E4-494C-8629-0DBD14BBD67C@opencsw.org> Message-ID: 2012/6/20 Dagobert Michelsen > It is in?pkg:/x11/library/toolkit/libxaw5 which was not installed on unstable11x. > I did this now, how can I reregister the packages from IPS? Following the documented procedure for registering system files will be enough. > BTW, shouldn't the file list come from the IPS repo instead of the installed things? According to the implementation, no. ;-) From romeotheriault at opencsw.org Thu Jun 21 01:11:04 2012 From: romeotheriault at opencsw.org (Romeo Theriault) Date: Wed, 20 Jun 2012 13:11:04 -1000 Subject: [csw-maintainers] zeromq build failing on i386: Too many open files (signaler.cpp:300) In-Reply-To: <2E567B0F-9528-46DF-9DDC-DF49F698D3FA@opencsw.org> References: <7400c3c55913.4fe16734@contac-dt.de> <740085ac3aa9.4fe18368@contac-dt.de> <2E567B0F-9528-46DF-9DDC-DF49F698D3FA@opencsw.org> Message-ID: On Tue, Jun 19, 2012 at 9:06 PM, Dagobert Michelsen wrote: >> >> This builds only libs 64-bit for other applications, client API etc. >> >> see http://sourceforge.net/apps/trac/gar/wiki/GAR%20Variable%20Reference >> so you need >> >> BUILD64 = 1 > > The variable reference lacked a description of > ?BUILD64_ONLY = 1 > which means to build only the 64 bit version. I guess this is what you need to > verify the assumption on 64 bit. Thanks Carsten and Dago, with the BUILD64_ONLY = 1 I was able to it to build just on 64 and the same test still failed, so it's not a 32bit vs 64bit dependent thing... > You can see what flags are passed by using > ?mgar modenv Nice, thanks for the info. This is good to know. > Setting flags about optimization, ISA, memorymodel manually in CFLAGS is extremely > dangerous as it interferes with the flags GAR sets for you. If you want to make > changes please override/adjust the respective compile-specific variables: > ?http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/gar.conf.mk#L224 > Usually this means selecting the correct ISA and then adding things as necessary. Ok. >>> Also, assuming it does build as 64bit it seems that all applications >>> that would need to link against it would need to be 64bit as well, >>> right? > > Right. Thanks for the verification. > To go back to your initial problem: Does the increased filehandles make it to the process? Bingo, it seems not! When I run the test manually (after up'ing the filehandles) it returns without error, doesn't core and a returns a return code of 0. Then when I bring the filehandles back down to 256 and run the test again it cores and errors out as it does during the build run tests. Now to figure out why the ulimit settings in my .bash_profile don't affect it when going through the build process. Does the build process use 'sh' I wonder... Will report back when I've found the culprit. Thanks for the very useful info. Romeo From romeotheriault at opencsw.org Thu Jun 21 01:41:39 2012 From: romeotheriault at opencsw.org (Romeo Theriault) Date: Wed, 20 Jun 2012 13:41:39 -1000 Subject: [csw-maintainers] zeromq build failing on i386: Too many open files (signaler.cpp:300) In-Reply-To: References: <7400c3c55913.4fe16734@contac-dt.de> <740085ac3aa9.4fe18368@contac-dt.de> <2E567B0F-9528-46DF-9DDC-DF49F698D3FA@opencsw.org> Message-ID: On Wed, Jun 20, 2012 at 1:11 PM, Romeo Theriault wrote: >> To go back to your initial problem: Does the increased filehandles make it to the process? > > Bingo, it seems not! When I run the test manually (after up'ing the > filehandles) it returns without error, doesn't core and a returns a > return code of 0. Then when I bring the filehandles back down to 256 > and run the test again it cores and errors out as it does during the > build run tests. Now to figure out why the ulimit settings in my > .bash_profile don't affect it when going through the build process. > Does the build process use 'sh' I wonder... > > Will report back when I've found the culprit. Thanks for the very useful info. Got it. It seems the build runs as a non-interactive shell, thus the ~/.profile or ~/.bash_profile were not getting sourced. I added the following to the Makefile to get the ~/.bash_profile sourced. EXTRA_TEST_ENV += BASH_ENV=~/.bash_profile Rebuilt and it worked like a charm. Thanks for all the help folks, Romeo From dam at opencsw.org Thu Jun 21 08:12:49 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 21 Jun 2012 08:12:49 +0200 Subject: [csw-maintainers] zeromq build failing on i386: Too many open files (signaler.cpp:300) In-Reply-To: References: <7400c3c55913.4fe16734@contac-dt.de> <740085ac3aa9.4fe18368@contac-dt.de> <2E567B0F-9528-46DF-9DDC-DF49F698D3FA@opencsw.org> Message-ID: <6F0F4781-FC1C-4EDE-8273-BD38D1E5289A@opencsw.org> Hi Romeo, Am 21.06.2012 um 01:41 schrieb Romeo Theriault: > Got it. It seems the build runs as a non-interactive shell, thus the > ~/.profile or ~/.bash_profile were not getting sourced. I added the > following to the Makefile to get the ~/.bash_profile sourced. > > EXTRA_TEST_ENV += BASH_ENV=~/.bash_profile > > Rebuilt and it worked like a charm. Does this mean the build depends on your home directory? That would be bad. I suggest using file/bash_profile DISTFILES += bash_profile BASH_ENV=$(WORKSRC)/bash_profile to make the recipe portable. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From grzemba at contac-dt.de Thu Jun 21 08:32:46 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Thu, 21 Jun 2012 08:32:46 +0200 Subject: [csw-maintainers] openssl-group1 gnome stuff Message-ID: <7400d6d46930.4fe2dc2e@contac-dt.de> I think we can remove the gnome stuff listed in openssl-group1, except of gthumb? Ken Mays ( Retired ) fileroller(http://www.opencsw.org/p/fileroller) gnomedesktop(http://www.opencsw.org/p/gnomedesktop) gnomekeyringmgr(http://www.opencsw.org/p/gnomekeyringmgr) gnome_session(http://www.opencsw.org/p/gnome_session) gnomesysmon(http://www.opencsw.org/p/gnomesysmon) gnome_terminal(http://www.opencsw.org/p/gnome_terminal) gthumb(http://www.opencsw.org/p/gthumb) libgnomecups(http://www.opencsw.org/p/libgnomecups) libgnomeprint(http://www.opencsw.org/p/libgnomeprint) nautilus(http://www.opencsw.org/p/nautilus) What think the others? -- Carsten Grzemba Tel.:?? +49 3677 64740 Mobil: +49 171 9749479 Fax::?? +49 3677 6474111 Email: carsten.grzemba at contac-dt.de contac Datentechnik GmbH -------------- next part -------------- An HTML attachment was scrubbed... URL: From romeotheriault at opencsw.org Thu Jun 21 08:45:46 2012 From: romeotheriault at opencsw.org (Romeo Theriault) Date: Wed, 20 Jun 2012 20:45:46 -1000 Subject: [csw-maintainers] zeromq build failing on i386: Too many open files (signaler.cpp:300) In-Reply-To: <6F0F4781-FC1C-4EDE-8273-BD38D1E5289A@opencsw.org> References: <7400c3c55913.4fe16734@contac-dt.de> <740085ac3aa9.4fe18368@contac-dt.de> <2E567B0F-9528-46DF-9DDC-DF49F698D3FA@opencsw.org> <6F0F4781-FC1C-4EDE-8273-BD38D1E5289A@opencsw.org> Message-ID: On Wed, Jun 20, 2012 at 8:12 PM, Dagobert Michelsen wrote: > Does this mean the build depends on your home directory? That would be bad. > I suggest using > ?file/bash_profile > ?DISTFILES += bash_profile > ?BASH_ENV=$(WORKSRC)/bash_profile > to make the recipe portable. Ahh, good idea. Thank you. From grzemba at contac-dt.de Thu Jun 21 10:28:07 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Thu, 21 Jun 2012 10:28:07 +0200 Subject: [csw-maintainers] Fwd: svn-1.7.5 builds was: svn ingores DESTDIR, was: link error with 1.7.3 In-Reply-To: <7460907172c5.4fe2db01@contac-dt.de> References: <7460907172c5.4fe2db01@contac-dt.de> Message-ID: <7460e76b1a58.4fe2f737@contac-dt.de> Hi Macjei, ? Am 28.05.12, schrieb Maciej (Matchek) Blizi?ski : > > Yet another call to programmers: Would anyone care for writing a check > that would be run against our catalog and report any found problems to > e.g. the devel@ mailing list? For example, something that builds on > Carsten's missing libraries heuristics script: > https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/v2/lib/python/find_missing_bins.py > Arming this script with pluggable checks and email output would get > the job done. > > is this request still valid? Can you give me more information? I think I can help you. > > > Maciej > -- > > Carsten Grzemba -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Thu Jun 21 11:47:36 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 21 Jun 2012 10:47:36 +0100 Subject: [csw-maintainers] Fwd: svn-1.7.5 builds was: svn ingores DESTDIR, was: link error with 1.7.3 In-Reply-To: <7460e76b1a58.4fe2f737@contac-dt.de> References: <7460907172c5.4fe2db01@contac-dt.de> <7460e76b1a58.4fe2f737@contac-dt.de> Message-ID: 2012/6/21 Carsten Grzemba : > Yet another call to programmers: Would anyone care for writing a check > that would be run against our catalog and report any found problems to > e.g. the devel@ mailing list? For example, something that builds on > Carsten's missing libraries heuristics script: > https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/v2/lib/python/find_missing_bins.py > Arming this script with pluggable checks and email output would get > the job done. > > > is this request still valid? Can you give me more information? I think I can > help you. Yup. We currently have no alerting / notification framework, and problems with catalog go unnoticed until they start cascading. There was some difference of opinion, where some people argued that checks should be done synchronously when modifying the catalog (so that you don't get into the bad state), and I argued that checks should be done asynchronously (so that they don't slow you down on every single operation). Either case is possible to implement, and I think that the async is easier. The reason it's easier is that you don't have to simulate ?what the state of the catalog would be if X was done?, you just check the current state. That was about checking. Another issue is alerting / notification. I haven't researched the open source space for this but I'm sure there is some project that deals with this, so you can e.g. write a check, and when it fails, a notification is sent, and you can control how often the notification will be repeated if the check keeps on failing. It could be something like Hyperic or Zabbix or Zenoss, or something like that. In this case we would care only about our own checks for things like dependency graph cycles, missing dependencies and other potential problems. Maciej From maciej at opencsw.org Thu Jun 21 12:02:12 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 21 Jun 2012 11:02:12 +0100 Subject: [csw-maintainers] openssl-group1 gnome stuff In-Reply-To: <7400d6d46930.4fe2dc2e@contac-dt.de> References: <7400d6d46930.4fe2dc2e@contac-dt.de> Message-ID: 2012/6/21 Carsten Grzemba : > What think the others? I agree that we might not need these any more, the consensus is that the modern OpenSolaris derivatives already provide the desktop software and we should specialize on server software. We need to assess how many reverse dependencies there are to actually remove these. Since these are central Gnome packages, I expect a high number of rev deps. Maciej From bwalton at opencsw.org Thu Jun 21 12:40:21 2012 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 21 Jun 2012 06:40:21 -0400 Subject: [csw-maintainers] openssl-group1 gnome stuff In-Reply-To: <7400d6d46930.4fe2dc2e@contac-dt.de> References: <7400d6d46930.4fe2dc2e@contac-dt.de> Message-ID: <42c20e01-29b4-402f-b98b-362febe9028b@email.android.com> Yes, that would be fine with me. If someone needs those they can build them again at that time. Thanks -Ben Carsten Grzemba wrote: I think we can remove the gnome stuff listed in openssl-group1, except of gthumb? Ken Mays ( Retired ) filerollergnomedesktopgnomekeyringmgrgnome_sessiongnomesysmongnome_terminalgthumblibgnomecupslibgnomeprintnautilusWhat think the others? -- Carsten Grzemba Tel.: +49 3677 64740 Mobil: +49 171 9749479 Fax:: +49 3677 6474111 Email: carsten.grzemba at contac-dt.de contac Datentechnik GmbH -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Thu Jun 21 15:19:41 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 21 Jun 2012 14:19:41 +0100 Subject: [csw-maintainers] openssl-group1 gnome stuff In-Reply-To: <7400d6d46930.4fe2dc2e@contac-dt.de> References: <7400d6d46930.4fe2dc2e@contac-dt.de> Message-ID: 2012/6/21 Carsten Grzemba : > I think we can remove the gnome stuff listed in openssl-group1, except of > gthumb? I checked the listed packages, dropped ones with no reverse dependencies, and listed the reverse dependencies I found. We need to think which revdeps we can drop too (e.g. bugbuddy), and which ones we want to keep, meaning that we have to do the work of rebuilding them and their dependencies. Maciej From pfelecan at opencsw.org Thu Jun 21 19:56:42 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 21 Jun 2012 19:56:42 +0200 Subject: [csw-maintainers] request to review pilotlink recipe In-Reply-To: <214902D3-96DB-48EF-ADFE-1D8AA421FA70@opencsw.org> (Dagobert Michelsen's message of "Wed, 20 Jun 2012 16:45:34 +0200") References: <214902D3-96DB-48EF-ADFE-1D8AA421FA70@opencsw.org> Message-ID: Dagobert Michelsen writes: >> What I'm doing wrong ? > > Because it is called PATCHFILES ? Right on spot. Thank you. -- Peter From yann at pleiades.fr.eu.org Thu Jun 21 20:09:11 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Thu, 21 Jun 2012 20:09:11 +0200 Subject: [csw-maintainers] openssl-group1 gnome stuff In-Reply-To: <42c20e01-29b4-402f-b98b-362febe9028b@email.android.com> References: <7400d6d46930.4fe2dc2e@contac-dt.de> <42c20e01-29b4-402f-b98b-362febe9028b@email.android.com> Message-ID: I also do agree. Yann 2012/6/21 Ben Walton > ** Yes, that would be fine with me. If someone needs those they can build > them again at that time. > > Thanks > -Ben > > > Carsten Grzemba wrote: >> >> I think we can remove the gnome stuff listed in openssl-group1, except of >> gthumb? >> >> *Ken Mays ( Retired )* >> >> - fileroller >> - gnomedesktop >> - gnomekeyringmgr >> - gnome_session >> - gnomesysmon >> - gnome_terminal >> - gthumb >> - libgnomecups >> - libgnomeprint >> - nautilus >> >> What think the others? >> -- >> Carsten Grzemba >> Tel.: +49 3677 64740 >> Mobil: +49 171 9749479 >> Fax:: +49 3677 6474111 >> Email: carsten.grzemba at contac-dt.de >> contac Datentechnik GmbH > > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Thu Jun 21 20:14:23 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Thu, 21 Jun 2012 20:14:23 +0200 Subject: [csw-maintainers] OpenSSL project task order In-Reply-To: <1340199645-sup-433@pinkfloyd.chass.utoronto.ca> References: <5A063A52-E8A1-4044-AD95-0FF0B096AC31@opencsw.org> <1340199645-sup-433@pinkfloyd.chass.utoronto.ca> Message-ID: Hi Ben, You're right, I've made a mistake in group 5, it should contain only php5_imap and imaprt, I fixed the wiki. imaprt has been superseded by libc_client. According to the opencsw website, php5_imap is linked with openssl 1.0.0 but libc_client is still linked with openssl 0.9.8. According to the wiki, it should be the opposite. Can you upload to unstable the package that is still linked to openssl 0.9.8 ? Yann 2012/6/20 Ben Walton > Excerpts from Dagobert Michelsen's message of Wed Jun 20 07:00:01 -0400 > 2012: > > Hi Dago, > > > openssl-relinking-group5 > > I've just been pushing anything from this group directly to unstable. > There are no inter-dependencies among this set. I'll move the other > things I've re-rolled around tonight. > > My current openssl project is gdal/libgdal which is part of group 1. > I can do a re-roll with c++ but got hung up trying to make it build > with studio so that I could test a patch I submitted. Several > additional patches later, I'm stuck with a c99/stdbool.h vs c++ issue. > I'll detail that in another email later to see if someone can help me > over that hurdle. > > Thanks > -Ben > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Fri Jun 22 01:44:08 2012 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 21 Jun 2012 19:44:08 -0400 Subject: [csw-maintainers] c99/stdbool.h with c++ Message-ID: <1340322099-sup-9966@pinkfloyd.chass.utoronto.ca> Hi All, I'm trying to build a C++ library with Sun CC and it's pulling in a header that subsequently includes stdbool.h. This fails with: "/usr/include/stdbool.h", line 42: Error: #error "Use of is valid only in a c99 compilation environment.". The failure is because _STDC_C99 isn't declared. I understand that c99 and c++ aren't compatible in some circumstances (this likely being a good example) but I'd like to try build this project with Sun CC so that I can test some patches that I submitted. I've tried using -xc99, -xlang=c99 and forcing the definition of _STDC_C99. I either get no better result or an explosing (_STDC_C99) has other bad effects. This project will build with g++. Does anyone have thoughts on building a c++ app that requires c99 features using CC? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Fri Jun 22 01:46:39 2012 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 21 Jun 2012 19:46:39 -0400 Subject: [csw-maintainers] OpenSSL project task order In-Reply-To: References: <5A063A52-E8A1-4044-AD95-0FF0B096AC31@opencsw.org> <1340199645-sup-433@pinkfloyd.chass.utoronto.ca> Message-ID: <1340322326-sup-9944@pinkfloyd.chass.utoronto.ca> Excerpts from Yann Rouillard's message of Thu Jun 21 14:14:23 -0400 2012: Hi Yann, > You're right, I've made a mistake in group 5, it should contain only > php5_imap and imaprt, I fixed the wiki. Ok, thanks for doing this. > imaprt has been superseded by libc_client. According to the opencsw > website, php5_imap is linked with openssl 1.0.0 but libc_client is > still linked with openssl 0.9.8. According to the wiki, it should > be the opposite. Can you upload to unstable the package that is > still linked to openssl 0.9.8 ? I split the imaprt package into: libc_client2004g (old, linked against 0.9.8), imaprt_stub (depends on 2004g) and libc_client2007f (new, linked against 1.0.0). I should be able to release just the php5_imap updated to a 1.0.0 dependency, no? I'm tweaking the php5 build right now as due to the poor .so naming in c-client it was ending up depending on the -dev package instead of the lib package...If you need me to revert something, I can likely do that, but I wanted to clarify the situation first. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From ihsan at opencsw.org Fri Jun 22 16:14:45 2012 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuIERvxJ9hbg==?=) Date: Fri, 22 Jun 2012 16:14:45 +0200 Subject: [csw-maintainers] Libraries in /opt/csw/lib Message-ID: <4FE47DD5.1000507@opencsw.org> Hi, I've updated last week my libldns1 package and I've noticed now, that there are no libraries in /opt/csw/lib, but in sparv8plus and sparcv9. Was there recently a change with Gar? Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Fri Jun 22 16:19:25 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 22 Jun 2012 16:19:25 +0200 Subject: [csw-maintainers] Libraries in /opt/csw/lib In-Reply-To: <4FE47DD5.1000507@opencsw.org> References: <4FE47DD5.1000507@opencsw.org> Message-ID: <009DF329-6565-4573-BAA4-1534B39FA73C@opencsw.org> Hi Ihsan, Am 22.06.2012 um 16:14 schrieb ?hsan Do?an: > I've updated last week my libldns1 package and I've noticed now, that > there are no libraries in /opt/csw/lib, but in sparv8plus and sparcv9. > > Was there recently a change with Gar? It has been some time now that we raised the build level to sparcv8+ and pentium due to __sync_fetch_and_add_4 reported missing on lots of builds on the lower end. However, I notice that we should lib .so in lib or linkage will fail. Do you have any issues? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From ihsan at opencsw.org Fri Jun 22 16:35:15 2012 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuIERvxJ9hbg==?=) Date: Fri, 22 Jun 2012 16:35:15 +0200 Subject: [csw-maintainers] Messages from non-opencsw.org addresses In-Reply-To: <1339083059-sup-2361@pinkfloyd.chass.utoronto.ca> References: <1339083059-sup-2361@pinkfloyd.chass.utoronto.ca> Message-ID: <4FE482A3.5000808@opencsw.org> On 06/07/2012 05:31 PM, Ben Walton wrote: >>> Any objections or thoughts? >> >> If that's possible I like that too. Less work for Ihsan. > > +1. I should be able to make this reconfig if nobody disagrees. I have changed now the mailing list options: - Posts from non @opencsw.org addresses are rejected. - I've deleted the exceptions. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Fri Jun 22 17:10:35 2012 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuIERvxJ9hbg==?=) Date: Fri, 22 Jun 2012 17:10:35 +0200 Subject: [csw-maintainers] Libraries in /opt/csw/lib In-Reply-To: <009DF329-6565-4573-BAA4-1534B39FA73C@opencsw.org> References: <4FE47DD5.1000507@opencsw.org> <009DF329-6565-4573-BAA4-1534B39FA73C@opencsw.org> Message-ID: <4FE48AEB.4080800@opencsw.org> Hi Dago, On 06/22/2012 04:19 PM, Dagobert Michelsen wrote: >> I've updated last week my libldns1 package and I've noticed now, that >> there are no libraries in /opt/csw/lib, but in sparv8plus and sparcv9. >> >> Was there recently a change with Gar? > > It has been some time now that we raised the build level to sparcv8+ and pentium > due to __sync_fetch_and_add_4 reported missing on lots of builds on the lower end. I know, but I just noticed that there no libraries in /opt/csw/lib anymore. > However, I notice that we should lib .so in lib or linkage will fail. Do you have > any issues? After building libldns1, the following files where packaged: 1 s none /opt/csw/lib/sparcv8plus+vis/libldns.so.1=libldns.so.1.6.13 1 f none /opt/csw/lib/sparcv8plus+vis/libldns.so.1.6.13 0755 root bin 1617688 7505 1340377388 1 s none /opt/csw/lib/sparcv8plus/libldns.so.1=libldns.so.1.6.13 1 f none /opt/csw/lib/sparcv8plus/libldns.so.1.6.13 0755 root bin 1617472 30367 1340376669 1 s none /opt/csw/lib/sparcv9/libldns.so.1=libldns.so.1.6.13 1 f none /opt/csw/lib/sparcv9/libldns.so.1.6.13 0755 root bin 1970960 37522 1340377079 1 d none /opt/csw/share/doc/libldns1 0755 root bin 1 f none /opt/csw/share/doc/libldns1/license 0644 root bin 1510 53742 1340377391 The problem is, that unbound expects something in /opt/csw/lib, but there is nothing and the configure script fails. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From maciej at opencsw.org Fri Jun 22 22:39:59 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 22 Jun 2012 21:39:59 +0100 Subject: [csw-maintainers] Messages from non-opencsw.org addresses In-Reply-To: <4FE482A3.5000808@opencsw.org> References: <1339083059-sup-2361@pinkfloyd.chass.utoronto.ca> <4FE482A3.5000808@opencsw.org> Message-ID: 2012/6/22 ?hsan Do?an : > I have changed now the mailing list options: > > - Posts from non @opencsw.org addresses are rejected. > - I've deleted the exceptions. Thanks! From Joerg.Schilling at fokus.fraunhofer.de Fri Jun 22 22:44:36 2012 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Fri, 22 Jun 2012 22:44:36 +0200 Subject: [csw-maintainers] Messages from non-opencsw.org addresses In-Reply-To: References: <1339083059-sup-2361@pinkfloyd.chass.utoronto.ca> <4FE482A3.5000808@opencsw.org> Message-ID: <4fe4d934.LpwpU/KkTsU8gNkz%Joerg.Schilling@fokus.fraunhofer.de> Maciej (Matchek) Blizi??ski wrote: > 2012/6/22 ??hsan Do??an : > > I have changed now the mailing list options: > > > > - Posts from non @opencsw.org addresses are rejected. > > - I've deleted the exceptions. > > Thanks! I am a bit confused: Isn't it sufficient to limit postings to addresses that are subscribed to the list? 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 maciej at opencsw.org Sat Jun 23 01:45:35 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 23 Jun 2012 00:45:35 +0100 Subject: [csw-maintainers] =?utf-8?q?MySQL_built_with_GCC_=E2=86=92_mysql_?= =?utf-8?q?config_vs_bindings?= In-Reply-To: References: <113DCAD0-9822-4938-993A-1EA6D4039287@opencsw.org> <1340063281-sup-9735@pinkfloyd.chass.utoronto.ca> Message-ID: 2012/6/19 Peter FELECAN : > Ben Walton writes: > >> Unless we make a hard standardization on one compiler, this problem >> won't be easily solved, I don't think. >> >> What do others think? > > For the majority of projects coming from the GNU and associates, using > gcc is the best thing that we can do. To simplify thing, all libraries > and development tools should be built with gcc; as a side effect we > avoid /opt/csw/gxx and other horrors. Using studio can be an option for > end user applications, i.e. on which there are no dependencies; of > course, for those application written in C++ it becomes mandatory to use > gcc. > > These were my 2 drachmas of evening wisdom I wouldn't like this to go unanswered. In my opinion, this is a reasonable target state. I don't mean that there should be only one compiler in the world. If C and C++ are portable languages, there should be multiple compilers implementing standards and code should be good to compile with any of them, on any system. Getting the state where the code compiles with multiple compilers requires a lot of work. Do we want us to be the people who do that? Many upstream developers don't test on Solaris, which already creates a lot of work of us, maintainers. Adding one more dimension of difference, we're putting even more work on our plate. Not that porting isn't interesting ? when building with Studio, you get to learn about some interesting aspects of C and C++. But with time, if what you want is a working binary and not porting fun, it just gets tedious. I suspect that we wouldn't be able to maintain Solaris Studio ports of all the software that we maintain. Some software we just want built and released. At the same time, I see value in building at least some major software projects, such as the database engines, with more than just GCC. If they already do a good job of building with Studio, why not continue building them with Studio? I just wouldn't like the compiler porting issue to hamper our ability to keep up to date with upstream releases and new builds. Maciej From pfelecan at opencsw.org Sat Jun 23 10:52:39 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 23 Jun 2012 10:52:39 +0200 Subject: [csw-maintainers] =?gb2312?b?TXlTUUwgYnVpbHQgd2l0aCBHQ0MgofogbXlz?= =?gb2312?b?cWwgY29uZmlnIHZzIGJpbmRpbmdz?= In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sat, 23 Jun 2012 00:45:35 +0100") References: <113DCAD0-9822-4938-993A-1EA6D4039287@opencsw.org> <1340063281-sup-9735@pinkfloyd.chass.utoronto.ca> Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2012/6/19 Peter FELECAN : >> Ben Walton writes: >> >>> Unless we make a hard standardization on one compiler, this problem >>> won't be easily solved, I don't think. >>> >>> What do others think? >> >> For the majority of projects coming from the GNU and associates, using >> gcc is the best thing that we can do. To simplify thing, all libraries >> and development tools should be built with gcc; as a side effect we >> avoid /opt/csw/gxx and other horrors. Using studio can be an option for >> end user applications, i.e. on which there are no dependencies; of >> course, for those application written in C++ it becomes mandatory to use >> gcc. >> >> These were my 2 drachmas of evening wisdom > > I wouldn't like this to go unanswered. In my opinion, this is a > reasonable target state. I don't mean that there should be only one > compiler in the world. If C and C++ are portable languages, there > should be multiple compilers implementing standards and code should be > good to compile with any of them, on any system. Getting the state > where the code compiles with multiple compilers requires a lot of > work. Do we want us to be the people who do that? Many upstream > developers don't test on Solaris, which already creates a lot of work > of us, maintainers. Adding one more dimension of difference, we're > putting even more work on our plate. Not that porting isn't > interesting ? when building with Studio, you get to learn about some > interesting aspects of C and C++. But with time, if what you want is a > working binary and not porting fun, it just gets tedious. > > I suspect that we wouldn't be able to maintain Solaris Studio ports of > all the software that we maintain. Some software we just want built > and released. At the same time, I see value in building at least some > major software projects, such as the database engines, with more than > just GCC. If they already do a good job of building with Studio, why > not continue building them with Studio? I just wouldn't like the > compiler porting issue to hamper our ability to keep up to date with > upstream releases and new builds. Here are 2 recent cases: - packaging pilot-link I'm forced to use Solaris Studio because TCL is built with and I'm left with the choice between compiling with gcc but without TCL binding or with Solaris Studio and TCL binding but probably forced to use the same for JPilot... I choose to go with the TCL binding as I'm taking over the package and don't wish to offer a poorer experience. - psedit has partially C++ code but depending on packages built with Solaris Studio, I'm forced to use it; this is not a case of a better complying compiler but of different mangling algorithms, isn't it? Given our limited resources we should be Hamiltonian adepts and adopt policies in this direction, i.e., using gcc as the default compiler. -- Peter From maciej at opencsw.org Sat Jun 23 11:28:14 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 23 Jun 2012 10:28:14 +0100 Subject: [csw-maintainers] Solaris 9 and amd64 Message-ID: We used this hack in which we'd put 5.10 built amd64 binaries into a 5.9 package. It allowed as to label the whole package as a 5.9 one and because amd64 binaries are never executed under Solaris 9, the package would just work. It didn't cause problems until now. The OpenSSL upgrade happens only on Solaris 10, so now we need different dependencies on Solaris 9 and 10. What happens is that the amd64 binary gets linked to the new OpenSSL, then merged into the 5.9 package which is supposed to only depend on the old OpenSSL. I've seen Dagobert tackling this in r17426 but this solution has the side effect that we remove the 64-bit build from sparc as well as intel, which is probably not what we want. Is there a better way? I tried adding a reference to $(GARCH) in the MySQL recipe[2], but it didn't work. Any other ideas? Maciej [1] http://sourceforge.net/apps/trac/gar/changeset/17426 [2] http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/mysql5/branches/mysql-5.5.x/Makefile?rev=18507#L144 From rupert at opencsw.org Sun Jun 24 14:42:48 2012 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 24 Jun 2012 14:42:48 +0200 Subject: [csw-maintainers] git subtree instead of submodule ... Message-ID: hi, last year some of us did some experiments with converting / tracking opencsw with git. git includes now "subtree", anyone of you has made some experiences with it? https://raw.github.com/git/git/master/Documentation/RelNotes/1.7.11.txt https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt rupert. From bwalton at opencsw.org Sun Jun 24 16:23:16 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 24 Jun 2012 10:23:16 -0400 Subject: [csw-maintainers] =?utf-8?q?MySQL_built_with_GCC_=E2=86=92_mysql_?= =?utf-8?q?config_vs_bindings?= In-Reply-To: References: <113DCAD0-9822-4938-993A-1EA6D4039287@opencsw.org> <1340063281-sup-9735@pinkfloyd.chass.utoronto.ca> Message-ID: <1340542610-sup-799@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Fri Jun 22 19:45:35 -0400 2012: > I wouldn't like this to go unanswered. In my opinion, this is a > reasonable target state. I don't mean that there should be only one Agreed. I kept this thread in my inbox as I did intend to reply. It's definitely an important topic and we've discussed it somewhat in the past. I'm basically in the pragmatic camp here. With limited time and resources, we should spend less time fighting the compilers and more time improving packages and tools. If fixes for making things build with studio are easy, that's great. Patches should be submitted upstream to keep the project honest. In cases where fixes are non-trivial the question of whether fixing it is time well spent should be asked...in my own case, this answer is most often no. I'm delivering less benefit to the project when I spend time porting to studio. (I agree that it is interesting and enjoyable work, but it's a side benefit to the project and not the core goal.) For the purposes of our project, having disjointed c++ libraries is something that can cause us serious pain. To avoid this, standardizing on one compiler is definitely a good choice. It would let us avoid the /opt/csw/gxx split. If we do standardize this way though, we would likely want to rebuild anything that is c++ and provides a library and then all of the dependant packages. I haven't looked at how large a set of packages this is (it may not be too bad), but it would be a lot of work too. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Sun Jun 24 20:07:13 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 24 Jun 2012 20:07:13 +0200 Subject: [csw-maintainers] =?gb2312?b?TXlTUUwgYnVpbHQgd2l0aCBHQ0MgofogbXlz?= =?gb2312?b?cWwgY29uZmlnIHZzIGJpbmRpbmdz?= In-Reply-To: <1340542610-sup-799@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Sun, 24 Jun 2012 10:23:16 -0400") References: <113DCAD0-9822-4938-993A-1EA6D4039287@opencsw.org> <1340063281-sup-9735@pinkfloyd.chass.utoronto.ca> <1340542610-sup-799@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > Excerpts from Maciej (Matchek) Blizi?ski's message of Fri Jun 22 19:45:35 -0400 2012: > >> I wouldn't like this to go unanswered. In my opinion, this is a >> reasonable target state. I don't mean that there should be only one > > For the purposes of our project, having disjointed c++ libraries is > something that can cause us serious pain. To avoid this, > standardizing on one compiler is definitely a good choice. It would > let us avoid the /opt/csw/gxx split. If we do standardize this way > though, we would likely want to rebuild anything that is c++ and > provides a library and then all of the dependant packages. I haven't > looked at how large a set of packages this is (it may not be too bad), > but it would be a lot of work too. Not only C++ based projects are impacted. As I mentioned in this thread, you can have similar issues with C based projects when the pkg-config files contain Sun Studio specific arguments; I suspect that there are shared objects issues also but I'm not sure yet (still exploring). -- Peter From maciej at opencsw.org Mon Jun 25 00:34:53 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 24 Jun 2012 23:34:53 +0100 Subject: [csw-maintainers] MySQL built with GCC ??? mysql_config vs bindings In-Reply-To: <20120619053608.GK15615@bender.opencsw.org> References: <113DCAD0-9822-4938-993A-1EA6D4039287@opencsw.org> <20120618185559.GB19735@quince.home.blizinski.pl> <20120619053608.GK15615@bender.opencsw.org> Message-ID: For the record, this is now done, we have MySQL 5.5 built with Studio. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Mon Jun 25 02:56:25 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 24 Jun 2012 20:56:25 -0400 Subject: [csw-maintainers] Solaris 9 and amd64 In-Reply-To: References: Message-ID: <1340585679-sup-6733@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Sat Jun 23 05:28:14 -0400 2012: Hi Maciej, > reference to $(GARCH) in the MySQL recipe[2], but it didn't work. Any > other ideas? Mabye we should just declare solaris 9 entirely dead instead of just 'best effort'? We can jump through all sorts of hoops to keep it going but at the end of the day, we're complicating either recipes or GAR itself in order to accommodate something the vendor no longer maintains. I think we'd be misspending cycles to continue down this path (and other similar ones that will arise as time passes). Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Jun 25 03:11:56 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 24 Jun 2012 21:11:56 -0400 Subject: [csw-maintainers] board elections 2012 In-Reply-To: <1339022795-sup-1395@pinkfloyd.chass.utoronto.ca> References: <1337265633-sup-8553@pinkfloyd.chass.utoronto.ca> <1339022795-sup-1395@pinkfloyd.chass.utoronto.ca> Message-ID: <1340586611-sup-7400@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Wed Jun 06 18:47:59 -0400 2012: > So far we've got two nominees to form the new board. Is anyone else > planning to step up but hasn't done so yet? Ok, there are currently three nominations on the wiki[1] page. It seems like an election by acclamation will be the way of things. Unless there are objections, we'll form the new board this week. To do the formal transfer, we'll need to hold our "annual" meeting to present the treasurer's report. That could be done as a G+ hangout with Rizzoma (a Wave replacement) to record the details. Thanks -Ben [1] http://wiki.opencsw.org/boardelection2012 -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Jun 25 03:13:55 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 24 Jun 2012 21:13:55 -0400 Subject: [csw-maintainers] =?utf-8?q?MySQL_built_with_GCC_=E2=86=92_mysql_?= =?utf-8?q?config_vs_bindings?= In-Reply-To: References: <113DCAD0-9822-4938-993A-1EA6D4039287@opencsw.org> <1340063281-sup-9735@pinkfloyd.chass.utoronto.ca> <1340542610-sup-799@pinkfloyd.chass.utoronto.ca> Message-ID: <1340586744-sup-8673@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Sun Jun 24 14:07:13 -0400 2012: Hi Peter, > Not only C++ based projects are impacted. As I mentioned in this > thread, you can have similar issues with C based projects when the > pkg-config files contain Sun Studio specific arguments; I suspect > that there are shared objects issues also but I'm not sure yet > (still exploring). Yes, sorry, I'd forgotten to discuss that point. This means that a switch to GNU as the preferred compiler set means we'd need to rebuild any C++ app with a footprint in $(libdir) in addition to any package providing a *-config program. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bonivart at opencsw.org Mon Jun 25 13:23:47 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 25 Jun 2012 13:23:47 +0200 Subject: [csw-maintainers] Solaris 9 and amd64 In-Reply-To: <1340585679-sup-6733@pinkfloyd.chass.utoronto.ca> References: <1340585679-sup-6733@pinkfloyd.chass.utoronto.ca> Message-ID: On Mon, Jun 25, 2012 at 2:56 AM, Ben Walton wrote: > Excerpts from Maciej (Matchek) Blizi?ski's message of Sat Jun 23 05:28:14 -0400 2012: > > Hi Maciej, > >> reference to $(GARCH) in the MySQL recipe[2], but it didn't work. Any >> other ideas? > > Mabye we should just declare solaris 9 entirely dead instead of just > 'best effort'? ?We can jump through all sorts of hoops to keep it > going but at the end of the day, we're complicating either recipes or > GAR itself in order to accommodate something the vendor no longer > maintains. ?I think we'd be misspending cycles to continue down this > path (and other similar ones that will arise as time passes). I think we should both drop Solaris 9 and make gcc the default compiler. /peter From jcraig at opencsw.org Mon Jun 25 13:31:40 2012 From: jcraig at opencsw.org (Jonathan Craig) Date: Mon, 25 Jun 2012 07:31:40 -0400 Subject: [csw-maintainers] =?utf-8?q?MySQL_built_with_GCC_=E2=86=92_mysql_?= =?utf-8?q?config_vs_bindings?= In-Reply-To: <1340586744-sup-8673@pinkfloyd.chass.utoronto.ca> References: <113DCAD0-9822-4938-993A-1EA6D4039287@opencsw.org> <1340063281-sup-9735@pinkfloyd.chass.utoronto.ca> <1340542610-sup-799@pinkfloyd.chass.utoronto.ca> <1340586744-sup-8673@pinkfloyd.chass.utoronto.ca> Message-ID: Sorry if this becomes a double post as I thought I sent this last night. This also affects language packages such as perl, ruby, etc, in that end users wishing to compile libraries are forced to put together a solaris studio environment and potentially forced to navigate the issues of compiling a gcc oriented module using studio. As we cannot package a studio install this becomes a source of consternation for the end user. I know some of these packages have offered gcc/studio variants but this becomes a burden for the packager and in times where cycles are short the GCC variant may become delayed or non-existent. Jon On Sun, Jun 24, 2012 at 9:13 PM, Ben Walton wrote: > Excerpts from Peter FELECAN's message of Sun Jun 24 14:07:13 -0400 2012: > > Hi Peter, > >> Not only C++ based projects are impacted. As I mentioned in this >> thread, you can have similar issues with C based projects when the >> pkg-config files contain Sun Studio specific arguments; I suspect >> that there are shared objects issues also but I'm not sure yet >> (still exploring). > > Yes, sorry, I'd forgotten to discuss that point. ?This means that a > switch to GNU as the preferred compiler set means we'd need to rebuild > any C++ app with a footprint in $(libdir) in addition to any package > providing a *-config program. > > Thanks > -Ben > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From Joerg.Schilling at fokus.fraunhofer.de Mon Jun 25 13:31:48 2012 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Mon, 25 Jun 2012 13:31:48 +0200 Subject: [csw-maintainers] Solaris 9 and amd64 In-Reply-To: References: <1340585679-sup-6733@pinkfloyd.chass.utoronto.ca> Message-ID: <4fe84c24.etv/KB+XonIDAnfZ%Joerg.Schilling@fokus.fraunhofer.de> Peter Bonivart wrote: > I think we should both drop Solaris 9 and make gcc the default compiler. Making gcc the default may be in conflict with trying to use OpenCSW as a replacement for Sun's SFW consolidation om OpenSolaris. 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 pfelecan at opencsw.org Mon Jun 25 15:13:37 2012 From: pfelecan at opencsw.org (pfelecan at opencsw.org) Date: Mon, 25 Jun 2012 15:13:37 +0200 (CEST) Subject: [csw-maintainers] please reveiw new CAS Message-ID: Trying to factorize installation and removal of Tex packages by implementing my first CAS. Please review: http://gar.svn.sourceforge.net/gar/?rev=18524&view=rev TIA From bwalton at opencsw.org Mon Jun 25 15:34:00 2012 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 25 Jun 2012 09:34:00 -0400 Subject: [csw-maintainers] please reveiw new CAS In-Reply-To: References: Message-ID: <1340631163-sup-7894@pinkfloyd.chass.utoronto.ca> Excerpts from pfelecan's message of Mon Jun 25 09:13:37 -0400 2012: Hi Peter, > Trying to factorize installation and removal of Tex packages by > implementing my first CAS. > > Please review: > http://gar.svn.sourceforge.net/gar/?rev=18524&view=rev Looks pretty good, but should this line: bash ${PKG_INSTALL_ROOT}/opt/csw/bin/mktexlsr || be: chroot ${PKG_INSTALL_ROOT} bash /opt/csw/bin/mktexlsr || I think the script would get confused about where to look for its files otherwise, no? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Jun 25 15:35:35 2012 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 25 Jun 2012 09:35:35 -0400 Subject: [csw-maintainers] please reveiw new CAS In-Reply-To: <1340631163-sup-7894@pinkfloyd.chass.utoronto.ca> References: <1340631163-sup-7894@pinkfloyd.chass.utoronto.ca> Message-ID: <1340631312-sup-2809@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Mon Jun 25 09:34:00 -0400 2012: > chroot ${PKG_INSTALL_ROOT} bash /opt/csw/bin/mktexlsr || Actually: chroot ${PKG_INSTALL_ROOT:-/} bash /opt/csw/bin/mktexlsr || Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Mon Jun 25 15:44:29 2012 From: pfelecan at opencsw.org (pfelecan at opencsw.org) Date: Mon, 25 Jun 2012 15:44:29 +0200 (CEST) Subject: [csw-maintainers] workflow for a new CAS Message-ID: <2c4b8aa122a52bcaadd234fcd3309250.squirrel@mail.opencsw.org> When a new CAS is created it should be documented in the README provided by the main package, i.e., cswclassutils. Consequently, it should be released the same time as the new package corresponding to the new CAS, isn't it? What's the 6th step, after: 5. mgar package-CSWcas-$name (eg: package-CSWcas-initsmf) From bwalton at opencsw.org Mon Jun 25 15:52:12 2012 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 25 Jun 2012 09:52:12 -0400 Subject: [csw-maintainers] workflow for a new CAS In-Reply-To: <2c4b8aa122a52bcaadd234fcd3309250.squirrel@mail.opencsw.org> References: <2c4b8aa122a52bcaadd234fcd3309250.squirrel@mail.opencsw.org> Message-ID: <1340632221-sup-9167@pinkfloyd.chass.utoronto.ca> Excerpts from pfelecan's message of Mon Jun 25 09:44:29 -0400 2012: Hi Peter, > What's the 6th step, after: > > 5. mgar package-CSWcas-$name (eg: package-CSWcas-initsmf) I'd normally just do mgar package and then only push the required updates. In this case, CSWcswclassutils and CSWcas-$name. In most cases, we don't even need to have CSWcswclassutils updated with the dependency on the new CAS as that was only to help transition from the monolithic package in the past. So for any future changes to an existing CAS, only the updated CAS package needs to be pushed. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From ihsan at opencsw.org Mon Jun 25 17:09:09 2012 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Mon, 25 Jun 2012 17:09:09 +0200 Subject: [csw-maintainers] Messages from non-opencsw.org addresses In-Reply-To: <4fe4d934.LpwpU/KkTsU8gNkz%Joerg.Schilling@fokus.fraunhofer.de> References: <1339083059-sup-2361@pinkfloyd.chass.utoronto.ca> <4FE482A3.5000808@opencsw.org> <4fe4d934.LpwpU/KkTsU8gNkz%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <4FE87F15.6020302@opencsw.org> Hi J?rg, Am 22.06.2012 22:44, schrieb Joerg Schilling: >> 2012/6/22 ??hsan Do??an : >>> I have changed now the mailing list options: >>> >>> - Posts from non @opencsw.org addresses are rejected. >>> - I've deleted the exceptions. >> >> Thanks! > > I am a bit confused: Isn't it sufficient to limit postings to addresses that > are subscribed to the list? Before, posts from non @opencsw.org addresses were put on hold. Besides that, there were many exceptions, which allowed people to post from their e-mail addresses, which were not subscribed to this list. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Mon Jun 25 17:11:21 2012 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Mon, 25 Jun 2012 17:11:21 +0200 Subject: [csw-maintainers] board elections 2012 In-Reply-To: <1340586611-sup-7400@pinkfloyd.chass.utoronto.ca> References: <1337265633-sup-8553@pinkfloyd.chass.utoronto.ca> <1339022795-sup-1395@pinkfloyd.chass.utoronto.ca> <1340586611-sup-7400@pinkfloyd.chass.utoronto.ca> Message-ID: <4FE87F99.9070307@opencsw.org> Am 25.06.2012 03:11, schrieb Ben Walton: >> So far we've got two nominees to form the new board. Is anyone else >> planning to step up but hasn't done so yet? > > Ok, there are currently three nominations on the wiki[1] page. It > seems like an election by acclamation will be the way of things. > Unless there are objections, we'll form the new board this week. > > To do the formal transfer, we'll need to hold our "annual" meeting to > present the treasurer's report. That could be done as a G+ hangout > with Rizzoma (a Wave replacement) to record the details. The last time we did it on Google Wave, so all the members should have a Google account. I think Google+ is for us probably the best solution. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From Joerg.Schilling at fokus.fraunhofer.de Mon Jun 25 17:25:05 2012 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Mon, 25 Jun 2012 17:25:05 +0200 Subject: [csw-maintainers] Messages from non-opencsw.org addresses In-Reply-To: <4FE87F15.6020302@opencsw.org> References: <1339083059-sup-2361@pinkfloyd.chass.utoronto.ca> <4FE482A3.5000808@opencsw.org> <4fe4d934.LpwpU/KkTsU8gNkz%Joerg.Schilling@fokus.fraunhofer.de> <4FE87F15.6020302@opencsw.org> Message-ID: <4fe882d1.fqWZNPh97Zg5btp2%Joerg.Schilling@fokus.fraunhofer.de> ??hsan?Do??an wrote: > >>> - Posts from non @opencsw.org addresses are rejected. > >>> - I've deleted the exceptions. > >> > >> Thanks! > > > > I am a bit confused: Isn't it sufficient to limit postings to addresses that > > are subscribed to the list? > > Before, posts from non @opencsw.org addresses were put on hold. Besides > that, there were many exceptions, which allowed people to post from > their e-mail addresses, which were not subscribed to this list. If everybody can post with the email address he is subsribed, I see no problem. 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 bwalton at opencsw.org Mon Jun 25 18:03:10 2012 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 25 Jun 2012 12:03:10 -0400 Subject: [csw-maintainers] git subtree instead of submodule ... In-Reply-To: References: Message-ID: <1340640105-sup-1197@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Sun Jun 24 08:42:48 -0400 2012: Hi Rupert, > last year some of us did some experiments with converting / tracking > opencsw with git. git includes now "subtree", anyone of you has made > some experiences with it? > https://raw.github.com/git/git/master/Documentation/RelNotes/1.7.11.txt > https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt I haven't played with this beyond some minor testing I did of the feature way back[1]. At that time, it didn't solve things in a way that I really liked but I hadn't thought about applying it to GAR either...It might be worth a look. Thanks -Ben [1] http://www.opencsw.org/packages/CSWgitsubtree/: I should drop this package, I guess. :) -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Mon Jun 25 18:25:57 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 25 Jun 2012 17:25:57 +0100 Subject: [csw-maintainers] board elections 2012 In-Reply-To: <4FE87F99.9070307@opencsw.org> References: <1337265633-sup-8553@pinkfloyd.chass.utoronto.ca> <1339022795-sup-1395@pinkfloyd.chass.utoronto.ca> <1340586611-sup-7400@pinkfloyd.chass.utoronto.ca> <4FE87F99.9070307@opencsw.org> Message-ID: 2012/6/25 ?hsan?Do?an > The last time we did it on Google Wave, so all the members should have a > Google account. I think Google+ is for us probably the best solution. For note keeping, Google Docs is enough. There is now integration between hangouts and docs, so this looks like the best fit overall. Maciej From maciej at opencsw.org Mon Jun 25 18:28:51 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 25 Jun 2012 17:28:51 +0100 Subject: [csw-maintainers] Solaris 9 and amd64 In-Reply-To: <4fe84c24.etv/KB+XonIDAnfZ%Joerg.Schilling@fokus.fraunhofer.de> References: <1340585679-sup-6733@pinkfloyd.chass.utoronto.ca> <4fe84c24.etv/KB+XonIDAnfZ%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: 2012/6/25 Joerg Schilling : >> I think we should both drop Solaris 9 and make gcc the default compiler. > > Making gcc the default may be in conflict with trying to use OpenCSW as a > replacement for Sun's SFW consolidation om OpenSolaris. Could you expand on that? By using OpenCSW, do you mean using the build recipes (with potentially altered $(BUILD_PREFIX)) or using the binary packages? I could imagine source-level cooperation, where two branches would be similar, with the only difference would be the compiler setting and required patches. Maciej From dam at opencsw.org Mon Jun 25 19:13:14 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 25 Jun 2012 19:13:14 +0200 Subject: [csw-maintainers] Inconsistency on package database In-Reply-To: References: <1330091058-sup-811@pinkfloyd.chass.utoronto.ca> <1331771691-sup-4120@pinkfloyd.chass.utoronto.ca> <1331918003-sup-8437@pinkfloyd.chass.utoronto.ca> <1331945934-sup-6797@pinkfloyd.chass.utoronto.ca> <1331949772-sup-6101@pinkfloyd.chass.utoronto.ca> <20120317092813.GA29664@quince.home.blizinski.pl> <5F2FB823-AC2F-4173-8D52-FB297659D081@opencsw.org> Message-ID: <86E15947-CEC3-4533-868A-BF8ECDEDD5B7@opencsw.org> Hi Juraj, Am 19.03.2012 um 10:37 schrieb Maciej (Matchek) Blizi?ski: > No dia 19 de Mar?o de 2012 09:15, Dagobert Michelsen escreveu: >>> = x86 only = >>> >>> libhashkit1 >>> libmemcached >>> libmemcached8 >>> libmemcachedprotocol0 >>> libmemcachedutil2 >>> libquadmath0 >>> mongodb >>> >>> = sparc only = >>> >>> ncsa_mosaic >> >> Is there a reason why libmemcached and ncsa_mosaic are only for one ISA? > > Not sure. I had it for both architectures. Maybe a failed push. I > removed it, I'll rather keep it in my experimental, it's of little > value in the catalog. > > I don't know about libmemchached. I notice that you pushed libmemcached for i386 only on 2011.10.23 and then updated for both sparc and i386 on 2011.10.26 which seems to never have reached unstable. Is there a reason for it or could you repush it? I would like to use it for lighttpd. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From yann at pleiades.fr.eu.org Mon Jun 25 21:56:55 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Mon, 25 Jun 2012 21:56:55 +0200 Subject: [csw-maintainers] Openssl 1.0 migration and desktop packages removal Message-ID: Hi everyone, It seems there is a consensus about our focus on server softwares: http://lists.opencsw.org/pipermail/maintainers/2012-June/016845.html but so far only gnome stuffs have been removed. I wonder what we include in desktop packages: are all graphical applications concerned ? I am particularly interested because the group 1 of packages to rebuild with openssl 1.0 contains a set of desktop packages (and some of them are not maintained anymore). For exemple, could we remove the following packages ? - claws_htmlviewer , claws_mail et libetpan - grip - gnucash - ooocore - bzflag (it's a 3D game so rather desktop no ?) That would allow us to remove these libraries: - libgnomeprint - libgnomecups I am also asking the question for gthumb and gvim, because that's the two last packages that will depend on these libraries (if the previous packages are removed): - libgnome - libbonoboui - gnomevfs2 Carsten Grzemba, why did you want to keep gthumb ? Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcraig at opencsw.org Mon Jun 25 22:25:59 2012 From: jcraig at opencsw.org (Jonathan Craig) Date: Mon, 25 Jun 2012 16:25:59 -0400 Subject: [csw-maintainers] =?utf-8?q?MySQL_built_with_GCC_=E2=86=92_mysql_?= =?utf-8?q?config_vs_bindings?= In-Reply-To: References: <113DCAD0-9822-4938-993A-1EA6D4039287@opencsw.org> <1340063281-sup-9735@pinkfloyd.chass.utoronto.ca> <1340542610-sup-799@pinkfloyd.chass.utoronto.ca> Message-ID: This issue also affects language packages such as perl, ruby, etc., where end users may wish to compile libraries not supplied by OpenCSW. With studio based packages they must establish an environment to support this and we are unable to make this easy on them by providing an OpenCSW packaging of studio. We can and do provide gcc and this makes gcc a better choice for these types of packages. On Jun 24, 2012 2:08 PM, "Peter FELECAN" wrote: > Ben Walton writes: > > > Excerpts from Maciej (Matchek) Blizi?ski's message of Fri Jun 22 > 19:45:35 -0400 2012: > > > >> I wouldn't like this to go unanswered. In my opinion, this is a > >> reasonable target state. I don't mean that there should be only one > > > > For the purposes of our project, having disjointed c++ libraries is > > something that can cause us serious pain. To avoid this, > > standardizing on one compiler is definitely a good choice. It would > > let us avoid the /opt/csw/gxx split. If we do standardize this way > > though, we would likely want to rebuild anything that is c++ and > > provides a library and then all of the dependant packages. I haven't > > looked at how large a set of packages this is (it may not be too bad), > > but it would be a lot of work too. > > Not only C++ based projects are impacted. As I mentioned in this > thread, you can have similar issues with C based projects when the > pkg-config files contain Sun Studio specific arguments; I suspect that > there are shared objects issues also but I'm not sure yet (still > exploring). > > -- > Peter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joerg.Schilling at fokus.fraunhofer.de Mon Jun 25 23:14:57 2012 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Mon, 25 Jun 2012 23:14:57 +0200 Subject: [csw-maintainers] Solaris 9 and amd64 In-Reply-To: References: <1340585679-sup-6733@pinkfloyd.chass.utoronto.ca> <4fe84c24.etv/KB+XonIDAnfZ%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <4fe8d4d1.1vyX0WtGZuClzxv4%Joerg.Schilling@fokus.fraunhofer.de> Maciej (Matchek) Blizi??ski wrote: > 2012/6/25 Joerg Schilling : > >> I think we should both drop Solaris 9 and make gcc the default compiler. > > > > Making gcc the default may be in conflict with trying to use OpenCSW as a > > replacement for Sun's SFW consolidation om OpenSolaris. > > Could you expand on that? By using OpenCSW, do you mean using the > build recipes (with potentially altered $(BUILD_PREFIX)) or using the > binary packages? I could imagine source-level cooperation, where two > branches would be similar, with the only difference would be the > compiler setting and required patches. SchilliX would need separate and slightly different packages but they could be compiled from the same set of sources. The packages should be as compatible as possible to the previous Sun packages. This means that we need to install the binaries relatively to / /usr or /usr/sfw and that there is a need to have ELF version information in libraries that are compatiblle to the Sun version data. The related information can be either obtained from the mapfiles from the sfw source consolidation or from readin the libraries itself. 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 grzemba at contac-dt.de Tue Jun 26 08:25:10 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Tue, 26 Jun 2012 08:25:10 +0200 Subject: [csw-maintainers] Openssl 1.0 migration and desktop packages removal In-Reply-To: <7400f4741ba.4fe955c2@contac-dt.de> References: <7400f4741ba.4fe955c2@contac-dt.de> Message-ID: <7490db193415.4fe971e6@contac-dt.de> > Carsten Grzemba, why did you want to keep gthumb ? I use this, the gthumb contained in Solaris is very outdated, less features. -- Carsten Grzemba -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Tue Jun 26 09:05:26 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 26 Jun 2012 09:05:26 +0200 Subject: [csw-maintainers] Openssl 1.0 migration and desktop packages removal In-Reply-To: <7490db193415.4fe971e6@contac-dt.de> References: <7400f4741ba.4fe955c2@contac-dt.de> <7490db193415.4fe971e6@contac-dt.de> Message-ID: <3D3E4BCE-DD46-4C1E-89C5-54E37AF277A8@opencsw.org> Hi, Am 26.06.2012 um 08:25 schrieb Carsten Grzemba: > > Carsten Grzemba, why did you want to keep gthumb ? > > I use this, the gthumb contained in Solaris is very outdated, less features. I never understood this policy as mandatory, more as a loose direction what is possible to be dropped if it is not maintained. IMHO we keep of course everything a maintainer actively maintains :-) Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Tue Jun 26 10:55:41 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 26 Jun 2012 10:55:41 +0200 Subject: [csw-maintainers] Changes to squid recipe Message-ID: Hi Juraj, I made some enhancements to the squid recipe in a private branch: http://sourceforge.net/apps/trac/gar/changeset/18425/csw/mgar/pkg/squid/branches/squid3-dam It takes out some patches no longer needed in the bumped .20, adds kerberos and fixed a 64 bit issue. Would you mind integrating the changes into trunk and release a new package or should I just push it? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Tue Jun 26 11:03:57 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 26 Jun 2012 10:03:57 +0100 Subject: [csw-maintainers] Openssl 1.0 migration and desktop packages removal In-Reply-To: <7490db193415.4fe971e6@contac-dt.de> References: <7400f4741ba.4fe955c2@contac-dt.de> <7490db193415.4fe971e6@contac-dt.de> Message-ID: 2012/6/26 Carsten Grzemba : > I use this, the gthumb contained in Solaris is very outdated, less features. Carsten, does gthumb actually depend on these gnome libraries? As in, can it be rebuilt to not depend on them? The problem we want to solve is staleness of libgnome, libbonoboui and gnomevfs2. We should either rebuild or remove these libraries. Maciej From maciej at opencsw.org Tue Jun 26 11:09:54 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 26 Jun 2012 10:09:54 +0100 Subject: [csw-maintainers] Solaris 9 and amd64 In-Reply-To: <4fe8d4d1.1vyX0WtGZuClzxv4%Joerg.Schilling@fokus.fraunhofer.de> References: <1340585679-sup-6733@pinkfloyd.chass.utoronto.ca> <4fe84c24.etv/KB+XonIDAnfZ%Joerg.Schilling@fokus.fraunhofer.de> <4fe8d4d1.1vyX0WtGZuClzxv4%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: 2012/6/25 Joerg Schilling : > Maciej (Matchek) Blizi??ski wrote: > >> 2012/6/25 Joerg Schilling : >> >> I think we should both drop Solaris 9 and make gcc the default compiler. >> > >> > Making gcc the default may be in conflict with trying to use OpenCSW as a >> > replacement for Sun's SFW consolidation om OpenSolaris. >> >> Could you expand on that? By using OpenCSW, do you mean using the >> build recipes (with potentially altered $(BUILD_PREFIX)) or using the >> binary packages? I could imagine source-level cooperation, where two >> branches would be similar, with the only difference would be the >> compiler setting and required patches. > > SchilliX would need separate and slightly different packages but they could be > compiled from the same set of sources. Sounds good. > The packages should be as compatible as possible to the previous Sun packages. > > This means that we need to install the binaries relatively to / /usr or /usr/sfw > and that there is a need to have ELF version information in libraries that are > compatiblle to the Sun version data. > > The related information can be either obtained from the mapfiles from the sfw > source consolidation or from readin the libraries itself. Although generally the BUILD_PREFIX can be set to something else, there are many places where the "/opt/csw" prefix is hardcoded: for example in patches, and in shipped example config files. I think that if you plan to adapt the sources to make the libraries backward compatible with the SFW packages, changing the compiler is probably the least of your worries. It would be cool if there was source-level collaboration. Making the same sources build in two flavors would be a challenge, a very interesting one. Maciej From pfelecan at opencsw.org Tue Jun 26 11:24:04 2012 From: pfelecan at opencsw.org (pfelecan at opencsw.org) Date: Tue, 26 Jun 2012 11:24:04 +0200 (CEST) Subject: [csw-maintainers] pkgcheck: error handling diacritical characters in paths Message-ID: Trying to package JPilot and getting the following: INFO:root:Juicing the svr4 package stream files... 0% | | ^MTraceback (most recent call last): File "/home/pfelecan/opencsw/.buildsys/v2/gar//bin/checkpkg", line 197, in main() File "/home/pfelecan/opencsw/.buildsys/v2/gar//bin/checkpkg", line 120, in main stats_list = collector.CollectStatsFromFiles(file_list, None) File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py", line 499, in CollectStatsFromFiles stats.CollectStats(force=force_unpack) File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py", line 175, in CollectStats return self._CollectStats(register_files=register_files) File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py", line 197, in _CollectStats "binaries": dir_pkg.ListBinaries(), File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/inspective_package.py", line 124, in ListBinaries files_metadata = self.GetFilesMetadata() File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/inspective_package.py", line 94, in GetFilesMetadata full_path = unicode(self.MakeAbsolutePath(file_path)) UnicodeDecodeError: 'ascii' codec can't decode byte 0xf1 in position 54: ordinal not in range(128) gmake[1]: *** [pkgcheck] Error 2 gmake[1]: Leaving directory `/home/pfelecan/opencsw/jpilot/trunk' gmake: *** [platforms] Error 2 The package contains the file: /opt/csw/share/jpilot/Ma?anaDB.pdb which raises this error. You can find the relevant files in ~pfelecan/opencsw/jpilot/trunk TIA From Joerg.Schilling at fokus.fraunhofer.de Tue Jun 26 12:00:31 2012 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 26 Jun 2012 12:00:31 +0200 Subject: [csw-maintainers] Solaris 9 and amd64 In-Reply-To: References: <1340585679-sup-6733@pinkfloyd.chass.utoronto.ca> <4fe84c24.etv/KB+XonIDAnfZ%Joerg.Schilling@fokus.fraunhofer.de> <4fe8d4d1.1vyX0WtGZuClzxv4%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <4fe9883f.qVdAsixuBqNXmEW1%Joerg.Schilling@fokus.fraunhofer.de> Maciej (Matchek) Blizi??ski wrote: > > SchilliX would need separate and slightly different packages but they could be > > compiled from the same set of sources. > > Sounds good. > > > The packages should be as compatible as possible to the previous Sun packages. > > > > This means that we need to install the binaries relatively to / /usr or /usr/sfw > > and that there is a need to have ELF version information in libraries that are > > compatiblle to the Sun version data. > > > > The related information can be either obtained from the mapfiles from the sfw > > source consolidation or from readin the libraries itself. > > Although generally the BUILD_PREFIX can be set to something else, > there are many places where the "/opt/csw" prefix is hardcoded: for > example in patches, and in shipped example config files. I think that > if you plan to adapt the sources to make the libraries backward > compatible with the SFW packages, changing the compiler is probably > the least of your worries. Then we would need to forbid such patches that introduce harcoded strings like "/opt/csw". If there is really a need to have such strings in the code, they should be "introduced" via defines from the cc command line like: cc '-DMY_STRING="/some/path"' and thus could be passed as parameters to the build system. > It would be cool if there was source-level collaboration. Making the > same sources build in two flavors would be a challenge, a very > interesting one. I would be interested in getting compiled SVr4 packages for SchilliX as there is already a lot of effort directly related to OpenSolaris and the ON code. 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 Tue Jun 26 12:08:49 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 26 Jun 2012 12:08:49 +0200 Subject: [csw-maintainers] Libraries in /opt/csw/lib In-Reply-To: <4FE48AEB.4080800@opencsw.org> References: <4FE47DD5.1000507@opencsw.org> <009DF329-6565-4573-BAA4-1534B39FA73C@opencsw.org> <4FE48AEB.4080800@opencsw.org> Message-ID: <1CC05CBB-1166-4372-B60E-5FDE6C0A7CCB@opencsw.org> Hi Ihsan, Am 22.06.2012 um 17:10 schrieb ?hsan Do?an: > On 06/22/2012 04:19 PM, Dagobert Michelsen wrote: > >>> I've updated last week my libldns1 package and I've noticed now, that >>> there are no libraries in /opt/csw/lib, but in sparv8plus and sparcv9. >>> >>> Was there recently a change with Gar? >> >> It has been some time now that we raised the build level to sparcv8+ and pentium >> due to __sync_fetch_and_add_4 reported missing on lots of builds on the lower end. > > I know, but I just noticed that there no libraries in /opt/csw/lib anymore. The problem was that sparcv8plus was added as extra ISA overriding the new default settings. I removed the resetting in r18536 and it should work now on your next rebuild. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From grzemba at contac-dt.de Tue Jun 26 12:11:08 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Tue, 26 Jun 2012 12:11:08 +0200 Subject: [csw-maintainers] why fails 'mgar fetch'? Message-ID: <7400ddb43133.4fe9a6dc@contac-dt.de> Does anybody know why fails: cgrzemba at unstable9s:~/opencsw/gthumb/trunk$ mgar fetch [===== NOW BUILDING: gthumb-2.14.4 =====] ginstall -d work/cookies/global ginstall -d work/download ginstall -d work/download/partial ==> Verifying installed package CSWxz: ok ==> Verifying installed package CSWbzip2: ok ==> Verifying installed package CSWdiffutils: ok ==> Verifying installed package CSWfindutils: ok ==> Verifying installed package CSWgawk: ok ==> Verifying installed package CSWgfile: ok ==> Verifying installed package CSWggrep: ok ==> Verifying installed package CSWgmake: ok ==> Verifying installed package CSWgsed: ok ==> Verifying installed package CSWgtar: ok ==> Verifying installed package CSWpy-cheetah: ok ==> Verifying installed package CSWpy-hachoir-core: ok ==> Verifying installed package CSWpy-hachoir-parser: ok ==> Verifying installed package CSWpy-libmagic: ok ==> Verifying installed package CSWpy-progressbar: ok ==> Verifying installed package CSWpy-sqlobject: ok ==> Verifying installed package CSWpy-yaml: ok ==> Verifying installed package CSWpython: ok ==> Verifying installed package CSWcoreutils: ok ==> Verifying installed package CSWwget: ok ==> Verifying installed package CSWgit: ok ??????? [prerequisite] complete for gthumb. ?==> Grabbing work/download/gthumb-2.14.4.tar.xz ??????? ==> Trying file://files/gthumb-2.14.4.tar.xz ??????? ==> Trying file:///home/src/gthumb-2.14.4.tar.xz (!!!) Failed to download work/download/gthumb-2.14.4.tar.xz! gmake: *** [work/download/gthumb-2.14.4.tar.xz] Error 1 -- Carsten Grzemba -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Tue Jun 26 13:17:37 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 26 Jun 2012 13:17:37 +0200 Subject: [csw-maintainers] why fails 'mgar fetch'? In-Reply-To: <7400ddb43133.4fe9a6dc@contac-dt.de> References: <7400ddb43133.4fe9a6dc@contac-dt.de> Message-ID: Hi Carsten, please commit what you have so I can have a look. Best regards -- dago Am 26.06.2012 um 12:11 schrieb Carsten Grzemba: > Does anybody know why fails: > > cgrzemba at unstable9s:~/opencsw/gthumb/trunk$ mgar fetch > [===== NOW BUILDING: gthumb-2.14.4 =====] > ginstall -d work/cookies/global > ginstall -d work/download > ginstall -d work/download/partial > ==> Verifying installed package CSWxz: ok > ==> Verifying installed package CSWbzip2: ok > ==> Verifying installed package CSWdiffutils: ok > ==> Verifying installed package CSWfindutils: ok > ==> Verifying installed package CSWgawk: ok > ==> Verifying installed package CSWgfile: ok > ==> Verifying installed package CSWggrep: ok > ==> Verifying installed package CSWgmake: ok > ==> Verifying installed package CSWgsed: ok > ==> Verifying installed package CSWgtar: ok > ==> Verifying installed package CSWpy-cheetah: ok > ==> Verifying installed package CSWpy-hachoir-core: ok > ==> Verifying installed package CSWpy-hachoir-parser: ok > ==> Verifying installed package CSWpy-libmagic: ok > ==> Verifying installed package CSWpy-progressbar: ok > ==> Verifying installed package CSWpy-sqlobject: ok > ==> Verifying installed package CSWpy-yaml: ok > ==> Verifying installed package CSWpython: ok > ==> Verifying installed package CSWcoreutils: ok > ==> Verifying installed package CSWwget: ok > ==> Verifying installed package CSWgit: ok > [prerequisite] complete for gthumb. > ==> Grabbing work/download/gthumb-2.14.4.tar.xz > ==> Trying file://files/gthumb-2.14.4.tar.xz > ==> Trying file:///home/src/gthumb-2.14.4.tar.xz > (!!!) Failed to download work/download/gthumb-2.14.4.tar.xz! > gmake: *** [work/download/gthumb-2.14.4.tar.xz] Error 1 > > > -- > Carsten Grzemba > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Tue Jun 26 13:45:56 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 26 Jun 2012 12:45:56 +0100 Subject: [csw-maintainers] pkgcheck: error handling diacritical characters in paths In-Reply-To: References: Message-ID: 2012/6/26 : > full_path = unicode(self.MakeAbsolutePath(file_path)) Try replacing this with: full_path = unicode(self.MakeAbsolutePath(file_path), 'utf-8') If this works, feel free to submit the fix. From yann at pleiades.fr.eu.org Tue Jun 26 22:06:05 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Tue, 26 Jun 2012 22:06:05 +0200 Subject: [csw-maintainers] Openssl 1.0 migration and desktop packages removal In-Reply-To: <3D3E4BCE-DD46-4C1E-89C5-54E37AF277A8@opencsw.org> References: <7400f4741ba.4fe955c2@contac-dt.de> <7490db193415.4fe971e6@contac-dt.de> <3D3E4BCE-DD46-4C1E-89C5-54E37AF277A8@opencsw.org> Message-ID: Hi Dago, 2012/6/26 Dagobert Michelsen > I never understood this policy as mandatory, more as a loose direction > what is possible > to be dropped if it is not maintained. IMHO we keep of course everything a > maintainer > actively maintains :-) > > The problem is the maintainer will probably have to maintain not only his package but also an important set of dependancies. This can be a lot of work. If we follow this direction, even as a loose direction, there will be few desktop packages so more work for the remaining package desktop maintainers. Anyway, I will simply ask if the packages impacted by the openssl migration will still be maintained. Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Tue Jun 26 22:32:54 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Tue, 26 Jun 2012 22:32:54 +0200 Subject: [csw-maintainers] Openssl 1.0 migration and desktop packages removal In-Reply-To: References: Message-ID: Hi again, Following the email from Dago, I am rather asking first if people are interested in taking over the maintenance or want to continue to actively maintain the listed packages. So: 1. claws_htmlviewer , claws_mail et libetpan These packages were maintained by Alex Moore but he is retired now. Is anyone interested in taking over the maintenance of these packages ? I propose to remove these packages from unstable if there are no volunteer. 2. ooocore James, do you want to continue to maintain this package ? 3. bzflag Dago, do you want to continue to maintain this package ? (didn't know that game btw) 4. grip and gnucash Peter, you're the current maintainer of these 2 packages. Will you continue to maintain them ? (If yes, can you answer to 5. and 6. ? :) ) 5. libgnomeprint and libgnomecups Ken Mays was the maintainer of these packages but he is retired. The only reverse dependancy seems to be gnucash. Peter, are you interested in taking over the maintenance of these packages ? 6. libgnome , libbonoboui and gnomevfs2 The reverse dependancies are gvim, gnucash, grip and gthumb. Dago, Carsten and Peter. Are you interested in taking over the maintenance of these packages ? Of course, feel free to step up if you're not cited but interested in taking over the maintenance of an orphaned package ! Thanks in advance for your answers ! Yann 2012/6/25 Yann Rouillard > Hi everyone, > > It seems there is a consensus about our focus on server softwares: > http://lists.opencsw.org/pipermail/maintainers/2012-June/016845.html > but so far only gnome stuffs have been removed. > > I wonder what we include in desktop packages: are all graphical > applications concerned ? > > I am particularly interested because the group 1 of packages to rebuild > with openssl 1.0 contains a set of desktop packages (and some of them are > not maintained anymore). > For exemple, could we remove the following packages ? > > - claws_htmlviewer , > claws_mail et libetpan > - grip > - gnucash > - ooocore > - bzflag (it's a 3D game so > rather desktop no ?) > > That would allow us to remove these libraries: > - libgnomeprint > - libgnomecups > > I am also asking the question for gthumb and gvim, because that's the two > last packages that will depend on these libraries (if the previous packages > are removed): > - libgnome > - libbonoboui > - gnomevfs2 > > Carsten Grzemba, why did you want to keep gthumb ? > > Yann > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Wed Jun 27 00:17:15 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Wed, 27 Jun 2012 00:17:15 +0200 Subject: [csw-maintainers] OpenSSL project task order In-Reply-To: <1340322326-sup-9944@pinkfloyd.chass.utoronto.ca> References: <5A063A52-E8A1-4044-AD95-0FF0B096AC31@opencsw.org> <1340199645-sup-433@pinkfloyd.chass.utoronto.ca> <1340322326-sup-9944@pinkfloyd.chass.utoronto.ca> Message-ID: Hi Ben, 2012/6/22 Ben Walton > I split the imaprt package into: libc_client2004g (old, linked against > 0.9.8), imaprt_stub (depends on 2004g) and libc_client2007f (new, > linked against 1.0.0). I should be able to release just the php5_imap > updated to a 1.0.0 dependency, no? Definitely ! What is strange is that php5_imap seems to already be linked with openssl 1.0.0 but still linked with libc_client2004g according to http://www.opencsw.org/packages/php5_imap/ But, yes, upload php5_imap linked with libc_client2007f and openssl 1.0 will definitely solve the problem. > I'm tweaking the php5 build right > now as due to the poor .so naming in c-client it was ending up > depending on the -dev package instead of the lib package...If you need > me to revert something, I can likely do that, but I wanted to clarify > the situation first. > Unless you have some deep problems with the compilation, quickly upload the new php5_imap package is indeed the best solution I think. Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Wed Jun 27 00:18:51 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Wed, 27 Jun 2012 00:18:51 +0200 Subject: [csw-maintainers] OpenSSL project task order In-Reply-To: <4FE18C73.3080602@opencsw.org> References: <5A063A52-E8A1-4044-AD95-0FF0B096AC31@opencsw.org> <4FE18C73.3080602@opencsw.org> Message-ID: Hi Juraj, Have you been able to work on courier IMAP ? I think you're entirely free to take over the package since Alex Moore is retired and no one else voluntereed. Yann 2012/6/20 Juraj Lutter > On 06/20/2012 10:36 AM, Dagobert Michelsen wrote: > > Hi Yann, > > > > you carefully splitted the tasks into different groups in > > http://wiki.opencsw.org/project-openssl > > > > Which order would you recommend? Can I talk you into taking the stab at > project > > lead and ask people to do specific things? What should I do first from > that list? > > I can have a look at Courier IMAP as I will need updated version very > soon :-) > > > > -- > Juraj Lutter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilbury at opencsw.org Wed Jun 27 00:23:46 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Wed, 27 Jun 2012 00:23:46 +0200 Subject: [csw-maintainers] OpenSSL project task order In-Reply-To: References: <5A063A52-E8A1-4044-AD95-0FF0B096AC31@opencsw.org> <4FE18C73.3080602@opencsw.org> Message-ID: <4FEA3672.1050205@opencsw.org> On 06/27/2012 12:18 AM, Yann Rouillard wrote: > Hi Juraj, > > Have you been able to work on courier IMAP ? > I think you're entirely free to take over the package since Alex Moore > is retired and no one else voluntereed. Not yet, I will spend some time with OpenCSW in next days, I've got more open tasks, like memcached, squid, ... > > Yann > > 2012/6/20 Juraj Lutter > > > On 06/20/2012 10:36 AM, Dagobert Michelsen wrote: > > Hi Yann, > > > > you carefully splitted the tasks into different groups in > > http://wiki.opencsw.org/project-openssl > > > > Which order would you recommend? Can I talk you into taking the > stab at project > > lead and ask people to do specific things? What should I do first > from that list? > > I can have a look at Courier IMAP as I will need updated version very > soon :-) > > > > -- > Juraj Lutter > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > > > > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -- Juraj Lutter From bwalton at opencsw.org Wed Jun 27 03:23:28 2012 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 26 Jun 2012 21:23:28 -0400 Subject: [csw-maintainers] OpenSSL project task order In-Reply-To: References: <5A063A52-E8A1-4044-AD95-0FF0B096AC31@opencsw.org> <1340199645-sup-433@pinkfloyd.chass.utoronto.ca> <1340322326-sup-9944@pinkfloyd.chass.utoronto.ca> Message-ID: <1340760061-sup-7758@pinkfloyd.chass.utoronto.ca> Excerpts from Yann Rouillard's message of Tue Jun 26 18:17:15 -0400 2012: > Definitely ! > What is strange is that php5_imap seems to already be linked with openssl > 1.0.0 but still linked with libc_client2004g according to > http://www.opencsw.org/packages/php5_imap/ > > But, yes, upload php5_imap linked with libc_client2007f and openssl 1.0 > will definitely solve the problem. Working on this now. It's pretty much ready to go, but I got side tracked the past few days. > > I'm tweaking the php5 build right now as due to the poor .so > > naming in c-client it was ending up depending on the -dev package > > instead of the lib package...If you need me to revert something, I > > can likely do that, but I wanted to clarify the situation first. > > > > Unless you have some deep problems with the compilation, quickly > upload the new php5_imap package is indeed the best solution I > think. Will do. It's fixed now. It just had a poor configure routine for finding the library. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Wed Jun 27 06:51:38 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 27 Jun 2012 06:51:38 +0200 Subject: [csw-maintainers] Update of libjpeg to .so.7 Message-ID: <6ABA15D5-9B94-4D16-8238-B5E3822DEDC0@opencsw.org> Hi, it just reappeared that jpeg has a similar issue as OpenSSL because we have both libjpeg.so.62 and libjpeg.so.7 leading to problems as again reported today: https://www.opencsw.org/mantis/view.php?id=4968 We should see to also clean these up, most of them could IMHO be dropped but there are a few candidates that need rebuild. I'll set up a project page today later on for the rdeps as listed here: http://www.opencsw.org/packages/libjpeg62/ Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From pfelecan at opencsw.org Wed Jun 27 09:30:59 2012 From: pfelecan at opencsw.org (pfelecan at opencsw.org) Date: Wed, 27 Jun 2012 09:30:59 +0200 (CEST) Subject: [csw-maintainers] error while uploading package cas_texhash Message-ID: Trying to upload a new iteration I get: pfelecan at login [login]:~ > csw-upload-pkg staging/build-27.Jun.2012/cas_texhash-1.48\,REV\=2012.06.27-SunOS5.9-all-CSW.pkg.gz Processing 1 file(s). Please wait. WARNING:root:http://buildfarm.opencsw.org/pkgdb/rest/srv4/e40ad51b0c57af8db7906e4542c7a34f/ -- HTTP Error 404: Not Found WARNING:root:staging/build-27.Jun.2012/cas_texhash-1.48,REV=2012.06.27-SunOS5.9-all-CSW.pkg.gz (e40ad51b0c57af8db7906e4542c7a34f) is not known to the database. INFO:root:Juicing the srv4 package stream files... Traceback (most recent call last): | File "/opt/csw/bin/pkgdb", line 696, in main() File "/opt/csw/bin/pkgdb", line 443, in main force_unpack=options.force_unpack) File "/opt/csw/lib/python/csw/package_stats.py", line 499, in CollectStatsFromFiles stats.CollectStats(force=force_unpack) File "/opt/csw/lib/python/csw/package_stats.py", line 175, in CollectStats return self._CollectStats(register_files=register_files) File "/opt/csw/lib/python/csw/package_stats.py", line 187, in _CollectStats dir_pkg = self.GetInspectivePkg() File "/opt/csw/lib/python/csw/package_stats.py", line 120, in GetInspectivePkg self.dir_format_pkg = self.srv4_pkg.GetInspectivePkg() File "/opt/csw/lib/python/csw/inspective_package.py", line 438, in GetInspectivePkg return self.GetDirFormatPkg() File "/opt/csw/lib/python/csw/package.py", line 174, in GetDirFormatPkg self.TransformToDir() File "/opt/csw/lib/python/csw/package.py", line 165, in TransformToDir unused_retcode = self.ShellCommand(args, quiet=(not self.debug)) File "/opt/csw/lib/python/csw/shell.py", line 18, in ShellCommand stderr=subprocess.PIPE) File "/opt/csw/lib/python/subprocess.py", line 623, in __init__ errread, errwrite) File "/opt/csw/lib/python/subprocess.py", line 1141, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory Traceback (most recent call last): File "/opt/csw/bin/csw-upload-pkg", line 627, in uploader.Upload() File "/opt/csw/bin/csw-upload-pkg", line 153, in Upload self._ImportMetadata(filename) File "/opt/csw/bin/csw-upload-pkg", line 137, in _ImportMetadata raise OSError("An error occurred when running %s." % args) OSError: An error occurred when running ['/opt/csw/bin/pkgdb', 'importpkg', 'staging/build-27.Jun.2012/cas_texhash-1.48,REV=2012.06.27-SunOS5.9-all-CSW.pkg.gz']. Can somebody asses this? TIA From maciej at opencsw.org Wed Jun 27 09:33:28 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 27 Jun 2012 08:33:28 +0100 Subject: [csw-maintainers] Solaris 9 and amd64 In-Reply-To: <4fe9883f.qVdAsixuBqNXmEW1%Joerg.Schilling@fokus.fraunhofer.de> References: <1340585679-sup-6733@pinkfloyd.chass.utoronto.ca> <4fe84c24.etv/KB+XonIDAnfZ%Joerg.Schilling@fokus.fraunhofer.de> <4fe8d4d1.1vyX0WtGZuClzxv4%Joerg.Schilling@fokus.fraunhofer.de> <4fe9883f.qVdAsixuBqNXmEW1%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: 2012/6/26 Joerg Schilling : > Maciej (Matchek) Blizi??ski wrote: > >> > SchilliX would need separate and slightly different packages but they could be >> > compiled from the same set of sources. >> >> Sounds good. >> >> > The packages should be as compatible as possible to the previous Sun packages. >> > >> > This means that we need to install the binaries relatively to / /usr or /usr/sfw >> > and that there is a need to have ELF version information in libraries that are >> > compatiblle to the Sun version data. >> > >> > The related information can be either obtained from the mapfiles from the sfw >> > source consolidation or from readin the libraries itself. >> >> Although generally the BUILD_PREFIX can be set to something else, >> there are many places where the "/opt/csw" prefix is hardcoded: for >> example in patches, and in shipped example config files. I think that >> if you plan to adapt the sources to make the libraries backward >> compatible with the SFW packages, changing the compiler is probably >> the least of your worries. > > Then we would need to forbid such patches that introduce harcoded strings like > "/opt/csw". > > If there is really a need to have such strings in the code, they should be > "introduced" via defines from the cc command line like: > > ? ? ? ?cc '-DMY_STRING="/some/path"' > > and thus could be passed as parameters to the build system. I suppose that someone has to start by attempting to build from GAR sources into a new tree and fix things on the way. >> It would be cool if there was source-level collaboration. Making the >> same sources build in two flavors would be a challenge, a very >> interesting one. > > I would be interested in getting compiled SVr4 packages for SchilliX as there > is already a lot of effort directly related to OpenSolaris and the ON code. I'm sure that maintainers will be able to provide guidance and reviews. Someone has to spearhead the project, though. From maciej at opencsw.org Wed Jun 27 09:40:29 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 27 Jun 2012 08:40:29 +0100 Subject: [csw-maintainers] error while uploading package cas_texhash In-Reply-To: References: Message-ID: 2012/6/27 : > Can somebody asses this? I think that there's a problem with the pkgdb installed on login - it can't import new packages. This is usually not a problem, because all the metadata of packages are imported during right after the GAR build. If you run pkgdb from the GAR sources first, the upload phase will not crash. I will see if I can fix the packaged pkgdb, in the meantime, please use the one from GAR sources. /path/to/your/pkgdb importpkg staging/build-27.Jun.2012/cas_texhash-1.48,REV=2012.06.27-SunOS5.9-all-CSW.pkg.gz I was curious, how come did the cas_texhash package escape checking prior to uploading? Maciej From Joerg.Schilling at fokus.fraunhofer.de Wed Jun 27 11:06:12 2012 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Wed, 27 Jun 2012 11:06:12 +0200 Subject: [csw-maintainers] Solaris 9 and amd64 In-Reply-To: References: <1340585679-sup-6733@pinkfloyd.chass.utoronto.ca> <4fe84c24.etv/KB+XonIDAnfZ%Joerg.Schilling@fokus.fraunhofer.de> <4fe8d4d1.1vyX0WtGZuClzxv4%Joerg.Schilling@fokus.fraunhofer.de> <4fe9883f.qVdAsixuBqNXmEW1%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <4feacd04.s0HGW+odG8pUSrA/%Joerg.Schilling@fokus.fraunhofer.de> Maciej (Matchek) Blizi??ski wrote: > > Then we would need to forbid such patches that introduce harcoded strings like > > "/opt/csw". > > > > If there is really a need to have such strings in the code, they should be > > "introduced" via defines from the cc command line like: > > > > ? ? ? ?cc '-DMY_STRING="/some/path"' > > > > and thus could be passed as parameters to the build system. > > I suppose that someone has to start by attempting to build from GAR > sources into a new tree and fix things on the way. These changes however look easier to integrate than adding support for versioned libraries. Versioned libraries on the other side are extremly important to achive binary compatibility with Oracle Solaris. 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 maciej at opencsw.org Wed Jun 27 13:48:53 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 27 Jun 2012 12:48:53 +0100 Subject: [csw-maintainers] Solaris 9 and amd64 In-Reply-To: <4feacd04.s0HGW+odG8pUSrA/%Joerg.Schilling@fokus.fraunhofer.de> References: <1340585679-sup-6733@pinkfloyd.chass.utoronto.ca> <4fe84c24.etv/KB+XonIDAnfZ%Joerg.Schilling@fokus.fraunhofer.de> <4fe8d4d1.1vyX0WtGZuClzxv4%Joerg.Schilling@fokus.fraunhofer.de> <4fe9883f.qVdAsixuBqNXmEW1%Joerg.Schilling@fokus.fraunhofer.de> <4feacd04.s0HGW+odG8pUSrA/%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: 2012/6/27 Joerg Schilling : > These changes however look easier to integrate than adding support for > versioned libraries. > > Versioned libraries on the other side are extremly important to achive binary > compatibility with Oracle Solaris. I imagine it's an involved process, because you have to model the whole history of the library by declaring versioned symbols. The companion CD (is it the one that you have in mind?) presumably did it already, but behind closed doors. I was curious whether these patches have been released as open source as part of OpenSolaris. If not, I guess they have to be written from scratch. Maciej From grzemba at contac-dt.de Wed Jun 27 14:33:18 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Wed, 27 Jun 2012 14:33:18 +0200 Subject: [csw-maintainers] Openssl 1.0 migration and desktop packages removal In-Reply-To: <7460e5871aa7.4feafd70@contac-dt.de> References: <7460e5871aa7.4feafd70@contac-dt.de> Message-ID: <7460beb265ad.4feb19ae@contac-dt.de> Am 26.06.12, schrieb Maciej (Matchek) Blizi?ski : > 2012/6/26 Carsten Grzemba : > > I use this, the gthumb contained in Solaris is very outdated, less features. > > Carsten, does gthumb actually depend on these gnome libraries? As in, > can it be rebuilt to not depend on them? The problem we want to solve > is staleness of > * libgnome, * libbonoboui * gnomevfs2. can be removed from the buildfarm; on rebuild the standard Solaris10 Packages will used which are uptodate enough (at least for gthumb). -- Carsten Grzemba -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joerg.Schilling at fokus.fraunhofer.de Wed Jun 27 18:36:26 2012 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Wed, 27 Jun 2012 18:36:26 +0200 Subject: [csw-maintainers] Solaris 9 and amd64 In-Reply-To: References: <1340585679-sup-6733@pinkfloyd.chass.utoronto.ca> <4fe84c24.etv/KB+XonIDAnfZ%Joerg.Schilling@fokus.fraunhofer.de> <4fe8d4d1.1vyX0WtGZuClzxv4%Joerg.Schilling@fokus.fraunhofer.de> <4fe9883f.qVdAsixuBqNXmEW1%Joerg.Schilling@fokus.fraunhofer.de> <4feacd04.s0HGW+odG8pUSrA/%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <4feb368a.Hm33zvmAh/EBQANq%Joerg.Schilling@fokus.fraunhofer.de> Maciej (Matchek) Blizi??ski wrote: > > Versioned libraries on the other side are extremly important to achive binary > > compatibility with Oracle Solaris. > > I imagine it's an involved process, because you have to model the > whole history of the library by declaring versioned symbols. The > companion CD (is it the one that you have in mind?) presumably did it > already, but behind closed doors. I was curious whether these patches > have been released as open source as part of OpenSolaris. If not, I > guess they have to be written from scratch. No, the sfw consolidation has been integrated into SXCE a long time ago. Here is the code that is compatible with the latest source: http://dlc.sun.com/osol/sfw/downloads/b147/ It contains all map files. 3~A From pfelecan at opencsw.org Wed Jun 27 19:48:02 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 27 Jun 2012 19:48:02 +0200 Subject: [csw-maintainers] Openssl 1.0 migration and desktop packages removal In-Reply-To: (Yann Rouillard's message of "Mon, 25 Jun 2012 21:56:55 +0200") References: Message-ID: Yann Rouillard writes: > It seems there is a consensus about our focus on server softwares: > http://lists.opencsw.org/pipermail/maintainers/2012-June/016845.html The above citation doesn't show consensus; maybe the thread? > I wonder what we include in desktop packages: are all graphical > applications concerned ? Hope that this is not the case as we would remove Emacs, XFig, &c > - grip > - gnucash Both packages are maintained, by me; a new version of grip was released last week and I hope to deliver gnucash next month. -- Peter From pfelecan at opencsw.org Wed Jun 27 19:50:14 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 27 Jun 2012 19:50:14 +0200 Subject: [csw-maintainers] Openssl 1.0 migration and desktop packages removal In-Reply-To: (Yann Rouillard's message of "Tue, 26 Jun 2012 22:32:54 +0200") References: Message-ID: Yann Rouillard writes: > 4. grip and > gnucash > > Peter, you're the current maintainer of these 2 packages. Will you continue > to maintain them ? > (If yes, can you answer to 5. and 6. ? :) ) Yes. > 5. libgnomeprint and > libgnomecups > > Ken Mays was the maintainer of these packages but he is retired. > The only reverse dependancy seems to be gnucash. > Peter, are you interested in taking over the maintenance of these packages ? I can try but not sure. > 6. libgnome , > libbonoboui > and gnomevfs2 > > The reverse dependancies are gvim, gnucash, grip and gthumb. > Dago, Carsten and Peter. Are you interested in taking over the maintenance > of these packages ? Not sure... -- Peter From pfelecan at opencsw.org Wed Jun 27 19:55:11 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 27 Jun 2012 19:55:11 +0200 Subject: [csw-maintainers] pkgcheck: error handling diacritical characters in paths In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Tue, 26 Jun 2012 12:45:56 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2012/6/26 : >> full_path = unicode(self.MakeAbsolutePath(file_path)) > > Try replacing this with: > > full_path = unicode(self.MakeAbsolutePath(file_path), 'utf-8') > > If this works, feel free to submit the fix. Modified the file in ~/opencsw/.buildys/v2/lib/inspective_package.py and obtain: File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/inspective_package.py", line 94, in GetFilesMetadata full_path = unicode(self.MakeAbsolutePath(file_path), 'utf-8') UnicodeDecodeError: 'utf8' codec can't decode byte 0xf1 in position 54: invalid continuation byte What's up doc? -- Peter From pfelecan at opencsw.org Wed Jun 27 19:59:28 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 27 Jun 2012 19:59:28 +0200 Subject: [csw-maintainers] error while uploading package cas_texhash In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Wed, 27 Jun 2012 08:40:29 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2012/6/27 : >> Can somebody asses this? > > I think that there's a problem with the pkgdb installed on login - > it can't import new packages. > > This is usually not a problem, because all the metadata of packages > are imported during right after the GAR build. If you run pkgdb from > the GAR sources first, the upload phase will not crash. > > I will see if I can fix the packaged pkgdb, in the meantime, please > use the one from GAR sources. > > /path/to/your/pkgdb importpkg > staging/build-27.Jun.2012/cas_texhash-1.48,REV=2012.06.27-SunOS5.9-all-CSW.pkg.gz > > I was curious, how come did the cas_texhash package escape checking > prior to uploading? I've done mgar package-CSWcas_texhash, i.e., only packaged the specific CAS; I think that pkgdb is invoked only when doing platforms, isn't it? When doing mgar platforms, everything works, even csw-upload-pkg on login. me thinks that there is a hole somewhere... -- Peter From maciej at opencsw.org Wed Jun 27 20:50:35 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 27 Jun 2012 19:50:35 +0100 Subject: [csw-maintainers] Openssl 1.0 migration and desktop packages removal In-Reply-To: References: Message-ID: 2012/6/27 Peter FELECAN : >> It seems there is a consensus about our focus on server softwares: >> http://lists.opencsw.org/pipermail/maintainers/2012-June/016845.html > > The above citation doesn't show consensus; maybe the thread? I would like to clarify two things - I don't know if you can show one specific thread that is a proof of the consensus. I think that there's consensus based on all the conversations here on the mailing list and on IRC. The second thing is what's the consensus about. If I understand correctly, focusing on server software means that we as a group or as the OpenCSW project will not be going out of our way to build desktop software. We will do it for things like GCC and OpenSSL, but not for Gnome. And if something stands in the way of rebuilding the server software, we'll do what's necessary to take it out of the way. When individual maintainers wish to build desktop software, great! By all means, go ahead. The problem here seems to be that the old gnome libraries are blocking progress. If the libraries are to be maintained, someone has to step up and take them on. Maciej From yann at pleiades.fr.eu.org Wed Jun 27 20:51:53 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Wed, 27 Jun 2012 20:51:53 +0200 Subject: [csw-maintainers] Openssl 1.0 migration and desktop packages removal In-Reply-To: <7460beb265ad.4feb19ae@contac-dt.de> References: <7460e5871aa7.4feafd70@contac-dt.de> <7460beb265ad.4feb19ae@contac-dt.de> Message-ID: Hi, These libraries are also used by gvim, grip and gnucash so we maybe we should wait for the opinion of Dago and Peter no ? But basically you are proposing to switch to native libraries for desktop stuff. I think we should discuss it further because: - it probably can't be a per package choice: if you use the native libraries and if we still provide the same libraries in OpenCSW for other packages, that would surely lead to some problems, - if we use native libraries, I don't think we will be guaranteed to have the same version on all versions of Solaris (that was one the advantage of providing our own libraries), so we will have to test and compile on each version (or restrict packages to a given OS version, that could make sense to provide a newer version of a software on the oldest OS). Yann 2012/6/27 Carsten Grzemba > > > Am 26.06.12, schrieb *Maciej (Matchek) Blizi?ski * : > > 2012/6/26 Carsten Grzemba : > > I use this, the gthumb contained in Solaris is very outdated, less > features. > > Carsten, does gthumb actually depend on these gnome libraries? As in, > can it be rebuilt to not depend on them? The problem we want to solve > is staleness of > > * libgnome, > * libbonoboui > * gnomevfs2. > > can be removed from the buildfarm; on rebuild the standard Solaris10 > Packages will used which are uptodate enough (at least for gthumb). > > -- > Carsten Grzemba > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Wed Jun 27 21:08:03 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Wed, 27 Jun 2012 21:08:03 +0200 Subject: [csw-maintainers] Openssl 1.0 migration and desktop packages removal In-Reply-To: References: Message-ID: Hi Peter, 2012/6/27 Peter FELECAN > > > - grip > > - gnucash > > Both packages are maintained, by me; a new version of grip was released > last week and I hope to deliver gnucash next month. > The last version of grip you uploaded depends on both openssl 0.9.8 and 1.0 according to the package depends file. However it seems to be only directly linked to openssl 1.0. Is there any reason for this ? If the openssl 0.9.8 ha in fact not useful, could you reupload the package with the openssl 0.9.8 dependancy removed ? This grip is currently dual linked at runtime because of its library dependancies. If it didn't cause any problem to the application, I will put the status of grip as ok in the migration tracking page: http://wiki.opencsw.org/project-openssl Can you confirm me that there are no problem with your last package ? Yann > > -- > Peter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Wed Jun 27 22:10:47 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 27 Jun 2012 21:10:47 +0100 Subject: [csw-maintainers] pkgcheck: error handling diacritical characters in paths In-Reply-To: References: Message-ID: 2012/6/27 Peter FELECAN : > "Maciej (Matchek) Blizi?ski" writes: > >> 2012/6/26 ?: >>> full_path = unicode(self.MakeAbsolutePath(file_path)) >> >> Try replacing this with: >> >> full_path = unicode(self.MakeAbsolutePath(file_path), 'utf-8') >> >> If this works, feel free to submit the fix. > > Modified the file in ~/opencsw/.buildys/v2/lib/inspective_package.py and > obtain: > > ?File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/inspective_package.py", line 94, in GetFilesMetadata > ? ?full_path = unicode(self.MakeAbsolutePath(file_path), 'utf-8') > UnicodeDecodeError: 'utf8' codec can't decode byte 0xf1 in position 54: invalid continuation byte > > What's up doc? Looks like the file name is not encoded in UTF-8. I'm not sure... what should checkpkg do? It has to be encoded in unicode at the end of the day, so what do we do? From maciej at opencsw.org Wed Jun 27 22:11:48 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 27 Jun 2012 21:11:48 +0100 Subject: [csw-maintainers] error while uploading package cas_texhash In-Reply-To: References: Message-ID: 2012/6/27 Peter FELECAN : > "Maciej (Matchek) Blizi?ski" writes: > >> 2012/6/27 ?: >>> Can somebody asses this? >> >> I think that there's a problem with the pkgdb installed on login - >> it can't import new packages. >> >> This is usually not a problem, because all the metadata of packages >> are imported during right after the GAR build. If you run pkgdb from >> the GAR sources first, the upload phase will not crash. >> >> I will see if I can fix the packaged pkgdb, in the meantime, please >> use the one from GAR sources. >> >> /path/to/your/pkgdb importpkg >> staging/build-27.Jun.2012/cas_texhash-1.48,REV=2012.06.27-SunOS5.9-all-CSW.pkg.gz >> >> I was curious, how come did the cas_texhash package escape checking >> prior to uploading? > > I've done mgar package-CSWcas_texhash, i.e., only packaged the specific > CAS; I think that pkgdb is invoked only when doing platforms, isn't it? > When doing mgar platforms, everything works, even csw-upload-pkg on > login. me thinks that there is a hole somewhere... Dago could confirm this, my guess is that the checkpkg stage is only invoked after all packages are built, and not after a single package. From maciej at opencsw.org Thu Jun 28 10:43:32 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 28 Jun 2012 09:43:32 +0100 Subject: [csw-maintainers] Transitive dependencies: do we add them or not? Message-ID: Suppose we have a binary foo, which needs libfoo.so.1, and only libfoo.so.1. Then we have libfoo.so.1 which needs libbar.so.2. We get: foo (in CSWfoo) ? libfoo.so.1 (in CSWlibfoo1) ? libbar.so.2 (in CSWlibbar2) My understanding is that we should, as a rule, add a dependency from CSWfoo to CSWlibfoo1, and from CSWlibfoo1 to CSWlibbar2, but not from CSWfoo to CSwlibbar2. Is this correct? From wilbury at opencsw.org Thu Jun 28 10:45:56 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Thu, 28 Jun 2012 10:45:56 +0200 Subject: [csw-maintainers] Transitive dependencies: do we add them or not? In-Reply-To: References: Message-ID: <4FEC19C4.3000401@opencsw.org> On 06/28/2012 10:43 AM, Maciej (Matchek) Blizi?ski wrote: > Suppose we have a binary foo, which needs libfoo.so.1, and only > libfoo.so.1. Then we have libfoo.so.1 which needs libbar.so.2. We get: > > foo (in CSWfoo) ? libfoo.so.1 (in CSWlibfoo1) ? libbar.so.2 (in CSWlibbar2) > > My understanding is that we should, as a rule, add a dependency from > CSWfoo to CSWlibfoo1, and from CSWlibfoo1 to CSWlibbar2, but not from > CSWfoo to CSwlibbar2. Yes. Only direct dependencies. -- Juraj Lutter From dam at opencsw.org Thu Jun 28 11:20:43 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 28 Jun 2012 11:20:43 +0200 Subject: [csw-maintainers] Transitive dependencies: do we add them or not? In-Reply-To: <4FEC19C4.3000401@opencsw.org> References: <4FEC19C4.3000401@opencsw.org> Message-ID: <95E0F098-642D-4DFD-B6EA-ADDDD7A40124@opencsw.org> Hi, Am 28.06.2012 um 10:45 schrieb Juraj Lutter: > On 06/28/2012 10:43 AM, Maciej (Matchek) Blizi?ski wrote: >> Suppose we have a binary foo, which needs libfoo.so.1, and only >> libfoo.so.1. Then we have libfoo.so.1 which needs libbar.so.2. We get: >> >> foo (in CSWfoo) ? libfoo.so.1 (in CSWlibfoo1) ? libbar.so.2 (in CSWlibbar2) >> >> My understanding is that we should, as a rule, add a dependency from >> CSWfoo to CSWlibfoo1, and from CSWlibfoo1 to CSWlibbar2, but not from >> CSWfoo to CSwlibbar2. > > Yes. Only direct dependencies. Indeed. The rationale is that libbar.so.2 provides some functionality which could be changed later on in libfoo.so.1.0.2 to libbaz.so.1. Prominent examples here are GnuTLS vs. OpenSSL and libcares vs. libadns which are both common backends but projects switch from time to time. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From bwalton at opencsw.org Thu Jun 28 14:44:14 2012 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 28 Jun 2012 08:44:14 -0400 Subject: [csw-maintainers] OpenSSL project task order In-Reply-To: <1340760061-sup-7758@pinkfloyd.chass.utoronto.ca> References: <5A063A52-E8A1-4044-AD95-0FF0B096AC31@opencsw.org> <1340199645-sup-433@pinkfloyd.chass.utoronto.ca> <1340322326-sup-9944@pinkfloyd.chass.utoronto.ca> <1340760061-sup-7758@pinkfloyd.chass.utoronto.ca> Message-ID: <1340887171-sup-2392@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Tue Jun 26 21:23:28 -0400 2012: > > What is strange is that php5_imap seems to already be linked with openssl > > 1.0.0 but still linked with libc_client2004g according to > > http://www.opencsw.org/packages/php5_imap/ > > > > But, yes, upload php5_imap linked with libc_client2007f and openssl 1.0 > > will definitely solve the problem. Ok, I moved the php5_imap and imaprt items into group1 since there was php5_curl there as well and I'd like to push them as a unit. That should be the end of my group1 items. I'll look at tackling other parts of that list from retired maintainers now and will lend a hand to anyone else that needs it for non-retired folks. I think that the claws* mail stuff and libetpan should be dropped. Nothing but claws needs libetpan. Using the solaris 10 gnome libraries is a good choice too. We can build things against them to keep our few desktop-ish things going without the burden of maintaining the whole stack. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Thu Jun 28 14:46:01 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 28 Jun 2012 14:46:01 +0200 Subject: [csw-maintainers] OpenSSL project task order In-Reply-To: <1340887171-sup-2392@pinkfloyd.chass.utoronto.ca> References: <5A063A52-E8A1-4044-AD95-0FF0B096AC31@opencsw.org> <1340199645-sup-433@pinkfloyd.chass.utoronto.ca> <1340322326-sup-9944@pinkfloyd.chass.utoronto.ca> <1340760061-sup-7758@pinkfloyd.chass.utoronto.ca> <1340887171-sup-2392@pinkfloyd.chass.utoronto.ca> Message-ID: <11A3CB60-B7F1-4AA9-A95F-FDA7A6AC1580@opencsw.org> Hi Ben, Am 28.06.2012 um 14:44 schrieb Ben Walton: > Using the solaris 10 gnome libraries is a good choice too. We can > build things against them to keep our few desktop-ish things going > without the burden of maintaining the whole stack. I am tickling the gvim base libs like libgnome, they are not hard to update. Heads up :-) Best regatrds -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From bwalton at opencsw.org Thu Jun 28 14:53:50 2012 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 28 Jun 2012 08:53:50 -0400 Subject: [csw-maintainers] OpenSSL project task order In-Reply-To: <11A3CB60-B7F1-4AA9-A95F-FDA7A6AC1580@opencsw.org> References: <5A063A52-E8A1-4044-AD95-0FF0B096AC31@opencsw.org> <1340199645-sup-433@pinkfloyd.chass.utoronto.ca> <1340322326-sup-9944@pinkfloyd.chass.utoronto.ca> <1340760061-sup-7758@pinkfloyd.chass.utoronto.ca> <1340887171-sup-2392@pinkfloyd.chass.utoronto.ca> <11A3CB60-B7F1-4AA9-A95F-FDA7A6AC1580@opencsw.org> Message-ID: <1340887943-sup-499@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Thu Jun 28 08:46:01 -0400 2012: > I am tickling the gvim base libs like libgnome, they are not hard to update. > Heads up :-) Ok. No problem. If you need cycles, let me know. It'd be nice to push group1 out the door. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Jun 28 15:28:59 2012 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 28 Jun 2012 09:28:59 -0400 Subject: [csw-maintainers] =?utf-8?q?MySQL_built_with_GCC_=E2=86=92_mysql_?= =?utf-8?q?config_vs_bindings?= In-Reply-To: References: <113DCAD0-9822-4938-993A-1EA6D4039287@opencsw.org> <1340063281-sup-9735@pinkfloyd.chass.utoronto.ca> <1340542610-sup-799@pinkfloyd.chass.utoronto.ca> Message-ID: <1340890103-sup-1124@pinkfloyd.chass.utoronto.ca> Excerpts from Jonathan Craig's message of Mon Jun 25 16:25:59 -0400 2012: > This issue also affects language packages such as perl, ruby, etc., > where end users may wish to compile libraries not supplied by > OpenCSW. With studio based packages they must establish an > environment to support this and we are unable to make this easy on > them by providing an OpenCSW packaging of studio. We can and do > provide gcc and this makes gcc a better choice for these types of > packages. In terms of user experience, I think that defaulting to the GNU compilers is definitely a win. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From yann at pleiades.fr.eu.org Thu Jun 28 22:25:26 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Thu, 28 Jun 2012 22:25:26 +0200 Subject: [csw-maintainers] OpenSSL project task order In-Reply-To: <1340887171-sup-2392@pinkfloyd.chass.utoronto.ca> References: <5A063A52-E8A1-4044-AD95-0FF0B096AC31@opencsw.org> <1340199645-sup-433@pinkfloyd.chass.utoronto.ca> <1340322326-sup-9944@pinkfloyd.chass.utoronto.ca> <1340760061-sup-7758@pinkfloyd.chass.utoronto.ca> <1340887171-sup-2392@pinkfloyd.chass.utoronto.ca> Message-ID: 2012/6/28 Ben Walton > Excerpts from Ben Walton's message of Tue Jun 26 21:23:28 -0400 2012: > [...] > That should be the end of my group1 items. I'll look at tackling > other parts of that list from retired maintainers now and will lend a > hand to anyone else that needs it for non-retired folks. > That's great Ben ! There are now only 24 packages remaining and it's likely that 9 of this 24 packages could be dropped. > I think that the claws* mail stuff and libetpan should be dropped. > Nothing but claws needs libetpan. > I am just waiting a little big longer in case someone step up. Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Thu Jun 28 22:39:30 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Thu, 28 Jun 2012 22:39:30 +0200 Subject: [csw-maintainers] OpenSSL project task order In-Reply-To: <11A3CB60-B7F1-4AA9-A95F-FDA7A6AC1580@opencsw.org> References: <5A063A52-E8A1-4044-AD95-0FF0B096AC31@opencsw.org> <1340199645-sup-433@pinkfloyd.chass.utoronto.ca> <1340322326-sup-9944@pinkfloyd.chass.utoronto.ca> <1340760061-sup-7758@pinkfloyd.chass.utoronto.ca> <1340887171-sup-2392@pinkfloyd.chass.utoronto.ca> <11A3CB60-B7F1-4AA9-A95F-FDA7A6AC1580@opencsw.org> Message-ID: Hi Dago, Thanks for stepping up ! Does this mean you're also on it for gnomevfs2 and libbonoboui ? :) I can also give some help you on writing the recipes. Yann 2012/6/28 Dagobert Michelsen > Hi Ben, > > Am 28.06.2012 um 14:44 schrieb Ben Walton: > > Using the solaris 10 gnome libraries is a good choice too. We can > > build things against them to keep our few desktop-ish things going > > without the burden of maintaining the whole stack. > > I am tickling the gvim base libs like libgnome, they are not hard to > update. > Heads up :-) > > > Best regatrds > > -- Dago > > > -- > "You don't become great by trying to be great, you become great by wanting > to do something, > and then doing it so hard that you become great in the process." - xkcd > #896 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Thu Jun 28 22:42:31 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 28 Jun 2012 22:42:31 +0200 Subject: [csw-maintainers] OpenSSL project task order In-Reply-To: References: <5A063A52-E8A1-4044-AD95-0FF0B096AC31@opencsw.org> <1340199645-sup-433@pinkfloyd.chass.utoronto.ca> <1340322326-sup-9944@pinkfloyd.chass.utoronto.ca> <1340760061-sup-7758@pinkfloyd.chass.utoronto.ca> <1340887171-sup-2392@pinkfloyd.chass.utoronto.ca> <11A3CB60-B7F1-4AA9-A95F-FDA7A6AC1580@opencsw.org> Message-ID: <62A22AB8-D026-4CB9-94D1-6FC1F8A301BC@opencsw.org> Hi Yann, Am 28.06.2012 um 22:39 schrieb Yann Rouillard: > Thanks for stepping up ! > Does this mean you're also on it for gnomevfs2 and libbonoboui ? :) > > I can also give some help you on writing the recipes. Cool! I pushed libgnome. I committed gnome-base/gnomevfs2/trunk but it has an issue with an unresolved symbol which would be great if you could have a look. libbonoboui should be easy once libgnome reaches the mirror (pushed to unstable), just 64 bit was missing, 32 bit already built fine. Best regards -- dago > > Yann > > > 2012/6/28 Dagobert Michelsen > Hi Ben, > > Am 28.06.2012 um 14:44 schrieb Ben Walton: > > Using the solaris 10 gnome libraries is a good choice too. We can > > build things against them to keep our few desktop-ish things going > > without the burden of maintaining the whole stack. > > I am tickling the gvim base libs like libgnome, they are not hard to update. > Heads up :-) > > > Best regatrds > > -- Dago > > > -- > "You don't become great by trying to be great, you become great by wanting to do something, > and then doing it so hard that you become great in the process." - xkcd #896 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Fri Jun 29 01:12:45 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Fri, 29 Jun 2012 01:12:45 +0200 Subject: [csw-maintainers] OpenSSL project task order In-Reply-To: <62A22AB8-D026-4CB9-94D1-6FC1F8A301BC@opencsw.org> References: <5A063A52-E8A1-4044-AD95-0FF0B096AC31@opencsw.org> <1340199645-sup-433@pinkfloyd.chass.utoronto.ca> <1340322326-sup-9944@pinkfloyd.chass.utoronto.ca> <1340760061-sup-7758@pinkfloyd.chass.utoronto.ca> <1340887171-sup-2392@pinkfloyd.chass.utoronto.ca> <11A3CB60-B7F1-4AA9-A95F-FDA7A6AC1580@opencsw.org> <62A22AB8-D026-4CB9-94D1-6FC1F8A301BC@opencsw.org> Message-ID: Hi Dago, 2012/6/28 Dagobert Michelsen > Hi Yann, > [...] > I committed gnome-base/gnomevfs2/trunk but it has an issue with an > unresolved symbol > which would be great if you could have a look. > Hmm that will be a difficult problem. This symbol has been removed from the samba library. The commit is here: http://gitweb.samba.org/?p=samba.git;a=commitdiff;h=d4b4bae8ded824d06ad5ab0e219f71187ee5c771 There is already a ticket opened upstream: https://bugzilla.gnome.org/show_bug.cgi?id=592341 but it won't be fixed as gnomevfs2 is not maintained anymore. We could try to 1) update the code or 2) disable samba in gnomevfs. I tried 1) after having a look at the commit and some code in other programs that were using the new function. The patch is here: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/gnome-base/gnomevfs2/trunk/files/0002-dont-use-smbc_remove_unused_server.patch I didn't have time to fully understand the libsmbclient API so any other look is welcome. The pentium-pro modulation compiles fine but at least one test fails for the amd64 modulation. I am stopping here for now. Yann > libbonoboui should be easy once libgnome > reaches the mirror (pushed to unstable), just 64 bit was missing, 32 bit > already built fine. > > > Best regards > > -- dago > > > Yann > > > 2012/6/28 Dagobert Michelsen > >> Hi Ben, >> >> Am 28.06.2012 um 14:44 schrieb Ben Walton: >> > Using the solaris 10 gnome libraries is a good choice too. We can >> > build things against them to keep our few desktop-ish things going >> > without the burden of maintaining the whole stack. >> >> I am tickling the gvim base libs like libgnome, they are not hard to >> update. >> Heads up :-) >> >> >> Best regatrds >> >> -- Dago >> >> >> -- >> "You don't become great by trying to be great, you become great by >> wanting to do something, >> and then doing it so hard that you become great in the process." - xkcd >> #896 >> >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers >> .:: This mailing list's archive is public. ::. >> > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > > > -- > "You don't become great by trying to be great, you become great by wanting > to do something, > and then doing it so hard that you become great in the process." - xkcd > #896 > > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Sat Jun 30 03:27:48 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 29 Jun 2012 21:27:48 -0400 Subject: [csw-maintainers] board elections 2012 In-Reply-To: <1340586611-sup-7400@pinkfloyd.chass.utoronto.ca> References: <1337265633-sup-8553@pinkfloyd.chass.utoronto.ca> <1339022795-sup-1395@pinkfloyd.chass.utoronto.ca> <1340586611-sup-7400@pinkfloyd.chass.utoronto.ca> Message-ID: <1341019529-sup-6831@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Sun Jun 24 21:11:56 -0400 2012: Hi All, > Ok, there are currently three nominations on the wiki[1] page. It > seems like an election by acclamation will be the way of things. > Unless there are objections, we'll form the new board this week. As an acclamation is a sub-optimal way to select the board, we'll be posting a ballot shortly to allow you to vote on the new composition of the board. If that ballot fails, we'll go back to a new nomination process...we'd need at least one more person to step forward if we're to have a vote to determine board membership. The proposed composition of the new board will be: President - Peter Felecan Secretary - Maciej Blizinski Treasurer - Ben Walton Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302