From bwalton at opencsw.org Wed May 1 21:36:40 2013 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 1 May 2013 20:36:40 +0100 Subject: [csw-maintainers] Next Camp In-Reply-To: <517FEB4C.2020208@opencsw.org> References: <3822BE18-A840-4955-8569-0206018C7555@opencsw.org> <517f9674.rTYnOHUQoILgGdFj%Joerg.Schilling@fokus.fraunhofer.de> <517FEB4C.2020208@opencsw.org> Message-ID: I'd love to visit either Zurich or Berlin so whoever is willing to host is fine with me. If the weekend works for me, I'd love to come this summer! Thanks -Ben On Tue, Apr 30, 2013 at 5:03 PM, ?hsan?Do?an wrote: > Hi, > > Am 30.04.2013 13:01, schrieb Joerg Schilling: > >>> time is flying and we should start to plan the next summercamp. We have offers for >>> Zurich and Berlin and probably others on request. As OpenCSW was founded in Zurich >>> it would be nice to come back there and there are also now at least three maintainers >>> in the area. On the other hand during the last camps some maintainers mentioned >>> that Berlin would be a cool location and J?rg Schilling offered to host it. >> >> Sorry for the missunderstanding, I would first need to ask whether this is >> possible at FOKUS. > > Berlin would be really cool. :-) > > I've asked my manager and it would be possible to do at Swisscom in Zurich. > > > > Ihsan > > -- > ihsan at dogan.ch http://blog.dogan.ch/ > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From wilbury at opencsw.org Wed May 1 21:59:41 2013 From: wilbury at opencsw.org (Juraj Lutter) Date: Wed, 01 May 2013 21:59:41 +0200 Subject: [csw-maintainers] Next Camp In-Reply-To: References: <3822BE18-A840-4955-8569-0206018C7555@opencsw.org> <517f9674.rTYnOHUQoILgGdFj%Joerg.Schilling@fokus.fraunhofer.de> <517FEB4C.2020208@opencsw.org> Message-ID: <5181742D.7080702@opencsw.org> On 05/01/2013 09:36 PM, Ben Walton wrote: > I'd love to visit either Zurich or Berlin so whoever is willing to > host is fine with me. If the weekend works for me, I'd love to come > this summer! Same for me! -- Juraj Lutter From raos at opencsw.org Thu May 2 12:41:03 2013 From: raos at opencsw.org (Rafael Ostertag) Date: Thu, 2 May 2013 12:41:03 +0200 Subject: [csw-maintainers] [csw-pkgrequests] New package request : Cfengine3 Message-ID: <20130502104103.GC1101@bender.opencsw.org> Hi Marko [...] >> Von: pkgrequests at lists.opencsw.org >> Betreff: [csw-pkgrequests] New package request : Cfengine3 >> Datum: 30. April 2013 15:24:43 MESZ >> An: pkgrequests at lists.opencsw.org >> >> Dear maintainers, >> >> A new package request has been received from Marko Jauhiainen (mailto:mark at tpu.fi). Cfengine3 is requested to be added to our catalog. >> >> Here is the attached message : >> >> Hi guys, >> >> Cfengine 3.2.3 which appears to be the latest unstable version for Solaris 5.9 does not work properly with a 3.4.2 server (which we run on linux platform), but the latest unstable version for Solaris 5.10, 3.4.4, works perfectly. It would be great if you could upgrade the current unstable version for 5.9 from 3.2.3 => 3.4.4. Starting with CFEngine 3.3, CFEngine dropped support for Berkeley DB and recommended using Tokycabinet or QDBM as data store. I decided to go with Tokyocabinet, which requires a C99 environment. Unfortunately, Sol 5.9 does not provide C99. Further, CFEngine 3.4.x claims to be C99 (see ChangeLog of CFE), which doesn't raise the confidence of being able to build it under 5.9 anymore. I can give it a shot during the weekend, but no promises. cheers rafi >> >> Thanks! >> _______________________________________________ >> pkgrequests mailing list >> pkgrequests at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/pkgrequests > > -- > "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 > ----- End forwarded message ----- From laurent at opencsw.org Thu May 2 13:26:01 2013 From: laurent at opencsw.org (Laurent Blume) Date: Thu, 02 May 2013 13:26:01 +0200 Subject: [csw-maintainers] Next Camp In-Reply-To: <5181742D.7080702@opencsw.org> References: <3822BE18-A840-4955-8569-0206018C7555@opencsw.org> <517f9674.rTYnOHUQoILgGdFj%Joerg.Schilling@fokus.fraunhofer.de> <517FEB4C.2020208@opencsw.org> <5181742D.7080702@opencsw.org> Message-ID: <51824D49.3070108@opencsw.org> On 01/05/13 21:59, Juraj Lutter wrote: > On 05/01/2013 09:36 PM, Ben Walton wrote: >> I'd love to visit either Zurich or Berlin so whoever is willing to >> host is fine with me. If the weekend works for me, I'd love to come >> this summer! > > Same for me! And for me too! I only would like the final date to be set soon, as if I go, I have to set my vacations quickly. I'm too new to make any request for the date itself, but I'll do my best to come :-) Laurent From ihsan at opencsw.org Fri May 3 10:57:52 2013 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Fri, 03 May 2013 11:57:52 +0300 Subject: [csw-maintainers] mirror.opencsw.org broken? Message-ID: <51837C10.3070507@opencsw.org> Hi, Just run into this: => Fetching CSWpy-mox-0.5.3,REV=2013.05.02 (140/151) ... --2013-05-03 10:53:38-- http://mirror.opencsw.org/opencsw/unstable/i386/5.10/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz Resolving mirror.opencsw.org (mirror.opencsw.org)... 131.188.40.82, 2001:638:a000:4140::ffff:82 Connecting to mirror.opencsw.org (mirror.opencsw.org)|131.188.40.82|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 2013-05-03 10:53:39 ERROR 403: Forbidden. Well, it doesn't look good. Anything wrong there? Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From jh at opencsw.org Fri May 3 11:04:09 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Fri, 03 May 2013 11:04:09 +0200 Subject: [csw-maintainers] mirror.opencsw.org broken? In-Reply-To: <51837C10.3070507@opencsw.org> References: <51837C10.3070507@opencsw.org> Message-ID: <51837D89.10808@opencsw.org> Hi, yes looks like the access rights are wrong :) I can't fix it though. Greetings Jan Am 03.05.13 10:57, schrieb ?hsan Do?an: > Hi, > > Just run into this: > > => Fetching CSWpy-mox-0.5.3,REV=2013.05.02 (140/151) ... > --2013-05-03 10:53:38-- > http://mirror.opencsw.org/opencsw/unstable/i386/5.10/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz > Resolving mirror.opencsw.org (mirror.opencsw.org)... 131.188.40.82, > 2001:638:a000:4140::ffff:82 > Connecting to mirror.opencsw.org > (mirror.opencsw.org)|131.188.40.82|:80... connected. > HTTP request sent, awaiting response... 403 Forbidden > 2013-05-03 10:53:39 ERROR 403: Forbidden. > > Well, it doesn't look good. Anything wrong there? > > > > > Ihsan > From dam at opencsw.org Fri May 3 11:31:03 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 3 May 2013 11:31:03 +0200 Subject: [csw-maintainers] mirror.opencsw.org broken? In-Reply-To: <51837C10.3070507@opencsw.org> References: <51837C10.3070507@opencsw.org> Message-ID: <43B2BD5C-1AB5-453C-8F73-8FB63A91E043@opencsw.org> Hi Ihsan, Am 03.05.2013 um 10:57 schrieb ?hsan Do?an : > Just run into this: > > => Fetching CSWpy-mox-0.5.3,REV=2013.05.02 (140/151) ... > --2013-05-03 10:53:38-- > http://mirror.opencsw.org/opencsw/unstable/i386/5.10/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz > Resolving mirror.opencsw.org (mirror.opencsw.org)... 131.188.40.82, > 2001:638:a000:4140::ffff:82 > Connecting to mirror.opencsw.org > (mirror.opencsw.org)|131.188.40.82|:80... connected. > HTTP request sent, awaiting response... 403 Forbidden > 2013-05-03 10:53:39 ERROR 403: Forbidden. > > Well, it doesn't look good. Anything wrong there? Indeed, I just fixed it: > root at ncsw [global]:/export/mirror/opencsw-official > find . -perm 0600 > ./unstable/sparc/5.10/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz > ./unstable/i386/5.10/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz > ./allpkgs/openssh-6.2p1,REV=2013.05.02-SunOS5.10-sparc-CSW.pkg.gz > ./allpkgs/pm_carpassertmore-1.14,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz > ./allpkgs/py_cjson-1.0.3x7,REV=2013.05.03-SunOS5.9-i386-CSW.pkg.gz > ./allpkgs/py_netifaces-0.8,REV=2013.05.02-SunOS5.10-i386-CSW.pkg.gz > ./allpkgs/xdg_utils-1.0.2,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz > ./allpkgs/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz > ./allpkgs/openssh_client-6.2p1,REV=2013.05.02-SunOS5.10-sparc-CSW.pkg.gz > ./allpkgs/py_cjson-1.0.3x7,REV=2013.05.03-SunOS5.9-sparc-CSW.pkg.gz > ./allpkgs/py_cjson-1.0.3x7,REV=2013.05.03-SunOS5.10-sparc-CSW.pkg.gz > ./allpkgs/py_netifaces-0.8,REV=2013.05.02-SunOS5.10-sparc-CSW.pkg.gz > ./allpkgs/pm_carp_assert_more-1.14,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz > ./allpkgs/openssh_client-6.2p1,REV=2013.05.02-SunOS5.10-i386-CSW.pkg.gz > ./allpkgs/py_cjson-1.0.3x7,REV=2013.05.03-SunOS5.10-i386-CSW.pkg.gz > ./allpkgs/py_cssutils-0.9.10b1,REV=2013.05.03-SunOS5.10-all-CSW.pkg.gz > ./allpkgs/openssh-6.2p1,REV=2013.05.02-SunOS5.10-i386-CSW.pkg.gz > root at ncsw [global]:/export/mirror/opencsw-official > find . -perm 0600 | xargs chmod 644 The question is: how did this happen? I have no idea. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From ihsan at opencsw.org Fri May 3 11:35:41 2013 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Fri, 03 May 2013 12:35:41 +0300 Subject: [csw-maintainers] mirror.opencsw.org broken? In-Reply-To: <43B2BD5C-1AB5-453C-8F73-8FB63A91E043@opencsw.org> References: <51837C10.3070507@opencsw.org> <43B2BD5C-1AB5-453C-8F73-8FB63A91E043@opencsw.org> Message-ID: <518384ED.5010804@opencsw.org> Hi Dago, Am 03.05.2013 12:31, schrieb Dagobert Michelsen: >> Just run into this: >> >> => Fetching CSWpy-mox-0.5.3,REV=2013.05.02 (140/151) ... >> --2013-05-03 10:53:38-- >> http://mirror.opencsw.org/opencsw/unstable/i386/5.10/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >> Resolving mirror.opencsw.org (mirror.opencsw.org)... 131.188.40.82, >> 2001:638:a000:4140::ffff:82 >> Connecting to mirror.opencsw.org >> (mirror.opencsw.org)|131.188.40.82|:80... connected. >> HTTP request sent, awaiting response... 403 Forbidden >> 2013-05-03 10:53:39 ERROR 403: Forbidden. >> >> Well, it doesn't look good. Anything wrong there? > > > Indeed, I just fixed it: > >> root at ncsw [global]:/export/mirror/opencsw-official > find . -perm 0600 >> ./unstable/sparc/5.10/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >> ./unstable/i386/5.10/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >> ./allpkgs/openssh-6.2p1,REV=2013.05.02-SunOS5.10-sparc-CSW.pkg.gz >> ./allpkgs/pm_carpassertmore-1.14,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >> ./allpkgs/py_cjson-1.0.3x7,REV=2013.05.03-SunOS5.9-i386-CSW.pkg.gz >> ./allpkgs/py_netifaces-0.8,REV=2013.05.02-SunOS5.10-i386-CSW.pkg.gz >> ./allpkgs/xdg_utils-1.0.2,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >> ./allpkgs/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >> ./allpkgs/openssh_client-6.2p1,REV=2013.05.02-SunOS5.10-sparc-CSW.pkg.gz >> ./allpkgs/py_cjson-1.0.3x7,REV=2013.05.03-SunOS5.9-sparc-CSW.pkg.gz >> ./allpkgs/py_cjson-1.0.3x7,REV=2013.05.03-SunOS5.10-sparc-CSW.pkg.gz >> ./allpkgs/py_netifaces-0.8,REV=2013.05.02-SunOS5.10-sparc-CSW.pkg.gz >> ./allpkgs/pm_carp_assert_more-1.14,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >> ./allpkgs/openssh_client-6.2p1,REV=2013.05.02-SunOS5.10-i386-CSW.pkg.gz >> ./allpkgs/py_cjson-1.0.3x7,REV=2013.05.03-SunOS5.10-i386-CSW.pkg.gz >> ./allpkgs/py_cssutils-0.9.10b1,REV=2013.05.03-SunOS5.10-all-CSW.pkg.gz >> ./allpkgs/openssh-6.2p1,REV=2013.05.02-SunOS5.10-i386-CSW.pkg.gz >> root at ncsw [global]:/export/mirror/opencsw-official > find . -perm 0600 | xargs chmod 644 > > The question is: how did this happen? I have no idea. Something is still not good: => Fetching CSWpy-mox-0.5.3,REV=2013.05.02 (140/151) ... --2013-05-03 11:35:12-- http://mirror.opencsw.org/opencsw/unstable/i386/5.10/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz Resolving mirror.opencsw.org (mirror.opencsw.org)... 131.188.40.82, 2001:638:a000:4140::ffff:82 Connecting to mirror.opencsw.org (mirror.opencsw.org)|131.188.40.82|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 2013-05-03 11:35:12 ERROR 403: Forbidden. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Fri May 3 11:43:57 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 3 May 2013 11:43:57 +0200 Subject: [csw-maintainers] mirror.opencsw.org broken? In-Reply-To: <518384ED.5010804@opencsw.org> References: <51837C10.3070507@opencsw.org> <43B2BD5C-1AB5-453C-8F73-8FB63A91E043@opencsw.org> <518384ED.5010804@opencsw.org> Message-ID: Hi Ihsan, Am 03.05.2013 um 11:35 schrieb ?hsan Do?an : > Am 03.05.2013 12:31, schrieb Dagobert Michelsen: > >>> Just run into this: >>> >>> => Fetching CSWpy-mox-0.5.3,REV=2013.05.02 (140/151) ... >>> --2013-05-03 10:53:38-- >>> http://mirror.opencsw.org/opencsw/unstable/i386/5.10/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >>> Resolving mirror.opencsw.org (mirror.opencsw.org)... 131.188.40.82, >>> 2001:638:a000:4140::ffff:82 >>> Connecting to mirror.opencsw.org >>> (mirror.opencsw.org)|131.188.40.82|:80... connected. >>> HTTP request sent, awaiting response... 403 Forbidden >>> 2013-05-03 10:53:39 ERROR 403: Forbidden. >>> >>> Well, it doesn't look good. Anything wrong there? >> >> >> Indeed, I just fixed it: >> >>> root at ncsw [global]:/export/mirror/opencsw-official > find . -perm 0600 >>> ./unstable/sparc/5.10/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >>> ./unstable/i386/5.10/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >>> ./allpkgs/openssh-6.2p1,REV=2013.05.02-SunOS5.10-sparc-CSW.pkg.gz >>> ./allpkgs/pm_carpassertmore-1.14,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >>> ./allpkgs/py_cjson-1.0.3x7,REV=2013.05.03-SunOS5.9-i386-CSW.pkg.gz >>> ./allpkgs/py_netifaces-0.8,REV=2013.05.02-SunOS5.10-i386-CSW.pkg.gz >>> ./allpkgs/xdg_utils-1.0.2,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >>> ./allpkgs/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >>> ./allpkgs/openssh_client-6.2p1,REV=2013.05.02-SunOS5.10-sparc-CSW.pkg.gz >>> ./allpkgs/py_cjson-1.0.3x7,REV=2013.05.03-SunOS5.9-sparc-CSW.pkg.gz >>> ./allpkgs/py_cjson-1.0.3x7,REV=2013.05.03-SunOS5.10-sparc-CSW.pkg.gz >>> ./allpkgs/py_netifaces-0.8,REV=2013.05.02-SunOS5.10-sparc-CSW.pkg.gz >>> ./allpkgs/pm_carp_assert_more-1.14,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >>> ./allpkgs/openssh_client-6.2p1,REV=2013.05.02-SunOS5.10-i386-CSW.pkg.gz >>> ./allpkgs/py_cjson-1.0.3x7,REV=2013.05.03-SunOS5.10-i386-CSW.pkg.gz >>> ./allpkgs/py_cssutils-0.9.10b1,REV=2013.05.03-SunOS5.10-all-CSW.pkg.gz >>> ./allpkgs/openssh-6.2p1,REV=2013.05.02-SunOS5.10-i386-CSW.pkg.gz >>> root at ncsw [global]:/export/mirror/opencsw-official > find . -perm 0600 | xargs chmod 644 >> >> The question is: how did this happen? I have no idea. > > Something is still not good: > > => Fetching CSWpy-mox-0.5.3,REV=2013.05.02 (140/151) ... > --2013-05-03 11:35:12-- > http://mirror.opencsw.org/opencsw/unstable/i386/5.10/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz > Resolving mirror.opencsw.org (mirror.opencsw.org)... 131.188.40.82, > 2001:638:a000:4140::ffff:82 > Connecting to mirror.opencsw.org > (mirror.opencsw.org)|131.188.40.82|:80... connected. > HTTP request sent, awaiting response... 403 Forbidden > 2013-05-03 11:35:12 ERROR 403: Forbidden. I fixed it on the buildfarm, this gets then pushed to the primary mirror and then to the downstream mirror. Please hang on :-) Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From ihsan at opencsw.org Fri May 3 11:52:43 2013 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Fri, 03 May 2013 12:52:43 +0300 Subject: [csw-maintainers] mirror.opencsw.org broken? In-Reply-To: References: <51837C10.3070507@opencsw.org> <43B2BD5C-1AB5-453C-8F73-8FB63A91E043@opencsw.org> <518384ED.5010804@opencsw.org> Message-ID: <518388EB.7080000@opencsw.org> Hi Dago, Am 03.05.2013 12:43, schrieb Dagobert Michelsen: >>>> Just run into this: >>>> >>>> => Fetching CSWpy-mox-0.5.3,REV=2013.05.02 (140/151) ... >>>> --2013-05-03 10:53:38-- >>>> http://mirror.opencsw.org/opencsw/unstable/i386/5.10/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >>>> Resolving mirror.opencsw.org (mirror.opencsw.org)... 131.188.40.82, >>>> 2001:638:a000:4140::ffff:82 >>>> Connecting to mirror.opencsw.org >>>> (mirror.opencsw.org)|131.188.40.82|:80... connected. >>>> HTTP request sent, awaiting response... 403 Forbidden >>>> 2013-05-03 10:53:39 ERROR 403: Forbidden. >>>> >>>> Well, it doesn't look good. Anything wrong there? >>> >>> >>> Indeed, I just fixed it: >>> >>>> root at ncsw [global]:/export/mirror/opencsw-official > find . -perm 0600 >>>> ./unstable/sparc/5.10/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >>>> ./unstable/i386/5.10/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >>>> ./allpkgs/openssh-6.2p1,REV=2013.05.02-SunOS5.10-sparc-CSW.pkg.gz >>>> ./allpkgs/pm_carpassertmore-1.14,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >>>> ./allpkgs/py_cjson-1.0.3x7,REV=2013.05.03-SunOS5.9-i386-CSW.pkg.gz >>>> ./allpkgs/py_netifaces-0.8,REV=2013.05.02-SunOS5.10-i386-CSW.pkg.gz >>>> ./allpkgs/xdg_utils-1.0.2,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >>>> ./allpkgs/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >>>> ./allpkgs/openssh_client-6.2p1,REV=2013.05.02-SunOS5.10-sparc-CSW.pkg.gz >>>> ./allpkgs/py_cjson-1.0.3x7,REV=2013.05.03-SunOS5.9-sparc-CSW.pkg.gz >>>> ./allpkgs/py_cjson-1.0.3x7,REV=2013.05.03-SunOS5.10-sparc-CSW.pkg.gz >>>> ./allpkgs/py_netifaces-0.8,REV=2013.05.02-SunOS5.10-sparc-CSW.pkg.gz >>>> ./allpkgs/pm_carp_assert_more-1.14,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >>>> ./allpkgs/openssh_client-6.2p1,REV=2013.05.02-SunOS5.10-i386-CSW.pkg.gz >>>> ./allpkgs/py_cjson-1.0.3x7,REV=2013.05.03-SunOS5.10-i386-CSW.pkg.gz >>>> ./allpkgs/py_cssutils-0.9.10b1,REV=2013.05.03-SunOS5.10-all-CSW.pkg.gz >>>> ./allpkgs/openssh-6.2p1,REV=2013.05.02-SunOS5.10-i386-CSW.pkg.gz >>>> root at ncsw [global]:/export/mirror/opencsw-official > find . -perm 0600 | xargs chmod 644 >>> >>> The question is: how did this happen? I have no idea. >> >> Something is still not good: >> >> => Fetching CSWpy-mox-0.5.3,REV=2013.05.02 (140/151) ... >> --2013-05-03 11:35:12-- >> http://mirror.opencsw.org/opencsw/unstable/i386/5.10/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >> Resolving mirror.opencsw.org (mirror.opencsw.org)... 131.188.40.82, >> 2001:638:a000:4140::ffff:82 >> Connecting to mirror.opencsw.org >> (mirror.opencsw.org)|131.188.40.82|:80... connected. >> HTTP request sent, awaiting response... 403 Forbidden >> 2013-05-03 11:35:12 ERROR 403: Forbidden. > > > I fixed it on the buildfarm, this gets then pushed to the primary mirror and > then to the downstream mirror. Please hang on :-) Sorry. I'm on holidays. I have plenty of time at the moment. :-) Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Fri May 3 12:20:28 2013 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Fri, 03 May 2013 13:20:28 +0300 Subject: [csw-maintainers] mirror.opencsw.org broken? In-Reply-To: <518388EB.7080000@opencsw.org> References: <51837C10.3070507@opencsw.org> <43B2BD5C-1AB5-453C-8F73-8FB63A91E043@opencsw.org> <518384ED.5010804@opencsw.org> <518388EB.7080000@opencsw.org> Message-ID: <51838F6C.4090507@opencsw.org> Am 03.05.2013 12:52, schrieb ?hsan Do?an: >>>>> Just run into this: >>>>> >>>>> => Fetching CSWpy-mox-0.5.3,REV=2013.05.02 (140/151) ... >>>>> --2013-05-03 10:53:38-- >>>>> http://mirror.opencsw.org/opencsw/unstable/i386/5.10/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >>>>> Resolving mirror.opencsw.org (mirror.opencsw.org)... 131.188.40.82, >>>>> 2001:638:a000:4140::ffff:82 >>>>> Connecting to mirror.opencsw.org >>>>> (mirror.opencsw.org)|131.188.40.82|:80... connected. >>>>> HTTP request sent, awaiting response... 403 Forbidden >>>>> 2013-05-03 10:53:39 ERROR 403: Forbidden. >>>>> >>>>> Well, it doesn't look good. Anything wrong there? >>>> >>>> >>>> Indeed, I just fixed it: >>>> >>>>> root at ncsw [global]:/export/mirror/opencsw-official > find . -perm 0600 >>>>> ./unstable/sparc/5.10/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >>>>> ./unstable/i386/5.10/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >>>>> ./allpkgs/openssh-6.2p1,REV=2013.05.02-SunOS5.10-sparc-CSW.pkg.gz >>>>> ./allpkgs/pm_carpassertmore-1.14,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >>>>> ./allpkgs/py_cjson-1.0.3x7,REV=2013.05.03-SunOS5.9-i386-CSW.pkg.gz >>>>> ./allpkgs/py_netifaces-0.8,REV=2013.05.02-SunOS5.10-i386-CSW.pkg.gz >>>>> ./allpkgs/xdg_utils-1.0.2,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >>>>> ./allpkgs/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >>>>> ./allpkgs/openssh_client-6.2p1,REV=2013.05.02-SunOS5.10-sparc-CSW.pkg.gz >>>>> ./allpkgs/py_cjson-1.0.3x7,REV=2013.05.03-SunOS5.9-sparc-CSW.pkg.gz >>>>> ./allpkgs/py_cjson-1.0.3x7,REV=2013.05.03-SunOS5.10-sparc-CSW.pkg.gz >>>>> ./allpkgs/py_netifaces-0.8,REV=2013.05.02-SunOS5.10-sparc-CSW.pkg.gz >>>>> ./allpkgs/pm_carp_assert_more-1.14,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >>>>> ./allpkgs/openssh_client-6.2p1,REV=2013.05.02-SunOS5.10-i386-CSW.pkg.gz >>>>> ./allpkgs/py_cjson-1.0.3x7,REV=2013.05.03-SunOS5.10-i386-CSW.pkg.gz >>>>> ./allpkgs/py_cssutils-0.9.10b1,REV=2013.05.03-SunOS5.10-all-CSW.pkg.gz >>>>> ./allpkgs/openssh-6.2p1,REV=2013.05.02-SunOS5.10-i386-CSW.pkg.gz >>>>> root at ncsw [global]:/export/mirror/opencsw-official > find . -perm 0600 | xargs chmod 644 >>>> >>>> The question is: how did this happen? I have no idea. >>> >>> Something is still not good: >>> >>> => Fetching CSWpy-mox-0.5.3,REV=2013.05.02 (140/151) ... >>> --2013-05-03 11:35:12-- >>> http://mirror.opencsw.org/opencsw/unstable/i386/5.10/py_mox-0.5.3,REV=2013.05.02-SunOS5.10-all-CSW.pkg.gz >>> Resolving mirror.opencsw.org (mirror.opencsw.org)... 131.188.40.82, >>> 2001:638:a000:4140::ffff:82 >>> Connecting to mirror.opencsw.org >>> (mirror.opencsw.org)|131.188.40.82|:80... connected. >>> HTTP request sent, awaiting response... 403 Forbidden >>> 2013-05-03 11:35:12 ERROR 403: Forbidden. >> >> >> I fixed it on the buildfarm, this gets then pushed to the primary mirror and >> then to the downstream mirror. Please hang on :-) > > Sorry. > > I'm on holidays. I have plenty of time at the moment. :-) Ok, it works. Thanks Dago. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From maciej at opencsw.org Fri May 3 15:07:58 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 3 May 2013 14:07:58 +0100 Subject: [csw-maintainers] mirror.opencsw.org broken? In-Reply-To: <51838F6C.4090507@opencsw.org> References: <51837C10.3070507@opencsw.org> <43B2BD5C-1AB5-453C-8F73-8FB63A91E043@opencsw.org> <518384ED.5010804@opencsw.org> <518388EB.7080000@opencsw.org> <51838F6C.4090507@opencsw.org> Message-ID: One obvious answer is: Maciej has broken something on the buildfarm again. Offending change: http://sourceforge.net/apps/trac/gar/changeset/20933 The problem? tempfile.mkstemp creates files with mode 0600 by default. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Fri May 3 15:13:30 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 3 May 2013 15:13:30 +0200 Subject: [csw-maintainers] mirror.opencsw.org broken? In-Reply-To: References: <51837C10.3070507@opencsw.org> <43B2BD5C-1AB5-453C-8F73-8FB63A91E043@opencsw.org> <518384ED.5010804@opencsw.org> <518388EB.7080000@opencsw.org> <51838F6C.4090507@opencsw.org> Message-ID: <2C895BE8-3D21-40E6-9E31-2CAF572AA8CB@opencsw.org> Hi Maciej, Am 03.05.2013 um 15:07 schrieb Maciej (Matchek) Blizi?ski : > One obvious answer is: Maciej has broken something on the buildfarm again. > > Offending change: > http://sourceforge.net/apps/trac/gar/changeset/20933 > > The problem? tempfile.mkstemp creates files with mode 0600 by default. Looks like the problem :-) Could you please look again if more files piled up after the fix? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Fri May 3 15:23:56 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 3 May 2013 14:23:56 +0100 Subject: [csw-maintainers] mirror.opencsw.org broken? In-Reply-To: <2C895BE8-3D21-40E6-9E31-2CAF572AA8CB@opencsw.org> References: <51837C10.3070507@opencsw.org> <43B2BD5C-1AB5-453C-8F73-8FB63A91E043@opencsw.org> <518384ED.5010804@opencsw.org> <518388EB.7080000@opencsw.org> <51838F6C.4090507@opencsw.org> <2C895BE8-3D21-40E6-9E31-2CAF572AA8CB@opencsw.org> Message-ID: 2013/5/3 Dagobert Michelsen > Looks like the problem :-) Could you please look again if more files piled > up > after the fix? > Yes. The fix is now in place, and there are no files with 0600 (I had to fix the unbound packages). We're back to a good state. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfelecan at opencsw.org Fri May 3 19:49:37 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 03 May 2013 19:49:37 +0200 Subject: [csw-maintainers] Next Camp In-Reply-To: <3822BE18-A840-4955-8569-0206018C7555@opencsw.org> (Dagobert Michelsen's message of "Tue, 30 Apr 2013 11:58:12 +0200") References: <3822BE18-A840-4955-8569-0206018C7555@opencsw.org> Message-ID: Dagobert Michelsen writes: > I suggest we first decide for the location and then for the date, > probably August or September. Thoughts? Berlin in August or September could be quite nice, isn't it ? -- Peter From pfelecan at opencsw.org Fri May 3 19:50:50 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 03 May 2013 19:50:50 +0200 Subject: [csw-maintainers] [csw-pkgrequests] New package request : Cfengine3 In-Reply-To: <20130502104103.GC1101@bender.opencsw.org> (Rafael Ostertag's message of "Thu, 2 May 2013 12:41:03 +0200") References: <20130502104103.GC1101@bender.opencsw.org> Message-ID: Rafael Ostertag writes: > Further, CFEngine 3.4.x claims to be C99 (see ChangeLog of CFE), which doesn't > raise the confidence of being able to build it under 5.9 anymore. > > I can give it a shot during the weekend, but no promises. As noted elsewhere, Solaris 9 is on best effort, at best. -- Peter From dam at opencsw.org Fri May 3 23:52:08 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 3 May 2013 23:52:08 +0200 Subject: [csw-maintainers] Away for a couple of days Message-ID: Hi folks, I will be away the next four days. @Ben, @Woody: Would you be so kind taking care of the buildfarm requests? Best regards -- Dago From laurent at opencsw.org Sat May 4 11:03:31 2013 From: laurent at opencsw.org (Laurent Blume) Date: Sat, 04 May 2013 11:03:31 +0200 Subject: [csw-maintainers] Review of updated libotr2 Message-ID: <5184CEE3.2000202@opencsw.org> Hello all, I've managed to make proper updated packages for otr: http://gar.svn.sourceforge.net/viewvc/gar?view=revision&revision=20976 Can someone review them before I push in the catalog? The packages themselves should probably be right at this point, but I'm changing the packages. The current status is this: otr CSWotr 3.2.0,REV=2009.03.30 113.2 KB otrdevel CSWotrdevel 3.2.0,REV=2009.03.30 20.2 KB pidginotr CSWpidginotr 3.2.0,REV=2009.02.03 74.7 KB What I'm targeting is this: libotr2 CSWlibotr2 3.2.1 libotr5 CSWlibotr5 4.0.0 otr CSWotr 4.0.0 otr_dev CSWotr-dev 4.0.0 pidginotr CSWpidginotr 4.0.0 With an intermediate step of this: libotr2 CSWlibotr2 3.2.1 otr CSWotr 3.2.1 otrdevel_stub CSWotrdevel 3.2.1 otr_dev CSWotr-dev 3.2.1 pidginotr CSWpidginotr 3.2.0 Does it make sense? Thanks, Laurent From maciej at opencsw.org Sat May 4 11:17:02 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 4 May 2013 10:17:02 +0100 Subject: [csw-maintainers] Review of updated libotr2 In-Reply-To: <5184CEE3.2000202@opencsw.org> References: <5184CEE3.2000202@opencsw.org> Message-ID: 2013/5/4 Laurent Blume > > The current status is this: > otr CSWotr 3.2.0,REV=2009.03.30 113.2 KB > otrdevel CSWotrdevel 3.2.0,REV=2009.03.30 20.2 KB > pidginotr CSWpidginotr 3.2.0,REV=2009.02.03 74.7 KB > > What I'm targeting is this: > libotr2 CSWlibotr2 3.2.1 > libotr5 CSWlibotr5 4.0.0 > otr CSWotr 4.0.0 > otr_dev CSWotr-dev 4.0.0 > pidginotr CSWpidginotr 4.0.0 > > With an intermediate step of this: > libotr2 CSWlibotr2 3.2.1 > otr CSWotr 3.2.1 > otrdevel_stub CSWotrdevel 3.2.1 > otr_dev CSWotr-dev 3.2.1 > pidginotr CSWpidginotr 3.2.0 > > > Does it make sense? A nit: in the intermediate step, would CSWpidginotr be 3.2.1 rather than 3.2.0? I like your plan: first splitting the package without changing the version (too much) and making space for new sonames, then updating the version and building the new soname. Ideally, in the target state you'd also break the dependency between CSWotr and CSWlibotr2; current reverse dependencies of CSWotr are small: it's just mcabber. So if you rebuilt mcabber too, you could make CSWotr not depend on CSWlibotr2 and drop CSWlibotr2 entirely. Also, CSWotrdevel could go away in the target state. I think we can be a bit more aggressive with development package renames and deletions. Broken dep on a library: bad. Broken dep on a development package: meh. Maciej From pfelecan at opencsw.org Sat May 4 11:27:25 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 04 May 2013 11:27:25 +0200 Subject: [csw-maintainers] Review of updated libotr2 In-Reply-To: <5184CEE3.2000202@opencsw.org> (Laurent Blume's message of "Sat, 04 May 2013 11:03:31 +0200") References: <5184CEE3.2000202@opencsw.org> Message-ID: Laurent Blume writes: > I've managed to make proper updated packages for otr: > http://gar.svn.sourceforge.net/viewvc/gar?view=revision&revision=20976 > > Can someone review them before I push in the catalog? > 11 DISTFILES = $(NAME)-$(VERSION).tar.gz 11 DISTFILES = $(DISTNAME).tar.gz > 36 BUILD64_LIBS_ONLY = 1 Why not 32 bit also? The obsolescence declaration for CSWotrdevel as being replaced by CSWotr-dev is missing. > The packages themselves should probably be right at this point, but I'm > changing the packages. > > The current status is this: > otr CSWotr 3.2.0,REV=2009.03.30 113.2 KB > otrdevel CSWotrdevel 3.2.0,REV=2009.03.30 20.2 KB > pidginotr CSWpidginotr 3.2.0,REV=2009.02.03 74.7 KB > > What I'm targeting is this: > libotr2 CSWlibotr2 3.2.1 > libotr5 CSWlibotr5 4.0.0 > otr CSWotr 4.0.0 > otr_dev CSWotr-dev 4.0.0 > pidginotr CSWpidginotr 4.0.0 > > With an intermediate step of this: > libotr2 CSWlibotr2 3.2.1 > otr CSWotr 3.2.1 > otrdevel_stub CSWotrdevel 3.2.1 > otr_dev CSWotr-dev 3.2.1 > pidginotr CSWpidginotr 3.2.0 > > > Does it make sense? >From my point of view this is good transition -- Peter From maciej at opencsw.org Sat May 4 11:37:45 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 4 May 2013 10:37:45 +0100 Subject: [csw-maintainers] Review of updated libotr2 In-Reply-To: References: <5184CEE3.2000202@opencsw.org> Message-ID: 2013/5/4 Peter FELECAN : >> 36 BUILD64_LIBS_ONLY = 1 > > Why not 32 bit also? The word "only" refers to "libs", not to "64-bit". It's a bit confusing (pun intended ;-) ). The difference in mechanics is merging or not merging e.g. $(bindir) from the 64-bit build. From laurent at opencsw.org Sat May 4 12:03:35 2013 From: laurent at opencsw.org (Laurent Blume) Date: Sat, 04 May 2013 12:03:35 +0200 Subject: [csw-maintainers] Review of updated libotr2 In-Reply-To: References: <5184CEE3.2000202@opencsw.org> Message-ID: <5184DCF7.3000903@opencsw.org> On 2013-05-04 11:27 AM, Peter FELECAN wrote: > Laurent Blume writes: > >> I've managed to make proper updated packages for otr: >> http://gar.svn.sourceforge.net/viewvc/gar?view=revision&revision=20976 >> >> Can someone review them before I push in the catalog? > >> 11 DISTFILES = $(NAME)-$(VERSION).tar.gz > 11 DISTFILES = $(DISTNAME).tar.gz Noted. >> 36 BUILD64_LIBS_ONLY = 1 > > Why not 32 bit also? Hehe, I had the same initial reaction when I saw that :-) > The obsolescence declaration for CSWotrdevel as being replaced by > CSWotr-dev is missing. Isn't this enough? OBSOLETED_BY_CSWotr-dev += CSWotrdevel Laurent From laurent at opencsw.org Sat May 4 12:08:22 2013 From: laurent at opencsw.org (Laurent Blume) Date: Sat, 04 May 2013 12:08:22 +0200 Subject: [csw-maintainers] Review of updated libotr2 In-Reply-To: References: <5184CEE3.2000202@opencsw.org> Message-ID: <5184DE16.6020707@opencsw.org> On 2013-05-04 11:17 AM, Maciej (Matchek) Blizi?ski wrote: > A nit: in the intermediate step, would CSWpidginotr be 3.2.1 rather than 3.2.0? No, I intend to do it quickly, so without bothering to push 3.2.1. Does that matter? I guess I could do it if it does. > I like your plan: first splitting the package without changing the > version (too much) and making space for new sonames, then updating the > version and building the new soname. > > Ideally, in the target state you'd also break the dependency between > CSWotr and CSWlibotr2; current reverse dependencies of CSWotr are > small: it's just mcabber. So if you rebuilt mcabber too, you could > make CSWotr not depend on CSWlibotr2 and drop CSWlibotr2 entirely. Well, there will be a dependency: CSWotr depends on CSWlibotr5 which depends on CSWlibotr2 (followed the flac libs there). So that's the one that would be ultimately removed when all other dependencies are rebuilt against CSWlibotr5. There should be no dependency at all on CSWotr in the end (AFAICT, there is no reason to). > Also, CSWotrdevel could go away in the target state. I think we can be > a bit more aggressive with development package renames and deletions. Okay, how to make sure that it'll go away when somebody runs pkgutil --cleanup? > Broken dep on a library: bad. > Broken dep on a development package: meh. Agreed. Laurent From maciej at opencsw.org Sat May 4 12:20:09 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 4 May 2013 11:20:09 +0100 Subject: [csw-maintainers] Review of updated libotr2 In-Reply-To: <5184DE16.6020707@opencsw.org> References: <5184CEE3.2000202@opencsw.org> <5184DE16.6020707@opencsw.org> Message-ID: 2013/5/4 Laurent Blume : > On 2013-05-04 11:17 AM, Maciej (Matchek) Blizi?ski wrote: >> A nit: in the intermediate step, would CSWpidginotr be 3.2.1 rather than 3.2.0? > > No, I intend to do it quickly, so without bothering to push 3.2.1. Does > that matter? I guess I could do it if it does. No, it doesn't matter, I just thought it was built from the same source tarball. >> I like your plan: first splitting the package without changing the >> version (too much) and making space for new sonames, then updating the >> version and building the new soname. >> >> Ideally, in the target state you'd also break the dependency between >> CSWotr and CSWlibotr2; current reverse dependencies of CSWotr are >> small: it's just mcabber. So if you rebuilt mcabber too, you could >> make CSWotr not depend on CSWlibotr2 and drop CSWlibotr2 entirely. > > Well, there will be a dependency: CSWotr depends on CSWlibotr5 which > depends on CSWlibotr2 (followed the flac libs there). > So that's the one that would be ultimately removed when all other > dependencies are rebuilt against CSWlibotr5. There should be no > dependency at all on CSWotr in the end (AFAICT, there is no reason to). Not sure why CSWlibotr5 would depend on CSWlibotr2. What role do flac libraries play in there? >> Also, CSWotrdevel could go away in the target state. I think we can be >> a bit more aggressive with development package renames and deletions. > > Okay, how to make sure that it'll go away when somebody runs pkgutil > --cleanup? OBSOLETED_BY is the only currently existing directive that does it. Maybe we could add a new one, or (ab)use OBSOLETED_BY? Maciej From laurent at opencsw.org Sat May 4 12:38:32 2013 From: laurent at opencsw.org (Laurent Blume) Date: Sat, 04 May 2013 12:38:32 +0200 Subject: [csw-maintainers] Review of updated libotr2 In-Reply-To: References: <5184CEE3.2000202@opencsw.org> <5184DE16.6020707@opencsw.org> Message-ID: <5184E528.3010400@opencsw.org> On 2013-05-04 12:20 PM, Maciej (Matchek) Blizi?ski wrote: > Not sure why CSWlibotr5 would depend on CSWlibotr2. What role do flac > libraries play in there? No direct one, of course, I only used their recipes as an example :-) But you're right, I didn't do it properly there: it should be the latest CSWotr depending on both CSWlibotr2 and CSWlibotr5, right? The first for compatibility with the previous version, the second because it needs it. > OBSOLETED_BY is the only currently existing directive that does it. > Maybe we could add a new one, or (ab)use OBSOLETED_BY? I'll use it for now. Laurent From pfelecan at opencsw.org Sat May 4 12:56:15 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 04 May 2013 12:56:15 +0200 Subject: [csw-maintainers] Review of updated libotr2 In-Reply-To: <5184DCF7.3000903@opencsw.org> (Laurent Blume's message of "Sat, 04 May 2013 12:03:35 +0200") References: <5184CEE3.2000202@opencsw.org> <5184DCF7.3000903@opencsw.org> Message-ID: Laurent Blume writes: > On 2013-05-04 11:27 AM, Peter FELECAN wrote: >> Laurent Blume writes: >> >>> I've managed to make proper updated packages for otr: >>> http://gar.svn.sourceforge.net/viewvc/gar?view=revision&revision=20976 >>> >>> Can someone review them before I push in the catalog? >> >>> 11 DISTFILES = $(NAME)-$(VERSION).tar.gz >> 11 DISTFILES = $(DISTNAME).tar.gz > > Noted. > >>> 36 BUILD64_LIBS_ONLY = 1 >> >> Why not 32 bit also? > > Hehe, I had the same initial reaction when I saw that :-) Happily Maciej explained it to us... >> The obsolescence declaration for CSWotrdevel as being replaced by >> CSWotr-dev is missing. > > Isn't this enough? > OBSOLETED_BY_CSWotr-dev += CSWotrdevel Sorry, I haven't seen it. -- Peter From jh at opencsw.org Mon May 6 11:42:42 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Mon, 06 May 2013 11:42:42 +0200 Subject: [csw-maintainers] [csw-buildfarm] Need package CSWgobject-introspection on the buildfarm In-Reply-To: References: Message-ID: <51877B12.7020109@opencsw.org> Hi, Am 06.05.13 11:37, schrieb Ralph Boehme: > Hi > > the build farm has CSWgobject-introspection-dev, but it's missing CSWgobject-introspection. As a result packages (e.g. dconf) checking for the presence for this toolkit finds it (via the .pc file from the -dev package), but then the whole machinery to drive introspection is missing as that lives in the CSWgobject-introspection package. > > Thanks! Will install it. @Carsten seems like you should change the deps from the -dev package to also include CSWgobject-introspection From laurent at opencsw.org Mon May 6 14:57:15 2013 From: laurent at opencsw.org (Laurent Blume) Date: Mon, 06 May 2013 14:57:15 +0200 Subject: [csw-maintainers] [csw-buildfarm] Need package CSWgobject-introspection on the buildfarm In-Reply-To: <51877B12.7020109@opencsw.org> References: <51877B12.7020109@opencsw.org> Message-ID: <5187A8AB.1070907@opencsw.org> On 06/05/13 11:42, Jan Holzhueter wrote: > Hi, > > Am 06.05.13 11:37, schrieb Ralph Boehme: >> Hi >> >> the build farm has CSWgobject-introspection-dev, but it's missing >> CSWgobject-introspection. As a result packages (e.g. dconf) >> checking for the presence for this toolkit finds it (via the .pc >> file from the -dev package), but then the whole machinery to drive >> introspection is missing as that lives in the >> CSWgobject-introspection package. >> >> Thanks! > > Will install it. > > @Carsten seems like you should change the deps from the -dev package > to also include CSWgobject-introspection I was hitting similar introspection issues when trying to rebuild libgconf. After the update above, it picks it up, but the result is a horrible mess: http://dpaste.com/1112141/ The PATH and PKG_CONFIG_PATH are correct during configure time, but at this point in the build, introspection runs the Solaris pkg-config (not OpenCSW's, since that one has the default of /opt/csw/lib/pkgconfig) and without a PKG_CONFIG_PATH set, so it fails to find gio-2.0.pc. Below, it tries to runs gcc, but this is a 64 bit build, and gcc is called without -m64 (please note that configure found Studio, so introspection just uses its own). So I say, this introspection package is broken at this point, and needs to be fixed, and preferably removed until then, as it breaks things. Laurent From grzemba at contac-dt.de Mon May 6 16:31:08 2013 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Mon, 06 May 2013 16:31:08 +0200 Subject: [csw-maintainers] [csw-buildfarm] Need package CSWgobject-introspection on the buildfarm In-Reply-To: References: <51877B12.7020109@opencsw.org> <5187A8AB.1070907@opencsw.org> Message-ID: because this in gobject-introspection build recipe: # Python isn't 64-bit yet #BUILD64 = 1 you should not enable gobject-introspection for 64bit builds?? Carsten Am 06.05.13 schrieb Laurent Blume : > On 06/05/13 11:42, Jan Holzhueter wrote: > >Hi, > > > >Am 06.05.13 11:37, schrieb Ralph Boehme: > >>Hi > >> > >>the build farm has CSWgobject-introspection-dev, but it's missing > >>CSWgobject-introspection. As a result packages (e.g. dconf) > >>checking for the presence for this toolkit finds it (via the .pc > >>file from the -dev package), but then the whole machinery to drive > >>introspection is missing as that lives in the > >>CSWgobject-introspection package. > >> > >>Thanks! > > > >Will install it. > > > >@Carsten seems like you should change the deps from the -dev package > >to also include CSWgobject-introspection > > I was hitting similar introspection issues when trying to rebuild libgconf. > After the update above, it picks it up, but the result is a horrible mess: > > http://dpaste.com/1112141/ > > The PATH and PKG_CONFIG_PATH are correct during configure time, but at this point in the build, introspection runs the Solaris pkg-config (not OpenCSW's, since that one has the default of /opt/csw/lib/pkgconfig) and without a PKG_CONFIG_PATH set, so it fails to find gio-2.0.pc. > > Below, it tries to runs gcc, but this is a 64 bit build, and gcc is called without -m64 (please note that configure found Studio, so introspection just uses its own). > > So I say, this introspection package is broken at this point, and needs to be fixed, and preferably removed until then, as it breaks things. > > Laurent > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laurent at opencsw.org Mon May 6 17:02:35 2013 From: laurent at opencsw.org (Laurent Blume) Date: Mon, 06 May 2013 17:02:35 +0200 Subject: [csw-maintainers] [csw-buildfarm] Need package CSWgobject-introspection on the buildfarm In-Reply-To: References: <51877B12.7020109@opencsw.org> <5187A8AB.1070907@opencsw.org> Message-ID: <5187C60B.5070208@opencsw.org> On 06/05/13 16:31, Carsten Grzemba wrote: > because this in gobject-introspection build recipe: > > > # Python isn't 64-bit yet > #BUILD64 = 1 > > you should not enable gobject-introspection for 64bit builds?? Well, something must have been done, it started working, and I find no trace of gcc anymore. I did have to add this, else it won't pick the .pc files it needs: === # Needed for introspection EXTRA_BUILD_EXPORTS += PKG_CONFIG_PATH === Now at least it builds to the end. I've not tested it yet nor reviewed the build output. Laurent From jh at opencsw.org Tue May 7 12:16:17 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Tue, 07 May 2013 12:16:17 +0200 Subject: [csw-maintainers] [csw-buildfarm] request to install CSWqt4-dev In-Reply-To: References: Message-ID: <5188D471.9010805@opencsw.org> Hi, Am 07.05.13 12:11, schrieb pfelecan: > Please install on the build farm's unstable servers the qt4_dev package. > I see that Carsten is still doning some work on it. @Carsten in which state is qt4? Can I install it or will it brake everything? :) Greetings Jan From grzemba at contac-dt.de Tue May 7 12:30:21 2013 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Tue, 07 May 2013 12:30:21 +0200 Subject: [csw-maintainers] [csw-buildfarm] request to install CSWqt4-dev In-Reply-To: References: <5188D471.9010805@opencsw.org> Message-ID: I am just going to add the obsoleting the QT4-gxx package. If you wont to install the current packages from unstable you should remove the Qt4-gxx packages by hand from buildfarm. Carsten Am 07.05.13 schrieb Jan Holzhueter : > Hi, > Am 07.05.13 12:11, schrieb pfelecan: > > Please install on the build farm's unstable servers the qt4_dev package. > > > > I see that Carsten is still doning some work on it. > @Carsten in which state is qt4? Can I install it or will it brake > everything? :) > > Greetings > Jan > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Tue May 7 12:46:57 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 7 May 2013 12:46:57 +0200 Subject: [csw-maintainers] [csw-buildfarm] Need package CSWgobject-introspection on the buildfarm In-Reply-To: <5187C60B.5070208@opencsw.org> References: <51877B12.7020109@opencsw.org> <5187A8AB.1070907@opencsw.org> <5187C60B.5070208@opencsw.org> Message-ID: Hi Laurent, Am 06.05.2013 um 17:02 schrieb Laurent Blume : > On 06/05/13 16:31, Carsten Grzemba wrote: >> because this in gobject-introspection build recipe: >> >> # Python isn't 64-bit yet >> #BUILD64 = 1 >> >> you should not enable gobject-introspection for 64bit builds?? > > Well, something must have been done, it started working, and I find no trace of gcc anymore. > I did have to add this, else it won't pick the .pc files it needs: > > === > # Needed for introspection > EXTRA_BUILD_EXPORTS += PKG_CONFIG_PATH > === > > Now at least it builds to the end. I've not tested it yet nor reviewed the build output. The default is to export that only during configure time. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From laurent at opencsw.org Tue May 7 21:15:08 2013 From: laurent at opencsw.org (Laurent Blume) Date: Tue, 07 May 2013 21:15:08 +0200 Subject: [csw-maintainers] Code issue w/ different behaviour on sparc and x86 Message-ID: <518952BC.2060401@opencsw.org> All, I've just noticed an issue with glib: during the configure part, on x86, header inlining is enabled. On Sparc, it is not. They end up having slightly different headers installed. This can have some effect on dependencies: pidgin-sipe builds without a hitch on x86, fails on sparc, because of that. I've tracked the issue down to the example attached, straight from the configure script. It fails like that on sparc, but no error on x86: /opt/solarisstudio12.3/bin/cc -o conftest -xO3 -m64 -features=extensions -xc99 -D_XPG6 -I/opt/csw/include -m64 -lsocket -R/opt/csw/lib/$ISALIST -R/opt/csw/lib/64 -L/opt/csw/lib/64 conftest.c -lintl Undefined first referenced symbol in file glib_test_func2 conftest.o ld: fatal: symbol referencing errors. No output written to conftest Does anybody know of a clean workaround? Also, can OpenCSW report the issue, as it seems a clean bug? Or should I do it on my side? Thanks for any hint, Laurent -------------- next part -------------- /* /opt/solarisstudio12.3/bin/cc -o conftest -xO3 -m64 -features=extensions \ -xc99 -D_XPG6 -I/opt/csw/include -m64 -lsocket -R/opt/csw/lib/$ISALIST \ -R/opt/csw/lib/64 -L/opt/csw/lib/64 conftest.c -lintl */ #define PACKAGE_NAME "glib" #define PACKAGE_TARNAME "glib" #define PACKAGE_VERSION "2.32.4" #define PACKAGE_STRING "glib 2.32.4" #define PACKAGE_BUGREPORT "http://bugzilla.gnome.org/enter_bug.cgi?product=glib" #define PACKAGE_URL "" #define GLIB_MAJOR_VERSION 2 #define GLIB_MINOR_VERSION 32 #define GLIB_MICRO_VERSION 4 #define GLIB_INTERFACE_AGE 4 #define GLIB_BINARY_AGE 3204 #define NEED_ICONV_CACHE 1 #define HAVE_LOCALE_H 1 #define HAVE_LC_MESSAGES 1 #define HAVE_BIND_TEXTDOMAIN_CODESET 1 #define HAVE_GETTEXT 1 #define HAVE_DCGETTEXT 1 #define ENABLE_NLS 1 #define GETTEXT_PACKAGE "glib20" #define GLIB_LOCALE_DIR "/opt/csw/share/locale" #define USE_LIBICONV_GNU 1 #define HAVE_DLFCN_H 1 #define LT_OBJDIR ".libs/" #define HAVE_VPRINTF 1 #define HAVE_DOPRNT 1 #define HAVE_ALLOCA_H 1 #define HAVE_ALLOCA 1 #define HAVE_MMAP 1 #define HAVE_MEMALIGN 1 #define HAVE_VALLOC 1 #define HAVE_FSYNC 1 #define HAVE_ATEXIT 1 #define HAVE_GMTIME_R 1 #define SIZEOF_CHAR 1 #define SIZEOF_SHORT 2 #define SIZEOF_LONG 8 #define SIZEOF_INT 4 #define SIZEOF_VOID_P 8 #define SIZEOF_LONG_LONG 8 #define SIZEOF___INT64 0 #define HAVE_SIG_ATOMIC_T 1 #define HAVE_LONG_LONG_FORMAT 1 #define G_HAVE___INLINE 1 #define G_HAVE___INLINE__ 1 #define G_HAVE_INLINE 1 /* end confdefs.h. */ #if defined (G_HAVE_INLINE) && defined (__GNUC__) && defined (__STRICT_ANSI__) # undef inline # define inline __inline__ #elif !defined (G_HAVE_INLINE) # undef inline # if defined (G_HAVE___INLINE__) # define inline __inline__ # elif defined (G_HAVE___INLINE) # define inline __inline # endif #endif int glib_test_func2 (int); static inline int glib_test_func1 (void) { return glib_test_func2 (1); } int main (void) { int i = 1; } From maciej at opencsw.org Wed May 8 13:49:58 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 8 May 2013 12:49:58 +0100 Subject: [csw-maintainers] Small/Medium-size coding project available Message-ID: Hello maintainers, Here's a small/medium sized coding project that we would significantly benefit from. It's nicely self-contained and it does have some algorithmic components. It can be written in any programming language (that we can run on our buildfarm). Our current catalog generation takes about 80 minutes. If we can make it faster, we can generate the catalog more often and have a quicker build-push-release turnaround, and relieve the buildfarm from most of the current catalog-generation-induced disk stress. We currently run the generation every 3h. If we can make the generation complete in something like 10 minutes (which I think is possible), we could run catalog generation e.g. every hour. We have a directory on disk with a package catalog, as we can see on the mirror: http://mirror.opencsw.org/opencsw/unstable/i386/5.10/ We can query the RESTful interface for the current state of the same catalog in the database: curl -s http://buildfarm.opencsw.org/pkgdb/rest/catalogs/unstable/i386/SunOS5.10/ \ | python -m json.tool | (head -n 30; cat >/dev/null) [ { "basename": "389_admin-1.1.30,REV=2013.01.07-SunOS5.10-i386-CSW.pkg.gz", "catalogname": "389_admin", "file_basename": "389_admin-1.1.30,REV=2013.01.07-SunOS5.10-i386-CSW.pkg.gz", "md5_sum": "6110aad210240504ede48f9cd8b4501c", "mtime": "2013-01-07T12:02:22", "rev": "2013.01.07", "size": 403046, "version": "1.1.30,REV=2013.01.07", "version_string": "1.1.30,REV=2013.01.07" }, (...) ] (the query takes about 25s to evaluate; the python bit is here just for data pretty-printing) We also have the 'allpkgs' directory: http://mirror.opencsw.org/opencsw/allpkgs/ It's excluded from rsync, so it doesn't get propagated to mirrors, but it does exist on the master mirror and the buildfarm. It's the central pool for all the package data files. When we generate catalogs, we do not copy anything, instead we make hardlinks to the allpkgs directory. For example, we make a hardlink from allpkgs/foo-i386-CSW.pkg.gz to unstable/5.9/i386. However, when we generate a catalog for the next OS release (e.g. 5.10), we do not make a hardlink; if possible, we make a symlink from the 5.10 directory to the 5.9 directory. This way we save space on mirrors: we only send out 1 copy of the file (in the lowest OS release in which it occurs), and then we create symlinks to it. For example: allpkgs/foo-i386-CSW.pkg.gz (not synced to mirrors) unstable/i386/5.9/foo-i386-CSW.pkg.gz (hardlink to the file in allpkgs) unstable/i386/5.10/foo-i386-CSW.pkg.gz ? ../5.9/foo-i386-CSW.pkg.gz (symlink) unstable/i386/5.11/foo-i386-CSW.pkg.gz ? ../5.9/foo-i386-CSW.pkg.gz (symlink) You can now see that we need to generate catalogs for one catalog release (e.g. unstable) and one architecture, and all OS releases in one program run. We do currently have code that does it, but the code is really stupid. It unlinks everything from the directory, and starts from scratch every time. This generates a lot of unnecessary disk operations, and makes the whole process slow. It would be much better to see what's in the database, see what's on disk, and figure out the smallest set of operations to bring the disk to the new state. Would anyone be up for writing it? Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfelecan at opencsw.org Wed May 8 14:01:15 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 08 May 2013 14:01:15 +0200 Subject: [csw-maintainers] Code issue w/ different behaviour on sparc and x86 In-Reply-To: <518952BC.2060401@opencsw.org> (Laurent Blume's message of "Tue, 07 May 2013 21:15:08 +0200") References: <518952BC.2060401@opencsw.org> Message-ID: Laurent Blume writes: > All, > > I've just noticed an issue with glib: during the configure part, on > x86, header inlining is enabled. On Sparc, it is not. They end up > having slightly different headers installed. > This can have some effect on dependencies: pidgin-sipe builds without > a hitch on x86, fails on sparc, because of that. > > I've tracked the issue down to the example attached, straight from the > configure script. > > It fails like that on sparc, but no error on x86: > > /opt/solarisstudio12.3/bin/cc -o conftest -xO3 -m64 > -features=extensions -xc99 -D_XPG6 -I/opt/csw/include -m64 -lsocket > -R/opt/csw/lib/$ISALIST -R/opt/csw/lib/64 -L/opt/csw/lib/64 > conftest.c -lintl > Undefined first referenced > symbol in file > glib_test_func2 conftest.o > ld: fatal: symbol referencing errors. No output written to conftest > > Does anybody know of a clean workaround? Did you try using GCC? What purpose do you pursue using Sun Studio? (Note that I'm not trying to start a compiler war, just trying to understand). > Also, can OpenCSW report the issue, as it seems a clean bug? Or should > I do it on my side? IMHO you do it on your side, i.e., OCSW is not doing it on your behalf; dont't forget: you are OCSW... -- Peter From pfelecan at opencsw.org Wed May 8 14:27:54 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 08 May 2013 14:27:54 +0200 Subject: [csw-maintainers] Small/Medium-size coding project available In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Wed, 8 May 2013 12:49:58 +0100") References: Message-ID: I have time for this starting on May 22 and I intend to use Qt Core for this. If nobody took it up until then, I'll come back if I need clarifications about the specifications. -- Peter From maciej at opencsw.org Wed May 8 15:51:46 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 8 May 2013 14:51:46 +0100 Subject: [csw-maintainers] Small/Medium-size coding project available In-Reply-To: References: Message-ID: 2013/5/8 Peter FELECAN > > I intend to use Qt Core for this. Do you mean you'd write this in C++? Qt Core[1] looks interesting. I didn't know QT had non-gui utility classes. What testing framework would you use? QtTest[2]? Maciej [1] http://qt-project.org/doc/qt-4.8/qtcore.html [2] http://qt-project.org/doc/qt-4.8/qtestlib-tutorial1.html From pfelecan at opencsw.org Wed May 8 16:17:31 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 08 May 2013 16:17:31 +0200 Subject: [csw-maintainers] Small/Medium-size coding project available In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Wed, 8 May 2013 14:51:46 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/5/8 Peter FELECAN >> >> I intend to use Qt Core for this. > > Do you mean you'd write this in C++? Yes. The result can run on all our servers, isn't it? > Qt Core[1] looks interesting. I didn't know QT had non-gui utility classes. In my case this is the main usage of Qt: writing servers, back ends, ETL, &c. > What testing framework would you use? QtTest? A very good candidate. Not that I need a special framework to write unit, system and integration tests. However, if you think that using a test framework should be in the specification, I will gladly conform. -- Peter From laurent at opencsw.org Wed May 8 19:16:49 2013 From: laurent at opencsw.org (Laurent Blume) Date: Wed, 08 May 2013 19:16:49 +0200 Subject: [csw-maintainers] Code issue w/ different behaviour on sparc and x86 In-Reply-To: References: <518952BC.2060401@opencsw.org> Message-ID: <518A8881.8020206@opencsw.org> On 08/05/2013 14:01, Peter FELECAN wrote: > Did you try using GCC? What purpose do you pursue using Sun Studio? > (Note that I'm not trying to start a compiler war, just trying to > understand). Yes, I tried, GCC does not show the issue. The recipe was using Studio, I kept it that way so far. In general, I prefer Studio, mostly to avoid dependencies on libgcc and C++ ABI problems. I guess the latter is not a problem for glib. Not sure if performance is still an issue, though I would probably think it is on Sparc. > IMHO you do it on your side, i.e., OCSW is not doing it on your behalf; > dont't forget: you are OCSW... Well, I meant, is there an OpenCSW CSI to raise the issue with Oracle? I don't mind using the support contract we have at work if needed. Laurent From maciej at opencsw.org Wed May 8 19:20:48 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 8 May 2013 18:20:48 +0100 Subject: [csw-maintainers] Small/Medium-size coding project available In-Reply-To: References: Message-ID: 2013/5/8 Peter FELECAN : > "Maciej (Matchek) Blizi?ski" writes: > >> 2013/5/8 Peter FELECAN >>> >>> I intend to use Qt Core for this. >> >> Do you mean you'd write this in C++? > > Yes. The result can run on all our servers, isn't it? Sure. >> Qt Core[1] looks interesting. I didn't know QT had non-gui utility classes. > > In my case this is the main usage of Qt: writing servers, back ends, > ETL, &c. > >> What testing framework would you use? QtTest? > > A very good candidate. Not that I need a special framework to write > unit, system and integration tests. However, if you think that using a > test framework should be in the specification, I will gladly conform. Usually you end up with a framework, even if you start without one, so I think picking one right at the start is a good idea. The top-level code could be something like: GetLock(); disk_state = GetDiskState(); db_state = GetDbState(); disk_operation_list = ComputeDiskOperationList(disk_state, db_state); ApplyDiskOperations(disk_operation_list); ReleaseLock(); The Get*State() methods would interact with the environment, so I wouldn't expect much tests for that part. The ComputeDiskOperationList() function on the other hand would do the critical work, so I would expect that there would be a set of sample inputs and expected outputs. This way we'll be able to add support for newly discovered corner cases while ensuring that all the previous cases are still working correctly. Maciej From pfelecan at opencsw.org Wed May 8 19:32:09 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 08 May 2013 19:32:09 +0200 Subject: [csw-maintainers] Code issue w/ different behaviour on sparc and x86 In-Reply-To: <518A8881.8020206@opencsw.org> (Laurent Blume's message of "Wed, 08 May 2013 19:16:49 +0200") References: <518952BC.2060401@opencsw.org> <518A8881.8020206@opencsw.org> Message-ID: Laurent Blume writes: > On 08/05/2013 14:01, Peter FELECAN wrote: >> Did you try using GCC? What purpose do you pursue using Sun Studio? >> (Note that I'm not trying to start a compiler war, just trying to >> understand). > > Yes, I tried, GCC does not show the issue. The recipe was using > Studio, I kept it that way so far. In general, I prefer Studio, mostly > to avoid dependencies on libgcc and C++ ABI problems. I guess the > latter is not a problem for glib. > Not sure if performance is still an issue, though I would probably > think it is on Sparc. I'm a supporter of using GCC for the sake of minimal effort, especially when packaging components usually compiled with. Of course, you're free to make the world better by enhancing the support of other compilers. You're right in guessing that there are no C++ ABI issues in this case. >> IMHO you do it on your side, i.e., OCSW is not doing it on your behalf; >> dont't forget: you are OCSW... > > Well, I meant, is there an OpenCSW CSI to raise the issue with Oracle? > I don't mind using the support contract we have at work if needed. I cannot answer your question as I don't know what's a CSI. -- Peter From pfelecan at opencsw.org Wed May 8 19:38:41 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 08 May 2013 19:38:41 +0200 Subject: [csw-maintainers] no i386 build for pyqt Message-ID: I'm working on PyQt4 and encounter something strange. Maybe it's due to my choice of using a lang-python environment. However, can somebody used with Python packaging review my recipe: http://gar.svn.sourceforge.net/gar/?rev=21030&view=rev The log is at ~/pfelecan/log/pyqt TIA -- Peter From jh at opencsw.org Wed May 8 19:44:35 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Wed, 08 May 2013 19:44:35 +0200 Subject: [csw-maintainers] Code issue w/ different behaviour on sparc and x86 In-Reply-To: References: <518952BC.2060401@opencsw.org> <518A8881.8020206@opencsw.org> Message-ID: <518A8F03.5060404@opencsw.org> Am 08.05.13 19:32, schrieb Peter FELECAN: > Laurent Blume writes: > >> On 08/05/2013 14:01, Peter FELECAN wrote: >>> Did you try using GCC? What purpose do you pursue using Sun Studio? >>> (Note that I'm not trying to start a compiler war, just trying to >>> understand). >> >> Yes, I tried, GCC does not show the issue. The recipe was using >> Studio, I kept it that way so far. In general, I prefer Studio, mostly >> to avoid dependencies on libgcc and C++ ABI problems. I guess the >> latter is not a problem for glib. >> Not sure if performance is still an issue, though I would probably >> think it is on Sparc. > > I'm a supporter of using GCC for the sake of minimal effort, especially > when packaging components usually compiled with. Of course, you're free > to make the world better by enhancing the support of other compilers. > > You're right in guessing that there are no C++ ABI issues in this case. > >>> IMHO you do it on your side, i.e., OCSW is not doing it on your behalf; >>> dont't forget: you are OCSW... >> >> Well, I meant, is there an OpenCSW CSI to raise the issue with Oracle? >> I don't mind using the support contract we have at work if needed. > > I cannot answer your question as I don't know what's a CSI. Customer Support Identifier the number you need to have support from oracle. We don't have one for SunStudio so feel free to open a support request. Greetings Jan From dam at opencsw.org Fri May 10 12:21:29 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 10 May 2013 12:21:29 +0200 Subject: [csw-maintainers] Summercamp 2013 in Berlin Message-ID: <51E76907-ED9B-4D81-816E-D365DD3ACE27@opencsw.org> Hi folks, I just talked to J?rg and he definitely offered to host the SummerCamp 2013 in Berlin! The Doodle poll for the date decision is available at http://doodle.com/nspgrnxuydk38n5r Please add yourself as soon as possible so we can fix the date and work on further planning. Best regards -- Dago From dam at opencsw.org Sun May 12 14:20:06 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 12 May 2013 14:20:06 +0200 Subject: [csw-maintainers] Codebrowser for the build recipes Message-ID: Hi folks, I just noticed that Ohloh has an excellent (and fast!) codebroweser: http://code.ohloh.net/project?pid=1FjsNz-SmKo&browser=Default&cid=m1lKGYqGZXE&prevcid=&prevDid= The URLs are pretty ugly, though. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From yann at pleiades.fr.eu.org Sun May 12 14:22:36 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sun, 12 May 2013 14:22:36 +0200 Subject: [csw-maintainers] Last remaining packages for the openssl migration (take 3) Message-ID: Hi everyone, Here is a new status update about of the libssl update (0.9.8 -> 1.0.0). Below is the list of the remaining packages, sorted by maintainer, that need to be updated before we can complete the migration. Oh my god ! Only 7 packages remaining !! *Benny von Mossner ( Sabbatical )* pound and pound2: Dago is still working on this ones. Dago, have you been able to make some progress ? The recipe is in good shape, isn't it ? What is missing to release the new packages ? *Ben Walton* libruby1_9_1_1 and ruby18: Ben is still working on updating these packages (or rather on new ruby 2.0 packages). Ben, have you been able to make some progress ? Do you need some help ? *Dagobert Michelsen* libcurl3 : blocked by a compilation issue forwarded upstream: http://sourceforge.net/p/curl/bugs/1217/ No answer from upstream since April, 23rd. I am afraid it might take a long time. Dago, do you think that, like for libarchive, you could just release an updated 7.11.2 package so we don't depend on the compilation bug being resolved ? *Jon Craig:* ntop : Blocked by the gdbm upgrade and automake issues. Jon, I noticed Ben committed a fix for the automake problem. Is it ok now ? Do you think you will be able to release the new package soon ? *Dominique Laigle:* erlang : I missed that one previously because it contains no binary linked against libssl. Either it is an error or erland dynamically loads the ssl library with dlsym.* * Whatever, I think I will drop this package unless someone objects. Dominique Laigle is not a maintainer anymore, the package has not been updated since 2007 and I am not sure compiling erland under Solaris is a piece of cake. So, is someone motivated to take over this package ? Thanks in advance for your help on this migration ! Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Sun May 12 14:26:30 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 12 May 2013 14:26:30 +0200 Subject: [csw-maintainers] Last remaining packages for the openssl migration (take 3) In-Reply-To: References: Message-ID: Hi Yann, Am 12.05.2013 um 14:22 schrieb Yann Rouillard : > Here is a new status update about of the libssl update (0.9.8 -> 1.0.0). > Below is the list of the remaining packages, sorted by maintainer, that need to be updated before we can complete the migration. > > Oh my god ! Only 7 packages remaining !! > > Benny von Mossner ( Sabbatical ) > pound and pound2: Dago is still working on this ones. > > Dago, have you been able to make some progress ? The recipe is in good shape, isn't it ? What is missing to release the new packages ? The binaries are all in place, however, I would like to provide a good SMF recipe and a reference configuration that enables poundctl via a sane name. I will have some time next week. > > Ben Walton > libruby1_9_1_1 and ruby18: Ben is still working on updating these packages (or rather on new ruby 2.0 packages). > > Ben, have you been able to make some progress ? Do you need some help ? > > Dagobert Michelsen > libcurl3: blocked by a compilation issue forwarded upstream: http://sourceforge.net/p/curl/bugs/1217/ > > No answer from upstream since April, 23rd. I am afraid it might take a long time. > Dago, do you think that, like for libarchive, you could just release an updated 7.11.2 package so we don't depend on the compilation bug being resolved ? Can do. > > Jon Craig: > ntop: Blocked by the gdbm upgrade and automake issues. > > Jon, I noticed Ben committed a fix for the automake problem. Is it ok now ? > Do you think you will be able to release the new package soon ? > > Dominique Laigle: > erlang: I missed that one previously because it contains no binary linked against libssl. Either it is an error or erland dynamically loads the ssl library with dlsym. > > Whatever, I think I will drop this package unless someone objects. Dominique Laigle is not a maintainer anymore, the package has not been updated since 2007 and I am not sure compiling erland under Solaris is a piece of cake. > So, is someone motivated to take over this package ? IIRC, Peter Felecan was working on it. The recipe should be pretty much ready for release IMHO. Best regards -- Dago > > > Thanks in advance for your help on this migration ! > > Yann > > > -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfelecan at opencsw.org Sun May 12 15:25:19 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 12 May 2013 15:25:19 +0200 Subject: [csw-maintainers] Last remaining packages for the openssl migration (take 3) In-Reply-To: (Dagobert Michelsen's message of "Sun, 12 May 2013 14:26:30 +0200") References: Message-ID: Dagobert Michelsen writes: >> Dominique Laigle: >> erlang: I missed that one previously because it contains no binary >> linked against libssl. Either it is an error or erland dynamically >> loads the ssl library with dlsym. >> >> Whatever, I think I will drop this package unless someone >> objects. Dominique Laigle is not a maintainer anymore, the package >> has not been updated since 2007 and I am not sure compiling erland >> under Solaris is a piece of cake. >> So, is someone motivated to take over this package ? > > IIRC, Peter Felecan was working on it. The recipe should be pretty much ready for release IMHO. Unfortunately I'm not and never was... -- Peter From bonivart at opencsw.org Sun May 12 19:41:32 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 12 May 2013 19:41:32 +0200 Subject: [csw-maintainers] Did I just break something? Message-ID: bonivart at login[build.2013-05-12]$ csw-upload-pkg pm_hook* pm_log* pm_test* Processing 6 file(s). Please wait. Checking 6 package(s) against catalog unstable sparc SunOS5.10 Checking 6 package(s) against catalog unstable i386 SunOS5.10 Checking 3 package(s) against catalog unstable sparc SunOS5.11 WARNING:root:Not saving an error for CSWpmlogany. WARNING:root:Not saving an error for CSWpmlogany. WARNING:root:Not saving an error for CSWpmlogany. WARNING:root:Not saving an error for CSWpmlogany. WARNING:root:Not saving an error for CSWpmlogany. WARNING:root:Not saving an error for CSWpmlogany. WARNING:root:Not saving an error for CSWpmlogany. WARNING:root:Not saving an error for CSWpmlogany. WARNING:root:Not saving an error for CSWpmlogany. WARNING:root:Not saving an error for CSWpmhooklexwrap. WARNING:root:Not saving an error for CSWpmhooklexwrap. Checking 6 package(s) against catalog unstable i386 SunOS5.11 Checks failed for catalogs: - sparc SunOS5.11 pm_hook_lexwrap-0.24,REV=2013.05.12-SunOS5.10-all-CSW.pkg.gz pm_log_any-0.15,REV=2013.05.12-SunOS5.10-all-CSW.pkg.gz pm_testdeep-0.110,REV=2013.05.12-SunOS5.10-all-CSW.pkg.gz To see errors, run: /home/bonivart/opencsw/.buildsys/v2/bin/checkpkg --catalog-release unstable --os-release SunOS5.11 --catalog-architecture sparc d71e8ae17cb5a5706b26b0ed73fe4398 2fab102e3fe5e962bee48f98120dea18 6bb16854c24e0ec63046cdde3f707d59 Packages have not been submitted to the unstable catalog. From dam at opencsw.org Sun May 12 19:58:21 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 12 May 2013 19:58:21 +0200 Subject: [csw-maintainers] Did I just break something? In-Reply-To: References: Message-ID: <7FF645B1-A303-4155-934D-057D20352CE2@opencsw.org> Hi Peter Am 12.05.2013 um 19:41 schrieb Peter Bonivart : > bonivart at login[build.2013-05-12]$ csw-upload-pkg pm_hook* pm_log* pm_test* > Processing 6 file(s). Please wait. > Checking 6 package(s) against catalog unstable sparc SunOS5.10 > Checking 6 package(s) against catalog unstable i386 SunOS5.10 > Checking 3 package(s) against catalog unstable sparc SunOS5.11 > WARNING:root:Not saving an error for CSWpmlogany. > WARNING:root:Not saving an error for CSWpmlogany. > WARNING:root:Not saving an error for CSWpmlogany. > WARNING:root:Not saving an error for CSWpmlogany. > WARNING:root:Not saving an error for CSWpmlogany. > WARNING:root:Not saving an error for CSWpmlogany. > WARNING:root:Not saving an error for CSWpmlogany. > WARNING:root:Not saving an error for CSWpmlogany. > WARNING:root:Not saving an error for CSWpmlogany. > WARNING:root:Not saving an error for CSWpmhooklexwrap. > WARNING:root:Not saving an error for CSWpmhooklexwrap. > Checking 6 package(s) against catalog unstable i386 SunOS5.11 > Checks failed for catalogs: > - sparc SunOS5.11 > pm_hook_lexwrap-0.24,REV=2013.05.12-SunOS5.10-all-CSW.pkg.gz > pm_log_any-0.15,REV=2013.05.12-SunOS5.10-all-CSW.pkg.gz > pm_testdeep-0.110,REV=2013.05.12-SunOS5.10-all-CSW.pkg.gz > To see errors, run: > /home/bonivart/opencsw/.buildsys/v2/bin/checkpkg --catalog-release > unstable --os-release SunOS5.11 --catalog-architecture sparc > d71e8ae17cb5a5706b26b0ed73fe4398 2fab102e3fe5e962bee48f98120dea18 > 6bb16854c24e0ec63046cdde3f707d59 What errors are printed? Best regards -- Dago > Packages have not been submitted to the unstable catalog. > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From bonivart at opencsw.org Sun May 12 19:59:46 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 12 May 2013 19:59:46 +0200 Subject: [csw-maintainers] Did I just break something? In-Reply-To: References: Message-ID: On Sun, May 12, 2013 at 7:41 PM, Peter Bonivart wrote: > bonivart at login[build.2013-05-12]$ csw-upload-pkg pm_hook* pm_log* pm_test* > Processing 6 file(s). Please wait. > Checking 6 package(s) against catalog unstable sparc SunOS5.10 > Checking 6 package(s) against catalog unstable i386 SunOS5.10 > Checking 3 package(s) against catalog unstable sparc SunOS5.11 > WARNING:root:Not saving an error for CSWpmlogany. > WARNING:root:Not saving an error for CSWpmlogany. > WARNING:root:Not saving an error for CSWpmlogany. > WARNING:root:Not saving an error for CSWpmlogany. > WARNING:root:Not saving an error for CSWpmlogany. > WARNING:root:Not saving an error for CSWpmlogany. > WARNING:root:Not saving an error for CSWpmlogany. > WARNING:root:Not saving an error for CSWpmlogany. > WARNING:root:Not saving an error for CSWpmlogany. > WARNING:root:Not saving an error for CSWpmhooklexwrap. > WARNING:root:Not saving an error for CSWpmhooklexwrap. > Checking 6 package(s) against catalog unstable i386 SunOS5.11 > Checks failed for catalogs: > - sparc SunOS5.11 > pm_hook_lexwrap-0.24,REV=2013.05.12-SunOS5.10-all-CSW.pkg.gz > pm_log_any-0.15,REV=2013.05.12-SunOS5.10-all-CSW.pkg.gz > pm_testdeep-0.110,REV=2013.05.12-SunOS5.10-all-CSW.pkg.gz > To see errors, run: > /home/bonivart/opencsw/.buildsys/v2/bin/checkpkg --catalog-release > unstable --os-release SunOS5.11 --catalog-architecture sparc > d71e8ae17cb5a5706b26b0ed73fe4398 2fab102e3fe5e962bee48f98120dea18 > 6bb16854c24e0ec63046cdde3f707d59 > Packages have not been submitted to the unstable catalog. More info. I think it started with me being lazy and not selecting which packages to upload, instead I just ran "csw-upload-pkg *" in my staging dir where I already had 18 previously uploaded packages. I expected it to skip those based on the checksum and it didn't upload them but it did check the whole set of 24 packages which is understandable depending on how you view it. Anyway, at the end I got some kind of server timeout and tried again, I think the first error caused the new packages not to be properly added to the 5.11 catalogs and now it claims (by running the above command) I have file collisions which I obviously didn't have before trying to upload. From bonivart at opencsw.org Sun May 12 20:02:16 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 12 May 2013 20:02:16 +0200 Subject: [csw-maintainers] Did I just break something? In-Reply-To: <7FF645B1-A303-4155-934D-057D20352CE2@opencsw.org> References: <7FF645B1-A303-4155-934D-057D20352CE2@opencsw.org> Message-ID: On Sun, May 12, 2013 at 7:58 PM, Dagobert Michelsen wrote: > What errors are printed? See my other post. It says I now have file collisions which I didn't before trying to upload. Something got half done in my first upload, note it saying it's checking only 3 packages against sparc 5.11 and 6 against all other catalogs. From bonivart at opencsw.org Sun May 12 20:14:39 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 12 May 2013 20:14:39 +0200 Subject: [csw-maintainers] Did I just break something? In-Reply-To: References: <7FF645B1-A303-4155-934D-057D20352CE2@opencsw.org> Message-ID: I tried to upload the packages specifically to sparc 5.11 and that seems to have succeeded: bonivart at login[build.2013-05-12]$ csw-upload-pkg --catalog-release=unstable --os-release=SunOS5.11 pm_hook* pm_log* pm_test* Processing 6 file(s). Please wait. Uploading 'pm_log_any-0.15,REV=2013.05.12-SunOS5.10-all-CSW.pkg.gz' Uploading 'pm_logany-0.15,REV=2013.05.12-SunOS5.10-all-CSW.pkg.gz' Checking 6 package(s) against catalog unstable sparc SunOS5.11 Checking 6 package(s) against catalog unstable i386 SunOS5.11 All checks successful. Proceeding. Inserting pm_hook_lexwrap (all SunOS5.10) into catalog unstable i386 SunOS5.11 Inserting pm_hooklexwrap (all SunOS5.10) into catalog unstable i386 SunOS5.11 Inserting pm_log_any (all SunOS5.10) into catalog unstable i386 SunOS5.11 Inserting pm_logany (all SunOS5.10) into catalog unstable i386 SunOS5.11 Inserting pm_test_deep (all SunOS5.10) into catalog unstable i386 SunOS5.11 Inserting pm_testdeep (all SunOS5.10) into catalog unstable i386 SunOS5.11 Inserting pm_hook_lexwrap (all SunOS5.10) into catalog unstable sparc SunOS5.11 Inserting pm_hooklexwrap (all SunOS5.10) into catalog unstable sparc SunOS5.11 Inserting pm_log_any (all SunOS5.10) into catalog unstable sparc SunOS5.11 Inserting pm_logany (all SunOS5.10) into catalog unstable sparc SunOS5.11 Inserting pm_test_deep (all SunOS5.10) into catalog unstable sparc SunOS5.11 Inserting pm_testdeep (all SunOS5.10) into catalog unstable sparc SunOS5.11 I guess it re-uploaded pm_log_any because I rebuilt that one just to make sure there were no errors so it got a new checksum. I then tried uploading the 6 packages to all catalogs again for good measure: bonivart at login[build.2013-05-12]$ csw-upload-pkg pm_hook* pm_log* pm_test* Processing 6 file(s). Please wait. Checking 6 package(s) against catalog unstable sparc SunOS5.10 Checking 6 package(s) against catalog unstable i386 SunOS5.10 Checking 6 package(s) against catalog unstable sparc SunOS5.11 Checking 6 package(s) against catalog unstable i386 SunOS5.11 All checks successful. Proceeding. Inserting pm_hook_lexwrap (all SunOS5.10) into catalog unstable i386 SunOS5.10 Inserting pm_hooklexwrap (all SunOS5.10) into catalog unstable i386 SunOS5.10 Inserting pm_log_any (all SunOS5.10) into catalog unstable i386 SunOS5.10 Inserting pm_logany (all SunOS5.10) into catalog unstable i386 SunOS5.10 Inserting pm_test_deep (all SunOS5.10) into catalog unstable i386 SunOS5.10 Inserting pm_testdeep (all SunOS5.10) into catalog unstable i386 SunOS5.10 Inserting pm_hook_lexwrap (all SunOS5.10) into catalog unstable i386 SunOS5.11 Inserting pm_hooklexwrap (all SunOS5.10) into catalog unstable i386 SunOS5.11 Inserting pm_log_any (all SunOS5.10) into catalog unstable i386 SunOS5.11 Inserting pm_logany (all SunOS5.10) into catalog unstable i386 SunOS5.11 Inserting pm_test_deep (all SunOS5.10) into catalog unstable i386 SunOS5.11 Inserting pm_testdeep (all SunOS5.10) into catalog unstable i386 SunOS5.11 Inserting pm_hook_lexwrap (all SunOS5.10) into catalog unstable sparc SunOS5.10 Inserting pm_hooklexwrap (all SunOS5.10) into catalog unstable sparc SunOS5.10 Inserting pm_log_any (all SunOS5.10) into catalog unstable sparc SunOS5.10 Inserting pm_logany (all SunOS5.10) into catalog unstable sparc SunOS5.10 Inserting pm_test_deep (all SunOS5.10) into catalog unstable sparc SunOS5.10 Inserting pm_testdeep (all SunOS5.10) into catalog unstable sparc SunOS5.10 Inserting pm_hook_lexwrap (all SunOS5.10) into catalog unstable sparc SunOS5.11 Inserting pm_hooklexwrap (all SunOS5.10) into catalog unstable sparc SunOS5.11 Inserting pm_log_any (all SunOS5.10) into catalog unstable sparc SunOS5.11 Inserting pm_logany (all SunOS5.10) into catalog unstable sparc SunOS5.11 Inserting pm_test_deep (all SunOS5.10) into catalog unstable sparc SunOS5.11 Inserting pm_testdeep (all SunOS5.10) into catalog unstable sparc SunOS5.11 And that also worked! :) From dam at opencsw.org Sun May 12 20:26:21 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 12 May 2013 20:26:21 +0200 Subject: [csw-maintainers] Did I just break something? In-Reply-To: References: <7FF645B1-A303-4155-934D-057D20352CE2@opencsw.org> Message-ID: <23C29B3A-D54C-43E4-A9E0-1B5608757992@opencsw.org> Am 12.05.2013 um 20:14 schrieb Peter Bonivart : > I tried to upload the packages specifically to sparc 5.11 and that > seems to have succeeded: > > bonivart at login[build.2013-05-12]$ csw-upload-pkg > --catalog-release=unstable --os-release=SunOS5.11 pm_hook* pm_log* > pm_test* > Processing 6 file(s). Please wait. > Uploading 'pm_log_any-0.15,REV=2013.05.12-SunOS5.10-all-CSW.pkg.gz' > Uploading 'pm_logany-0.15,REV=2013.05.12-SunOS5.10-all-CSW.pkg.gz' > Checking 6 package(s) against catalog unstable sparc SunOS5.11 > Checking 6 package(s) against catalog unstable i386 SunOS5.11 > All checks successful. Proceeding. > Inserting pm_hook_lexwrap (all SunOS5.10) into catalog unstable i386 SunOS5.11 > Inserting pm_hooklexwrap (all SunOS5.10) into catalog unstable i386 SunOS5.11 > Inserting pm_log_any (all SunOS5.10) into catalog unstable i386 SunOS5.11 > Inserting pm_logany (all SunOS5.10) into catalog unstable i386 SunOS5.11 > Inserting pm_test_deep (all SunOS5.10) into catalog unstable i386 SunOS5.11 > Inserting pm_testdeep (all SunOS5.10) into catalog unstable i386 SunOS5.11 > Inserting pm_hook_lexwrap (all SunOS5.10) into catalog unstable sparc SunOS5.11 > Inserting pm_hooklexwrap (all SunOS5.10) into catalog unstable sparc SunOS5.11 > Inserting pm_log_any (all SunOS5.10) into catalog unstable sparc SunOS5.11 > Inserting pm_logany (all SunOS5.10) into catalog unstable sparc SunOS5.11 > Inserting pm_test_deep (all SunOS5.10) into catalog unstable sparc SunOS5.11 > Inserting pm_testdeep (all SunOS5.10) into catalog unstable sparc SunOS5.11 > > I guess it re-uploaded pm_log_any because I rebuilt that one just to > make sure there were no errors so it got a new checksum. This will cause troubles as it leads to corrupt allpkgs and other oddities. Maciej? Best regards -- Dago > I then tried > uploading the 6 packages to all catalogs again for good measure: > > bonivart at login[build.2013-05-12]$ csw-upload-pkg pm_hook* pm_log* pm_test* > Processing 6 file(s). Please wait. > Checking 6 package(s) against catalog unstable sparc SunOS5.10 > Checking 6 package(s) against catalog unstable i386 SunOS5.10 > Checking 6 package(s) against catalog unstable sparc SunOS5.11 > Checking 6 package(s) against catalog unstable i386 SunOS5.11 > All checks successful. Proceeding. > Inserting pm_hook_lexwrap (all SunOS5.10) into catalog unstable i386 SunOS5.10 > Inserting pm_hooklexwrap (all SunOS5.10) into catalog unstable i386 SunOS5.10 > Inserting pm_log_any (all SunOS5.10) into catalog unstable i386 SunOS5.10 > Inserting pm_logany (all SunOS5.10) into catalog unstable i386 SunOS5.10 > Inserting pm_test_deep (all SunOS5.10) into catalog unstable i386 SunOS5.10 > Inserting pm_testdeep (all SunOS5.10) into catalog unstable i386 SunOS5.10 > Inserting pm_hook_lexwrap (all SunOS5.10) into catalog unstable i386 SunOS5.11 > Inserting pm_hooklexwrap (all SunOS5.10) into catalog unstable i386 SunOS5.11 > Inserting pm_log_any (all SunOS5.10) into catalog unstable i386 SunOS5.11 > Inserting pm_logany (all SunOS5.10) into catalog unstable i386 SunOS5.11 > Inserting pm_test_deep (all SunOS5.10) into catalog unstable i386 SunOS5.11 > Inserting pm_testdeep (all SunOS5.10) into catalog unstable i386 SunOS5.11 > Inserting pm_hook_lexwrap (all SunOS5.10) into catalog unstable sparc SunOS5.10 > Inserting pm_hooklexwrap (all SunOS5.10) into catalog unstable sparc SunOS5.10 > Inserting pm_log_any (all SunOS5.10) into catalog unstable sparc SunOS5.10 > Inserting pm_logany (all SunOS5.10) into catalog unstable sparc SunOS5.10 > Inserting pm_test_deep (all SunOS5.10) into catalog unstable sparc SunOS5.10 > Inserting pm_testdeep (all SunOS5.10) into catalog unstable sparc SunOS5.10 > Inserting pm_hook_lexwrap (all SunOS5.10) into catalog unstable sparc SunOS5.11 > Inserting pm_hooklexwrap (all SunOS5.10) into catalog unstable sparc SunOS5.11 > Inserting pm_log_any (all SunOS5.10) into catalog unstable sparc SunOS5.11 > Inserting pm_logany (all SunOS5.10) into catalog unstable sparc SunOS5.11 > Inserting pm_test_deep (all SunOS5.10) into catalog unstable sparc SunOS5.11 > Inserting pm_testdeep (all SunOS5.10) into catalog unstable sparc SunOS5.11 > > And that also worked! :) > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From maciej at opencsw.org Sun May 12 20:52:41 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 12 May 2013 19:52:41 +0100 Subject: [csw-maintainers] Did I just break something? In-Reply-To: <23C29B3A-D54C-43E4-A9E0-1B5608757992@opencsw.org> References: <7FF645B1-A303-4155-934D-057D20352CE2@opencsw.org> <23C29B3A-D54C-43E4-A9E0-1B5608757992@opencsw.org> Message-ID: 2013/5/12 Dagobert Michelsen > > > I guess it re-uploaded pm_log_any because I rebuilt that one just to > > make sure there were no errors so it got a new checksum. > > This will cause troubles as it leads to corrupt allpkgs and other oddities. > Maciej? Yes, it could. Consider this scenario: 1. Build foo-1.0,REV=today-all-CSW.pkg.gz 2. Upload it to 5.9, 5.10, 5.11 3. Rebuild foo-1.0,REV=today-all-CSW.pkg.gz (the same file name, different content / md5 sum) 4. Upload it into 5.11 (replaces the file in allpkgs) This leads to different catalogs referring to 2 different pieces of content under one file name. But one of them was lost. When pkgutil fetches the package, it is able to do so (because the filename is there), but the md5 sum is different, so if you have checking enabled, it looks like the catalog is corrupt. If you can rebuild the package, the fix is easy: upload the same package to all catalogs it needs to be in. We don't currently have a check for this kind of problem in the catalog. But it could be written, it's enough to get the catalog data from URLs like this one: http://buildfarm.opencsw.org/pkgdb/rest/catalogs/unstable/i386/SunOS5.10/ ...and then check the data for >1 md5 sums referring to 1 file name. Maciej From bonivart at opencsw.org Sun May 12 21:01:00 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 12 May 2013 21:01:00 +0200 Subject: [csw-maintainers] Did I just break something? In-Reply-To: References: <7FF645B1-A303-4155-934D-057D20352CE2@opencsw.org> <23C29B3A-D54C-43E4-A9E0-1B5608757992@opencsw.org> Message-ID: On Sun, May 12, 2013 at 8:52 PM, Maciej (Matchek) Blizi?ski wrote: > If you can rebuild the package, the fix is easy: upload the same > package to all catalogs it needs to be in. And that's what I did. See my last post. From dam at opencsw.org Sun May 12 22:32:04 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 12 May 2013 22:32:04 +0200 Subject: [csw-maintainers] Last remaining packages for the openssl migration (take 3) In-Reply-To: References: Message-ID: <51270DB5-6DCB-4654-B9EB-16621E9918A5@opencsw.org> Hi, Am 12.05.2013 um 14:26 schrieb Dagobert Michelsen: > Am 12.05.2013 um 14:22 schrieb Yann Rouillard : >> Here is a new status update about of the libssl update (0.9.8 -> 1.0.0). >> Below is the list of the remaining packages, sorted by maintainer, that need to be updated before we can complete the migration. >> >> Oh my god ! Only 7 packages remaining !! >> >> Benny von Mossner ( Sabbatical ) >> pound and pound2: Dago is still working on this ones. >> >> Dago, have you been able to make some progress ? The recipe is in good shape, isn't it ? What is missing to release the new packages ? > > The binaries are all in place, however, I would like to provide a good SMF recipe and > a reference configuration that enables poundctl via a sane name. I will have some time > next week. > >> >> Ben Walton >> libruby1_9_1_1 and ruby18: Ben is still working on updating these packages (or rather on new ruby 2.0 packages). >> >> Ben, have you been able to make some progress ? Do you need some help ? >> >> Dagobert Michelsen >> libcurl3: blocked by a compilation issue forwarded upstream: http://sourceforge.net/p/curl/bugs/1217/ >> >> No answer from upstream since April, 23rd. I am afraid it might take a long time. >> Dago, do you think that, like for libarchive, you could just release an updated 7.11.2 package so we don't depend on the compilation bug being resolved ? > > Can do. I just uploaded 7.28.1 again now with curl not depending on libcurl2 and libcurl3 any more. Now libcurl2 and libcurl3 need to be dropped. I'll try that tomorrow as I remember long running times of safe_remove. Best regards -- Dago > >> >> Jon Craig: >> ntop: Blocked by the gdbm upgrade and automake issues. >> >> Jon, I noticed Ben committed a fix for the automake problem. Is it ok now ? >> Do you think you will be able to release the new package soon ? >> >> Dominique Laigle: >> erlang: I missed that one previously because it contains no binary linked against libssl. Either it is an error or erland dynamically loads the ssl library with dlsym. >> >> Whatever, I think I will drop this package unless someone objects. Dominique Laigle is not a maintainer anymore, the package has not been updated since 2007 and I am not sure compiling erland under Solaris is a piece of cake. >> So, is someone motivated to take over this package ? > > IIRC, Peter Felecan was working on it. The recipe should be pretty much ready for release IMHO. > > > Best regards > > -- Dago > >> >> >> Thanks in advance for your help on this migration ! >> >> Yann >> >> >> > > -- > "You don't become great by trying to be great, you become great by wanting to do something, > and then doing it so hard that you become great in the process." - xkcd #896 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sun May 12 22:39:44 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 12 May 2013 21:39:44 +0100 Subject: [csw-maintainers] Last remaining packages for the openssl migration (take 3) In-Reply-To: <51270DB5-6DCB-4654-B9EB-16621E9918A5@opencsw.org> References: <51270DB5-6DCB-4654-B9EB-16621E9918A5@opencsw.org> Message-ID: 2013/5/12 Dagobert Michelsen > I just uploaded 7.28.1 again now with curl not depending on libcurl2 and > libcurl3 > any more. Now libcurl2 and libcurl3 need to be dropped. I'll try that > tomorrow > as I remember long running times of safe_remove. > Only the first run is long. Subsequent runs are fast thanks to the local cache. The problem is that these caches go out of date, so you might need to remove the revdep* files. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sun May 12 23:03:56 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 12 May 2013 22:03:56 +0100 Subject: [csw-maintainers] Did I just break something? In-Reply-To: References: <7FF645B1-A303-4155-934D-057D20352CE2@opencsw.org> <23C29B3A-D54C-43E4-A9E0-1B5608757992@opencsw.org> Message-ID: 2013/5/12 Peter Bonivart > > And that's what I did. See my last post. Cool. By the way, we can prevent this problem from occurring by simply refusing to re-upload a file with the same name. That is, if you're willing to endure more Python stacktraces and error messages. Maciej From bonivart at opencsw.org Sun May 12 23:10:01 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 12 May 2013 23:10:01 +0200 Subject: [csw-maintainers] Did I just break something? In-Reply-To: References: <7FF645B1-A303-4155-934D-057D20352CE2@opencsw.org> <23C29B3A-D54C-43E4-A9E0-1B5608757992@opencsw.org> Message-ID: On Sun, May 12, 2013 at 11:03 PM, Maciej (Matchek) Blizi?ski wrote: > By the way, we can prevent this problem from occurring by simply > refusing to re-upload a file with the same name. That is, if you're > willing to endure more Python stacktraces and error messages. Sure, but in this case that was just a side problem. The real problem was the whole operation timed out on me. The only reason I respun one package was because checkpkg said I had file collisions and I wanted to confirm that it was just due to the weird state of things, not in my package. From maciej at opencsw.org Sun May 12 23:13:26 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 12 May 2013 22:13:26 +0100 Subject: [csw-maintainers] Did I just break something? In-Reply-To: References: <7FF645B1-A303-4155-934D-057D20352CE2@opencsw.org> <23C29B3A-D54C-43E4-A9E0-1B5608757992@opencsw.org> Message-ID: 2013/5/12 Peter Bonivart : > Sure, but in this case that was just a side problem. The real problem > was the whole operation timed out on me. That shouldn't happen... If you see this problem again, we'll try to investigate what happened. From maciej at opencsw.org Sun May 12 23:15:50 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 12 May 2013 22:15:50 +0100 Subject: [csw-maintainers] Codebrowser for the build recipes In-Reply-To: References: Message-ID: 2013/5/12 Dagobert Michelsen : > I just noticed that Ohloh has an excellent (and fast!) codebroweser: > http://code.ohloh.net/project?pid=1FjsNz-SmKo&browser=Default&cid=m1lKGYqGZXE&prevcid=&prevDid= > > The URLs are pretty ugly, though. I don't see any files there. Let's say I want to see the gcc4 build file: http://code.ohloh.net/project?pid=1FjsNz-SmKo&prevcid=1&browser=Default&did=pkg%2Fgcc4%2Ftrunk&cid=m1lKGYqGZXE&prevDid= There's only the 'files' directory. "What this program does is not what we need, but it does it very quickly!" From dam at opencsw.org Mon May 13 19:06:24 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 13 May 2013 19:06:24 +0200 Subject: [csw-maintainers] Summercamp Date TBD: 13.-15. September 2013 References: Message-ID: <98FA8CA6-54F6-466E-B9F4-D20F4C6D3D38@opencsw.org> Hi folks, registrations are rolling in and organization is proceeding. So far the following persons have enrolled for participation: Dagobert Michelsen Carsten Grzemba Juraj Lutter Peter Felecan Laurent Blume J?rg Schilling J?rg found out that the legendary Zuse Z3 (the worlds first working programmable, fully automatic computing machine) http://en.wikipedia.org/wiki/Z3_(computer) will be demonstrated on 15. September morning by Horst Zuse, the grandchild of the inventor Konrad Zuse, so the date would be pretty cool. From the list so far all participants are ok with the date, Carsten and me are "maybe", but I can shuffle my dates, so: @Carsten: Would you be ok with that? Maciej? Peter? Ihsan? ? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From Joerg.Schilling at fokus.fraunhofer.de Mon May 13 19:22:30 2013 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Mon, 13 May 2013 19:22:30 +0200 Subject: [csw-maintainers] Summercamp Date TBD: 13.-15. September 2013 In-Reply-To: <98FA8CA6-54F6-466E-B9F4-D20F4C6D3D38@opencsw.org> References: <98FA8CA6-54F6-466E-B9F4-D20F4C6D3D38@opencsw.org> Message-ID: <51912156.TgkFh3OKqjJ4zUCo%Joerg.Schilling@fokus.fraunhofer.de> Dagobert Michelsen wrote: > Hi folks, > > registrations are rolling in and organization is proceeding. So far the following > persons have enrolled for participation: > > Dagobert Michelsen > Carsten Grzemba > Juraj Lutter > Peter Felecan > Laurent Blume > J?rg Schilling > > J?rg found out that the legendary Zuse Z3 (the worlds first working programmable, > fully automatic computing machine) > http://en.wikipedia.org/wiki/Z3_(computer) > will be demonstrated on 15. September morning by Horst Zuse, the grandchild of > the inventor Konrad Zuse, so the date would be pretty cool. From the list so far > all participants are ok with the date, Carsten and me are "maybe", but I can shuffle Hi Dagobert, Horst Zuse is the son of Konrad Zuse and I have to admit that there is no way to see the original Z3 from 1941 as it has been bombed by the "allies" on December 21 1943. There exists a non working but natural looking replique in Munic and a working machine made of current smaller relais. This working machine: http://www.z3-computer.de/ will be presented in Berlin by the son of Konrad Zuse. Host Zuse build this machine in his flat in Berlin 3 years ago. Near by this machine, the Technik Museum has a original replique of the first mechanical programmable computer Z1 (from 1937). http://commons.wikimedia.org/wiki/File:Zuse_Z1-2.jpg If you are interested, I will send a mail to Horst Zuse asking whether he may give an explanation in English. History: Z1 1937 First digital programmable computer (mechanical and unreliable) Z2 1939 Experimental arithmetic block to evaluate relais Z3 1941 First electrical digital programmable computer Z4 1942 First commercially sold programmable computer J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From bwalton at opencsw.org Mon May 13 20:32:47 2013 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 13 May 2013 19:32:47 +0100 Subject: [csw-maintainers] Summercamp Date TBD: 13.-15. September 2013 In-Reply-To: <98FA8CA6-54F6-466E-B9F4-D20F4C6D3D38@opencsw.org> References: <98FA8CA6-54F6-466E-B9F4-D20F4C6D3D38@opencsw.org> Message-ID: I'm still looking at dates, but I think the 15th should work. Thanks -Ben On May 13, 2013 6:06 PM, "Dagobert Michelsen" wrote: > Hi folks, > > registrations are rolling in and organization is proceeding. So far the > following > persons have enrolled for participation: > > Dagobert Michelsen > Carsten Grzemba > Juraj Lutter > Peter Felecan > Laurent Blume > J?rg Schilling > > J?rg found out that the legendary Zuse Z3 (the worlds first working > programmable, > fully automatic computing machine) > http://en.wikipedia.org/wiki/Z3_(computer) > will be demonstrated on 15. September morning by Horst Zuse, the > grandchild of > the inventor Konrad Zuse, so the date would be pretty cool. From the list > so far > all participants are ok with the date, Carsten and me are "maybe", but I > can shuffle > my dates, so: > @Carsten: Would you be ok with that? > > Maciej? Peter? Ihsan? ? > > > Best regards > > -- Dago > > -- > "You don't become great by trying to be great, you become great by wanting > to do something, > and then doing it so hard that you become great in the process." - xkcd > #896 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From grzemba at contac-dt.de Tue May 14 08:04:21 2013 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Tue, 14 May 2013 08:04:21 +0200 Subject: [csw-maintainers] Summercamp Date TBD: 13.-15. September 2013 In-Reply-To: References: <98FA8CA6-54F6-466E-B9F4-D20F4C6D3D38@opencsw.org> Message-ID: yes, I want to see that I can move my task on 13. Sept. Am 13.05.13 schrieb Ben Walton : > > I'm still looking at dates, but I think the 15th should work. > > Thanks > > -Ben > On May 13, 2013 6:06 PM, "Dagobert Michelsen" wrote: > > > Hi folks, > > > > > > > > registrations are rolling in and organization is proceeding. So far the following > > > > persons have enrolled for participation: > > > > > > > > Dagobert Michelsen > > > > Carsten Grzemba > > > > Juraj Lutter > > > > Peter Felecan > > > > Laurent Blume > > > > J?rg Schilling > > > > > > > > J?rg found out that the legendary Zuse Z3 (the worlds first working programmable, > > > > fully automatic computing machine) > > http://en.wikipedia.org/wiki/Z3_(computer) > > > > will be demonstrated on 15. September morning by Horst Zuse, the grandchild of > > > > the inventor Konrad Zuse, so the date would be pretty cool. >From the list so far > > > > all participants are ok with the date, Carsten and me are "maybe", but I can shuffle > > > > my dates, so: > > > > @Carsten: Would you be ok with that? > > > > > > > > Maciej? Peter? Ihsan? ? > > > > > > > > > > > > Best regards > > > > > > -- Dago > > > > > > > > -- > > > > "You don't become great by trying to be great, you become great by wanting to do something, > > > > and then doing it so hard that you become great in the process." - xkcd #896 > > > > > > > > _______________________________________________ > > > > maintainers mailing list > > > > maintainers at lists.opencsw.org > > > > https://lists.opencsw.org/mailman/listinfo/maintainers > > > > .:: This mailing list's archive is public. ::. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Tue May 14 08:52:22 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 14 May 2013 08:52:22 +0200 Subject: [csw-maintainers] Catalog broken ATM Message-ID: <5093FCB5-9169-4AD5-97F1-DF30385C793F@opencsw.org> Hi folks, the current catalog production is broken ATM: ERROR! Dependency CSWlibprotobuf-lite7-gxx of package CSWprotobuf-gxx-dev is missing. ERROR! Dependency CSWlibprotoc7-gxx of package CSWprotobuf-gxx-dev is missing. I will be in meetings the whole morning, so if someone has time please have a look. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Tue May 14 10:51:12 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 14 May 2013 10:51:12 +0200 Subject: [csw-maintainers] Catalog broken ATM In-Reply-To: <5093FCB5-9169-4AD5-97F1-DF30385C793F@opencsw.org> References: <5093FCB5-9169-4AD5-97F1-DF30385C793F@opencsw.org> Message-ID: Hi, Am 14.05.2013 um 08:52 schrieb Dagobert Michelsen : > Hi folks, > > the current catalog production is broken ATM: > > ERROR! Dependency CSWlibprotobuf-lite7-gxx of package CSWprotobuf-gxx-dev is missing. > ERROR! Dependency CSWlibprotoc7-gxx of package CSWprotobuf-gxx-dev is missing. > > I will be in meetings the whole morning, so if someone has time please have a look. This looks mighty strange, like that the pushed package is not the one in the catalog: dam at login [login]:/export/mirror/opencsw-official > ls -1 unstable/*/*/*protobuf*dev* unstable/i386/5.10/protobuf_gxx_dev-2.5.0,REV=2013.04.30-SunOS5.10-i386-CSW.pkg.gz unstable/i386/5.11/protobuf_gxx_dev-2.5.0,REV=2013.04.30-SunOS5.10-i386-CSW.pkg.gz unstable/i386/5.9/protobuf_devel-2.3.0,REV=2010.12.14-SunOS5.9-i386-CSW.pkg.gz unstable/sparc/5.9/protobuf_devel-2.3.0,REV=2010.12.14-SunOS5.9-sparc-CSW.pkg.gz dam at login [login]:/export/mirror/opencsw-official > ls -1 unstable/*/*/*protobuf* unstable/i386/5.10/libprotobuf_lite8_gxx-2.5.0,REV=2013.04.30-SunOS5.10-i386-CSW.pkg.gz unstable/i386/5.10/libprotobuf7_gxx-2.4.1,REV=2012.03.15-SunOS5.10-i386-CSW.pkg.gz unstable/i386/5.10/libprotobuf8_gxx-2.5.0,REV=2013.04.30-SunOS5.10-i386-CSW.pkg.gz unstable/i386/5.10/protobuf_gxx_dev-2.5.0,REV=2013.04.30-SunOS5.10-i386-CSW.pkg.gz unstable/i386/5.10/py_protobuf-2.5.0,REV=2013.04.30-SunOS5.10-all-CSW.pkg.gz unstable/i386/5.11/libprotobuf_lite8_gxx-2.5.0,REV=2013.04.30-SunOS5.10-i386-CSW.pkg.gz unstable/i386/5.11/libprotobuf7_gxx-2.4.1,REV=2012.03.15-SunOS5.10-i386-CSW.pkg.gz unstable/i386/5.11/libprotobuf8_gxx-2.5.0,REV=2013.04.30-SunOS5.10-i386-CSW.pkg.gz unstable/i386/5.11/protobuf_gxx_dev-2.5.0,REV=2013.04.30-SunOS5.10-i386-CSW.pkg.gz unstable/i386/5.11/py_protobuf-2.5.0,REV=2013.04.30-SunOS5.10-all-CSW.pkg.gz unstable/i386/5.9/libprotobuf_lite6-2.3.0,REV=2010.12.14-SunOS5.9-i386-CSW.pkg.gz unstable/i386/5.9/libprotobuf6-2.3.0,REV=2010.12.14-SunOS5.9-i386-CSW.pkg.gz unstable/i386/5.9/protobuf_devel-2.3.0,REV=2010.12.14-SunOS5.9-i386-CSW.pkg.gz unstable/i386/5.9/protobuf-2.3.0,REV=2010.12.14-SunOS5.9-i386-CSW.pkg.gz unstable/i386/5.9/py_protobuf-2.3.0,REV=2010.12.14-SunOS5.9-all-CSW.pkg.gz unstable/sparc/5.10/libprotobuf7_gxx-2.4.1,REV=2012.03.15-SunOS5.10-sparc-CSW.pkg.gz unstable/sparc/5.10/py_protobuf-2.5.0,REV=2013.04.30-SunOS5.10-all-CSW.pkg.gz unstable/sparc/5.11/libprotobuf7_gxx-2.4.1,REV=2012.03.15-SunOS5.10-sparc-CSW.pkg.gz unstable/sparc/5.11/py_protobuf-2.5.0,REV=2013.04.30-SunOS5.10-all-CSW.pkg.gz unstable/sparc/5.9/libprotobuf_lite6-2.3.0,REV=2010.12.14-SunOS5.9-sparc-CSW.pkg.gz unstable/sparc/5.9/libprotobuf6-2.3.0,REV=2010.12.14-SunOS5.9-sparc-CSW.pkg.gz unstable/sparc/5.9/protobuf_devel-2.3.0,REV=2010.12.14-SunOS5.9-sparc-CSW.pkg.gz unstable/sparc/5.9/protobuf-2.3.0,REV=2010.12.14-SunOS5.9-sparc-CSW.pkg.gz unstable/sparc/5.9/py_protobuf-2.3.0,REV=2010.12.14-SunOS5.9-all-CSW.pkg.gz Maciej, anything strange happened on uploading? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Tue May 14 10:51:31 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 14 May 2013 09:51:31 +0100 Subject: [csw-maintainers] Catalog broken ATM In-Reply-To: <5093FCB5-9169-4AD5-97F1-DF30385C793F@opencsw.org> References: <5093FCB5-9169-4AD5-97F1-DF30385C793F@opencsw.org> Message-ID: 2013/5/14 Dagobert Michelsen > ERROR! Dependency CSWlibprotobuf-lite7-gxx of package CSWprotobuf-gxx-dev > is missing. > ERROR! Dependency CSWlibprotoc7-gxx of package CSWprotobuf-gxx-dev is > missing. > > I will be in meetings the whole morning, so if someone has time please > have a look. > The catalog in question is kiel. I'm looking into it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Tue May 14 10:53:36 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 14 May 2013 10:53:36 +0200 Subject: [csw-maintainers] Catalog broken ATM In-Reply-To: References: <5093FCB5-9169-4AD5-97F1-DF30385C793F@opencsw.org> Message-ID: Hi Maciej, Am 14.05.2013 um 10:51 schrieb Maciej (Matchek) Blizi?ski : >> 2013/5/14 Dagobert Michelsen >> ERROR! Dependency CSWlibprotobuf-lite7-gxx of package CSWprotobuf-gxx-dev is missing. >> ERROR! Dependency CSWlibprotoc7-gxx of package CSWprotobuf-gxx-dev is missing. > > The catalog in question is kiel. I'm looking into it. I think I need better checks in our monitoring, there is much too much manual inspection to find issues. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Tue May 14 10:53:44 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 14 May 2013 09:53:44 +0100 Subject: [csw-maintainers] Catalog broken ATM In-Reply-To: References: <5093FCB5-9169-4AD5-97F1-DF30385C793F@opencsw.org> Message-ID: 2013/5/14 Dagobert Michelsen > dam at login [login]:/export/mirror/opencsw-official > ls -1 > unstable/*/*/*protobuf*dev* > Not unstable. Kiel. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Tue May 14 11:00:22 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 14 May 2013 10:00:22 +0100 Subject: [csw-maintainers] Catalog broken ATM In-Reply-To: References: <5093FCB5-9169-4AD5-97F1-DF30385C793F@opencsw.org> Message-ID: 2013/5/14 Dagobert Michelsen > > > The catalog in question is kiel. I'm looking into it. > > I think I need better checks in our monitoring, there is much too much > manual inspection to find issues. I was talking to Peter Bonivart on IRC last night, trying to convince him to write a REST enabled version of chkcat. Maciej From ihsan at opencsw.org Tue May 14 11:05:14 2013 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuIERvxJ9hbg==?=) Date: Tue, 14 May 2013 11:05:14 +0200 Subject: [csw-maintainers] Summercamp Date TBD: 13.-15. September 2013 In-Reply-To: <98FA8CA6-54F6-466E-B9F4-D20F4C6D3D38@opencsw.org> References: <98FA8CA6-54F6-466E-B9F4-D20F4C6D3D38@opencsw.org> Message-ID: <5191FE4A.7030609@opencsw.org> Hi Dago, On 05/13/2013 07:06 PM, Dagobert Michelsen wrote: > J?rg found out that the legendary Zuse Z3 (the worlds first working programmable, > fully automatic computing machine) > http://en.wikipedia.org/wiki/Z3_(computer) > will be demonstrated on 15. September morning by Horst Zuse, the grandchild of > the inventor Konrad Zuse, so the date would be pretty cool. From the list so far > all participants are ok with the date, Carsten and me are "maybe", but I can shuffle > my dates, so: Cool! > Maciej? Peter? Ihsan? ? 13-15 September is fine for me. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From maciej at opencsw.org Tue May 14 14:57:47 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 14 May 2013 13:57:47 +0100 Subject: [csw-maintainers] Catalog broken ATM In-Reply-To: References: <5093FCB5-9169-4AD5-97F1-DF30385C793F@opencsw.org> Message-ID: The root cause was a bug in the integration script. The catalogs are now corrected and pushed out. I'm working on fixing the bug. From maciej at opencsw.org Tue May 14 17:45:11 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 14 May 2013 16:45:11 +0100 Subject: [csw-maintainers] Catalog broken ATM In-Reply-To: References: <5093FCB5-9169-4AD5-97F1-DF30385C793F@opencsw.org> Message-ID: 2013/5/14 Maciej (Matchek) Blizi?ski : > The root cause was a bug in the integration script. The catalogs are > now corrected and pushed out. I'm working on fixing the bug. The bug is fixed: https://sourceforge.net/apps/trac/gar/changeset/21072 The change includes cleanup changes, which I should have separated into another patch, sorry about that. The fix is a blank line in the template, which ensures that different catalog names end up on different lines and are not joined together in one line. Maciej From jh at opencsw.org Wed May 15 09:15:22 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Wed, 15 May 2013 09:15:22 +0200 Subject: [csw-maintainers] [csw-buildfarm] Problem during upload again In-Reply-To: References: Message-ID: <5193360A.6010007@opencsw.org> Forward from buildfarm.... Am 14.05.13 22:12, schrieb Peter Bonivart: > Ran it again, no error. > > On Tue, May 14, 2013 at 10:00 PM, Peter Bonivart wrote: >> bonivart at login[build.2013-05-14]$ csw-upload-pkg pm_* >> Processing 3 file(s). Please wait. >> Uploading 'pm_html_mason-1.51,REV=2013.05.14-SunOS5.10-all-CSW.pkg.gz' >> Uploading 'pm_htmlmason-1.51,REV=2013.05.14-SunOS5.10-all-CSW.pkg.gz' >> Uploading 'pm_ppix_regexp-0.034,REV=2013.05.14-SunOS5.10-all-CSW.pkg.gz' >> Checking 3 package(s) against catalog unstable sparc SunOS5.10 >> Checking 3 package(s) against catalog unstable i386 SunOS5.10 >> Checking 3 package(s) against catalog unstable sparc SunOS5.11 >> Checking 3 package(s) against catalog unstable i386 SunOS5.11 >> All checks successful. Proceeding. >> Inserting pm_html_mason (all SunOS5.10) into catalog unstable i386 SunOS5.10 >> Inserting pm_htmlmason (all SunOS5.10) into catalog unstable i386 SunOS5.10 >> CRITICAL:root:Response: 500 >> >> 200 Continue >> >>

Continue

>>

The server encountered an internal error or >> misconfiguration and was unable to complete >> your request.

>>

Please contact the server administrator, >> dam at opencsw.org and inform them of the time the error occurred, >> and anything you might have done that may have >> caused the error.

>>

More information about this error may be available >> in the server error log.

>> >> >> INFO:root:Retry, exception: >> http://buildfarm.opencsw.org/releases/catalogs/unstable/i386/SunOS5.10/e5bcb76cbce9bbc7d9f8bcaad5485422/ >> - HTTP code: 500 >> Inserting pm_ppix_regexp (all SunOS5.10) into catalog unstable i386 SunOS5.10 >> Inserting pm_html_mason (all SunOS5.10) into catalog unstable i386 SunOS5.11 >> Inserting pm_htmlmason (all SunOS5.10) into catalog unstable i386 SunOS5.11 >> Inserting pm_ppix_regexp (all SunOS5.10) into catalog unstable i386 SunOS5.11 >> Inserting pm_html_mason (all SunOS5.10) into catalog unstable sparc SunOS5.10 >> Inserting pm_htmlmason (all SunOS5.10) into catalog unstable sparc SunOS5.10 >> Inserting pm_ppix_regexp (all SunOS5.10) into catalog unstable sparc SunOS5.10 >> Inserting pm_html_mason (all SunOS5.10) into catalog unstable sparc SunOS5.11 >> Inserting pm_htmlmason (all SunOS5.10) into catalog unstable sparc SunOS5.11 >> Inserting pm_ppix_regexp (all SunOS5.10) into catalog unstable sparc SunOS5.11 >> bonivart at login[build.2013-05-14]$ > _______________________________________________ > buildfarm mailing list > buildfarm at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/buildfarm > From maciej at opencsw.org Wed May 15 10:32:57 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 15 May 2013 09:32:57 +0100 Subject: [csw-maintainers] [csw-buildfarm] Problem during upload again In-Reply-To: <5193360A.6010007@opencsw.org> References: <5193360A.6010007@opencsw.org> Message-ID: 2013/5/15 Jan Holzhueter : > Forward from buildfarm.... > > > Am 14.05.13 22:12, schrieb Peter Bonivart: >> Ran it again, no error. I was working on the backend, so you caught one of the short time windows when upload wasn't working. Should I send email to the list when I'm working on the buildfarm? Maciej From maciej at opencsw.org Wed May 15 10:40:34 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 15 May 2013 09:40:34 +0100 Subject: [csw-maintainers] Faster catalog generation In-Reply-To: References: Message-ID: I spent some time yesterday working on the buildfarm[1], and managed to remove one bottleneck and cut down the catalog generation time from ~80 minutes to ~32 minutes. The new (and current) bottleneck seems to be what I described in [2]: mass unlinking and relinking of files. There's also a new HTTP endpoint: /rest/catalogs/([^/]+)/(sparc|i386)/(SunOS[^/]+)/for-generation/ (Prefix: http://buildfarm.opencsw.org/pkgdb/) It's quite quick to return and returns all information necessary to generate a catalog. Maciej [1] https://sourceforge.net/apps/trac/gar/changeset/21086 [2] http://lists.opencsw.org/pipermail/maintainers/2013-May/018016.html From bonivart at opencsw.org Wed May 15 10:41:45 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 15 May 2013 10:41:45 +0200 Subject: [csw-maintainers] [csw-buildfarm] Problem during upload again In-Reply-To: References: <5193360A.6010007@opencsw.org> Message-ID: On Wed, May 15, 2013 at 10:32 AM, Maciej (Matchek) Blizi?ski wrote: > I was working on the backend, so you caught one of the short time > windows when upload wasn't working. Should I send email to the list > when I'm working on the buildfarm? Maybe you should send one when you're not working on it. ;) /peter From maciej at opencsw.org Wed May 15 10:57:32 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 15 May 2013 09:57:32 +0100 Subject: [csw-maintainers] [csw-buildfarm] Problem during upload again In-Reply-To: References: <5193360A.6010007@opencsw.org> Message-ID: 2013/5/15 Peter Bonivart : > On Wed, May 15, 2013 at 10:32 AM, Maciej (Matchek) Blizi?ski > wrote: >> I was working on the backend, so you caught one of the short time >> windows when upload wasn't working. Should I send email to the list >> when I'm working on the buildfarm? > > Maybe you should send one when you're not working on it. ;) Heh. :-) By the way, you might have not noticed that your first run actually succeeded. You saw an error message, so you didn't check the $? variable or the catalog content, but I bet you ?100 it was correct. Why? Because of the new retry code. I noticed that on my VM, when running a lot of HTTP queries for a long time, a query might occasionally fail with no obvious reason. Since all RESTful calls are idempotent, it's safe to retry, so I added some rudimentary retry logic a few weeks ago. In your first run, one of the queries failed with a HTTP 500, but it waited a few seconds, tried again, and the retried run has succeeded, so the process could move forward. So this failure was so transient that didn't even break your csw-upload-pkg run! Yay REST + idempotence. Maciej From bonivart at opencsw.org Wed May 15 11:17:36 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 15 May 2013 11:17:36 +0200 Subject: [csw-maintainers] [csw-buildfarm] Problem during upload again In-Reply-To: References: <5193360A.6010007@opencsw.org> Message-ID: On Wed, May 15, 2013 at 10:57 AM, Maciej (Matchek) Blizi?ski wrote: > By the way, you might have not noticed that your first run actually > succeeded. You saw an error message, so you didn't check the $? > variable or the catalog content, but I bet you ?100 it was correct. > > Why? Because of the new retry code. I noticed that on my VM, when > running a lot of HTTP queries for a long time, a query might > occasionally fail with no obvious reason. Since all RESTful calls are > idempotent, it's safe to retry, so I added some rudimentary retry > logic a few weeks ago. In your first run, one of the queries failed > with a HTTP 500, but it waited a few seconds, tried again, and the > retried run has succeeded, so the process could move forward. So this > failure was so transient that didn't even break your csw-upload-pkg > run! Yay REST + idempotence. I did notice the text about retry but I wasn't sure about how successful that was so I re-ran the whole set. It looked to me like the retry also got a code 500 but maybe it was just that it was called with that error or something. >> INFO:root:Retry, exception: >> http://buildfarm.opencsw.org/releases/catalogs/unstable/i386/SunOS5.10/e5bcb76cbce9bbc7d9f8bcaad5485422/ >> - HTTP code: 500 From maciej at opencsw.org Wed May 15 11:20:33 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 15 May 2013 10:20:33 +0100 Subject: [csw-maintainers] [csw-buildfarm] Problem during upload again In-Reply-To: References: <5193360A.6010007@opencsw.org> Message-ID: 2013/5/15 Peter Bonivart : > I did notice the text about retry but I wasn't sure about how > successful that was so I re-ran the whole set. It looked to me like > the retry also got a code 500 but maybe it was just that it was called > with that error or something. The other 500 was probably me as well. From maciej at opencsw.org Wed May 15 14:32:09 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 15 May 2013 13:32:09 +0100 Subject: [csw-maintainers] Call for projects Message-ID: Hi guys, I'm looking for ideas for coding projects at OpenCSW. We have quite a lot of low hanging fruit, that is projects that can be completed in limited time like a weekend of a few evenings. We often talk about our grand plans, but these plans have to translate to small/medium size steps, or they will not get completed. I've started a new page and written up a few ideas I had: http://wiki.opencsw.org/projects-available If you have more ideas for projects that are well defined and small/medium in scale, please describe them! If you have a larger project in mind, try to split it up to the right size individual steps. Maciej From laurent at opencsw.org Fri May 17 00:35:30 2013 From: laurent at opencsw.org (Laurent Blume) Date: Fri, 17 May 2013 00:35:30 +0200 Subject: [csw-maintainers] [csw-devel] SF.net SVN: gar:[21121] csw/mgar/pkg/mysql5/branches/mysql-5.5.x In-Reply-To: References: Message-ID: <51955F32.5040903@opencsw.org> With this one, I'm introducing some changes to the way MySQL 5.5 is built to make it closer to how they make the official builds, which vary according to arch and bitness (though some of their methods seem a little dubious). There should however not be any change in the look and feel. And I've fixed the test so at least it fully passes "make test" now. I'm planning to introduce it very soon because I need it. I'll test for S10 on x86 and sparc. If anybody notices some unwelcome side-effect, please tell me. Laurent On 2013-05-16 6:08 PM, lblume at users.sourceforge.net wrote: > Revision: 21121 > http://gar.svn.sourceforge.net/gar/?rev=21121&view=rev > Author: lblume > Date: 2013-05-16 16:08:12 +0000 (Thu, 16 May 2013) > Log Message: > ----------- > mysql5/branches/mysql-5.5.x: Use build options close to those of the official build; Fix the make test > > Modified Paths: > -------------- > csw/mgar/pkg/mysql5/branches/mysql-5.5.x/Makefile > > Added Paths: > ----------- > csw/mgar/pkg/mysql5/branches/mysql-5.5.x/files/0005_my_vsnprintf-t_fails_bug_62572.patch > > Modified: csw/mgar/pkg/mysql5/branches/mysql-5.5.x/Makefile > =================================================================== > --- csw/mgar/pkg/mysql5/branches/mysql-5.5.x/Makefile 2013-05-16 15:47:41 UTC (rev 21120) > +++ csw/mgar/pkg/mysql5/branches/mysql-5.5.x/Makefile 2013-05-16 16:08:12 UTC (rev 21121) > @@ -28,9 +28,6 @@ > GARCOMPILER = SOS12U3 > endif > > -#Since Solaris9 does not have sos12u3 use lower opt > -OPT_FLAGS_SOS12_i386 = -xO2 > - > # There is some assembler code, which doesn't work on sparcv8, and I don't see > # an easy way to switch it off. > ISA_DEFAULT_sparc-5.9 = sparcv8plus > @@ -52,9 +49,21 @@ > (Structured Query Language) database server. > endef > > -EXTRA_CFLAGS += -mt -D__EXTENSIONS__ > -EXTRA_CXXFLAGS += -mt -D__EXTENSIONS__ > +# Those options follow those of the official builds > +EXTRA_CFLAGS-sparc = -Xa -xstrconst > +EXTRA_CFLAGS-i386 = -fsimple=1 -ftrap=%none -nofstore -xbuiltin=%all -xlibmil -xlibmopt > +EXTRA_CXXFLAGS-sparc = -noex > +EXTRA_CXXFLAGS-i386 = -fsimple=1 -ftrap=%none -nofstore -xbuiltin=%all -features=no%except -xlibmil -xlibmopt > +EXTRA_CFLAGS += $(EXTRA_CFLAGS-$(GARCH)) -g -mt -KPIC -DDBUG_OFF -DHAVE_OPENSSL -DMULTI_THREADED -lm > +EXTRA_CXXFLAGS += $(EXTRA_CXXFLAGS-$(GARCH)) -g0 -mt -KPIC -DDBUG_OFF -DHAVE_OPENSSL -DMULTI_THREADED -lm > > +# The official build used -xO2 on 32 bit x86, -xO3 for 64 bit > +# Use that for all builds > +OPT_FLAGS_SOS-32 = -xO2 > +OPT_FLAGS_SOS-64 = -xO3 > +OPT_FLAGS_SOS = $(OPT_FLAGS_SOS-$(MEMORYMODEL)) > + > + > INITSMF = $(sysconfdir)/init\.d/csw$(NAME) > > # Existing databases are in this location > @@ -83,6 +92,9 @@ > PATCHFILES += 0003-WHY-IS-CMAKE-TRYING-TO-BE-SMARTER-THAN-ME.patch > PATCHFILES += 0003-Use-bash-for-mysqld_safe.patch > > +# Cf http://bugs.mysql.com/bug.php?id=62572 > +PATCHFILES += 0005_my_vsnprintf-t_fails_bug_62572.patch > + > PACKAGES += CSWlibmysqlclient$(MYSQL_LIB_VER) > PKGFILES_CSWlibmysqlclient$(MYSQL_LIB_VER) += $(call baseisadirs,$(libdir),libmysqlclient\.so\.$(MYSQL_LIB_VER)(\.\d+)*) > SPKG_DESC_CSWlibmysqlclient$(MYSQL_LIB_VER) += MySQL $(BASE_VERSION) client library, libmysqlclient.so.$(MYSQL_LIB_VER) > @@ -189,30 +201,6 @@ > BUILD_DEP_PKGS += CSWcmake > BUILD_DEP_PKGS += CSWbison > > -# Set ./configure options > -CONFIGURE_ARGS = $(DIRPATHS) > -CONFIGURE_ARGS += --disable-assembler > -# Why not have a docs package? > -# CONFIGURE_ARGS += --without-docs > -CONFIGURE_ARGS += --enable-local-infile > -CONFIGURE_ARGS += --with-charset=utf8 > -CONFIGURE_ARGS += --with-extra-charsets=all > -CONFIGURE_ARGS += --with-low-memory > -CONFIGURE_ARGS += --with-pthread > -CONFIGURE_ARGS += --with-readline > -CONFIGURE_ARGS += --with-zlib-dir=$(BUILD_PREFIX) > -CONFIGURE_ARGS += --with-ssl=$(BUILD_PREFIX) > -CONFIGURE_ARGS += --with-plugins=max-no-ndb > -CONFIGURE_ARGS += --with-comment="(OpenCSW)" > -CONFIGURE_ARGS += --with-mysqld-user=mysql > -CONFIGURE_ARGS += --with-fast-mutexes > -CONFIGURE_ARGS += --with-libwrap > -CONFIGURE_ARGS += --with-mysqld-libs=-lmtmalloc > -CONFIGURE_ARGS += --with-big-tables > -CONFIGURE_ARGS += --enable-thread-safe-client > -CONFIGURE_ARGS_DBG = --with-debug > -CONFIGURE_ARGS += $(CONFIGURE_ARGS_$(GARFLAVOR)) > - > # http://forge.mysql.com/wiki/Autotools_to_CMake_Transition_Guide > CMAKE_ARGS += -DCMAKE_INSTALL_PREFIX=$(prefix) > CMAKE_ARGS += -DINSTALL_LAYOUT=RPM > @@ -220,36 +208,46 @@ > CMAKE_ARGS += -DSYSCONFDIR=$(sysconfdir) > CMAKE_ARGS += -DINSTALL_BINDIR=$(subst $(prefix)/,,$(bindir)) > CMAKE_ARGS += -DINSTALL_SBINDIR=$(subst $(prefix)/,,$(libexecdir)) > -# CMAKE_ARGS += -DINSTALL_MANDIR=$(subst $(prefix)/,,$(mandir)) > CMAKE_ARGS += -DINSTALL_LIBDIR=$(subst $(prefix)/,,$(libdir)) > CMAKE_ARGS += -DINSTALL_PLUGINDIR=$(subst $(prefix)/,,$(libdir))/$(NAME)/plugin > -CMAKE_ARGS += -DWITH_READLINE=1 > CMAKE_ARGS += -DWITH_LIBWRAP=1 > CMAKE_ARGS += -DWITH_SSL=system > CMAKE_ARGS += -DWITH_ZLIB=system > CMAKE_ARGS += -DDEFAULT_CHARSET=utf8 > CMAKE_ARGS += -DDEFAULT_COLLATION=utf8_general_ci > CMAKE_ARGS += -DWITH_COMMENT='OpenCSW' > -CMAKE_ARGS += -DCMAKE_C_FLAGS="$(CFLAGS)" > -CMAKE_ARGS += -DCMAKE_CXX_FLAGS="$(CXXFLAGS)" > CMAKE_ARGS += -DBUILD_CONFIG=mysql_release > -# CMAKE_ARGS += -DOPENSSL_INCLUDE_DIR="$(includedir)" > -# CMAKE_ARGS += -DCMAKE_LIBRARY_PATH="$(libdir)" > -# CMAKE_ARGS += -DCMAKE_PREFIX_PATH="$(prefix)" > CMAKE_ARGS += -DOPENSSL_ROOT_DIR=$(prefix) > -# CMAKE_ARGS += -DOPENSSL_SSL_LIBRARIES=$(libdir)/libssl.so > -# CMAKE_ARGS += -DOPENSSL_CRYPTO_LIBRARIES=$(libdir)/libcrypto.so > -CMAKE_ARGS += -DCMAKE_INCLUDE_PATH="$(includedir)" > +CMAKE_ARGS += -DCMAKE_C_FLAGS="$(CFLAGS)" > +CMAKE_ARGS += -DCMAKE_CXX_FLAGS="$(CXXFLAGS)" > CMAKE_ARGS += -DCMAKE_LIBRARY_PATH="$(libdir)" > -CMAKE_ARGS += "-DCMAKE_C_FLAGS=$(CFLAGS)" > -CMAKE_ARGS += "-DCMAKE_CXX_FLAGS=$(CXXFLAGS)" > +CMAKE_ARGS += -DCMAKE_PREFIX_PATH="$(prefix)" > +CMAKE_ARGS += -DCMAKE_INCLUDE_PATH="$(includedir)" > CMAKE_ARGS += -DCMAKE_VERBOSE_MAKEFILE=ON > +CMAKE_ARGS += -DBISON_EXECUTABLE=/opt/csw/bin/bison > > -# TODO: Make the tests pass. They don't at the moment. > -SKIPTEST ?= 1 > -TEST_SCRIPTS = custom > -TEST_TARGETS = check > +# The line below come from the official MySQL build configuration > +CMAKE_ARGS += "-DENABLED_PROFILING:BOOL=ON" > +CMAKE_ARGS += "-DENABLE_DEBUG_SYNC:BOOL=ON" > +CMAKE_ARGS += "-DENABLE_DTRACE:BOOL=ON" > +CMAKE_ARGS += "-DENABLE_GCOV:BOOL=OFF" > +CMAKE_ARGS += "-DWITH_ARCHIVE_STORAGE_ENGINE:BOOL=ON" > +CMAKE_ARGS += "-DWITH_BLACKHOLE_STORAGE_ENGINE:BOOL=ON" > +CMAKE_ARGS += "-DWITH_DEBUG:BOOL=OFF" > +CMAKE_ARGS += "-DWITH_EMBEDDED_SERVER:BOOL=ON" > +CMAKE_ARGS += "-DWITH_EXAMPLE_STORAGE_ENGINE:BOOL=OFF" > +CMAKE_ARGS += "-DWITH_EXTRA_CHARSETS:STRING=all" > +CMAKE_ARGS += "-DWITH_FEDERATED_STORAGE_ENGINE:BOOL=ON" > +CMAKE_ARGS += "-DWITH_INNOBASE_STORAGE_ENGINE:BOOL=ON" > +CMAKE_ARGS += "-DWITH_LIBEDIT:BOOL=OFF" > +CMAKE_ARGS += "-DWITH_PARTITION_STORAGE_ENGINE:BOOL=ON" > +CMAKE_ARGS += "-DWITH_PERFSCHEMA_STORAGE_ENGINE:BOOL=ON" > +CMAKE_ARGS += "-DWITH_PIC:BOOL=ON" > +CMAKE_ARGS += "-DWITH_READLINE:BOOL=ON" > +CMAKE_ARGS += "-DWITH_UNIT_TESTS:BOOL=ON" > +CMAKE_ARGS += "-DWITH_VALGRIND:BOOL=OFF" > > + > USERGROUP = /etc/opt/csw/pkg/CSW$(NAME)/cswusergroup > > PROTOTYPE_MODIFIERS = dbdir > > Added: csw/mgar/pkg/mysql5/branches/mysql-5.5.x/files/0005_my_vsnprintf-t_fails_bug_62572.patch > =================================================================== > --- csw/mgar/pkg/mysql5/branches/mysql-5.5.x/files/0005_my_vsnprintf-t_fails_bug_62572.patch (rev 0) > +++ csw/mgar/pkg/mysql5/branches/mysql-5.5.x/files/0005_my_vsnprintf-t_fails_bug_62572.patch 2013-05-16 16:08:12 UTC (rev 21121) > @@ -0,0 +1,14 @@ > +--- a/unittest/mysys/my_vsnprintf-t.c.original lun. mars 25 14:14:58 2013 > ++++ b/unittest/mysys/my_vsnprintf-t.c jeu. mai 16 15:35:30 2013 > +@@ -31,7 +31,11 @@ > + > + int main(void) > + { > ++#if defined (__GNUC__) > + plan(58); > ++#else > ++ plan(57); > ++#endif > + > + test1("Constant string", > + "Constant string"); > > This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. > > _______________________________________________ > devel mailing list > devel at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/devel > From ihsan at opencsw.org Sat May 18 09:20:11 2013 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Sat, 18 May 2013 09:20:11 +0200 Subject: [csw-maintainers] Mail / Web outage Message-ID: <51972BAB.50300@opencsw.org> Good morning, I'm very sorry for the recent outage. During the live upgrade to Solaris 10 update 11 I've run into troubles. I will install patches now and do another reboot tomorrow. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Sat May 18 19:26:17 2013 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Sat, 18 May 2013 19:26:17 +0200 Subject: [csw-maintainers] Mail / Web outage In-Reply-To: <51972BAB.50300@opencsw.org> References: <51972BAB.50300@opencsw.org> Message-ID: <5197B9B9.5080209@opencsw.org> Am 18.05.2013 09:20, schrieb ?hsan Do?an: > I will install patches now and do another reboot tomorrow. The patching round was faster then I thought. The mail/web service might not run during the next 120 minutes. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Sun May 19 00:42:23 2013 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Sun, 19 May 2013 00:42:23 +0200 Subject: [csw-maintainers] Mail / Web outage In-Reply-To: <5197B9B9.5080209@opencsw.org> References: <51972BAB.50300@opencsw.org> <5197B9B9.5080209@opencsw.org> Message-ID: <519803CF.9040504@opencsw.org> Am 18.05.2013 19:26, schrieb ?hsan Do?an: >> I will install patches now and do another reboot tomorrow. > > The patching round was faster then I thought. The mail/web service might > not run during the next 120 minutes. The Live Upgrade reboot took 5 hours! Well, everything is now up to date again. Sorry for the outage and thanks for the patience. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Sun May 19 16:49:29 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 19 May 2013 16:49:29 +0200 Subject: [csw-maintainers] I broke checkpkg Message-ID: Hi folks, looks like there is a problem with the new libmagic and its Python module: > AttributeError: ld.so.1: python2.6: fatal: magic_open: can't find symbol I am looking into it. Best regads -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Sun May 19 16:58:02 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 19 May 2013 16:58:02 +0200 Subject: [csw-maintainers] I broke checkpkg In-Reply-To: References: Message-ID: <037FDB86-A8AB-4773-98DE-157EEF3EC6DF@opencsw.org> Hi folks, Am 19.05.2013 um 16:49 schrieb Dagobert Michelsen : > looks like there is a problem with the new libmagic and its Python module: > >> AttributeError: ld.so.1: python2.6: fatal: magic_open: can't find symbol > > I am looking into it. This is very strange, the needed library is there and everything looks good: > dam at unstable10s [unstable10s]:/home/dam/mgar/pkg/rcs/trunk > ls -l /opt/csw/lib/python/site-packages/need-libmagic > lrwxrwxrwx 1 root root 19 May 19 16:30 /opt/csw/lib/python/site-packages/need-libmagic -> ../../libmagic.so.1 > dam at unstable10s [unstable10s]:/home/dam/mgar/pkg/rcs/trunk > ldd -r /opt/csw/lib/python/site-packages/need-libmagic > libpcreposix.so.0 => /opt/csw/lib/sparcv8/libpcreposix.so.0 > libz.so.1 => /opt/csw/lib/sparcv8plus+vis/libz.so.1 > libc.so.1 => /lib/libc.so.1 > libpcre.so.1 => /opt/csw/lib/sparcv8/libpcre.so.1 > /platform/SUNW,SPARC-Enterprise-T5220/lib/libc_psr.so.1 > libm.so.2 => /lib/libm.so.2 Is there some special Python logic I am missing? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Sun May 19 17:04:36 2013 From: maciej at opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?=) Date: Sun, 19 May 2013 16:04:36 +0100 Subject: [csw-maintainers] I broke checkpkg In-Reply-To: <037FDB86-A8AB-4773-98DE-157EEF3EC6DF@opencsw.org> References: <037FDB86-A8AB-4773-98DE-157EEF3EC6DF@opencsw.org> Message-ID: <20130519150436.GA10392@cotton.home.blizinski.pl> On Sun, May 19, 2013 at 04:58:02PM +0200, Dagobert Michelsen wrote: > Hi folks, > > Am 19.05.2013 um 16:49 schrieb Dagobert Michelsen : > > looks like there is a problem with the new libmagic and its Python module: > > > >> AttributeError: ld.so.1: python2.6: fatal: magic_open: can't find symbol > > > > I am looking into it. > > > This is very strange, the needed library is there and everything looks good: > > > dam at unstable10s [unstable10s]:/home/dam/mgar/pkg/rcs/trunk > ls -l /opt/csw/lib/python/site-packages/need-libmagic > > lrwxrwxrwx 1 root root 19 May 19 16:30 /opt/csw/lib/python/site-packages/need-libmagic -> ../../libmagic.so.1 > > dam at unstable10s [unstable10s]:/home/dam/mgar/pkg/rcs/trunk > ldd -r /opt/csw/lib/python/site-packages/need-libmagic > > libpcreposix.so.0 => /opt/csw/lib/sparcv8/libpcreposix.so.0 > > libz.so.1 => /opt/csw/lib/sparcv8plus+vis/libz.so.1 > > libc.so.1 => /lib/libc.so.1 > > libpcre.so.1 => /opt/csw/lib/sparcv8/libpcre.so.1 > > /platform/SUNW,SPARC-Enterprise-T5220/lib/libc_psr.so.1 > > libm.so.2 => /lib/libm.so.2 > > Is there some special Python logic I am missing? The "need-libmagic" thing not relevant at all. I just put it there to hint checkpkg that it should make the package with Python files depend on the package with the shared library. But it has no relevance to the module working or not. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From maciej at opencsw.org Sun May 19 17:10:20 2013 From: maciej at opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?=) Date: Sun, 19 May 2013 16:10:20 +0100 Subject: [csw-maintainers] Mail / Web outage In-Reply-To: <519803CF.9040504@opencsw.org> References: <51972BAB.50300@opencsw.org> <5197B9B9.5080209@opencsw.org> <519803CF.9040504@opencsw.org> Message-ID: <20130519151020.GA10735@cotton.home.blizinski.pl> On Sun, May 19, 2013 at 12:42:23AM +0200, ?hsan?Do?an wrote: > Am 18.05.2013 19:26, schrieb ?hsan Do?an: > > >> I will install patches now and do another reboot tomorrow. > > > > The patching round was faster then I thought. The mail/web service might > > not run during the next 120 minutes. > > The Live Upgrade reboot took 5 hours! > > Well, everything is now up to date again. Sorry for the outage and > thanks for the patience. Thanks for handling the upgrade! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From dam at opencsw.org Sun May 19 17:54:12 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 19 May 2013 17:54:12 +0200 Subject: [csw-maintainers] I broke checkpkg In-Reply-To: <20130519150436.GA10392@cotton.home.blizinski.pl> References: <037FDB86-A8AB-4773-98DE-157EEF3EC6DF@opencsw.org> <20130519150436.GA10392@cotton.home.blizinski.pl> Message-ID: <4E469C4D-8B34-4588-ABC3-74C3ADC1A121@opencsw.org> Hi, Am 19.05.2013 um 17:04 schrieb Maciej Blizi?ski : > On Sun, May 19, 2013 at 04:58:02PM +0200, Dagobert Michelsen wrote: >> Am 19.05.2013 um 16:49 schrieb Dagobert Michelsen : >>> looks like there is a problem with the new libmagic and its Python module: >>> >>>> AttributeError: ld.so.1: python2.6: fatal: magic_open: can't find symbol >>> >>> I am looking into it. >> >> >> This is very strange, the needed library is there and everything looks good: >> >>> dam at unstable10s [unstable10s]:/home/dam/mgar/pkg/rcs/trunk > ls -l /opt/csw/lib/python/site-packages/need-libmagic >>> lrwxrwxrwx 1 root root 19 May 19 16:30 /opt/csw/lib/python/site-packages/need-libmagic -> ../../libmagic.so.1 >>> dam at unstable10s [unstable10s]:/home/dam/mgar/pkg/rcs/trunk > ldd -r /opt/csw/lib/python/site-packages/need-libmagic >>> libpcreposix.so.0 => /opt/csw/lib/sparcv8/libpcreposix.so.0 >>> libz.so.1 => /opt/csw/lib/sparcv8plus+vis/libz.so.1 >>> libc.so.1 => /lib/libc.so.1 >>> libpcre.so.1 => /opt/csw/lib/sparcv8/libpcre.so.1 >>> /platform/SUNW,SPARC-Enterprise-T5220/lib/libc_psr.so.1 >>> libm.so.2 => /lib/libm.so.2 >> >> Is there some special Python logic I am missing? > > The "need-libmagic" thing not relevant at all. I just put it there to > hint checkpkg that it should make the package with Python files depend > on the package with the shared library. But it has no relevance to the > module working or not. With the help of Maciej the packages should be in good shape again, thanks! Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From ihsan at opencsw.org Sun May 19 19:45:03 2013 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Sun, 19 May 2013 19:45:03 +0200 Subject: [csw-maintainers] Mail / Web outage In-Reply-To: <20130519151020.GA10735@cotton.home.blizinski.pl> References: <51972BAB.50300@opencsw.org> <5197B9B9.5080209@opencsw.org> <519803CF.9040504@opencsw.org> <20130519151020.GA10735@cotton.home.blizinski.pl> Message-ID: <51990F9F.6000009@opencsw.org> Am 19.05.2013 17:10, schrieb Maciej Blizi?ski: >>>> I will install patches now and do another reboot tomorrow. >>> >>> The patching round was faster then I thought. The mail/web service might >>> not run during the next 120 minutes. >> >> The Live Upgrade reboot took 5 hours! >> >> Well, everything is now up to date again. Sorry for the outage and >> thanks for the patience. > > Thanks for handling the upgrade! BTW, I've disabled IPv6 again. As soon I've upgraded the global zone to Solaris 11 and and the zone have their own dedicated IP stack, I will enabled it again. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From wilbury at opencsw.org Sun May 19 19:57:01 2013 From: wilbury at opencsw.org (Juraj Lutter) Date: Sun, 19 May 2013 19:57:01 +0200 Subject: [csw-maintainers] Mail / Web outage In-Reply-To: <51990F9F.6000009@opencsw.org> References: <51972BAB.50300@opencsw.org> <5197B9B9.5080209@opencsw.org> <519803CF.9040504@opencsw.org> <20130519151020.GA10735@cotton.home.blizinski.pl> <51990F9F.6000009@opencsw.org> Message-ID: <5199126D.3010800@opencsw.org> On 05/19/2013 07:45 PM, ?hsan Do?an wrote: > Am 19.05.2013 17:10, schrieb Maciej Blizi?ski: > >>>>> I will install patches now and do another reboot tomorrow. >>>> >>>> The patching round was faster then I thought. The mail/web service might >>>> not run during the next 120 minutes. >>> >>> The Live Upgrade reboot took 5 hours! >>> >>> Well, everything is now up to date again. Sorry for the outage and >>> thanks for the patience. >> >> Thanks for handling the upgrade! > > BTW, I've disabled IPv6 again. As soon I've upgraded the global zone to > Solaris 11 and and the zone have their own dedicated IP stack, I will > enabled it again. What is the problem with IPv6 in local zones on Solaris 10? -- Juraj Lutter From ihsan at opencsw.org Sun May 19 20:44:04 2013 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Sun, 19 May 2013 20:44:04 +0200 Subject: [csw-maintainers] Mail / Web outage In-Reply-To: <5199126D.3010800@opencsw.org> References: <51972BAB.50300@opencsw.org> <5197B9B9.5080209@opencsw.org> <519803CF.9040504@opencsw.org> <20130519151020.GA10735@cotton.home.blizinski.pl> <51990F9F.6000009@opencsw.org> <5199126D.3010800@opencsw.org> Message-ID: <51991D74.6070506@opencsw.org> Am 19.05.2013 19:57, schrieb Juraj Lutter: >>>>>> I will install patches now and do another reboot tomorrow. >>>>> The patching round was faster then I thought. The mail/web service might >>>>> not run during the next 120 minutes. >>>> The Live Upgrade reboot took 5 hours! >>>> >>>> Well, everything is now up to date again. Sorry for the outage and >>>> thanks for the patience. >>> Thanks for handling the upgrade! >> BTW, I've disabled IPv6 again. As soon I've upgraded the global zone to >> Solaris 11 and and the zone have their own dedicated IP stack, I will >> enabled it again. > > What is the problem with IPv6 in local zones on Solaris 10? I don't want, that the global zone can be reached from a regular zone. With a shared IP stack, configuring black hole routes for the global zone isn't easy. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From wilbury at opencsw.org Sun May 19 21:10:33 2013 From: wilbury at opencsw.org (Juraj Lutter) Date: Sun, 19 May 2013 21:10:33 +0200 Subject: [csw-maintainers] Mail / Web outage In-Reply-To: <51991D74.6070506@opencsw.org> References: <51972BAB.50300@opencsw.org> <5197B9B9.5080209@opencsw.org> <519803CF.9040504@opencsw.org> <20130519151020.GA10735@cotton.home.blizinski.pl> <51990F9F.6000009@opencsw.org> <5199126D.3010800@opencsw.org> <51991D74.6070506@opencsw.org> Message-ID: <519923A9.2010603@opencsw.org> On 05/19/2013 08:44 PM, ?hsan Do?an wrote: > Am 19.05.2013 19:57, schrieb Juraj Lutter: > >>>>>>> I will install patches now and do another reboot tomorrow. >>>>>> The patching round was faster then I thought. The mail/web service might >>>>>> not run during the next 120 minutes. >>>>> The Live Upgrade reboot took 5 hours! >>>>> >>>>> Well, everything is now up to date again. Sorry for the outage and >>>>> thanks for the patience. >>>> Thanks for handling the upgrade! >>> BTW, I've disabled IPv6 again. As soon I've upgraded the global zone to >>> Solaris 11 and and the zone have their own dedicated IP stack, I will >>> enabled it again. >> >> What is the problem with IPv6 in local zones on Solaris 10? > > I don't want, that the global zone can be reached from a regular zone. > With a shared IP stack, configuring black hole routes for the global > zone isn't easy. intercept loopback via ipfilter or https://blogs.oracle.com/stw/entry/solaris_zones_and_networking_common ? > > > > Ihsan > -- Juraj Lutter From maciej at opencsw.org Sun May 19 23:47:23 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 19 May 2013 22:47:23 +0100 Subject: [csw-maintainers] Summercamp Date TBD: 13.-15. September 2013 In-Reply-To: <98FA8CA6-54F6-466E-B9F4-D20F4C6D3D38@opencsw.org> References: <98FA8CA6-54F6-466E-B9F4-D20F4C6D3D38@opencsw.org> Message-ID: 2013/5/13 Dagobert Michelsen > > Maciej? I usually don't confirm until my flight is booked. I can can confirm now! Do you guys have a hotel booked already? Which one? If not, let's pick one. From wilbury at opencsw.org Sun May 19 23:50:35 2013 From: wilbury at opencsw.org (Juraj Lutter) Date: Sun, 19 May 2013 23:50:35 +0200 Subject: [csw-maintainers] Summercamp Date TBD: 13.-15. September 2013 In-Reply-To: References: <98FA8CA6-54F6-466E-B9F4-D20F4C6D3D38@opencsw.org> Message-ID: <5199492B.6030808@opencsw.org> On 05/19/2013 11:47 PM, Maciej (Matchek) Blizi?ski wrote: > 2013/5/13 Dagobert Michelsen >> >> Maciej? > > I usually don't confirm until my flight is booked. I will come by car (If i will come alone) or by plane (If I will take my wife and kids with me, just to visit Berlin.) If I will go by car, probably I can do pick up for someone from Vienna if they will attend :-) > > I can can confirm now! Can the can! -- Juraj Lutter From laurent at opencsw.org Mon May 20 00:05:39 2013 From: laurent at opencsw.org (Laurent Blume) Date: Mon, 20 May 2013 00:05:39 +0200 Subject: [csw-maintainers] Mail / Web outage In-Reply-To: <519803CF.9040504@opencsw.org> References: <51972BAB.50300@opencsw.org> <5197B9B9.5080209@opencsw.org> <519803CF.9040504@opencsw.org> Message-ID: <51994CB3.3050202@opencsw.org> On 2013-05-19 12:42 AM, ?hsan Do?an wrote: > The Live Upgrade reboot took 5 hours! > > Well, everything is now up to date again. Sorry for the outage and > thanks for the patience. Congratulations for beating LU! Laurent From maciej at opencsw.org Tue May 21 00:23:13 2013 From: maciej at opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?=) Date: Mon, 20 May 2013 23:23:13 +0100 Subject: [csw-maintainers] Populating private checkpkg databases via REST In-Reply-To: References: Message-ID: <20130520222313.GB10950@cotton.home.blizinski.pl> On Wed, Jan 30, 2013 at 07:13:25PM +0100, Peter FELECAN wrote: > "Maciej (Matchek) Blizi?ski" writes: > > > While I'm wresting with the memory leak in catalog indexing, I got the > > idea that instead of unpacking and indexing everything locally, we > > could make people's private build hosts download data from our > > buildfarm. What do you think? > > Your proposition has merit but I think that we should keep things > reproducible even without OpenCSW's infrastructure; in an extreme case, > somebody wishing to build in an unconnected bunker (viz. a bank or stuff > like that) can do it. Sure. I wouldn't think about this data load as of a dependency, but just as an optional speedup. For the last month and a half or so, instead of being productive and playing Call of Duty, I've been rewriting parts of pkgdb and part of that was re-indexing all out packages. I didn't make it run in one smooth go ? I will do that after I've finished the main set of changes ? because I had to deal with some code issues along the way, but I can tell it took something like 30h to index one catalog (e.g. unstable or dublin). So if you could instead just download a SQL dump file and load it, it would be much quicker. When I'm done, I'm actually thinking of not re-running the indexing on the buildfarm, but instead taking the data from my virtual machine and loading them onto the buildfarm database. Maciej -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From ihsan at opencsw.org Tue May 21 10:28:58 2013 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuIERvxJ9hbg==?=) Date: Tue, 21 May 2013 10:28:58 +0200 Subject: [csw-maintainers] Summercamp Date TBD: 13.-15. September 2013 In-Reply-To: References: <98FA8CA6-54F6-466E-B9F4-D20F4C6D3D38@opencsw.org> Message-ID: <519B304A.1050700@opencsw.org> On 05/19/2013 11:47 PM, Maciej (Matchek) Blizi?ski wrote: > I usually don't confirm until my flight is booked. > > I can can confirm now! > > Do you guys have a hotel booked already? Which one? If not, let's pick one. J?rg, do you think the new Berlin airport will be finished till then? ;-) Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From Joerg.Schilling at fokus.fraunhofer.de Tue May 21 10:41:11 2013 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 21 May 2013 10:41:11 +0200 Subject: [csw-maintainers] Summercamp Date TBD: 13.-15. September 2013 In-Reply-To: <519B304A.1050700@opencsw.org> References: <98FA8CA6-54F6-466E-B9F4-D20F4C6D3D38@opencsw.org> <519B304A.1050700@opencsw.org> Message-ID: <519b3327.foAi4QZcbkl72pq1%Joerg.Schilling@fokus.fraunhofer.de> ??hsan Do??an wrote: > On 05/19/2013 11:47 PM, Maciej (Matchek) Blizi??ski wrote: > > > I usually don't confirm until my flight is booked. > > > > I can can confirm now! > > > > Do you guys have a hotel booked already? Which one? If not, let's pick one. > > J?rg, do you think the new Berlin airport will be finished till then? ;-) Opening of the new airport building will be 2064 together with Hamburg's "Elbphilharmonie". This will be a really big celebration. I though cannot tell when they finish to dig the runway under the earth ;-) J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From pfelecan at opencsw.org Tue May 21 12:16:30 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 21 May 2013 12:16:30 +0200 Subject: [csw-maintainers] Summercamp Date TBD: 13.-15. September 2013 In-Reply-To: <98FA8CA6-54F6-466E-B9F4-D20F4C6D3D38@opencsw.org> (Dagobert Michelsen's message of "Mon, 13 May 2013 19:06:24 +0200") References: <98FA8CA6-54F6-466E-B9F4-D20F4C6D3D38@opencsw.org> Message-ID: Dagobert Michelsen writes: > Maciej? Peter? Ihsan? ? yes -- Peter From Joerg.Schilling at fokus.fraunhofer.de Tue May 21 12:22:31 2013 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 21 May 2013 12:22:31 +0200 Subject: [csw-maintainers] Summercamp Date TBD: 13.-15. September 2013 In-Reply-To: References: <98FA8CA6-54F6-466E-B9F4-D20F4C6D3D38@opencsw.org> Message-ID: <519b4ae7.DlELoJovh3/knK57%Joerg.Schilling@fokus.fraunhofer.de> Peter FELECAN wrote: > Dagobert Michelsen writes: > > > Maciej? Peter? Ihsan? ? Hi, I just called the Alpha Hotel Ufnaustr and they have only premium rooms for 99 Euro without breakfast at that time. I have called: ECONTEL HOTEL Berlin (***) S?mmeringstra?e 24-26 10589 Berlin-Charlottenburg www.AMBER-HOTELS.de/Berlin Telefon +49 30 34 68 1 - 0 Fax +49 30 34 68 1 - 063 and there are currently enough rooms. 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 Joerg.Schilling at fokus.fraunhofer.de Tue May 21 12:23:30 2013 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 21 May 2013 12:23:30 +0200 Subject: [csw-maintainers] Summercamp Date TBD: 13.-15. September 2013 In-Reply-To: References: <98FA8CA6-54F6-466E-B9F4-D20F4C6D3D38@opencsw.org> Message-ID: <519b4b22.xpKUxCZACgYoLwKQ%Joerg.Schilling@fokus.fraunhofer.de> .... don't forget to mention Fraunhofer FOKUS when booking to get the special FOKUS price. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From pfelecan at opencsw.org Tue May 21 12:27:02 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 21 May 2013 12:27:02 +0200 Subject: [csw-maintainers] Populating private checkpkg databases via REST In-Reply-To: <20130520222313.GB10950@cotton.home.blizinski.pl> ("Maciej =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Mon, 20 May 2013 23:23:13 +0100") References: <20130520222313.GB10950@cotton.home.blizinski.pl> Message-ID: Maciej Blizi?ski writes: > On Wed, Jan 30, 2013 at 07:13:25PM +0100, Peter FELECAN wrote: >> "Maciej (Matchek) Blizi?ski" writes: >> >> > While I'm wresting with the memory leak in catalog indexing, I got the >> > idea that instead of unpacking and indexing everything locally, we >> > could make people's private build hosts download data from our >> > buildfarm. What do you think? >> >> Your proposition has merit but I think that we should keep things >> reproducible even without OpenCSW's infrastructure; in an extreme case, >> somebody wishing to build in an unconnected bunker (viz. a bank or stuff >> like that) can do it. > > Sure. I wouldn't think about this data load as of a dependency, but just > as an optional speedup. Well, if it's only an optional optimization, why not. -- Peter From pfelecan at opencsw.org Tue May 21 12:29:13 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 21 May 2013 12:29:13 +0200 Subject: [csw-maintainers] Faster catalog generation In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Wed, 15 May 2013 09:40:34 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > I spent some time yesterday working on the buildfarm[1], and managed > to remove one bottleneck and cut down the catalog generation time from > ~80 minutes to ~32 minutes. The new (and current) bottleneck seems to > be what I described in [2]: mass unlinking and relinking of files. > > There's also a new HTTP endpoint: > /rest/catalogs/([^/]+)/(sparc|i386)/(SunOS[^/]+)/for-generation/ > > (Prefix: http://buildfarm.opencsw.org/pkgdb/) > > It's quite quick to return and returns all information necessary to > generate a catalog. > > Maciej > > [1] https://sourceforge.net/apps/trac/gar/changeset/21086 > [2] http://lists.opencsw.org/pipermail/maintainers/2013-May/018016.html Does this invalidate the project that you proposed in [2] ? -- Peter From maciej at opencsw.org Tue May 21 12:43:14 2013 From: maciej at opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?=) Date: Tue, 21 May 2013 11:43:14 +0100 Subject: [csw-maintainers] Faster catalog generation In-Reply-To: References: Message-ID: <20130521104314.GA29424@cotton.home.blizinski.pl> On Tue, May 21, 2013 at 12:29:13PM +0200, Peter FELECAN wrote: > "Maciej (Matchek) Blizi?ski" writes: > > > I spent some time yesterday working on the buildfarm[1], and managed > > to remove one bottleneck and cut down the catalog generation time from > > ~80 minutes to ~32 minutes. The new (and current) bottleneck seems to > > be what I described in [2]: mass unlinking and relinking of files. > > > > There's also a new HTTP endpoint: > > /rest/catalogs/([^/]+)/(sparc|i386)/(SunOS[^/]+)/for-generation/ > > > > (Prefix: http://buildfarm.opencsw.org/pkgdb/) > > > > It's quite quick to return and returns all information necessary to > > generate a catalog. > > > > Maciej > > > > [1] https://sourceforge.net/apps/trac/gar/changeset/21086 > > [2] http://lists.opencsw.org/pipermail/maintainers/2013-May/018016.html > > Does this invalidate the project that you proposed in [2] ? No, quite the opposite! When I proposed [2], the unlinking was not yet the bottleneck, because there was another bottleneck that was way worse: unnecessary data transfers and deserialization. Now that I've optimized it away, the mass unlinking and relinking is the current standing bottleneck. Maciej From laurent at opencsw.org Tue May 21 14:04:05 2013 From: laurent at opencsw.org (Laurent Blume) Date: Tue, 21 May 2013 14:04:05 +0200 Subject: [csw-maintainers] Summercamp Date TBD: 13.-15. September 2013 In-Reply-To: <519b4b22.xpKUxCZACgYoLwKQ%Joerg.Schilling@fokus.fraunhofer.de> References: <98FA8CA6-54F6-466E-B9F4-D20F4C6D3D38@opencsw.org> <519b4b22.xpKUxCZACgYoLwKQ%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <519B62B5.8040703@opencsw.org> On 21/05/13 12:23, Joerg Schilling wrote: > .... don't forget to mention Fraunhofer FOKUS when booking to get the special > FOKUS price. > > J?rg > Nice! For the Econtel? Do you know if it can be done by their webpage of if it's better to call them? My German is, err, a bit rusty. Well, never has been good in the first place :-) Laurent From Joerg.Schilling at fokus.fraunhofer.de Tue May 21 14:15:28 2013 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 21 May 2013 14:15:28 +0200 Subject: [csw-maintainers] Summercamp Date TBD: 13.-15. September 2013 In-Reply-To: <519B62B5.8040703@opencsw.org> References: <98FA8CA6-54F6-466E-B9F4-D20F4C6D3D38@opencsw.org> <519b4b22.xpKUxCZACgYoLwKQ%Joerg.Schilling@fokus.fraunhofer.de> <519B62B5.8040703@opencsw.org> Message-ID: <519b6560.ipWW8hi6bZzNVZsz%Joerg.Schilling@fokus.fraunhofer.de> Laurent Blume wrote: > On 21/05/13 12:23, Joerg Schilling wrote: > > .... don't forget to mention Fraunhofer FOKUS when booking to get the special > > FOKUS price. > > > > J?rg > > > > Nice! For the Econtel? Do you know if it can be done by their webpage of > if it's better to call them? My German is, err, a bit rusty. Well, never > has been good in the first place :-) If you like a special price, you should call them. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From maciej at opencsw.org Tue May 21 18:32:51 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 21 May 2013 17:32:51 +0100 Subject: [csw-maintainers] Documentation: 4 places and their use In-Reply-To: References: Message-ID: 2013/4/27 Maciej (Matchek) Blizi?ski : > I have written up a short document ?About documentation?. > > https://sourceforge.net/apps/trac/gar/changeset/20875 > > Things in this document are largely just common sense, but I felt they > need to be spelled out to remove any potential doubt. For the record, this page lives at: http://www.opencsw.org/manual/for-maintainers/about-documentation.html I discovered that you can place HTTP redirects in wikidot. I just created one: http://wiki.opencsw.org/catalog-format Very useful for moving documentation from the wiki to the manual. One more update, I've written up a new page in the manual: http://www.opencsw.org/manual/for-maintainers/32-bit-and-64-bit.html For those who don't know, the manual is checked into our code repository in the opencsw-manual package. If you see any omissions or errors, please just make your edit and submit it! Maciej From rmottola at opencsw.org Tue May 21 23:00:37 2013 From: rmottola at opencsw.org (Riccardo Mottola) Date: Tue, 21 May 2013 23:00:37 +0200 Subject: [csw-maintainers] missing symbol libz Message-ID: <519BE075.1000108@opencsw.org> Hi, on solaris 10 with current packages, while compiling my "own" stuff, I get this error: Linking service GSspell ... Undefined first referenced symbol in file gzopen64 /opt/csw/lib/libxml2.so.2 ld: fatal: symbol referencing errors. No output written to GSspell.service/./GSspell but where is this symbol defined? I suppose there is a problem with how libxml2 was linked. Or perhaps libz instead, checking on the web that people have similar problems on linux. If all -L and -R flags are correct, it should work I suppose. Clues? Thanks, Riccardo From dam at opencsw.org Tue May 21 23:06:47 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 21 May 2013 23:06:47 +0200 Subject: [csw-maintainers] missing symbol libz In-Reply-To: <519BE075.1000108@opencsw.org> References: <519BE075.1000108@opencsw.org> Message-ID: <5207AAB7-C250-44BB-B27D-8E33D1926DAA@opencsw.org> Hi Riccardo, Am 21.05.2013 um 23:00 schrieb Riccardo Mottola : > on solaris 10 with current packages, while compiling my "own" stuff, I get this error: > > Linking service GSspell ... > Undefined first referenced > symbol in file > gzopen64 /opt/csw/lib/libxml2.so.2 > ld: fatal: symbol referencing errors. No output written to GSspell.service/./GSspell > > but where is this symbol defined? I suppose there is a problem with how libxml2 was linked. Or perhaps libz instead, checking on the web that people have similar problems on linux. > If all -L and -R flags are correct, it should work I suppose. > > Clues? gzopen64 is from libz.so.1. Most certainly you link with system libz.so.1 previously, the linker remembers that libz.so.1 is already in and the version from /opt/csw/lib is not used. Just make sure to always use libz.so.1 from OpenCSW if you are using other OpenCSW libraries. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From rmottola at opencsw.org Wed May 22 00:06:49 2013 From: rmottola at opencsw.org (Riccardo Mottola) Date: Wed, 22 May 2013 00:06:49 +0200 Subject: [csw-maintainers] missing symbol libz In-Reply-To: <5207AAB7-C250-44BB-B27D-8E33D1926DAA@opencsw.org> References: <519BE075.1000108@opencsw.org> <5207AAB7-C250-44BB-B27D-8E33D1926DAA@opencsw.org> Message-ID: <519BEFF9.3000702@opencsw.org> On 05/21/13 23:06, Dagobert Michelsen wrote: > Hi Riccardo, > gzopen64 is from libz.so.1. Most certainly you link with system libz.so.1 previously, > the linker remembers that libz.so.1 is already in and the version from /opt/csw/lib > is not used. Just make sure to always use libz.so.1 from OpenCSW if you are using > other OpenCSW libraries. how can I make sure? I have libz.so.1 from OpenCSW installed: ls -l /opt/csw/lib/libz.so.1 lrwxrwxrwx 1 root root 13 Apr 7 18:57 /opt/csw/lib/libz.so.1 -> libz.so.1.2.7 The linker ought to prefer this one? ldd says something even different: ldd libxml2.so.2 libdl.so.1 => /lib/libdl.so.1 libpthread.so.1 => /lib/libpthread.so.1 libz.so.1 => /opt/csw/lib/sparcv8plus+vis/libz.so.1 libiconv.so.2 => /opt/csw/lib/sparcv8/libiconv.so.2 libm.so.1 => /lib/libm.so.1 libsocket.so.1 => /lib/libsocket.so.1 libnsl.so.1 => /lib/libnsl.so.1 libc.so.1 => /lib/libc.so.1 libmp.so.2 => /lib/libmp.so.2 libmd.so.1 => /lib/libmd.so.1 libscf.so.1 => /lib/libscf.so.1 libdoor.so.1 => /lib/libdoor.so.1 libuutil.so.1 => /lib/libuutil.so.1 libgen.so.1 => /lib/libgen.so.1 libm.so.2 => /lib/libm.so.2 /platform/SUNW,UltraAX-i2/lib/libc_psr.so.1 /platform/SUNW,UltraAX-i2/lib/libmd_psr.so.1 my linking line is: gcc -shared-libgcc -pthread -fexceptions -fgnu-runtime -o GSspell.service/./GSspell \ ./obj/GSspell.obj/GSspell.m.o -L/opt/csw/lib -R/opt/csw/lib -L/opt/csw/lib -licui18n -licuuc -licudata -L/usr/lib -lpng12 -L../Source/./obj -L../Model/./obj -L/home/multix/GNUstep/Library/Libraries -L/opt/GNUstep/Local/Library/Libraries -L/opt/GNUstep/System/Library/Libraries -lgnustep-gui -lpng -ltiff -lz -ljpeg -lm -lgnustep-base -lobjc -lsocket -lnsl -lm Undefined first referenced symbol in file gzopen64 /opt/csw/lib/libxml2.so.2 which would include /opt/csw/lib but not the particular /opt/csw/lib/sparcv8/ ! Riccardo From pfelecan at opencsw.org Wed May 22 09:30:57 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 22 May 2013 09:30:57 +0200 Subject: [csw-maintainers] missing symbol libz In-Reply-To: <519BEFF9.3000702@opencsw.org> (Riccardo Mottola's message of "Wed, 22 May 2013 00:06:49 +0200") References: <519BE075.1000108@opencsw.org> <5207AAB7-C250-44BB-B27D-8E33D1926DAA@opencsw.org> <519BEFF9.3000702@opencsw.org> Message-ID: Riccardo Mottola writes: > -L/opt/csw/lib -licui18n -licuuc -licudata -L/usr/lib -lpng12 The last -L doesn't seems good. -- Peter From maciej at opencsw.org Wed May 22 09:54:34 2013 From: maciej at opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?=) Date: Wed, 22 May 2013 08:54:34 +0100 Subject: [csw-maintainers] NMUs, non-maintainer uploads In-Reply-To: References: Message-ID: <20130522075434.GA13770@cotton.home.blizinski.pl> On Sun, Apr 14, 2013 at 04:14:03PM +0200, Peter FELECAN wrote: > "Maciej (Matchek) Blizi?ski" writes: > > > 2013/4/12 Peter FELECAN : > >> In the pkginfo file we have this: > >> > >> VENDOR=http://leocad.googlecode.com/files/ packaged for CSW by Peter Felecan > >> EMAIL=pfelecan at opencsw.org > >> > >> We should have: > >> > >> VENDOR=http://leocad.googlecode.com/files/ > >> EMAIL=pfelecan at opencsw.org > >> ... > >> OPENCSW_MAINTAINERS=Peter Felecan, Dagobert Michelsen > >> > >> The last variable contain the values of the multi-valuated attribute > >> "maintainer". The user uploading the package is the value of the > >> attribute "NMU" --- when I'm writing about "attribute" I'm thinking to > >> the packages database schema. > > > > One more distinction: The user who uploads the package doesn't have to > > be the same user who ran "mgar package". So we have: > > > > 1. users who are long-term maintainers of a given package > > These are in variable containing the list and which is in the recipe, > i.e. Makefile and used to generate the corresponding information in the > pkginfo file. > > > 2. user who ran "mgar package" > > Who cares? But if you find it useful, why not. This is what we currently have. Unless somebody puts in the time to change the code, this is what we have to work with. > > 3. user who uploaded the package (ran csw-upload-pkg) > > This is more important that one who runs mgar and should be recorded by > the upload process. We have no tracking of the user who ran csw-upload-pkg. I tried to implement it, but our proxy stands in the way, stripping away REMOTE_USER. https://github.com/opencsw/gar/blob/ca2fa7fa5327bbda182201ad1f37ecc5a9979567/lib/web/releases_web.py#L208 (I'm giving links to github, because the sf.net code browser is too slow.) > >> The variable in the pkginfo file is generated at packaging time. > >> > >> The attributes are valuated at upload time. > > > > We can no longer modify the package contents at upload time, and I'm > > guessing we want everything to be inside the package. > > At upload time, the database's attributes are valuated from what's in the > package, isn't it? Yes. However, what we have in the package, is the information about who ran 'mgar package'. > > The list of maintainers needs to be in one of the pkginfo fields, > > that's simple. But I think it should be a list of user names, or a > > list of valid (rich) email addresses: > > > > OPENCSW_MAINTAINERS=joe, jane > > > > or > > > > OPENCSW_MAINTAINERS=Joe Doe , Jane Dow > > Too complex from my POV but why not. So you're thinking of associating 1 package with 1 name only? Maciej -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From dam at opencsw.org Wed May 22 10:29:46 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 22 May 2013 10:29:46 +0200 Subject: [csw-maintainers] Updated curl has issue with libtool/autoconf Message-ID: Hi, when working on the curl update I noticed that the linker pathes are put in too late in the invocation. Further analysis showed that this is because upstream uses now new versions for libtool/autoconf/automake which results in the wrong positions in Makefile.in whereas Makefile.am has not changed. I opened a bug upstream https://sourceforge.net/p/curl/bugs/1217/ but the actual situation is that the upstream maintainer is unable to fix it. It would be great if someone with libtool/automake skills could take a look at the issue. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From pfelecan at opencsw.org Wed May 22 11:20:10 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 22 May 2013 11:20:10 +0200 Subject: [csw-maintainers] NMUs, non-maintainer uploads In-Reply-To: <20130522075434.GA13770@cotton.home.blizinski.pl> ("Maciej =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Wed, 22 May 2013 08:54:34 +0100") References: <20130522075434.GA13770@cotton.home.blizinski.pl> Message-ID: Maciej Blizi?ski writes: > On Sun, Apr 14, 2013 at 04:14:03PM +0200, Peter FELECAN wrote: >> "Maciej (Matchek) Blizi?ski" writes: >> >> > 2013/4/12 Peter FELECAN : >> >> In the pkginfo file we have this: >> >> >> >> VENDOR=http://leocad.googlecode.com/files/ packaged for CSW by Peter Felecan >> >> EMAIL=pfelecan at opencsw.org >> >> >> >> We should have: >> >> >> >> VENDOR=http://leocad.googlecode.com/files/ >> >> EMAIL=pfelecan at opencsw.org >> >> ... >> >> OPENCSW_MAINTAINERS=Peter Felecan, Dagobert Michelsen >> >> >> >> The last variable contain the values of the multi-valuated attribute >> >> "maintainer". The user uploading the package is the value of the >> >> attribute "NMU" --- when I'm writing about "attribute" I'm thinking to >> >> the packages database schema. >> > >> > One more distinction: The user who uploads the package doesn't have to >> > be the same user who ran "mgar package". So we have: >> > >> > 1. users who are long-term maintainers of a given package >> >> These are in variable containing the list and which is in the recipe, >> i.e. Makefile and used to generate the corresponding information in the >> pkginfo file. >> >> > 2. user who ran "mgar package" >> >> Who cares? But if you find it useful, why not. > > This is what we currently have. Unless somebody puts in the time to > change the code, this is what we have to work with. > >> > 3. user who uploaded the package (ran csw-upload-pkg) >> >> This is more important that one who runs mgar and should be recorded by >> the upload process. > > We have no tracking of the user who ran csw-upload-pkg. I tried to > implement it, but our proxy stands in the way, stripping away > REMOTE_USER. > > https://github.com/opencsw/gar/blob/ca2fa7fa5327bbda182201ad1f37ecc5a9979567/lib/web/releases_web.py#L208 > > (I'm giving links to github, because the sf.net code browser is too > slow.) I don't see why somebody runs mgar and he's not the one uploading it; yes, there is the possibility to have an automatic builder but we don't have one yet. If there is really no solution around the proxy issue then consider that the upload-er is the same as the "magar-er". >> >> The variable in the pkginfo file is generated at packaging time. >> >> >> >> The attributes are valuated at upload time. >> > >> > We can no longer modify the package contents at upload time, and I'm >> > guessing we want everything to be inside the package. >> >> At upload time, the database's attributes are valuated from what's in the >> package, isn't it? > > Yes. However, what we have in the package, is the information about who > ran 'mgar package'. And there is no information sent by csw-upload-pkg? Hmm... >> > The list of maintainers needs to be in one of the pkginfo fields, >> > that's simple. But I think it should be a list of user names, or a >> > list of valid (rich) email addresses: >> > >> > OPENCSW_MAINTAINERS=joe, jane >> > >> > or >> > >> > OPENCSW_MAINTAINERS=Joe Doe , Jane Dow >> >> Too complex from my POV but why not. > > So you're thinking of associating 1 package with 1 name only? No. I just considered the second form too complex, i.e., I prefer a simple user list, without the e-mail address. -- Peter From maciej at opencsw.org Wed May 22 11:29:51 2013 From: maciej at opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?=) Date: Wed, 22 May 2013 10:29:51 +0100 Subject: [csw-maintainers] NMUs, non-maintainer uploads In-Reply-To: References: <20130522075434.GA13770@cotton.home.blizinski.pl> Message-ID: <20130522092951.GA15954@cotton.home.blizinski.pl> On Wed, May 22, 2013 at 11:20:10AM +0200, Peter FELECAN wrote: > Maciej Blizi?ski writes: > > >> > 3. user who uploaded the package (ran csw-upload-pkg) > >> > >> This is more important that one who runs mgar and should be recorded by > >> the upload process. > > > > We have no tracking of the user who ran csw-upload-pkg. I tried to > > implement it, but our proxy stands in the way, stripping away > > REMOTE_USER. > > > > https://github.com/opencsw/gar/blob/ca2fa7fa5327bbda182201ad1f37ecc5a9979567/lib/web/releases_web.py#L208 > > > > (I'm giving links to github, because the sf.net code browser is too > > slow.) > > I don't see why somebody runs mgar and he's not the one uploading it; > yes, there is the possibility to have an automatic builder but we don't > have one yet. If there is really no solution around the proxy issue then > consider that the upload-er is the same as the "magar-er". One example could be catalog integrations. Maintainers upload to the unstable catalog, but when packages migrate from unstable to testing, this is usually done by someone else. For the kiel catalog, mgar-er and uploader are almost always two different people. > >> >> The variable in the pkginfo file is generated at packaging time. > >> >> > >> >> The attributes are valuated at upload time. > >> > > >> > We can no longer modify the package contents at upload time, and I'm > >> > guessing we want everything to be inside the package. > >> > >> At upload time, the database's attributes are valuated from what's in the > >> package, isn't it? > > > > Yes. However, what we have in the package, is the information about who > > ran 'mgar package'. > > And there is no information sent by csw-upload-pkg? Hmm... There absolutely is. And it gets nuked by the proxy. :-( > >> > The list of maintainers needs to be in one of the pkginfo fields, > >> > that's simple. But I think it should be a list of user names, or a > >> > list of valid (rich) email addresses: > >> > > >> > OPENCSW_MAINTAINERS=joe, jane > >> > > >> > or > >> > > >> > OPENCSW_MAINTAINERS=Joe Doe , Jane Dow > >> > >> Too complex from my POV but why not. > > > > So you're thinking of associating 1 package with 1 name only? > > No. I just considered the second form too complex, i.e., I prefer a > simple user list, without the e-mail address. This can get a little ambiguous, since we have a number of user namespaces: - buildfarm - mantis - sourceforge Usually buildfarm and mantis are in sync, but user names on sourceforge are very different, e.g. my sourceforge user name is wahwah. Full names make it clearer. But if we make it explicit that we mean e.g. buildfarm names, bare usernames should be sufficient. Maciej -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From pfelecan at opencsw.org Wed May 22 11:49:06 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 22 May 2013 11:49:06 +0200 Subject: [csw-maintainers] NMUs, non-maintainer uploads In-Reply-To: <20130522092951.GA15954@cotton.home.blizinski.pl> ("Maciej =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Wed, 22 May 2013 10:29:51 +0100") References: <20130522075434.GA13770@cotton.home.blizinski.pl> <20130522092951.GA15954@cotton.home.blizinski.pl> Message-ID: Maciej Blizi?ski writes: > On Wed, May 22, 2013 at 11:20:10AM +0200, Peter FELECAN wrote: >> Maciej Blizi?ski writes: >> >> >> > 3. user who uploaded the package (ran csw-upload-pkg) >> >> >> >> This is more important that one who runs mgar and should be recorded by >> >> the upload process. >> > >> > We have no tracking of the user who ran csw-upload-pkg. I tried to >> > implement it, but our proxy stands in the way, stripping away >> > REMOTE_USER. >> > >> > https://github.com/opencsw/gar/blob/ca2fa7fa5327bbda182201ad1f37ecc5a9979567/lib/web/releases_web.py#L208 >> > >> > (I'm giving links to github, because the sf.net code browser is too >> > slow.) >> >> I don't see why somebody runs mgar and he's not the one uploading it; >> yes, there is the possibility to have an automatic builder but we don't >> have one yet. If there is really no solution around the proxy issue then >> consider that the upload-er is the same as the "magar-er". > > One example could be catalog integrations. Maintainers upload to the > unstable catalog, but when packages migrate from unstable to testing, > this is usually done by someone else. For the kiel catalog, mgar-er and > uploader are almost always two different people. In those cases the uploader doesn't matter because the transitions are done homogeneously. >> >> >> The variable in the pkginfo file is generated at packaging time. >> >> >> >> >> >> The attributes are valuated at upload time. >> >> > >> >> > We can no longer modify the package contents at upload time, and I'm >> >> > guessing we want everything to be inside the package. >> >> >> >> At upload time, the database's attributes are valuated from what's in the >> >> package, isn't it? >> > >> > Yes. However, what we have in the package, is the information about who >> > ran 'mgar package'. >> >> And there is no information sent by csw-upload-pkg? Hmm... > > There absolutely is. > > And it gets nuked by the proxy. :-( Every information sent by the tool? Or just specifically the user name? >> >> > The list of maintainers needs to be in one of the pkginfo fields, >> >> > that's simple. But I think it should be a list of user names, or a >> >> > list of valid (rich) email addresses: >> >> > >> >> > OPENCSW_MAINTAINERS=joe, jane >> >> > >> >> > or >> >> > >> >> > OPENCSW_MAINTAINERS=Joe Doe , Jane Dow >> >> >> >> Too complex from my POV but why not. >> > >> > So you're thinking of associating 1 package with 1 name only? >> >> No. I just considered the second form too complex, i.e., I prefer a >> simple user list, without the e-mail address. > > This can get a little ambiguous, since we have a number of user > namespaces: > > - buildfarm > - mantis > - sourceforge > > Usually buildfarm and mantis are in sync, but user names on sourceforge > are very different, e.g. my sourceforge user name is wahwah. Full names > make it clearer. But if we make it explicit that we mean e.g. buildfarm > names, bare usernames should be sufficient. What kind of user name are we storing in the package? It seems to me that is the one that I put in .garrc, e.g.: # Data for pkginfo SPKG_PACKAGER = Peter Felecan SPKG_EMAIL = pfelecan at opencsw.org What are the default values for this? -- Peter From ihsan at opencsw.org Wed May 22 12:10:14 2013 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuIERvxJ9hbg==?=) Date: Wed, 22 May 2013 12:10:14 +0200 Subject: [csw-maintainers] Mail / Web outage In-Reply-To: <519923A9.2010603@opencsw.org> References: <51972BAB.50300@opencsw.org> <5197B9B9.5080209@opencsw.org> <519803CF.9040504@opencsw.org> <20130519151020.GA10735@cotton.home.blizinski.pl> <51990F9F.6000009@opencsw.org> <5199126D.3010800@opencsw.org> <51991D74.6070506@opencsw.org> <519923A9.2010603@opencsw.org> Message-ID: <519C9986.9030204@opencsw.org> On 05/19/2013 09:10 PM, Juraj Lutter wrote: >>>>>>>> I will install patches now and do another reboot tomorrow. >>>>>>> The patching round was faster then I thought. The mail/web service might >>>>>>> not run during the next 120 minutes. >>>>>> The Live Upgrade reboot took 5 hours! >>>>>> >>>>>> Well, everything is now up to date again. Sorry for the outage and >>>>>> thanks for the patience. >>>>> Thanks for handling the upgrade! >>>> BTW, I've disabled IPv6 again. As soon I've upgraded the global zone to >>>> Solaris 11 and and the zone have their own dedicated IP stack, I will >>>> enabled it again. >>> What is the problem with IPv6 in local zones on Solaris 10? >> I don't want, that the global zone can be reached from a regular zone. >> With a shared IP stack, configuring black hole routes for the global >> zone isn't easy. > > intercept loopback via ipfilter or > https://blogs.oracle.com/stw/entry/solaris_zones_and_networking_common ? I didn't know, that there are other options then the route hole. ----------------------------------------------------------------- The /dev/ip ndd(1M) paramter 'ip_restrict_interzone_loopback', managed from the global zone, will force traffic out of the system on a datalink if the source and destination zones do not share a datalink. The default configuration for this is to allow inter-zone networking using internal loopback of IP datagrams, with the value of this parameter set to '0'. When the value is set to '1', traffic to an IP address in another zone in the shared IP Instance that is not on the same datalink will be put onto the external network. Whether the destination is reached will depend on the full network configuration of the system and the external network. This applies whether the source and destination IP address are on the same or different IP subnets. This parameter applies to all IP Instances active on the system, including exclusive IP Instance zones. In the case of exclusive IP zones, this will apply only if the zone has more than one datalink configured with IP addresses. The for two zones on the same system to communicate with the 'ip_restrict_interzone_loopback' set to '1' requires the following conditions. There is a network path to the destination. If on the same subnet, the switch(es) must allow the connection. If on different subnets, routes must be in place for packets to pass reliably between the two zones. The destination address is not on the same datalink (as this would break the datalink rules). The destination is not on datalink in an IPMP group that the sending datalink is also in. ----------------------------------------------------------------- The ip_restrict_interzone_loopback sounds very interesting. Have you ever tried it out? Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Wed May 22 15:40:37 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 22 May 2013 15:40:37 +0200 Subject: [csw-maintainers] enlightenment anyone? Message-ID: <4A9E1ECD-8061-4FAD-A3B1-2D9E5503E245@opencsw.org> Hi folks, hi Jake, I noticed that we have an outdated enlightenment in our catalog which is also the only package (apart from fnlib also used by en) depending on imlib which I want to remove. It would be nice if you could refresh enlightenment, but as it is sitting there for so long I am afraid that this is not going to happen. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From bwalton at opencsw.org Wed May 22 20:29:07 2013 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 22 May 2013 19:29:07 +0100 Subject: [csw-maintainers] Updated curl has issue with libtool/autoconf In-Reply-To: References: Message-ID: I'll take a look this this evening when the kids are in bed and I've had a short down time. Thanks -Ben On May 22, 2013 9:30 AM, "Dagobert Michelsen" wrote: > Hi, > > when working on the curl update I noticed that the linker pathes are put > in too late > in the invocation. Further analysis showed that this is because upstream > uses now > new versions for libtool/autoconf/automake which results in the wrong > positions in > Makefile.in whereas Makefile.am has not changed. I opened a bug upstream > https://sourceforge.net/p/curl/bugs/1217/ > but the actual situation is that the upstream maintainer is unable to fix > it. > > It would be great if someone with libtool/automake skills could take a > look at > the issue. > > > Best regards > > -- Dago > > -- > "You don't become great by trying to be great, you become great by wanting > to do something, > and then doing it so hard that you become great in the process." - xkcd > #896 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laurent at opencsw.org Wed May 22 20:39:58 2013 From: laurent at opencsw.org (Laurent Blume) Date: Wed, 22 May 2013 20:39:58 +0200 Subject: [csw-maintainers] missing symbol libz In-Reply-To: <519BEFF9.3000702@opencsw.org> References: <519BE075.1000108@opencsw.org> <5207AAB7-C250-44BB-B27D-8E33D1926DAA@opencsw.org> <519BEFF9.3000702@opencsw.org> Message-ID: <519D10FE.6000909@opencsw.org> On 2013-05-22 12:06 AM, Riccardo Mottola wrote: > ls -l /opt/csw/lib/libz.so.1 > lrwxrwxrwx 1 root root 13 Apr 7 18:57 > /opt/csw/lib/libz.so.1 -> libz.so.1.2.7 > > The linker ought to prefer this one? ldd says something even different: > ldd libxml2.so.2 > libdl.so.1 => /lib/libdl.so.1 > libpthread.so.1 => /lib/libpthread.so.1 > libz.so.1 => /opt/csw/lib/sparcv8plus+vis/libz.so.1 That's correct. Actually, it's probably an indirect link, because you didn't provide -R/opt/csw/lib/$ISALIST in your linking. If you do an ldd -v, you will get which other lib is asking for this one. You must not link directly against those, it's the runtime linker that chooses thet best one according to the best architecture your current CPU supports. > -L/opt/csw/lib -R/opt/csw/lib -L/usr/lib That's good: OpenCSW's lib comes first, before the system's. No problem with that, it doesn't matter if you add other -L after it. > -L../Source/./obj -L../Model/./obj > -L/home/multix/GNUstep/Library/Libraries > -L/opt/GNUstep/Local/Library/Libraries > -L/opt/GNUstep/System/Library/Libraries -lgnustep-gui -lpng -ltiff > -lz -ljpeg -lm -lgnustep-base -lobjc -lsocket -lnsl -lm That's good, -lz is here. > Undefined first referenced > symbol in file > gzopen64 /opt/csw/lib/libxml2.so.2 > > which would include /opt/csw/lib but not the particular > /opt/csw/lib/sparcv8/ ! Again, it must not include it, so don't try. What comes to my mind here is, have you installed CSWlibz-dev? Ie, do you have /opt/csw/lib/libz.so, so that the linker can find it? If you have only the .so.1*, it's not enough. Laurent From maciej at opencsw.org Wed May 22 22:29:08 2013 From: maciej at opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?=) Date: Wed, 22 May 2013 21:29:08 +0100 Subject: [csw-maintainers] NMUs, non-maintainer uploads In-Reply-To: References: <20130522075434.GA13770@cotton.home.blizinski.pl> <20130522092951.GA15954@cotton.home.blizinski.pl> Message-ID: <20130522202908.GA27341@cotton.home.blizinski.pl> On Wed, May 22, 2013 at 11:49:06AM +0200, Peter FELECAN wrote: > Maciej Blizi?ski writes: > > > On Wed, May 22, 2013 at 11:20:10AM +0200, Peter FELECAN wrote: > >> I don't see why somebody runs mgar and he's not the one uploading it; > >> yes, there is the possibility to have an automatic builder but we don't > >> have one yet. If there is really no solution around the proxy issue then > >> consider that the upload-er is the same as the "magar-er". > > > > One example could be catalog integrations. Maintainers upload to the > > unstable catalog, but when packages migrate from unstable to testing, > > this is usually done by someone else. For the kiel catalog, mgar-er and > > uploader are almost always two different people. > > In those cases the uploader doesn't matter because the transitions are > done homogeneously. Maybe we should define what 'uploader' means. There are 2 components: 1. Making a POST request, causing a .pkg.gz file to be saved in the allpkgs directory. 2. Making a PUT request, causing a modification in the database which associates certain .pkg.gz file with certain catalog, e.g. unstable-SunOS5.10-sparc. Inserting a package into a catalog is done in the same way (from the REST interface perspective), so it does matter who the uploader (inserter?) is, because this is the person who decided that package X will be part of catalog Y. > >> >> > We can no longer modify the package contents at upload time, and I'm > >> >> > guessing we want everything to be inside the package. > >> >> > >> >> At upload time, the database's attributes are valuated from what's in the > >> >> package, isn't it? > >> > > >> > Yes. However, what we have in the package, is the information about who > >> > ran 'mgar package'. > >> > >> And there is no information sent by csw-upload-pkg? Hmm... > > > > There absolutely is. > > > > And it gets nuked by the proxy. :-( > > Every information sent by the tool? Or just specifically the user name? Specifically the uploader user name. The user name is part of basic HTTP authentication. Under normal circumstances you can read the REMOTE_USER veriable from the environment, but proxies are notorious for stripping this information away, even though the HTTP auth is working. It is possible to pass REMOTE_USER forward from the proxy to the HTTP server, but it requires fiddling with the configuration. I tried to make it work from the level our of Apache configuration, but I wasn't able to fix it. > What kind of user name are we storing in the package? It seems to me > that is the one that I put in .garrc, e.g.: > > # Data for pkginfo > SPKG_PACKAGER = Peter Felecan > SPKG_EMAIL = pfelecan at opencsw.org > > What are the default values for this? No default values. Every mgar run expects these to be set. In principle, they could be put in the recipe itself. These two values are stored in the pkginfo. The email goes into the EMAIL field, and the full name goes into the VENDOR field as "... packaged for CSW by ${full_name}". The user names e.g. displayed at http://buildfarm.opencsw.org/pkgdb/srv4/ are taken from the EMAIL field with the @opencsw.org part stripped out. Maciej From rmottola at opencsw.org Thu May 23 08:31:12 2013 From: rmottola at opencsw.org (Riccardo Mottola) Date: Thu, 23 May 2013 08:31:12 +0200 Subject: [csw-maintainers] missing symbol libz In-Reply-To: <519D10FE.6000909@opencsw.org> References: <519BE075.1000108@opencsw.org> <5207AAB7-C250-44BB-B27D-8E33D1926DAA@opencsw.org> <519BEFF9.3000702@opencsw.org> <519D10FE.6000909@opencsw.org> Message-ID: <519DB7B0.1000106@opencsw.org> Hi Laurent, On 05/22/13 20:39, Laurent Blume wrote: > > Again, it must not include it, so don't try. > > What comes to my mind here is, have you installed CSWlibz-dev? > Ie, do you have /opt/csw/lib/libz.so, so that the linker can find it? If > you have only the .so.1*, it's not enough. That was it, thank you. I haad a libz transitional package, but lost the -dev part. Now it links fine. Riccardo From skayser at opencsw.org Fri May 24 07:23:38 2013 From: skayser at opencsw.org (Sebastian Kayser) Date: Fri, 24 May 2013 07:23:38 +0200 Subject: [csw-maintainers] ceeswi needs to be migrated Message-ID: Hi, the system which hosts ceeswi needs to be shut off permanently. Can someone please move ceeswi to a opencsw system? I don't have the time to do this myself. Sorry. There's a tarball with it on login under ~skayser/migrate. If there's anything crucial you need to know, include me directly as I don't follow maintainers anymore. Best, Sebastian -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfelecan at opencsw.org Fri May 24 11:58:24 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 24 May 2013 11:58:24 +0200 Subject: [csw-maintainers] ceeswi needs to be migrated In-Reply-To: (Sebastian Kayser's message of "Fri, 24 May 2013 07:23:38 +0200") References: Message-ID: What's "ceeswi"? -- Peter From maciej at opencsw.org Fri May 24 12:23:23 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 24 May 2013 11:23:23 +0100 Subject: [csw-maintainers] ceeswi needs to be migrated In-Reply-To: References: Message-ID: 2013/5/24 Peter FELECAN : > What's "ceeswi"? It's the name of our IRC bot. From slowfranklin at opencsw.org Fri May 24 14:55:23 2013 From: slowfranklin at opencsw.org (slowfranklin) Date: Fri, 24 May 2013 14:55:23 +0200 Subject: [csw-maintainers] Maintainer and Uploader Info Message-ID: <6D4996B8-BB29-4E60-8E03-79C5940B0D92@opencsw.org> Hey just noticed that the packages I've uploaded are missing proper maintainer and uploader info, e.g. http://www.opencsw.org/package/netatalk/ http://www.opencsw.org/qa/package/netatalk/ -slow From slowfranklin at opencsw.org Mon May 27 10:56:34 2013 From: slowfranklin at opencsw.org (slowfranklin) Date: Mon, 27 May 2013 10:56:34 +0200 Subject: [csw-maintainers] glib2 updates Message-ID: <55A7B138-94BA-4920-9BB3-57E43F4A9CE1@opencsw.org> Hey Rafael, Laurent Blume and myself have committed several changes to the glib2 recipe. Don't remember off-hand what Laurent's changes are about, but my commits add Solaris 11 specific packages in order to have a glib2 with FEN support on Solaris 11. Can you take a look at it and release updates packages? make check still occasionally fails on dbus related tests with an "address still in use" error, I believe these are artifacts that can be ignored. Requires rerunning mgar package of course unless you pass SKIP_TESTS=1 in the first place. Besides that, the packages seem to be in good shape on all build platforms including the new Solaris 11 builds. -slow From maciej at opencsw.org Mon May 27 14:44:08 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 27 May 2013 13:44:08 +0100 Subject: [csw-maintainers] Discovering 32/64 differences in shared files (pre-merge) Message-ID: During the merge phase, GAR rewrites paths so that the binary files are nicely sorted to subdirectories, and it takes platform-independent files from the first modulation, under the assumption that they're the same for all platforms. But sometimes they really aren't. Do we have a tool which inspects the DESTDIR directories for 32/64-bit modulations and verifies that the files are in fact the same? If not, would anyone be up for writing such a tool? It would be really useful for us, for the whole project. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Mon May 27 14:48:02 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 27 May 2013 14:48:02 +0200 Subject: [csw-maintainers] Discovering 32/64 differences in shared files (pre-merge) In-Reply-To: References: Message-ID: <0AB9F7B8-802B-4ACF-B123-57DCD7B90547@opencsw.org> Hi Maciej, Am 27.05.2013 um 14:44 schrieb Maciej (Matchek) Blizi?ski : > During the merge phase, GAR rewrites paths so that the binary files are nicely sorted to subdirectories, and it takes platform-independent files from the first modulation, under the assumption that they're the same for all platforms. > > But sometimes they really aren't. > > Do we have a tool which inspects the DESTDIR directories for 32/64-bit modulations and verifies that the files are in fact the same? > > If not, would anyone be up for writing such a tool? It would be really useful for us, for the whole project. In fact we talked about that during the last camp and Igor suggested to always add include-merging with automatic 32/64 selection similar to what we have for curl right now with "diff -D". We should also use the opportunity to factor out the merging from GAR and enhance modularization. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Mon May 27 15:19:44 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 27 May 2013 14:19:44 +0100 Subject: [csw-maintainers] Discovering 32/64 differences in shared files (pre-merge) In-Reply-To: <0AB9F7B8-802B-4ACF-B123-57DCD7B90547@opencsw.org> References: <0AB9F7B8-802B-4ACF-B123-57DCD7B90547@opencsw.org> Message-ID: 2013/5/27 Dagobert Michelsen > > In fact we talked about that during the last camp and Igor suggested to > always add include-merging with automatic 32/64 selection similar to what > we have for curl right now with "diff -D". We should also use the > opportunity to factor out the merging from GAR and enhance modularization. Right, these are the things we could do after the utility is brought into existence. I'm suggesting splitting this into smaller steps. Having a simple utility doing this would be the first step. It would be relatively simple and allow us to run it by hand and examine the output. Once we have that in place, we can think about building more automation around it. For now, I just want something like this: $ csw-compare-shared-install-dirs (...) /opt/csw/lib/python3.3/_sysconfigdata.py differs $ csw-compare-shared-install-dirs --verbose (...) /opt/csw/lib/python3.3/_sysconfigdata.py: -foo +bar The point being that it knows which directories to compare and which not to. Maciej From grzemba at contac-dt.de Mon May 27 15:55:26 2013 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Mon, 27 May 2013 15:55:26 +0200 Subject: [csw-maintainers] 64bit ldd search patch In-Reply-To: References: Message-ID: ?is this the right ld lib search path /opt/csw/lib/$ISALIST:/opt/csw/lib/64, which will result in find the 32bit lib first?: cgrzemba at unstable10x:~/opencsw/cups/trunk/work/solaris10-i386/install-isa-amd64/opt/csw/lib/64$ ldd -s libcupsppdc.so.1 find object=libcups.so.2; required by ./libcupsppdc.so.1 search path=/opt/csw/lib/$ISALIST:/opt/csw/lib/64:/opt/solarisstudio12.3/lib/amd64 (RUNPATH/RPATH from file ./libcupsppdc.so.1) trying path=/opt/csw/lib/amd64/libcups.so.2 trying path=/opt/csw/lib/pentium_pro+mmx/libcups.so.2 trying path=/opt/csw/lib/pentium_pro/libcups.so.2 trying path=/opt/csw/lib/pentium+mmx/libcups.so.2 trying path=/opt/csw/lib/pentium/libcups.so.2 trying path=/opt/csw/lib/i486/libcups.so.2 trying path=/opt/csw/lib/i386/libcups.so.2 trying path=/opt/csw/lib/i86/libcups.so.2 trying path=/opt/csw/lib/64/libcups.so.2 trying path=/opt/solarisstudio12.3/lib/amd64/libcups.so.2 search path=/lib/64:/usr/lib/64 (default) trying path=/lib/64/libcups.so.2 trying path=/usr/lib/64/libcups.so.2 libcups.so.2 => /opt/csw/lib/i386/libcups.so.2 - wrong ELF class: ELFCLASS32 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Mon May 27 15:59:25 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 27 May 2013 15:59:25 +0200 Subject: [csw-maintainers] 64bit ldd search patch In-Reply-To: References: Message-ID: <4BC8C344-6707-4617-A7F7-3906D3F85FAA@opencsw.org> Hi Carsten, Am 27.05.2013 um 15:55 schrieb Carsten Grzemba : > is this the right ld lib search path /opt/csw/lib/$ISALIST:/opt/csw/lib/64, which will result in find the 32bit lib first?: Yes, this is normal. One could think that on 64 bit execution the 32 bit ISAs would be skipped, but actually this is not the case. The problem is that the path to the newly built libcups.so.2 is not searched, so you can either add the path with LD_LIBRARY_PATH intermediately (this is what libtool does) or install the library to the correct path /opt/csw/lib/amd64. Best regards -- Dago > > cgrzemba at unstable10x:~/opencsw/cups/trunk/work/solaris10-i386/install-isa-amd64/opt/csw/lib/64$ ldd -s libcupsppdc.so.1 > > find object=libcups.so.2; required by ./libcupsppdc.so.1 > search path=/opt/csw/lib/$ISALIST:/opt/csw/lib/64:/opt/solarisstudio12.3/lib/amd64 (RUNPATH/RPATH from file ./libcupsppdc.so.1) > trying path=/opt/csw/lib/amd64/libcups.so.2 > trying path=/opt/csw/lib/pentium_pro+mmx/libcups.so.2 > trying path=/opt/csw/lib/pentium_pro/libcups.so.2 > trying path=/opt/csw/lib/pentium+mmx/libcups.so.2 > trying path=/opt/csw/lib/pentium/libcups.so.2 > trying path=/opt/csw/lib/i486/libcups.so.2 > trying path=/opt/csw/lib/i386/libcups.so.2 > trying path=/opt/csw/lib/i86/libcups.so.2 > trying path=/opt/csw/lib/64/libcups.so.2 > trying path=/opt/solarisstudio12.3/lib/amd64/libcups.so.2 > search path=/lib/64:/usr/lib/64 (default) > trying path=/lib/64/libcups.so.2 > trying path=/usr/lib/64/libcups.so.2 > libcups.so.2 => /opt/csw/lib/i386/libcups.so.2 - wrong ELF class: ELFCLASS32 > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From raos at opencsw.org Mon May 27 17:09:05 2013 From: raos at opencsw.org (Rafael Ostertag) Date: Mon, 27 May 2013 17:09:05 +0200 Subject: [csw-maintainers] glib2 updates In-Reply-To: <55A7B138-94BA-4920-9BB3-57E43F4A9CE1@opencsw.org> References: <55A7B138-94BA-4920-9BB3-57E43F4A9CE1@opencsw.org> Message-ID: <20130527150905.GA9436@bender.opencsw.org> Hi guys On Mon, May 27, 2013 at 10:56:34AM +0200, slowfranklin wrote: > Hey Rafael, > > Laurent Blume and myself have committed several changes to the glib2 recipe. Don't remember off-hand what Laurent's changes are about, but my commits add Solaris 11 specific packages in order to have a glib2 with FEN support on Solaris 11. > > Can you take a look at it and release updates packages? Just started mgar platforms will let you know of the outcome. > > make check still occasionally fails on dbus related tests with an "address still in use" error, I believe these are artifacts that can be ignored. Requires rerunning mgar package of course unless you pass SKIP_TESTS=1 in the first place. Besides that, the packages seem to be in good shape on all build platforms including the new Solaris 11 builds. yeah, the checks are a pain in the neck... cheers & thx rafi From slowfranklin at opencsw.org Mon May 27 17:11:17 2013 From: slowfranklin at opencsw.org (slowfranklin) Date: Mon, 27 May 2013 17:11:17 +0200 Subject: [csw-maintainers] glib2 updates In-Reply-To: <20130527150905.GA9436@bender.opencsw.org> References: <55A7B138-94BA-4920-9BB3-57E43F4A9CE1@opencsw.org> <20130527150905.GA9436@bender.opencsw.org> Message-ID: <4FB69EFB-54FE-45D8-8C4E-83D153517DF0@opencsw.org> Hi Am 27.05.2013 um 17:09 schrieb Rafael Ostertag : > Hi guys > > On Mon, May 27, 2013 at 10:56:34AM +0200, slowfranklin wrote: >> Hey Rafael, >> >> Laurent Blume and myself have committed several changes to the glib2 recipe. Don't remember off-hand what Laurent's changes are about, but my commits add Solaris 11 specific packages in order to have a glib2 with FEN support on Solaris 11. >> >> Can you take a look at it and release updates packages? > > Just started > > mgar platforms > > will let you know of the outcome. ah, so tomorrow, then. :) Thanks! -slow From jh at opencsw.org Tue May 28 09:57:54 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Tue, 28 May 2013 09:57:54 +0200 Subject: [csw-maintainers] Signing broken atm. Message-ID: <51A46382.1080403@opencsw.org> Hi, Fetching 'http://192.168.1.40:9981/clearsign/opencsw-official/unstable/i386/5.8' + curl -s -f http://192.168.1.40:9981/clearsign/opencsw-official/unstable/i386/5.8 ++ pwd + echo 'Signing /home/mirror/opencsw-official/unstable/i386/5.8 failed.' Signing /home/mirror/opencsw-official/unstable/i386/5.8 failed. + exit 1 someone with the rights to fix signing please do :) Greetings Jan From maciej at opencsw.org Tue May 28 12:16:11 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 28 May 2013 11:16:11 +0100 Subject: [csw-maintainers] Signing broken atm. In-Reply-To: <51A46382.1080403@opencsw.org> References: <51A46382.1080403@opencsw.org> Message-ID: 2013/5/28 Jan Holzhueter : > 'http://192.168.1.40:9981/clearsign/opencsw-official/unstable/i386/5.8' > + curl -s -f > http://192.168.1.40:9981/clearsign/opencsw-official/unstable/i386/5.8 > ++ pwd > + echo 'Signing /home/mirror/opencsw-official/unstable/i386/5.8 failed.' > Signing /home/mirror/opencsw-official/unstable/i386/5.8 failed. > + exit 1 Done. 3 things: 1. There is no error message. Is the above snippet from a cron email? 2. Why are we signing the 5.8 catalog? We're not generating the 5.8 catalogs, so why are we trying to sign them? 3. I did not get the automated email. From grzemba at contac-dt.de Tue May 28 12:17:05 2013 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Tue, 28 May 2013 12:17:05 +0200 Subject: [csw-maintainers] how to prevent gmake silent compile In-Reply-To: References: Message-ID: ?Hi, cups build process has a annoying magic to silent compile. Does anybody know how can I disable silent compiling? gmake V=1 does not work. Thanks Carsten -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Tue May 28 12:22:27 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 28 May 2013 11:22:27 +0100 Subject: [csw-maintainers] how to prevent gmake silent compile In-Reply-To: References: Message-ID: 2013/5/28 Carsten Grzemba : > cups build process has a annoying magic to silent compile. Does anybody know > how can I disable silent compiling? gmake V=1 does not work. How is cups doing the silent compile? I assume it's using Makefiles, so there's probably some sort of a prefix for each command. From Joerg.Schilling at fokus.fraunhofer.de Tue May 28 13:02:09 2013 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 28 May 2013 13:02:09 +0200 Subject: [csw-maintainers] how to prevent gmake silent compile In-Reply-To: References: Message-ID: <51a48eb1.4YMFUczo1yWcwxoV%Joerg.Schilling@fokus.fraunhofer.de> Carsten Grzemba wrote: > ?Hi, > cups build process has a annoying magic to silent compile. Does anybody know how can I disable silent compiling? gmake V=1 does not work. > Thanks Carsten If this is done vie .SILENT: in a makefile, you need to remove this line. 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 jh at opencsw.org Tue May 28 13:16:20 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Tue, 28 May 2013 13:16:20 +0200 Subject: [csw-maintainers] Signing broken atm. In-Reply-To: References: <51A46382.1080403@opencsw.org> Message-ID: <51A49204.8020208@opencsw.org> Hi, Am 28.05.13 12:16, schrieb Maciej (Matchek) Blizi?ski: > 2013/5/28 Jan Holzhueter : >> 'http://192.168.1.40:9981/clearsign/opencsw-official/unstable/i386/5.8' >> + curl -s -f >> http://192.168.1.40:9981/clearsign/opencsw-official/unstable/i386/5.8 >> ++ pwd >> + echo 'Signing /home/mirror/opencsw-official/unstable/i386/5.8 failed.' >> Signing /home/mirror/opencsw-official/unstable/i386/5.8 failed. >> + exit 1 > > Done. > > 3 things: > > 1. There is no error message. Is the above snippet from a cron email? no, manuell run since nagios told me the cataloge was older then 12h. > 2. Why are we signing the 5.8 catalog? We're not generating the 5.8 > catalogs, so why are we trying to sign them? don't know :) Thats was the code does :) > 3. I did not get the automated email. It just exits so no mail unless you get cron mail. From maciej at opencsw.org Tue May 28 18:15:06 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 28 May 2013 17:15:06 +0100 Subject: [csw-maintainers] Maintainer and Uploader Info In-Reply-To: <6D4996B8-BB29-4E60-8E03-79C5940B0D92@opencsw.org> References: <6D4996B8-BB29-4E60-8E03-79C5940B0D92@opencsw.org> Message-ID: 2013/5/24 slowfranklin > just noticed that the packages I've uploaded are missing proper maintainer and uploader info, e.g. > > http://www.opencsw.org/package/netatalk/ > http://www.opencsw.org/qa/package/netatalk/ There's an additional manual step we currently have to take to put maintainer's full name in the database. I've just done that. It should be updated in the next iteration. This is fixed in the new version of checkpkg code which I'm currently working on. By the way, kudos to Laurent for helping me test it! Maciej From maciej at opencsw.org Tue May 28 18:41:28 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 28 May 2013 17:41:28 +0100 Subject: [csw-maintainers] Python 3.3 in 64 bits In-Reply-To: <1C4C9A75-96DC-4814-958F-680FBF291091@opencsw.org> References: <15E0815A-014D-45EA-9308-43D6A13FE738@opencsw.org> <9634E070-791C-46F0-B700-5524EB98E31B@opencsw.org> <1C4C9A75-96DC-4814-958F-680FBF291091@opencsw.org> Message-ID: 2013/1/13 Dagobert Michelsen : > This is... peculiar. Why would upstream put stuff in $(prefix)/lib instead of > $(libdir) at all? No idea. I asked on python-list and received no response. So I filed a bug. http://bugs.python.org/issue18083 Maciej From dam at opencsw.org Wed May 29 15:56:22 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 29 May 2013 15:56:22 +0200 Subject: [csw-maintainers] Update of Ghostscript Message-ID: <4E9D255A-E09D-41D3-8203-C6D6F596C841@opencsw.org> Fellow maintainers, I have updated ghostscript to the latest 9.07. However, this goes with bumping libgs from libgs.so.8 to libgs.so.9 which are used by a couple of packages that would need rebuilding. I am not sure about how libgs.so interacts with other files like printer drivers between 8 and 9, probably someone can help me out on this? The updated packages are available at http://buildfarm.opencsw.org/experimental.html#ghostscript for testing. Additionally, the final packages would need to include CSWlibgs8 for libgs.so.8 being required by a couple of packages including texlive which will probably not be rebuilt because of some minor dependency change :-) Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From pfelecan at opencsw.org Wed May 29 16:55:47 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 29 May 2013 16:55:47 +0200 Subject: [csw-maintainers] Update of Ghostscript In-Reply-To: <4E9D255A-E09D-41D3-8203-C6D6F596C841@opencsw.org> (Dagobert Michelsen's message of "Wed, 29 May 2013 15:56:22 +0200") References: <4E9D255A-E09D-41D3-8203-C6D6F596C841@opencsw.org> Message-ID: Dagobert Michelsen writes: > Fellow maintainers, > > I have updated ghostscript to the latest 9.07. However, this goes with bumping libgs from > libgs.so.8 to libgs.so.9 which are used by a couple of packages that would need rebuilding. > I am not sure about how libgs.so interacts with other files like printer drivers between > 8 and 9, probably someone can help me out on this? The updated packages are available at > http://buildfarm.opencsw.org/experimental.html#ghostscript > for testing. Additionally, the final packages would need to include CSWlibgs8 for libgs.so.8 > being required by a couple of packages including texlive which will probably not be rebuilt > because of some minor dependency change :-) The maintainer of TeXLive greatly appreciate this! Sometime, in the future, I'll rebuild it and use the new library... -- Peter From rupert at opencsw.org Wed May 29 20:30:11 2013 From: rupert at opencsw.org (rupert THURNER) Date: Wed, 29 May 2013 20:30:11 +0200 Subject: [csw-maintainers] Fwd: OpenCSW question about package subversion In-Reply-To: <201305291533.r4TFXOCr027703@www.opencsw.org> References: <201305291533.r4TFXOCr027703@www.opencsw.org> Message-ID: Hi, anybody is able to help here? This cannot be the recent catalog changes isnt it? ---------- Weitergeleitete Nachricht ---------- Von: Datum: 29.05.2013 17:33 Betreff: OpenCSW question about package subversion An: Hello, I have been working to install CSWsvn. I got it installed and this is the error I get when I try to run it. Please help. \" # svn --help ld.so.1: svn: fatal: libaprutil-1.so.0: open failed: No such file or directory Killed\" -------------- next part -------------- An HTML attachment was scrubbed... URL: From bonivart at opencsw.org Wed May 29 20:45:19 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 29 May 2013 20:45:19 +0200 Subject: [csw-maintainers] Fwd: OpenCSW question about package subversion In-Reply-To: References: <201305291533.r4TFXOCr027703@www.opencsw.org> Message-ID: I just installed it from unstable and it works nicely. Ask him what catalog he uses and if he has updated the deps as well. Does he even have CSWlibaprutil1-0 installed? On Wed, May 29, 2013 at 8:30 PM, rupert THURNER wrote: > Hi, anybody is able to help here? This cannot be the recent catalog changes > isnt it? > > ---------- Weitergeleitete Nachricht ---------- > Von: > Datum: 29.05.2013 17:33 > Betreff: OpenCSW question about package subversion > An: > > Hello, I have been working to install CSWsvn. I got it installed and this is > the error I get when I try to run it. Please help. > \" # svn --help > ld.so.1: svn: fatal: libaprutil-1.so.0: open failed: No such file or > directory > Killed\" > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::.