From jgoerzen at opencsw.org Wed Sep 3 04:25:57 2014 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Tue, 02 Sep 2014 19:25:57 -0700 Subject: cmake compile error In-Reply-To: References: Message-ID: <54067C35.2030506@opencsw.org> On 08/04/14 01:56, rupert THURNER wrote: > > hi, > > i am lacking time a little bit, would somebody be able to look into > the error cmake-3.0.0 compile gives, if i read correct the log these > ones: > > "/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.0/Source/CursesDialog/form/form.priv.h", > line 124: syntax error before or at: _nc_Copy_Type > ... > "/home/rupert/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.0/Source/CursesDialog/form/form.priv.h", > line 132: syntax error before or at: _nc_Internal_Validation > > rupert > Hi Rupert, I took the cmake GAR recipe for a spin and found that the ./configure step finds two different libcurses.so (the SUNW version and the OpenCSW version): -- Looking for wsyncup in /usr/lib/libcurses.so -- Looking for wsyncup in /usr/lib/libcurses.so - found -- Looking for cbreak in /opt/csw/lib/libncurses.so -- Looking for cbreak in /opt/csw/lib/libncurses.so - found Also, just before the same place as you mention in your post above, the compile fails with an error cannot find ncurses/ncurses.h [ 41%] Building C object Source/CursesDialog/form/CMakeFiles/cmForm.dir/fld_arg.c.o "/home/jgoerzen/opencsw/cmake/trunk/work/solaris10-i386/build-isa-pentium_pro/cmake-3.0.0/Source/CursesDialog/form/form.h", line 46: cannot find include file: Hope this will help in finding the solution. Best regards, Jake From maciej at opencsw.org Wed Sep 3 16:51:55 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 3 Sep 2014 16:51:55 +0200 Subject: mgar error when doing platforms In-Reply-To: References: Message-ID: I've seen this error occur to me, only once, and it wasn't repeatable. If anybody else sees this, please let me know. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert at opencsw.org Thu Sep 4 03:49:42 2014 From: rupert at opencsw.org (rupert THURNER) Date: Thu, 4 Sep 2014 03:49:42 +0200 Subject: Fwd: In-Reply-To: References: Message-ID: hi, csw-upload-pkg gives an error message to run a command, copy pasting to run it gives: rupert @ login : ~ $ /home/rupert/opencsw/.buildsys/v2/bin/../lib/python/checkpkg2.py --catalog-release unstable --os-release SunOS5.11 --catalog-architecture i386 7f82dd230aab95d460d7432f9f14149a 54c4e0afeb93b65d962ef784e0c591ba 721ce2d771f40083d13b7c58a18b520d 0d0076b9ee0ad5ec94c96b596b39988d 96b13d8079ba40b40416b3779131ffd2 63e8c45236d11e6f9dc87cd4f241e959 72f951411280f6f101dfad3fdd9c503d 8df35701cd5bb99b60bc1b80247b05eb Traceback (most recent call last): File "/home/rupert/opencsw/.buildsys/v2/bin/../lib/python/checkpkg2.py", line 16, in from lib.python import checkpkg_lib ImportError: No module named lib.python rupert From grzemba at contac-dt.de Thu Sep 4 07:57:41 2014 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Thu, 04 Sep 2014 07:57:41 +0200 Subject: checkpkg2 problem In-Reply-To: References: Message-ID: set environment variable PYTHONPATH=/home/rupert/opencsw/.buildsys/v2 Am 04.09.14 schrieb rupert THURNER : > hi, > > csw-upload-pkg gives an error message to run a command, copy pasting > to run it gives: > > rupert @ login : ~ > $ /home/rupert/opencsw/.buildsys/v2/bin/../lib/python/checkpkg2.py > --catalog-release unstable --os-release SunOS5.11 > --catalog-architecture i386 7f82dd230aab95d460d7432f9f14149a > 54c4e0afeb93b65d962ef784e0c591ba 721ce2d771f40083d13b7c58a18b520d > 0d0076b9ee0ad5ec94c96b596b39988d 96b13d8079ba40b40416b3779131ffd2 > 63e8c45236d11e6f9dc87cd4f241e959 72f951411280f6f101dfad3fdd9c503d > 8df35701cd5bb99b60bc1b80247b05eb > Traceback (most recent call last): > File "/home/rupert/opencsw/.buildsys/v2/bin/../lib/python/checkpkg2.py", > line 16, in > from lib.python import checkpkg_lib > ImportError: No module named lib.python > > rupert > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Thu Sep 4 08:38:22 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 4 Sep 2014 08:38:22 +0200 Subject: In-Reply-To: References: Message-ID: <06DD0B15-C414-4F83-8608-6B60240AFECE@opencsw.org> Hi Rupert, Am 04.09.2014 um 03:49 schrieb rupert THURNER : > csw-upload-pkg gives an error message to run a command, copy pasting > to run it gives: > > rupert @ login : ~ > $ /home/rupert/opencsw/.buildsys/v2/bin/../lib/python/checkpkg2.py > --catalog-release unstable --os-release SunOS5.11 > --catalog-architecture i386 7f82dd230aab95d460d7432f9f14149a > 54c4e0afeb93b65d962ef784e0c591ba 721ce2d771f40083d13b7c58a18b520d > 0d0076b9ee0ad5ec94c96b596b39988d 96b13d8079ba40b40416b3779131ffd2 > 63e8c45236d11e6f9dc87cd4f241e959 72f951411280f6f101dfad3fdd9c503d > 8df35701cd5bb99b60bc1b80247b05eb > Traceback (most recent call last): > File "/home/rupert/opencsw/.buildsys/v2/bin/../lib/python/checkpkg2.py", > line 16, in > from lib.python import checkpkg_lib > ImportError: No module named lib.python Well, csw-upload-pkg sets some environment variables, notably PYTHON_PATH to /home/rupert/opencsw/.buildsys/v2/bin/../lib/python IIRC. 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From maciej at opencsw.org Fri Sep 5 15:48:32 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 5 Sep 2014 14:48:32 +0100 Subject: Giving up maintainer duty In-Reply-To: <4F72ABE0-4D09-435A-B9C1-1CA6732A550D@opencsw.org> References: <4F72ABE0-4D09-435A-B9C1-1CA6732A550D@opencsw.org> Message-ID: Hi Mark, 2014-07-18 19:18 GMT+01:00 Mark Phillips : > I haven't been able to maintain any of my stuff for a while - I'm not a Solaris user any more. It seems to be a common pattern. I'm in the same club now, not using Solaris since late 2010. Thanks for all your contributions! > I have tried to give things up, but it appears my name is still against Puppet, Puppet3, ruby-augeas and Augeas. So I get some contact with issues. > > Could another name be placed against my old stuff please, so at least somebody valid sees any package enquiries? Unfortunately, we don't have the facility to do this. Somebody else has to rebuild and push new versions of these packages. We've talked about related issues in the past[1], but we don't have a workable conclusion[2]. All ideas that people liked would require changes to the infrastructure, and nobody volunteered to make these changes. I suggested some ideas that did not require infrastructure changes, but people didn't like them. [1] http://lists.opencsw.org/pipermail/maintainers/2013-April/017851.html [2] http://lists.opencsw.org/pipermail/maintainers/2013-April/017966.html Maciej From bonivart at opencsw.org Fri Sep 5 16:17:57 2014 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 5 Sep 2014 16:17:57 +0200 Subject: Giving up maintainer duty In-Reply-To: References: <4F72ABE0-4D09-435A-B9C1-1CA6732A550D@opencsw.org> Message-ID: On Fri, Sep 5, 2014 at 3:48 PM, Maciej (Matchek) Blizi?ski wrote: > Unfortunately, we don't have the facility to do this. Somebody else > has to rebuild and push new versions of these packages. We've talked > about related issues in the past[1], but we don't have a workable > conclusion[2]. All ideas that people liked would require changes to > the infrastructure, and nobody volunteered to make these changes. I > suggested some ideas that did not require infrastructure changes, but > people didn't like them. Isn't it simplest to register a dummy user called Orphaned or similar and assign such packages to that "maintainer"? That way users can easily see the state of the package in question and it doesn't require any changes on our part. From maciej at opencsw.org Fri Sep 5 17:04:39 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 5 Sep 2014 16:04:39 +0100 Subject: Giving up maintainer duty In-Reply-To: References: <4F72ABE0-4D09-435A-B9C1-1CA6732A550D@opencsw.org> Message-ID: 2014-09-05 15:17 GMT+01:00 Peter Bonivart : > Isn't it simplest to register a dummy user called Orphaned or similar > and assign such packages to that "maintainer"? That way users can > easily see the state of the package in question and it doesn't require > any changes on our part. Yes, we have this maintainer: http://www.opencsw.org/maintainers/orphaned/ To assign a package to this fake maintainer, somebody has to rebuild packages and spoof the maintainer name. Maciej From bonivart at opencsw.org Fri Sep 5 17:22:03 2014 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 5 Sep 2014 17:22:03 +0200 Subject: Giving up maintainer duty In-Reply-To: References: <4F72ABE0-4D09-435A-B9C1-1CA6732A550D@opencsw.org> Message-ID: On Fri, Sep 5, 2014 at 5:04 PM, Maciej (Matchek) Blizi?ski wrote: > To assign a package to this fake maintainer, somebody has to rebuild > packages and spoof the maintainer name. Yes, that's the normal way of updating the database but surely it must be possible to re-assign packages directly in the database. I assume pkginfo data is never used again by us so it doesn't matter much if someone downloads a package and queries it for the old maintainer. When forking Dago also ran every package through a script to rebuild pkginfo data so even that isn't that hard if deemed necessary. From maciej at opencsw.org Fri Sep 5 17:42:36 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 5 Sep 2014 16:42:36 +0100 Subject: Giving up maintainer duty In-Reply-To: References: <4F72ABE0-4D09-435A-B9C1-1CA6732A550D@opencsw.org> Message-ID: 2014-09-05 16:22 GMT+01:00 Peter Bonivart : > On Fri, Sep 5, 2014 at 5:04 PM, Maciej (Matchek) Blizi?ski > wrote: >> To assign a package to this fake maintainer, somebody has to rebuild >> packages and spoof the maintainer name. > > Yes, that's the normal way of updating the database but surely it must > be possible to re-assign packages directly in the database. It's not possible now, unfortunately. I mean, unless somebody implements it. > I assume > pkginfo data is never used again by us so it doesn't matter much if > someone downloads a package and queries it for the old maintainer. You would need to update it in at least two places: - the svr4_file_stats table - the JSON blob > When forking Dago also ran every package through a script to rebuild > pkginfo data so even that isn't that hard if deemed necessary. Maybe this would be a better idea? Instead of messing with the database, modify packages and push them using the standard procedure? Maciej From bonivart at opencsw.org Fri Sep 5 17:51:09 2014 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 5 Sep 2014 17:51:09 +0200 Subject: Giving up maintainer duty In-Reply-To: References: <4F72ABE0-4D09-435A-B9C1-1CA6732A550D@opencsw.org> Message-ID: On Fri, Sep 5, 2014 at 5:42 PM, Maciej (Matchek) Blizi?ski wrote: > Maybe this would be a better idea? Instead of messing with the > database, modify packages and push them using the standard procedure? Probably easier to implement (no internal messing) and results in a complete change everywhere. From maciej at opencsw.org Fri Sep 5 19:16:17 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 5 Sep 2014 18:16:17 +0100 Subject: Giving up maintainer duty In-Reply-To: References: <4F72ABE0-4D09-435A-B9C1-1CA6732A550D@opencsw.org> Message-ID: 2014-09-05 16:51 GMT+01:00 Peter Bonivart : > Probably easier to implement (no internal messing) and results in a > complete change everywhere. Yes. Dago, do you still have any of these scripts? One wrinkle I can think of is that this package might trigger some checkpkg errors, so apart from modifying PKGINFO, we would need to add some overrides. It's a minor issue, but it needs to be solved for this to work reliably. Maciej From maciej at opencsw.org Tue Sep 9 00:59:12 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 8 Sep 2014 23:59:12 +0100 Subject: making the first gnustep packages available In-Reply-To: <1408964256.6019.0.camel@anor> References: <1407405257.7880.6.camel@anor> <1408964256.6019.0.camel@anor> Message-ID: 2014-08-25 11:57 GMT+01:00 Riccardo Mottola : > sorry if I ping this up, but I ever got a reply.... I have replied, no? http://lists.opencsw.org/pipermail/maintainers/2014-August/019408.html From dam at opencsw.org Tue Sep 9 08:58:37 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 9 Sep 2014 08:58:37 +0200 Subject: making the first gnustep packages available In-Reply-To: <1408964256.6019.0.camel@anor> References: <1407405257.7880.6.camel@anor> <1408964256.6019.0.camel@anor> Message-ID: <78CD7F4D-DA7C-4362-B239-2552B10CCAC4@opencsw.org> Hi Riccardo, Am 25.08.2014 um 12:57 schrieb Riccardo Mottola : > In the meanwhile I successfully packaged ProjectCenter and PRICE! Excellent! > I wonder what my next-steps are, after my "mgar commit? Make packages without ?UNCOMMITTED? and then upload them from ?login? with csw-upload-pkg all in one batch. They will show up on unstable within a few hours at most. Best regards ? Dago > > Riccardo > > On Thu, 2014-08-07 at 11:54, Riccardo Mottola wrote: >> Hi, >> >> while there are still problems which can be surely worked out later, I >> have now completed a first set of packages for GNUstep: >> - core packagess (make, base, gui, back) >> - Gorm, the graphical interface builder >> - a couple of easy-to-package apps (Terminal, Zipper, FTP) >> >> the latter were the simplest since they don't have external dependencies >> and they prove that the core packages work! >> I have prefixed all directories with gs_, so that in case there is no >> name clash (e.g. FTP gets gs_ftp), if there will be package name clashes >> I hope we can sort them out too. Several utility apps have pretty >> generic names. >> >> right now what builds is commited with "mgar commit". >> >> What's next to make them packages? >> >> >> The best would be if somebody did try them also on solaris 9 and 11 and >> on x86, since I only have a solaris 10 sparc host. And maybe even use >> them and find them useful :) >> >> Riccardo >> > -- "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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From dam at opencsw.org Wed Sep 10 15:22:48 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 10 Sep 2014 15:22:48 +0200 Subject: Python 2.7.8 Message-ID: <53513F4D-80F0-4DF1-8D1F-09966BE5ACC3@opencsw.org> Hi folks, I just bumped Python to 2.7.8, feel free to give it a try: http://buildfarm.opencsw.org/experimental.html#python27 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From maciej at opencsw.org Wed Sep 10 16:17:08 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 10 Sep 2014 15:17:08 +0100 Subject: Python 2.7.8 In-Reply-To: <53513F4D-80F0-4DF1-8D1F-09966BE5ACC3@opencsw.org> References: <53513F4D-80F0-4DF1-8D1F-09966BE5ACC3@opencsw.org> Message-ID: 2014-09-10 14:22 GMT+01:00 Dagobert Michelsen : > > I just bumped Python to 2.7.8, feel free to give it a try: > http://buildfarm.opencsw.org/experimental.html#python27 I recently received an email from a user. I haven't done anything about it, but it might be a good time to look into it: > Hi Maciej, > Thank you for creating CSWpython27. I have an old V240 system from 2006 that was in desperate need of updating and the CSW packages, expecially python was what i was very happy to find. > I notice however that CSWpython27 package bundles the compiled curses dynamic libs disabled (they are included as _curses_failed.so and _curses_panel_failed.so). The modules get named with _failed if they are missing a dependency somewhere, as you may already know. The dependency was on function unctrl, which seems to only be available in ncurses but not being used because Python was instead compiling against the system curses library instead. > I downloaded the Python-2.7.6.tar.xz source code and was able to get them to compile manually by including -DHAVE_NCURSES_H and then the modules loaded and were not renamed to failed. > The package looks like it already has a dependency CSWncurses (i have version 5.9,REV=2011.11.21 installed), but the compilation of Python doesn\'t seem to pick up/use that, so it needed a little help. > When you are next going to package python 2.7.x (i\'m hoping for 2.7.8 since i just like to be on the bleeding edge), i am hoping the above is helpful to get the Python suite packaged with all modules intact (e.g. with no _failed modules bundled). > The following are the commands i used manually to compile the two modules by hand: > gcc -fPIC -fno-strict-aliasing -g -O2 -DHAVE_NCURSES_H -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/opt/csw/include/ncurses -I/home/cynikal/patch/Python-2.7.6/Include -I/home/cynikal/patch/Python-2.7.6 -c /home/cynikal/patch/Python-2.7.6/Modules/_cursesmodule.c -o build/temp.solaris-2.10-sun4u.32bit-2.7/home/cynikal/patch/Python-2.7.6/Modules/_cursesmodule.o > gcc -shared build/temp.solaris-2.10-sun4u.32bit-2.7/home/cynikal/patch/Python-2.7.6/Modules/_cursesmodule.o -L/opt/csw/lib -lncurses -o build/lib.solaris-2.10-sun4u.32bit-2.7/_curses.so > gcc -fPIC -fno-strict-aliasing -g -O2 -DHAVE_NCURSES_H -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/opt/csw/include/ncurses -I/home/cynikal/patch/Python-2.7.6/Include -I/home/cynikal/patch/Python-2.7.6 -c /home/cynikal/patch/Python-2.7.6/Modules/_curses_panel.c -o build/temp.solaris-2.10-sun4u.32bit-2.7/home/cynikal/patch/Python-2.7.6/Modules/_curses_panel.o > gcc -shared build/temp.solaris-2.10-sun4u.32bit-2.7/home/cynikal/patch/Python-2.7.6/Modules/_curses_panel.o -L/opt/csw/lib -lpanel -lncurses -o build/lib.solaris-2.10-sun4u.32bit-2.7/_curses_panel.so > (i then manually copied the build/lib.solaris-2.10-sun4u.32bit-2.7/_*so to /opt/csw/lib/python2.7/lib-dynload ) > Hope this helps! From kester at opencsw.org Thu Sep 11 17:17:54 2014 From: kester at opencsw.org (Kester Habermann) Date: Thu, 11 Sep 2014 17:17:54 +0200 Subject: [csw-maintainers] New ImageMagick In-Reply-To: <522B7039.3030603@opencsw.org> References: <51E3FA6A.90008@opencsw.org> <51E6505D.9040400@opencsw.org> <522B63BF.5060402@opencsw.org> <522b6dd7.wya849MBsHkoCamb%Joerg.Schilling@fokus.fraunhofer.de> <522B7039.3030603@opencsw.org> Message-ID: <20140911151754.GB6560@bender.opencsw.org> Hello, I encountered a problem with ImageMagick, it would be great if someone could see if they can replicate the problem. The version of ImageMagick in Kiel (6.7.3) does not have the bug, I first noticed this witj the version in Bratislava (6.8.8) 16-bit greyscale images (fits or tiff) are not handled properly on Solaris/SPARC which is big endian. On Solaris/x86 (little endian) and Linux/x86 there is no problem. Also 8-bit greyscale images are not affected. I habe no idea if the issue is actually related to endianness. As it works on Solaris/x86, I conclude that it is not Solaris specific. To reproduce the problem: - view a 16-bit greyscale image (fits or tiff) using display - convert a a 16-bit greyscale image to a 8-bit format (e. g. as png) and view it In my case the fits-image is displayed (or converted to) completely black and the tiff-image to grey noise. I've already reported this upstream, but no one has confirmed the problem: http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=25919&sid=e2b38c6d2c2db0333abd5c4bb817ccdf A completely unrelated issue also involving ImageMagick, it is actually more an emacs issue. GNU emacs can actually display images inline. Some images formats (likes fits are displayed using ImageMagick). It appears that the version of ImageMagick was changed without rebuilding emacs. This causes emacs to crash when opening an image file: $ emacs file.fits ld.so.1: emacs-24.3-athena: fatal: libMagickWand-6.Q16HDRI.so.1: open failed: No such file or directory ld.so.1: emacs-24.3-athena: fatal: relocation error: file /opt/csw/bin/emacs-24.3-athena: symbol MagickWandGenesis: referenced symbol not found killed emacs Note: DISPLAY has to be set to see the problem. ldd also shows the problem: kester at unstable10s [unstable10s]:~ > ldd -ur /opt/csw/bin/emacs | grep "not found" libMagickWand-6.Q16HDRI.so.1 => (file not found) libMagickCore-6.Q16HDRI.so.1 => (file not found) symbol not found: MagickGetException (/opt/csw/bin/emacs-24.3-athena) Regards Kester From laurent at opencsw.org Thu Sep 11 19:40:04 2014 From: laurent at opencsw.org (Laurent Blume) Date: Thu, 11 Sep 2014 19:40:04 +0200 Subject: [csw-maintainers] New ImageMagick In-Reply-To: <20140911151754.GB6560@bender.opencsw.org> References: <51E3FA6A.90008@opencsw.org> <51E6505D.9040400@opencsw.org> <522B63BF.5060402@opencsw.org> <522b6dd7.wya849MBsHkoCamb%Joerg.Schilling@fokus.fraunhofer.de> <522B7039.3030603@opencsw.org> <20140911151754.GB6560@bender.opencsw.org> Message-ID: <5411DE74.5060808@opencsw.org> On 11/09/2014 17:17, Kester Habermann wrote: [snip] > I've already reported this upstream, but no one has confirmed the problem: > http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=25919&sid=e2b38c6d2c2db0333abd5c4bb817ccdf Have you tried with some other tool using libtiff, just to make sure it's specific to ImageMagick? > A completely unrelated issue also involving ImageMagick, it is actually > more an emacs issue. GNU emacs can actually display images inline. Some > images formats (likes fits are displayed using ImageMagick). It appears > that the version of ImageMagick was changed without rebuilding emacs. > This causes emacs to crash when opening an image file: > > $ emacs file.fits > ld.so.1: emacs-24.3-athena: fatal: libMagickWand-6.Q16HDRI.so.1: open failed: No such file or directory > ld.so.1: emacs-24.3-athena: fatal: relocation error: file /opt/csw/bin/emacs-24.3-athena: symbol MagickWandGenesis: referenced symbol not found > killed emacs > > Note: DISPLAY has to be set to see the problem. > > ldd also shows the problem: > kester at unstable10s [unstable10s]:~ > ldd -ur /opt/csw/bin/emacs | grep "not found" > libMagickWand-6.Q16HDRI.so.1 => (file not found) > libMagickCore-6.Q16HDRI.so.1 => (file not found) > symbol not found: MagickGetException (/opt/csw/bin/emacs-24.3-athena) That's a mistake of mine, I think I some point I pushed a stub for the .so.1 libs, and that was wrong. I hadn't realized it had had some effect. I need to find a way to rebuild that version. Can you open a bug report on it to prod me? Laurent From rmottola at opencsw.org Thu Sep 11 22:30:44 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Thu, 11 Sep 2014 22:30:44 +0200 Subject: making the first gnustep packages available In-Reply-To: References: <1407405257.7880.6.camel@anor> Message-ID: <54120674.5060301@opencsw.org> Hi Maciej, sorry that I mised your original mail, it went to the trash unnoticed :( Thanks for the patience of pointing to it again. I thought that the build system was more like 1) make receipe 2) mark it as complete part of a certain "collection" (eg. certain OS and architectures) 3) an automated system will build the packages and make them available insted you are saying that to build a package, i need to generate it myself on each host/arch i want to support and then "upload" it? Maciej (Matchek) Blizi?ski wrote: > Log in to the buildfarm, and in each build recipe run "mgar > platforms", or "mgar replatforms" if you have files from previous runs > lying around. Then you upload them from the login host, using the > csw-upload-pkg utility. 1) I login to unstable10s 2) cd to my first package, ~/opencsw/gnustep-make/trunk 3) run most steps seem positive, including package build, but I get: ## Validating control scripts. ## Packaging complete. mkp: exec( pkgtrans -s /home/rmottola/spool.5.10-sparc /tmp/gnustep_make-2.6.6,REV=2014.09.11-SunOS5.10-sparc-CSW.pkg CSWgnustep-make ) Transferring package instance mkp: exec( gzip -9 -f /tmp/gnustep_make-2.6.6,REV=2014.09.11-SunOS5.10-sparc-CSW.pkg ) mkp: exec( mv /tmp/gnustep_make-2.6.6,REV=2014.09.11-SunOS5.10-sparc-CSW.pkg.gz /home/rmottola/pkgs ) mkp: exec( rm -rf /home/rmottola/spool.5.10-sparc/CSWgnustep-make ) INFO 2014-09-11 09:39:08,781 package_stats.py:132 Juicing the svr4 package stream files... CRITICAL 2014-09-11 09:40:03,401 shell.py:55 | CRITICAL 2014-09-11 09:40:03,402 shell.py:56 INFO 2014-09-11 09:39:13,232 retry_decorator.py:35 Retry, exception: URL HEAD 'http://buildfarm.opencsw.org/releases/blob/pkgstats/5c8964ae284f425cc04df17b1dd33373/' HTTP code: 401 INFO 2014-09-11 09:39:23,243 retry_decorator.py:35 Retry, exception: URL HEAD 'http://buildfarm.opencsw.org/releases/blob/pkgstats/5c8964ae284f425cc04df17b1dd33373/' HTTP code: 401 INFO 2014-09-11 09:39:33,254 retry_decorator.py:35 Retry, exception: URL HEAD 'http://buildfarm.opencsw.org/releases/blob/pkgstats/5c8964ae284f425cc04df17b1dd33373/' HTTP code: 401 INFO 2014-09-11 09:39:43,264 retry_decorator.py:35 Retry, exception: URL HEAD 'http://buildfarm.opencsw.org/releases/blob/pkgstats/5c8964ae284f425cc04df17b1dd33373/' HTTP code: 401 INFO 2014-09-11 09:39:53,275 retry_decorator.py:35 Retry, exception: URL HEAD 'http://buildfarm.opencsw.org/releases/blob/pkgstats/5c8964ae284f425cc04df17b1dd33373/' HTTP code: 401 Traceback (most recent call last): File "/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/collect_pkg_metadata.py", line 623, in unpacked = unpacker.CollectStats(force_unpack=options.force_unpack) File "/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/collect_pkg_metadata.py", line 594, in CollectStats self.md5_sum): File "/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/retry_decorator.py", line 39, in fn raise last_exception lib.python.rest.RestCommunicationError: URL HEAD 'http://buildfarm.opencsw.org/releases/blob/pkgstats/5c8964ae284f425cc04df17b1dd33373/' HTTP code: 401 Traceback (most recent call last): File "/home/rmottola/opencsw/.buildsys/v2/gar//bin/../lib/python/checkpkg2.py", line 268, in main() File "/home/rmottola/opencsw/.buildsys/v2/gar//bin/../lib/python/checkpkg2.py", line 174, in main md5_sums_from_files = collector.CollectStatsFromCatalogEntries(entries, False) File "/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/package_stats.py", line 158, in CollectStatsFromCatalogEntries stderr=stderr_file) File "/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/shell.py", line 60, in ShellCommand % (args, retcode, ' '.join(pipes.quote(x) for x in args))) lib.python.shell.ShellError: Running ['/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/collect_pkg_metadata.py', '--input', '/home/rmottola/pkgs/gnustep_make-2.6.6,REV=2014.09.11-SunOS5.10-sparc-CSW.pkg.gz'] has failed, error code: 1. To find out why the command failed, please run it in the foreground, like this: /home/rmottola/opencsw/.buildsys/v2/gar/lib/python/collect_pkg_metadata.py --input /home/rmottola/pkgs/gnustep_make-2.6.6,REV=2014.09.11-SunOS5.10-sparc-CSW.pkg.gz /home/rmottola/opencsw/.buildsys/v2/gar//gar.pkg.mk:1023: recipe for target 'pkgcheck' failed gmake[1]: *** [pkgcheck] Error 2 gmake[1]: Leaving directory '/home/rmottola/opencsw/gnustep-make/trunk' /home/rmottola/opencsw/.buildsys/v2/gar//gar.pkg.mk:1068: recipe for target 'platforms' failed gmake: *** [platforms] Error 2 I followed the instruction and did run: /home/rmottola/opencsw/.buildsys/v2/gar/lib/python/collect_pkg_metadata.py --input /home/rmottola/pkgs/gnustep_make-2.6.6,REV=2014.09.11-SunOS5.10-sparc-CSW.pkg.gz I get: Traceback (most recent call last): File "/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/collect_pkg_metadata.py", line 16, in from lib.python import common_constants ImportError: No module named lib.python Riccardo From rmottola at opencsw.org Thu Sep 11 22:30:52 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Thu, 11 Sep 2014 22:30:52 +0200 Subject: making the first gnustep packages available In-Reply-To: References: <1407405257.7880.6.camel@anor> Message-ID: <5412067C.8080200@opencsw.org> Hi, Maciej (Matchek) Blizi?ski wrote: > Have you built it on Solaris 9? If you only built it on Solaris 10, it > will very likely not build on Solaris 9. Unless you want to, I would > suggest not spending time on Solaris 9. actually, I didn't. I did all the work on my own solaris 10 machine. Since I am able with some manual hacking to build on my solaris 8 machine against the old packages (not from the receipes of course, just a local build) I'd like to see how my mileage on Solaris 9 is. I'm still a bit new to the buildfarm setup. What I did is: 1) ssh to login, where I did all the mgar checkout 2) ssh to unstable9s 3) run for the "gnustep-make" package, which is the root of all stuff, "mgar fetch makesum extract configure build" I fail with: ==> Verifying installed package CSWpy-sqlobject: ok ==> Verifying installed package CSWpython: ok ==> Verifying installed package CSWwget: ok ==> Verifying installed package CSWxz: ok ==> Verifying installed package CSWgmake: ok ==> Verifying installed package CSWgcc4objc: MISSING gmake: *** [check-prereqs] Error 1 is gcc4obj not available on solaris9 or it is just not installed? Who can install it? Riccardo From kester at opencsw.org Fri Sep 12 08:59:49 2014 From: kester at opencsw.org (Kester Habermann) Date: Fri, 12 Sep 2014 08:59:49 +0200 Subject: [csw-maintainers] New ImageMagick In-Reply-To: <5411DE74.5060808@opencsw.org> References: <51E3FA6A.90008@opencsw.org> <51E6505D.9040400@opencsw.org> <522B63BF.5060402@opencsw.org> <522b6dd7.wya849MBsHkoCamb%Joerg.Schilling@fokus.fraunhofer.de> <522B7039.3030603@opencsw.org> <20140911151754.GB6560@bender.opencsw.org> <5411DE74.5060808@opencsw.org> Message-ID: <20140912065949.GD6560@bender.opencsw.org> Hi, On Thu, Sep 11, 2014 at 07:40:04PM +0200, Laurent Blume wrote: > On 11/09/2014 17:17, Kester Habermann wrote: > [snip] > >I've already reported this upstream, but no one has confirmed the problem: > >http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=25919&sid=e2b38c6d2c2db0333abd5c4bb817ccdf > > Have you tried with some other tool using libtiff, just to make sure > it's specific to ImageMagick? I can display these images with xv and gimp. The only thing that is broken is imagemagick. Downgrading imagemagick to an older version (without changing anything else) fixed the problem. > That's a mistake of mine, I think I some point I pushed a stub for > the .so.1 libs, and that was wrong. I hadn't realized it had had > some effect. I need to find a way to rebuild that version. Can you > open a bug report on it to prod me? Done (Id: 5204). Regards Kester From dam at opencsw.org Fri Sep 12 12:57:17 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 12 Sep 2014 12:57:17 +0200 Subject: making the first gnustep packages available In-Reply-To: <5412067C.8080200@opencsw.org> References: <1407405257.7880.6.camel@anor> <5412067C.8080200@opencsw.org> Message-ID: <8D0CF22E-DEC3-4D8D-9EDC-45BCEC0990E5@opencsw.org> Hi Riccardo, Am 11.09.2014 um 22:30 schrieb Riccardo Mottola : > Maciej (Matchek) Blizi?ski wrote: >> Have you built it on Solaris 9? If you only built it on Solaris 10, it >> will very likely not build on Solaris 9. Unless you want to, I would >> suggest not spending time on Solaris 9. > > actually, I didn't. I did all the work on my own solaris 10 machine. > > Since I am able with some manual hacking to build on my solaris 8 machine against the old packages (not from the receipes of course, just a local build) I'd like to see how my mileage on Solaris 9 is. > > I'm still a bit new to the buildfarm setup. > > What I did is: > > 1) ssh to login, where I did all the mgar checkout > 2) ssh to unstable9s > 3) run for the "gnustep-make" package, which is the root of all stuff, "mgar fetch makesum extract configure build" > > I fail with: > ==> Verifying installed package CSWpy-sqlobject: ok > ==> Verifying installed package CSWpython: ok > ==> Verifying installed package CSWwget: ok > ==> Verifying installed package CSWxz: ok > ==> Verifying installed package CSWgmake: ok > ==> Verifying installed package CSWgcc4objc: MISSING > gmake: *** [check-prereqs] Error 1 > > is gcc4obj not available on solaris9 or it is just not installed? Who can install it? It is, but was not installed: unstable9s% pkgutil -a CSWgcc4objc You're not root and didn't set -W, using home dir. => Fetching new catalog and descriptions (file:///export/mirror/opencsw-official/unstable/sparc/5.9) if available ... common package catalog size gcc4objc CSWgcc4objc 4.6.3,REV=2012.03.05 23.7 MB unstable9s% pkginfo CSWgcc4objc ERROR: information for "CSWgcc4objc" was not found You can request additional packages on the farm servers any time by mailing to buildfarm at opencsw.org (which also goes to me :-) 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From dam at opencsw.org Fri Sep 12 13:02:26 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 12 Sep 2014 13:02:26 +0200 Subject: making the first gnustep packages available In-Reply-To: <54120674.5060301@opencsw.org> References: <1407405257.7880.6.camel@anor> <54120674.5060301@opencsw.org> Message-ID: <650478DB-B93B-47D5-844D-B1B1551D802B@opencsw.org> Hi Riccardo, Am 11.09.2014 um 22:30 schrieb Riccardo Mottola : > sorry that I mised your original mail, it went to the trash unnoticed :( Thanks for the patience of pointing to it again. > > I thought that the build system was more like > 1) make receipe > 2) mark it as complete part of a certain "collection" (eg. certain OS and architectures) > 3) an automated system will build the packages and make them available > > insted you are saying that to build a package, i need to generate it myself on each host/arch i want to support and then "upload" it? Yes. Just mgar spotless && mgar platforms > Maciej (Matchek) Blizi?ski wrote: >> Log in to the buildfarm, and in each build recipe run "mgar >> platforms", or "mgar replatforms" if you have files from previous runs >> lying around. Then you upload them from the login host, using the >> csw-upload-pkg utility. > > 1) I login to unstable10s > 2) cd to my first package, ~/opencsw/gnustep-make/trunk > 3) run > > most steps seem positive, including package build, but I get: > ## Validating control scripts. > ## Packaging complete. > mkp: exec( pkgtrans -s /home/rmottola/spool.5.10-sparc /tmp/gnustep_make-2.6.6,REV=2014.09.11-SunOS5.10-sparc-CSW.pkg CSWgnustep-make ) > Transferring package instance > mkp: exec( gzip -9 -f /tmp/gnustep_make-2.6.6,REV=2014.09.11-SunOS5.10-sparc-CSW.pkg ) > mkp: exec( mv /tmp/gnustep_make-2.6.6,REV=2014.09.11-SunOS5.10-sparc-CSW.pkg.gz /home/rmottola/pkgs ) > mkp: exec( rm -rf /home/rmottola/spool.5.10-sparc/CSWgnustep-make ) > INFO 2014-09-11 09:39:08,781 package_stats.py:132 Juicing the svr4 package stream files... > CRITICAL 2014-09-11 09:40:03,401 shell.py:55 | > CRITICAL 2014-09-11 09:40:03,402 shell.py:56 INFO 2014-09-11 09:39:13,232 retry_decorator.py:35 Retry, exception: URL HEAD 'http://buildfarm.opencsw.org/releases/blob/pkgstats/5c8964ae284f425cc04df17b1dd33373/' HTTP code: 401 > INFO 2014-09-11 09:39:23,243 retry_decorator.py:35 Retry, exception: URL HEAD 'http://buildfarm.opencsw.org/releases/blob/pkgstats/5c8964ae284f425cc04df17b1dd33373/' HTTP code: 401 > INFO 2014-09-11 09:39:33,254 retry_decorator.py:35 Retry, exception: URL HEAD 'http://buildfarm.opencsw.org/releases/blob/pkgstats/5c8964ae284f425cc04df17b1dd33373/' HTTP code: 401 > INFO 2014-09-11 09:39:43,264 retry_decorator.py:35 Retry, exception: URL HEAD 'http://buildfarm.opencsw.org/releases/blob/pkgstats/5c8964ae284f425cc04df17b1dd33373/' HTTP code: 401 > INFO 2014-09-11 09:39:53,275 retry_decorator.py:35 Retry, exception: URL HEAD 'http://buildfarm.opencsw.org/releases/blob/pkgstats/5c8964ae284f425cc04df17b1dd33373/' HTTP code: 401 > Traceback (most recent call last): > File "/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/collect_pkg_metadata.py", line 623, in > unpacked = unpacker.CollectStats(force_unpack=options.force_unpack) > File "/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/collect_pkg_metadata.py", line 594, in CollectStats > self.md5_sum): > File "/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/retry_decorator.py", line 39, in fn > raise last_exception > lib.python.rest.RestCommunicationError: URL HEAD 'http://buildfarm.opencsw.org/releases/blob/pkgstats/5c8964ae284f425cc04df17b1dd33373/' HTTP code: 401 > > Traceback (most recent call last): > File "/home/rmottola/opencsw/.buildsys/v2/gar//bin/../lib/python/checkpkg2.py", line 268, in > main() > File "/home/rmottola/opencsw/.buildsys/v2/gar//bin/../lib/python/checkpkg2.py", line 174, in main > md5_sums_from_files = collector.CollectStatsFromCatalogEntries(entries, False) > File "/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/package_stats.py", line 158, in CollectStatsFromCatalogEntries > stderr=stderr_file) > File "/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/shell.py", line 60, in ShellCommand > % (args, retcode, ' '.join(pipes.quote(x) for x in args))) > lib.python.shell.ShellError: Running ['/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/collect_pkg_metadata.py', '--input', '/home/rmottola/pkgs/gnustep_make-2.6.6,REV=2014.09.11-SunOS5.10-sparc-CSW.pkg.gz'] has failed, error code: 1. To find out why the command failed, please run it in the foreground, like this: /home/rmottola/opencsw/.buildsys/v2/gar/lib/python/collect_pkg_metadata.py --input /home/rmottola/pkgs/gnustep_make-2.6.6,REV=2014.09.11-SunOS5.10-sparc-CSW.pkg.gz > /home/rmottola/opencsw/.buildsys/v2/gar//gar.pkg.mk:1023: recipe for target 'pkgcheck' failed > gmake[1]: *** [pkgcheck] Error 2 > gmake[1]: Leaving directory '/home/rmottola/opencsw/gnustep-make/trunk' > /home/rmottola/opencsw/.buildsys/v2/gar//gar.pkg.mk:1068: recipe for target 'platforms' failed > gmake: *** [platforms] Error 2 > > I followed the instruction and did run: > /home/rmottola/opencsw/.buildsys/v2/gar/lib/python/collect_pkg_metadata.py --input /home/rmottola/pkgs/gnustep_make-2.6.6,REV=2014.09.11-SunOS5.10-sparc-CSW.pkg.gz > > I get: > Traceback (most recent call last): > File "/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/collect_pkg_metadata.py", line 16, in > from lib.python import common_constants > ImportError: No module named lib.python I guess you need export PYTHONLIB=/home/rmottola/opencsw/.buildsys/v2/gar/lib/python But just try again, these web errors happen from time to time, we haven?t managed to track that down, most certainly an WSGI issue with our Apache. 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From maciej at opencsw.org Fri Sep 12 14:52:05 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 12 Sep 2014 13:52:05 +0100 Subject: making the first gnustep packages available In-Reply-To: <650478DB-B93B-47D5-844D-B1B1551D802B@opencsw.org> References: <1407405257.7880.6.camel@anor> <54120674.5060301@opencsw.org> <650478DB-B93B-47D5-844D-B1B1551D802B@opencsw.org> Message-ID: Hi Dago and Riccardo, 2014-09-12 12:02 GMT+01:00 Dagobert Michelsen : > > > INFO 2014-09-11 09:39:23,243 retry_decorator.py:35 Retry, exception: URL HEAD 'http://buildfarm.opencsw.org/releases/blob/pkgstats/5c8964ae284f425cc04df17b1dd33373/' HTTP code: 401 This is HTTP 401 Unauthorized, because Riccardo's account hasn't been authorized yet to publish packages. Dago, can you handle this? Maciej From dam at opencsw.org Fri Sep 12 14:55:50 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 12 Sep 2014 14:55:50 +0200 Subject: making the first gnustep packages available In-Reply-To: References: <1407405257.7880.6.camel@anor> <54120674.5060301@opencsw.org> <650478DB-B93B-47D5-844D-B1B1551D802B@opencsw.org> Message-ID: <606C5593-03A2-485D-91BC-C4D827B699EA@opencsw.org> Hi Maciej, Am 12.09.2014 um 14:52 schrieb Maciej (Matchek) Blizi?ski : > 2014-09-12 12:02 GMT+01:00 Dagobert Michelsen : >> >>> INFO 2014-09-11 09:39:23,243 retry_decorator.py:35 Retry, exception: URL HEAD 'http://buildfarm.opencsw.org/releases/blob/pkgstats/5c8964ae284f425cc04df17b1dd33373/' HTTP code: 401 > > This is HTTP 401 Unauthorized, because Riccardo's account hasn't been > authorized yet to publish packages. Dago, can you handle this? Ah, sure! But why is this needed? I mean, this is not csw-upload-pkg. Or is this the /etc/opt/csw/?-NFS things for auth? 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From dam at opencsw.org Fri Sep 12 15:06:29 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 12 Sep 2014 15:06:29 +0200 Subject: making the first gnustep packages available In-Reply-To: <606C5593-03A2-485D-91BC-C4D827B699EA@opencsw.org> References: <1407405257.7880.6.camel@anor> <54120674.5060301@opencsw.org> <650478DB-B93B-47D5-844D-B1B1551D802B@opencsw.org> <606C5593-03A2-485D-91BC-C4D827B699EA@opencsw.org> Message-ID: <80534F3B-611F-4266-BF7E-50BDD18BB5CC@opencsw.org> Hi Riccardo, Am 12.09.2014 um 14:55 schrieb Dagobert Michelsen : > Am 12.09.2014 um 14:52 schrieb Maciej (Matchek) Blizi?ski : >> 2014-09-12 12:02 GMT+01:00 Dagobert Michelsen : >>> >>>> INFO 2014-09-11 09:39:23,243 retry_decorator.py:35 Retry, exception: URL HEAD 'http://buildfarm.opencsw.org/releases/blob/pkgstats/5c8964ae284f425cc04df17b1dd33373/' HTTP code: 401 >> >> This is HTTP 401 Unauthorized, because Riccardo's account hasn't been >> authorized yet to publish packages. Dago, can you handle this? Done. @Riccardo: Please try again. 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From dam at opencsw.org Fri Sep 12 15:27:20 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 12 Sep 2014 15:27:20 +0200 Subject: Giving up maintainer duty In-Reply-To: References: <4F72ABE0-4D09-435A-B9C1-1CA6732A550D@opencsw.org> Message-ID: Hi Maciej, Am 05.09.2014 um 19:16 schrieb Maciej (Matchek) Blizi?ski : > 2014-09-05 16:51 GMT+01:00 Peter Bonivart : >> Probably easier to implement (no internal messing) and results in a >> complete change everywhere. > > Yes. Dago, do you still have any of these scripts? That was really, really ugly stuff, just enough to do it. > One wrinkle I can think of is that this package might trigger some > checkpkg errors, so apart from modifying PKGINFO, we would need to add > some overrides. It's a minor issue, but it needs to be solved for this > to work reliably. I would prefer a solution that just modified the displayed things on the webpage, we already have that information in the database for displaying this: http://www.opencsw.org/qa/maintainers/ 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From maciej at opencsw.org Fri Sep 12 15:56:58 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 12 Sep 2014 14:56:58 +0100 Subject: Giving up maintainer duty In-Reply-To: References: <4F72ABE0-4D09-435A-B9C1-1CA6732A550D@opencsw.org> Message-ID: 2014-09-12 14:27 GMT+01:00 Dagobert Michelsen : > I would prefer a solution that just modified the displayed things on the webpage, > we already have that information in the database for displaying this: > http://www.opencsw.org/qa/maintainers/ The main pain point is the web contact form -- it has to tell users that they have to write to users@ and not to the retired maintainer. I don't see any problems with either of these solutions. Is there a volunteer? Maciej From rmottola at opencsw.org Fri Sep 12 19:38:15 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Fri, 12 Sep 2014 19:38:15 +0200 Subject: making the first gnustep packages available In-Reply-To: References: <1407405257.7880.6.camel@anor> Message-ID: <54132F87.2000805@opencsw.org> Hi, Maciej (Matchek) Blizi?ski wrote: > Log in to the buildfarm, and in each build recipe run "mgar > platforms", or "mgar replatforms" if you have files from previous runs > lying around. Then you upload them from the login host, using the > csw-upload-pkg utility. fine! I did so. Build completed. I did so on unstable10s and unstable 9s I find now both a sparc and an i386 package, yet I build only on "unstable10s". Is the i386 package reliable? I saw that during build unstable9s somehow "connected" to unstable10s.... also, these are the solaris 10 packages, where are the 9 ? I would have expected two sparc packages, one for 9 and one for 10 A bit confused. Riccardo From maciej at opencsw.org Tue Sep 16 17:38:12 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 16 Sep 2014 16:38:12 +0100 Subject: Update of MySQL to 5.6 In-Reply-To: <54184F25.8060408@opencsw.org> References: <54184F25.8060408@opencsw.org> Message-ID: 2014-09-16 15:54 GMT+01:00 Laurent Blume : > A heads up: I'll be pushing MySQL 5.6.20 shortly. We plan to carve a new stable soon. The task is simple. I will write it up when performing, for the sake of future releases. Maybe let's publish a new stable first, and release 5.6 after that? Maciej From laurent at opencsw.org Tue Sep 16 20:53:32 2014 From: laurent at opencsw.org (Laurent Blume) Date: Tue, 16 Sep 2014 20:53:32 +0200 Subject: Update of MySQL to 5.6 In-Reply-To: References: <54184F25.8060408@opencsw.org> Message-ID: <5418872C.30907@opencsw.org> Le 2014/09/16 17:38 +0200, Matchek a ?crit: > 2014-09-16 15:54 GMT+01:00 Laurent Blume : >> A heads up: I'll be pushing MySQL 5.6.20 shortly. > > We plan to carve a new stable soon. The task is simple. I will write > it up when performing, for the sake of future releases. > > Maybe let's publish a new stable first, and release 5.6 after that? Sounds reasonable. Do you have a timeframe already? Laurent From rmottola at opencsw.org Wed Sep 17 08:16:41 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Wed, 17 Sep 2014 08:16:41 +0200 Subject: which host builds what Message-ID: <54192749.4090707@opencsw.org> Hi, I'm still confused by what builds which packages. I am trying to build gnustep-make, so that I can upload it for the first time. Also I want to test my packages on solaris 9, maybe I am lucky (I know they can build with some kicking on solaris 8...) I issue: mgar spotless && mgar platforms If I log into unstable9s SunOS unstable9s 5.9 Generic_Virtual sun4u sparc SUNW,SPARC-Enterprise-T5220 I see the following log: <...> # Checkpkg suggests adding the following lines to the GAR recipe: # This is a summary; see above for details. ARCHALL_CSWgnustep-make = 1 gmake: Leaving directory '/home/rmottola/opencsw/gnustep-make/trunk' Connection to unstable10x closed. The following packages have been built during this invocation: * Platform solaris10-sparc (built on host 'unstable10s') CSWgnustep-make /home/rmottola/pkgs/gnustep_make-2.6.6,REV=2014.09.16-SunOS5.10-sparc-CSW.pkg.gz * Platform solaris10-i386 (built on host 'unstable10x') CSWgnustep-make /home/rmottola/pkgs/gnustep_make-2.6.6,REV=2014.09.16-SunOS5.10-i386-CSW.pkg.gz why does it build two packages, on other two machines? and not "itself"? How do I generate the sparc 9 package (and x86 package) ? Is the mgar tool somehow "smart" and does a grid build? and how do I tell it what to? not all combination may be working. Riccardo From dam at opencsw.org Wed Sep 17 09:27:54 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 17 Sep 2014 09:27:54 +0200 Subject: which host builds what In-Reply-To: <54192749.4090707@opencsw.org> References: <54192749.4090707@opencsw.org> Message-ID: Hi Riccardo, Am 17.09.2014 um 08:16 schrieb Riccardo Mottola : > I'm still confused by what builds which packages. > > I am trying to build gnustep-make, so that I can upload it for the first time. Also I want to test my packages on solaris 9, maybe I am lucky (I know they can build with some kicking on solaris 8...) > > I issue: > > mgar spotless && mgar platforms > > If I log into unstable9s > SunOS unstable9s 5.9 Generic_Virtual sun4u sparc SUNW,SPARC-Enterprise-T5220 > > I see the following log: > > <...> > > # Checkpkg suggests adding the following lines to the GAR recipe: > # This is a summary; see above for details. > ARCHALL_CSWgnustep-make = 1 > > gmake: Leaving directory '/home/rmottola/opencsw/gnustep-make/trunk' > Connection to unstable10x closed. > > The following packages have been built during this invocation: > > * Platform solaris10-sparc (built on host 'unstable10s') > CSWgnustep-make /home/rmottola/pkgs/gnustep_make-2.6.6,REV=2014.09.16-SunOS5.10-sparc-CSW.pkg.gz > > * Platform solaris10-i386 (built on host 'unstable10x') > CSWgnustep-make /home/rmottola/pkgs/gnustep_make-2.6.6,REV=2014.09.16-SunOS5.10-i386-CSW.pkg.gz > > why does it build two packages, on other two machines? and not "itself"? How do I generate the sparc 9 package (and x86 package) ? > > Is the mgar tool somehow "smart" and does a grid build? and how do I tell it what to? not all combination may be working. Indeed :-) That is platforms support: https://buildfarm.opencsw.org/trac/wiki/Platforms Default is Solaris 10 only, if you want extra/other platforms you must specify that in the Makefile with PACKAGING_PLATFORMS. However, if you don?t have any platform configuration on the server where you are then GAR behaves a little differently and just builds where it is running on due to lack of information. If you have built at home this may have confused you. 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From maciej at opencsw.org Wed Sep 17 09:47:46 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 17 Sep 2014 08:47:46 +0100 Subject: Update of MySQL to 5.6 In-Reply-To: <5418872C.30907@opencsw.org> References: <54184F25.8060408@opencsw.org> <5418872C.30907@opencsw.org> Message-ID: 2014-09-16 19:53 GMT+01:00 Laurent Blume : > Sounds reasonable. Do you have a timeframe already? I could do it the weekend of 27th of September. From laurent at opencsw.org Wed Sep 17 13:19:49 2014 From: laurent at opencsw.org (Laurent Blume) Date: Wed, 17 Sep 2014 13:19:49 +0200 Subject: Update of MySQL to 5.6 In-Reply-To: References: <54184F25.8060408@opencsw.org> <5418872C.30907@opencsw.org> Message-ID: <54196E55.1040206@opencsw.org> Le 2014/09/17 09:47 +0200, Matchek a ?crit: > 2014-09-16 19:53 GMT+01:00 Laurent Blume : >> Sounds reasonable. Do you have a timeframe already? > > I could do it the weekend of 27th of September. > Okay then. Laurent From maciej at opencsw.org Wed Sep 17 14:35:11 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 17 Sep 2014 13:35:11 +0100 Subject: Update of MySQL to 5.6 In-Reply-To: <54196E55.1040206@opencsw.org> References: <54184F25.8060408@opencsw.org> <5418872C.30907@opencsw.org> <54196E55.1040206@opencsw.org> Message-ID: 2014-09-17 12:19 GMT+01:00 Laurent Blume : >> >> I could do it the weekend of 27th of September. >> > > Okay then. After 5 seconds of strenuous thinking: this is less than 2 weeks, so you can push the new MySQL, and I will release stable before your new packages hit the testing catalog. Don't wait! Maciej From laurent at opencsw.org Wed Sep 17 15:32:50 2014 From: laurent at opencsw.org (Laurent Blume) Date: Wed, 17 Sep 2014 15:32:50 +0200 Subject: Update of MySQL to 5.6 In-Reply-To: References: <54184F25.8060408@opencsw.org> <5418872C.30907@opencsw.org> <54196E55.1040206@opencsw.org> Message-ID: <54198D82.3030208@opencsw.org> Le 2014/09/17 14:35 +0200, Matchek a ?crit: > 2014-09-17 12:19 GMT+01:00 Laurent Blume : >>> >>> I could do it the weekend of 27th of September. >>> >> >> Okay then. > > After 5 seconds of strenuous thinking: this is less than 2 weeks, so > you can push the new MySQL, and I will release stable before your new > packages hit the testing catalog. Don't wait! The 4th second is the one that really counts. Okay, so it should hit unstable before this weekend :-) Laurent From rmottola at opencsw.org Wed Sep 17 22:14:25 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Wed, 17 Sep 2014 22:14:25 +0200 Subject: putting a dependency on libicu Message-ID: <5419EBA1.3060505@opencsw.org> Hi, what's the best way to mark ICU as a dependency? the version is actually indifferent to me. Currently I have in gnustep-base: BUILD_DEP_PKGS = CSWgmake CSWgcc4objc CSWlibgnutls-dev CSWlibffi-dev CSWlibicu-dev DEP_PKGS = CSWgnustep-make CSWlibgnutls28 CSWlibssl1-0-0 CSWlibffi5 CSWlibicuuc52 which means a generic CSW provided ICU version and a specific 5.2 runtime. What would you do? when I build on unstable10s I get: ==> Verifying installed package CSWlibicu-dev: ok ==> Verifying installed package CSWlibicuuc52: MISSING running pkginfo on unstable10s shows actually quite a maze of stuff: application CSWlibharfbuzz-icu0 libharfbuzz_icu0 - OpenType text shaping engine, libharfbuzz-icu.so.0 application CSWlibicu-dev libicu_dev - Development files for libicu.so.52 application CSWlibicu46 libicu46 - International Components for Unicode, libicu*.so.46 application CSWlibicudata48 libicudata48 - International Components for Unicode, libicudata.so.48 application CSWlibicudata49 libicudata49 - International Components for Unicode, libicudata.so.49 application CSWlibicudata50 libicudata50 - International Components for Unicode, libicudata.so.50 application CSWlibicudata51 libicudata51 - International Components for Unicode, libicudata.so.51 application CSWlibicudata52 libicudata52 - International Components for Unicode, libicudata.so.52 application CSWlibicui18n48 libicui18n48 - International Components for Unicode, libicui18n.so.48 application CSWlibicui18n49 libicui18n49 - International Components for Unicode, libicui18n.so.49 application CSWlibicui18n50 libicui18n50 - International Components for Unicode, libicui18n.so.50 application CSWlibicui18n51 libicui18n51 - International Components for Unicode, libicui18n.so.51 application CSWlibicui18n52 libicui18n52 - International Components for Unicode, libicui18n.so.52 application CSWlibicuio48 libicuio48 - International Components for Unicode, libicuio.so.48 application CSWlibicuio49 libicuio49 - International Components for Unicode, libicuio.so.49 application CSWlibicuio50 libicuio50 - International Components for Unicode, libicuio.so.50 application CSWlibicuio51 libicuio51 - International Components for Unicode, libicuio.so.51 application CSWlibicuio52 libicuio52 - International Components for Unicode, libicuio.so.52 application CSWlibicule48 libicule48 - International Components for Unicode, libicule.so.48 application CSWlibicule49 libicule49 - International Components for Unicode, libicule.so.49 application CSWlibicule50 libicule50 - International Components for Unicode, libicule.so.50 application CSWlibicule51 libicule51 - International Components for Unicode, libicule.so.51 application CSWlibicule52 libicule52 - International Components for Unicode, libicule.so.52 application CSWlibiculx48 libiculx48 - International Components for Unicode, libiculx.so.48 application CSWlibiculx49 libiculx49 - International Components for Unicode, libiculx.so.49 application CSWlibiculx50 libiculx50 - International Components for Unicode, libiculx.so.50 application CSWlibiculx51 libiculx51 - International Components for Unicode, libiculx.so.51 application CSWlibiculx52 libiculx52 - International Components for Unicode, libiculx.so.52 application CSWlibicutest48 libicutest48 - International Components for Unicode, libicutest.so.48 application CSWlibicutest49 libicutest49 - International Components for Unicode, libicutest.so.49 application CSWlibicutest50 libicutest50 - International Components for Unicode, libicutest.so.50 application CSWlibicutest51 libicutest51 - International Components for Unicode, libicutest.so.51 application CSWlibicutest52 libicutest52 - International Components for Unicode, libicutest.so.52 application CSWlibicutu48 libicutu48 - International Components for Unicode, libicutu.so.48 application CSWlibicutu49 libicutu49 - International Components for Unicode, libicutu.so.49 application CSWlibicutu50 libicutu50 - International Components for Unicode, libicutu.so.50 application CSWlibicutu51 libicutu51 - International Components for Unicode, libicutu.so.51 application CSWlibicutu52 libicutu52 - International Components for Unicode, libicutu.so.52 application CSWlibicuuc48 libicuuc48 - International Components for Unicode, libicuuc.so.48 application CSWlibicuuc49 libicuuc49 - International Components for Unicode, libicuuc.so.49 application CSWlibicuuc50 libicuuc50 - International Components for Unicode, libicuuc.so.50 application CSWlibicuuc51 libicuuc51 - International Components for Unicode, libicuuc.so.51 application CSWlibicuuc52 libicuuc52 - International Components for Unicode, libicuuc.so.52 it seems they are "split" and only for 4.6 there is a full version. What are the splits for? suggestions? Riccardo From laurent at opencsw.org Wed Sep 17 22:19:53 2014 From: laurent at opencsw.org (Laurent Blume) Date: Wed, 17 Sep 2014 22:19:53 +0200 Subject: putting a dependency on libicu In-Reply-To: <5419EBA1.3060505@opencsw.org> References: <5419EBA1.3060505@opencsw.org> Message-ID: <5419ECE9.4090406@opencsw.org> Le 2014/09/17 22:14 +0200, Riccardo Mottola a ?crit: > Hi, > > what's the best way to mark ICU as a dependency? the version is actually > indifferent to me. > > Currently I have in gnustep-base: > BUILD_DEP_PKGS = CSWgmake CSWgcc4objc CSWlibgnutls-dev CSWlibffi-dev > CSWlibicu-dev > DEP_PKGS = CSWgnustep-make CSWlibgnutls28 CSWlibssl1-0-0 CSWlibffi5 > CSWlibicuuc52 > it seems they are "split" and only for 4.6 there is a full version. What > are the splits for? > > suggestions? Remove that DEP_PKGS, mgar package will tell you what dependencies you need to add, you basically only need to copy/paste what it tells you 9 times out of 10. Laurent From pfelecan at opencsw.org Thu Sep 18 12:11:00 2014 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 18 Sep 2014 12:11:00 +0200 Subject: lost in crypto space Message-ID: I'm packaging a project in need of GPG support and I'm encountering an unusual situation, at least for me: GPGME:150: Invalid crypto engine Here is a test case: /* gcc -std=gnu99 -I/opt/csw/include gpgeng.c -m32 -march=pentiumpro -L/opt/csw/lib -lgpgme -lgpg-error -o gpgeng */ #define _FILE_OFFSET_BITS 64 #include #include #include #include int main(int argc, char** argv) { int rc = EXIT_SUCCESS; gpg_error_t err; err = gpgme_engine_check_version(GPGME_PROTOCOL_OpenPGP); if (err != 0) { rc = EXIT_FAILURE; fprintf(stderr, "gpgme failed with %s:%d: %s\n", gpg_strsource(err), gpg_err_code(err), gpg_strerror(err)); } exit(rc); } What am I missing? TIA -- Peter From rmottola at opencsw.org Thu Sep 18 19:40:42 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Thu, 18 Sep 2014 19:40:42 +0200 Subject: putting a dependency on libicu In-Reply-To: <5419ECE9.4090406@opencsw.org> References: <5419EBA1.3060505@opencsw.org> <5419ECE9.4090406@opencsw.org> Message-ID: <541B191A.3090709@opencsw.org> Hi, Laurent Blume wrote: > Remove that DEP_PKGS, mgar package will tell you what dependencies you > need to add, you basically only need to copy/paste what it tells you 9 > times out of 10. indeed, and I see a lot of stuff that worries me.. I have: BUILD_DEP_PKGS = CSWgmake CSWgcc4objc CSWlibgnutls-dev CSWlibffi-dev CSWgnustep-make DEP_PKGS = CSWgnustep-make DEP_PKGS += CSWlibffi5 BUILD_DEP_PKGS += CSWlibicu-dev DEP_PGKS += CSWlibicui18n52 CSWlibicuuc52 CSWlibicudata52 DEP_PGKS += CSWlibobjc4 CSWlibgcc-s1 CSWlibgmp10 DEP_PGKS += CSWlibssl1-0-0 CSWlibgnutls28 CSWlibgcrypt20 BUILD_DEP_PKGS += CSWlibxml2-dev CSWlibxslt-dev DEP_PGKS += CSWlibxslt1 CSWlibxml2-2 BUILD_DEP_PKGS += CSWlibiconv-dev DEP_PKGS += CSWlibiconv2 and get: CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibgcrypt11 CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibz1 CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibobjc3 CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibicui18n49 CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibicuuc49 CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibxslt1 CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibgnutls26 CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibxml2-2 CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibicudata49 CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibgcc-s1 CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibgmp10 CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibffi4 CHECKPKG_OVERRIDES_CSWgnustep-base += surplus-dependency|CSWlibffi5 it looks like a mess It seems that several times older libraries get picked up, why? sometimes the corresponding I selected is marked as surplus, sometimes not which makes me fear "double linking" of different versions 1) objc3 (I really want 4 if I compile with gcc4 or it will crash) 2) libffi 3) gnutls 4) libicu components Other appear as missing, but they are there! 1) CSWlibxml2-2 2) CSWlibxslt1 From laurent at opencsw.org Thu Sep 18 20:30:53 2014 From: laurent at opencsw.org (Laurent Blume) Date: Thu, 18 Sep 2014 20:30:53 +0200 Subject: putting a dependency on libicu In-Reply-To: <541B191A.3090709@opencsw.org> References: <5419EBA1.3060505@opencsw.org> <5419ECE9.4090406@opencsw.org> <541B191A.3090709@opencsw.org> Message-ID: <541B24DD.8020002@opencsw.org> Le 2014/09/18 19:40 +0200, Riccardo Mottola a ?crit: > and get: > CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibgcrypt11 > CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibz1 > CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibobjc3 > CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibicui18n49 > CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibicuuc49 > CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibxslt1 > CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibgnutls26 > CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibxml2-2 > CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibicudata49 > CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibgcc-s1 > CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibgmp10 > CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibffi4 > CHECKPKG_OVERRIDES_CSWgnustep-base += surplus-dependency|CSWlibffi5 Don't look at the overrides, look above, where it tells you the proper line to add. Also, there's a long standing ld bug on the Solaris sparc build boxes, which I think has not been fixed. So build on x86, and check dependencies there. When that's good, look eg at the ImageMagick recipe to add a conditional section to make the sparc ld happy. > it looks like a mess > It seems that several times older libraries get picked up, why? > sometimes the corresponding I selected is marked as surplus, sometimes > not which makes me fear "double linking" of different versions > 1) objc3 (I really want 4 if I compile with gcc4 or it will crash) > 2) libffi > 3) gnutls > 4) libicu components Double check your config.log to see what was picked up by configure. > Other appear as missing, but they are there! > 1) CSWlibxml2-2 > 2) CSWlibxslt1 There, where? Did you check with ldd? Laurent From dam at opencsw.org Fri Sep 19 10:24:41 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 19 Sep 2014 10:24:41 +0200 Subject: down ? In-Reply-To: References: Message-ID: <3CC3F31D-AE0C-4185-8293-92F1CCE365AB@opencsw.org> Hi Peter, Am 19.09.2014 um 09:14 schrieb Peter FELECAN via buildfarm : > I'm trying to log in with no avail. What's up? The builfarm T5220 paniced tonight with NULL pointer exception in UNIX :-( I opened a service request, everything should be working again. 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From pfelecan at opencsw.org Fri Sep 19 16:32:08 2014 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 19 Sep 2014 16:32:08 +0200 Subject: lost in crypto space In-Reply-To: (Peter FELECAN's message of "Thu, 18 Sep 2014 12:11:00 +0200") References: Message-ID: Peter FELECAN writes: > I'm packaging a project in need of GPG support and I'm encountering an > unusual situation, at least for me: GPGME:150: Invalid crypto engine Answering myself for documentation purposes: after through exploration I found that our libgpgme package is brain-dead; when calling up the gpg infrastructure instead of providing the name of the respective programs it tries to execute the /opt/csw/bin directory! I'm filling a bug report with all the relevant information: https://www.opencsw.org/mantis/view.php?id=5206 -- Peter From kester at opencsw.org Mon Sep 22 16:59:58 2014 From: kester at opencsw.org (Kester Habermann) Date: Mon, 22 Sep 2014 16:59:58 +0200 Subject: Python version issues Message-ID: <20140922145958.GC21223@bender.opencsw.org> Hello, python-config is linked to a non-existent file: kester at unstable10s [unstable10s]:~ > ls -l /opt/csw/bin/python-config lrwxrwxrwx 1 root other 27 Aug 10 2013 /opt/csw/bin/python-config -> /opt/csw/bin/python-config2 kester at unstable10s [unstable10s]:~ > ls -l /opt/csw/bin/python-config2 lrwxrwxrwx 1 root other 29 Nov 3 2013 /opt/csw/bin/python-config2 -> /opt/csw/bin/python-config2.6 kester at unstable10s [unstable10s]:~ > ls -l /opt/csw/bin/python-config2.6 /opt/csw/bin/python-config2.6: No such file or directory This should probably point to: /opt/csw/bin/python2.6-config I have not raised a Mantis issue, as I am not sure where this is done (Python package, alternatives, ?). If I install CSWpython27 and remove CSWpython26 then the link is changed to: /opt/csw/bin/python-config2 -> /opt/csw/bin/python-config2.7 which also does not exist. It should probably point to: /opt/csw/bin/python2.7-config I also noticed, if I install python 2.6 and python 2.7 at the same time, the links remain pointing to 2.6, e. g.: /opt/csw/bin/python2 -> python2.6 It is even worse: If I only have python 2.7 installed and the links set up to make /opt/csw/bin/python2 point to python2.7 and the python2.6 package gets installed as a dependency then link from /opt/csw/bin/python2 changes back to python2.6 which is not what I want. On a related issue, in the gar files we have: MODULATIONS_PYTHON_VERSION = 2_6 2_7 How much changes would it take to also add 3_3? Regards Kester From maciej at opencsw.org Tue Sep 23 13:19:45 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 23 Sep 2014 12:19:45 +0100 Subject: Python version issues In-Reply-To: <20140922145958.GC21223@bender.opencsw.org> References: <20140922145958.GC21223@bender.opencsw.org> Message-ID: Hi Kester, 2014-09-22 15:59 GMT+01:00 Kester Habermann : > > python-config is linked to a non-existent file Feel free to modify the build files to fix these issues. There are some decisions to be made, for example whether we default to Python 2.6 or 2.7 for Python 2.x. We've now rebuilt many modules to 2.7[1], so it can be reasonable to switch the default. Maciej [1] Status of Python modules: http://buildfarm.opencsw.org/~maciej/python-modules.html From maciej at opencsw.org Tue Sep 23 13:21:13 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 23 Sep 2014 12:21:13 +0100 Subject: Modules for Python 3.x Message-ID: 2014-09-22 15:59 GMT+01:00 Kester Habermann : > On a related issue, in the gar files we have: > MODULATIONS_PYTHON_VERSION = 2_6 2_7 > How much changes would it take to also add 3_3? I don't know, you need to try and see what happens. From dam at opencsw.org Tue Sep 23 13:28:12 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 23 Sep 2014 13:28:12 +0200 Subject: Python version issues In-Reply-To: <20140922145958.GC21223@bender.opencsw.org> References: <20140922145958.GC21223@bender.opencsw.org> Message-ID: <0A2F596C-F518-437C-B4AF-5250AC5C58FF@opencsw.org> Hi Kester, Am 22.09.2014 um 16:59 schrieb Kester Habermann : > python-config is linked to a non-existent file: > > kester at unstable10s [unstable10s]:~ > ls -l /opt/csw/bin/python-config > lrwxrwxrwx 1 root other 27 Aug 10 2013 /opt/csw/bin/python-config -> /opt/csw/bin/python-config2 > kester at unstable10s [unstable10s]:~ > ls -l /opt/csw/bin/python-config2 > lrwxrwxrwx 1 root other 29 Nov 3 2013 /opt/csw/bin/python-config2 -> /opt/csw/bin/python-config2.6 > kester at unstable10s [unstable10s]:~ > ls -l /opt/csw/bin/python-config2.6 > /opt/csw/bin/python-config2.6: No such file or directory > > This should probably point to: /opt/csw/bin/python2.6-config > > I have not raised a Mantis issue, as I am not sure where this is done > (Python package, alternatives, ?). Yes, this is an error on the Makefile with the alternatives definition: https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/pkg/lang-python/python/trunk/Makefile#221 I?ll try to fix that issue, some experimental packages are here: http://buildfarm.opencsw.org/experimental.html#python > If I install CSWpython27 and remove CSWpython26 then the link is changed to: > /opt/csw/bin/python-config2 -> /opt/csw/bin/python-config2.7 > which also does not exist. Alternatives is behaving as configured, the configuration is wrong. > It should probably point to: /opt/csw/bin/python2.7-config Yes. > I also noticed, if I install python 2.6 and python 2.7 at the same > time, the links remain pointing to 2.6, e. g.: > /opt/csw/bin/python2 -> python2.6 > > It is even worse: If I only have python 2.7 installed and the links set up to make > /opt/csw/bin/python2 point to python2.7 and the python2.6 package gets installed > as a dependency then link from /opt/csw/bin/python2 changes back to python2.6 > which is not what I want. > > On a related issue, in the gar files we have: > MODULATIONS_PYTHON_VERSION = 2_6 2_7 > How much changes would it take to also add 3_3? Not much, but AFAIK Python 3 needs special care from the module authors. Feel free to set the extra modulation in you tree and see how far you get. If it works reasonably well we can move that into the main branch. 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From dam at opencsw.org Tue Sep 23 15:32:12 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 23 Sep 2014 15:32:12 +0200 Subject: Python version issues In-Reply-To: <0A2F596C-F518-437C-B4AF-5250AC5C58FF@opencsw.org> References: <20140922145958.GC21223@bender.opencsw.org> <0A2F596C-F518-437C-B4AF-5250AC5C58FF@opencsw.org> Message-ID: Hi Kester, Am 23.09.2014 um 13:28 schrieb Dagobert Michelsen : > Am 22.09.2014 um 16:59 schrieb Kester Habermann : >> python-config is linked to a non-existent file: >> >> kester at unstable10s [unstable10s]:~ > ls -l /opt/csw/bin/python-config >> lrwxrwxrwx 1 root other 27 Aug 10 2013 /opt/csw/bin/python-config -> /opt/csw/bin/python-config2 >> kester at unstable10s [unstable10s]:~ > ls -l /opt/csw/bin/python-config2 >> lrwxrwxrwx 1 root other 29 Nov 3 2013 /opt/csw/bin/python-config2 -> /opt/csw/bin/python-config2.6 >> kester at unstable10s [unstable10s]:~ > ls -l /opt/csw/bin/python-config2.6 >> /opt/csw/bin/python-config2.6: No such file or directory >> >> This should probably point to: /opt/csw/bin/python2.6-config >> >> I have not raised a Mantis issue, as I am not sure where this is done >> (Python package, alternatives, ?). > > Yes, this is an error on the Makefile with the alternatives definition: > https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/pkg/lang-python/python/trunk/Makefile#221 > I?ll try to fix that issue, some experimental packages are here: > http://buildfarm.opencsw.org/experimental.html#python I fixed the issue and just pushed updated packages to unstable/. 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From maciej at opencsw.org Tue Sep 23 21:46:03 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 23 Sep 2014 20:46:03 +0100 Subject: Python version issues In-Reply-To: References: <20140922145958.GC21223@bender.opencsw.org> <0A2F596C-F518-437C-B4AF-5250AC5C58FF@opencsw.org> Message-ID: 2014-09-23 14:32 GMT+01:00 Dagobert Michelsen : > I fixed the issue and just pushed updated packages to unstable/. Thanks Dago for handling this! Maciej From kester at opencsw.org Wed Sep 24 15:41:00 2014 From: kester at opencsw.org (Kester Habermann) Date: Wed, 24 Sep 2014 15:41:00 +0200 Subject: Python version issues In-Reply-To: References: <20140922145958.GC21223@bender.opencsw.org> <0A2F596C-F518-437C-B4AF-5250AC5C58FF@opencsw.org> Message-ID: <20140924134100.GD21223@bender.opencsw.org> Hi Dagobert, On Tue, Sep 23, 2014 at 03:32:12PM +0200, Dagobert Michelsen wrote: > I fixed the issue and just pushed updated packages to unstable/. Thanks for building the package. It looks good. Regards Kester From jh at opencsw.org Fri Sep 26 14:56:45 2014 From: jh at opencsw.org (Jan Holzhueter) Date: Fri, 26 Sep 2014 14:56:45 +0200 Subject: Mysql hickups. (was The Python web apps throw 500s) Message-ID: <5425628D.5050405@opencsw.org> Hi, had some time to debug it :) Simple problem someone somehow updated the mysql Packege on our mysql zone. That caused an update from Mysql Version 5.0 to 5.5 (all praise whom they like that this did not cause any database problems ) But with this the my.cnf file moved from /opt/csw/mysql5 to /etc/opt/csw but without any migration script. So some default was loaded with did not fit our environment. I fixed that now. It should not give those errors anymore I hope. @Carsten your mysql trac database needs to be looked at. To do the update the cswmysql5:trac Service is broken now and starts not your database anymore. I disabled it for now. If you have the time please fix it. Greetings Jan From grzemba at contac-dt.de Fri Sep 26 16:15:08 2014 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Fri, 26 Sep 2014 16:15:08 +0200 Subject: Mysql hickups. (was The Python web apps throw 500s) In-Reply-To: References: <5425628D.5050405@opencsw.org> Message-ID: mysql trac is online again. I have changed /etc/opt/csw/init.d/cswmysql5 for support instances: root at mysql [mysql]:/etc/opt/csw/init.d > diff cswmysql5.org cswmysql5 41c41,42 < datadir= --- > datadir=`/bin/svcprop -p config/datadir ${SMF_FMRI} 2>/dev/null` > defaults=`/bin/svcprop -p config/defaults ${SMF_FMRI} 2>/dev/null` 293a295,299 > if [ ! -z "$defaults" ] > then > defaults_args="--defaults-file=$defaults" > extra_args="$defaults_args $extra_args" > fi 323c329 < $bindir/mysqld_safe --datadir="$datadir" --pid-file="$mysqld_pid_file_path" $other_args >/dev/null 2>&1 & --- > $bindir/mysqld_safe $defaults_args --datadir="$datadir" --pid-file="$mysqld_pid_file_path" $other_args >/dev/null 2>&1 & I don't if it is the best place for do this but this kind is a usual way. @ Laurent: what do you mean, would you incorporate this script change in your package? Am 26.09.14 schrieb Jan Holzhueter : > Hi, > had some time to debug it :) > > Simple problem someone somehow updated the mysql Packege on our mysql zone. > > That caused an update from Mysql Version 5.0 to 5.5 (all praise whom > they like that this did not cause any database problems ) > > But with this the my.cnf file moved from /opt/csw/mysql5 to /etc/opt/csw > but without any migration script. So some default was loaded with did > not fit our environment. I fixed that now. > It should not give those errors anymore I hope. > > @Carsten your mysql trac database needs to be looked at. To do the > update the cswmysql5:trac Service is broken now and starts not your > database anymore. I disabled it for now. If you have the time please fix it. > > Greetings > Jan > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Fri Sep 26 16:24:52 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 26 Sep 2014 15:24:52 +0100 Subject: Mysql hickups. (was The Python web apps throw 500s) In-Reply-To: <5425628D.5050405@opencsw.org> References: <5425628D.5050405@opencsw.org> Message-ID: 2014-09-26 13:56 GMT+01:00 Jan Holzhueter via buildfarm : > Simple problem someone somehow updated the mysql Packege on our mysql zone. I'm thinking whether it could have been me. It probably was. I have a vague recollection of upgrading packages there when I needed some new packages, and I didn't want to have a mix of old and new packages. Maybe I missed the configuration file change. Sorry about that. Maciej From laurent at opencsw.org Fri Sep 26 17:21:55 2014 From: laurent at opencsw.org (Laurent Blume) Date: Fri, 26 Sep 2014 17:21:55 +0200 Subject: Mysql hickups. (was The Python web apps throw 500s) In-Reply-To: References: <5425628D.5050405@opencsw.org> Message-ID: <54258493.5010500@opencsw.org> I will look into it. For now, be careful that I'm going to push a new package that will overwrite it (now that MySQL works, the MySQL packages could be created :-) My first idea is that it could be handled automatically, following this rough outline: - CSW package installs cswservice:default - users can create cswservice:otherinstance if they wish - on package removal, cswservice:* are handled by CAS (instead of just the :default) - so on updates, all are stopped/restarted. Only :default is updated, the others stay of course the responsibility of their creators Makes sense? Laurent Le 2014/09/26 16:15 +0200, Carsten Grzemba a ?crit: > mysql trac is online again. > > I have changed /etc/opt/csw/init.d/cswmysql5 for support instances: > > root at mysql [mysql]:/etc/opt/csw/init.d > diff cswmysql5.org cswmysql5 > 41c41,42 > < datadir= > --- > > datadir=`/bin/svcprop -p config/datadir ${SMF_FMRI} 2>/dev/null` > > defaults=`/bin/svcprop -p config/defaults ${SMF_FMRI} 2>/dev/null` > 293a295,299 > > if [ ! -z "$defaults" ] > > then > > defaults_args="--defaults-file=$defaults" > > extra_args="$defaults_args $extra_args" > > fi > 323c329 > < $bindir/mysqld_safe --datadir="$datadir" > --pid-file="$mysqld_pid_file_path" $other_args >/dev/null 2>&1 & > --- > > $bindir/mysqld_safe $defaults_args --datadir="$datadir" > --pid-file="$mysqld_pid_file_path" $other_args >/dev/null 2>&1 & > > I don't if it is the best place for do this but this kind is a usual way. > @ Laurent: what do you mean, would you incorporate this script change in > your package? > > Am 26.09.14 schrieb *Jan Holzhueter * : >> Hi, >> had some time to debug it :) >> >> Simple problem someone somehow updated the mysql Packege on our mysql >> zone. >> >> That caused an update from Mysql Version 5.0 to 5.5 (all praise whom >> they like that this did not cause any database problems ) >> >> But with this the my.cnf file moved from /opt/csw/mysql5 to /etc/opt/csw >> but without any migration script. So some default was loaded with did >> not fit our environment. I fixed that now. >> It should not give those errors anymore I hope. >> >> @Carsten your mysql trac database needs to be looked at. To do the >> update the cswmysql5:trac Service is broken now and starts not your >> database anymore. I disabled it for now. If you have the time please >> fix it. >> >> Greetings >> Jan >> >> From maciej at opencsw.org Mon Sep 29 02:01:58 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 29 Sep 2014 01:01:58 +0100 Subject: New stable release: bratislava In-Reply-To: References: Message-ID: Below is a copy of an announcement I've just sent to users@ and announce at . --Maciej 2014-09-29 1:00 GMT+01:00 Maciej (Matchek) Blizi?ski : > Hello OpenCSW users, > > Six months have passed since we've promoted 'kiel' to stable. We have > released a new stable: bratislava. > > Before: > > unstable > testing ? bratislava > stable ? kiel > > After: > > unstable > testing ? munich > stable ? bratislava > > Upgrading notes: > > I. If your pkgutil.conf contains a line similar to this: > > mirror=http://mirror.opencsw.org/opencsw/stable/ > > ...you're subscribed to the stable release and you will notice changes > automatically. > > II. If your pkgutil.conf contains a line similar to this: > > mirror=http://mirror.opencsw.org/opencsw/dublin/ > > ...you will not notice any changes, but you should consider moving over to the > kiel release. You can upgrade from kiel to bratislava by reconfiguring pkgutil. > > mirror=http://mirror.opencsw.org/opencsw/bratislava/ > > Once the configuration is changed, this command will update all the packages: > > pkgutil --yes --catalog --upgrade > > In case of any questions or problems, please contact us either on the mailing > list or on the IRC channel, #opencsw on Freenode. From grzemba at contac-dt.de Mon Sep 29 09:03:26 2014 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Mon, 29 Sep 2014 09:03:26 +0200 Subject: Mysql hickups. (was The Python web apps throw 500s) In-Reply-To: References: <5425628D.5050405@opencsw.org> <54258493.5010500@opencsw.org> Message-ID: Am 26.09.14 schrieb Laurent Blume : > I will look into it. > For now, be careful that I'm going to push a new package that will overwrite it (now that MySQL works, the MySQL packages could be created :-) > > My first idea is that it could be handled automatically, following this rough outline: > - CSW package installs cswservice:default > - users can create cswservice:otherinstance if they wish > - on package removal, cswservice:* are handled by CAS (instead of just the :default) > - so on updates, all are stopped/restarted. Only :default is updated, the others stay of course the responsibility of their creators > > Makes sense? > Yes, this sounds good. > > > Laurent > > Le 2014/09/26 16:15 +0200, Carsten Grzemba a ?crit: > >mysql trac is online again. > > > >I have changed /etc/opt/csw/init.d/cswmysql5 for support instances: > > > >root at mysql [mysql]:/etc/opt/csw/init.d > diff cswmysql5.org cswmysql5 > >41c41,42 > >< datadir= > >--- > > > datadir=`/bin/svcprop -p config/datadir ${SMF_FMRI} 2>/dev/null` > > > defaults=`/bin/svcprop -p config/defaults ${SMF_FMRI} 2>/dev/null` > >293a295,299 > > > if [ ! -z "$defaults" ] > > > then > > > defaults_args="--defaults-file=$defaults" > > > extra_args="$defaults_args $extra_args" > > > fi > >323c329 > >< $bindir/mysqld_safe --datadir="$datadir" > >--pid-file="$mysqld_pid_file_path" $other_args >/dev/null 2>&1 & > >--- > > > $bindir/mysqld_safe $defaults_args --datadir="$datadir" > >--pid-file="$mysqld_pid_file_path" $other_args >/dev/null 2>&1 & > > > >I don't if it is the best place for do this but this kind is a usual way. > >@ Laurent: what do you mean, would you incorporate this script change in > >your package? > > > >Am 26.09.14 schrieb *Jan Holzhueter * : > >>Hi, > >>had some time to debug it :) > >> > >>Simple problem someone somehow updated the mysql Packege on our mysql > >>zone. > >> > >>That caused an update from Mysql Version 5.0 to 5.5 (all praise whom > >>they like that this did not cause any database problems ) > >> > >>But with this the my.cnf file moved from /opt/csw/mysql5 to /etc/opt/csw > >>but without any migration script. So some default was loaded with did > >>not fit our environment. I fixed that now. > >>It should not give those errors anymore I hope. > >> > >>@Carsten your mysql trac database needs to be looked at. To do the > >>update the cswmysql5:trac Service is broken now and starts not your > >>database anymore. I disabled it for now. If you have the time please > >>fix it. > >> > >>Greetings > >>Jan > >> > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jh at opencsw.org Mon Sep 29 11:52:14 2014 From: jh at opencsw.org (Jan Holzhueter) Date: Mon, 29 Sep 2014 11:52:14 +0200 Subject: Linker Problem on Sparc Servers. (after Kernel update) Message-ID: <54292BCE.6050203@opencsw.org> Hi, maybe I missed it during my vacation. But looks like Oracle fixed something in that area: https://support.oracle.com/epmos/faces/BugDisplay?_afrLoop=189010529288142&id=18175522&_afrWindowMode=0&_adf.ctrl-state=m8erilfzj_153 Bug 18175522 : WITH 147147-26 -ZIGNORE WRONGLY KEEPS LIBRARIES FOR DEPENDENCY COMPENSATION Thats patched with latest Kernel: 150400-16. Maybe it's worth a try. Yann did you ever hear back from them about the case you opened? Greetings Jan From yann at pleiades.fr.eu.org Mon Sep 29 12:00:00 2014 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Mon, 29 Sep 2014 12:00:00 +0200 Subject: Linker Problem on Sparc Servers. (after Kernel update) In-Reply-To: <54292BCE.6050203@opencsw.org> References: <54292BCE.6050203@opencsw.org> Message-ID: Hi Jan, Yes I had an update last week to ask me to test this patch and I asked Dago if he could test it on the build farm, but he needed to be back at the office to perform this update. Dago, will you be back at the office soon ? Yann 2014-09-29 11:52 GMT+02:00 Jan Holzhueter : > Hi, > maybe I missed it during my vacation. > But looks like Oracle fixed something in that area: > > > https://support.oracle.com/epmos/faces/BugDisplay?_afrLoop=189010529288142&id=18175522&_afrWindowMode=0&_adf.ctrl-state=m8erilfzj_153 > > Bug 18175522 : WITH 147147-26 -ZIGNORE WRONGLY KEEPS LIBRARIES FOR > DEPENDENCY COMPENSATION > > Thats patched with latest Kernel: > > 150400-16. > > Maybe it's worth a try. > > Yann did you ever hear back from them about the case you opened? > > Greetings > Jan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Tue Sep 30 13:00:52 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 30 Sep 2014 13:00:52 +0200 Subject: Linker Problem on Sparc Servers. (after Kernel update) In-Reply-To: References: <54292BCE.6050203@opencsw.org> Message-ID: <931EF64F-E6F7-44EE-AC1A-CDC9409F5810@opencsw.org> Hi Yann, Am 29.09.2014 um 12:00 schrieb Yann Rouillard : > Yes I had an update last week to ask me to test this patch and I asked Dago if he could test it on the build farm, but he needed to be back at the office to perform this update. > > Dago, will you be back at the office soon ? There is new machine with ip 192.168.1.100, it is a V440 with just Sun Studio 12 and 150400-16. Please give it a try, I would like to turn the machine off again soon. Best regards ? Dago > > Yann > > > > 2014-09-29 11:52 GMT+02:00 Jan Holzhueter : > Hi, > maybe I missed it during my vacation. > But looks like Oracle fixed something in that area: > > https://support.oracle.com/epmos/faces/BugDisplay?_afrLoop=189010529288142&id=18175522&_afrWindowMode=0&_adf.ctrl-state=m8erilfzj_153 > > Bug 18175522 : WITH 147147-26 -ZIGNORE WRONGLY KEEPS LIBRARIES FOR > DEPENDENCY COMPENSATION > > Thats patched with latest Kernel: > > 150400-16. > > Maybe it's worth a try. > > Yann did you ever hear back from them about the case you opened? > > Greetings > Jan > -- "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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From dam at opencsw.org Tue Sep 30 15:21:22 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 30 Sep 2014 15:21:22 +0200 Subject: Linker Problem on Sparc Servers. (after Kernel update) In-Reply-To: <931EF64F-E6F7-44EE-AC1A-CDC9409F5810@opencsw.org> References: <54292BCE.6050203@opencsw.org> <931EF64F-E6F7-44EE-AC1A-CDC9409F5810@opencsw.org> Message-ID: <7592AE51-A149-42E7-AFC6-749AC4F2225D@opencsw.org> Hi, Am 30.09.2014 um 13:00 schrieb Dagobert Michelsen via buildfarm : > Am 29.09.2014 um 12:00 schrieb Yann Rouillard : >> Yes I had an update last week to ask me to test this patch and I asked Dago if he could test it on the build farm, but he needed to be back at the office to perform this update. >> >> Dago, will you be back at the office soon ? > > There is new machine with ip 192.168.1.100, it is a V440 with just Sun Studio 12 > and 150400-16. Please give it a try, I would like to turn the machine off again soon. The patch looks good. I will install it ASAP on the farm. 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From yann at pleiades.fr.eu.org Tue Sep 30 21:04:15 2014 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Tue, 30 Sep 2014 21:04:15 +0200 Subject: Linker Problem on Sparc Servers. (after Kernel update) In-Reply-To: <7592AE51-A149-42E7-AFC6-749AC4F2225D@opencsw.org> References: <54292BCE.6050203@opencsw.org> <931EF64F-E6F7-44EE-AC1A-CDC9409F5810@opencsw.org> <7592AE51-A149-42E7-AFC6-749AC4F2225D@opencsw.org> Message-ID: Cool, tell me when it's done. I will check if everything is fine on packages that suffered from the issue. Yann 2014-09-30 15:21 GMT+02:00 Dagobert Michelsen : > Hi, > > Am 30.09.2014 um 13:00 schrieb Dagobert Michelsen via buildfarm < > buildfarm at lists.opencsw.org>: > > Am 29.09.2014 um 12:00 schrieb Yann Rouillard : > > Yes I had an update last week to ask me to test this patch and I asked > Dago if he could test it on the build farm, but he needed to be back at the > office to perform this update. > > Dago, will you be back at the office soon ? > > > There is new machine with ip 192.168.1.100, it is a V440 with just Sun > Studio 12 > and 150400-16. Please give it a try, I would like to turn the machine off > again soon. > > > The patch looks good. I will install it ASAP on the farm. > > > 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: