From pfelecan at opencsw.org Sat Jun 1 11:38:42 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 01 Jun 2013 11:38:42 +0200 Subject: [csw-maintainers] support for GitHub hosted repositories Message-ID: FYI, in http://gar.svn.sourceforge.net/gar/?rev=21236&view=rev I implemented the support for GitHub hosted repositories which is documented at: https://sourceforge.net/apps/trac/gar/wiki/GAR%20Variable%20Reference#DownloadSettings I'm welcoming comments and enhancement proposals. -- Peter From maciej at opencsw.org Sun Jun 2 13:15:06 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 2 Jun 2013 12:15:06 +0100 Subject: [csw-maintainers] support for GitHub hosted repositories In-Reply-To: References: Message-ID: 2013/6/1 Peter FELECAN : > FYI, in http://gar.svn.sourceforge.net/gar/?rev=21236&view=rev I > implemented the support for GitHub hosted repositories which is > documented at: > https://sourceforge.net/apps/trac/gar/wiki/GAR%20Variable%20Reference#DownloadSettings > > I'm welcoming comments and enhancement proposals. When you build a package from a github repository, is the idea that you build a specific node/commit/hash, or do you build whatever happens to be in the master branch at the moment? From pfelecan at opencsw.org Sun Jun 2 16:27:47 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 02 Jun 2013 16:27:47 +0200 Subject: [csw-maintainers] support for GitHub hosted repositories In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sun, 2 Jun 2013 12:15:06 +0100") References:

Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/6/1 Peter FELECAN : >> FYI, in http://gar.svn.sourceforge.net/gar/?rev=21236&view=rev I >> implemented the support for GitHub hosted repositories which is >> documented at: >> https://sourceforge.net/apps/trac/gar/wiki/GAR%20Variable%20Reference#DownloadSettings >> >> I'm welcoming comments and enhancement proposals. > > When you build a package from a github repository, is the idea that > you build a specific node/commit/hash, or do you build whatever > happens to be in the master branch at the moment? What's gathered/built depends on GITHUB_BRANCH variable, by default "master"; if you provide something else, as in the example given in the documentation, then that is gathered and eventually built... -- Peter From maciej at opencsw.org Sun Jun 2 16:34:58 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 2 Jun 2013 15:34:58 +0100 Subject: [csw-maintainers] support for GitHub hosted repositories In-Reply-To: References:

Message-ID: 2013/6/2 Peter FELECAN : > What's gathered/built depends on GITHUB_BRANCH variable, by default > "master"; if you provide something else, as in the example given in the > documentation, then that is gathered and eventually built... Aha, so it can be a sha1 sum as well, and you can do something like: GITHUB_BRANCH = d40fb7cc8f2b598df1225ec2c1841dbd6843c712 Then maybe the variable can be named in a fashion suggesting that you can put any identifier in there? Maciej From pfelecan at opencsw.org Sun Jun 2 16:43:28 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 02 Jun 2013 16:43:28 +0200 Subject: [csw-maintainers] support for GitHub hosted repositories In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sun, 2 Jun 2013 15:34:58 +0100") References:

Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/6/2 Peter FELECAN : >> What's gathered/built depends on GITHUB_BRANCH variable, by default >> "master"; if you provide something else, as in the example given in the >> documentation, then that is gathered and eventually built... > > Aha, so it can be a sha1 sum as well, and you can do something like: > > GITHUB_BRANCH = d40fb7cc8f2b598df1225ec2c1841dbd6843c712 > > > Then maybe the variable can be named in a fashion suggesting that you > can put any identifier in there? I don't know and, consequently not tested, something like that. My implementation is based on http://developer.github.com/v3/repos/contents/#get-archive-link and if what you shown is a valid Git reference the I suppose that it's possible and if somebody test this with success we can rename it as GITHUB_REFERENCE. -- Peter From bwalton at opencsw.org Sun Jun 2 16:54:33 2013 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 2 Jun 2013 15:54:33 +0100 Subject: [csw-maintainers] support for GitHub hosted repositories In-Reply-To: References:

Message-ID: Also note that I added generic git (git or http protocol) support a few years back. It supports arbitrary treeish targets. The downside I found was permissions when a subsequent maintainer wants to pull. I never got sons to forcing usable permissions in the garchive directory. A second downside was needing to v drive the auto tools setup every time. There are a few examples if using this support in the tree still. Hth. Thanks -Ben On Jun 2, 2013 3:43 PM, "Peter FELECAN" wrote: > "Maciej (Matchek) Blizi?ski" writes: > > > 2013/6/2 Peter FELECAN : > >> What's gathered/built depends on GITHUB_BRANCH variable, by default > >> "master"; if you provide something else, as in the example given in the > >> documentation, then that is gathered and eventually built... > > > > Aha, so it can be a sha1 sum as well, and you can do something like: > > > > GITHUB_BRANCH = d40fb7cc8f2b598df1225ec2c1841dbd6843c712 > > > > > > Then maybe the variable can be named in a fashion suggesting that you > > can put any identifier in there? > > I don't know and, consequently not tested, something like that. My > implementation is based on > http://developer.github.com/v3/repos/contents/#get-archive-link and if > what you shown is a valid Git reference the I suppose that it's > possible and if somebody test this with success we can rename it as > GITHUB_REFERENCE. > -- > 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 rmottola at opencsw.org Mon Jun 3 01:15:17 2013 From: rmottola at opencsw.org (Riccardo Mottola) Date: Mon, 03 Jun 2013 01:15:17 +0200 Subject: [csw-maintainers] emacs missing library / relocation error Message-ID: <51ABD205.50201@opencsw.org> Hi list, after doing pkgutil --upgrade, emacs stopped working: bash-3.2$ ld.so.1: emacs-24.3-gtk: fatal: libm17n-flt.so.0: open failed: No such file or directory ld.so.1: emacs-24.3-gtk: fatal: relocation error: file /opt/csw/bin/emacs-24.3-gtk: symbol mflt_enable_new_feature: referenced symbol not found this is on Solaris 10 Riccardo From pfelecan at opencsw.org Mon Jun 3 09:27:43 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 03 Jun 2013 09:27:43 +0200 Subject: [csw-maintainers] emacs missing library / relocation error In-Reply-To: <51ABD205.50201@opencsw.org> (Riccardo Mottola's message of "Mon, 03 Jun 2013 01:15:17 +0200") References: <51ABD205.50201@opencsw.org> Message-ID: Riccardo Mottola writes: > Hi list, > > after doing pkgutil --upgrade, emacs stopped working: > > bash-3.2$ ld.so.1: emacs-24.3-gtk: fatal: libm17n-flt.so.0: open > failed: No such file or directory > ld.so.1: emacs-24.3-gtk: fatal: relocation error: file > /opt/csw/bin/emacs-24.3-gtk: symbol mflt_enable_new_feature: > referenced symbol not found > > > this is on Solaris 10 We use mantis for this kind of report. After that, as the maintainer for Emacs, I'll analyze the issue. -- Peter From pfelecan at opencsw.org Mon Jun 3 10:17:20 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 03 Jun 2013 10:17:20 +0200 Subject: [csw-maintainers] emacs missing library / relocation error In-Reply-To: <51ABD205.50201@opencsw.org> (Riccardo Mottola's message of "Mon, 03 Jun 2013 01:15:17 +0200") References: <51ABD205.50201@opencsw.org> Message-ID: Riccardo Mottola writes: > after doing pkgutil --upgrade, emacs stopped working: > > bash-3.2$ ld.so.1: emacs-24.3-gtk: fatal: libm17n-flt.so.0: open > failed: No such file or directory > ld.so.1: emacs-24.3-gtk: fatal: relocation error: file > /opt/csw/bin/emacs-24.3-gtk: symbol mflt_enable_new_feature: > referenced symbol not found CSWemacs-gtk depends on CSWlibm17n-utils which depends on CSWlibm17n-flt0 which contains /opt/csw/lib/libm17n-flt.so.0 Consequently, the error is in the installation/upgrade process for which I don't have enough information do analyze further. Anyhow, as said in the sibling message, a Mantis report is required to go further. -- Peter From pfelecan at opencsw.org Mon Jun 3 10:52:09 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 03 Jun 2013 10:52:09 +0200 Subject: [csw-maintainers] support for GitHub hosted repositories In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sun, 2 Jun 2013 15:34:58 +0100") References:

Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/6/2 Peter FELECAN : >> What's gathered/built depends on GITHUB_BRANCH variable, by default >> "master"; if you provide something else, as in the example given in the >> documentation, then that is gathered and eventually built... > > Aha, so it can be a sha1 sum as well, and you can do something like: > > GITHUB_BRANCH = d40fb7cc8f2b598df1225ec2c1841dbd6843c712 > > > Then maybe the variable can be named in a fashion suggesting that you > can put any identifier in there? I tested using a commit identifier similar to what you show above and it works. I made some tweaks to gar and changed the variable's name to GITHUB_REFERENCE. -- Peter From pfelecan at opencsw.org Mon Jun 3 10:54:49 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 03 Jun 2013 10:54:49 +0200 Subject: [csw-maintainers] support for GitHub hosted repositories In-Reply-To: (Ben Walton's message of "Sun, 2 Jun 2013 15:54:33 +0100") References:

Message-ID: Ben Walton writes: > Also note that I added generic git (git or http protocol) support a few > years back. It supports arbitrary treeish targets. > > The downside I found was permissions when a subsequent maintainer wants to > pull. I never got sons to forcing usable permissions in the garchive > directory. A second downside was needing to v drive the auto tools setup > every time. > > There are a few examples if using this support in the tree still. I have seen that. However, what I implemented is downloading tarballs fro GitHub and that has less issues even tough the autotools part can be necessary which I don't see as an issue but a feature... -- Peter From bwalton at opencsw.org Mon Jun 3 12:48:40 2013 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 3 Jun 2013 11:48:40 +0100 Subject: [csw-maintainers] support for GitHub hosted repositories In-Reply-To: References:

Message-ID: Cool. That is a good feature then! Thanks -Ben On Jun 3, 2013 9:55 AM, "Peter FELECAN" wrote: > Ben Walton writes: > > > Also note that I added generic git (git or http protocol) support a few > > years back. It supports arbitrary treeish targets. > > > > The downside I found was permissions when a subsequent maintainer wants > to > > pull. I never got sons to forcing usable permissions in the garchive > > directory. A second downside was needing to v drive the auto tools setup > > every time. > > > > There are a few examples if using this support in the tree still. > > I have seen that. However, what I implemented is downloading tarballs > fro GitHub and that has less issues even tough the autotools part can be > necessary which I don't see as an issue but a feature... > -- > 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 slowfranklin at opencsw.org Mon Jun 3 18:21:02 2013 From: slowfranklin at opencsw.org (slowfranklin) Date: Mon, 3 Jun 2013 18:21:02 +0200 Subject: [csw-maintainers] glib2 updates In-Reply-To: <20130527150905.GA9436@bender.opencsw.org> References: <55A7B138-94BA-4920-9BB3-57E43F4A9CE1@opencsw.org> <20130527150905.GA9436@bender.opencsw.org> Message-ID: <34CD2E71-34D0-4BC7-8EC1-29C72D5A2780@opencsw.org> Hi Rafael Am 27.05.2013 um 17:09 schrieb Rafael Ostertag : > Hi guys > > On Mon, May 27, 2013 at 10:56:34AM +0200, slowfranklin wrote: >> Hey Rafael, >> >> Laurent Blume and myself have committed several changes to the glib2 recipe. Don't remember off-hand what Laurent's changes are about, but my commits add Solaris 11 specific packages in order to have a glib2 with FEN support on Solaris 11. >> >> Can you take a look at it and release updates packages? > > Just started > > mgar platforms > > will let you know of the outcome. any progress so far? Don't mean to push you, but I'm eagerly waiting for the glib/s11 packages so I can finally finish my work on the Tracker package. Thanks! -Ralph From laurent at opencsw.org Mon Jun 3 20:13:03 2013 From: laurent at opencsw.org (Laurent Blume) Date: Mon, 03 Jun 2013 20:13:03 +0200 Subject: [csw-maintainers] glib2 updates In-Reply-To: <34CD2E71-34D0-4BC7-8EC1-29C72D5A2780@opencsw.org> References: <55A7B138-94BA-4920-9BB3-57E43F4A9CE1@opencsw.org> <20130527150905.GA9436@bender.opencsw.org> <34CD2E71-34D0-4BC7-8EC1-29C72D5A2780@opencsw.org> Message-ID: <51ACDCAF.3030708@opencsw.org> As a sidenote, I've found a workaround for my gesttings segfault issue: $ gsettings list-schemas Segmentation Fault (core dumped) If I just add an empty file, it stops: # touch "/opt/csw/share/glib-2.0/schemas/gschemas.compiled" $ gsettings list-schemas I have no idea why there's no .gschema.xml file that would be compiled into it. Maybe because they came in later GNOME versions. But that's good enough for now. The question is, is it worth creating that file inside the package? Postinstall script, if it doesn't exist, touch it? Laurent On 2013-06-03 6:21 PM, slowfranklin wrote: > Hi Rafael > > Am 27.05.2013 um 17:09 schrieb Rafael Ostertag : > >> Hi guys >> >> On Mon, May 27, 2013 at 10:56:34AM +0200, slowfranklin wrote: >>> Hey Rafael, >>> >>> Laurent Blume and myself have committed several changes to the glib2 recipe. Don't remember off-hand what Laurent's changes are about, but my commits add Solaris 11 specific packages in order to have a glib2 with FEN support on Solaris 11. >>> >>> Can you take a look at it and release updates packages? >> >> Just started >> >> mgar platforms >> >> will let you know of the outcome. > > any progress so far? Don't mean to push you, but I'm eagerly waiting for the glib/s11 packages so I can finally finish my work on the Tracker package. > > Thanks! > -Ralph > From slowfranklin at opencsw.org Wed Jun 5 10:11:18 2013 From: slowfranklin at opencsw.org (slowfranklin) Date: Wed, 5 Jun 2013 10:11:18 +0200 Subject: [csw-maintainers] Maintainer and Uploader Info In-Reply-To: References: <6D4996B8-BB29-4E60-8E03-79C5940B0D92@opencsw.org> Message-ID: <873FA4B5-4AE5-4F0F-8FA3-A1BE1C49400E@opencsw.org> Hey Am 28.05.2013 um 18:15 schrieb Maciej (Matchek) Blizi?ski : > 2013/5/24 slowfranklin >> just noticed that the packages I've uploaded are missing proper maintainer and uploader info, e.g. >> >> http://www.opencsw.org/package/netatalk/ >> http://www.opencsw.org/qa/package/netatalk/ > > There's an additional manual step we currently have to take to put > maintainer's full name in the database. I've just done that. It should > be updated in the next iteration. Thanks! -slow From dam at opencsw.org Wed Jun 5 15:47:53 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 5 Jun 2013 15:47:53 +0200 Subject: [csw-maintainers] Update of Ghostscript In-Reply-To: References: <4E9D255A-E09D-41D3-8203-C6D6F596C841@opencsw.org> Message-ID: <84A0AC6A-1151-40B1-9EAE-7B845C13F420@opencsw.org> Hi Peter, Am 29.05.2013 um 16:55 schrieb Peter FELECAN : > Dagobert Michelsen writes: >> I have updated ghostscript to the latest 9.07. However, this goes with bumping libgs from >> libgs.so.8 to libgs.so.9 which are used by a couple of packages that would need rebuilding. >> I am not sure about how libgs.so interacts with other files like printer drivers between >> 8 and 9, probably someone can help me out on this? The updated packages are available at >> http://buildfarm.opencsw.org/experimental.html#ghostscript >> for testing. Additionally, the final packages would need to include CSWlibgs8 for libgs.so.8 >> being required by a couple of packages including texlive which will probably not be rebuilt >> because of some minor dependency change :-) > > The maintainer of TeXLive greatly appreciate this! Sometime, in the > future, I'll rebuild it and use the new library? I have made updated packages with legacy dependencies of CSWgs to CSWlibgs8 which should allow continuing use of existing software: http://buildfarm.opencsw.org/experimental.html#ghostscript Peter, would you be so kind verifying texlive against it as it is the most complex package? 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 5 17:59:45 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 05 Jun 2013 17:59:45 +0200 Subject: [csw-maintainers] Update of Ghostscript In-Reply-To: <84A0AC6A-1151-40B1-9EAE-7B845C13F420@opencsw.org> (Dagobert Michelsen's message of "Wed, 5 Jun 2013 15:47:53 +0200") References: <4E9D255A-E09D-41D3-8203-C6D6F596C841@opencsw.org> <84A0AC6A-1151-40B1-9EAE-7B845C13F420@opencsw.org> Message-ID: Dagobert Michelsen writes: > Hi Peter, > > Am 29.05.2013 um 16:55 schrieb Peter FELECAN : >> Dagobert Michelsen writes: >>> I have updated ghostscript to the latest 9.07. However, this goes with bumping libgs from >>> libgs.so.8 to libgs.so.9 which are used by a couple of packages that would need rebuilding. >>> I am not sure about how libgs.so interacts with other files like printer drivers between >>> 8 and 9, probably someone can help me out on this? The updated packages are available at >>> http://buildfarm.opencsw.org/experimental.html#ghostscript >>> for testing. Additionally, the final packages would need to include CSWlibgs8 for libgs.so.8 >>> being required by a couple of packages including texlive which will probably not be rebuilt >>> because of some minor dependency change :-) >> >> The maintainer of TeXLive greatly appreciate this! Sometime, in the >> future, I'll rebuild it and use the new library? > > I have made updated packages with legacy dependencies of CSWgs to CSWlibgs8 which > should allow continuing use of existing software: > http://buildfarm.opencsw.org/experimental.html#ghostscript > > Peter, would you be so kind verifying texlive against it as it is the most complex package? Tested and works for me. -- Peter From dam at opencsw.org Thu Jun 6 14:11:29 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 6 Jun 2013 14:11:29 +0200 Subject: [csw-maintainers] Update of Ghostscript In-Reply-To: References: <4E9D255A-E09D-41D3-8203-C6D6F596C841@opencsw.org> <84A0AC6A-1151-40B1-9EAE-7B845C13F420@opencsw.org> Message-ID: <5084A619-F4CA-4D24-A7A7-4ED750500D3D@opencsw.org> Hi folks, Am 05.06.2013 um 17:59 schrieb Peter FELECAN : > Dagobert Michelsen writes: >> Am 29.05.2013 um 16:55 schrieb Peter FELECAN : >>> Dagobert Michelsen writes: >>>> I have updated ghostscript to the latest 9.07. However, this goes with bumping libgs from >>>> libgs.so.8 to libgs.so.9 which are used by a couple of packages that would need rebuilding. >>>> I am not sure about how libgs.so interacts with other files like printer drivers between >>>> 8 and 9, probably someone can help me out on this? The updated packages are available at >>>> http://buildfarm.opencsw.org/experimental.html#ghostscript >>>> for testing. Additionally, the final packages would need to include CSWlibgs8 for libgs.so.8 >>>> being required by a couple of packages including texlive which will probably not be rebuilt >>>> because of some minor dependency change :-) >>> >>> The maintainer of TeXLive greatly appreciate this! Sometime, in the >>> future, I'll rebuild it and use the new library? >> >> I have made updated packages with legacy dependencies of CSWgs to CSWlibgs8 which >> should allow continuing use of existing software: >> http://buildfarm.opencsw.org/experimental.html#ghostscript >> >> Peter, would you be so kind verifying texlive against it as it is the most complex package? > > Tested and works for me. Ok, I have now pushed a new ghostscript 9.07,REV=2013.06.06. There have been the following changes to the existing package: - The package is now called CSWghostscript instead of CSWgs - The existing CSWgs still depends on CSWlibgs8 until all programs have been rebuilt - The new CSWghostscript uses CSWlibgs9 and there is now CSWghostscript-dev - The CUPS filters have been put into a separate package CSWghostscript-filters All known bugs have been addressed which include #3651 Please provide 64 bit version #4551 Please upgrade to 9.00 #4704 Documentation reference incorrect in -help page output #4913 pstopxl: Solaris /bin/sh cannot eval $( ), sed has not option -r If you encounter anything suspicious just let me know. 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 Thu Jun 6 14:15:25 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 6 Jun 2013 14:15:25 +0200 Subject: [csw-maintainers] New package for Erlang R16B Message-ID: Hi folks, I just finished an updated package for Erlang R16B. It features full 32/64 bit with isaexec. As my erlang skills are a bit rusty it would be nice if someone with more skills could have a look if I everything is in good shape. Packages are available from http://buildfarm.opencsw.org/experimental.html#erlang 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 Sun Jun 9 00:32:59 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 8 Jun 2013 23:32:59 +0100 Subject: [csw-maintainers] Inspecting package metadata using curl - made easier Message-ID: I've been really missing the display of package metadata in pkgdb on the buildfarm website. I couldn't put them on the site because of the amount of data, but I just added a generated copy&paste-ready shell line which displays package metadata. For instance under this address: http://buildfarm.opencsw.org/pkgdb/srv4/1643972067f15dc105328a5b67ed19a2/ ...there's a curl invocation which will download the data, prettify and display them. If you're interested in viewing your package's metadata, calculate its md5 sum and use it in the URL. You can also view recently built packages under this address: http://buildfarm.opencsw.org/pkgdb/srv4/ Maciej From laurent at opencsw.org Tue Jun 11 20:55:26 2013 From: laurent at opencsw.org (Laurent Blume) Date: Tue, 11 Jun 2013 20:55:26 +0200 Subject: [csw-maintainers] C++ ABIs are fun (not) Message-ID: <51B7729E.70604@opencsw.org> Hello all, I'm a bit in a tie because of C++ ABI issue. I'm trying t o build the scummvm-tools. They use wxwidget, which is a C++ library. Only g++ is officially supported. That can't work, because wxwidget is built with Studio. So I tinkered a little, and it builds reasonably well with Studio, until this: $ CC -library=iostream -library=rwtools7 -g -DHAVE_CONFIG_H -DSOLARIS -DSYSTEM_NOT_SUPPORTING_D_TYPE -DPOSIX -I. -I. -c scummvm-tools-cli.cpp -o scummvm-tools-cli.o "scummvm-tools-cli.cpp", line 43: Error: Could not find a match for std::deque::deque(char**, char**) needed in ToolsCLI::run(int, char**). 1 Error(s) detected. Basically, it appears to be using a constructor that's not supported on Studio. However, I've found out that this bit builds when adding -library=stlport4. But that doesn't help much, because it means that all dependencies must be built with that too, so it's practically the same problem as the GCC incompatibility. At this point, I wonder what's the best path? Have a special GCC-built version of the lib (messy)? Try to get upstream change their code (doubtful)? Give it up already and get a drink? Thanks for any insight, Laurent From jh at opencsw.org Wed Jun 12 07:03:08 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Wed, 12 Jun 2013 07:03:08 +0200 Subject: [csw-maintainers] C++ ABIs are fun (not) In-Reply-To: <51B7729E.70604@opencsw.org> References: <51B7729E.70604@opencsw.org> Message-ID: <51B8010C.3060008@opencsw.org> Hi, Am 11.06.13 20:55, schrieb Laurent Blume: > Hello all, > > I'm a bit in a tie because of C++ ABI issue. > > I'm trying t o build the scummvm-tools. They use wxwidget, which is a > C++ library. > Only g++ is officially supported. That can't work, because wxwidget is > built with Studio. > So I tinkered a little, and it builds reasonably well with Studio, until > this: > > > $ CC -library=iostream -library=rwtools7 -g -DHAVE_CONFIG_H -DSOLARIS > -DSYSTEM_NOT_SUPPORTING_D_TYPE -DPOSIX -I. -I. -c scummvm-tools-cli.cpp > -o scummvm-tools-cli.o > "scummvm-tools-cli.cpp", line 43: Error: Could not find a match for > std::deque::deque(char**, char**) needed in > ToolsCLI::run(int, char**). > 1 Error(s) detected. > > > Basically, it appears to be using a constructor that's not supported on > Studio. > > However, I've found out that this bit builds when adding > -library=stlport4. But that doesn't help much, because it means that all > dependencies must be built with that too, so it's practically the same > problem as the GCC incompatibility. > > > At this point, I wonder what's the best path? Have a special GCC-built > version of the lib (messy)? Try to get upstream change their code > (doubtful)? Give it up already and get a drink? The plan for C++ stuff iirc was to switch to gcc anyway. Since you build a new wxwidget anyway I would should rebuild it with gcc. Greetings Jan From laurent at opencsw.org Wed Jun 12 09:58:06 2013 From: laurent at opencsw.org (Laurent Blume) Date: Wed, 12 Jun 2013 09:58:06 +0200 Subject: [csw-maintainers] C++ ABIs are fun (not) In-Reply-To: <51B8010C.3060008@opencsw.org> References: <51B7729E.70604@opencsw.org> <51B8010C.3060008@opencsw.org> Message-ID: <51B82A0E.9020602@opencsw.org> On 12/06/13 07:03, Jan Holzhueter wrote: > The plan for C++ stuff iirc was to switch to gcc anyway. Since you build > a new wxwidget anyway I would should rebuild it with gcc. I'm not against, not much in favour either: that will break all dependencies. Switching to g++ looks like a huge task, since everything touched should be repushed at the same time. And GCC has a poor track record of keeping ABI compatibility on Solaris, particularly on Sparc, so it's far from being a warranty there won't be the same issue down the path later. I noticed that Studio 12.3 now has a g++ compatibility mode, but only on x86. If that were extended to Sparc, it'd make it much more attractive as a de facto standard ABI. For the concern at hand, I did get help from upstream (they're cool :-) and I could get all to build. Laurent From slowfranklin at opencsw.org Wed Jun 12 11:11:23 2013 From: slowfranklin at opencsw.org (slowfranklin) Date: Wed, 12 Jun 2013 11:11:23 +0200 Subject: [csw-maintainers] C++ ABIs are fun (not) In-Reply-To: <51B82A0E.9020602@opencsw.org> References: <51B7729E.70604@opencsw.org> <51B8010C.3060008@opencsw.org> <51B82A0E.9020602@opencsw.org> Message-ID: <86B23951-66BE-40CF-AA2A-85718472FB75@opencsw.org> Hey Laurent! Am 12.06.2013 um 09:58 schrieb Laurent Blume : > On 12/06/13 07:03, Jan Holzhueter wrote: >> The plan for C++ stuff iirc was to switch to gcc anyway. Since you build >> a new wxwidget anyway I would should rebuild it with gcc. > > I'm not against, not much in favour either: that will break all dependencies. > Switching to g++ looks like a huge task, since everything touched should be repushed at the same time. > And GCC has a poor track record of keeping ABI compatibility on Solaris, particularly on Sparc, so it's far from being a warranty there won't be the same issue down the path later. > > I noticed that Studio 12.3 now has a g++ compatibility mode, but only on x86. If that were extended to Sparc, it'd make it much more attractive as a de facto standard ABI. > > For the concern at hand, I did get help from upstream (they're cool :-) and I could get all to build. how? -slow From Joerg.Schilling at fokus.fraunhofer.de Wed Jun 12 11:27:25 2013 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Wed, 12 Jun 2013 11:27:25 +0200 Subject: [csw-maintainers] C++ ABIs are fun (not) In-Reply-To: <86B23951-66BE-40CF-AA2A-85718472FB75@opencsw.org> References: <51B7729E.70604@opencsw.org> <51B8010C.3060008@opencsw.org> <51B82A0E.9020602@opencsw.org> <86B23951-66BE-40CF-AA2A-85718472FB75@opencsw.org> Message-ID: <51b83efd.yDaaAgTrwhTRb47G%Joerg.Schilling@fokus.fraunhofer.de> slowfranklin wrote: > > I noticed that Studio 12.3 now has a g++ compatibility mode, but only on x86. If that were extended to Sparc, it'd make it much more attractive as a de facto standard ABI. > > > > For the concern at hand, I did get help from upstream (they're cool :-) and I could get all to build. > > how? Wasn't this something you could get from the Linux version of Sun Studio? 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 laurent at opencsw.org Wed Jun 12 11:30:38 2013 From: laurent at opencsw.org (Laurent Blume) Date: Wed, 12 Jun 2013 11:30:38 +0200 Subject: [csw-maintainers] C++ ABIs are fun (not) In-Reply-To: <86B23951-66BE-40CF-AA2A-85718472FB75@opencsw.org> References: <51B7729E.70604@opencsw.org> <51B8010C.3060008@opencsw.org> <51B82A0E.9020602@opencsw.org> <86B23951-66BE-40CF-AA2A-85718472FB75@opencsw.org> Message-ID: <51B83FBE.1010501@opencsw.org> On 12/06/13 11:11, slowfranklin wrote: > how? I asked politely on #scummvm and I was provided with a simple alternative that works with Studio. I'm going to provide them some patches back. Overall, it was an easy build, more than I expected, only a couple of outstanding errors. Laurent From laurent at opencsw.org Wed Jun 12 11:40:03 2013 From: laurent at opencsw.org (Laurent Blume) Date: Wed, 12 Jun 2013 11:40:03 +0200 Subject: [csw-maintainers] C++ ABIs are fun (not) In-Reply-To: <51b83efd.yDaaAgTrwhTRb47G%Joerg.Schilling@fokus.fraunhofer.de> References: <51B7729E.70604@opencsw.org> <51B8010C.3060008@opencsw.org> <51B82A0E.9020602@opencsw.org> <86B23951-66BE-40CF-AA2A-85718472FB75@opencsw.org> <51b83efd.yDaaAgTrwhTRb47G%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <51B841F3.5040608@opencsw.org> On 12/06/13 11:27, Joerg Schilling wrote: > Wasn't this something you could get from the Linux version of Sun Studio? Ah, if talking about g++ ABI compatibility, it is available for Studio x86, both Solaris and Linux. Too bad they didn't add it for Sparc. http://docs.oracle.com/cd/E24457_01/html/E21991/bkana.html#bkanr Laurent From laurent at opencsw.org Wed Jun 12 20:22:17 2013 From: laurent at opencsw.org (Laurent Blume) Date: Wed, 12 Jun 2013 20:22:17 +0200 Subject: [csw-maintainers] C++ ABIs are fun (not) In-Reply-To: <51B841F3.5040608@opencsw.org> References: <51B7729E.70604@opencsw.org> <51B8010C.3060008@opencsw.org> <51B82A0E.9020602@opencsw.org> <86B23951-66BE-40CF-AA2A-85718472FB75@opencsw.org> <51b83efd.yDaaAgTrwhTRb47G%Joerg.Schilling@fokus.fraunhofer.de> <51B841F3.5040608@opencsw.org> Message-ID: <51B8BC59.90704@opencsw.org> On 2013-06-12 11:40 AM, Laurent Blume wrote: > On 12/06/13 11:27, Joerg Schilling wrote: >> Wasn't this something you could get from the Linux version of Sun Studio? > > Ah, if talking about g++ ABI compatibility, it is available for Studio > x86, both Solaris and Linux. Too bad they didn't add it for Sparc. > > http://docs.oracle.com/cd/E24457_01/html/E21991/bkana.html#bkanr And I've heard that the next Studio is planned to have the g++ ABI compatibility mode for Solaris sparc as well. So standardizing on that will make a lot of sense, building with either Studio or GCC. The plan to change ABI will be an interesting one to pull up, though. Laurent From pfelecan at opencsw.org Thu Jun 13 09:17:56 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 13 Jun 2013 09:17:56 +0200 Subject: [csw-maintainers] C++ ABIs are fun (not) In-Reply-To: <51B8BC59.90704@opencsw.org> (Laurent Blume's message of "Wed, 12 Jun 2013 20:22:17 +0200") References: <51B7729E.70604@opencsw.org> <51B8010C.3060008@opencsw.org> <51B82A0E.9020602@opencsw.org> <86B23951-66BE-40CF-AA2A-85718472FB75@opencsw.org> <51b83efd.yDaaAgTrwhTRb47G%Joerg.Schilling@fokus.fraunhofer.de> <51B841F3.5040608@opencsw.org> <51B8BC59.90704@opencsw.org> Message-ID: Laurent Blume writes: > The plan to change ABI will be an interesting one to pull up, though. The decision to standardize on GNU C++ ABI is already taken and underway. The decision to not transit wxwidgets to it is temporary, i.e., work force availability. I do not remember when GNU C++ ABI changed last time but now we can consider it quite stable isn't it? -- Peter From laurent at opencsw.org Thu Jun 13 10:38:06 2013 From: laurent at opencsw.org (Laurent Blume) Date: Thu, 13 Jun 2013 10:38:06 +0200 Subject: [csw-maintainers] C++ ABIs are fun (not) In-Reply-To: References: <51B7729E.70604@opencsw.org> <51B8010C.3060008@opencsw.org> <51B82A0E.9020602@opencsw.org> <86B23951-66BE-40CF-AA2A-85718472FB75@opencsw.org> <51b83efd.yDaaAgTrwhTRb47G%Joerg.Schilling@fokus.fraunhofer.de> <51B841F3.5040608@opencsw.org> <51B8BC59.90704@opencsw.org> Message-ID: <51B984EE.6080401@opencsw.org> On 13/06/13 09:17, Peter FELECAN wrote: > The decision to standardize on GNU C++ ABI is already taken and > underway. > > The decision to not transit wxwidgets to it is temporary, i.e., work > force availability. > > I do not remember when GNU C++ ABI changed last time but now we can > consider it quite stable isn't it? At least Oracle does, which is a good sign, I guess. Laurent From dam at opencsw.org Thu Jun 13 12:54:24 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 13 Jun 2013 12:54:24 +0200 Subject: [csw-maintainers] Issue with checkpkg Message-ID: <3A8319F6-75FC-4CAC-8A81-DB7D761E2F52@opencsw.org> Hi folks, I am currently trying with Joerg to roll a new set of his packages like star, snake and cdrtools but get an error on checkpkg that some output can not be parsed. Notably these packages have not been built with GAR as Joerg uses his cross-platform build system to make package for all architectures at once, so there may be some other flags to parse than in our normal case. Nonetheless I would think making checkpkg more flexible and not bail out would be a good thing: > dam at login [login]:/home/joerg/newpackages > ls -l /home/dam/bin/checkpkg > lrwxrwxrwx 1 dam csw 27 Mrz 28 2011 /home/dam/bin/checkpkg -> ../mgar/gar/v2/bin/checkpkg > dam at login [login]:/home/joerg/newpackages > checkpkg --catalog-architecture sparc --os-release SunOS5.9 *sparc*.pkg.gz > INFO:root:Juicing the svr4 package stream files... > Traceback (most recent call last): | > File "/home/dam/bin/checkpkg", line 211, in > main() > File "/home/dam/bin/checkpkg", line 120, in main > stats_list = collector.CollectStatsFromFiles(file_list, None) > File "/home/dam/mgar/gar/v2/lib/python/package_stats.py", line 527, in CollectStatsFromFiles > stats.CollectStats(force=force_unpack) > File "/home/dam/mgar/gar/v2/lib/python/package_stats.py", line 184, in CollectStats > return self._CollectStats(register_files=register_files) > File "/home/dam/mgar/gar/v2/lib/python/package_stats.py", line 224, in _CollectStats > "ldd_info": dir_pkg.GetLddMinusRlines(), > File "/home/dam/mgar/gar/v2/lib/python/inspective_package.py", line 394, in GetLddMinusRlines > result = self._ParseLddDashRline(line, binary_abspath) > File "/home/dam/mgar/gar/v2/lib/python/inspective_package.py", line 573, in _ParseLddDashRline > % (repr(line), common_re)) > package.StdoutSyntaxError: Could not parse ' nicht referenziertes Objekt=/lib/libnsl.so.1; nicht verwendete Abh\xc3\xa4ngigkeit von /var/tmp/pkg_mQb_eN/CSWcdrtools/reloc/bin/isovfy' with (^\t(?P\S+)\s+=>\s+(?P\S+)|^\tsymbol not found:\s(?P\S+)\s+$(?P\S+)$|^\t(?P\S+)$|^\t(?P\S+) $(?P\S+)$ =>\t $version not found$|^\trelocation \S+ symbol: (?P\S+): file (?P\S+): relocation bound to a symbol with STV_PROTECTED visibility$|^\trelocation \S+ sizes differ: (?P\S+)$|^\t\t$file (?P\S+) size=(?P0x\w+); file (?P\S+) size=(?P0x\w+)$$|^\t\t(?P\S+) size used; possible insufficient data copied$|^\s*unreferenced object=(?P