From maciej at opencsw.org Sun May 4 19:29:56 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 4 May 2014 18:29:56 +0100 Subject: We should talk about getting IPS packages going Message-ID: Our community site counts visits. Questions about IPS and Solaris 11 have are visited more often, by about 1 order of magnitude. http://buildfarm.opencsw.org/~maciej/ips-questions.png We're an open source project, so the sole reason why we don't have an IPS repository is that nobody did it yet. From my conversation with Dago about it, there are 2 things that need to be done: 1. IPS backend for GAR 2. build environment - somebody has to administer it I also know that some of our maintainers effectively got inactive because they mainly need / build IPS packages, and we don't have a framework to do that. Each time we talk about IPS, we look a bit like this: http://i1276.photobucket.com/albums/y462/staffpicks/Animated_GIFs/startrek-1.gif Maybe we should get something going, something quick and dirty? It might be something like running "mgar merge" and then a completely different command to build the package? That would be completely fine for now. If the resulting IPS catalog would be in someone's home dir, that would be fine too. When it's done we can move it to a common place. If packages were built on somebody's VM, that would be fine too. Does anybody here manage Solaris 11 hosts? Maciej From maciej at opencsw.org Mon May 5 12:11:25 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 5 May 2014 11:11:25 +0100 Subject: We should talk about getting IPS packages going In-Reply-To: References: Message-ID: Hi Gordon, You need to reply to the list from your @opencsw email address. Maciej On Sun, May 4, 2014 at 11:39 PM, gmarler wrote: > Yes, I'm pretty much only doing S11 and IPS for the past 2-3 years. > > Publishing is currently done via the built in S11 pkgbuild tool, but mgar > could easily outstrip it's lacking features. > > I can manage the S11 host's pkg/server SMF service, and do a continuous > brain dump on everything I've learned. > > And there's thankfully documentation for the IPS packaging concepts that > have been missing for quite some time. > > Stripping out the features in mgar that are native to IPS is probably > important, to avoid duplication of effort. > > > -------- Original message -------- > From: "Maciej (Matchek) Blizi?ski" > Date:05/04/2014 1:29 PM (GMT-05:00) > To: CSW maintainers > Subject: We should talk about getting IPS packages going > > Our community site counts visits. Questions about IPS and Solaris 11 > have are visited more often, by about 1 order of magnitude. > > http://buildfarm.opencsw.org/~maciej/ips-questions.png > > We're an open source project, so the sole reason why we don't have an > IPS repository is that nobody did it yet. From my conversation with > Dago about it, there are 2 things that need to be done: > > 1. IPS backend for GAR > 2. build environment - somebody has to administer it > > I also know that some of our maintainers effectively got inactive > because they mainly need / build IPS packages, and we don't have a > framework to do that. > > Each time we talk about IPS, we look a bit like this: > > http://i1276.photobucket.com/albums/y462/staffpicks/Animated_GIFs/startrek-1.gif > > Maybe we should get something going, something quick and dirty? It > might be something like running "mgar merge" and then a completely > different command to build the package? That would be completely fine > for now. > > If the resulting IPS catalog would be in someone's home dir, that > would be fine too. When it's done we can move it to a common place. > > If packages were built on somebody's VM, that would be fine too. > > Does anybody here manage Solaris 11 hosts? > > Maciej > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmottola at opencsw.org Tue May 6 00:14:52 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Tue, 06 May 2014 00:14:52 +0200 Subject: Solaris 9 support to be removed from GCC upstream In-Reply-To: References: Message-ID: <53680D5C.30806@opencsw.org> Hi, Maciej (Matchek) Blizi?ski wrote: > We haven't built GCC for Solaris 9 in a long while, the version we've > got in the 5.9 repo is 4.6. I was looking if we can refresh it, and I > wanted to report potential compilation errors, but I guess I won't. that's a pity, since my interest is in GNUstep and thus I need objective-c, gcc 4.7 and 4.8 greatly improved Objective-c support. I fear however that nobody will step up? Gcc support for non-mainstream support is certainly not what it used to be :( Riccardo From gmarler at opencsw.org Tue May 6 07:08:10 2014 From: gmarler at opencsw.org (Gordon Marler) Date: Tue, 06 May 2014 01:08:10 -0400 Subject: We should talk about getting IPS packages going In-Reply-To: References: Message-ID: <53686E3A.6030508@opencsw.org> On 05/ 4/14 01:29 PM, Maciej (Matchek) Blizi?ski wrote: > Our community site counts visits. Questions about IPS and Solaris 11 > have are visited more often, by about 1 order of magnitude. > > http://buildfarm.opencsw.org/~maciej/ips-questions.png > > We're an open source project, so the sole reason why we don't have an > IPS repository is that nobody did it yet. From my conversation with > Dago about it, there are 2 things that need to be done: > > 1. IPS backend for GAR > 2. build environment - somebody has to administer it > > I also know that some of our maintainers effectively got inactive > because they mainly need / build IPS packages, and we don't have a > framework to do that. > > Each time we talk about IPS, we look a bit like this: > http://i1276.photobucket.com/albums/y462/staffpicks/Animated_GIFs/startrek-1.gif > > Maybe we should get something going, something quick and dirty? It > might be something like running "mgar merge" and then a completely > different command to build the package? That would be completely fine > for now. > > If the resulting IPS catalog would be in someone's home dir, that > would be fine too. When it's done we can move it to a common place. > > If packages were built on somebody's VM, that would be fine too. > > Does anybody here manage Solaris 11 hosts? > > Maciej > Yes, I'm pretty much only doing S11 and IPS for the past 2-3 years. Publishing is currently done via the built in S11 pkgbuild tool, but mgar could easily outstrip pkgbuild's lacking features. I can manage an S11 host's pkg/server SMF service(s), and do a continuous brain dump on everything I've learned. Thankfully, there's finally documentation for the IPS packaging concepts that have been missing for quite some time: http://docs.oracle.com/cd/E26502_01/html/E21383/index.html Stripping out the features in mgar that are native to IPS is probably important, to avoid duplication of effort. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfelecan at opencsw.org Tue May 6 19:52:33 2014 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 06 May 2014 19:52:33 +0200 Subject: Should OpenCSW joining the software patent non-aggression community? Message-ID: Dear maintainers and members of the foundation, We are invited by Valer Mischenkoto join The Open Invention Network, a community of software patent non-aggression. You can read about this at http://www.openinventionnetwork.com/ I'm asking you, on the behalf of the foundation'sboard, if you wish to join this community. Please read and, if needed, discuss it on this list. If there is a need, we can organize a vote. If, however, in a reasonable lapse of time, lets say 4 week, there is no opposition or a request for vote, I will make the necessary to join the OIN. Thank you -- Peter From bonivart at opencsw.org Tue May 6 20:16:22 2014 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 6 May 2014 20:16:22 +0200 Subject: Should OpenCSW joining the software patent non-aggression community? In-Reply-To: References: Message-ID: On Tue, May 6, 2014 at 7:52 PM, Peter FELECAN wrote: > Dear maintainers and members of the foundation, > > We are invited by Valer Mischenkoto join The Open Invention Network, a > community of software patent non-aggression. > > You can read about this at http://www.openinventionnetwork.com/ > > I'm asking you, on the behalf of the foundation'sboard, if you wish to > join this community. > > Please read and, if needed, discuss it on this list. If there is a need, > we can organize a vote. If, however, in a reasonable lapse of time, > lets say 4 week, there is no opposition or a request for vote, I will > make the necessary to join the OIN. >From what I can see it's about Linux, how does it apply to us? From pfelecan at opencsw.org Wed May 7 19:24:55 2014 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 07 May 2014 19:24:55 +0200 Subject: Should OpenCSW joining the software patent non-aggression community? In-Reply-To: (Peter Bonivart's message of "Tue, 6 May 2014 20:16:22 +0200") References: Message-ID: Peter Bonivart writes: > On Tue, May 6, 2014 at 7:52 PM, Peter FELECAN wrote: >> Dear maintainers and members of the foundation, >> >> We are invited by Valer Mischenkoto join The Open Invention Network, a >> community of software patent non-aggression. >> >> You can read about this at http://www.openinventionnetwork.com/ >> >> I'm asking you, on the behalf of the foundation'sboard, if you wish to >> join this community. >> >> Please read and, if needed, discuss it on this list. If there is a need, >> we can organize a vote. If, however, in a reasonable lapse of time, >> lets say 4 week, there is no opposition or a request for vote, I will >> make the necessary to join the OIN. > >>From what I can see it's about Linux, how does it apply to us? Peter, You'll find bellow the answers to my questions that Valer kindly answered. The second point answers your question. If you have specific question do not hesitate to ask him and, if needed, share with us. Valer Mischenko writes: > 1. The foundation doesn't have any patents. The vast majority of the participants have no patents. This is not a requirement for participation. For most participants it is often symbolic. > 2. The Foundation is not Linux related. Historically we call it the Linux system. But its much more now than Linux only. We gradually try to make the definition of "the Linux system" broader and broader. Now it is spanning from eCommerce to PHP to Biometric Portfolio, and eventually will span to many other fields. In total there are more that 2200 software packages. We will not stop until we cover the whole open source field. Before that we keep doing this monks' work of gathering more projects and organizations around the initiative to acquire the mass needed among others for being able to influence the legislation. And get gravity which will hopefully attract all of open source. > 3. When you say "not to use pattents aggresively" I would say "not to > use patents". Period. Personally I am the same anti-patent type as you. But from our mission point of view we do not want to exclude anybody. We'd better have everybody sign the non-aggression pledge, with or without patents, than divide the world in two camps - pro-patent and anti-patent, as such division would lead to even more wars. However, when everybody pledges peace around open source we will finally have freedom to innovate without the fear to be attacked by trolls or monopolists in the market. This is a practical and realisable approach contrary to "praying against patents and hoping that they will eventually disappear". As to the patents in general. Well, you may see that from this point: When we free open source, whether software or hardware, from aggression, people will be able to innovate at faster pace. This will attract more creative people to open source and will let open source at a certain moment take over. That's a nice goal, but we are not able to achieve it on our own, without your help, without the help of others who want to set innovation free. -- Peter From rmottola at opencsw.org Wed May 7 23:17:29 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Wed, 07 May 2014 23:17:29 +0200 Subject: custom stuff in build and configure Message-ID: <536AA2E9.1040004@opencsw.org> Hi, I need to add a custom step in my makefile. I need to "source" a file which sets several env. variables before configuring or buidling. What I would do manually for configuring is: . /opt/csw/System/Library/Makefiles/GNUstep.sh ./configure (note the " " after .) to build: . /opt/csw/System/Library/Makefiles/GNUstep.sh make if everything has to be done together, it needs to be done only once . /opt/csw/System/Library/Makefiles/GNUstep.sh ./configure make make install since it stays in your environment. How can I replicate this in my mgar Makefile? Macjej suggested to use CONFIGURE_SCRIPTS and BUILD_SCRIPTS, I thus tried to: first: configure-sourcegs: . /opt/csw/System/Library/Makefiles/GNUstep.sh @$(MAKECOOKIE) or even: configure-sourcegs: . /opt/csw/System/Library/Makefiles/GNUstep.sh @( cd $(WORKSRC) ; $(CONFIGURE_ENV) ../dist/configure $(CONFIGURE_ARGS) ) @$(MAKECOOKIE) but then the configure target appears to do nothing, like: bash-4.3$ mgar configure gmake: 'work/cookies/global/configure' is up to date. but this is untrue, the configure script never did run, there is no config.log what am I doing wrong? Thanks, Riccardo From maciej at opencsw.org Thu May 8 01:27:07 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 8 May 2014 00:27:07 +0100 Subject: custom stuff in build and configure In-Reply-To: <536AA2E9.1040004@opencsw.org> References: <536AA2E9.1040004@opencsw.org> Message-ID: On Wed, May 7, 2014 at 10:17 PM, Riccardo Mottola wrote: > > but then the configure target appears to do nothing, like: > bash-4.3$ mgar configure > gmake: 'work/cookies/global/configure' is up to date. > > but this is untrue, the configure script never did run, there is no config.log > > what am I doing wrong? GAR is using its own cookies to track the state. If you want to reset the configure stage cookie, you need to run "mgar reconfigure". Overall, I'd suggest writing your own shell script that does whatever you need to do, and calling that shell script from make. If you write something like this in gmake... foo: cmd1 cmd2 ...the environment from cmd1 will not be seen by cmd2, because they are independent (sub)shells started by gmake, I think. Somebody correct me if I'm wrong. Maciej From claudio at opencsw.org Thu May 8 09:33:31 2014 From: claudio at opencsw.org (Claudio) Date: Thu, 08 May 2014 09:33:31 +0200 Subject: custom stuff in build and configure In-Reply-To: References: <536AA2E9.1040004@opencsw.org> Message-ID: <536B334B.4070905@opencsw.org> On 08-05-14 01:27, Maciej (Matchek) Blizi?ski wrote: > If you write something like this in gmake... > > foo: > cmd1 > cmd2 > > ...the environment from cmd1 will not be seen by cmd2, because they > are independent (sub)shells started by gmake, I think. Somebody > correct me if I'm wrong. What about: foo: cmd1 && cmd2 C. From maciej at opencsw.org Thu May 8 09:47:25 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 8 May 2014 08:47:25 +0100 Subject: custom stuff in build and configure In-Reply-To: <536B334B.4070905@opencsw.org> References: <536AA2E9.1040004@opencsw.org> <536B334B.4070905@opencsw.org> Message-ID: On Thu, May 8, 2014 at 8:33 AM, Claudio wrote: > On 08-05-14 01:27, Maciej (Matchek) Blizi?ski wrote: >> >> If you write something like this in gmake... >> >> foo: >> cmd1 >> cmd2 >> >> ...the environment from cmd1 will not be seen by cmd2, because they >> are independent (sub)shells started by gmake, I think. Somebody >> correct me if I'm wrong. > > > What about: > > foo: > > cmd1 && cmd2 It should work. For example: $ echo foo=bar > env.sh $ . env.sh && echo ${foo} bar Maciej From dam at opencsw.org Thu May 8 10:47:01 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 8 May 2014 10:47:01 +0200 Subject: custom stuff in build and configure In-Reply-To: References: <536AA2E9.1040004@opencsw.org> Message-ID: Am 08.05.2014 um 01:27 schrieb Maciej (Matchek) Blizi?ski : > On Wed, May 7, 2014 at 10:17 PM, Riccardo Mottola wrote: >> >> but then the configure target appears to do nothing, like: >> bash-4.3$ mgar configure >> gmake: 'work/cookies/global/configure' is up to date. >> >> but this is untrue, the configure script never did run, there is no config.log >> >> what am I doing wrong? > > GAR is using its own cookies to track the state. If you want to reset > the configure stage cookie, you need to run "mgar reconfigure?. reconfigure does not reset the whole state, just configure. So if you reconfigure and repackage make is not redone. Essentially it is better to do spotless and restart 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 maciej at opencsw.org Thu May 8 10:52:10 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 8 May 2014 09:52:10 +0100 Subject: custom stuff in build and configure In-Reply-To: References: <536AA2E9.1040004@opencsw.org> Message-ID: On Thu, May 8, 2014 at 9:47 AM, Dagobert Michelsen wrote: > reconfigure does not reset the whole state, just configure. So if you > reconfigure and repackage make is not redone. > Essentially it is better to do spotless and restart again. I feel that each new maintainer bumps into the same set of problems. - why can I run "mgar package" once but not twice? - when do I use spotless, platforms, replatforms, platforms-re{merge,package}? - I added overrides, but they aren't picked up, what's wrong? - I keep getting the "uncommitted" error, what am I doing wrong? It happens over and over again. Maciej From dam at opencsw.org Thu May 8 14:07:39 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 8 May 2014 14:07:39 +0200 Subject: custom stuff in build and configure In-Reply-To: References: <536AA2E9.1040004@opencsw.org> Message-ID: Hi Maciej, Am 08.05.2014 um 10:52 schrieb Maciej (Matchek) Blizi?ski : > On Thu, May 8, 2014 at 9:47 AM, Dagobert Michelsen wrote: >> reconfigure does not reset the whole state, just configure. So if you >> reconfigure and repackage make is not redone. >> Essentially it is better to do spotless and restart again. > > I feel that each new maintainer bumps into the same set of problems. I see. Let?s talk what we can do about that. > - why can I run "mgar package" once but not twice? The consistent behaviour would be to do nothing on the second invocation as the cookie would already be there. Unfortunately I just can?t get this to work. Apart from that it may be more expectable to just generate a new package. This could be done by doing a reset-package before each package. > - when do I use spotless, platforms, replatforms, platforms-re{merge,package}? This is mainly a documentation issue. Or do you have suggestions for better names which more cleanly indicate what is happening? > - I added overrides, but they aren't picked up, what's wrong? This is because overrides are done in the merge phase as they merge data, but I do unerstand this may be not be what is expected. I could relocate these actions to the package phase. > - I keep getting the "uncommitted" error, what am I doing wrong? When uncommitted is printed a summary could be listed after ?package? that lists the reason (read: output of ?svn status?). 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 rmottola at opencsw.org Fri May 9 02:07:10 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Fri, 09 May 2014 02:07:10 +0200 Subject: gnutls dependency Message-ID: <536C1C2E.1060707@opencsw.org> Hi, I am working on my makefile making progress, I need gnutls: checking for libgnutls-config... no checking for libgnutls - version >= 1.4.0... no *** The libgnutls-config script installed by libgnutls could not be found *** If libtgnuls-config was installed in PREFIX, make sure PREFIX/bin is in *** your path. no You do not appear to have usable libgnutls headers/library. Building without them will disable SSL/TLS/HTTPS in NSStream, In my makefile I specified: BUILD_DEP_PKGS = CSWgmake CSWgcc4objc CSWlibgnutls-dev CSWlibffi-dev DEP_PKGS = CSWgnustep-make CSWlibgnutls28 CSWlibssl1-0-0 CSWlibffi5 I fear that the "-config" is missing or not found. pkg-config? When I did it by hand the same package outside mgar I did: $ ./configure LDFLAGS=-L/opt/csw/lib -R/opt/csw/lib -L/opt/csw/lib/ffi -R/opt/csw/lib/ffi CPPFLAGS=-I/opt/csw/include most of it should be handled by $DIRPATHS I hope! Riccardo From maciej at opencsw.org Fri May 9 09:21:33 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 9 May 2014 08:21:33 +0100 Subject: gnutls dependency In-Reply-To: <536C1C2E.1060707@opencsw.org> References: <536C1C2E.1060707@opencsw.org> Message-ID: On Fri, May 9, 2014 at 1:07 AM, Riccardo Mottola wrote: > > I fear that the "-config" is missing or not found. pkg-config? I looked if our libgnutls_dev package contains /opt/csw/bin/libgnutls-config -- it does not. Here's how you can find whether any package from a given catalog contains a file with a given base name. For example, pkg-config: baseurl=http://buildfarm.opencsw.org/pkgdb/rest/catalogs/unstable/sparc/SunOS5.10/pkgnames-and-paths-by-basename curl -s "${baseurl}?basename=pkg-config" | python -m json.tool You will see some results. If you run the same query looking for "libgnutls-config" you will get back nothing. So it seems to be a discrepancy between what the gnutls packages provide, and what your sources expect. Maciej From rmottola at opencsw.org Fri May 9 12:06:25 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Fri, 09 May 2014 12:06:25 +0200 Subject: gnutls dependency In-Reply-To: References: <536C1C2E.1060707@opencsw.org> Message-ID: <1399629985.7786.6.camel@anor> Hi, On Fri, 2014-05-09 at 09:21, Maciej (Matchek) Blizi?ski wrote: > On Fri, May 9, 2014 at 1:07 AM, Riccardo Mottola wrote: > > > > I fear that the "-config" is missing or not found. pkg-config? > > I looked if our libgnutls_dev package contains > /opt/csw/bin/libgnutls-config -- it does not. Here's how you can find > whether any package from a given catalog contains a file with a given > base name. For example, pkg-config: > > baseurl=http://buildfarm.opencsw.org/pkgdb/rest/catalogs/unstable/sparc/SunOS5.10/pkgnames-and-paths-by-basename > curl -s "${baseurl}?basename=pkg-config" | python -m json.tool > > You will see some results. If you run the same query looking for > "libgnutls-config" you will get back nothing. So it seems to be a > discrepancy between what the gnutls packages provide, and what your > sources expect. You are correct. libgnutls-config is not there at all, it is just a configure aid, I suppose coming from pkg-config. In fact, if I configure outside gar, configure works even without detecting libgnutls-config: checking for libgnutls-config... no checking for libgnutls - version >= 1.4.0... yes checking for gcry_control in -lgcrypt... yes the specific test looks like this: configure:25140: gcc -o conftest -g -O2 -I/usr/include -I/opt/csw/include -I/opt/GNUstep/Local/Library/Headers -I/opt/GNUstep/Local/Library/Headers -I/opt/GNUstep/System/Library/Headers -I/usr/include/libxml2 -L/opt/csw/lib -R/opt/csw/lib -L/opt/csw/lib/ffi -R/opt/csw/lib/ffi -L/opt/GNUstep/Local/Library/Libraries -L/opt/GNUstep/Local/Library/Libraries -L/opt/GNUstep/System/Library/Libraries conftest.c -L/usr/lib -lgnutls -lgcrypt -lxslt -L/usr/lib -R/usr/lib -lxml2 -lz -lpthread -lm -lsocket -lnsl -liconv -lffi -lnsl -lrt -ldl -lpthread -lz >&5 Inside mgar, i get this error: configure:11104: checking for libgnutls-config configure:11135: result: no configure:11144: checking for libgnutls - version >= 1.4.0 configure:11191: /opt/csw/bin/gcc-4.9 -o conftest -O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus -I/usr/include -I/opt/csw/include -I/opt/csw/Local/Library/Headers -I/opt/csw/Local/Library/Headers -I/opt/csw/System/Library/Headers -I/opt/csw/include -I/usr/include/libxml2 -mcpu=v9 -Wa,-xarch=v8plus -L/opt/csw/lib -L/opt/csw/Local/Library/Libraries -L/opt/csw/Local/Library/Libraries -L/opt/csw/System/Library/Libraries conftest.c -L/usr/lib -lgnutls -lgcrypt -lxslt -L/usr/lib -R/usr/lib -lxml2 -lz -lpthread -lm -lsocket -lnsl -liconv -L/opt/csw/lib/ffi -lffi -lnsl -lrt -ldl -lpthread -lz >&5 ld: fatal: file /usr/lib/libc.so: version 'SUNW_1.22.5' is unavailable: required by file /opt/csw/lib/libgnutls.so ld: fatal: file processing errors. No output written to conftest configure:11191: $? = 1 What kind of failure is that? On libc? One thing that I notice is that mgar only adds the -L flags and not the -R. The paths are of course slightly different because I configured my own stuff in /opt/GNUstep and not /opt/csw to keep them separate. my configure section looks like this: configure-sourcegs: . /opt/csw/System/Library/Makefiles/GNUstep.sh && cd $(WORKSRC) ; $(CONF IGURE_ENV) ./configure $(CONFIGURE_ARGS) @$(MAKECOOKIE) which was, admittedly, blatantly coped as far as the variables goes, but it makes sense to me. Riccardo From dam at opencsw.org Fri May 9 12:39:08 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 9 May 2014 12:39:08 +0200 Subject: gnutls dependency In-Reply-To: <1399629985.7786.6.camel@anor> References: <536C1C2E.1060707@opencsw.org> <1399629985.7786.6.camel@anor> Message-ID: <3BBD09C5-863A-4952-8A1A-668BACADA840@opencsw.org> Hi Riccardo, Am 09.05.2014 um 12:06 schrieb Riccardo Mottola : > On Fri, 2014-05-09 at 09:21, Maciej (Matchek) Blizi?ski wrote: >> On Fri, May 9, 2014 at 1:07 AM, Riccardo Mottola wrote: >>> >>> I fear that the "-config" is missing or not found. pkg-config? >> >> I looked if our libgnutls_dev package contains >> /opt/csw/bin/libgnutls-config -- it does not. Here's how you can find >> whether any package from a given catalog contains a file with a given >> base name. For example, pkg-config: >> >> baseurl=http://buildfarm.opencsw.org/pkgdb/rest/catalogs/unstable/sparc/SunOS5.10/pkgnames-and-paths-by-basename >> curl -s "${baseurl}?basename=pkg-config" | python -m json.tool >> >> You will see some results. If you run the same query looking for >> "libgnutls-config" you will get back nothing. So it seems to be a >> discrepancy between what the gnutls packages provide, and what your >> sources expect. > > You are correct. libgnutls-config is not there at all, it is just a > configure aid, I suppose coming from pkg-config. This was removed in GnuTLS 2.8.0: > *** Old libgnutls.m4 and libgnutls-config scripts removed. > Please use pkg-config instead. > In fact, if I configure outside gar, configure works even without > detecting libgnutls-config: > > checking for libgnutls-config... no > checking for libgnutls - version >= 1.4.0... yes > checking for gcry_control in -lgcrypt... yes > > the specific test looks like this: > configure:25140: gcc -o conftest -g -O2 -I/usr/include > -I/opt/csw/include -I/opt/GNUstep/Local/Library/Headers > -I/opt/GNUstep/Local/Library/Headers > -I/opt/GNUstep/System/Library/Headers -I/usr/include/libxml2 > -L/opt/csw/lib -R/opt/csw/lib -L/opt/csw/lib/ffi -R/opt/csw/lib/ffi > -L/opt/GNUstep/Local/Library/Libraries > -L/opt/GNUstep/Local/Library/Libraries > -L/opt/GNUstep/System/Library/Libraries conftest.c -L/usr/lib -lgnutls > -lgcrypt -lxslt -L/usr/lib -R/usr/lib -lxml2 -lz -lpthread -lm -lsocket > -lnsl -liconv -lffi -lnsl -lrt -ldl -lpthread -lz >&5 > > > Inside mgar, i get this error: > > configure:11104: checking for libgnutls-config > configure:11135: result: no > configure:11144: checking for libgnutls - version >= 1.4.0 > configure:11191: /opt/csw/bin/gcc-4.9 -o conftest -O2 -pipe -mcpu=v9 > -Wa,-xarch=v8plus -I/usr/include -I/opt/csw/include > -I/opt/csw/Local/Library/Headers -I/opt/csw/Local/Library/Headers > -I/opt/csw/System/Library/Headers -I/opt/csw/include > -I/usr/include/libxml2 -mcpu=v9 -Wa,-xarch=v8plus -L/opt/csw/lib > -L/opt/csw/Local/Library/Libraries -L/opt/csw/Local/Library/Libraries > -L/opt/csw/System/Library/Libraries conftest.c -L/usr/lib -lgnutls > -lgcrypt -lxslt -L/usr/lib -R/usr/lib -lxml2 -lz -lpthread -lm -lsocket > -lnsl -liconv -L/opt/csw/lib/ffi -lffi -lnsl -lrt -ldl -lpthread -lz >> &5 > ld: fatal: file /usr/lib/libc.so: version 'SUNW_1.22.5' is unavailable: > required by file /opt/csw/lib/libgnutls.so > ld: fatal: file processing errors. No output written to conftest > configure:11191: $? = 1 > > What kind of failure is that? On libc? You need to disable linker maps with LINKER_MAPS = We restrict libc versioning to Solaris 10u8 if possible, but gnutls needs a newer libc. > > One thing that I notice is that mgar only adds the -L flags and not the > -R. The paths are of course slightly different because I configured my > own stuff in /opt/GNUstep and not /opt/csw to keep them separate. -R is passed via LD_OPTIONS through the environment, you need to look in the command invocation or ?mgar modenv?. > my configure section looks like this: > configure-sourcegs: > . /opt/csw/System/Library/Makefiles/GNUstep.sh && cd $(WORKSRC); $(CONFIGURE_ENV) ./configure $(CONFIGURE_ARGS) > @$(MAKECOOKIE) > > which was, admittedly, blatantly coped as far as the variables goes, but > it makes sense to me. Essentially this is similar enough to https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/gar/v2/gar.lib.mk#834 that it should work. Just add the linker map removal and 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 jh at opencsw.org Fri May 9 15:52:10 2014 From: jh at opencsw.org (Jan Holzhueter) Date: Fri, 09 May 2014 15:52:10 +0200 Subject: gnutls dependency In-Reply-To: <3BBD09C5-863A-4952-8A1A-668BACADA840@opencsw.org> References: <536C1C2E.1060707@opencsw.org> <1399629985.7786.6.camel@anor> <3BBD09C5-863A-4952-8A1A-668BACADA840@opencsw.org> Message-ID: <536CDD8A.70004@opencsw.org> Hi, >> What kind of failure is that? On libc? > > You need to disable linker maps with > LINKER_MAPS = > We restrict libc versioning to Solaris 10u8 if possible, but gnutls needs > a newer libc. not empty please set it to solaris10u8 as explained here: http://sourceforge.net/apps/trac/gar/wiki/Mapfiles Greetings Jan From rmottola at opencsw.org Fri May 9 17:55:01 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Fri, 09 May 2014 17:55:01 +0200 Subject: gnutls dependency In-Reply-To: <536CDD8A.70004@opencsw.org> References: <536C1C2E.1060707@opencsw.org> <1399629985.7786.6.camel@anor> <3BBD09C5-863A-4952-8A1A-668BACADA840@opencsw.org> <536CDD8A.70004@opencsw.org> Message-ID: <1399650900.7374.1.camel@anor> Hi, On Fri, 2014-05-09 at 15:52, Jan Holzhueter wrote: > Hi, > > >> What kind of failure is that? On libc? > > > > You need to disable linker maps with > > LINKER_MAPS = > > We restrict libc versioning to Solaris 10u8 if possible, but gnutls needs > > a newer libc. > > not empty > please set it to solaris10u8 > > as explained here: > http://sourceforge.net/apps/trac/gar/wiki/Mapfiles And for solaris 9 will it work? 8? 11? Is it an option used only on solaris 10? R From rmottola at opencsw.org Fri May 9 21:40:02 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Fri, 09 May 2014 21:40:02 +0200 Subject: gnutls dependency In-Reply-To: <3BBD09C5-863A-4952-8A1A-668BACADA840@opencsw.org> References: <536C1C2E.1060707@opencsw.org> <1399629985.7786.6.camel@anor> <3BBD09C5-863A-4952-8A1A-668BACADA840@opencsw.org> Message-ID: <1399664401.7374.112.camel@anor> Hi Dagobert, On Fri, 2014-05-09 at 12:39, Dagobert Michelsen wrote: > > You need to disable linker maps with > LINKER_MAPS = > We restrict libc versioning to Solaris 10u8 if possible, but gnutls needs > a newer libc. > Perhaps this can be perfected later, but it works for now. > > > > One thing that I notice is that mgar only adds the -L flags and not the > > -R. The paths are of course slightly different because I configured my > > own stuff in /opt/GNUstep and not /opt/csw to keep them separate. > > -R is passed via LD_OPTIONS through the environment, you need to look in the > command invocation or ?mgar modenv?. > > > my configure section looks like this: > > configure-sourcegs: > > . /opt/csw/System/Library/Makefiles/GNUstep.sh && cd $(WORKSRC); $(CONFIGURE_ENV) ./configure $(CONFIGURE_ARGS) > > @$(MAKECOOKIE) > > > > which was, admittedly, blatantly coped as far as the variables goes, but > > it makes sense to me. > > Essentially this is similar enough to > https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/gar/v2/gar.lib.mk#834 > that it should work. Just add the linker map removal and try again. I was able to configure, then build. However then build never ends, it gets in a sort of vicious cycle: [===== NOW BUILDING: gnustep-base-1.24.6 MODULATION isa-sparcv8plus: ISA=sparcv8plus =====] [extract-modulated] complete for gnustep-base. [patch-modulated] complete for gnustep-base. [configure-modulated] complete for gnustep-base. gmake[10]: Entering directory '/home/multix/code/opencsw/gnustep-base/trunk' gmake[11]: Entering directory '/home/multix/code/opencsw/gnustep-base/trunk' [===== NOW BUILDING: gnustep-base-1.24.6 MODULATION isa-sparcv8plus: ISA=sparcv8plus =====] Riccardo From dam at opencsw.org Fri May 9 22:17:50 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 9 May 2014 22:17:50 +0200 Subject: gnutls dependency In-Reply-To: <1399664401.7374.112.camel@anor> References: <536C1C2E.1060707@opencsw.org> <1399629985.7786.6.camel@anor> <3BBD09C5-863A-4952-8A1A-668BACADA840@opencsw.org> <1399664401.7374.112.camel@anor> Message-ID: <2F077FDD-73F3-41C4-8D97-2DDDC5EEE206@opencsw.org> Hi, Am 09.05.2014 um 21:40 schrieb Riccardo Mottola : >>> One thing that I notice is that mgar only adds the -L flags and not the >>> -R. The paths are of course slightly different because I configured my >>> own stuff in /opt/GNUstep and not /opt/csw to keep them separate. >> >> -R is passed via LD_OPTIONS through the environment, you need to look in the >> command invocation or ?mgar modenv?. >> >>> my configure section looks like this: >>> configure-sourcegs: >>> . /opt/csw/System/Library/Makefiles/GNUstep.sh && cd $(WORKSRC); $(CONFIGURE_ENV) ./configure $(CONFIGURE_ARGS) >>> @$(MAKECOOKIE) >>> >>> which was, admittedly, blatantly coped as far as the variables goes, but >>> it makes sense to me. >> >> Essentially this is similar enough to >> https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/gar/v2/gar.lib.mk#834 >> that it should work. Just add the linker map removal and try again. > > I was able to configure, then build. However then build never ends, it > gets in a sort of vicious cycle: > [===== NOW BUILDING: gnustep-base-1.24.6 MODULATION isa-sparcv8plus: > ISA=sparcv8plus =====] > [extract-modulated] complete for gnustep-base. > [patch-modulated] complete for gnustep-base. > [configure-modulated] complete for gnustep-base. > > gmake[10]: Entering directory > '/home/multix/code/opencsw/gnustep-base/trunk' > gmake[11]: Entering directory > '/home/multix/code/opencsw/gnustep-base/trunk' > > [===== NOW BUILDING: gnustep-base-1.24.6 MODULATION isa-sparcv8plus: > ISA=sparcv8plus =====] This is strange, please commit what you have and let me know about the location in the svn tree. 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 rmottola at opencsw.org Fri May 9 22:29:45 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Fri, 09 May 2014 22:29:45 +0200 Subject: gnutls dependency In-Reply-To: <2F077FDD-73F3-41C4-8D97-2DDDC5EEE206@opencsw.org> References: <536C1C2E.1060707@opencsw.org> <1399629985.7786.6.camel@anor> <3BBD09C5-863A-4952-8A1A-668BACADA840@opencsw.org> <1399664401.7374.112.camel@anor> <2F077FDD-73F3-41C4-8D97-2DDDC5EEE206@opencsw.org> Message-ID: <1399667384.7374.119.camel@anor> Hi, On Fri, 2014-05-09 at 22:17, Dagobert Michelsen wrote: > > > > [===== NOW BUILDING: gnustep-base-1.24.6 MODULATION isa-sparcv8plus: > > ISA=sparcv8plus =====] > > This is strange, please commit what you have and let me know about the location in the > svn tree. My first commit ! I hope I did it right, I used mgar commit. I commited gnustep-make, which is prerequisite, then gnustep-base which is the package we are speaking about. Riccardo From dam at opencsw.org Fri May 9 23:10:54 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 9 May 2014 23:10:54 +0200 Subject: gnutls dependency In-Reply-To: <2F077FDD-73F3-41C4-8D97-2DDDC5EEE206@opencsw.org> References: <536C1C2E.1060707@opencsw.org> <1399629985.7786.6.camel@anor> <3BBD09C5-863A-4952-8A1A-668BACADA840@opencsw.org> <1399664401.7374.112.camel@anor> <2F077FDD-73F3-41C4-8D97-2DDDC5EEE206@opencsw.org> Message-ID: <934B81D8-F9FE-438E-9847-8CAB27709DAB@opencsw.org> Hi, Am 09.05.2014 um 22:17 schrieb Dagobert Michelsen : > Am 09.05.2014 um 21:40 schrieb Riccardo Mottola : >>>> One thing that I notice is that mgar only adds the -L flags and not the >>>> -R. The paths are of course slightly different because I configured my >>>> own stuff in /opt/GNUstep and not /opt/csw to keep them separate. >>> >>> -R is passed via LD_OPTIONS through the environment, you need to look in the >>> command invocation or ?mgar modenv?. >>> >>>> my configure section looks like this: >>>> configure-sourcegs: >>>> . /opt/csw/System/Library/Makefiles/GNUstep.sh && cd $(WORKSRC); $(CONFIGURE_ENV) ./configure $(CONFIGURE_ARGS) >>>> @$(MAKECOOKIE) >>>> >>>> which was, admittedly, blatantly coped as far as the variables goes, but >>>> it makes sense to me. >>> >>> Essentially this is similar enough to >>> https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/gar/v2/gar.lib.mk#834 >>> that it should work. Just add the linker map removal and try again. >> >> I was able to configure, then build. However then build never ends, it >> gets in a sort of vicious cycle: >> [===== NOW BUILDING: gnustep-base-1.24.6 MODULATION isa-sparcv8plus: >> ISA=sparcv8plus =====] >> [extract-modulated] complete for gnustep-base. >> [patch-modulated] complete for gnustep-base. >> [configure-modulated] complete for gnustep-base. >> >> gmake[10]: Entering directory >> '/home/multix/code/opencsw/gnustep-base/trunk' >> gmake[11]: Entering directory >> '/home/multix/code/opencsw/gnustep-base/trunk' >> >> [===== NOW BUILDING: gnustep-base-1.24.6 MODULATION isa-sparcv8plus: >> ISA=sparcv8plus =====] > > This is strange, please commit what you have and let me know about the location in the > svn tree. In fact it was quite easy: you missed changing to the working directory. That way you invoked just ?make? in the GAR directory doing one invocation after the other. You can also ommit the -C as it is a special case. My modification looks like this and it starts to compile now: http://sourceforge.net/p/gar/code/23585/ 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 rmottola at opencsw.org Sat May 10 18:55:51 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Sat, 10 May 2014 18:55:51 +0200 Subject: gnutls dependency In-Reply-To: <934B81D8-F9FE-438E-9847-8CAB27709DAB@opencsw.org> References: <536C1C2E.1060707@opencsw.org> <1399629985.7786.6.camel@anor> <3BBD09C5-863A-4952-8A1A-668BACADA840@opencsw.org> <1399664401.7374.112.camel@anor> <2F077FDD-73F3-41C4-8D97-2DDDC5EEE206@opencsw.org> <934B81D8-F9FE-438E-9847-8CAB27709DAB@opencsw.org> Message-ID: <1399740951.17202.10.camel@anor> Hi Dagoberto, > > In fact it was quite easy: you missed changing to the working directory. > That way you invoked just ?make? in the GAR directory doing one invocation > after the other. You can also ommit the -C as it is a special case. My modification > looks like this and it starts to compile now: > http://sourceforge.net/p/gar/code/23585/ Thank you! that fixed build. However, when I package, I get the following error: From rmottola at opencsw.org Sat May 10 19:01:11 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Sat, 10 May 2014 19:01:11 +0200 Subject: gnutls dependency In-Reply-To: <934B81D8-F9FE-438E-9847-8CAB27709DAB@opencsw.org> References: <536C1C2E.1060707@opencsw.org> <1399629985.7786.6.camel@anor> <3BBD09C5-863A-4952-8A1A-668BACADA840@opencsw.org> <1399664401.7374.112.camel@anor> <2F077FDD-73F3-41C4-8D97-2DDDC5EEE206@opencsw.org> <934B81D8-F9FE-438E-9847-8CAB27709DAB@opencsw.org> Message-ID: <1399741271.17202.17.camel@anor> Sorry, the previous message got sent before I finished writing it. during "mgar package", I get an error that "gnustep-config" is not found. gnustep-config is installed by the gnustep-make package and should be in a path wihich the GNUstep.sh script sets up. /opt/csw/System/Tools/gnustep-config it looks as if the package phase does not happen in the same environment my script set up. If you look, I set it for CONFIGURE_SCRIPTS, BUILD_SCRIPTS and INSTALL_SCRIPTS What else could be missing? During the package phase? Riccardo From rmottola at opencsw.org Sun May 11 09:27:14 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Sun, 11 May 2014 09:27:14 +0200 Subject: gnutls dependency In-Reply-To: <1399740951.17202.10.camel@anor> References: <536C1C2E.1060707@opencsw.org> <1399629985.7786.6.camel@anor> <3BBD09C5-863A-4952-8A1A-668BACADA840@opencsw.org> <1399664401.7374.112.camel@anor> <2F077FDD-73F3-41C4-8D97-2DDDC5EEE206@opencsw.org> <934B81D8-F9FE-438E-9847-8CAB27709DAB@opencsw.org> <1399740951.17202.10.camel@anor> Message-ID: <536F2652.8030601@opencsw.org> Hi, yesterday while writing I sent the massage accidentally without copy&paste, evolution had a problem. On 05/10/14 18:55, Riccardo Mottola wrote: > Thank you! that fixed build. However, when I package, I get the > following error: [===== NOW BUILDING: gnustep-base-1.24.6 MODULATION isa-sparcv8plus: ISA=sparcv8plus =====] [extract-modulated] complete for gnustep-base. [patch-modulated] complete for gnustep-base. [configure-modulated] complete for gnustep-base. ==> Running make check in work/build-isa-sparcv8plus/gnustep-base-1.24.6 cd work/build-isa-sparcv8plus/gnustep-base-1.24.6 && /usr/bin/env -i HOME="/home/multix" PATH="/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/bin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/bin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/sbin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/sbin:/opt/csw/bin:/opt/csw/bin:/opt/csw/sbin:/opt/csw/sbin:/opt/csw/bin:/home/multix/code/opencsw/.buildsys/v2/gar/bin:/usr/bin:/usr/sbin:/usr/java/bin:/usr/ccs/bin:/usr/openwin/bin" LC_ALL="C" prefix="/opt/csw" exec_prefix="/opt/csw" bindir="/opt/csw/bin" sbindir="/opt/csw/sbin" libexecdir="/opt/csw/libexec" datadir="/opt/csw/share" sysconfdir="/etc/opt/csw" sharedstatedir="/opt/csw/share" localstatedir="/var/opt/csw" libdir="/opt/csw/lib" infodir="/opt/csw/share/info" lispdir="/opt/csw/share/emacs/site-lisp" includedir="/opt/csw/include" mandir="/opt/csw/share/man" docdir="/opt/csw/share/doc" sourcedir="/opt/csw/src" CPPFLAGS="-I/opt/csw/include" CFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" CXXFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" LDFLAGS="-mcpu=v9 -Wa,-xarch=v8plus -L/opt/csw/lib" FFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" FCFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" F77="/opt/csw/bin/gfortran-4.9" FC="/opt/csw/bin/gfortran-4.9" ASFLAGS="" OPTFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" CC="/opt/csw/bin/gcc-4.9" CXX="/opt/csw/bin/g++-4.9" CC_HOME="/opt/csw" CC_VERSION="gcc version 4.9.0 (GCC) " CXX_VERSION="gcc version 4.9.0 (GCC) " GARCH="sparc" GAROSREL="5.10" GARPACKAGE="trunk" LD_OPTIONS="-R/opt/csw/lib/\$ISALIST -R/opt/csw/lib -B direct -z ignore" gmake -I/home/multix/code/opencsw/.buildsys/v2 -C . check gmake: Entering directory '/home/multix/code/opencsw/gnustep-base/trunk/work/build-isa-sparcv8plus/gnustep-base-1.24.6' /bin/sh: gnustep-config: not found GNUmakefile:34: Your PATH is currently /home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/bin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/bin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/sbin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/sbin:/opt/csw/bin:/opt/csw/bin:/opt/csw/sbin:/opt/csw/sbin:/opt/csw/bin:/home/multix/code/opencsw/.buildsys/v2/gar/bin:/usr/bin:/usr/sbin:/usr/java/bin:/usr/ccs/bin:/usr/openwin/bin GNUmakefile:35: Thhe path does not contain /opt/csw/System/* which should if GNUstep.sh was correctly sourced at this stage. What's different in the package build stage? Configure and make worked fine. Riccardo From dam at opencsw.org Sun May 11 18:07:37 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 11 May 2014 18:07:37 +0200 Subject: gnutls dependency In-Reply-To: <536F2652.8030601@opencsw.org> References: <536C1C2E.1060707@opencsw.org> <1399629985.7786.6.camel@anor> <3BBD09C5-863A-4952-8A1A-668BACADA840@opencsw.org> <1399664401.7374.112.camel@anor> <2F077FDD-73F3-41C4-8D97-2DDDC5EEE206@opencsw.org> <934B81D8-F9FE-438E-9847-8CAB27709DAB@opencsw.org> <1399740951.17202.10.camel@anor> <536F2652.8030601@opencsw.org> Message-ID: <599B3A45-4E37-4BAD-916C-AEBE3D0C4B83@opencsw.org> Hi Riccardo, Am 11.05.2014 um 09:27 schrieb Riccardo Mottola : > yesterday while writing I sent the massage accidentally without copy&paste, evolution had a problem. > > On 05/10/14 18:55, Riccardo Mottola wrote: >> Thank you! that fixed build. However, when I package, I get the following error: > [===== NOW BUILDING: gnustep-base-1.24.6 MODULATION isa-sparcv8plus: ISA=sparcv8plus =====] > [extract-modulated] complete for gnustep-base. > [patch-modulated] complete for gnustep-base. > [configure-modulated] complete for gnustep-base. > ==> Running make check in work/build-isa-sparcv8plus/gnustep-base-1.24.6 > cd work/build-isa-sparcv8plus/gnustep-base-1.24.6 && /usr/bin/env -i HOME="/home/multix" PATH="/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/bin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/bin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/sbin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/sbin:/opt/csw/bin:/opt/csw/bin:/opt/csw/sbin:/opt/csw/sbin:/opt/csw/bin:/home/multix/code/opencsw/.buildsys/v2/gar/bin:/usr/bin:/usr/sbin:/usr/java/bin:/usr/ccs/bin:/usr/openwin/bin" LC_ALL="C" prefix="/opt/csw" exec_prefix="/opt/csw" bindir="/opt/csw/bin" sbindir="/opt/csw/sbin" libexecdir="/opt/csw/libexec" datadir="/opt/csw/share" sysconfdir="/etc/opt/csw" sharedstatedir="/opt/csw/share" localstatedir="/var/opt/csw" libdir="/opt/csw/lib" infodir="/opt/csw/share/info" lispdir="/opt/csw/share/emacs/site-lisp" includedir="/opt/csw/include" mandir="/opt/csw/share/man" docdir="/opt/csw/share/doc" sourcedir="/opt/csw/src" CPPFLAGS="-I/opt/csw/include" CFLAGS="-O2 -pipe -mcpu=v9 > -Wa,-xarch=v8plus" CXXFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" LDFLAGS="-mcpu=v9 -Wa,-xarch=v8plus -L/opt/csw/lib" FFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" FCFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" F77="/opt/csw/bin/gfortran-4.9" FC="/opt/csw/bin/gfortran-4.9" ASFLAGS="" OPTFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" CC="/opt/csw/bin/gcc-4.9" CXX="/opt/csw/bin/g++-4.9" CC_HOME="/opt/csw" CC_VERSION="gcc version 4.9.0 (GCC) " CXX_VERSION="gcc version 4.9.0 (GCC) " GARCH="sparc" GAROSREL="5.10" GARPACKAGE="trunk" LD_OPTIONS="-R/opt/csw/lib/\$ISALIST -R/opt/csw/lib -B direct -z ignore" gmake -I/home/multix/code/opencsw/.buildsys/v2 -C . check > gmake: Entering directory '/home/multix/code/opencsw/gnustep-base/trunk/work/build-isa-sparcv8plus/gnustep-base-1.24.6' > /bin/sh: gnustep-config: not found > GNUmakefile:34: Your PATH is currently /home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/bin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/bin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/sbin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/sbin:/opt/csw/bin:/opt/csw/bin:/opt/csw/sbin:/opt/csw/sbin:/opt/csw/bin:/home/multix/code/opencsw/.buildsys/v2/gar/bin:/usr/bin:/usr/sbin:/usr/java/bin:/usr/ccs/bin:/usr/openwin/bin > GNUmakefile:35: > > Thhe path does not contain /opt/csw/System/* which should if GNUstep.sh was correctly sourced at this stage. What's different in the package build stage? Configure and make worked fine. No, it was not :-) This is the ?check? phase. Just add another rule with TEST_SCRIPTS = sourcegs similar to the other ones. 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 Sun May 11 23:59:36 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 11 May 2014 22:59:36 +0100 Subject: We should talk about getting IPS packages going In-Reply-To: <53686E3A.6030508@opencsw.org> References: <53686E3A.6030508@opencsw.org> Message-ID: Em 06/05/2014 06:08, "Gordon Marler" escreveu: > Stripping out the features in mgar that are native to IPS is probably important, to avoid duplication of effort. My idea was to use "mgar merge" to get the pkgroot directory. Then we could use any means necessary to build an IPS package front that pkgroot, taking as much information as possible from the GAR build recipe. Then we would ask Dago for help in integrating it into GAR. Gordon, do you think it's possible to start that way? Is anything blocking you? Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmottola at opencsw.org Mon May 12 00:49:35 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Mon, 12 May 2014 00:49:35 +0200 Subject: gnutls dependency In-Reply-To: <599B3A45-4E37-4BAD-916C-AEBE3D0C4B83@opencsw.org> References: <536C1C2E.1060707@opencsw.org> <1399629985.7786.6.camel@anor> <3BBD09C5-863A-4952-8A1A-668BACADA840@opencsw.org> <1399664401.7374.112.camel@anor> <2F077FDD-73F3-41C4-8D97-2DDDC5EEE206@opencsw.org> <934B81D8-F9FE-438E-9847-8CAB27709DAB@opencsw.org> <1399740951.17202.10.camel@anor> <536F2652.8030601@opencsw.org> <599B3A45-4E37-4BAD-916C-AEBE3D0C4B83@opencsw.org> Message-ID: <1399848574.10348.1.camel@anor> Hi Dagobert, On 05/11/14 18:07, Dagobert Michelsen wrote: > No, it was not :-) This is the ?check? phase. Just add another rule with > TEST_SCRIPTS = sourcegs > similar to the other ones. Actually, gnustep "make check"is complicated and different, so I just "disabled" it. I commited it, you might see the change. Now however, "mgar package" still fails. Making all in Tests ... If you want to run the gnustep-base testsuite, please type 'make check' /opt/csw/bin/ginstall: cannot create regular file `/opt/csw/System/Library/Makefiles/Additional/base.make': Permission denied Makefile.postamble:46: recipe for target 'before-install' failed gmake[2]: *** [before-install] Error 1 gmake[2]: Leaving directory '/home/multix/code/opencsw/gnustep-base/trunk/work/build-isa-sparcv8plus/gnustep-base-1.24.6' Makefile:47: recipe for target 'install-sourcegs' failed Here I fear something tries to gets installed while the package is still getting build? that sounds difficult. If you can tell me more, I might ask the gnustep mailing list for help. Is "mgar package" trying to install? Riccardo From maciej at opencsw.org Mon May 12 01:34:54 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 12 May 2014 00:34:54 +0100 Subject: gnutls dependency In-Reply-To: <1399848574.10348.1.camel@anor> References: <536C1C2E.1060707@opencsw.org> <1399629985.7786.6.camel@anor> <3BBD09C5-863A-4952-8A1A-668BACADA840@opencsw.org> <1399664401.7374.112.camel@anor> <2F077FDD-73F3-41C4-8D97-2DDDC5EEE206@opencsw.org> <934B81D8-F9FE-438E-9847-8CAB27709DAB@opencsw.org> <1399740951.17202.10.camel@anor> <536F2652.8030601@opencsw.org> <599B3A45-4E37-4BAD-916C-AEBE3D0C4B83@opencsw.org> <1399848574.10348.1.camel@anor> Message-ID: The /opt/csw/System path looks very wrong to me. Our system layout is having /opt/csw as the prefix, with typical Unix subdirectories such as bin, lib, etc. /opt/csw/System does not conform to this. It needs to be adjusted to follow our layout. http://www.opencsw.org/manual/for-maintainers/filesystem-layout.html Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmottola at opencsw.org Mon May 12 09:52:38 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Mon, 12 May 2014 09:52:38 +0200 Subject: gnutls dependency In-Reply-To: References: <536C1C2E.1060707@opencsw.org> <1399629985.7786.6.camel@anor> <3BBD09C5-863A-4952-8A1A-668BACADA840@opencsw.org> <1399664401.7374.112.camel@anor> <2F077FDD-73F3-41C4-8D97-2DDDC5EEE206@opencsw.org> <934B81D8-F9FE-438E-9847-8CAB27709DAB@opencsw.org> <1399740951.17202.10.camel@anor> <536F2652.8030601@opencsw.org> <599B3A45-4E37-4BAD-916C-AEBE3D0C4B83@opencsw.org> <1399848574.10348.1.camel@anor> Message-ID: <1399881157.13066.0.camel@anor> Hi, On 05/12/14 01:34, Maciej (Matchek) Blizi?ski wrote: > The /opt/csw/System path looks very wrong to me. Our system layout is > having /opt/csw as the prefix, with typical Unix subdirectories such > as bin, lib, etc. /opt/csw/System does not conform to this. It needs > to be adjusted to follow our layout. > > http://www.opencsw.org/manual/for-maintainers/filesystem-layout.html > The GNUstep layout is different, it has a prefix and inside it will have /System and /Local (optionally /Network) inside each you will have the substructure: Application, Library, Tools. Usually the prefix is "/usr/GNUstep", but on a "native" system it would be "/" yielding a layout as you get it on a Mac (or on an "original" NeXT black box). I don't know how it was solved with Openstep for Solaris since I never used it. In fact, GNUstep here would be the equivalent. Each executable is either in Tools or in an application bundle inside Applications. This is also why you "source" GNUstep.sh, to set up the path to these non-standard locations. in these package, the prefix fot /opt/csw... I could override it to /opt/csw/GNUstep, but I don't tink it would solve the problem I am facing, or? Riccardo From maciej at opencsw.org Mon May 12 10:41:20 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 12 May 2014 09:41:20 +0100 Subject: gnutls dependency In-Reply-To: <1399881157.13066.0.camel@anor> References: <536C1C2E.1060707@opencsw.org> <1399629985.7786.6.camel@anor> <3BBD09C5-863A-4952-8A1A-668BACADA840@opencsw.org> <1399664401.7374.112.camel@anor> <2F077FDD-73F3-41C4-8D97-2DDDC5EEE206@opencsw.org> <934B81D8-F9FE-438E-9847-8CAB27709DAB@opencsw.org> <1399740951.17202.10.camel@anor> <536F2652.8030601@opencsw.org> <599B3A45-4E37-4BAD-916C-AEBE3D0C4B83@opencsw.org> <1399848574.10348.1.camel@anor> <1399881157.13066.0.camel@anor> Message-ID: Em 12/05/2014 08:52, "Riccardo Mottola" escreveu: > in these package, the prefix fot /opt/csw... I could override it to > /opt/csw/GNUstep, but I don't tink it would solve the problem I am > facing, or? Sorry, my comment was about the file layout as a separate issue, not related to the question you were asking. Using the /opt/csw/GNUstep prefix sounds good. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From bonivart at opencsw.org Mon May 12 13:14:11 2014 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 12 May 2014 13:14:11 +0200 Subject: Something wrong with the package release chain? Message-ID: The other day I uploaded a few packages and quickly got confirmation e-mails, the web site package browser also updated and they were removed from experimental. Later this weekend I uploaded some other packages, e.g. phpsysinfo, the process went without problems and they were removed from experimental but the package browser never updated. $ csw-upload-pkg phpsysinfo-3.1.12\,REV\=2014.05.10-SunOS5.10-all-CSW.pkg.gz Processing 1 file(s). Please wait. INFO 2014-05-10 20:29:22,825 rest.py:454 Uploading 'phpsysinfo-3.1.12,REV=2014.05.10-SunOS5.10-all-CSW.pkg.gz' Checking 1 package against catalog unstable sparc SunOS5.10 Checking 1 package against catalog unstable i386 SunOS5.10 Checking 1 package against catalog unstable sparc SunOS5.11 Checking 1 package against catalog unstable i386 SunOS5.11 All checks successful. Proceeding. Inserting phpsysinfo (all SunOS5.10) into catalog unstable i386 SunOS5.10 Inserting phpsysinfo (all SunOS5.10) into catalog unstable i386 SunOS5.11 Inserting phpsysinfo (all SunOS5.10) into catalog unstable sparc SunOS5.10 Inserting phpsysinfo (all SunOS5.10) into catalog unstable sparc SunOS5.11 Most important is that they never hit the mirrors, first an example of a package that did hit the mirrors: bind-9.9.5,REV=2014.05.08-SunOS5.10-i386-CSW.pkg.gz 2014-May-10 11:57:57 560.0K application/x-gzip And then one that didn't: phpsysinfo-3.0.4,REV=2010.03.29-SunOS5.9-all-CSW.pkg.gz 2010-Mar-30 02:46:58 571.5K application/x-gzip /peter From maciej at opencsw.org Mon May 12 13:33:43 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 12 May 2014 12:33:43 +0100 Subject: Something wrong with the package release chain? In-Reply-To: References: Message-ID: Yes, it is a known issue, it has been happening for a few months. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bonivart at opencsw.org Mon May 12 13:38:06 2014 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 12 May 2014 13:38:06 +0200 Subject: Something wrong with the package release chain? In-Reply-To: References: Message-ID: On Mon, May 12, 2014 at 1:33 PM, Maciej (Matchek) Blizi?ski wrote: > Yes, it is a known issue, it has been happening for a few months. Is it possible to get them "unstuck"? Or should I upload them again? From maciej at opencsw.org Mon May 12 13:55:24 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 12 May 2014 12:55:24 +0100 Subject: Something wrong with the package release chain? In-Reply-To: References: Message-ID: You can upload them again, you can use files directly from /export/mirror/... . The problem is that some other packages might have been removed from some catalogs. Not your packages - some other packages. These need to be uploaded again as well. Perhaps the atom feed contains this information. I have read the code multiple times and I don't see a bug. I an suspecting things like caching in the ORM, or parallel runs. I have recently added more logging to obtain more information. But the issue hasn't been triggered since, until now. I am now on vacations until the 17th, I will look at the logs then. Until that time, please try to identify the missing packages and upload them again. Sorry for the inconvenience! Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Mon May 12 12:12:14 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 12 May 2014 12:12:14 +0200 Subject: gnutls dependency In-Reply-To: <1399848574.10348.1.camel@anor> References: <536C1C2E.1060707@opencsw.org> <1399629985.7786.6.camel@anor> <3BBD09C5-863A-4952-8A1A-668BACADA840@opencsw.org> <1399664401.7374.112.camel@anor> <2F077FDD-73F3-41C4-8D97-2DDDC5EEE206@opencsw.org> <934B81D8-F9FE-438E-9847-8CAB27709DAB@opencsw.org> <1399740951.17202.10.camel@anor> <536F2652.8030601@opencsw.org> <599B3A45-4E37-4BAD-916C-AEBE3D0C4B83@opencsw.org> <1399848574.10348.1.camel@anor> Message-ID: <6BCB68A1-EB13-4E97-9A39-99FFF97A38B8@opencsw.org> Hi Riccardo, Am 12.05.2014 um 00:49 schrieb Riccardo Mottola : > Hi Dagobert, > > On 05/11/14 18:07, Dagobert Michelsen wrote: >> No, it was not :-) This is the ?check? phase. Just add another rule with >> TEST_SCRIPTS = sourcegs >> similar to the other ones. > Actually, gnustep "make check"is complicated and different, so I just > "disabled" it. I commited it, you might see the change. > > Now however, "mgar package" still fails. > > Making all in Tests ... > If you want to run the gnustep-base testsuite, please type 'make check' > /opt/csw/bin/ginstall: cannot create regular file > `/opt/csw/System/Library/Makefiles/Additional/base.make': Permission denied > Makefile.postamble:46: recipe for target 'before-install' failed > gmake[2]: *** [before-install] Error 1 > gmake[2]: Leaving directory > '/home/multix/code/opencsw/gnustep-base/trunk/work/build-isa-sparcv8plus/gnustep-base-1.24.6' > Makefile:47: recipe for target 'install-sourcegs' failed > > > Here I fear something tries to gets installed while the package is still > getting build? that sounds difficult. If you can tell me more, I might > ask the gnustep mailing list for help. > > Is "mgar package" trying to install? Of course, but to DESTDIR, make sure your package is DESTDIR-aware or override the respective prefix, bindir, etc. with DESTDIR prefixed. 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 slowfranklin at opencsw.org Mon May 12 17:57:12 2014 From: slowfranklin at opencsw.org (slowfranklin) Date: Mon, 12 May 2014 17:57:12 +0200 Subject: Something wrong with the package release chain? In-Reply-To: References: Message-ID: Hi all! Am 12.05.2014 um 13:33 schrieb Maciej (Matchek) Blizi?ski : > Yes, it is a known issue, it has been happening for a few months. hey, is it possibly triggered by uploading package for s10 and s11 at the same time? I remember someone pointing out to me (you?) that this should be avoided for some reason. I see Peter actually did upload 10 and 11 packages at the same time. -slow From bonivart at opencsw.org Mon May 12 18:09:26 2014 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 12 May 2014 18:09:26 +0200 Subject: Something wrong with the package release chain? In-Reply-To: References: Message-ID: On Mon, May 12, 2014 at 5:57 PM, slowfranklin wrote: > I see Peter actually did upload 10 and 11 packages at the same time. Not really, they are all built on 5.10 but they get inserted into both 5.10 and 5.11 catalogs. From slowfranklin at opencsw.org Mon May 12 18:48:53 2014 From: slowfranklin at opencsw.org (slowfranklin) Date: Mon, 12 May 2014 18:48:53 +0200 Subject: Something wrong with the package release chain? In-Reply-To: References: Message-ID: <858A2A9A-EC42-4210-8DFE-0FFD6CE236AA@opencsw.org> Am 12.05.2014 um 18:09 schrieb Peter Bonivart : > On Mon, May 12, 2014 at 5:57 PM, slowfranklin wrote: >> I see Peter actually did upload 10 and 11 packages at the same time. > > Not really, they are all built on 5.10 but they get inserted into both > 5.10 and 5.11 catalogs. ah sorry, was misreading in a hurry... -slow From dam at opencsw.org Tue May 13 10:33:01 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 13 May 2014 10:33:01 +0200 Subject: gnutls dependency In-Reply-To: References: <536C1C2E.1060707@opencsw.org> <1399629985.7786.6.camel@anor> <3BBD09C5-863A-4952-8A1A-668BACADA840@opencsw.org> <1399664401.7374.112.camel@anor> <2F077FDD-73F3-41C4-8D97-2DDDC5EEE206@opencsw.org> <934B81D8-F9FE-438E-9847-8CAB27709DAB@opencsw.org> <1399740951.17202.10.camel@anor> <536F2652.8030601@opencsw.org> <599B3A45-4E37-4BAD-916C-AEBE3D0C4B83@opencsw.org> <1399848574.10348.1.camel@anor> <1399881157.13066.0.camel@anor> <5371D6F3.6020809@libero.it> Message-ID: <6597C9AE-5AC0-481E-B335-ACE7A5D0F884@opencsw.org> Hi Riccardo, please user maintainers@ for general discussion. Am 13.05.2014 um 10:30 schrieb Maciej (Matchek) Blizi?ski : > I am on vacations. Electricity sparse. > > Google gar variable reference. Use lowercase $(prefix). > > Em 13/05/2014 09:25, "Riccardo Mottola" escreveu: > Hi Macjej, > > then some further newbie questions... > > Maciej (Matchek) Blizi?ski wrote: > Using the /opt/csw/GNUstep prefix sounds good. > the --prefix gets set automatically by csw. > > How do I best override it in mgar? and, further, in overriding it, how do I get the official value ? > I?'m thinking something along > > $PREFIX= $(PREFIX)/GNUstep > > so that in case someone wants to override /opt/csw everything moves with... I could force it in configure, but then I would get on the same command line both the --prefix specified by mgar automatically? The idiom to use for complete tree redirection is prefix = $(BUILD_PREFIX)/GNUstep See for an example e.g. https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/pkg/bdb48/trunk/Makefile#33 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 bonivart at opencsw.org Tue May 13 17:15:05 2014 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 13 May 2014 17:15:05 +0200 Subject: Something wrong with the package release chain? In-Reply-To: References: Message-ID: On Mon, May 12, 2014 at 1:55 PM, Maciej (Matchek) Blizi?ski wrote: > I have read the code multiple times and I don't see a bug. I an suspecting > things like caching in the ORM, or parallel runs. I have recently added more > logging to obtain more information. But the issue hasn't been triggered > since, until now. I am now on vacations until the 17th, I will look at the > logs then. Until that time, please try to identify the missing packages and > upload them again. Sorry for the inconvenience! I have now uploaded the missing packages twice with no success, it recognized them as already uploaded since it skips the actual upload and proceeds with the checks and insertion which completes successfully. Then nothing. I assume other packages are possible to upload and get published while mine are stuck otherwise others would complain now too. Have a good vacation but know that you're welcome back as well. :) From slowfranklin at opencsw.org Tue May 13 17:18:24 2014 From: slowfranklin at opencsw.org (slowfranklin) Date: Tue, 13 May 2014 17:18:24 +0200 Subject: Something wrong with the package release chain? In-Reply-To: References: Message-ID: Am 13.05.2014 um 17:15 schrieb Peter Bonivart : > On Mon, May 12, 2014 at 1:55 PM, Maciej (Matchek) Blizi?ski > wrote: >> I have read the code multiple times and I don't see a bug. I an suspecting >> things like caching in the ORM, or parallel runs. I have recently added more >> logging to obtain more information. But the issue hasn't been triggered >> since, until now. I am now on vacations until the 17th, I will look at the >> logs then. Until that time, please try to identify the missing packages and >> upload them again. Sorry for the inconvenience! > > I have now uploaded the missing packages twice with no success, it > recognized them as already uploaded since it skips the actual upload > and proceeds with the checks and insertion which completes > successfully. Then nothing. > > I assume other packages are possible to upload and get published while > mine are stuck otherwise others would complain now too. *complain* I tried to upload libglib2-dev twice without success. csw-upload-pkg finished successfully, but the updated packages never hit the catalog. -Ralph From dam at opencsw.org Tue May 13 18:58:20 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 13 May 2014 18:58:20 +0200 Subject: Something wrong with the package release chain? In-Reply-To: References: Message-ID: <3895F96C-4B6F-47B8-AAA0-C10079ADFBEA@opencsw.org> Hi folks, Am 13.05.2014 um 17:18 schrieb slowfranklin : > Am 13.05.2014 um 17:15 schrieb Peter Bonivart : >> On Mon, May 12, 2014 at 1:55 PM, Maciej (Matchek) Blizi?ski >> wrote: >>> I have read the code multiple times and I don't see a bug. I an suspecting >>> things like caching in the ORM, or parallel runs. I have recently added more >>> logging to obtain more information. But the issue hasn't been triggered >>> since, until now. I am now on vacations until the 17th, I will look at the >>> logs then. Until that time, please try to identify the missing packages and >>> upload them again. Sorry for the inconvenience! >> >> I have now uploaded the missing packages twice with no success, it >> recognized them as already uploaded since it skips the actual upload >> and proceeds with the checks and insertion which completes >> successfully. Then nothing. >> >> I assume other packages are possible to upload and get published while >> mine are stuck otherwise others would complain now too. > > *complain* > > I tried to upload libglib2-dev twice without success. csw-upload-pkg finished successfully, but the updated packages never hit the catalog. Got it :-) 2014/05/13 18:52:28 Problem in the catalog: Package CSWamavisdnew declares dependency on CSWspamassassin but CSWspamassassin is missing from the {unstable sparc SunOS5.11} catalog. 2014/05/13 18:52:28 Problem in the catalog: Package CSWbotnet declares dependency on CSWspamassassin but CSWspamassassin is missing from the {unstable sparc SunOS5.11} catalog. 2014/05/13 18:52:28 Problem in the catalog: Package CSWspamass-milter declares dependency on CSWspamassassin but CSWspamassassin is missing from the {unstable sparc SunOS5.11} catalog. 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 bonivart at opencsw.org Tue May 13 19:44:08 2014 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 13 May 2014 19:44:08 +0200 Subject: Something wrong with the package release chain? In-Reply-To: <3895F96C-4B6F-47B8-AAA0-C10079ADFBEA@opencsw.org> References: <3895F96C-4B6F-47B8-AAA0-C10079ADFBEA@opencsw.org> Message-ID: On Tue, May 13, 2014 at 6:58 PM, Dagobert Michelsen wrote: > Got it :-) > > 2014/05/13 18:52:28 Problem in the catalog: Package CSWamavisdnew declares dependency on CSWspamassassin but CSWspamassassin is missing from the {unstable sparc SunOS5.11} catalog. > 2014/05/13 18:52:28 Problem in the catalog: Package CSWbotnet declares dependency on CSWspamassassin but CSWspamassassin is missing from the {unstable sparc SunOS5.11} catalog. > 2014/05/13 18:52:28 Problem in the catalog: Package CSWspamass-milter declares dependency on CSWspamassassin but CSWspamassassin is missing from the {unstable sparc SunOS5.11} catalog. Weird, SpamAssassin was one of the packages I "successfully" uploaded this weekend. I just re-uploaded it, output below, so we can see if this heals the catalog. :) $ csw-upload-pkg spamassassin-3.4.0\,REV\=2014.05.09-SunOS5.10-* Processing 2 file(s). Please wait. Checking 1 package against catalog unstable i386 SunOS5.10 Checking 1 package against catalog unstable sparc SunOS5.10 Checking 1 package against catalog unstable i386 SunOS5.11 Checking 1 package against catalog unstable sparc SunOS5.11 All checks successful. Proceeding. Inserting spamassassin (i386 SunOS5.10) into catalog unstable i386 SunOS5.10 Inserting spamassassin (i386 SunOS5.10) into catalog unstable i386 SunOS5.11 Inserting spamassassin (sparc SunOS5.10) into catalog unstable sparc SunOS5.10 Inserting spamassassin (sparc SunOS5.10) into catalog unstable sparc SunOS5.11 From slowfranklin at opencsw.org Tue May 13 21:52:35 2014 From: slowfranklin at opencsw.org (slowfranklin) Date: Tue, 13 May 2014 21:52:35 +0200 Subject: Something wrong with the package release chain? In-Reply-To: <3895F96C-4B6F-47B8-AAA0-C10079ADFBEA@opencsw.org> References: <3895F96C-4B6F-47B8-AAA0-C10079ADFBEA@opencsw.org> Message-ID: <6C9787C7-7166-4B6A-9CE6-B3F4FB4D081F@opencsw.org> Hi Dago, Am 13.05.2014 um 18:58 schrieb Dagobert Michelsen : > Hi folks, > > Am 13.05.2014 um 17:18 schrieb slowfranklin : >> Am 13.05.2014 um 17:15 schrieb Peter Bonivart : >>> On Mon, May 12, 2014 at 1:55 PM, Maciej (Matchek) Blizi?ski >>> wrote: >>>> I have read the code multiple times and I don't see a bug. I an suspecting >>>> things like caching in the ORM, or parallel runs. I have recently added more >>>> logging to obtain more information. But the issue hasn't been triggered >>>> since, until now. I am now on vacations until the 17th, I will look at the >>>> logs then. Until that time, please try to identify the missing packages and >>>> upload them again. Sorry for the inconvenience! >>> >>> I have now uploaded the missing packages twice with no success, it >>> recognized them as already uploaded since it skips the actual upload >>> and proceeds with the checks and insertion which completes >>> successfully. Then nothing. >>> >>> I assume other packages are possible to upload and get published while >>> mine are stuck otherwise others would complain now too. >> >> *complain* >> >> I tried to upload libglib2-dev twice without success. csw-upload-pkg finished successfully, but the updated packages never hit the catalog. > > Got it :-) where? -slow From dam at opencsw.org Tue May 13 22:59:20 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 13 May 2014 22:59:20 +0200 Subject: Something wrong with the package release chain? In-Reply-To: <6C9787C7-7166-4B6A-9CE6-B3F4FB4D081F@opencsw.org> References: <3895F96C-4B6F-47B8-AAA0-C10079ADFBEA@opencsw.org> <6C9787C7-7166-4B6A-9CE6-B3F4FB4D081F@opencsw.org> Message-ID: Hi folks, Am 13.05.2014 um 21:52 schrieb slowfranklin : > Am 13.05.2014 um 18:58 schrieb Dagobert Michelsen : >> Am 13.05.2014 um 17:18 schrieb slowfranklin : >>> Am 13.05.2014 um 17:15 schrieb Peter Bonivart : >>>> On Mon, May 12, 2014 at 1:55 PM, Maciej (Matchek) Blizi?ski >>>> wrote: >>>>> I have read the code multiple times and I don't see a bug. I an suspecting >>>>> things like caching in the ORM, or parallel runs. I have recently added more >>>>> logging to obtain more information. But the issue hasn't been triggered >>>>> since, until now. I am now on vacations until the 17th, I will look at the >>>>> logs then. Until that time, please try to identify the missing packages and >>>>> upload them again. Sorry for the inconvenience! >>>> >>>> I have now uploaded the missing packages twice with no success, it >>>> recognized them as already uploaded since it skips the actual upload >>>> and proceeds with the checks and insertion which completes >>>> successfully. Then nothing. >>>> >>>> I assume other packages are possible to upload and get published while >>>> mine are stuck otherwise others would complain now too. >>> >>> *complain* >>> >>> I tried to upload libglib2-dev twice without success. csw-upload-pkg finished successfully, but the updated packages never hit the catalog. >> >> Got it :-) > > where? The missing package issue has been resolved and catalog generation is running 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 rmottola at opencsw.org Wed May 14 01:17:46 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Wed, 14 May 2014 01:17:46 +0200 Subject: gnutls dependency In-Reply-To: <6BCB68A1-EB13-4E97-9A39-99FFF97A38B8@opencsw.org> References: <536C1C2E.1060707@opencsw.org> <1399629985.7786.6.camel@anor> <3BBD09C5-863A-4952-8A1A-668BACADA840@opencsw.org> <1399664401.7374.112.camel@anor> <2F077FDD-73F3-41C4-8D97-2DDDC5EEE206@opencsw.org> <934B81D8-F9FE-438E-9847-8CAB27709DAB@opencsw.org> <1399740951.17202.10.camel@anor> <536F2652.8030601@opencsw.org> <599B3A45-4E37-4BAD-916C-AEBE3D0C4B83@opencsw.org> <1399848574.10348.1.camel@anor> <6BCB68A1-EB13-4E97-9A39-99FFF97A38B8@opencsw.org> Message-ID: <1400023066.899.57.camel@anor> Hi Dagobert, On Mon, 2014-05-12 at 12:12, Dagobert Michelsen wrote: > > > Of course, but to DESTDIR, make sure your package is DESTDIR-aware or > override the respective prefix, bindir, etc. with DESTDIR prefixed. gnustep-base is DESTDIR aware, I asked the gnustep guys to be sure. Other packages use DESTDIR when building e.g. RPMs What could be wrong? I use this: install-sourcegs: . $(BUILD_PREFIX)/GNUstep/System/Library/Makefiles/GNUstep.sh && cd $(WORKSRC) && /usr/bin/env -i $(BUILD_ENV) && $(MAKE) install @$(MAKECOOKIE) If you look below, I don't see DESTDIR... I though it woulld come in with BUILD_ENV ? Riccardo [test-modulated] complete for gnustep-base. . /opt/csw/GNUstep/System/Library/Makefiles/GNUstep.sh && cd work/build-isa-sparcv8plus/gnustep-base-1.24.6 && /usr/bin/env -i HOME="/home/multix" PATH="/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/bin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/bin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/sbin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/sbin:/opt/csw/bin:/opt/csw/bin:/opt/csw/sbin:/opt/csw/sbin:/opt/csw/bin:/home/multix/code/opencsw/.buildsys/v2/gar/bin:/usr/bin:/usr/sbin:/usr/java/bin:/usr/ccs/bin:/usr/openwin/bin" LC_ALL="C" prefix="/opt/csw" exec_prefix="/opt/csw" bindir="/opt/csw/bin" sbindir="/opt/csw/sbin" libexecdir="/opt/csw/libexec" datadir="/opt/csw/share" sysconfdir="/etc/opt/csw" sharedstatedir="/opt/csw/share" localstatedir="/var/opt/csw" libdir="/opt/csw/lib" infodir="/opt/csw/share/info" lispdir="/opt/csw/share/emacs/site-lisp" includedir="/opt/csw/include" mandir="/opt/csw/share/man" docdir="/opt/csw/share/doc" sourcedir="/opt/csw/src" CPPFLAGS="-I/opt/csw/include" CFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" CXXFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" LDFLAGS="-mcpu=v9 -Wa,-xarch=v8plus -L/opt/csw/lib" FFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" FCFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" F77="/opt/csw/bin/gfortran-4.9" FC="/opt/csw/bin/gfortran-4.9" ASFLAGS="" OPTFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" CC="/opt/csw/bin/gcc-4.9" CXX="/opt/csw/bin/g++-4.9" CC_HOME="/opt/csw" CC_VERSION="gcc version 4.9.0 (GCC) " CXX_VERSION="gcc version 4.9.0 (GCC) " GARCH="sparc" GAROSREL="5.10" GARPACKAGE="trunk" LD_OPTIONS="-R/opt/csw/lib/\$ISALIST -R/opt/csw/lib -B direct -z ignore" && gmake install LD_OPTIONS=-R/opt/csw/lib/$ISALIST -R/opt/csw/lib -B direct -z ignore GARPACKAGE=trunk GAROSREL=5.10 GARCH=sparc CXX_VERSION=gcc version 4.9.0 (GCC) CC_VERSION=gcc version 4.9.0 (GCC) CC_HOME=/opt/csw CXX=/opt/csw/bin/g++-4.9 CC=/opt/csw/bin/gcc-4.9 OPTFLAGS=-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus ASFLAGS= FC=/opt/csw/bin/gfortran-4.9 F77=/opt/csw/bin/gfortran-4.9 FCFLAGS=-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus FFLAGS=-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus LDFLAGS=-mcpu=v9 -Wa,-xarch=v8plus -L/opt/csw/lib CXXFLAGS=-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus CFLAGS=-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus CPPFLAGS=-I/opt/csw/include sourcedir=/opt/csw/src docdir=/opt/csw/share/doc mandir=/opt/csw/share/man includedir=/opt/csw/include lispdir=/opt/csw/share/emacs/site-lisp infodir=/opt/csw/share/info libdir=/opt/csw/lib localstatedir=/var/opt/csw sharedstatedir=/opt/csw/share sysconfdir=/etc/opt/csw datadir=/opt/csw/share libexecdir=/opt/csw/libexec sbindir=/opt/csw/sbin bindir=/opt/csw/bin exec_prefix=/opt/csw prefix=/opt/csw LC_ALL=C PATH=/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/bin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/bin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/sbin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/sbin:/opt/csw/bin:/opt/csw/bin:/opt/csw/sbin:/opt/csw/sbin:/opt/csw/bin:/home/multix/code/opencsw/.buildsys/v2/gar/bin:/usr/bin:/usr/sbin:/usr/java/bin:/usr/ccs/bin:/usr/openwin/bin HOME=/home/multix gmake[2]: Entering directory '/home/multix/code/opencsw/gnustep-base/trunk/work/build-isa-sparcv8plus/gnustep-base-1.24.6' This is gnustep-make 2.6.6. Type 'gmake print-gnustep-make-help' for help. Making all in Source ... Making all in Additions ... Making all for subproject Additions... gmake[6]: Nothing to be done for 'internal-subproject-compile'. Making all in subprojects of library libgnustep-base... Making all for subproject ObjectiveC2... gmake[7]: Nothing to be done for 'internal-subproject-compile'. Making all for subproject Additions... gmake[7]: Nothing to be done for 'internal-subproject-compile'. Making all for subproject unix... gmake[7]: Nothing to be done for 'internal-subproject-compile'. Making all for library libgnustep-base... gmake[6]: Nothing to be done for 'internal-library-compile'. Making all in Tools ... Making all for tool autogsdoc... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool cvtenc... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool gdnc... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool gspath... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool defaults... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool pl... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool plmerge... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool plparse... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool sfparse... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool pldes... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool plget... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool plser... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool pl2link... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool xmlparse... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool HTMLLinker... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for ctool gdomap... gmake[6]: Nothing to be done for 'internal-ctool-compile'. Making all in make_strings ... Making all for tool make_strings... gmake[7]: Nothing to be done for 'internal-tool-compile'. Making all in NSTimeZones ... gmake[3]: Nothing to be done for 'all'. Making all in Resources ... gmake[3]: Nothing to be done for 'all'. Making all in Tests ... If you want to run the gnustep-base testsuite, please type 'make check' /opt/csw/bin/ginstall: cannot create regular file `/opt/csw/GNUstep/System/Library/Makefiles/Additional/base.make': Permission denied Makefile.postamble:46: recipe for target 'before-install' failed From dam at opencsw.org Wed May 14 09:28:31 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 14 May 2014 09:28:31 +0200 Subject: gnutls dependency In-Reply-To: <1400023066.899.57.camel@anor> References: <536C1C2E.1060707@opencsw.org> <1399629985.7786.6.camel@anor> <3BBD09C5-863A-4952-8A1A-668BACADA840@opencsw.org> <1399664401.7374.112.camel@anor> <2F077FDD-73F3-41C4-8D97-2DDDC5EEE206@opencsw.org> <934B81D8-F9FE-438E-9847-8CAB27709DAB@opencsw.org> <1399740951.17202.10.camel@anor> <536F2652.8030601@opencsw.org> <599B3A45-4E37-4BAD-916C-AEBE3D0C4B83@opencsw.org> <1399848574.10348.1.camel@anor> <6BCB68A1-EB13-4E97-9A39-99FFF97A38B8@opencsw.org> <1400023066.899.57.camel@anor> Message-ID: <42F3DF35-C256-41FB-AC4D-25EE42EA2428@opencsw.org> Hi Riccardo, Am 14.05.2014 um 01:17 schrieb Riccardo Mottola : > On Mon, 2014-05-12 at 12:12, Dagobert Michelsen wrote: >> Of course, but to DESTDIR, make sure your package is DESTDIR-aware or >> override the respective prefix, bindir, etc. with DESTDIR prefixed. > > gnustep-base is DESTDIR aware, I asked the gnustep guys to be sure. > Other packages use DESTDIR when building e.g. RPMs > > What could be wrong? > > I use this: > > install-sourcegs: > . $(BUILD_PREFIX)/GNUstep/System/Library/Makefiles/GNUstep.sh && cd > $(WORKSRC) && /usr/bin/env -i $(BUILD_ENV) && $(MAKE) install > @$(MAKECOOKIE) > > If you look below, I don't see DESTDIR... I though it woulld come in > with BUILD_ENV ? No, INSTALL_ENV :-) https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/gar/v2/gar.lib.mk#1003 See here for the respective exports: https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/gar/v2/gar.conf.mk#848 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 rmottola at opencsw.org Thu May 15 00:14:54 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Thu, 15 May 2014 00:14:54 +0200 Subject: gnutls dependency In-Reply-To: <42F3DF35-C256-41FB-AC4D-25EE42EA2428@opencsw.org> References: <536C1C2E.1060707@opencsw.org> <1399629985.7786.6.camel@anor> <3BBD09C5-863A-4952-8A1A-668BACADA840@opencsw.org> <1399664401.7374.112.camel@anor> <2F077FDD-73F3-41C4-8D97-2DDDC5EEE206@opencsw.org> <934B81D8-F9FE-438E-9847-8CAB27709DAB@opencsw.org> <1399740951.17202.10.camel@anor> <536F2652.8030601@opencsw.org> <599B3A45-4E37-4BAD-916C-AEBE3D0C4B83@opencsw.org> <1399848574.10348.1.camel@anor> <6BCB68A1-EB13-4E97-9A39-99FFF97A38B8@opencsw.org> <1400023066.899.57.camel@anor> <42F3DF35-C256-41FB-AC4D-25EE42EA2428@opencsw.org> Message-ID: <1400105693.2298.2.camel@anor> Hi, On Wed, 2014-05-14 at 09:28, Dagobert Michelsen wrote: > Hi Riccardo, > don't see DESTDIR... I though it woulld come in > > with BUILD_ENV ? > > No, INSTALL_ENV :-) > https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/gar/v2/gar.lib.mk#1003 > See here for the respective exports: > https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/gar/v2/gar.conf.mk#848 > What would be th difference between export and env, in this case? Anyway, is ee that there is a variable for each stage. I changed to isntall-env and now at least I see the correct parameter being pased as evn variable, as I paste below. However, it still fails for me in the same place. Could it be an upstream bug that nobody detected while doing RPMs for example? It would be strange. R Here the error. I can see now DESTDIR being set: . /opt/csw/GNUstep/System/Library/Makefiles/GNUstep.sh && cd work/build-isa-sparcv8plus/gnustep-base-1.24.6 && /usr/bin/env -i HOME="/home/multix" PATH="/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/bin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/bin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/sbin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/sbin:/opt/csw/bin:/opt/csw/bin:/opt/csw/sbin:/opt/csw/sbin:/opt/csw/bin:/home/multix/code/opencsw/.buildsys/v2/gar/bin:/usr/bin:/usr/sbin:/usr/java/bin:/usr/ccs/bin:/usr/openwin/bin" LC_ALL="C" prefix="/opt/csw" exec_prefix="/opt/csw" bindir="/opt/csw/bin" sbindir="/opt/csw/sbin" libexecdir="/opt/csw/libexec" datadir="/opt/csw/share" sysconfdir="/etc/opt/csw" sharedstatedir="/opt/csw/share" localstatedir="/var/opt/csw" libdir="/opt/csw/lib" infodir="/opt/csw/share/info" lispdir="/opt/csw/share/emacs/site-lisp" includedir="/opt/csw/include" mandir="/opt/csw/share/man" docdir="/opt/csw/share/doc" sourcedir="/opt/csw/src" CPPFLAGS="-I/opt/csw/include" CFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" CXXFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" LDFLAGS="-mcpu=v9 -Wa,-xarch=v8plus -L/opt/csw/lib" FFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" FCFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" F77="/opt/csw/bin/gfortran-4.9" FC="/opt/csw/bin/gfortran-4.9" ASFLAGS="" OPTFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" CC="/opt/csw/bin/gcc-4.9" CXX="/opt/csw/bin/g++-4.9" CC_HOME="/opt/csw" CC_VERSION="gcc version 4.9.0 (GCC) " CXX_VERSION="gcc version 4.9.0 (GCC) " GARCH="sparc" GAROSREL="5.10" GARPACKAGE="trunk" LD_OPTIONS="-R/opt/csw/lib/\$ISALIST -R/opt/csw/lib -B direct -z ignore" DESTDIR="/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus" && gmake install DESTDIR=/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus LD_OPTIONS=-R/opt/csw/lib/$ISALIST -R/opt/csw/lib -B direct -z ignore GARPACKAGE=trunk GAROSREL=5.10 GARCH=sparc CXX_VERSION=gcc version 4.9.0 (GCC) CC_VERSION=gcc version 4.9.0 (GCC) CC_HOME=/opt/csw CXX=/opt/csw/bin/g++-4.9 CC=/opt/csw/bin/gcc-4.9 OPTFLAGS=-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus ASFLAGS= FC=/opt/csw/bin/gfortran-4.9 F77=/opt/csw/bin/gfortran-4.9 FCFLAGS=-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus FFLAGS=-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus LDFLAGS=-mcpu=v9 -Wa,-xarch=v8plus -L/opt/csw/lib CXXFLAGS=-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus CFLAGS=-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus CPPFLAGS=-I/opt/csw/include sourcedir=/opt/csw/src docdir=/opt/csw/share/doc mandir=/opt/csw/share/man includedir=/opt/csw/include lispdir=/opt/csw/share/emacs/site-lisp infodir=/opt/csw/share/info libdir=/opt/csw/lib localstatedir=/var/opt/csw sharedstatedir=/opt/csw/share sysconfdir=/etc/opt/csw datadir=/opt/csw/share libexecdir=/opt/csw/libexec sbindir=/opt/csw/sbin bindir=/opt/csw/bin exec_prefix=/opt/csw prefix=/opt/csw LC_ALL=C PATH=/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/bin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/bin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/sbin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/sbin:/opt/csw/bin:/opt/csw/bin:/opt/csw/sbin:/opt/csw/sbin:/opt/csw/bin:/home/multix/code/opencsw/.buildsys/v2/gar/bin:/usr/bin:/usr/sbin:/usr/java/bin:/usr/ccs/bin:/usr/openwin/bin HOME=/home/multix gmake[2]: Entering directory '/home/multix/code/opencsw/gnustep-base/trunk/work/build-isa-sparcv8plus/gnustep-base-1.24.6' This is gnustep-make 2.6.6. Type 'gmake print-gnustep-make-help' for help. Making all in Source ... Making all in Additions ... Making all for subproject Additions... gmake[6]: Nothing to be done for 'internal-subproject-compile'. Making all in subprojects of library libgnustep-base... Making all for subproject ObjectiveC2... gmake[7]: Nothing to be done for 'internal-subproject-compile'. Making all for subproject Additions... gmake[7]: Nothing to be done for 'internal-subproject-compile'. Making all for subproject unix... gmake[7]: Nothing to be done for 'internal-subproject-compile'. Making all for library libgnustep-base... gmake[6]: Nothing to be done for 'internal-library-compile'. Making all in Tools ... Making all for tool autogsdoc... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool cvtenc... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool gdnc... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool gspath... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool defaults... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool pl... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool plmerge... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool plparse... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool sfparse... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool pldes... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool plget... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool plser... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool pl2link... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool xmlparse... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for tool HTMLLinker... gmake[6]: Nothing to be done for 'internal-tool-compile'. Making all for ctool gdomap... gmake[6]: Nothing to be done for 'internal-ctool-compile'. Making all in make_strings ... Making all for tool make_strings... gmake[7]: Nothing to be done for 'internal-tool-compile'. Making all in NSTimeZones ... gmake[3]: Nothing to be done for 'all'. Making all in Resources ... gmake[3]: Nothing to be done for 'all'. Making all in Tests ... If you want to run the gnustep-base testsuite, please type 'make check' /opt/csw/bin/ginstall: cannot create regular file `/opt/csw/GNUstep/System/Library/Makefiles/Additional/base.make': Permission denied Makefile.postamble:46: recipe for target 'before-install' failed gmake[2]: *** [before-install] Error 1 From slowfranklin at opencsw.org Thu May 15 12:49:08 2014 From: slowfranklin at opencsw.org (slowfranklin) Date: Thu, 15 May 2014 12:49:08 +0200 Subject: "_FILE_OFFSET_BITS" redefined Message-ID: Hi guys and a cheerio from SambaXP! I'm working on a poppler update and noticed that compilation spits out lot of LFS related warning: ---8<--- In file included from poppler-private.h:4:0, from poppler-form-field.cc:22: ../config.h:262:0: warning: "_FILE_OFFSET_BITS" redefined #define _FILE_OFFSET_BITS 64 ^ In file included from /usr/include/limits.h:17:0, from /opt/csw/lib/gcc/i386-pc-solaris2.10/4.9.0/include-fixed/limits.h:168, from /opt/csw/lib/gcc/i386-pc-solaris2.10/4.9.0/include-fixed/syslimits.h:7, from /opt/csw/lib/gcc/i386-pc-solaris2.10/4.9.0/include-fixed/limits.h:34, from /opt/csw/lib/glib-2.0/include/glibconfig.h:11, from /opt/csw/include/glib-2.0/glib/gtypes.h:32, from /opt/csw/include/glib-2.0/glib/galloca.h:32, from /opt/csw/include/glib-2.0/glib.h:30, from /opt/csw/include/glib-2.0/gobject/gbinding.h:28, from /opt/csw/include/glib-2.0/glib-object.h:23, from poppler.h:22, from poppler-form-field.cc:21: /opt/csw/lib/gcc/i386-pc-solaris2.10/4.9.0/include-fixed/sys/feature_tests.h:196:0: note: this is the location of the previous definition #define _FILE_OFFSET_BITS 32 ^ ---8<--- poppler uses the autoconf macro for enabling LFS support so things should just work afaict. I can't remember ever having to fix LFS issues in may OpenCSW packages. Is there anything simple I can do to fix this? Thanks! From Joerg.Schilling at fokus.fraunhofer.de Thu May 15 12:57:25 2014 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Thu, 15 May 2014 12:57:25 +0200 Subject: "_FILE_OFFSET_BITS" redefined In-Reply-To: References: Message-ID: <53749d95.K4otto4Z+sbRqJ8z%Joerg.Schilling@fokus.fraunhofer.de> slowfranklin wrote: > Hi guys and a cheerio from SambaXP! > > I'm working on a poppler update and noticed that compilation spits out lot of LFS related warning: > > ---8<--- > In file included from poppler-private.h:4:0, > from poppler-form-field.cc:22: > ../config.h:262:0: warning: "_FILE_OFFSET_BITS" redefined > #define _FILE_OFFSET_BITS 64 > ^ > In file included from /usr/include/limits.h:17:0, > from /opt/csw/lib/gcc/i386-pc-solaris2.10/4.9.0/include-fixed/limits.h:168, > from /opt/csw/lib/gcc/i386-pc-solaris2.10/4.9.0/include-fixed/syslimits.h:7, > from /opt/csw/lib/gcc/i386-pc-solaris2.10/4.9.0/include-fixed/limits.h:34, > from /opt/csw/lib/glib-2.0/include/glibconfig.h:11, > from /opt/csw/include/glib-2.0/glib/gtypes.h:32, > from /opt/csw/include/glib-2.0/glib/galloca.h:32, > from /opt/csw/include/glib-2.0/glib.h:30, > from /opt/csw/include/glib-2.0/gobject/gbinding.h:28, > from /opt/csw/include/glib-2.0/glib-object.h:23, > from poppler.h:22, > from poppler-form-field.cc:21: > /opt/csw/lib/gcc/i386-pc-solaris2.10/4.9.0/include-fixed/sys/feature_tests.h:196:0: note: this is the location of the previous definition > #define _FILE_OFFSET_BITS 32 > ^ > ---8<--- > > poppler uses the autoconf macro for enabling LFS support so things should just work afaict. _FILE_OFFSET_BITS must be (if ever) set one before including any system include file. This OSS is aparently broken as it first includes system include files and later includes it's config.h. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From slowfranklin at opencsw.org Thu May 15 17:43:41 2014 From: slowfranklin at opencsw.org (slowfranklin) Date: Thu, 15 May 2014 17:43:41 +0200 Subject: "_FILE_OFFSET_BITS" redefined In-Reply-To: <53749d95.K4otto4Z+sbRqJ8z%Joerg.Schilling@fokus.fraunhofer.de> References: <53749d95.K4otto4Z+sbRqJ8z%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: Am 15.05.2014 um 12:57 schrieb Joerg Schilling : > slowfranklin wrote: > >> Hi guys and a cheerio from SambaXP! >> >> I'm working on a poppler update and noticed that compilation spits out lot of LFS related warning: >> >> ---8<--- >> In file included from poppler-private.h:4:0, >> from poppler-form-field.cc:22: >> ../config.h:262:0: warning: "_FILE_OFFSET_BITS" redefined >> #define _FILE_OFFSET_BITS 64 >> ^ >> In file included from /usr/include/limits.h:17:0, >> from /opt/csw/lib/gcc/i386-pc-solaris2.10/4.9.0/include-fixed/limits.h:168, >> from /opt/csw/lib/gcc/i386-pc-solaris2.10/4.9.0/include-fixed/syslimits.h:7, >> from /opt/csw/lib/gcc/i386-pc-solaris2.10/4.9.0/include-fixed/limits.h:34, >> from /opt/csw/lib/glib-2.0/include/glibconfig.h:11, >> from /opt/csw/include/glib-2.0/glib/gtypes.h:32, >> from /opt/csw/include/glib-2.0/glib/galloca.h:32, >> from /opt/csw/include/glib-2.0/glib.h:30, >> from /opt/csw/include/glib-2.0/gobject/gbinding.h:28, >> from /opt/csw/include/glib-2.0/glib-object.h:23, >> from poppler.h:22, >> from poppler-form-field.cc:21: >> /opt/csw/lib/gcc/i386-pc-solaris2.10/4.9.0/include-fixed/sys/feature_tests.h:196:0: note: this is the location of the previous definition >> #define _FILE_OFFSET_BITS 32 >> ^ >> ---8<--- >> >> poppler uses the autoconf macro for enabling LFS support so things should just work afaict. > > _FILE_OFFSET_BITS must be (if ever) set one before including any system include > file. > > This OSS is aparently broken as it first includes system include files and > later includes it's config.h. This OSS is Solaris 10 on the buildfarm. :) -bash-4.3$ hostname unstable10x -bash-4.3$ uname -a SunOS unstable10x 5.10 Generic_147441-19 i86pc i386 i86pc -bash-4.3$ Turned out the poppler guys simply fail to properly include config.h in all places. Stuffing _FILE_OFFSET_BITS=64 in its throat from gar fixes it. Cheers! -slow From gmarler at opencsw.org Thu May 15 19:43:15 2014 From: gmarler at opencsw.org (Gordon Marler) Date: Thu, 15 May 2014 13:43:15 -0400 Subject: We should talk about getting IPS packages going In-Reply-To: References: <53686E3A.6030508@opencsw.org> Message-ID: <5374FCB3.1080404@opencsw.org> On 5/11/2014 5:59 PM, Maciej (Matchek) Blizi?ski wrote: > > Em 06/05/2014 06:08, "Gordon Marler" > escreveu: > > Stripping out the features in mgar that are native to IPS is > probably important, to avoid duplication of effort. > > My idea was to use "mgar merge" to get the pkgroot directory. Then we > could use any means necessary to build an IPS package front that > pkgroot, taking as much information as possible from the GAR build > recipe. Then we would ask Dago for help in integrating it into GAR. > > Gordon, do you think it's possible to start that way? Is anything > blocking you? > Sounds reasonable. Just getting myself reactivated and up to speed now. IRC (I'll be gmarler, duh), and reading up on all that's changed while I've been "dormant". I guess the only thing slowing me down would be this: - I suppose we'll be starting this IPS repo from scratch, so I'd better start building packages from the foundation up, and we'll fix items as they show up as obstacles along the way. Is there a nice way to either see or generate a dependency list of the package chain from the bottom up? That'll provide a nice map to follow. Separately, and I'll probably see this shortly, but is there a Solaris 11 x86 or SPARC system in the buildfarm? If not, I have an x86 variant available. Having a SPARC M-x000 or T4 or higher will be required if we want to have dual binary builds for each package, which IPS supports now. If not, it's easily added later. > Maciej > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmarler at opencsw.org Thu May 15 19:47:31 2014 From: gmarler at opencsw.org (Gordon Marler) Date: Thu, 15 May 2014 13:47:31 -0400 Subject: We should talk about getting IPS packages going In-Reply-To: References: <53686E3A.6030508@opencsw.org> Message-ID: <5374FDB3.40605@opencsw.org> On 5/11/2014 5:59 PM, Maciej (Matchek) Blizi?ski wrote: > > Em 06/05/2014 06:08, "Gordon Marler" > escreveu: > > Stripping out the features in mgar that are native to IPS is > probably important, to avoid duplication of effort. > > My idea was to use "mgar merge" to get the pkgroot directory. Then we > could use any means necessary to build an IPS package front that > pkgroot, taking as much information as possible from the GAR build > recipe. Then we would ask Dago for help in integrating it into GAR. > > Gordon, do you think it's possible to start that way? Is anything > blocking you? > Sounds reasonable. Just getting myself reactivated and up to speed now. IRC (I'll be gmarler, duh), and reading up on all that's changed while I've been "dormant". I guess the only thing slowing me down would be this: - I suppose we'll be starting this IPS repo from scratch, so I'd better start building packages from the foundation up, and we'll fix items as they show up as obstacles along the way. Is there a nice way to either see or generate a dependency list of the package chain from the bottom up? That'll provide a nice map to follow. Separately, and I'll probably see this shortly, but is there a Solaris 11 x86 or SPARC system in the buildfarm? If not, I have an x86 variant available. Having a SPARC M-x000 or T4 or higher will be required if we want to have dual binary builds for each package, which IPS supports now. If not, it's easily added later. > Maciej > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Thu May 15 21:44:27 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 15 May 2014 21:44:27 +0200 Subject: We should talk about getting IPS packages going In-Reply-To: <5374FCB3.1080404@opencsw.org> References: <53686E3A.6030508@opencsw.org> <5374FCB3.1080404@opencsw.org> Message-ID: <43574DFE-DAE8-4E48-AB77-596B563D1EC3@opencsw.org> Hi Gordon, Am 15.05.2014 um 19:43 schrieb Gordon Marler : > On 5/11/2014 5:59 PM, Maciej (Matchek) Blizi?ski wrote: >> Em 06/05/2014 06:08, "Gordon Marler" escreveu: >> > Stripping out the features in mgar that are native to IPS is probably important, to avoid duplication of effort. >> >> My idea was to use "mgar merge" to get the pkgroot directory. Then we could use any means necessary to build an IPS package front that pkgroot, taking as much information as possible from the GAR build recipe. Then we would ask Dago for help in integrating it into GAR. >> >> Gordon, do you think it's possible to start that way? Is anything blocking you? > > Sounds reasonable. Just getting myself reactivated and up to speed now. IRC (I'll be gmarler, duh), and reading up on all that's changed while I've been "dormant". > > I guess the only thing slowing me down would be this: > > - I suppose we'll be starting this IPS repo from scratch, so I'd better start building packages from the foundation up, and we'll fix items as they show up as obstacles along the way. Is there a nice way to either see or generate a dependency list of the package chain from the bottom up? That'll provide a nice map to follow. Sure, these are on the qa pages, e.g. http://buildfarm.opencsw.org/cgi-bin/depgraph?pkg=imagemagick (the generation of the graph takes a little time, be patient) You can click on some boxes and package names, feel free to play around with it. > Separately, and I'll probably see this shortly, but is there a Solaris 11 x86 or SPARC system in the buildfarm? Sure, unstable11s and unstable11x. > If not, I have an x86 variant available. Having a SPARC M-x000 or T4 or higher will be required if we want to have dual binary builds for each package, which IPS supports now. If not, it's easily added later. Nobody has donated one yet ;-) 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 bonivart at opencsw.org Sat May 17 19:48:45 2014 From: bonivart at opencsw.org (Peter Bonivart) Date: Sat, 17 May 2014 19:48:45 +0200 Subject: ClamAV binary needs .so from dev-package? Message-ID: The 0.93 release of Clam AntiVirus was a pretty bad release causing troubles for many both building and running so they quickly got a release candidate out for the next release supposed to fix all known problems. It now builds, passes the tests and I can run it and it doesn't show any of the problems plaguing 0.93 but I stumbled on this instead, freshclam is the binary used to update the signature database and for some reason it wants the .so-file I have put in the dev package. # freshclam -V LibClamAV Warning: Cannot dlopen libclamunrar_iface: file not found - unrar support unavailable ClamAV 0.98.4-rc1/18999/Sat May 17 13:26:18 2014 If I install the dev package everything is fine. The below looks ok to me so why doesn't the library use the .so.6-file you think? # ls -ld /opt/csw/lib/*unrar_iface* lrwxrwxrwx 1 root root 28 May 17 19:22 /opt/csw/lib/libclamunrar_iface.so -> libclamunrar_iface.so.6.1.23 lrwxrwxrwx 1 root root 28 May 16 18:56 /opt/csw/lib/libclamunrar_iface.so.6 -> libclamunrar_iface.so.6.1.23 -rwxr-xr-x 1 root bin 11908 May 16 15:58 /opt/csw/lib/libclamunrar_iface.so.6.1.23 /peter From raos at opencsw.org Sat May 17 22:11:18 2014 From: raos at opencsw.org (Rafael Ostertag) Date: Sat, 17 May 2014 22:11:18 +0200 Subject: ClamAV binary needs .so from dev-package? In-Reply-To: References: Message-ID: <20140517201118.GD19917@bender.opencsw.org> Hi Peter On Sat, May 17, 2014 at 07:48:45PM +0200, Peter Bonivart wrote: > # freshclam -V > LibClamAV Warning: Cannot dlopen libclamunrar_iface: file not found - > unrar support unavailable > ClamAV 0.98.4-rc1/18999/Sat May 17 13:26:18 2014 Judging from the message, freshclam (or libclamav) tries to dlopen(3C) the library, i.e. the library is loaded dynamically at runtime by a call to dlopen(3C) instead of being loaded during initialization phase of the executable. dlopen() requires a pathname, so the usual 'SONAME is recorded in the binary, and then used to locate the library later' does not apply here. AFAIK, all applications which dlopen() libraries at runtime do so by searching for .so files. As an example, apache's modules are loaded dynamically and also only feature .so names (see /opt/csw/apache2/libexec). Using versioned file names wouldn't do any good, and one had to constantly update the file name in the code to keep in sync. > > If I install the dev package everything is fine. The below looks ok to > me so why doesn't the library use the .so.6-file you think? > > # ls -ld /opt/csw/lib/*unrar_iface* > lrwxrwxrwx 1 root root 28 May 17 19:22 > /opt/csw/lib/libclamunrar_iface.so -> libclamunrar_iface.so.6.1.23 > lrwxrwxrwx 1 root root 28 May 16 18:56 > /opt/csw/lib/libclamunrar_iface.so.6 -> libclamunrar_iface.so.6.1.23 > -rwxr-xr-x 1 root bin 11908 May 16 15:58 > /opt/csw/lib/libclamunrar_iface.so.6.1.23 See above. I'd bet the clamav guys use libtool and 6.1.23 is also the version of libclam, and they were just lazzy to create a separate recipe for generating dynamically loaded modules. However, if remotely possible, I would put the dynamically loaded libraries into /opt/csw/lib/clamav or similar. HTH cheers rafi > > /peter > From bonivart at opencsw.org Sat May 17 23:05:02 2014 From: bonivart at opencsw.org (Peter Bonivart) Date: Sat, 17 May 2014 23:05:02 +0200 Subject: ClamAV binary needs .so from dev-package? In-Reply-To: <20140517201118.GD19917@bender.opencsw.org> References: <20140517201118.GD19917@bender.opencsw.org> Message-ID: On Sat, May 17, 2014 at 10:11 PM, Rafael Ostertag wrote: > dlopen() requires a pathname, so the usual 'SONAME is recorded in the binary, > and then used to locate the library later' does not apply here. AFAIK, all > applications which dlopen() libraries at runtime do so by searching for .so > files. As an example, apache's modules are loaded dynamically and also only > feature .so names (see /opt/csw/apache2/libexec). Using versioned file names > wouldn't do any good, and one had to constantly update the file name in the > code to keep in sync. Good explanation, weird though that this happens now, I have built ClamAV for years and this is something new. > However, if remotely possible, I would put the > dynamically loaded libraries into /opt/csw/lib/clamav or similar. I think it would be easiest for me to just add a dep to the dev package for now and see if this is something they will continue with or not. If they do, I can go the apache2 way and include the .so links into the lib package. Thanks for the help. From raos at opencsw.org Sun May 18 00:47:00 2014 From: raos at opencsw.org (Rafael Ostertag) Date: Sun, 18 May 2014 00:47:00 +0200 Subject: ClamAV binary needs .so from dev-package? In-Reply-To: References: <20140517201118.GD19917@bender.opencsw.org> Message-ID: <20140517224700.GE19917@bender.opencsw.org> Hi Peter On Sat, May 17, 2014 at 11:05:02PM +0200, Peter Bonivart wrote: > On Sat, May 17, 2014 at 10:11 PM, Rafael Ostertag wrote: > > dlopen() requires a pathname, so the usual 'SONAME is recorded in the binary, > > and then used to locate the library later' does not apply here. AFAIK, all > > applications which dlopen() libraries at runtime do so by searching for .so > > files. As an example, apache's modules are loaded dynamically and also only > > feature .so names (see /opt/csw/apache2/libexec). Using versioned file names > > wouldn't do any good, and one had to constantly update the file name in the > > code to keep in sync. > > Good explanation, weird though that this happens now, I have built > ClamAV for years and this is something new. True. Ok, I believe I spotted the place where they compose the filename to dlopen. It's in libclamav/others.c:lt_dlfind(): static const char *suffixes[] = { LT_MODULE_EXT"."LIBCLAMAV_FULLVER, PASTE(LT_MODULE_EXT".", LIBCLAMAV_MAJORVER), LT_MODULE_EXT, "."LT_LIBEXT }; What says your clamav-config.h about LT_MODULE_EXT, LIBCLAMAV_FULLVER, etc.? I tried it on Fedora 20. After removing the .so links, freshclam complained about LibClamAV Warning: Cannot dlopen libclamunrar_iface: file not found - unrar support unavailable So, it might be a bug in the build system, since my clamav-config.h does #define LIBCLAMAV_FULLVER ".1.22" #define LIBCLAMAV_MAJORVER #define LT_MODULE_EXT ".so" #define LT_LIBEXT "a" which wouldn't form any suffix except for .so that leads to a resolvable filepath. > > > However, if remotely possible, I would put the > > dynamically loaded libraries into /opt/csw/lib/clamav or similar. > > I think it would be easiest for me to just add a dep to the dev > package for now and see if this is something they will continue with > or not. If they do, I can go the apache2 way and include the .so links > into the lib package. > > Thanks for the help. You're welcome. cheers rafi > From maciej at opencsw.org Sun May 18 14:42:10 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 18 May 2014 13:42:10 +0100 Subject: Something wrong with the package release chain? In-Reply-To: References: <3895F96C-4B6F-47B8-AAA0-C10079ADFBEA@opencsw.org> <6C9787C7-7166-4B6A-9CE6-B3F4FB4D081F@opencsw.org> Message-ID: On Tue, May 13, 2014 at 9:59 PM, Dagobert Michelsen wrote: > The missing package issue has been resolved and catalog generation is running again. Thanks, Dago! When anybody notices that updates are not running, here's an URL to check: http://buildfarm.opencsw.org/catalog-generation.log It's a log file, but it's not very long, and you'll usually quickly spot if there is a problem like the one discussed in this topic. If anybody sees failures when running csw-upload-pkg, please do send me an email with the error message. In the meantime, I am continuing to look for the bug we're seeing. I added yet more logging, and I disabled caching in the ORM in one place. I'll continue to watch the situation. If any packages get removed from the catalog while they shouldn't, please let me know. Maciej From maciej at opencsw.org Mon May 19 01:19:21 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 19 May 2014 00:19:21 +0100 Subject: Something wrong with the package release chain? In-Reply-To: References: <3895F96C-4B6F-47B8-AAA0-C10079ADFBEA@opencsw.org> <6C9787C7-7166-4B6A-9CE6-B3F4FB4D081F@opencsw.org> Message-ID: On Sun, May 18, 2014 at 1:42 PM, Maciej (Matchek) Blizi?ski wrote: > In the meantime, I am continuing to look for the bug we're seeing. I > added yet more logging, and I disabled caching in the ORM in one > place. I'll continue to watch the situation. If any packages get > removed from the catalog while they shouldn't, please let me know. With help from Laurent, Peter and Slow, I'm beginning to gain confidence in the idea that putting released packages in the experimental directory causes them to be removed from the catalog. My working hypothesis is that running checkpkg against a package resets the package's state in the database, which causes the package to be removed from all catalogs. Maciej From maciej at opencsw.org Mon May 19 10:21:20 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 19 May 2014 09:21:20 +0100 Subject: Something wrong with the package release chain? In-Reply-To: References: <3895F96C-4B6F-47B8-AAA0-C10079ADFBEA@opencsw.org> <6C9787C7-7166-4B6A-9CE6-B3F4FB4D081F@opencsw.org> Message-ID: I have put a provisional fix in place. Please do some more testing: uploads and * copies into experimental. The problem should not occur any more. Lots of thanks to Laurent, Peter and Slow for reporting the symptoms, I wouldn't have fixed it without their help! Maciej Em 19/05/2014 00:19, "Maciej (Matchek) Blizi?ski" escreveu: > On Sun, May 18, 2014 at 1:42 PM, Maciej (Matchek) Blizi?ski > wrote: > > In the meantime, I am continuing to look for the bug we're seeing. I > > added yet more logging, and I disabled caching in the ORM in one > > place. I'll continue to watch the situation. If any packages get > > removed from the catalog while they shouldn't, please let me know. > > With help from Laurent, Peter and Slow, I'm beginning to gain > confidence in the idea that putting released packages in the > experimental directory causes them to be removed from the catalog. My > working hypothesis is that running checkpkg against a package resets > the package's state in the database, which causes the package to be > removed from all catalogs. > > Maciej > -------------- next part -------------- An HTML attachment was scrubbed... URL: From slowfranklin at opencsw.org Mon May 19 10:49:52 2014 From: slowfranklin at opencsw.org (slowfranklin) Date: Mon, 19 May 2014 10:49:52 +0200 Subject: Something wrong with the package release chain? In-Reply-To: References: <3895F96C-4B6F-47B8-AAA0-C10079ADFBEA@opencsw.org> <6C9787C7-7166-4B6A-9CE6-B3F4FB4D081F@opencsw.org> Message-ID: <3C47271F-8663-4D75-AE23-D19271AEDA2B@opencsw.org> Whether it's fixed or not: thanks! :) -slow Am 19.05.2014 um 10:21 schrieb Maciej (Matchek) Blizi?ski : > I have put a provisional fix in place. Please do some more testing: uploads and * copies into experimental. The problem should not occur any more. > > Lots of thanks to Laurent, Peter and Slow for reporting the symptoms, I wouldn't have fixed it without their help! > > Maciej > > Em 19/05/2014 00:19, "Maciej (Matchek) Blizi?ski" escreveu: > On Sun, May 18, 2014 at 1:42 PM, Maciej (Matchek) Blizi?ski > wrote: > > In the meantime, I am continuing to look for the bug we're seeing. I > > added yet more logging, and I disabled caching in the ORM in one > > place. I'll continue to watch the situation. If any packages get > > removed from the catalog while they shouldn't, please let me know. > > With help from Laurent, Peter and Slow, I'm beginning to gain > confidence in the idea that putting released packages in the > experimental directory causes them to be removed from the catalog. My > working hypothesis is that running checkpkg against a package resets > the package's state in the database, which causes the package to be > removed from all catalogs. > > Maciej From jh at opencsw.org Mon May 19 17:33:57 2014 From: jh at opencsw.org (Jan Holzhueter) Date: Mon, 19 May 2014 17:33:57 +0200 Subject: GNUTLS needs libc 1.22.5 now !? Message-ID: <537A2465.3020902@opencsw.org> Hi, do you have a clue how that sneaked in? Or is this intentional? Could not find anything that would disable the map file. Greetings Jan From rmottola at opencsw.org Tue May 20 01:21:10 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Tue, 20 May 2014 01:21:10 +0200 Subject: gnsutep and DESTDIR Message-ID: <1400541669.5397.3.camel@anor> Hi, I got gnustep-base workign (commited the mgar makefile) I had to define however the following target: install-sourcegs: . $(BUILD_PREFIX)/GNUstep/System/Library/Makefiles/GNUstep.sh && cd $(WORKSRC) && /usr/bin/env -i $(INSTALL_ENV) && $(MAKE) install DESTDIR=$(DESTDIR) @$(MAKECOOKIE) that is, explicitely set DESDTIR after INSTALL. Otheriwse it wouldn't work. I tried explicitely exporting $DESTDIR before install, but it did not help. Do you think this is correct or is there a better way? Riccardo From maciej at opencsw.org Tue May 20 07:21:55 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 20 May 2014 06:21:55 +0100 Subject: gnsutep and DESTDIR In-Reply-To: <1400541669.5397.3.camel@anor> References: <1400541669.5397.3.camel@anor> Message-ID: On Tue, May 20, 2014 at 12:21 AM, Riccardo Mottola wrote: > I got gnustep-base workign (commited the mgar makefile) I had to define > however the following target: > > install-sourcegs: > . $(BUILD_PREFIX)/GNUstep/System/Library/Makefiles/GNUstep.sh && cd > $(WORKSRC) && /usr/bin/env -i $(INSTALL_ENV) && $(MAKE) install > DESTDIR=$(DESTDIR) > @$(MAKECOOKIE) > > that is, explicitely set DESDTIR after INSTALL. Otheriwse it wouldn't > work. I tried explicitely exporting $DESTDIR before install, but it did > not help. > > Do you think this is correct or is there a better way? It probably has to with how /usr/bin/env and gmake are called. See this example: > /usr/bin/env -i FOO=bar /opt/csw/bin/gmake -f <( echo -e 'a:\n\t at if [ -n "$(FOO)" ]; then echo "FOO has a value"; else echo "FOO has no value"; fi' ) FOO has a value > /usr/bin/env -i FOO=bar && /opt/csw/bin/gmake -f <( echo -e 'a:\n\t at if [ -n "$(FOO)" ]; then echo "FOO has a value"; else echo "FOO has no value"; fi' ) FOO=bar FOO has no value If line breaks in email get in the way: http://pastie.org/9191629 Maciej From rmottola at opencsw.org Tue May 20 08:00:03 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Tue, 20 May 2014 08:00:03 +0200 Subject: alternatives: multiple versions for the same package Message-ID: <1400565603.12948.6.camel@anor> Hi, Progressing, I have now to preparecthe "backend" for the GNUstep packages. The backend provides the graphical part and can be configured with different libraries,s upporting different dependencies. The best rendering is currently supported with the "cairo" library, but one can also use the older "xlib" backend which has thus much less dependencies and is useful e.g. on a server where just a couple of small programs are run without much graphics. Does mgar support his? How? Essentially, I would build "gnustep-back-xlib" and "gnustep-back-cairo" and they should be installed mutually exclusive. All other applications need to depend on either one or the other, the choice is free, but one is needed. On systems like debian, one builds two packages and puts them mutually on dependency. On other systems like gentoo linux, I would build only one package "gnustep-back" and then be able to pass an option, a flavour or something like that to the time being. Riccardo From rmottola at opencsw.org Tue May 20 11:05:35 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Tue, 20 May 2014 11:05:35 +0200 Subject: gnustep and DESTDIR In-Reply-To: References: <1400541669.5397.3.camel@anor> Message-ID: <1400576735.21301.25.camel@anor> Hi, Maciej (Matchek) Blizi?ski wrote: > > probably has to with how /usr/bin/env and gmake are called. See this example: > > > > > /usr/bin/env -i FOO=bar /opt/csw/bin/gmake -f <( echo -e 'a:\n\t at if [ -n "$(FOO)" ]; then echo "FOO has a value"; else echo "FOO has no value"; fi' ) > FOO has a value > > > /usr/bin/env -i FOO=bar && /opt/csw/bin/gmake -f <( echo -e 'a:\n\t at if [ -n "$(FOO)" ]; then echo "FOO has a value"; else echo "FOO has no value"; fi' ) > FOO=bar > FOO has no value > > If line breaks in email get in the way: http://pastie.org/9191629 Yes line breaks made it difficult, thanks for the pastie. Essentially, you are saying I have a " &&" too much? the line should be then: . $(BUILD_PREFIX)/GNUstep/System/Library/Makefiles/GNUstep.sh && cd $(WO RKSRC) && /usr/bin/env -i $(BUILD_ENV) $(MAKE) . $(BUILD_PREFIX)/GNUstep/System/Library/Makefiles/GNUstep.sh && cd $(WO RKSRC) && /usr/bin/env -i $(INSTALL_ENV) $(MAKE) install I removed "&&" before $(MAKE): however in that case make fails because it apparently "looses" the environment sourced in GNUstep.sh [configure-modulated] complete for gnustep-base. . /opt/csw/GNUstep/System/Library/Makefiles/GNUstep.sh && cd work/build-isa-sparcv8plus/gnustep-base-1.24.6 && /usr/bin/env -i HOME="/home/multix" PATH="/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/bin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/bin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/sbin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/sbin:/opt/csw/bin:/opt/csw/bin:/opt/csw/sbin:/opt/csw/sbin:/opt/csw/bin:/home/multix/code/opencsw/.buildsys/v2/gar/bin:/usr/bin:/usr/sbin:/usr/java/bin:/usr/ccs/bin:/usr/openwin/bin" LC_ALL="C" prefix="/opt/csw" exec_prefix="/opt/csw" bindir="/opt/csw/bin" sbindir="/opt/csw/sbin" libexecdir="/opt/csw/libexec" datadir="/opt/csw/share" sysconfdir="/etc/opt/csw" sharedstatedir="/opt/csw/share" localstatedir="/var/opt/csw" libdir="/opt/csw/lib" infodir="/opt/csw/share/info" lispdir="/opt/csw/share/emacs/site-lisp" includedir="/opt/csw/include" mandir="/opt/csw/share/man" docdir="/opt/csw/share/doc" sourcedir="/opt/csw/src" CPPFLAGS="-I/opt/csw/include" CFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" CXXFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" LDFLAGS="-mcpu=v9 -Wa,-xarch=v8plus -L/opt/csw/lib" FFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" FCFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" F77="/opt/csw/bin/gfortran-4.9" FC="/opt/csw/bin/gfortran-4.9" ASFLAGS="" OPTFLAGS="-O2 -pipe -mcpu=v9 -Wa,-xarch=v8plus" CC="/opt/csw/bin/gcc-4.9" CXX="/opt/csw/bin/g++-4.9" CC_HOME="/opt/csw" CC_VERSION="gcc version 4.9.0 (GCC) " CXX_VERSION="gcc version 4.9.0 (GCC) " GARCH="sparc" GAROSREL="5.10" GARPACKAGE="trunk" LD_OPTIONS="-R/opt/csw/lib/\$ISALIST -R/opt/csw/lib -B direct -z ignore" gmake /bin/sh: gnustep-config: not found GNUmakefile:29: GNUmakefile:30: Unable to obtain GNUSTEP_MAKEFILES setting from gnustep-config! GNUmakefile:31: Perhaps gnustep-make is not properly installed, GNUmakefile:32: so gnustep-config is not in your PATH. GNUmakefile:33: GNUmakefile:34: Your PATH is currently /home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/bin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/bin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/sbin:/home/multix/code/opencsw/gnustep-base/trunk/work/install-isa-sparcv8plus/opt/csw/sbin:/opt/csw/bin:/opt/csw/bin:/opt/csw/sbin:/opt/csw/sbin:/opt/csw/bin:/home/multix/code/opencsw/.buildsys/v2/gar/bin:/usr/bin:/usr/sbin:/usr/java/bin:/usr/ccs/bin:/usr/openwin/bin this is becoming a makefile & shell battle! Substituting "&&" with ";" does no help, as your small example proves. I don't understand, the previous steps in the line are the same, why with "&&" the sourced environment from GNUstep.sh gets preserved and in the other case not :( Looking for examples in othe rpackages shows a plethora of solutions: 1) antiword/trunk/Makefile: (cd $(WORKSRC) && /usr/bin/env -i $(INSTALL_ENV) gmake -f Makefile.Solaris DESTDIR=$(DESTDIR) $(PARALLELMFLAGS) install) This is how you suggest, but it gives me troubles with my GNUstep.sh sourcing 2) autogen/trunk/Makefile: cd $(WORKSRC) && /usr/bin/env -i $(INSTALL_ENV) && $(MAKE) -C $(OBJDIR) $(INSTALL_ARGS) DESTDIR=$(DESTDIR) install This does it my current way, that is, by separating make with && and then DESTDIR=$(DESTDIR) the latter seems to be quite used, so perhaps it is fine to be left so. Riccardo From dam at opencsw.org Tue May 20 11:09:47 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 20 May 2014 11:09:47 +0200 Subject: gnustep and DESTDIR In-Reply-To: <1400576735.21301.25.camel@anor> References: <1400541669.5397.3.camel@anor> <1400576735.21301.25.camel@anor> Message-ID: <9411E923-545A-437D-A779-6C20E3C7FB80@opencsw.org> Hi Riccardo, Am 20.05.2014 um 11:05 schrieb Riccardo Mottola : > This does it my current way, that is, by separating make with && and > then DESTDIR=$(DESTDIR) There is a difference between DESTDIR=/foo gmake bar and gmake bar DESTDIR=/foo The latter one aggresively overrides settings inside the Makefile. See for details https://www.gnu.org/software/make/manual/html_node/Values.html#Values 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 May 20 11:11:16 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 20 May 2014 10:11:16 +0100 Subject: gnustep and DESTDIR In-Reply-To: <1400576735.21301.25.camel@anor> References: <1400541669.5397.3.camel@anor> <1400576735.21301.25.camel@anor> Message-ID: On Tue, May 20, 2014 at 10:05 AM, Riccardo Mottola wrote: > I removed "&&" before $(MAKE): however in that case make fails because > it apparently "looses" the environment sourced in GNUstep.sh Yes, because the "-i" flag tells /usr/bin/env to clean the environment. From dam at opencsw.org Tue May 20 11:16:14 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 20 May 2014 11:16:14 +0200 Subject: alternatives: multiple versions for the same package In-Reply-To: <1400565603.12948.6.camel@anor> References: <1400565603.12948.6.camel@anor> Message-ID: <02B1A9B3-0F24-448C-98B9-C81A67AB5350@opencsw.org> Hi Riccardo, Am 20.05.2014 um 08:00 schrieb Riccardo Mottola : > Progressing, I have now to preparecthe "backend" for the GNUstep > packages. > > The backend provides the graphical part and can be configured with > different libraries,s upporting different dependencies. > > The best rendering is currently supported with the "cairo" library, but > one can also use the older "xlib" backend which has thus much less > dependencies and is useful e.g. on a server where just a couple of small > programs are run without much graphics. > > Does mgar support his? How? > Essentially, I would build "gnustep-back-xlib" and "gnustep-back-cairo" > and they should be installed mutually exclusive. > All other applications need to depend on either one or the other, the > choice is free, but one is needed. > > On systems like debian, one builds two packages and puts them mutually > on dependency. > > On other systems like gentoo linux, I would build only one package > "gnustep-back" and then be able to pass an option, a flavour or > something like that to the time being. We have alternatives for that. You can look at gnuplot which has one basic alternative and one with wxWidgets: https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/pkg/gnuplot/trunk/Makefile 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 rmottola at opencsw.org Tue May 20 16:12:36 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Tue, 20 May 2014 16:12:36 +0200 Subject: alternatives: multiple versions for the same package In-Reply-To: <02B1A9B3-0F24-448C-98B9-C81A67AB5350@opencsw.org> References: <1400565603.12948.6.camel@anor> <02B1A9B3-0F24-448C-98B9-C81A67AB5350@opencsw.org> Message-ID: <1400595156.24448.16.camel@anor> Hi, On Tue, 2014-05-20 at 11:16, Dagobert Michelsen wrote: > We have alternatives for that. You can look at gnuplot which has one basic > alternative and one with wxWidgets: > https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/pkg/gnuplot/trunk/Makefile > that is, Modulations., the "m" part in GAR. I read your slides :) Very fine! I'm biting my teeth. I want to provide two options for the time being: EXTRA_MODULATORS = GRAPHICS MODULATIONS_graphics = xlib cairo I now have a package, but it does not configure. it does nothing: bash-4.3$ mgar configure gmake: 'work/cookies/global/configure' is up to date. if I did things well, I should be able to do: mgar configure MODULATION=GRAPHICS-xlib and mgar configure MODULATION=GRAPHICS-cairo right? May I commit my not-yet-working package makefile so yo ucan see it in its entirety? Riccardo From dam at opencsw.org Tue May 20 18:26:54 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 20 May 2014 18:26:54 +0200 Subject: alternatives: multiple versions for the same package In-Reply-To: <1400595156.24448.16.camel@anor> References: <1400565603.12948.6.camel@anor> <02B1A9B3-0F24-448C-98B9-C81A67AB5350@opencsw.org> <1400595156.24448.16.camel@anor> Message-ID: <27622694-3522-4723-8E23-90C27D1760CA@opencsw.org> > Am 20.05.2014 um 16:12 schrieb Riccardo Mottola : > > Hi, > > On Tue, 2014-05-20 at 11:16, Dagobert Michelsen wrote: > > >> We have alternatives for that. You can look at gnuplot which has one basic >> alternative and one with wxWidgets: >> https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/pkg/gnuplot/trunk/Makefile > > that is, Modulations., the "m" part in GAR. I read your slides :) > > Very fine! I'm biting my teeth. > > I want to provide two options for the time being: > EXTRA_MODULATORS = GRAPHICS > MODULATIONS_graphics = xlib cairo > > I now have a package, but it does not configure. > > it does nothing: > > bash-4.3$ mgar configure > gmake: 'work/cookies/global/configure' is up to date. > > if I did things well, I should be able to do: > mgar configure MODULATION=GRAPHICS-xlib > > and > > mgar configure MODULATION=GRAPHICS-cairo > > right? > > May I commit my not-yet-working package makefile so yo ucan see it in > its entirety? Yes please :-) > > Riccardo > From maciej at opencsw.org Tue May 20 18:44:40 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 20 May 2014 17:44:40 +0100 Subject: alternatives: multiple versions for the same package In-Reply-To: <27622694-3522-4723-8E23-90C27D1760CA@opencsw.org> References: <1400565603.12948.6.camel@anor> <02B1A9B3-0F24-448C-98B9-C81A67AB5350@opencsw.org> <1400595156.24448.16.camel@anor> <27622694-3522-4723-8E23-90C27D1760CA@opencsw.org> Message-ID: On Tue, May 20, 2014 at 5:26 PM, Dagobert Michelsen wrote: >> May I commit my not-yet-working package makefile so yo ucan see it in >> its entirety? > > Yes please :-) If it gets hard, maybe it makes sense to build just one version for starters. You can give packages names with the future dual build in mind, but only do one build for now. I think it's good to release a simpler set of packages earlier. Maciej From maciej at opencsw.org Wed May 21 18:02:20 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 21 May 2014 17:02:20 +0100 Subject: mgar check-upstream now works on unstable* hosts Message-ID: I've modified the uwatch and gar.lib.mk code to support proxies, so now you can run "mgar check-upstream" on unstable* hosts, and it will work, at least with HTTP targets. The patch was: http://sourceforge.net/p/gar/code/23641/ Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmottola at opencsw.org Wed May 21 20:34:32 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Wed, 21 May 2014 20:34:32 +0200 Subject: alternatives: multiple versions for the same package In-Reply-To: References: <1400565603.12948.6.camel@anor> <02B1A9B3-0F24-448C-98B9-C81A67AB5350@opencsw.org> <1400595156.24448.16.camel@anor> <27622694-3522-4723-8E23-90C27D1760CA@opencsw.org> Message-ID: <1400697272.3639.4.camel@anor> Hi, On Tue, 2014-05-20 at 18:44, Maciej (Matchek) Blizi?ski wrote: > On Tue, May 20, 2014 at 5:26 PM, Dagobert Michelsen wrote: > >> May I commit my not-yet-working package makefile so yo ucan see it in > >> its entirety? > > > > Yes please :-) > > If it gets hard, maybe it makes sense to build just one version for > starters. You can give packages names with the future dual build in > mind, but only do one build for now. I think it's good to release a > simpler set of packages earlier. Fine, the two packages would be quite similar. Before committing something with the wrong name. Let me understand better and explain. 1) I currently have package "x" (that is gnustep-back) and thus it is named in my opencsw directory 2) one of the modulations needs to be choosen. it is not a feature tha tyou can activate, but a choice that you need to make 3) as package name do you refer to the actual name in the directory? that is, I have gnustep-back, that can be built either "xlib" or "cairo". There is no "gnustep-back" without this choice. All remaining packages will depend on either one or the other, you can't have both. Is it now correct to commit gnustep-back? perhaps with a first hard-configured version to which we make modulations then work? Riccardo From maciej at opencsw.org Thu May 22 10:10:08 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 22 May 2014 09:10:08 +0100 Subject: Our code on github Message-ID: We had github repositories with GAR and packages. They were not used by anyone, so I've deleted them. I would love to use git for GAR development, but we're still keeping the code in Subversion, and I don't want to keep a dead repository around. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Fri May 23 09:28:02 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 23 May 2014 09:28:02 +0200 Subject: alternatives: multiple versions for the same package In-Reply-To: <1400697272.3639.4.camel@anor> References: <1400565603.12948.6.camel@anor> <02B1A9B3-0F24-448C-98B9-C81A67AB5350@opencsw.org> <1400595156.24448.16.camel@anor> <27622694-3522-4723-8E23-90C27D1760CA@opencsw.org> <1400697272.3639.4.camel@anor> Message-ID: Hi Riccardo, Am 21.05.2014 um 20:34 schrieb Riccardo Mottola : > On Tue, 2014-05-20 at 18:44, Maciej (Matchek) Blizi?ski wrote: >> If it gets hard, maybe it makes sense to build just one version for >> starters. You can give packages names with the future dual build in >> mind, but only do one build for now. I think it's good to release a >> simpler set of packages earlier. > > Fine, the two packages would be quite similar. Before committing > something with the wrong name. > > Let me understand better and explain. > 1) I currently have package "x" (that is gnustep-back) and thus it is > named in my opencsw directory > 2) one of the modulations needs to be choosen. it is not a feature tha > tyou can activate, but a choice that you need to make > 3) as package name do you refer to the actual name in the directory? > > that is, I have gnustep-back, that can be built either "xlib" or > "cairo". There is no "gnustep-back" without this choice. > > All remaining packages will depend on either one or the other, you can't > have both. > > Is it now correct to commit gnustep-back? perhaps with a first > hard-configured version to which we make modulations then work? I suggest to make one CSWgnustep-back which uses xlib and registers xlib as alternative. All packages depend on this one. If you want the more elaborate cairo you install CSWgnustep-back-cairo which just ships the changed files from the alternatives and these alternatives have a higher precedence than the xlib one. This is the same way as we do gnuplot. Does this sound reasonable? 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 Sat May 24 11:46:21 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 24 May 2014 11:46:21 +0200 Subject: Fwd: [gnutls-devel] Symbol versioning in gnutls broken -> crashes References: <20140524065807.GA2250@downhill.g.la> Message-ID: <8FC06800-5E69-42F7-9DD4-836B00CDDD99@opencsw.org> Hi folks, Looks like other distros suffer the same pain /-) Best regards -- Dago Anfang der weitergeleiteten E?Mail: > Von: Andreas Metzler > Datum: 24. Mai 2014 08:58:07 MESZ > An: gnutls-devel at lists.gnutls.org > Betreff: [gnutls-devel] Symbol versioning in gnutls broken -> crashes > > Hello, > > GnuTLS symbol versioning apparently does not fullfill its main > purpose, to allow a binary to link against gnutls 2.x and gnutls 3.x > without crashing. > > This is a pretty common screnario for distributions in a transition > period, where you go from: > > scenario1 > application --depends_on--> libgnutls.so.26 > `-depends_on--> libbar.so.5 --dep_on--> libgnutls.so.26 > > to > > scenario2 > application --depends_on--> libgnutls.so.26 > `-depends_on--> libbar.so.5 --dep_on--> libgnutls.so.28 > > at some point of time, since you cannot switch the whole distro at one > point. Especially for the GnuTLS transition, since this is not just a > straight rebuild but involves checking the source's gcrypt related > code. > > Usually symbol-versioning would cause any references to gnutls to be > resolved to GnuTLS 2.x in both of the abovementioned cases, libbar's > to GnuTLS 2.x or 3.x respectively. However e.g. gnutls_init() is > versioned as @1.4 in both gnutls versions, therefore in scenario2 > application could also get gnutls_init() from GnuTLS 3.x. > > Another function where it is obvious this breaks is > gnutls_priority_set_direct(), where 3.x accepts more priority strings. > > ------ > > Anyway, this causes hard crashes like in > or > . > > Fixing this in gnutls' source is pretty easy: In gnutls.map move the > contents of GNUTLS_1_4, GNUTLS_2_8, GNUTLS_2_10 and GNUTLS_2_12 to > GNUTLS_3_0_0. However it breaks the ABI, everything linking against > gnutls3 will need to be rebuilt after the change. Afaiu a soname bump > would therefore be the correct thing. > > cu Andreas > > See also: > > > -- > `What a good friend you are to him, Dr. Maturin. His other friends are > so grateful to you.' > `I sew his ears on from time to time, sure' > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sat May 24 19:39:19 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 24 May 2014 19:39:19 +0200 Subject: py_elftools upgraded Message-ID: I've upgraded py_elftools on the buildfarm. If there are trouble with package checking, please let me know. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Sat May 24 23:13:15 2014 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sat, 24 May 2014 23:13:15 +0200 Subject: GNUTLS needs libc 1.22.5 now !? In-Reply-To: <537A2465.3020902@opencsw.org> References: <537A2465.3020902@opencsw.org> Message-ID: Hi Jan, It was a mistake on my side. It's strange that gnutls picked this dependency although it doesn't use any symbol of version interface 1.22.5. Anyway, I just uploaded new gnutls packages that doesn't depend anymore on libc version interface 1.22.5. BTW, shouldn't we now upgrade the minimal libc version interface in OpenCSW ? 1.22.5 was brought in Solaris 10 update 8 which is nearly 5 years old now and mysql already depends on it. Yann 2014-05-19 17:33 GMT+02:00 Jan Holzhueter : > Hi, > do you have a clue how that sneaked in? > Or is this intentional? > > Could not find anything that would disable the map file. > > Greetings > Jan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Sat May 24 23:15:38 2014 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sat, 24 May 2014 23:15:38 +0200 Subject: [gnutls-devel] Symbol versioning in gnutls broken -> crashes In-Reply-To: <8FC06800-5E69-42F7-9DD4-836B00CDDD99@opencsw.org> References: <20140524065807.GA2250@downhill.g.la> <8FC06800-5E69-42F7-9DD4-836B00CDDD99@opencsw.org> Message-ID: Hi, Thanks for the information. I think that direct binding should save us for this kind of nightmare, even if symbol versioning was done wrong as it is the case here. Yann 2014-05-24 11:46 GMT+02:00 Dagobert Michelsen : > Hi folks, > > Looks like other distros suffer the same pain /-) > > Best regards -- Dago > > > Anfang der weitergeleiteten E?Mail: > > *Von:* Andreas Metzler > *Datum:* 24. Mai 2014 08:58:07 MESZ > *An:* gnutls-devel at lists.gnutls.org > *Betreff:* *[gnutls-devel] Symbol versioning in gnutls broken -> crashes* > > Hello, > > GnuTLS symbol versioning apparently does not fullfill its main > purpose, to allow a binary to link against gnutls 2.x and gnutls 3.x > without crashing. > > This is a pretty common screnario for distributions in a transition > period, where you go from: > > scenario1 > application --depends_on--> libgnutls.so.26 > `-depends_on--> libbar.so.5 --dep_on--> libgnutls.so.26 > > to > > scenario2 > application --depends_on--> libgnutls.so.26 > `-depends_on--> libbar.so.5 --dep_on--> libgnutls.so.28 > > at some point of time, since you cannot switch the whole distro at one > point. Especially for the GnuTLS transition, since this is not just a > straight rebuild but involves checking the source's gcrypt related > code. > > Usually symbol-versioning would cause any references to gnutls to be > resolved to GnuTLS 2.x in both of the abovementioned cases, libbar's > to GnuTLS 2.x or 3.x respectively. However e.g. gnutls_init() is > versioned as @1.4 in both gnutls versions, therefore in scenario2 > application could also get gnutls_init() from GnuTLS 3.x. > > Another function where it is obvious this breaks is > gnutls_priority_set_direct(), where 3.x accepts more priority strings. > > ------ > > Anyway, this causes hard crashes like in > or > . > > Fixing this in gnutls' source is pretty easy: In gnutls.map move the > contents of GNUTLS_1_4, GNUTLS_2_8, GNUTLS_2_10 and GNUTLS_2_12 to > GNUTLS_3_0_0. However it breaks the ABI, everything linking against > gnutls3 will need to be rebuilt after the change. Afaiu a soname bump > would therefore be the correct thing. > > cu Andreas > > See also: > > > -- > `What a good friend you are to him, Dr. Maturin. His other friends are > so grateful to you.' > `I sew his ears on from time to time, sure' > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jh at opencsw.org Mon May 26 07:17:33 2014 From: jh at opencsw.org (=?UTF-8?B?SmFuIEhvbHpow7x0ZXI=?=) Date: Mon, 26 May 2014 07:17:33 +0200 Subject: GNUTLS needs libc 1.22.5 now !? In-Reply-To: References: <537A2465.3020902@opencsw.org> Message-ID: <5382CE6D.70702@opencsw.org> Hi, > > BTW, shouldn't we now upgrade the minimal libc version interface in > OpenCSW ? > 1.22.5 was brought in Solaris 10 update 8 which is nearly 5 years old > now and mysql already depends on it. We probably should. Greetings Jan From maciej at opencsw.org Mon May 26 11:12:14 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 26 May 2014 11:12:14 +0200 Subject: Rules for automatic package promotions Message-ID: Did anybody write down what should be the rules for automatic package promotion? As in automatic migration from unstable to bratislava. I know that Dago had some thoughts about it, e.g. that it should be done by bundle and include all dependencies. Does anybody have a thought-through, written down set of these rules? Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From slowfranklin at opencsw.org Mon May 26 11:21:54 2014 From: slowfranklin at opencsw.org (slowfranklin) Date: Mon, 26 May 2014 11:21:54 +0200 Subject: Rules for automatic package promotions In-Reply-To: References: Message-ID: <18E7D54B-29F2-4959-BE4B-F0D88A45BBB4@opencsw.org> Am 26.05.2014 um 11:12 schrieb Maciej (Matchek) Blizi?ski : > Did anybody write down what should be the rules for automatic package promotion? As in automatic migration from unstable to bratislava. don't know if this helps, but the Debian folks do the promotion dance like this: "Every day a program automatically selects the packages to include in Testing, according to elements guaranteeing a certain level of quality: ? lack of critical bugs, or, at least fewer than the version currently included in Testing; ? at least 10 days spent in Unstable, which is sufficient time to find and report any serious problems; ? successful compilation on all officially supported architectures; ? dependencies that can be satisfied in Testing, or that can at least be moved there together with the package in question." Cheerio! -slow From maciej at opencsw.org Tue May 27 00:26:14 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 27 May 2014 00:26:14 +0200 Subject: Rules for automatic package promotions In-Reply-To: <18E7D54B-29F2-4959-BE4B-F0D88A45BBB4@opencsw.org> References: <18E7D54B-29F2-4959-BE4B-F0D88A45BBB4@opencsw.org> Message-ID: There's a problem that not all of these data are available for us now. On Mon, May 26, 2014 at 11:21 AM, slowfranklin wrote: > "Every day a program automatically selects the packages to include in Testing, according to elements guaranteeing a certain level of quality: > ? lack of critical bugs, or, at least fewer than the version currently included in Testing; We don't have that information, because our mantis installation can't differentiate between different versions of one package. We also don't have a ready to use RPC API for it. There was something, but I don't think anybody made it work. > ? at least 10 days spent in Unstable, which is sufficient time to find and report any serious problems; Easy to do. > ? successful compilation on all officially supported architectures; We don't have this. > ? dependencies that can be satisfied in Testing, or that can at least be moved there together with the package in question." Transitiveness is easy too. We would need to define it in more detail; for example CSWfoo depends on CSWbar, where CSWbar is not ready to be promoted, but there is an older version of CSWbar in the testing catalog. Can we promote CSWfoo or not? I also checked that we don't have fast/easy access to bundles. This means that we can now implement promotion of individual packages, not by-bundle. Maciej From rmottola at opencsw.org Tue May 27 01:20:52 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Tue, 27 May 2014 01:20:52 +0200 Subject: alternatives: multiple versions for the same package In-Reply-To: References: <1400565603.12948.6.camel@anor> <02B1A9B3-0F24-448C-98B9-C81A67AB5350@opencsw.org> <1400595156.24448.16.camel@anor> <27622694-3522-4723-8E23-90C27D1760CA@opencsw.org> <1400697272.3639.4.camel@anor> Message-ID: <1401146452.5810.5.camel@anor> Hi, On Fri, 2014-05-23 at 09:28, Dagobert Michelsen wrote: > Hi Riccardo, > > I suggest to make one CSWgnustep-back which uses xlib and registers xlib as > alternative. All packages depend on this one. If you want the more elaborate > cairo you install CSWgnustep-back-cairo which just ships the changed files > from the alternatives and these alternatives have a higher precedence than > the xlib one. This is the same way as we do gnuplot. Does this sound reasonable? confused, I made a step back: I removed all modulations by commenting them out and setup gnustep-back as cairo backend. I commited the makefile. Right now it fails very early for me: ==> Verifying installed package CSWgnustep-gui: ok ==> Verifying installed package CSWlibcairo2: ok gar/gar.mk:320: recipe for target 'check-prereqs' failed gmake: *** [check-prereqs] Error 1 Any hints? Riccardo From dam at opencsw.org Tue May 27 08:53:50 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 27 May 2014 08:53:50 +0200 Subject: alternatives: multiple versions for the same package In-Reply-To: <1401146452.5810.5.camel@anor> References: <1400565603.12948.6.camel@anor> <02B1A9B3-0F24-448C-98B9-C81A67AB5350@opencsw.org> <1400595156.24448.16.camel@anor> <27622694-3522-4723-8E23-90C27D1760CA@opencsw.org> <1400697272.3639.4.camel@anor> <1401146452.5810.5.camel@anor> Message-ID: Hi Riccardo, Am 27.05.2014 um 01:20 schrieb Riccardo Mottola : > Hi, > > On Fri, 2014-05-23 at 09:28, Dagobert Michelsen wrote: >> Hi Riccardo, > >> >> I suggest to make one CSWgnustep-back which uses xlib and registers xlib as >> alternative. All packages depend on this one. If you want the more elaborate >> cairo you install CSWgnustep-back-cairo which just ships the changed files >> from the alternatives and these alternatives have a higher precedence than >> the xlib one. This is the same way as we do gnuplot. Does this sound reasonable? > > confused, I made a step back: I removed all modulations by commenting > them out and setup gnustep-back as cairo backend. I commited the > makefile. > > Right now it fails very early for me: > > ==> Verifying installed package CSWgnustep-gui: ok > ==> Verifying installed package CSWlibcairo2: ok > gar/gar.mk:320: recipe for target 'check-prereqs' failed > gmake: *** [check-prereqs] Error 1 > > Any hints? Yes, look at the above lines which not have ?ok? in them ;-) 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 rmottola at opencsw.org Wed May 28 00:38:50 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Wed, 28 May 2014 00:38:50 +0200 Subject: alternatives: multiple versions for the same package In-Reply-To: References: <1400565603.12948.6.camel@anor> <02B1A9B3-0F24-448C-98B9-C81A67AB5350@opencsw.org> <1400595156.24448.16.camel@anor> <27622694-3522-4723-8E23-90C27D1760CA@opencsw.org> <1400697272.3639.4.camel@anor> <1401146452.5810.5.camel@anor> Message-ID: <538513FA.40509@opencsw.org> Dagobert Michelsen wrote: > Yes, look at the above lines which not have ?ok? in them;-) That was it! there were unmet dependencies which I did not add. They must have been aded during an mgar update.. since I could build a cuople of days ago! I now completed my first GNUstep app package... Riccardo From dam at opencsw.org Wed May 28 10:37:26 2014 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 28 May 2014 10:37:26 +0200 Subject: alternatives: multiple versions for the same package In-Reply-To: <538513FA.40509@opencsw.org> References: <1400565603.12948.6.camel@anor> <02B1A9B3-0F24-448C-98B9-C81A67AB5350@opencsw.org> <1400595156.24448.16.camel@anor> <27622694-3522-4723-8E23-90C27D1760CA@opencsw.org> <1400697272.3639.4.camel@anor> <1401146452.5810.5.camel@anor> <538513FA.40509@opencsw.org> Message-ID: <7E44FABA-E332-4DE0-AB2F-53734F484968@opencsw.org> Hi Riccardo, Am 28.05.2014 um 00:38 schrieb Riccardo Mottola : > Dagobert Michelsen wrote: >> Yes, look at the above lines which not have ?ok? in them;-) > That was it! there were unmet dependencies which I did not add. They must have been aded during an mgar update.. since I could build a cuople of days ago! > > I now completed my first GNUstep app package... Congrats! 8-) -- "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 dts at opencsw.org Wed May 28 11:49:09 2014 From: dts at opencsw.org (Daniel Takahashi-Schwarz) Date: Wed, 28 May 2014 11:49:09 +0200 Subject: test Message-ID: <6BC159FB-02F2-49B6-AFC3-3B2AAD81B490@opencsw.org> test From rmottola at opencsw.org Wed May 28 23:02:33 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Wed, 28 May 2014 23:02:33 +0200 Subject: first gnustep app! but segfaults Message-ID: <53864EE9.7050909@opencsw.org> Hi, I just commited my first packaged GNUstep application, FTP (gs_ftp). After packaging gnustep core, I start finally to package applications. I'll prepend them with gs_ in the directory to distinguish them especially when the name is ambiguous, like FTP. About the backend, I just resorted for now removing Modulations and sticking to the cairo backend which is proven on Solaris anyway. gnustep-make, base, gui and back! Now to FTP.app, it builds, installs, but the application coredumps on startup. Does it do the same for you? Ideas? ON the same machine, I have a parallel GNUstep installation in another tree, built entirely from source without packages, there FTP works! (granted, it is svn trunk and not released, but that shouldn't justify a crash) Riccardo From maciej at opencsw.org Fri May 30 00:42:33 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 30 May 2014 00:42:33 +0200 Subject: Rules for automatic package promotions In-Reply-To: References: <18E7D54B-29F2-4959-BE4B-F0D88A45BBB4@opencsw.org> Message-ID: Quick update, I've looked at the code, and it turned out that most of the plumbing needed for bundles is already there. I have forgotten I had already done it. Bug/mantis information is likely available in JSON already - I need to find and confirm it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmottola at opencsw.org Fri May 30 00:58:54 2014 From: rmottola at opencsw.org (Riccardo Mottola) Date: Fri, 30 May 2014 00:58:54 +0200 Subject: first gnustep app! but segfaults In-Reply-To: <53864EE9.7050909@opencsw.org> References: <53864EE9.7050909@opencsw.org> Message-ID: <5387BBAE.3020405@opencsw.org> Hi, Riccardo Mottola wrote: > > Now to FTP.app, it builds, installs, but the application coredumps on > startup. Does it do the same for you? > Ideas? > > ON the same machine, I have a parallel GNUstep installation in another > tree, built entirely from source without packages, there FTP works! > (granted, it is svn trunk and not released, but that shouldn't justify > a crash) > I built and packaged another quite simple gnustep application, Zipper. It too just segfaults. Can someone reproduce this or does it work for you? I'm confused by the fact that my previous attempt to build everything from source outside mgar yielded working applications. Riccardo From bwalton at opencsw.org Sat May 31 10:01:31 2014 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 31 May 2014 09:01:31 +0100 Subject: issue with pkgdb Message-ID: Hi Folks, I was attempting to upload new git packages this morning and was getting 503's from the csw-upload-pkg script. Visiting the url http://buildfarm.opencsw.org/pkgdb/ yielded the same. Digging into the backend, it looks like there is a wsgi issue that has resulting in apache not properly respawing the backend processes: [Sat May 31 04:24:26 2014] [info] [client 213.178.77.176] mod_wsgi (pid=12178, process='buildfarm.opencs w.org', application='buildfarm.opencsw.org|/releases'): Loading WSGI script '/home/web/bin/gar/lib/web/r eleases_web.py'. [Sat May 31 04:24:52 2014] [info] mod_wsgi (pid=12178): Maximum requests reached 'buildfarm.opencsw.org' . [Sat May 31 04:24:52 2014] [info] mod_wsgi (pid=12178): Shutdown requested 'buildfarm.opencsw.org'. [Sat May 31 04:24:52 2014] [info] mod_wsgi (pid=12178): Stopping process 'buildfarm.opencsw.org'. [Sat May 31 04:24:52 2014] [info] mod_wsgi (pid=12178): Destroying interpreters. [Sat May 31 04:24:52 2014] [info] mod_wsgi (pid=12178): Destroy interpreter 'buildfarm.opencsw.org|/rele ases'. [Sat May 31 04:24:52 2014] [info] mod_wsgi (pid=12178): Cleanup interpreter ''. [Sat May 31 04:24:52 2014] [info] mod_wsgi (pid=12178): Terminating Python. [Sat May 31 04:24:52 2014] [info] mod_wsgi (pid=12178): Python has shutdown. [Sat May 31 04:24:52 2014] [info] mod_wsgi (pid=12207): Attach interpreter ''. [Sat May 31 04:24:52 2014] [info] mod_wsgi (pid=12207): Create interpreter 'buildfarm.opencsw.org|/relea ses'. [Sat May 31 04:24:52 2014] [info] [client 213.178.77.176] mod_wsgi (pid=12207, process='buildfarm.opencs w.org', application='buildfarm.opencsw.org|/releases'): Loading WSGI script '/home/web/bin/gar/lib/web/r eleases_web.py'. [Sat May 31 04:25:00 2014] [info] mod_wsgi (pid=12207): Create interpreter 'buildfarm.opencsw.org|/pkgdb '. [Sat May 31 04:25:00 2014] [info] [client 213.178.77.178] mod_wsgi (pid=12207, process='buildfarm.opencs w.org', application='buildfarm.opencsw.org|/pkgdb'): Loading WSGI script '/home/web/bin/gar/lib/web/pkgd b_web.py'. [Sat May 31 04:25:21 2014] [info] mod_wsgi (pid=12207): Maximum requests reached 'buildfarm.opencsw.org' . [Sat May 31 04:25:21 2014] [info] mod_wsgi (pid=12207): Shutdown requested 'buildfarm.opencsw.org'. [Sat May 31 04:25:21 2014] [info] mod_wsgi (pid=12207): Stopping process 'buildfarm.opencsw.org'. [Sat May 31 04:25:21 2014] [info] mod_wsgi (pid=12207): Destroying interpreters. [Sat May 31 04:25:21 2014] [info] mod_wsgi (pid=12207): Destroy interpreter 'buildfarm.opencsw.org|/rele ases'. [Sat May 31 04:25:21 2014] [info] mod_wsgi (pid=12207): Destroy interpreter 'buildfarm.opencsw.org|/pkgd b'. [Sat May 31 04:25:21 2014] [info] mod_wsgi (pid=12207): Cleanup interpreter ''. [Sat May 31 04:25:21 2014] [info] mod_wsgi (pid=12207): Terminating Python. [Sat May 31 04:25:21 2014] [info] mod_wsgi (pid=12207): Python has shutdown. [..snip lines from other stuff...] [Sat May 31 04:30:21 2014] [error] [client 213.178.77.176] Script timed out before returning headers: re leases_web.py [Sat May 31 04:35:00 2014] [error] [client 213.178.77.178] Script timed out before returning headers: pk gdb_web.py [Sat May 31 04:35:24 2014] [error] [client 213.178.77.176] Script timed out before returning headers: pk gdb_web.py [Sat May 31 04:37:02 2014] [error] [client 213.178.77.176] Script timed out before returning headers: pk gdb_web.py [Sat May 31 04:40:00 2014] [error] [client 213.178.77.178] Script timed out before returning headers: pk gdb_web.py This is now resulting in errors logged for each connection attempt: [Sat May 31 08:00:00 2014] [error] [client 213.178.77.178] (146)Connection refused: mod_wsgi (pid=11958): Connection attempt #1 to WSGI daemon process 'buildfarm.opencsw.org' on '/var/run/wsgi.20108.0.1.sock' failed, sleeping before retrying again. [Sat May 31 08:00:00 2014] [error] [client 213.178.77.178] (146)Connection refused: mod_wsgi (pid=11958): Connection attempt #2 to WSGI daemon process 'buildfarm.opencsw.org' on '/var/run/wsgi.20108.0.1.sock' failed, sleeping before retrying again. [Sat May 31 08:00:00 2014] [error] [client 213.178.77.178] Script timed out before returning headers: pkgdb_web.py I just kicked apache and that seems to have brought things back to life. I'm not currently planning to dig any further for a root cause here, but am noting the event in case it becomes a pattern in the future - we'll have more data to work with. Thanks -Ben From maciej at opencsw.org Sat May 31 10:09:06 2014 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 31 May 2014 09:09:06 +0100 Subject: issue with pkgdb In-Reply-To: References: Message-ID: On Sat, May 31, 2014 at 9:01 AM, Ben Walton via buildfarm < buildfarm at lists.opencsw.org> wrote: > I just kicked apache and that seems to have brought things back to > life. I'm not currently planning to dig any further for a root cause > here, but am noting the event in case it becomes a pattern in the > future - we'll have more data to work with. > I went to the same sequence of steps yesterday. Notice the problem, view the log, restart apache. There were error messages that apache couldn't connect to the wsgi script/process. If we see it happen again, let's investigate a bit more. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Sat May 31 10:38:30 2014 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 31 May 2014 09:38:30 +0100 Subject: issue with pkgdb In-Reply-To: References: Message-ID: On Sat, May 31, 2014 at 9:09 AM, Maciej (Matchek) Blizi?ski wrote: > On Sat, May 31, 2014 at 9:01 AM, Ben Walton via buildfarm > wrote: >> >> I just kicked apache and that seems to have brought things back to >> life. I'm not currently planning to dig any further for a root cause >> here, but am noting the event in case it becomes a pattern in the >> future - we'll have more data to work with. > > > I went to the same sequence of steps yesterday. Notice the problem, view the > log, restart apache. There were error messages that apache couldn't connect > to the wsgi script/process. If we see it happen again, let's investigate a > bit more. Ack. I didn't realized you'd done this already or I'd have spent a bit more time now. I agree that we should dig deeper the next time it happens. Thanks -Ben