From maciej at opencsw.org Tue Jan 1 12:00:16 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 1 Jan 2013 11:00:16 +0000 Subject: [csw-maintainers] Garbage collection in allpkgs In-Reply-To: <1A4196A0-120D-4217-B0A4-646E30F34BAA@opencsw.org> References: <9A41C992-9D7E-481C-BBFB-2C14E8080B47@opencsw.org> <1A4196A0-120D-4217-B0A4-646E30F34BAA@opencsw.org> Message-ID: 2012/12/31 Dagobert Michelsen : >>>> I'm not sure what you mean by downstream-sites selecting what to >>>> offer. >>> >>> Official sites mirroring our packages. >> >> I was asking what do you mean by selecting what to offer. Downstream >> sites I understand. >> >>>> The primary mirror has a set of files, and that's it. >>> >>> Not quite. There are all files in the filesystem avaialable for download. >>> However, if you rsync "opencsw" you won't get allpkgs/, so almost all >>> of the official mirror sites don't mirror allpkgs/. >> >> So there's a set of file that you get when you rsync and that's it. If >> you rsync, you don't get to choose, you get what you it's given to >> you. If you don't, then you're not a full mirror. > > You are completely missing the point here. Please try > rsync rsync://mirror.opencsw.org/opencsw/ > and compare this to > rsync rsync://mirror.opencsw.org/opencsw-full/ I don't think I've ever come across the opencsw-full URL. Our conversation could have been: Me: "I'm not sure what you mean by downstream-sites selecting what to offer." You: "There are 2 directories you can sync, /opencsw and /opencsw-full, it's documented at ." It would have saved us confusion. > The former does not include allpkgs/, the latter does. By choosing the rsync URL > you as downstream mirror decide if you want to include allpkgs or not although > it is on the filesystem of the primary. This is rsync-magic. Trust me! :-) > >>>> People >>>> can make snapshots from different points in time, is that what you >>>> mean? >>> >>> No, that is different. We don't do this ATM, but archive catalog-files, >>> so if someone has a specific problem we can regenerate everything >>> from that catalog and allpkgs/ and this is another reason why I think >>> having allpkgs is a Good Thing?. >> >> Did we ever do that? Did we even exercise doing this? I think that in >> a real situation we would do something else rather than recreating a >> past catalog. Do you have a specific scenario in mind? For example, we >> have a bad, I don't know, MySQL. What would make us recreate an old >> catalog from archives, rather than selectively solving the problem at >> hand? > > I did a couple of times. Fair enough then. Maciej From dam at opencsw.org Tue Jan 1 12:37:38 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 1 Jan 2013 12:37:38 +0100 Subject: [csw-maintainers] Garbage collection in allpkgs In-Reply-To: References: <9A41C992-9D7E-481C-BBFB-2C14E8080B47@opencsw.org> <1A4196A0-120D-4217-B0A4-646E30F34BAA@opencsw.org> Message-ID: <1339637B-7A57-4560-BC95-A07633AFBA49@opencsw.org> Hi Maciej, Am 01.01.2013 um 12:00 schrieb Maciej (Matchek) Blizi?ski : > 2012/12/31 Dagobert Michelsen : >>>>> I'm not sure what you mean by downstream-sites selecting what to >>>>> offer. >>>> >>>> Official sites mirroring our packages. >>> >>> I was asking what do you mean by selecting what to offer. Downstream >>> sites I understand. >>> >>>>> The primary mirror has a set of files, and that's it. >>>> >>>> Not quite. There are all files in the filesystem avaialable for download. >>>> However, if you rsync "opencsw" you won't get allpkgs/, so almost all >>>> of the official mirror sites don't mirror allpkgs/. >>> >>> So there's a set of file that you get when you rsync and that's it. If >>> you rsync, you don't get to choose, you get what you it's given to >>> you. If you don't, then you're not a full mirror. >> >> You are completely missing the point here. Please try >> rsync rsync://mirror.opencsw.org/opencsw/ >> and compare this to >> rsync rsync://mirror.opencsw.org/opencsw-full/ > > I don't think I've ever come across the opencsw-full URL. I was pretty sure we discussed this on maintainers, but as I couldn't find the post this probably happened on IRC which you may have missed. There was quite some discussion on the layout and AFAIR everybody was fine with the extra rsync URL not being the default, so I wrongly assumed you also were part of the discussion. > Our conversation could have been: > > Me: "I'm not sure what you mean by downstream-sites selecting what to offer." > You: "There are 2 directories you can sync, /opencsw and > /opencsw-full, it's documented at ." > > It would have saved us confusion. Yeah. I added a note to http://www.opencsw.org/get-it/mirrors/ about the extra rsync URL. As always I should have done this in the first place :-( 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 Jan 1 14:15:11 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 1 Jan 2013 13:15:11 +0000 Subject: [csw-maintainers] Garbage collection in allpkgs In-Reply-To: <1339637B-7A57-4560-BC95-A07633AFBA49@opencsw.org> References: <9A41C992-9D7E-481C-BBFB-2C14E8080B47@opencsw.org> <1A4196A0-120D-4217-B0A4-646E30F34BAA@opencsw.org> <1339637B-7A57-4560-BC95-A07633AFBA49@opencsw.org> Message-ID: 2013/1/1 Dagobert Michelsen : > Yeah. I added a note to > http://www.opencsw.org/get-it/mirrors/ > about the extra rsync URL. As always I should have done this in the first place :-( Thanks. I'm a bit dubious about the name opencsw-full. It implies that the 'opencsw' direcory/URL is somehow not full (from the user's perspective), which is not true. 'opencsw-extra' or 'opencsw-allpkgs' would be a better name. I understand that you can get the information if you run 'rsync rsync://rsync.opencsw.org', but giving something a imprecise name and then explaining in a comment is worse than using a good name straight away is a better choice. Maciej From maciej at opencsw.org Tue Jan 1 14:19:55 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 1 Jan 2013 13:19:55 +0000 Subject: [csw-maintainers] Garbage collection in allpkgs In-Reply-To: References: <9A41C992-9D7E-481C-BBFB-2C14E8080B47@opencsw.org> <1A4196A0-120D-4217-B0A4-646E30F34BAA@opencsw.org> <1339637B-7A57-4560-BC95-A07633AFBA49@opencsw.org> Message-ID: 2013/1/1 Maciej (Matchek) Blizi?ski : > if you run 'rsync rsync://rsync.opencsw.org', but giving something a > imprecise name and then explaining in a comment is worse than using a > good name straight away is a better choice. Grammar fail, hah. I meant that it's better to give something a good self-explanatory name than to give it an imprecise one and then try to fix it by adding a comment. Maciej From bwalton at opencsw.org Tue Jan 1 17:39:41 2013 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 1 Jan 2013 16:39:41 +0000 Subject: [csw-maintainers] Solaris 8 packages in named releases In-Reply-To: References: <50D6FCEF.70508@opencsw.org> Message-ID: On Sat, Dec 29, 2012 at 2:08 PM, Peter Bonivart wrote: > On Sat, Dec 29, 2012 at 2:38 PM, Maciej (Matchek) Blizi?ski > wrote: >> 12/12/29 Ben Walton : >>> A very simple addition to pkgutil will make moving to a new release >>> more obvious: >>> >>> 1. Look for $catalog_url/UPGRADE_AVAILABLE (name is for discussion >>> purposes, not a real proposal). >>> 2. If found, display with pause before doing new package actions. >>> >>> So, when we're ready to have people move from Dublin to the next >>> release, we place this file and pkgutil will now tell people that >> >> I like the idea. It would make the catalogs a linked list. It could be >> also a field in the catalog file, similar to the one with the creation >> date. > > Dago suggested a long time ago support for a message-of-the-day > feature if files like ANNOUNCE/MOTD/CHANGES were present. We also have > talked about the RELEASE feature inside the catalogs, I think that was > in Kiel. The last one is already implemented in pkgutil but I don't > see that we publish the RELEASE line in our catalogs. > > I just wanted to bring those older ideas up again. > Yes, I guess the proposal I made is similar. If we settle on a preference, I'm still willing to implement. Thanks -Ben From bonivart at opencsw.org Tue Jan 1 22:50:51 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 1 Jan 2013 22:50:51 +0100 Subject: [csw-maintainers] Solaris 8 packages in named releases In-Reply-To: References: <50D6FCEF.70508@opencsw.org> Message-ID: On Tue, Jan 1, 2013 at 5:39 PM, Ben Walton wrote: > Yes, I guess the proposal I made is similar. If we settle on a > preference, I'm still willing to implement. It's exactly the same except there's no content to display, instead there's a generic message in pkgutil. I think it's been there (line ~2300 in pkgutil) for a year after Kiel but the catalogs don't use it. We also used to have a timestamp in the catalogs for some time. Bldcat supports putting this in. /peter From dam at opencsw.org Tue Jan 1 22:53:36 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 1 Jan 2013 22:53:36 +0100 Subject: [csw-maintainers] Solaris 8 packages in named releases In-Reply-To: References: <50D6FCEF.70508@opencsw.org> Message-ID: Hi Peter, Am 01.01.2013 um 22:50 schrieb Peter Bonivart : > On Tue, Jan 1, 2013 at 5:39 PM, Ben Walton wrote: >> Yes, I guess the proposal I made is similar. If we settle on a >> preference, I'm still willing to implement. > > It's exactly the same except there's no content to display, instead > there's a generic message in pkgutil. I think it's been there (line > ~2300 in pkgutil) for a year after Kiel but the catalogs don't use it. > We also used to have a timestamp in the catalogs for some time. Bldcat > supports putting this in. I remember to wanted to add this to the mirror freshness check but also noticed it was not in there. IIRC the catalogs are not build from the catalogs with bldcat, but directly from the database, so that code needs the addition of the fields also. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Wed Jan 2 00:14:43 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 2 Jan 2013 00:14:43 +0100 Subject: [csw-maintainers] Issue with csw-upload-pkg Message-ID: Hi folks, I updated some packages today and when I tried to upload the last batch I got the following error: > dam at login [login]:/home/dam/staging/build-01.Jan.2013 > ls -la > Gesamt 86446 > drwxr-xr-x 2 dam csw 20 Jan 2 00:09 . > drwxr-xr-x 86 dam csw 86 Jan 1 18:12 .. > -rw-r--r-- 1 dam csw 1009928 Jan 2 00:05 libicu_dev-50.1.1,REV=2013.01.01-SunOS5.10-i386-CSW.pkg.gz > -rw-r--r-- 1 dam csw 1023677 Jan 1 23:01 libicu_dev-50.1.1,REV=2013.01.01-SunOS5.10-sparc-CSW.pkg.gz > -rw-r--r-- 1 dam csw 16727883 Jan 2 00:05 libicudata50-50.1.1,REV=2013.01.01-SunOS5.10-i386-CSW.pkg.gz > -rw-r--r-- 1 dam csw 17048399 Jan 1 23:01 libicudata50-50.1.1,REV=2013.01.01-SunOS5.10-sparc-CSW.pkg.gz > -rw-r--r-- 1 dam csw 1982427 Jan 2 00:05 libicui18n50-50.1.1,REV=2013.01.01-SunOS5.10-i386-CSW.pkg.gz > -rw-r--r-- 1 dam csw 2131179 Jan 1 23:01 libicui18n50-50.1.1,REV=2013.01.01-SunOS5.10-sparc-CSW.pkg.gz > -rw-r--r-- 1 dam csw 57344 Jan 2 00:05 libicuio50-50.1.1,REV=2013.01.01-SunOS5.10-i386-CSW.pkg.gz > -rw-r--r-- 1 dam csw 59727 Jan 1 23:02 libicuio50-50.1.1,REV=2013.01.01-SunOS5.10-sparc-CSW.pkg.gz > -rw-r--r-- 1 dam csw 246501 Jan 2 00:05 libicule50-50.1.1,REV=2013.01.01-SunOS5.10-i386-CSW.pkg.gz > -rw-r--r-- 1 dam csw 251937 Jan 1 23:02 libicule50-50.1.1,REV=2013.01.01-SunOS5.10-sparc-CSW.pkg.gz > -rw-r--r-- 1 dam csw 54018 Jan 2 00:05 libiculx50-50.1.1,REV=2013.01.01-SunOS5.10-i386-CSW.pkg.gz > -rw-r--r-- 1 dam csw 54123 Jan 1 23:02 libiculx50-50.1.1,REV=2013.01.01-SunOS5.10-sparc-CSW.pkg.gz > -rw-r--r-- 1 dam csw 68756 Jan 2 00:06 libicutest50-50.1.1,REV=2013.01.01-SunOS5.10-i386-CSW.pkg.gz > -rw-r--r-- 1 dam csw 67703 Jan 1 23:02 libicutest50-50.1.1,REV=2013.01.01-SunOS5.10-sparc-CSW.pkg.gz > -rw-r--r-- 1 dam csw 180706 Jan 2 00:06 libicutu50-50.1.1,REV=2013.01.01-SunOS5.10-i386-CSW.pkg.gz > -rw-r--r-- 1 dam csw 181053 Jan 1 23:02 libicutu50-50.1.1,REV=2013.01.01-SunOS5.10-sparc-CSW.pkg.gz > -rw-r--r-- 1 dam csw 1366266 Jan 2 00:06 libicuuc50-50.1.1,REV=2013.01.01-SunOS5.10-i386-CSW.pkg.gz > -rw-r--r-- 1 dam csw 1538088 Jan 1 23:02 libicuuc50-50.1.1,REV=2013.01.01-SunOS5.10-sparc-CSW.pkg.gz > dam at login [login]:/home/dam/staging/build-01.Jan.2013 > csw-upload-pkg * > Processing 18 file(s). Please wait. > Traceback (most recent call last): > File "/home/dam/bin/csw-upload-pkg", line 513, in > uploader.Upload() > File "/home/dam/bin/csw-upload-pkg", line 175, in Upload > filename, self.catrel, arch, osrel, md5_sum) > File "/home/dam/bin/csw-upload-pkg", line 244, in _MatchSrv4ToCatalogs > catrel, arch, osrel, catalogname) > File "/home/dam/mgar/gar/v2/lib/python/rest.py", line 105, in Srv4ByCatalogAndCatalogname > data = urllib2.urlopen(url).read() > File "/opt/csw/lib/python/urllib2.py", line 126, in urlopen > return _opener.open(url, data, timeout) > File "/opt/csw/lib/python/urllib2.py", line 397, in open > response = meth(req, response) > File "/opt/csw/lib/python/urllib2.py", line 510, in http_response > 'http', request, response, code, msg, hdrs) > File "/opt/csw/lib/python/urllib2.py", line 435, in error > return self._call_chain(*args) > File "/opt/csw/lib/python/urllib2.py", line 369, in _call_chain > result = func(*args) > File "/opt/csw/lib/python/urllib2.py", line 518, in http_error_default > raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) > urllib2.HTTPError: HTTP Error 404: Not Found > zsh: 28186 exit 1 csw-upload-pkg * > dam at login [login]:/home/dam/staging/build-01.Jan.2013 > I find it really strange that a 404 is thrown, although I uploaded other packages fine a couple of seconds ago. This is in buildfarm.opencsw.org-access_log: > 213.178.77.178 - - [02/Jan/2013:00:12:58 +0100] "GET /pkgdb/rest/srv4/a8e22e75d4336b0f088619b458ed2f4e/ HTTP/1.1" 200 708 > 213.178.77.178 - - [02/Jan/2013:00:12:58 +0100] "GET /releases/srv4/a8e22e75d4336b0f088619b458ed2f4e/ HTTP/1.1" 401 401 > 213.178.77.178 - dam [02/Jan/2013:00:12:58 +0100] "GET /releases/srv4/a8e22e75d4336b0f088619b458ed2f4e/ HTTP/1.1" 200 270 > 213.178.77.178 - - [02/Jan/2013:00:12:59 +0100] "GET /pkgdb/rest/catalogs/unstable/i386/SunOS5.10/catalognames/libicu_dev/ HTTP/1.1" 200 704 > 213.178.77.178 - - [02/Jan/2013:00:12:59 +0100] "GET /pkgdb/rest/catalogs/unstable/i386/SunOS5.11/catalognames/libicu_dev/ HTTP/1.1" 200 704 > 213.178.77.178 - - [02/Jan/2013:00:13:00 +0100] "GET /pkgdb/rest/srv4/ac9958340e110bcd3fea87467703c1d3/ HTTP/1.1" 200 712 > 213.178.77.178 - - [02/Jan/2013:00:13:00 +0100] "GET /releases/srv4/ac9958340e110bcd3fea87467703c1d3/ HTTP/1.1" 401 401 > 213.178.77.178 - dam [02/Jan/2013:00:13:00 +0100] "GET /releases/srv4/ac9958340e110bcd3fea87467703c1d3/ HTTP/1.1" 200 272 > 213.178.77.178 - - [02/Jan/2013:00:13:00 +0100] "GET /pkgdb/rest/catalogs/unstable/sparc/SunOS5.10/catalognames/libicu_dev/ HTTP/1.1" 200 708 > 213.178.77.178 - - [02/Jan/2013:00:13:01 +0100] "GET /pkgdb/rest/catalogs/unstable/sparc/SunOS5.11/catalognames/libicu_dev/ HTTP/1.1" 200 708 > 213.178.77.178 - - [02/Jan/2013:00:13:02 +0100] "GET /pkgdb/rest/srv4/790f8f04e74fbca37e1d9eb581f34a45/ HTTP/1.1" 200 717 > 213.178.77.178 - - [02/Jan/2013:00:13:02 +0100] "GET /releases/srv4/790f8f04e74fbca37e1d9eb581f34a45/ HTTP/1.1" 401 401 > 213.178.77.178 - dam [02/Jan/2013:00:13:02 +0100] "GET /releases/srv4/790f8f04e74fbca37e1d9eb581f34a45/ HTTP/1.1" 200 276 > 213.178.77.178 - - [02/Jan/2013:00:13:02 +0100] "GET /pkgdb/rest/catalogs/unstable/i386/SunOS5.10/catalognames/libicudata50/ HTTP/1.1" 404 9 So it tries to look up the package which is not there, because libicudata50 is a new catalogname not in the catalog yet. Maciej, do you have an 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 maciej at opencsw.org Wed Jan 2 02:50:04 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 2 Jan 2013 01:50:04 +0000 Subject: [csw-maintainers] Issue with csw-upload-pkg In-Reply-To: References: Message-ID: Try this patch: index 24ace0a..194597d 100755 --- a/gar/v2/lib/python/csw_upload_pkg.py +++ b/gar/v2/lib/python/csw_upload_pkg.py @@ -240,8 +240,11 @@ class Srv4Uploader(object): for osrel in osrels: logging.debug("%s %s %s", catrel, arch, osrel) cat_key = (catrel, arch, osrel) - srv4_in_catalog = self._rest_client.Srv4ByCatalogAndCatalogname( - catrel, arch, osrel, catalogname) + try: + srv4_in_catalog = self._rest_client.Srv4ByCatalogAndCatalogname( + catrel, arch, osrel, catalogname) + except urllib2.HTTPError, e: + srv4_in_catalog = None if srv4_in_catalog: logging.debug("Catalog %s %s contains version %s of the %s package", arch, osrel, srv4_in_catalog["osrel"], catalogname) From dam at opencsw.org Wed Jan 2 10:04:02 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 2 Jan 2013 10:04:02 +0100 Subject: [csw-maintainers] Issue with csw-upload-pkg In-Reply-To: References: Message-ID: <50F2106E-8DAB-48B3-8AC6-BB774F80CD0A@opencsw.org> Hi Maciej, Am 02.01.2013 um 02:50 schrieb Maciej (Matchek) Blizi?ski : > Try this patch: > > index 24ace0a..194597d 100755 > --- a/gar/v2/lib/python/csw_upload_pkg.py > +++ b/gar/v2/lib/python/csw_upload_pkg.py > @@ -240,8 +240,11 @@ class Srv4Uploader(object): > for osrel in osrels: > logging.debug("%s %s %s", catrel, arch, osrel) > cat_key = (catrel, arch, osrel) > - srv4_in_catalog = self._rest_client.Srv4ByCatalogAndCatalogname( > - catrel, arch, osrel, catalogname) > + try: > + srv4_in_catalog = self._rest_client.Srv4ByCatalogAndCatalogname( > + catrel, arch, osrel, catalogname) > + except urllib2.HTTPError, e: > + srv4_in_catalog = None > if srv4_in_catalog: > logging.debug("Catalog %s %s contains version %s of the %s package", > arch, osrel, srv4_in_catalog["osrel"], catalogname) Looks like there is still something missing: dam at login [login]:/home/dam/staging/build-01.Jan.2013 > csw-upload-pkg *icu* Processing 18 file(s). Please wait. Traceback (most recent call last): File "/home/dam/bin/csw-upload-pkg", line 516, in uploader.Upload() File "/home/dam/bin/csw-upload-pkg", line 175, in Upload filename, self.catrel, arch, osrel, md5_sum) File "/home/dam/bin/csw-upload-pkg", line 246, in _MatchSrv4ToCatalogs except urllib2.HTTPError, e: NameError: global name 'urllib2' is not defined zsh: 12499 exit 1 csw-upload-pkg *icu* Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Wed Jan 2 10:34:29 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 2 Jan 2013 10:34:29 +0100 Subject: [csw-maintainers] Planned changes to GAR Message-ID: <9F78FD43-70CB-40AC-AE50-23001FA4D64F@opencsw.org> Hi folks, to make GAR even easier I would like to make a change in the naming of targets. In the past the idea was to have rules like pre-configure run after configure has been finished for all modulations and use pre-configure-modulated to be called after one modulation. However, this has proven not to be useful as there is virtually no usecase for things to be called after all modulations of a phase. Additionally, the global extract modulation was always a bit different as archives like .tar.gz are not unpacked there and adjustments must take special care as post-extract-modulated was also called for the global modulation. So the changes in detail are: 1. The targets pre-/post-extract, -configure, -build, -test and -install are replaced by what was called pre-/post-extract-modulated etc. This should make usage easier and less misleading. 2. The target pre-/post-extract are no longer called for the global modulation. This makes the usage more consistent with the other pre-/post calls as they are also called only in nonglobal modulation context and also removes the necessity to handle the global special case. For the global modulation the standard-rule applies that there is also pre-/post-extract- like pre-extract-global. What does this mean to your Makefile? * Remove the -modulated in the target names * Drop special handling in post-extract Hopefully not more is needed. The *-modulated targets will be kept for some time for compatibility. However, I don't know of a way to inform the user that he has a legacy *-modulated target. Thoughts? If everyone is ok with that I can merge my changes. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Wed Jan 2 10:39:37 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 2 Jan 2013 09:39:37 +0000 Subject: [csw-maintainers] Issue with csw-upload-pkg In-Reply-To: <50F2106E-8DAB-48B3-8AC6-BB774F80CD0A@opencsw.org> References: <50F2106E-8DAB-48B3-8AC6-BB774F80CD0A@opencsw.org> Message-ID: import urllib2 at the top -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Wed Jan 2 10:43:13 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 2 Jan 2013 10:43:13 +0100 Subject: [csw-maintainers] Issue with csw-upload-pkg In-Reply-To: References: <50F2106E-8DAB-48B3-8AC6-BB774F80CD0A@opencsw.org> Message-ID: Hi Maciej, Am 02.01.2013 um 10:39 schrieb Maciej (Matchek) Blizi?ski : > import urllib2 at the top Everytime you say something I look stupid ;-) It works now, so I guess I'll also commit the changes so it looks like I did 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 From maciej at opencsw.org Wed Jan 2 12:21:03 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 2 Jan 2013 11:21:03 +0000 Subject: [csw-maintainers] Issue with csw-upload-pkg In-Reply-To: References: <50F2106E-8DAB-48B3-8AC6-BB774F80CD0A@opencsw.org> Message-ID: 2013/1/2 Dagobert Michelsen : > It works now, so I guess I'll also commit the changes so it looks like I > did the fix :-) Cool. Sorry for not providing a 100% complete patch, I had little time to respond, so I opted for a quick imperfect response rather than no response at all. The problem was a general dilemma in programming: when you query for something and it's not there, should you return nothing or should you throw an error? Maybe you should return nothing (None / null / empty string / zero, etc) to let the program run further? But maybe you should throw an error, to make a distinction between e.g. an empty string and there not being anything at all? I think that the current API, which throws a HTTP exception when you ask for a name of a package, is a bad API, but I have to rethink the whole thing before I start to make any further changes in the code. I think I'll create a new exception class in the rest.py file and throw that. And/or maybe I'll add an option that instructs what do you want when the object you're looking for is missing, e.g. rest_client.GetFooBySomething(something="its name", on_missing=rest.RETURN_NONE) vs rest_client.GetFooBySomething(something="its name", on_missing=rest.THROW_EXCEPTION) The question is not language specific, so I'd like to ask Pythonistas as well as other language enthusiasts, what behavior and API would you prefer? Maciej From maciej at opencsw.org Wed Jan 2 12:25:22 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 2 Jan 2013 11:25:22 +0000 Subject: [csw-maintainers] Planned changes to GAR In-Reply-To: <9F78FD43-70CB-40AC-AE50-23001FA4D64F@opencsw.org> References: <9F78FD43-70CB-40AC-AE50-23001FA4D64F@opencsw.org> Message-ID: 2013/1/2 Dagobert Michelsen : > Thoughts? If everyone is ok with that I can merge my changes. Sounds great. The global modulation was often getting in my way when I was trying to write my own targets that e.g. expected files, and in the global modulation they weren't there at all, and I didn't know how to detect whether I'm in the global modulation or not. This will simplify things. From pfelecan at opencsw.org Wed Jan 2 15:31:41 2013 From: pfelecan at opencsw.org (pfelecan at opencsw.org) Date: Wed, 2 Jan 2013 15:31:41 +0100 (CET) Subject: [csw-maintainers] inoperant reinplace Message-ID: In the packaging recipe of TeXLive, http://gar.svn.sourceforge.net/gar/?rev=20008&view=rev, I have the following stanza: REINPLACE_WHEN_USRLOCAL = postinstall REINPLACE_USRLOCAL += /opt/csw/include/kpathsea/types.h I understood that the replacement file path is relative to the PKGROOT. However, no replacement is done at all. The file can be viewed on the build farm: ~pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw/include/kpathsea/types.h Is there a kind soul willing to have a look? TIA From dam at opencsw.org Wed Jan 2 15:50:13 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 2 Jan 2013 15:50:13 +0100 Subject: [csw-maintainers] inoperant reinplace In-Reply-To: References: Message-ID: <2082590D-311C-496F-A51C-74EF554E4CA0@opencsw.org> Hi Peter, Am 02.01.2013 um 15:31 schrieb pfelecan at opencsw.org: > In the packaging recipe of TeXLive, > http://gar.svn.sourceforge.net/gar/?rev=20008&view=rev, I have the > following stanza: > > REINPLACE_WHEN_USRLOCAL = postinstall > REINPLACE_USRLOCAL += /opt/csw/include/kpathsea/types.h > > I understood that the replacement file path is relative to the > PKGROOT. It is relative to DESTDIR in fact, I fixed the docs. The code is at https://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/gar.mk#L720 > However, no replacement is done at all. > > The file can be viewed on the build farm: > ~pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw/include/kpathsea/types.h > > Is there a kind soul willing to have a look? Sure, hang on, I become you and see what happens. Best regards -- Dago From dam at opencsw.org Wed Jan 2 19:38:46 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 2 Jan 2013 19:38:46 +0100 Subject: [csw-maintainers] inoperant reinplace In-Reply-To: <2082590D-311C-496F-A51C-74EF554E4CA0@opencsw.org> References: <2082590D-311C-496F-A51C-74EF554E4CA0@opencsw.org> Message-ID: <29626693-1279-4366-A14E-65586318A69F@opencsw.org> Hi Peter, Am 02.01.2013 um 15:50 schrieb Dagobert Michelsen: > Am 02.01.2013 um 15:31 schrieb pfelecan at opencsw.org: >> In the packaging recipe of TeXLive, >> http://gar.svn.sourceforge.net/gar/?rev=20008&view=rev, I have the >> following stanza: >> >> REINPLACE_WHEN_USRLOCAL = postinstall >> REINPLACE_USRLOCAL += /opt/csw/include/kpathsea/types.h >> >> I understood that the replacement file path is relative to the >> PKGROOT. > > It is relative to DESTDIR in fact, I fixed the docs. The code is at > https://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/gar.mk#L720 > >> However, no replacement is done at all. >> >> The file can be viewed on the build farm: >> ~pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw/include/kpathsea/types.h >> >> Is there a kind soul willing to have a look? > > Sure, hang on, I become you and see what happens. This looks mostly good, however, there is something really strange going on on the buildfarm: > root at ncsw [global]:/root > rm -rf /export/home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot; sync > root at ncsw [global]:/root > find /export/home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot > /export/home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot > /export/home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt > /export/home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw > /export/home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw/share > /export/home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw/share/texmf-dist > /export/home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw/share/texmf-dist/tex > /export/home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw/share/texmf-dist/tex/latex > /export/home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw/share/texmf-dist/tex/latex/csvsimple > /export/home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw/share/texmf-dist/tex/latex/csvsimple/csvsimple.sty > /export/home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw/share/texmf-dist/tex/latex/flagderiv > /export/home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw/share/texmf-dist/tex/latex/flagderiv/flagderiv.sty > /export/home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw/share/texmf-dist/tex/latex/parselines > /export/home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw/share/texmf-dist/tex/latex/parselines/parselines.sty > /export/home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw/share/texmf-dist/tex/latex/dramatist > /export/home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw/share/texmf-dist/tex/latex/dramatist/dramatist.sty > /export/home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw/share/texmf-dist/tex/latex/adfsymbols > /export/home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw/share/texmf-dist/tex/latex/adfsymbols/adfarrows.sty > /export/home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw/share/texmf-dist/tex/latex/adfsymbols/adfbullets.sty > /export/home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw/share/texmf-dist/tex/latex/adfsymbols/uarrowsadf.fd Is this probably related to my disablement of the ZIL? Anyway, this leads to the cookie for the phase not to be deleted during reinstall. Best regards -- Dago From pfelecan at opencsw.org Wed Jan 2 19:43:40 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 02 Jan 2013 19:43:40 +0100 Subject: [csw-maintainers] inoperant reinplace In-Reply-To: <29626693-1279-4366-A14E-65586318A69F@opencsw.org> (Dagobert Michelsen's message of "Wed, 2 Jan 2013 19:38:46 +0100") References: <2082590D-311C-496F-A51C-74EF554E4CA0@opencsw.org> <29626693-1279-4366-A14E-65586318A69F@opencsw.org> Message-ID: Dagobert Michelsen writes: > Anyway, this leads to the cookie for the phase not to be deleted during reinstall. Thank you for the analysis. What's your advice? How can I proceed? -- Peter From dam at opencsw.org Wed Jan 2 19:52:56 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 2 Jan 2013 19:52:56 +0100 Subject: [csw-maintainers] inoperant reinplace In-Reply-To: References: <2082590D-311C-496F-A51C-74EF554E4CA0@opencsw.org> <29626693-1279-4366-A14E-65586318A69F@opencsw.org> Message-ID: <6697A0DC-97E9-4880-AE3F-581BF785C5D0@opencsw.org> Hi Peter, Am 02.01.2013 um 19:43 schrieb Peter FELECAN : > Dagobert Michelsen writes: > >> Anyway, this leads to the cookie for the phase not to be deleted during reinstall. > > Thank you for the analysis. What's your advice? I am still looking, the turnaround on this recipe is BIG!! Best regards -- Dago From pfelecan at opencsw.org Wed Jan 2 21:09:32 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 02 Jan 2013 21:09:32 +0100 Subject: [csw-maintainers] inoperant reinplace In-Reply-To: <6697A0DC-97E9-4880-AE3F-581BF785C5D0@opencsw.org> (Dagobert Michelsen's message of "Wed, 2 Jan 2013 19:52:56 +0100") References: <2082590D-311C-496F-A51C-74EF554E4CA0@opencsw.org> <29626693-1279-4366-A14E-65586318A69F@opencsw.org> <6697A0DC-97E9-4880-AE3F-581BF785C5D0@opencsw.org> Message-ID: Dagobert Michelsen writes: > Hi Peter, > > Am 02.01.2013 um 19:43 schrieb Peter FELECAN : > >> Dagobert Michelsen writes: >> >>> Anyway, this leads to the cookie for the phase not to be deleted during reinstall. >> >> Thank you for the analysis. What's your advice? > > I am still looking, the turnaround on this recipe is BIG!! teTeX was big. TeXLive is enormous... -- Peter From dam at opencsw.org Wed Jan 2 22:23:23 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 2 Jan 2013 22:23:23 +0100 Subject: [csw-maintainers] inoperant reinplace In-Reply-To: <6697A0DC-97E9-4880-AE3F-581BF785C5D0@opencsw.org> References: <2082590D-311C-496F-A51C-74EF554E4CA0@opencsw.org> <29626693-1279-4366-A14E-65586318A69F@opencsw.org> <6697A0DC-97E9-4880-AE3F-581BF785C5D0@opencsw.org> Message-ID: <4747946B-A028-4780-8572-E0B36A91A852@opencsw.org> Hi Peter, Am 02.01.2013 um 19:52 schrieb Dagobert Michelsen: > Am 02.01.2013 um 19:43 schrieb Peter FELECAN : > >> Dagobert Michelsen writes: >> >>> Anyway, this leads to the cookie for the phase not to be deleted during reinstall. >> >> Thank you for the analysis. What's your advice? > > I am still looking, the turnaround on this recipe is BIG!! For now you can remove the cookie manually: rm ./work/solaris10-sparc/cookies/isa-sparcv8plus/post-install-reinplace-USRLOCAL I'll see that I get this fixed ASAP. Best regards -- Dago From dam at opencsw.org Thu Jan 3 13:55:55 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 3 Jan 2013 13:55:55 +0100 Subject: [csw-maintainers] Planned changes to GAR In-Reply-To: References: <9F78FD43-70CB-40AC-AE50-23001FA4D64F@opencsw.org> Message-ID: <142B1D84-CD28-41C3-B014-77501E10274C@opencsw.org> Hi, Am 02.01.2013 um 12:25 schrieb Maciej (Matchek) Blizi?ski : > 2013/1/2 Dagobert Michelsen : >> Thoughts? If everyone is ok with that I can merge my changes. > > Sounds great. The global modulation was often getting in my way when I > was trying to write my own targets that e.g. expected files, and in > the global modulation they weren't there at all, and I didn't know how > to detect whether I'm in the global modulation or not. This will > simplify things. With r20014 the changes are now in effect: https://sourceforge.net/apps/trac/gar/changeset/20014 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 Thu Jan 3 22:27:55 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Thu, 3 Jan 2013 22:27:55 +0100 Subject: [csw-maintainers] Checkpkg database update and new checkpkg tests Message-ID: Hi everybody, I proposed some time ago to implement new checkpkg checks in order to detect binaries not honouring the new direct binding constraint or having unused libraries dependencies: http://lists.opencsw.org/pipermail/maintainers/2012-August/017126.html and http://lists.opencsw.org/pipermail/maintainers/2012-August/017158.html Well, as always, it took longer than expected but with the help and advices of Maciej, I will eventually be able to commit the new tests on the main branch the day after tomorrow. These new checks will probably not change anything or trigger new warnings for your package, except if your build system doesn't correctly take into account the LD_OPTIONS default variable defined by GAR. In that case, you will probably have one the two new checkpkg errors documented here: http://wiki.opencsw.org/checkpkg-error-tags#no-direct-binding http://wiki.opencsw.org/checkpkg-error-tags#soname-unused An important note: ldd is used to gather some information about binaries. As ldd only work on binaries of the same architecture, this means that the package content analysis step can now only be done on a server with the same architecture as the package checked. The real check step however can still be performed from anywhere. These new checks required to add new information about symbols and linkage in the checkpkg database. This information can now easily be used to create others checks related to linkage, symbol and interfaces. For exemple I also added a new test to detect if a binary is using a forbidden version interface: http://wiki.opencsw.org/checkpkg-error-tags#forbidden-version-interface-dependencies Unfortunately this also requires to re-import all the existing packages to in the database to gather the symbols and linkage information from previous packages. I will begin this operation starting from now, it takes around 18h and can be done live without preventing maintainers to upload new packages. However, at the end, I will update the db schema version and commit the new code. After this, you will have to svn update your gar build system or it will complains about db schema version difference. The procedure followed is described on the wiki: http://wiki.opencsw.org/checkpkg#toc I'll keep you updated as soon as it is finished. If you have any question, don't hesitate. BTW, happy New Year to everybody ! Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Fri Jan 4 21:00:08 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Fri, 4 Jan 2013 21:00:08 +0100 Subject: [csw-maintainers] Checkpkg database update and new checkpkg tests In-Reply-To: References: Message-ID: Hi again everyone, The operation is now finished. You must now update your gar tree with the "mgar update" command to be able to upload packages again in the opencsw repository. If you don't, you will have this kind of error: "database.DatabaseError: Database schema does not match the application. Database contains: 8, the application expects: 7. Make sure your application sources are up to date." Everything should be fine but if you notice something wrong with new checks, don't hesitate to ping me. If I have time, I will gather some stats about the number of unecessary dependencies found in dublin, i.e. before the "-z ignore" flags was enabled in LD_OPTIONS in gar. Yann 2013/1/3 Yann Rouillard > Hi everybody, > > I proposed some time ago to implement new checkpkg checks in order to > detect binaries not honouring the new direct binding constraint or having > unused libraries dependencies: > http://lists.opencsw.org/pipermail/maintainers/2012-August/017126.html > and > http://lists.opencsw.org/pipermail/maintainers/2012-August/017158.html > > Well, as always, it took longer than expected but with the help and > advices of Maciej, I will eventually be able to commit the new tests on the > main branch the day after tomorrow. > > These new checks will probably not change anything or trigger new warnings > for your package, except if your build system doesn't correctly take into > account the LD_OPTIONS default variable defined by GAR. > In that case, you will probably have one the two new checkpkg errors > documented here: > http://wiki.opencsw.org/checkpkg-error-tags#no-direct-binding > http://wiki.opencsw.org/checkpkg-error-tags#soname-unused > > An important note: ldd is used to gather some information about binaries. > As ldd only work on binaries of the same architecture, this means that the > package content analysis step can now only be done on a server with the > same architecture as the package checked. > The real check step however can still be performed from anywhere. > > > These new checks required to add new information about symbols and linkage > in the checkpkg database. This information can now easily be used to create > others checks related to linkage, symbol and interfaces. > For exemple I also added a new test to detect if a binary is using a > forbidden version interface: > http://wiki.opencsw.org/checkpkg-error-tags#forbidden-version-interface-dependencies > > Unfortunately this also requires to re-import all the existing packages to > in the database to gather the symbols and linkage information from previous > packages. > I will begin this operation starting from now, it takes around 18h and can > be done live without preventing maintainers to upload new packages. > However, at the end, I will update the db schema version and commit the > new code. After this, you will have to svn update your gar build system or > it will complains about db schema version difference. > The procedure followed is described on the wiki: > http://wiki.opencsw.org/checkpkg#toc > > I'll keep you updated as soon as it is finished. > > If you have any question, don't hesitate. > > > BTW, happy New Year to everybody ! > > > Yann > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Sat Jan 5 16:47:42 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sat, 5 Jan 2013 16:47:42 +0100 Subject: [csw-maintainers] Checkpkg database update and new checkpkg tests In-Reply-To: References: Message-ID: Hi everyone, We had to fix some issues in the last commit, nothing really impacting but for safety reasons, we updated again the schema version to be sure nothing would be uploaded again using the previous code. So don't forget do update again your code base. Thanks again to Maciej for its time and help on this issue. Bye. Yann 2013/1/4 Yann Rouillard > Hi again everyone, > > The operation is now finished. > You must now update your gar tree with the "mgar update" command to be > able to upload packages again in the opencsw repository. > > If you don't, you will have this kind of error: > "database.DatabaseError: Database schema does not match the application. > Database contains: 8, the application expects: 7. Make sure your > application sources are up to date." > > Everything should be fine but if you notice something wrong with new > checks, don't hesitate to ping me. > > If I have time, I will gather some stats about the number of unecessary > dependencies found in dublin, i.e. before the "-z ignore" flags was enabled > in LD_OPTIONS in gar. > > > Yann > > > > 2013/1/3 Yann Rouillard > >> Hi everybody, >> >> I proposed some time ago to implement new checkpkg checks in order to >> detect binaries not honouring the new direct binding constraint or having >> unused libraries dependencies: >> http://lists.opencsw.org/pipermail/maintainers/2012-August/017126.html >> and >> http://lists.opencsw.org/pipermail/maintainers/2012-August/017158.html >> >> Well, as always, it took longer than expected but with the help and >> advices of Maciej, I will eventually be able to commit the new tests on the >> main branch the day after tomorrow. >> >> These new checks will probably not change anything or trigger new >> warnings for your package, except if your build system doesn't correctly >> take into account the LD_OPTIONS default variable defined by GAR. >> In that case, you will probably have one the two new checkpkg errors >> documented here: >> http://wiki.opencsw.org/checkpkg-error-tags#no-direct-binding >> http://wiki.opencsw.org/checkpkg-error-tags#soname-unused >> >> An important note: ldd is used to gather some information about binaries. >> As ldd only work on binaries of the same architecture, this means that the >> package content analysis step can now only be done on a server with the >> same architecture as the package checked. >> The real check step however can still be performed from anywhere. >> >> >> These new checks required to add new information about symbols and >> linkage in the checkpkg database. This information can now easily be used >> to create others checks related to linkage, symbol and interfaces. >> For exemple I also added a new test to detect if a binary is using a >> forbidden version interface: >> http://wiki.opencsw.org/checkpkg-error-tags#forbidden-version-interface-dependencies >> >> Unfortunately this also requires to re-import all the existing packages >> to in the database to gather the symbols and linkage information from >> previous packages. >> I will begin this operation starting from now, it takes around 18h and >> can be done live without preventing maintainers to upload new packages. >> However, at the end, I will update the db schema version and commit the >> new code. After this, you will have to svn update your gar build system or >> it will complains about db schema version difference. >> The procedure followed is described on the wiki: >> http://wiki.opencsw.org/checkpkg#toc >> >> I'll keep you updated as soon as it is finished. >> >> If you have any question, don't hesitate. >> >> >> BTW, happy New Year to everybody ! >> >> >> Yann >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ihsan at opencsw.org Sat Jan 5 20:24:02 2013 From: ihsan at opencsw.org (=?UTF-8?Q?=C4=B0hsan_Do=C4=9Fan?=) Date: Sat, 05 Jan 2013 20:24:02 +0100 Subject: [csw-maintainers] HEADS-UP: New Webmail Message-ID: <74216cfff90caa0b8b6c5ce637547f85@opencsw.org> Hi, Squirrelmail became old and was not up to date any with it's features and it's look and feel. I've replaced Squirrelmail with Roundcube, a more advance Webmail client. It can be reached at: https://mail.opencsw.org/ (Redirects to https://www.opencsw.org/mail/ ) Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From bwalton at opencsw.org Sat Jan 5 20:42:06 2013 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 5 Jan 2013 19:42:06 +0000 Subject: [csw-maintainers] HEADS-UP: New Webmail In-Reply-To: <74216cfff90caa0b8b6c5ce637547f85@opencsw.org> References: <74216cfff90caa0b8b6c5ce637547f85@opencsw.org> Message-ID: Looks great Ihsan; Thanks for the update! Thanks -Ben On Sat, Jan 5, 2013 at 7:24 PM, ?hsan Do?an wrote: > Hi, > > Squirrelmail became old and was not up to date any with it's features and > it's look and feel. I've replaced Squirrelmail with Roundcube, a more > advance Webmail client. > > It can be reached at: https://mail.opencsw.org/ (Redirects to > https://www.opencsw.org/mail/ ) > > > > > 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 dam at opencsw.org Sat Jan 5 23:09:04 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 5 Jan 2013 23:09:04 +0100 Subject: [csw-maintainers] HEADS-UP: New Webmail In-Reply-To: <74216cfff90caa0b8b6c5ce637547f85@opencsw.org> References: <74216cfff90caa0b8b6c5ce637547f85@opencsw.org> Message-ID: Hi Ihsan, Am 05.01.2013 um 20:24 schrieb ?hsan Do?an: > Squirrelmail became old and was not up to date any with it's features and it's look and feel. I've replaced Squirrelmail with Roundcube, a more advance Webmail client. > > It can be reached at: https://mail.opencsw.org/ (Redirects to https://www.opencsw.org/mail/ ) Excellent! This feels much more like it :-) Best regards -- Dago From bwalton at opencsw.org Sat Jan 5 23:48:46 2013 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 5 Jan 2013 22:48:46 +0000 Subject: [csw-maintainers] Some ideas about forthcoming camps In-Reply-To: References: Message-ID: Hi Dago, On Mon, Dec 31, 2012 at 9:26 PM, Dagobert Michelsen wrote: > Hi folks, > > in the past we had a lot of cool camps at maintainer locations. To attract more > maintainers to come to the camps I just got the idea of combining the camp with > some other larger-scale event like FOSDEM in Brussel or CCCC in Hamburg and > either pre- or postpend some extra days exclusively for OpenCSW. We could also > do this from time to time as events see fit. > > Thoughts? This could go both ways. There might be more maintainers able to make it because they're attending the other event, but it could also mean that they're only able to dedicate the weekend (at most) because they're attending the other event. It would be fantastic if everyone interested in attending the other event was able to take a large enough block of time to do both. Depending on employer, it could reduce travel expenses though. Thanks -Ben From maciej at opencsw.org Sun Jan 6 18:07:14 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 6 Jan 2013 17:07:14 +0000 Subject: [csw-maintainers] OpenCSW packaging screencast In-Reply-To: References: Message-ID: A new screencast is out: Modulations in GAR http://www.opencsw.org/2013/01/modulations-in-gar/ This time it's been done by Dago and me together, using a Google hangout. Comments are welcome! Maciej From bonivart at opencsw.org Sun Jan 6 18:20:37 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 6 Jan 2013 18:20:37 +0100 Subject: [csw-maintainers] OpenCSW packaging screencast In-Reply-To: References: Message-ID: On Sun, Jan 6, 2013 at 6:07 PM, Maciej (Matchek) Blizi?ski wrote: > A new screencast is out: Modulations in GAR > > http://www.opencsw.org/2013/01/modulations-in-gar/ > > This time it's been done by Dago and me together, using a Google > hangout. Comments are welcome! I've already seen it and I liked the interviewing style but showing the different screens below made the main text harder to read. I would have preferred switching between full screens instead of having miniatures at the bottom. /peter From maciej at opencsw.org Mon Jan 7 01:27:07 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 7 Jan 2013 00:27:07 +0000 Subject: [csw-maintainers] Old libnet deprecation Message-ID: I've removed the old libnet from the unstable hosts. There are still some packages that depend on it, so it is still in the catalog, but there's nothing that we would need at build time. Maciej From pfelecan at opencsw.org Mon Jan 7 09:03:45 2013 From: pfelecan at opencsw.org (pfelecan) Date: Mon, 07 Jan 2013 09:03:45 +0100 Subject: [csw-maintainers] pkgcheck phase is failing Message-ID: <05813f564f05c4ddd771de6fd69c4ab7@opencsw.org> Since last week the checking phase of the packages is quite fragile. The last error that I got follows: File "/home/pfelecan/opencsw/.buildsys/v2/gar//bin/checkpkg", line 197, in main() File "/home/pfelecan/opencsw/.buildsys/v2/gar//bin/checkpkg", line 120, in main stats_list = collector.CollectStatsFromFiles(file_list, None) File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py", line 506, in CollectStatsFromFiles stats.CollectStats(force=force_unpack) File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py", line 175, in CollectStats return self._CollectStats(register_files=register_files) File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py", line 211, in _CollectStats "ldd_info": dir_pkg.GetLddMinusRlines(), File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/inspective_package.py", line 405, in GetLddMinusRlines raise package.Error("%s returned an error: %s" % (args, stderr)) package.Error: ['ldd', '-Ur', '/tmp/pkg_Oqf0qy/CSWtexlive-binaries/root/opt/csw/bin/dvips'] returned an error: ldd: /tmp/pkg_Oqf0qy/CSWtexlive-binaries/root/opt/csw/bin/dvips: elf_getehdr: Format error: shdr table truncated gmake[1]: *** [pkgcheck] Error 2 gmake: *** [platforms-repackage] Error 2 Don't hesitate to tell me when a correction is made to start a new iteration on TeXLive. TIA N.B. I updated the .buildsys/v2 before the action. From maciej at opencsw.org Mon Jan 7 09:09:54 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 7 Jan 2013 08:09:54 +0000 Subject: [csw-maintainers] A systematic approach to package renames In-Reply-To: References: <1326654445-sup-2754@pinkfloyd.chass.utoronto.ca> Message-ID: I'd like to return to the topic of package renames. I initially described it here: http://lists.opencsw.org/pipermail/maintainers/2012-January/015908.html I think it's a great topic for a coding mini-project. The restful API to the package database makes it easy to get the data. I would imagine the utility working like this: track-renamed-packages legacy dublin kiel [ more catalogs ] Then for each combination of OS release + architecture, the application gets all the catalogs (potentially caches them locally), and for each package name, tracks down its renames. At the end of the run, the most important information it should display, is which _stub packages can now become marked incompatible with their original package. For instance: legacy: CSWlibfoo / libfoo dublin: CSWlibfoo_dev / libfoo_dev (depends on CSWlibfoo / libfoo_stub) CSWlibfoo1 / libfoo1 (depends on CSWlibfoo / libfoo_stub) CSWlibfoo / libfoo_stub kiel: CSWlibfoo_dev / libfoo_dev CSWlibfoo1 / libfoo1 (incompatible with CSWlibfoo / libfoo_stub; this makes sure that when you upgrade to kiel, and have te libfoo1 package, libfoo_stub gets removed) CSWlibfoo / libfoo_stub (deleted) So as you can see, we have 2 transitions to make before the package split is complete. It doesn't make sense for a human to try to track this. A computer program will to do it faster and more reliably. Is anyone interested in writing it? Maciej From yann at pleiades.fr.eu.org Mon Jan 7 09:29:41 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Mon, 7 Jan 2013 09:29:41 +0100 Subject: [csw-maintainers] pkgcheck phase is failing In-Reply-To: <05813f564f05c4ddd771de6fd69c4ab7@opencsw.org> References: <05813f564f05c4ddd771de6fd69c4ab7@opencsw.org> Message-ID: Hi Peter, It's not really the build system that seems to be wrong here. The elf header of the dvips binary seems to be corrupt and ldd, that is used to gather information on the binary, doesn't like it. Indeed: $ ldd -Ur /home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw/bin/dvips ldd: /home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw/bin/dvips: elf_getehdr: Format error: shdr table truncated $ ldd /home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw/bin/dvips ldd: /home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw/bin/dvips: elf_getehdr: Format error: shdr table truncated $ elfdump /home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw/bin/dvips /home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/pkgroot/opt/csw/bin/dvips: elf_getehdr failed: Format error: shdr table truncated Can you find the exact command line that was used to generate this binary ? Yann Le 7 janv. 2013 09:03, "pfelecan" a ?crit : > Since last week the checking phase of the packages is quite fragile. The > last error that I got follows: > > File "/home/pfelecan/opencsw/.**buildsys/v2/gar//bin/checkpkg"**, line > 197, in > main() > File "/home/pfelecan/opencsw/.**buildsys/v2/gar//bin/checkpkg"**, line > 120, in main > stats_list = collector.**CollectStatsFromFiles(file_**list, None) > File "/home/pfelecan/opencsw/.**buildsys/v2/lib/python/**package_stats.py", > line 506, in CollectStatsFromFiles > stats.CollectStats(force=**force_unpack) > File "/home/pfelecan/opencsw/.**buildsys/v2/lib/python/**package_stats.py", > line 175, in CollectStats > return self._CollectStats(register_**files=register_files) > File "/home/pfelecan/opencsw/.**buildsys/v2/lib/python/**package_stats.py", > line 211, in _CollectStats > "ldd_info": dir_pkg.GetLddMinusRlines(), > File "/home/pfelecan/opencsw/.**buildsys/v2/lib/python/**inspective_package.py", > line 405, in GetLddMinusRlines > raise package.Error("%s returned an error: %s" % (args, stderr)) > package.Error: ['ldd', '-Ur', '/tmp/pkg_Oqf0qy/CSWtexlive-** > binaries/root/opt/csw/bin/**dvips'] returned an error: ldd: > /tmp/pkg_Oqf0qy/CSWtexlive-**binaries/root/opt/csw/bin/**dvips: > elf_getehdr: Format error: shdr table truncated > > gmake[1]: *** [pkgcheck] Error 2 > gmake: *** [platforms-repackage] Error 2 > > Don't hesitate to tell me when a correction is made to start a new > iteration on TeXLive. > > TIA > > N.B. I updated the .buildsys/v2 before the action. > > ______________________________**_________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/**mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfelecan at opencsw.org Mon Jan 7 09:43:49 2013 From: pfelecan at opencsw.org (pfelecan) Date: Mon, 07 Jan 2013 09:43:49 +0100 Subject: [csw-maintainers] pkgcheck phase is failing In-Reply-To: <05813f564f05c4ddd771de6fd69c4ab7@opencsw.org> References: <05813f564f05c4ddd771de6fd69c4ab7@opencsw.org> Message-ID: On 2013-01-07 09:03, pfelecan wrote: > Since last week the checking phase of the packages is quite fragile. > The last error that I got follows: > > File "/home/pfelecan/opencsw/.buildsys/v2/gar//bin/checkpkg", line > 197, in > main() > File "/home/pfelecan/opencsw/.buildsys/v2/gar//bin/checkpkg", line > 120, in main > stats_list = collector.CollectStatsFromFiles(file_list, None) > File > "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py", > line 506, in CollectStatsFromFiles > stats.CollectStats(force=force_unpack) > File > "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py", > line 175, in CollectStats > return self._CollectStats(register_files=register_files) > File > "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py", > line 211, in _CollectStats > "ldd_info": dir_pkg.GetLddMinusRlines(), > File > > "/home/pfelecan/opencsw/.buildsys/v2/lib/python/inspective_package.py", > line 405, in GetLddMinusRlines > raise package.Error("%s returned an error: %s" % (args, stderr)) > package.Error: ['ldd', '-Ur', > '/tmp/pkg_Oqf0qy/CSWtexlive-binaries/root/opt/csw/bin/dvips'] > returned > an error: ldd: > /tmp/pkg_Oqf0qy/CSWtexlive-binaries/root/opt/csw/bin/dvips: > elf_getehdr: Format error: shdr table truncated > > gmake[1]: *** [pkgcheck] Error 2 > gmake: *** [platforms-repackage] Error 2 > > Don't hesitate to tell me when a correction is made to start a new > iteration on TeXLive. > > TIA > > N.B. I updated the .buildsys/v2 before the action. Additionnal information: - this error arises only for the SPARC instance of this executable - the executable is available as: ~pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/install-isa-sparcv8plus/opt/csw/bin/dvips - the error arises on all the executable files in the directory containing the above file From pfelecan at opencsw.org Mon Jan 7 10:03:21 2013 From: pfelecan at opencsw.org (pfelecan) Date: Mon, 07 Jan 2013 10:03:21 +0100 Subject: [csw-maintainers] pkgcheck phase is failing In-Reply-To: References: <05813f564f05c4ddd771de6fd69c4ab7@opencsw.org> Message-ID: <4c653f647591e4c1f299373a154c7f6c@opencsw.org> On 2013-01-07 09:43, pfelecan wrote: > On 2013-01-07 09:03, pfelecan wrote: >> Since last week the checking phase of the packages is quite fragile. >> The last error that I got follows: >> >> File "/home/pfelecan/opencsw/.buildsys/v2/gar//bin/checkpkg", line >> 197, in >> main() >> File "/home/pfelecan/opencsw/.buildsys/v2/gar//bin/checkpkg", line >> 120, in main >> stats_list = collector.CollectStatsFromFiles(file_list, None) >> File >> "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py", >> line 506, in CollectStatsFromFiles >> stats.CollectStats(force=force_unpack) >> File >> "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py", >> line 175, in CollectStats >> return self._CollectStats(register_files=register_files) >> File >> "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py", >> line 211, in _CollectStats >> "ldd_info": dir_pkg.GetLddMinusRlines(), >> File >> >> "/home/pfelecan/opencsw/.buildsys/v2/lib/python/inspective_package.py", >> line 405, in GetLddMinusRlines >> raise package.Error("%s returned an error: %s" % (args, stderr)) >> package.Error: ['ldd', '-Ur', >> '/tmp/pkg_Oqf0qy/CSWtexlive-binaries/root/opt/csw/bin/dvips'] >> returned >> an error: ldd: >> /tmp/pkg_Oqf0qy/CSWtexlive-binaries/root/opt/csw/bin/dvips: >> elf_getehdr: Format error: shdr table truncated >> >> gmake[1]: *** [pkgcheck] Error 2 >> gmake: *** [platforms-repackage] Error 2 >> >> Don't hesitate to tell me when a correction is made to start a new >> iteration on TeXLive. >> >> TIA >> >> N.B. I updated the .buildsys/v2 before the action. > > Additionnal information: > > - this error arises only for the SPARC instance of this executable > - the executable is available as: > > > ~pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/install-isa-sparcv8plus/opt/csw/bin/dvips > - the error arises on all the executable files in the directory > containing the above file The executable is obtained as follows: libtool: link: /opt/csw/bin/gcc-4.7 -Wimplicit -Wreturn-type -Wdeclaration-after-statement -Wno-unknown-pragmas -O2 -pipe -mcpu=v9 -std=gnu99 -D_XPG6 -mcpu=v9 -o .libs/dvips bbox.o color.o dopage.o dosection.o dospecial.o download.o dpicheck.o drawPS.o dviinput.o dvips.o emspecial.o finclude.o fontdef.o header.o hps.o loadfont.o output.o papersiz.o pprescan.o prescan.o repack.o resident.o scalewidth.o scanpage.o search.o skippage.o t1part.o tfmload.o unpack.o virtualfont.o writet1.o -L/opt/csw/lib /home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/build-isa-sparcv8plus/objdir/texk/kpathsea/.libs/libkpathsea.so -lm -R/opt/csw/lib From pfelecan at opencsw.org Mon Jan 7 10:26:43 2013 From: pfelecan at opencsw.org (pfelecan) Date: Mon, 07 Jan 2013 10:26:43 +0100 Subject: [csw-maintainers] pkgcheck phase is failing In-Reply-To: References: <05813f564f05c4ddd771de6fd69c4ab7@opencsw.org> Message-ID: On 2013-01-07 09:43, pfelecan wrote: > On 2013-01-07 09:03, pfelecan wrote: >> Since last week the checking phase of the packages is quite fragile. >> The last error that I got follows: >> >> File "/home/pfelecan/opencsw/.buildsys/v2/gar//bin/checkpkg", line >> 197, in >> main() >> File "/home/pfelecan/opencsw/.buildsys/v2/gar//bin/checkpkg", line >> 120, in main >> stats_list = collector.CollectStatsFromFiles(file_list, None) >> File >> "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py", >> line 506, in CollectStatsFromFiles >> stats.CollectStats(force=force_unpack) >> File >> "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py", >> line 175, in CollectStats >> return self._CollectStats(register_files=register_files) >> File >> "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py", >> line 211, in _CollectStats >> "ldd_info": dir_pkg.GetLddMinusRlines(), >> File >> >> "/home/pfelecan/opencsw/.buildsys/v2/lib/python/inspective_package.py", >> line 405, in GetLddMinusRlines >> raise package.Error("%s returned an error: %s" % (args, stderr)) >> package.Error: ['ldd', '-Ur', >> '/tmp/pkg_Oqf0qy/CSWtexlive-binaries/root/opt/csw/bin/dvips'] >> returned >> an error: ldd: >> /tmp/pkg_Oqf0qy/CSWtexlive-binaries/root/opt/csw/bin/dvips: >> elf_getehdr: Format error: shdr table truncated >> >> gmake[1]: *** [pkgcheck] Error 2 >> gmake: *** [platforms-repackage] Error 2 >> >> Don't hesitate to tell me when a correction is made to start a new >> iteration on TeXLive. >> >> TIA >> >> N.B. I updated the .buildsys/v2 before the action. > > Additionnal information: > > - this error arises only for the SPARC instance of this executable > - the executable is available as: > > > ~pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/install-isa-sparcv8plus/opt/csw/bin/dvips > - the error arises on all the executable files in the directory > containing the above file the last statement is incorrect; the error arises only on 3 executables: - xdvi-xaw - luatex - dvips From pfelecan at opencsw.org Mon Jan 7 11:30:30 2013 From: pfelecan at opencsw.org (pfelecan) Date: Mon, 07 Jan 2013 11:30:30 +0100 Subject: [csw-maintainers] pkgcheck phase is failing In-Reply-To: References: <05813f564f05c4ddd771de6fd69c4ab7@opencsw.org> Message-ID: On 2013-01-07 10:26, pfelecan wrote: > On 2013-01-07 09:43, pfelecan wrote: >> On 2013-01-07 09:03, pfelecan wrote: >>> Since last week the checking phase of the packages is quite >>> fragile. >>> The last error that I got follows: >>> >>> File "/home/pfelecan/opencsw/.buildsys/v2/gar//bin/checkpkg", >>> line >>> 197, in >>> main() >>> File "/home/pfelecan/opencsw/.buildsys/v2/gar//bin/checkpkg", >>> line >>> 120, in main >>> stats_list = collector.CollectStatsFromFiles(file_list, None) >>> File >>> "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py", >>> line 506, in CollectStatsFromFiles >>> stats.CollectStats(force=force_unpack) >>> File >>> "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py", >>> line 175, in CollectStats >>> return self._CollectStats(register_files=register_files) >>> File >>> "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py", >>> line 211, in _CollectStats >>> "ldd_info": dir_pkg.GetLddMinusRlines(), >>> File >>> >>> "/home/pfelecan/opencsw/.buildsys/v2/lib/python/inspective_package.py", >>> line 405, in GetLddMinusRlines >>> raise package.Error("%s returned an error: %s" % (args, >>> stderr)) >>> package.Error: ['ldd', '-Ur', >>> '/tmp/pkg_Oqf0qy/CSWtexlive-binaries/root/opt/csw/bin/dvips'] >>> returned >>> an error: ldd: >>> /tmp/pkg_Oqf0qy/CSWtexlive-binaries/root/opt/csw/bin/dvips: >>> elf_getehdr: Format error: shdr table truncated >>> >>> gmake[1]: *** [pkgcheck] Error 2 >>> gmake: *** [platforms-repackage] Error 2 >>> >>> Don't hesitate to tell me when a correction is made to start a new >>> iteration on TeXLive. >>> >>> TIA >>> >>> N.B. I updated the .buildsys/v2 before the action. >> >> Additionnal information: >> >> - this error arises only for the SPARC instance of this executable >> - the executable is available as: >> >> >> ~pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/install-isa-sparcv8plus/opt/csw/bin/dvips >> - the error arises on all the executable files in the directory >> containing the above file > > the last statement is incorrect; the error arises only on 3 > executables: > > - xdvi-xaw > - luatex > - dvips and the explanation is that in the turmoil I left binaries in the in place replacements rules (REINPLACE) which is a no no... sorry for the noise From maciej at opencsw.org Mon Jan 7 16:23:23 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 7 Jan 2013 15:23:23 +0000 Subject: [csw-maintainers] pkgcheck phase is failing In-Reply-To: References: <05813f564f05c4ddd771de6fd69c4ab7@opencsw.org> Message-ID: 2013/1/7 pfelecan : > and the explanation is that in the turmoil I left binaries in the in place > replacements rules (REINPLACE) which is a no no... So checkpkg did the right thing in failing, but the error message displayed wasn't terribly helpful. Yann, could we display an informative message? I know that there's a lot you can already see: that it's ldd run that failed, so it feels natural to try to execute the same command and see what happens. Since people often freak out when they see a seemingly unintentional stack trace, adding two sentences of guidance would be good. (Of course, it's essential for debugging to re-raise the exception and display the stack trace.)\ What do you think? Maciej From maciej at opencsw.org Mon Jan 7 16:26:50 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 7 Jan 2013 15:26:50 +0000 Subject: [csw-maintainers] Proposal: switch off autostarting of services Message-ID: We're currently defaulting to automatically start services after installation. For example, when you install MySQL packages, the database starts up without any additional commands. For MySQL this is harmless enough, but as a general rule it goes against intuitions and expectations of sysadmins. I propose that we change the default to not start services by default. Thoughts? Maciej From ihsan at opencsw.org Mon Jan 7 16:48:11 2013 From: ihsan at opencsw.org (=?UTF-8?Q?=C4=B0hsan_Do=C4=9Fan?=) Date: Mon, 07 Jan 2013 16:48:11 +0100 Subject: [csw-maintainers] Proposal: switch off autostarting of services Message-ID: <7a97dd2f5e692a537557871493fc735d@opencsw.org> Am 07.01.2013 16:26, schrieb Maciej Blizi?ski: > We're currently defaulting to automatically start services after > installation. For example, when you install MySQL packages, the > database starts up without any additional commands. For MySQL this is > harmless enough, but as a general rule it goes against intuitions and > expectations of sysadmins. > > I propose that we change the default to not start services by > default. I fully agree on that. I've set on all my machines the autostart to "no" and as most admins, I don't like services starting automatically. Most package repositories are working this way. Our target are not the end-users. Our users are admins and even those who using the first time Solaris and OpenCSW can handle services, that do not start automatically. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From yann at pleiades.fr.eu.org Mon Jan 7 17:57:57 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Mon, 7 Jan 2013 17:57:57 +0100 Subject: [csw-maintainers] pkgcheck phase is failing In-Reply-To: References: <05813f564f05c4ddd771de6fd69c4ab7@opencsw.org> Message-ID: I think that makes a lot of sense. I suppose we should define some exception class whose instances would at least contain the error message and the information message. Any check could use this exception or a sub-class when they need to raise an error. Now the question is just: where is the central place to catch these exceptions and display the message ? I didn't check yet but I am sure you already have an idea. For the stack trace, we could display it only in debug mode. Yann Le 7 janv. 2013 16:24, "Maciej (Matchek) Blizi?ski" a ?crit : > 2013/1/7 pfelecan : > > and the explanation is that in the turmoil I left binaries in the in > place > > replacements rules (REINPLACE) which is a no no... > > So checkpkg did the right thing in failing, but the error message > displayed wasn't terribly helpful. > > Yann, could we display an informative message? I know that there's a > lot you can already see: that it's ldd run that failed, so it feels > natural to try to execute the same command and see what happens. Since > people often freak out when they see a seemingly unintentional stack > trace, adding two sentences of guidance would be good. (Of course, > it's essential for debugging to re-raise the exception and display the > stack trace.)\ > > What do you think? > > Maciej > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Mon Jan 7 18:19:16 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 7 Jan 2013 17:19:16 +0000 Subject: [csw-maintainers] pkgcheck phase is failing In-Reply-To: References: <05813f564f05c4ddd771de6fd69c4ab7@opencsw.org> Message-ID: 2013/1/7 Yann Rouillard : > I think that makes a lot of sense. > > I suppose we should define some exception class whose instances would at > least contain the error message and the information message. > Any check could use this exception or a sub-class when they need to raise an > error. Each module can define its exceptions; I was following this rule most of the time so far. But for simplicity, we should not change the type of exception we're raising, only display an error message and propagate the exception as-is. This way we keep the code simpler and not bury ourselves in an exception handling jungle. > Now the question is just: where is the central place to catch these > exceptions and display the message ? I would like to avoid having this. If anything goes wrong, I want to crash early and loud. > I didn't check yet but I am sure you already have an idea. > > For the stack trace, we could display it only in debug mode. I'm thinking that if we don't display the stack trace, we won't be able to ask for it right away (?can you show me the stack trace?? -- ?what stack trace??). Right now people can immediately copy/paste the stack trace and quickly give us idea about what's going on. Without the stack trace, we'll still have to go and ask people to re-run in debug mode, then copy and paste. Why add an additional middle step? Maciej From dam at opencsw.org Mon Jan 7 19:24:58 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 7 Jan 2013 19:24:58 +0100 Subject: [csw-maintainers] Old libnet deprecation In-Reply-To: References: Message-ID: <57A46AC7-B524-4225-ADAE-0CA763F2E9FF@opencsw.org> Hi Maciej, Am 07.01.2013 um 01:27 schrieb Maciej (Matchek) Blizi?ski: > I've removed the old libnet from the unstable hosts. There are still > some packages that depend on it, so it is still in the catalog, but > there's nothing that we would need at build time. Ok. Best regards -- Dago From dam at opencsw.org Mon Jan 7 19:54:53 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 7 Jan 2013 19:54:53 +0100 Subject: [csw-maintainers] Proposal: switch off autostarting of services In-Reply-To: <7a97dd2f5e692a537557871493fc735d@opencsw.org> References: <7a97dd2f5e692a537557871493fc735d@opencsw.org> Message-ID: Hi folks, Am 07.01.2013 um 16:48 schrieb ?hsan Do?an : > Am 07.01.2013 16:26, schrieb Maciej Blizi?ski: >> We're currently defaulting to automatically start services after >> installation. For example, when you install MySQL packages, the >> database starts up without any additional commands. For MySQL this is >> harmless enough, but as a general rule it goes against intuitions and >> expectations of sysadmins. >> >> I propose that we change the default to not start services by default. > > I fully agree on that. I've set on all my machines the autostart to "no" and as most admins, I don't like services starting automatically. Most package repositories are working this way. > > Our target are not the end-users. Our users are admins and even those who using the first time Solaris and OpenCSW can handle services, that do not start automatically. Definitely. IMHO we should just reverse the default for autostart_daemons in csw.conf to be off by default. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From bwalton at opencsw.org Mon Jan 7 20:27:55 2013 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 7 Jan 2013 19:27:55 +0000 Subject: [csw-maintainers] Proposal: switch off autostarting of services In-Reply-To: References: <7a97dd2f5e692a537557871493fc735d@opencsw.org> Message-ID: +1 for switching the default...we should send a notice to the user list as a courtesy though. Thanks -Ben On Jan 7, 2013 6:54 PM, "Dagobert Michelsen" wrote: > Hi folks, > > Am 07.01.2013 um 16:48 schrieb ?hsan Do?an : > > Am 07.01.2013 16:26, schrieb Maciej Blizi?ski: > >> We're currently defaulting to automatically start services after > >> installation. For example, when you install MySQL packages, the > >> database starts up without any additional commands. For MySQL this is > >> harmless enough, but as a general rule it goes against intuitions and > >> expectations of sysadmins. > >> > >> I propose that we change the default to not start services by default. > > > > I fully agree on that. I've set on all my machines the autostart to "no" > and as most admins, I don't like services starting automatically. Most > package repositories are working this way. > > > > Our target are not the end-users. Our users are admins and even those > who using the first time Solaris and OpenCSW can handle services, that do > not start automatically. > > Definitely. IMHO we should just reverse the default for autostart_daemons > in csw.conf > to be off by default. > > > 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 yann at pleiades.fr.eu.org Mon Jan 7 20:56:58 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Mon, 7 Jan 2013 20:56:58 +0100 Subject: [csw-maintainers] pkgcheck phase is failing In-Reply-To: References: <05813f564f05c4ddd771de6fd69c4ab7@opencsw.org> Message-ID: 2013/1/7 Maciej (Matchek) Blizi?ski > 2013/1/7 Yann Rouillard : > > I think that makes a lot of sense. > > > > I suppose we should define some exception class whose instances would at > > least contain the error message and the information message. > > Any check could use this exception or a sub-class when they need to > raise an > > error. > > Each module can define its exceptions; I was following this rule most > of the time so far. But for simplicity, we should not change the type > of exception we're raising, only display an error message and > propagate the exception as-is. This way we keep the code simpler and > not bury ourselves in an exception handling jungle. > You think it will be so complicated if we just use a parent class for all exceptions (or at least these kind of exceptions) ? > > Now the question is just: where is the central place to catch these > > exceptions and display the message ? > > I would like to avoid having this. If anything goes wrong, I want to > crash early and loud. > I find cleaner that the function just raises exceptions and that the caller decides how to handle the message. I find this more flexible, it allows us to easily make change to the way we handle these errors if this is done in a one place. About the need to crash early, what is exactly the risk ? After your comment, I thought that for exemple an intermediate function might catch exceptions too broadly and prevents the exception from being properly handled. I am not sure if this is a big problem. We could easily search for this kind of exception catch. At least, I think we should create some common function used by each module to print the error message so we keep the advantage of not duplicating the code used to display the error. > > > I didn't check yet but I am sure you already have an idea. > > > > For the stack trace, we could display it only in debug mode. > > I'm thinking that if we don't display the stack trace, we won't be > able to ask for it right away (?can you show me the stack trace?? -- > ?what stack trace??). Right now people can immediately copy/paste the > stack trace and quickly give us idea about what's going on. Without > the stack trace, we'll still have to go and ask people to re-run in > debug mode, then copy and paste. Why add an additional middle step? > Well I understood that the idea was not freak people. I think that a stack trace can give the impression that the error was not properly handled and can prevent people from really looking at the output and see the informative message. If the stack trace is really long, you might even miss the informative message. We can try to lay out the message so we don't miss the informative part, but we would need to generate the traceback ourself to be able to display it before the informative message. That would advocate even more to use some common code to display the error. Well, that's just my opinion. I am less versed in python that you are. Yann > > Maciej > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Mon Jan 7 21:53:23 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Mon, 7 Jan 2013 21:53:23 +0100 Subject: [csw-maintainers] Proposal: switch off autostarting of services In-Reply-To: <7a97dd2f5e692a537557871493fc735d@opencsw.org> References: <7a97dd2f5e692a537557871493fc735d@opencsw.org> Message-ID: Hi, I also agree about disabling auto-start after installation. But by the way, are we talking only about auto-starting after first installation or also after upgrade ? Under Solaris 10, autostart_daemons=no will only prevent daemons from auto-starting at first installation. After, the previous state of the daemon will be restored no matter what is the value of autostart_daemons. I personnally like this behaviour (and in fact proposed the patch for it): after I correctly configured a service, I prefer it to be automatically restarted on upgrade, but I put the subject on the table so we're sure to agree on the same thing. Yann Am 07.01.2013 16:26, schrieb Maciej Blizi?ski: > We're currently defaulting to automatically start services after > installation. For example, when you install MySQL packages, the > database starts up without any additional commands. For MySQL this is > harmless enough, but as a general rule it goes against intuitions and > expectations of sysadmins. > > I propose that we change the default to not start services by default. > I fully agree on that. I've set on all my machines the autostart to "no" and as most admins, I don't like services starting automatically. Most package repositories are working this way. Our target are not the end-users. Our users are admins and even those who using the first time Solaris and OpenCSW can handle services, that do not start automatically. 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. ::. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Tue Jan 8 10:10:41 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 8 Jan 2013 09:10:41 +0000 Subject: [csw-maintainers] pkgcheck phase is failing In-Reply-To: References: <05813f564f05c4ddd771de6fd69c4ab7@opencsw.org> Message-ID: 2013/1/7 Yann Rouillard : > > 2013/1/7 Maciej (Matchek) Blizi?ski > >> 2013/1/7 Yann Rouillard : >> > I think that makes a lot of sense. >> > >> > I suppose we should define some exception class whose instances would at >> > least contain the error message and the information message. >> > Any check could use this exception or a sub-class when they need to >> > raise an >> > error. >> >> Each module can define its exceptions; I was following this rule most >> of the time so far. But for simplicity, we should not change the type >> of exception we're raising, only display an error message and >> propagate the exception as-is. This way we keep the code simpler and >> not bury ourselves in an exception handling jungle. > > > You think it will be so complicated if we just use a parent class for all > exceptions (or at least these kind of exceptions) ? No, for custom exceptions we should use specific classes. For example, in the opencsw.py file https://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/python/opencsw.py ...we're using PackageError, and it's good that way. I looked at the code that runs ldd: https://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/python/inspective_package.py#L289 ...and I see that it raises the non-specific package.Error. I think that this exception is specific to running ldd. So we could either declare a new exception in package.py, or create a new exception in inspective_package.py: class LddExecutionError(package.Error): """Problem while running ldd.""" >> > Now the question is just: where is the central place to catch these >> > exceptions and display the message ? >> >> I would like to avoid having this. If anything goes wrong, I want to >> crash early and loud. > > > I find cleaner that the function just raises exceptions and that the caller > decides how to handle the message. Sure. Is that different from what I was saying? > I find this more flexible, it allows us to easily make change to the way we > handle these errors if this is done in a one place. Generally, the place where you should handle an exception depends on the exception, no? > About the need to crash early, what is exactly the risk ? What's the risk of not crashing early when there's a problem? Eric Raymond wrote it best: http://www.faqs.org/docs/artu/ch01s06.html#id2878538 "It's best when software can cope with unexpected conditions by adapting to them, but the worst kinds of bugs are those in which the repair doesn't succeed and the problem quietly causes corruption that doesn't show up until much later." > After your > comment, I thought that for example an intermediate function might catch > exceptions too broadly and prevents the exception from being properly > handled. I am not sure if this is a big problem. We could easily search for > this kind of exception catch. > > At least, I think we should create some common function used by each module > to print the error message so we keep the advantage of not duplicating the > code used to display the error. We have that already, the code to display the error is simply: logging.fatal("...") Or you can roll the message right into the exception itself. >> > I didn't check yet but I am sure you already have an idea. >> > >> > For the stack trace, we could display it only in debug mode. >> >> I'm thinking that if we don't display the stack trace, we won't be >> able to ask for it right away (?can you show me the stack trace?? -- >> ?what stack trace??). Right now people can immediately copy/paste the >> stack trace and quickly give us idea about what's going on. Without >> the stack trace, we'll still have to go and ask people to re-run in >> debug mode, then copy and paste. Why add an additional middle step? > > > Well I understood that the idea was not freak people. Let me illustrate. Good stack trace (does not freak people out that much): Traceback (most recent call last): File "./example.py", line 13, in main() File "./example.py", line 10, in main raise IntentionalError("Yes, I meant to do throw this exception, " __main__.IntentionalError: Yes, I meant to do throw this exception, and it means that foo is probably barred. Bad stack trace (freaks people out): Traceback (most recent call last): File "./example_bad.py", line 12, in main() File "./example_bad.py", line 10, in main raise IOError() IOError > I think that a stack trace can give the impression that the error was not > properly handled and can prevent people from really looking at the output > and see the informative message. If we had millions of casual users, I would agree. But our user base is rather technically savvy, dealing with breakages day to day, so we should be able to educate them that the stack trace is something useful to show to the developer. > If the stack trace is really long, you might even miss the informative > message. I think that shouldn't happen, the error message from inside the exception gets displayed at the very bottom of the trace. > We can try to lay out the message so we don't miss the informative part, but > we would need to generate the traceback ourself to be able to display it > before the informative message. If anything, we should display it below, not above, no? What's wrong with the default stack trace, how own stack trace will be better? > That would advocate even more to use some > common code to display the error. Right now we say simply: raise WhatWentWrong("and why"). How do you improve on that? It doesn't look to me that it can be shorter than that. Maciej From pfelecan at opencsw.org Tue Jan 8 16:13:43 2013 From: pfelecan at opencsw.org (pfelecan) Date: Tue, 08 Jan 2013 16:13:43 +0100 Subject: [csw-maintainers] reminder on contributing on recipes Message-ID: I would like to remind the good usage when contributing on recipes maintained by others: - The maintainer is retired: On the maintainers mailing list, announce your intention to work on the recipe and eventually take up the maintenance. When you have a working recipe and generated the package, upload-it and you became the active maintainer. - The maintainer is inactive: Contact him before and, after his accord or a reasonable time without an answer, usually 1 to 2 weeks is a good measure, proceed as described above. - The maintainer is active, i.e. answers to bug reports, messages sent on the maintainers mailing list or private messages: Work on a branch, see http://wiki.opencsw.org/branching-from-trunk, and when you obtain satisfying results explain your changes to the maintainer such as he can use what you've done and/or, if you obtain his explicit permission, merge your modifications on the trunk. There are, of course, possible variations on contributing to recipes maintained by others, and we should discuss them. However, I hope that the above can be used as a foundation of a possible policy definition on this issue. Thank you From pfelecan at opencsw.org Wed Jan 9 09:12:06 2013 From: pfelecan at opencsw.org (pfelecan) Date: Wed, 09 Jan 2013 09:12:06 +0100 Subject: [csw-maintainers] working on guile Message-ID: <9b9e0e385db249df40c6e0b7d114456c@opencsw.org> I started an upgrade work on guile http://www.opencsw.org/packages/CSWguile/ on a specific branch: 2.0.7 The results are quite promising. If there are people who worked on it I welcome their suggestions, hints, comments, &c From maciej at opencsw.org Wed Jan 9 10:36:49 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 9 Jan 2013 09:36:49 +0000 Subject: [csw-maintainers] reminder on contributing on recipes In-Reply-To: References: Message-ID: 2013/1/8 pfelecan : > On the maintainers mailing list, announce your intention to work on > the recipe and eventually take up the maintenance. What if I want to make a change and upload it, but not become a permanent maintainer of the package? I had loads of such cases, especially with packages depending on old libraries. I want to remove an old library, so I rebuild packages depending on it. Obviously, most of these packages are not maintained. But I only care about them not depending on a legacy dependency I want to kill, I don't want to spend weeks on all the bugs that such package might have filed in Mantis. Currently, the result is that I have a lot of bugs assigned to me, which are legitimate bugs, but I have no intention to fix them, because I didn't want to take over these packages. But the mechanics of our uploads work in such a way that it's impossible not to appear as the main maintainer after you've uploaded a package. Maciej From maciej at opencsw.org Wed Jan 9 12:02:04 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 9 Jan 2013 11:02:04 +0000 Subject: [csw-maintainers] reminder on contributing on recipes In-Reply-To: References: Message-ID: 2013/1/8 pfelecan : > There are, of course, possible variations on contributing to recipes > maintained by others, and we should discuss them. However, I hope that > the above can be used as a foundation of a possible policy definition > on this issue. Thanks for writing this up. I put it in our manual. https://sourceforge.net/apps/trac/gar/changeset/20060 From guillomovitch at opencsw.org Wed Jan 9 18:00:27 2013 From: guillomovitch at opencsw.org (Guillaume Rousse) Date: Wed, 09 Jan 2013 18:00:27 +0100 Subject: [csw-maintainers] Error during CSWnsca installation: missing nagios user Message-ID: <50EDA22B.6050800@opencsw.org> Installing nsca - Nagios service check acceptor as ## Executing preinstall script. ======================================================================= From NSCA 2.7.2,REV=2009.10.12 on the configuration file for the OpenCSW package is stored in /etc/opt/csw/nagios/. No further action is needed (to have a backup is always a good idea). Installation will proceed in 15 seconds. Press CTRL+C if you want to stop now. ======================================================================= 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 ## Installing part 1 of 1. pkgadd: ERROR: unable to create package object . group name not found in group table(s) owner name not found in passwd table(s) /etc/opt/csw/nagios /opt/csw/etc/pkg/CSWnsca/cswusergroup pkgadd: ERROR: unable to create package object . pathname does not exist group name not found in group table(s) owner name not found in passwd table(s) [..] Installation of partially failed. pkgadd failed with exit code: 2 Exit from pkgutil and fix this issue first (recommended)? ([y],n) This missing user also prevents the software to work. Either the package miss a dependency on something else supposed to create it, either it fails to create it itself. -- BOFH excuse #90: Budget cuts From bonivart at opencsw.org Wed Jan 9 18:14:43 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 9 Jan 2013 18:14:43 +0100 Subject: [csw-maintainers] Error during CSWnsca installation: missing nagios user In-Reply-To: <50EDA22B.6050800@opencsw.org> References: <50EDA22B.6050800@opencsw.org> Message-ID: On Wed, Jan 9, 2013 at 6:00 PM, Guillaume Rousse wrote: > This missing user also prevents the software to work. Either the package > miss a dependency on something else supposed to create it, either it fails > to create it itself. If the package is meant to be used without nagios I guess it should take care of creating nagios:nagios itself and the Makefile seems to define something of that kind even though it doesn't work (the dependency on CSWcas-usergroup is not picked up). Please file a bug on the package, in the meantime you can make the installation happy by creating the user/group combo yourself beforehand. /peter From ja at opencsw.org Wed Jan 9 18:37:33 2013 From: ja at opencsw.org (Juergen Arndt) Date: Wed, 9 Jan 2013 18:37:33 +0100 Subject: [csw-maintainers] Error during CSWnsca installation: missing nagios user In-Reply-To: References: <50EDA22B.6050800@opencsw.org> Message-ID: <303423DB-8C4D-40F1-954C-5A061926E3C8@opencsw.org> On 09.01.2013, at 18:14, Peter Bonivart wrote: > On Wed, Jan 9, 2013 at 6:00 PM, Guillaume Rousse > wrote: >> This missing user also prevents the software to work. Either the package >> miss a dependency on something else supposed to create it, either it fails >> to create it itself. > > If the package is meant to be used without nagios I guess it should > take care of creating nagios:nagios itself and the Makefile seems to > define something of that kind even though it doesn't work (the > dependency on CSWcas-usergroup is not picked up). I - as the maintainer of the package - will take a look tomorrow. It's the first time, that I heard or read about this. Regards, Juergen -- Juergen Arndt From bonivart at opencsw.org Wed Jan 9 18:44:45 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 9 Jan 2013 18:44:45 +0100 Subject: [csw-maintainers] Proposal: switch off autostarting of services In-Reply-To: References: Message-ID: On Mon, Jan 7, 2013 at 4:26 PM, Maciej (Matchek) Blizi?ski wrote: > I propose that we change the default to not start services by default. None opposed so far. I don't know what constitutes a change (wait a week?) but the change would be in CSWcas-initsmf. Some docs would also need updating. /peter From pfelecan at opencsw.org Wed Jan 9 20:10:10 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 09 Jan 2013 20:10:10 +0100 Subject: [csw-maintainers] reminder on contributing on recipes In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Wed, 9 Jan 2013 09:36:49 +0000") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/1/8 pfelecan : >> On the maintainers mailing list, announce your intention to work on >> the recipe and eventually take up the maintenance. > > What if I want to make a change and upload it, but not become a > permanent maintainer of the package? I had loads of such cases, > especially with packages depending on old libraries. I want to remove > an old library, so I rebuild packages depending on it. Obviously, most > of these packages are not maintained. But I only care about them not > depending on a legacy dependency I want to kill, I don't want to spend > weeks on all the bugs that such package might have filed in Mantis. > > Currently, the result is that I have a lot of bugs assigned to me, > which are legitimate bugs, but I have no intention to fix them, > because I didn't want to take over these packages. But the mechanics > of our uploads work in such a way that it's impossible not to appear > as the main maintainer after you've uploaded a package. Indeed, this is bothering me also: a maintainer correcting a lot of packages that are orphaned acquire, by default, the maintenance of the those packages. What if we change the uploader to have an option saying that the action is on the behalf of the current maintainer --- even a retired one; we can log that the upload was done by somebody else. Debian has a similar feature... -- Peter From bwalton at opencsw.org Wed Jan 9 20:17:35 2013 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 9 Jan 2013 19:17:35 +0000 Subject: [csw-maintainers] reminder on contributing on recipes In-Reply-To: References: Message-ID: This would be fine with me for all of the reasons you've listed. It's not a trivial change though as maintainership info is derived from package metadata. A gar override its the answer... In fact, simply making that info part of the recipe instead of storing it in .garrc would allow versioned take overs. Am I missing a downside here? On Jan 9, 2013 7:10 PM, "Peter FELECAN" wrote: > "Maciej (Matchek) Blizi?ski" writes: > > > 2013/1/8 pfelecan : > >> On the maintainers mailing list, announce your intention to work on > >> the recipe and eventually take up the maintenance. > > > > What if I want to make a change and upload it, but not become a > > permanent maintainer of the package? I had loads of such cases, > > especially with packages depending on old libraries. I want to remove > > an old library, so I rebuild packages depending on it. Obviously, most > > of these packages are not maintained. But I only care about them not > > depending on a legacy dependency I want to kill, I don't want to spend > > weeks on all the bugs that such package might have filed in Mantis. > > > > Currently, the result is that I have a lot of bugs assigned to me, > > which are legitimate bugs, but I have no intention to fix them, > > because I didn't want to take over these packages. But the mechanics > > of our uploads work in such a way that it's impossible not to appear > > as the main maintainer after you've uploaded a package. > > Indeed, this is bothering me also: a maintainer correcting a lot of > packages that are orphaned acquire, by default, the maintenance of the > those packages. > > What if we change the uploader to have an option saying that the action > is on the behalf of the current maintainer --- even a retired one; we > can log that the upload was done by somebody else. Debian has a similar > feature... > -- > Peter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Wed Jan 9 21:24:26 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 9 Jan 2013 21:24:26 +0100 Subject: [csw-maintainers] reminder on contributing on recipes In-Reply-To: References: Message-ID: <50953159-8725-4C7A-BDFB-25D379A01BD1@opencsw.org> Hi Ben, Am 09.01.2013 um 20:17 schrieb Ben Walton : > This would be fine with me for all of the reasons you've listed. It's not a trivial change though as maintainership info is derived from package metadata. A gar override its the answer... > > In fact, simply making that info part of the recipe instead of storing it in .garrc would allow versioned take overs. > > Am I missing a downside here? We could add something like MAINTAINER = dam in the Makefile with the person currently maintaining the package which then goes to SPKG_EMAIL = $(MAINTAINER)@$(PKGDOMAIN) if MAINTAINER is set and falls back to already defined SPKG_EMAIL where PKGDOMAIN is preset in the global /etc/opt/csw/garrc Best regards -- DAgo > > On Jan 9, 2013 7:10 PM, "Peter FELECAN" wrote: > "Maciej (Matchek) Blizi?ski" writes: > > > 2013/1/8 pfelecan : > >> On the maintainers mailing list, announce your intention to work on > >> the recipe and eventually take up the maintenance. > > > > What if I want to make a change and upload it, but not become a > > permanent maintainer of the package? I had loads of such cases, > > especially with packages depending on old libraries. I want to remove > > an old library, so I rebuild packages depending on it. Obviously, most > > of these packages are not maintained. But I only care about them not > > depending on a legacy dependency I want to kill, I don't want to spend > > weeks on all the bugs that such package might have filed in Mantis. > > > > Currently, the result is that I have a lot of bugs assigned to me, > > which are legitimate bugs, but I have no intention to fix them, > > because I didn't want to take over these packages. But the mechanics > > of our uploads work in such a way that it's impossible not to appear > > as the main maintainer after you've uploaded a package. > > Indeed, this is bothering me also: a maintainer correcting a lot of > packages that are orphaned acquire, by default, the maintenance of the > those packages. > > What if we change the uploader to have an option saying that the action > is on the behalf of the current maintainer --- even a retired one; we > can log that the upload was done by somebody else. Debian has a similar > feature... > -- > Peter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Wed Jan 9 21:39:43 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 9 Jan 2013 20:39:43 +0000 Subject: [csw-maintainers] Proposal: switch off autostarting of services In-Reply-To: References: <7a97dd2f5e692a537557871493fc735d@opencsw.org> Message-ID: 2013/1/7 Yann Rouillard : > I also agree about disabling auto-start after installation. > > But by the way, are we talking only about auto-starting after first > installation or also after upgrade ? > > Under Solaris 10, autostart_daemons=no will only prevent daemons from > auto-starting at first installation. After, the previous state of the daemon > will be restored no matter what is the value of autostart_daemons. > > I personnally like this behaviour (and in fact proposed the patch for it): > after I correctly configured a service, I prefer it to be automatically > restarted on upgrade, but I put the subject on the table so we're sure to > agree on the same thing. I think we mean the auto-start after installation, not upgrade. Preserving the state throughout an update would be an intuitive behavior. Maciej From bwalton at opencsw.org Wed Jan 9 21:51:27 2013 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 9 Jan 2013 20:51:27 +0000 Subject: [csw-maintainers] reminder on contributing on recipes In-Reply-To: <50953159-8725-4C7A-BDFB-25D379A01BD1@opencsw.org> References: <50953159-8725-4C7A-BDFB-25D379A01BD1@opencsw.org> Message-ID: I like that approach. Anyone else? Thanks -Ben On Jan 9, 2013 8:24 PM, "Dagobert Michelsen" wrote: > Hi Ben, > > Am 09.01.2013 um 20:17 schrieb Ben Walton : > > This would be fine with me for all of the reasons you've listed. It's > not a trivial change though as maintainership info is derived from package > metadata. A gar override its the answer... > > > > In fact, simply making that info part of the recipe instead of storing > it in .garrc would allow versioned take overs. > > > > Am I missing a downside here? > > We could add something like > MAINTAINER = dam > in the Makefile with the person currently maintaining the package which > then goes to > SPKG_EMAIL = $(MAINTAINER)@$(PKGDOMAIN) > if MAINTAINER is set and falls back to already defined SPKG_EMAIL > where PKGDOMAIN is preset in the global /etc/opt/csw/garrc > > > Best regards > > -- DAgo > > > > > On Jan 9, 2013 7:10 PM, "Peter FELECAN" wrote: > > "Maciej (Matchek) Blizi?ski" writes: > > > > > 2013/1/8 pfelecan : > > >> On the maintainers mailing list, announce your intention to work on > > >> the recipe and eventually take up the maintenance. > > > > > > What if I want to make a change and upload it, but not become a > > > permanent maintainer of the package? I had loads of such cases, > > > especially with packages depending on old libraries. I want to remove > > > an old library, so I rebuild packages depending on it. Obviously, most > > > of these packages are not maintained. But I only care about them not > > > depending on a legacy dependency I want to kill, I don't want to spend > > > weeks on all the bugs that such package might have filed in Mantis. > > > > > > Currently, the result is that I have a lot of bugs assigned to me, > > > which are legitimate bugs, but I have no intention to fix them, > > > because I didn't want to take over these packages. But the mechanics > > > of our uploads work in such a way that it's impossible not to appear > > > as the main maintainer after you've uploaded a package. > > > > Indeed, this is bothering me also: a maintainer correcting a lot of > > packages that are orphaned acquire, by default, the maintenance of the > > those packages. > > > > What if we change the uploader to have an option saying that the action > > is on the behalf of the current maintainer --- even a retired one; we > > can log that the upload was done by somebody else. Debian has a similar > > feature... > > -- > > Peter > > _______________________________________________ > > maintainers mailing list > > maintainers at lists.opencsw.org > > https://lists.opencsw.org/mailman/listinfo/maintainers > > .:: This mailing list's archive is public. ::. > > _______________________________________________ > > maintainers mailing list > > maintainers at lists.opencsw.org > > https://lists.opencsw.org/mailman/listinfo/maintainers > > .:: This mailing list's archive is public. ::. > > -- > "You don't become great by trying to be great, you become great by wanting > to do something, > and then doing it so hard that you become great in the process." - xkcd > #896 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Wed Jan 9 22:25:49 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 9 Jan 2013 21:25:49 +0000 Subject: [csw-maintainers] reminder on contributing on recipes In-Reply-To: References: <50953159-8725-4C7A-BDFB-25D379A01BD1@opencsw.org> Message-ID: 2013/1/9 Ben Walton : > I like that approach. Anyone else? Me too. I was just about to suggest some form of email obfuscation to hide from spam harvesters. From dam at opencsw.org Wed Jan 9 22:43:47 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 9 Jan 2013 22:43:47 +0100 Subject: [csw-maintainers] reminder on contributing on recipes In-Reply-To: References: <50953159-8725-4C7A-BDFB-25D379A01BD1@opencsw.org> Message-ID: Hi Maciej, Am 09.01.2013 um 22:25 schrieb Maciej (Matchek) Blizi?ski : > 2013/1/9 Ben Walton : >> I like that approach. Anyone else? > > Me too. I was just about to suggest some form of email obfuscation to > hide from spam harvesters. We need to make this adjustable anyway to make it world-rebuildable. 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 Jan 9 22:52:01 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 09 Jan 2013 22:52:01 +0100 Subject: [csw-maintainers] reminder on contributing on recipes In-Reply-To: <50953159-8725-4C7A-BDFB-25D379A01BD1@opencsw.org> (Dagobert Michelsen's message of "Wed, 9 Jan 2013 21:24:26 +0100") References: <50953159-8725-4C7A-BDFB-25D379A01BD1@opencsw.org> Message-ID: Dagobert Michelsen writes: > Hi Ben, > > Am 09.01.2013 um 20:17 schrieb Ben Walton : >> This would be fine with me for all of the reasons you've >> listed. It's not a trivial change though as maintainership info is >> derived from package metadata. A gar override its the answer... >> >> In fact, simply making that info part of the recipe instead of storing it in .garrc would allow versioned take overs. >> >> Am I missing a downside here? > > We could add something like > MAINTAINER = dam > in the Makefile with the person currently maintaining the package which then goes to > SPKG_EMAIL = $(MAINTAINER)@$(PKGDOMAIN) > if MAINTAINER is set and falls back to already defined SPKG_EMAIL > where PKGDOMAIN is preset in the global /etc/opt/csw/garrc Excellent Dago! Can you use your magic to fix that in all the recipe to start with, i.e. define in all the Makefiles the current maintainer and the remaining and required stanza that you mention above? Afterward we can do it manually... However, a check is in order to verify that a maintainer is defined, isn't it, Maciej? >> >> On Jan 9, 2013 7:10 PM, "Peter FELECAN" wrote: >> "Maciej (Matchek) Blizi?ski" writes: >> >> > 2013/1/8 pfelecan : >> >> On the maintainers mailing list, announce your intention to work on >> >> the recipe and eventually take up the maintenance. >> > >> > What if I want to make a change and upload it, but not become a >> > permanent maintainer of the package? I had loads of such cases, >> > especially with packages depending on old libraries. I want to remove >> > an old library, so I rebuild packages depending on it. Obviously, most >> > of these packages are not maintained. But I only care about them not >> > depending on a legacy dependency I want to kill, I don't want to spend >> > weeks on all the bugs that such package might have filed in Mantis. >> > >> > Currently, the result is that I have a lot of bugs assigned to me, >> > which are legitimate bugs, but I have no intention to fix them, >> > because I didn't want to take over these packages. But the mechanics >> > of our uploads work in such a way that it's impossible not to appear >> > as the main maintainer after you've uploaded a package. >> >> Indeed, this is bothering me also: a maintainer correcting a lot of >> packages that are orphaned acquire, by default, the maintenance of the >> those packages. >> >> What if we change the uploader to have an option saying that the action >> is on the behalf of the current maintainer --- even a retired one; we >> can log that the upload was done by somebody else. Debian has a similar >> feature... >> -- >> Peter >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers >> .:: This mailing list's archive is public. ::. >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers >> .:: This mailing list's archive is public. ::. -- Peter From yann at pleiades.fr.eu.org Wed Jan 9 23:33:50 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Wed, 9 Jan 2013 23:33:50 +0100 Subject: [csw-maintainers] Proposal: switch off autostarting of services In-Reply-To: References: <7a97dd2f5e692a537557871493fc735d@opencsw.org> Message-ID: 2013/1/9 Maciej (Matchek) Blizi?ski > 2013/1/7 Yann Rouillard : > > Under Solaris 10, autostart_daemons=no will only prevent daemons from > > auto-starting at first installation. After, the previous state of the > daemon > > will be restored no matter what is the value of autostart_daemons. > > > > I personnally like this behaviour (and in fact proposed the patch for > it): > > after I correctly configured a service, I prefer it to be automatically > > restarted on upgrade, but I put the subject on the table so we're sure to > > agree on the same thing. > > I think we mean the auto-start after installation, not upgrade. > Preserving the state throughout an update would be an intuitive > behavior. > Yes I agree, but this is not the current behaviour under Solaris 9 for example. But as Solaris 9 days in opencsw are numbered, it is not a big issue. Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Thu Jan 10 00:28:02 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 9 Jan 2013 23:28:02 +0000 Subject: [csw-maintainers] reminder on contributing on recipes In-Reply-To: References: <50953159-8725-4C7A-BDFB-25D379A01BD1@opencsw.org> Message-ID: 2013/1/9 Peter FELECAN : > Afterward we can do it manually... However, a check is in order to > verify that a maintainer is defined, isn't it, Maciej? Yes, there's a check that the maintainer should be defined in a package. https://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/python/package_checks.py#L606 Maciej From maciej at opencsw.org Thu Jan 10 00:28:45 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 9 Jan 2013 23:28:45 +0000 Subject: [csw-maintainers] Proposal: switch off autostarting of services In-Reply-To: References: <7a97dd2f5e692a537557871493fc735d@opencsw.org> Message-ID: 2013/1/9 Yann Rouillard : > Yes I agree, but this is not the current behaviour under Solaris 9 for > example. > But as Solaris 9 days in opencsw are numbered, it is not a big issue. I'm thinking that we wouldn't make the change for Solaris 9, only for 10. Maciej From bwalton at opencsw.org Thu Jan 10 08:45:14 2013 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 10 Jan 2013 07:45:14 +0000 Subject: [csw-maintainers] Proposal: switch off autostarting of services In-Reply-To: References: <7a97dd2f5e692a537557871493fc735d@opencsw.org> Message-ID: Agreed. The worms have already devoured 9 so there is no point in doing anything special for it. :) Thanks -Ben On Jan 9, 2013 11:29 PM, "Maciej (Matchek) Blizi?ski" wrote: > 2013/1/9 Yann Rouillard : > > Yes I agree, but this is not the current behaviour under Solaris 9 for > > example. > > But as Solaris 9 days in opencsw are numbered, it is not a big issue. > > I'm thinking that we wouldn't make the change for Solaris 9, only for 10. > > Maciej > _______________________________________________ > 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 jh at opencsw.org Thu Jan 10 11:13:42 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Thu, 10 Jan 2013 11:13:42 +0100 Subject: [csw-maintainers] Checkpkg database update and new checkpkg tests In-Reply-To: References: Message-ID: <50EE9456.4050608@opencsw.org> Hi, I did brake it :) package.StdoutSyntaxError: Could not parse '/tmp/pkg_v0EICf/CSWffmpeg/root/opt/csw/bin/amd64/ffmpeg: warning: hardware capability (CA_SUNW_HW_1) unsupported: 0x100 [ AMD_3DNow ]' with (^\t(?P\S+)\s+=>\s+(?P\S+)|^\tsymbol not found:\s(?P\S+)\s+\((?P\S+)\)|^\t(?P\S+)$|^\t(?P\S+) \((?P\S+)\) =>\t \(version not found\)|^\trelocation \S+ symbol: (?P\S+): file (?P\S+): relocation bound to a symbol with STV_PROTECTED visibility$|^\trelocation \S+ sizes differ: (?P\S+)$|^\t\t\(file (?P\S+) size=(?P0x\w+); file (?P\S+) size=(?P0x\w+)\)$|^\t\t(?P\S+) size used; possible insufficient data copied$|^\s*unreferenced object=(?P.*); unused dependency of (?P.*)$|^\s*unused object=.*$|^\s*unused search path=.* \(RUNPATH/RPATH from file .*\)$|^\s*$|^\tmove (?P\d+) offset invalid: \(unknown\): offset=(?P0x[0-9a-f]+) lies outside memory image; move discarded|relocation R_(386|AMD64|X86_64|SPARC)_\w+ sizes differ: (?P.*)|\t\t\(file .* size=0(?:x[0-9a-f]+)?; file .*size=0x(?:[0-9a-f]+)?\)|\t.* size used; possible data truncation) Don't know how it gets AMD_3DNow but thats fine too :) package is ffmpeg if you want to test it. Greetings Jan Am 03.01.13 22:27, schrieb Yann Rouillard: > Hi everybody, > > I proposed some time ago to implement new checkpkg checks in order to > detect binaries not honouring the new direct binding constraint or > having unused libraries dependencies: > http://lists.opencsw.org/pipermail/maintainers/2012-August/017126.html and http://lists.opencsw.org/pipermail/maintainers/2012-August/017158.html > > Well, as always, it took longer than expected but with the help and > advices of Maciej, I will eventually be able to commit the new tests on > the main branch the day after tomorrow. > > These new checks will probably not change anything or trigger new > warnings for your package, except if your build system doesn't correctly > take into account the LD_OPTIONS default variable defined by GAR. > In that case, you will probably have one the two new checkpkg errors > documented here: > http://wiki.opencsw.org/checkpkg-error-tags#no-direct-binding > http://wiki.opencsw.org/checkpkg-error-tags#soname-unused > > An important note: ldd is used to gather some information about > binaries. As ldd only work on binaries of the same architecture, this > means that the package content analysis step can now only be done on a > server with the same architecture as the package checked. > The real check step however can still be performed from anywhere. > > > These new checks required to add new information about symbols and > linkage in the checkpkg database. This information can now easily be > used to create others checks related to linkage, symbol and interfaces. > For exemple I also added a new test to detect if a binary is using a > forbidden version > interface: http://wiki.opencsw.org/checkpkg-error-tags#forbidden-version-interface-dependencies > > Unfortunately this also requires to re-import all the existing packages > to in the database to gather the symbols and linkage information from > previous packages. > I will begin this operation starting from now, it takes around 18h and > can be done live without preventing maintainers to upload new packages. > However, at the end, I will update the db schema version and commit the > new code. After this, you will have to svn update your gar build system > or it will complains about db schema version difference. > The procedure followed is described on the > wiki: http://wiki.opencsw.org/checkpkg#toc > > > I'll keep you updated as soon as it is finished. > > If you have any question, don't hesitate. > > > BTW, happy New Year to everybody ! > > > Yann > > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From maciej at opencsw.org Thu Jan 10 14:04:52 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 10 Jan 2013 13:04:52 +0000 Subject: [csw-maintainers] Direct binding now active In-Reply-To: <50619729.9050007@opencsw.org> References: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> <8B21EC9D-F841-430B-B81E-00F41CE7792F@opencsw.org> <1345911801-sup-2797@pinkfloyd.chass.utoronto.ca> <00CBA899-4CD2-405D-BFB1-BAAB2D8C020D@opencsw.org> <50600FC0.3070104@opencsw.org> <50619729.9050007@opencsw.org> Message-ID: It looks like https://www.opencsw.org/mantis/view.php?id=5040 was caused by the new linker flags. After I disabled them with "LINKER_IGNORE =", the problem went away. Maybe it can be solved better, but it did produce some errors, so I added overrides. http://sourceforge.net/apps/trac/gar/changeset/20073 Maciej From guillomovitch at opencsw.org Thu Jan 10 14:13:01 2013 From: guillomovitch at opencsw.org (Guillaume Rousse) Date: Thu, 10 Jan 2013 14:13:01 +0100 Subject: [csw-maintainers] Error during CSWnsca installation: missing nagios user In-Reply-To: <303423DB-8C4D-40F1-954C-5A061926E3C8@opencsw.org> References: <50EDA22B.6050800@opencsw.org> <303423DB-8C4D-40F1-954C-5A061926E3C8@opencsw.org> Message-ID: <50EEBE5D.6080703@opencsw.org> Le 09/01/2013 18:37, Juergen Arndt a ?crit : > I - as the maintainer of the package - will take a look tomorrow. It's the first time, that I heard or read about this. Congratulation, I'm your first user :) More seriously, the problem can be a transient issue on my side (transition from testing to kiel catalog). -- BOFH excuse #40: not enough memory, go get system upgrade From maciej at opencsw.org Thu Jan 10 18:31:31 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 10 Jan 2013 17:31:31 +0000 Subject: [csw-maintainers] Python 3.3 in 64 bits In-Reply-To: References: Message-ID: Guys, do you see what I see? $ /opt/csw/bin/pentium_pro/python3.3 -c 'import sys;print("%x" % sys.maxsize, sys.maxsize > 2**32)' 7fffffff False $ /opt/csw/bin/amd64/python3.3 -c 'import sys;print("%x" % sys.maxsize, sys.maxsize > 2**32)' 7fffffffffffffff True Of course, of the modules that require shared objects (e.g. the socket module), none work. From dam at opencsw.org Thu Jan 10 18:33:52 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 10 Jan 2013 18:33:52 +0100 Subject: [csw-maintainers] Python 3.3 in 64 bits In-Reply-To: References: Message-ID: <15E0815A-014D-45EA-9308-43D6A13FE738@opencsw.org> Hi Maciej, Am 10.01.2013 um 18:31 schrieb Maciej (Matchek) Blizi?ski : > Guys, do you see what I see? > > $ /opt/csw/bin/pentium_pro/python3.3 -c 'import sys;print("%x" % > sys.maxsize, sys.maxsize > 2**32)' > 7fffffff False > $ /opt/csw/bin/amd64/python3.3 -c 'import sys;print("%x" % > sys.maxsize, sys.maxsize > 2**32)' > 7fffffffffffffff True > > Of course, of the modules that require shared objects (e.g. the socket > module), none work. Why? The 64 bit version of course uses 64 bit ints, sounds ok to me. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Thu Jan 10 18:36:21 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 10 Jan 2013 17:36:21 +0000 Subject: [csw-maintainers] Python 3.3 in 64 bits In-Reply-To: <15E0815A-014D-45EA-9308-43D6A13FE738@opencsw.org> References: <15E0815A-014D-45EA-9308-43D6A13FE738@opencsw.org> Message-ID: 2013/1/10 Dagobert Michelsen : >> Of course, of the modules that require shared objects (e.g. the socket >> module), none work. > > Why? The 64 bit version of course uses 64 bit ints, sounds ok to me. The 64-bit version doesn't look in the right place when trying to load shared objects. >> import socket Traceback (most recent call last): File "", line 1, in File "/opt/csw/lib/python3.3/socket.py", line 47, in import _socket ImportError: ld.so.1: python3.3: fatal: /opt/csw/lib/python3.3/lib-dynload/_socket.so: wrong ELF class: ELFCLASS32 The shared object it should load is in /opt/csw/lib/*amd64/* python3.3/lib-dynload/_socket.so. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Thu Jan 10 18:39:22 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 10 Jan 2013 18:39:22 +0100 Subject: [csw-maintainers] Python 3.3 in 64 bits In-Reply-To: References: <15E0815A-014D-45EA-9308-43D6A13FE738@opencsw.org> Message-ID: Hi Maciej, Am 10.01.2013 um 18:36 schrieb Maciej (Matchek) Blizi?ski : > 2013/1/10 Dagobert Michelsen : > >> Of course, of the modules that require shared objects (e.g. the socket > >> module), none work. > > > > Why? The 64 bit version of course uses 64 bit ints, sounds ok to me. > > The 64-bit version doesn't look in the right place when trying to load shared objects. > > >> import socket > Traceback (most recent call last): > File "", line 1, in > File "/opt/csw/lib/python3.3/socket.py", line 47, in > import _socket > ImportError: ld.so.1: python3.3: fatal: /opt/csw/lib/python3.3/lib-dynload/_socket.so: wrong ELF class: ELFCLASS32 > > The shared object it should load is in /opt/csw/lib/amd64/python3.3/lib-dynload/_socket.so. Indeed. That means it doesn't honour $libdir which it should, right? Maybe you can bring this to upstream attention? 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 Thu Jan 10 18:47:30 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 10 Jan 2013 17:47:30 +0000 Subject: [csw-maintainers] Python 3.3 in 64 bits In-Reply-To: References: <15E0815A-014D-45EA-9308-43D6A13FE738@opencsw.org> Message-ID: 2013/1/10 Dagobert Michelsen > The 64-bit version doesn't look in the right place when trying to load shared objects. > > >> import socket > Traceback (most recent call last): > File "", line 1, in > File "/opt/csw/lib/python3.3/socket.py", line 47, in > import _socket > ImportError: ld.so.1: python3.3: fatal: /opt/csw/lib/python3.3/lib-dynload/_socket.so: wrong ELF class: ELFCLASS32 > > > The shared object it should load is in /opt/csw/lib/amd64/python3.3/lib-dynload/_socket.so. > > > Indeed. That means it doesn't honour $libdir which it should, right? Maybe you can bring > this to upstream attention? Who knows how it works. Maybe the file that defines where to look for shared objects is not even merged from the 64-bit installation; AFAIK only binaries are. I found a workaround: $ PYTHONPATH=/opt/csw/lib/amd64/python3.3/lib-dynload python3.3 Python 3.3.0 (default, Jan 10 2013, 11:28:31) [GCC 4.7.2] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import socket >>> socket.gethostname() 'vsol08' Maybe we can somehow hardcode it into the build. From yann at pleiades.fr.eu.org Thu Jan 10 19:01:03 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Thu, 10 Jan 2013 19:01:03 +0100 Subject: [csw-maintainers] Direct binding now active In-Reply-To: References: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> <8B21EC9D-F841-430B-B81E-00F41CE7792F@opencsw.org> <1345911801-sup-2797@pinkfloyd.chass.utoronto.ca> <00CBA899-4CD2-405D-BFB1-BAAB2D8C020D@opencsw.org> <50600FC0.3070104@opencsw.org> <50619729.9050007@opencsw.org> Message-ID: Hi Maciej, Does this _socket module import problem happens everytime or just for this program ? FYI, the direct binding error are a side effect of the "unused soname" error. The "direct binding" test doesn't find any symbol with a direct binding, which is normal as the binary doesn't use any of the symbol of the library. I will fix that case. No need to have two checkpkg errors for one real error. For the real problem, I will try to reproduce it to understand what is wrong. Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Thu Jan 10 19:01:42 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Thu, 10 Jan 2013 19:01:42 +0100 Subject: [csw-maintainers] Checkpkg database update and new checkpkg tests In-Reply-To: <50EE9456.4050608@opencsw.org> References: <50EE9456.4050608@opencsw.org> Message-ID: Hi Jan, 2013/1/10 Jan Holzhueter > Hi, > I did brake it :) > > package.StdoutSyntaxError: Could not parse > '/tmp/pkg_v0EICf/CSWffmpeg/root/opt/csw/bin/amd64/ffmpeg: warning: > hardware capability (CA_SUNW_HW_1) unsupported: 0x100 [ AMD_3DNow ]' > [...] > > What a nice error message ! (this wil be improved soon ;) ). This error happens because ldd encountered an unexpected line. In that case, we should figure out if this line is the sign of a problem or not: - if this is not a problem, we should ignore it when parsing ldd output (modification to be done in checkpkg code), - if this is a problem: - either we let the error be raised so that the maintainer is warned that something is wrong, - or better we store the information in the checkpkg database and add a real check about this issue. > Don't know how it gets AMD_3DNow but thats fine too :) > Well I am not sure it is fine. It usually means that, to be run, your binary requires a system with hardware capability AMD_3DNOW. See: http://docs.oracle.com/cd/E19082-01/819-0690/chapter2-20/index.html I am not sure we want that for our binaries. Are there still a lot of computers without this capability ? But maybe this is just an optional feature, I have to check exactly how it works. Are you able to run the resulting binary on a system without AMD_3DNOW capabilites ? > > package is ffmpeg if you want to test it. > > Do I have a direct access to the location where you built it so I can skip the building step ? Yann > > Greetings > Jan > > > > Am 03.01.13 22:27, schrieb Yann Rouillard: > > Hi everybody, > > > > I proposed some time ago to implement new checkpkg checks in order to > > detect binaries not honouring the new direct binding constraint or > > having unused libraries dependencies: > > http://lists.opencsw.org/pipermail/maintainers/2012-August/017126.htmland > http://lists.opencsw.org/pipermail/maintainers/2012-August/017158.html > > > > Well, as always, it took longer than expected but with the help and > > advices of Maciej, I will eventually be able to commit the new tests on > > the main branch the day after tomorrow. > > > > These new checks will probably not change anything or trigger new > > warnings for your package, except if your build system doesn't correctly > > take into account the LD_OPTIONS default variable defined by GAR. > > In that case, you will probably have one the two new checkpkg errors > > documented here: > > http://wiki.opencsw.org/checkpkg-error-tags#no-direct-binding > > http://wiki.opencsw.org/checkpkg-error-tags#soname-unused > > > > An important note: ldd is used to gather some information about > > binaries. As ldd only work on binaries of the same architecture, this > > means that the package content analysis step can now only be done on a > > server with the same architecture as the package checked. > > The real check step however can still be performed from anywhere. > > > > > > These new checks required to add new information about symbols and > > linkage in the checkpkg database. This information can now easily be > > used to create others checks related to linkage, symbol and interfaces. > > For exemple I also added a new test to detect if a binary is using a > > forbidden version > > interface: > http://wiki.opencsw.org/checkpkg-error-tags#forbidden-version-interface-dependencies > > > > Unfortunately this also requires to re-import all the existing packages > > to in the database to gather the symbols and linkage information from > > previous packages. > > I will begin this operation starting from now, it takes around 18h and > > can be done live without preventing maintainers to upload new packages. > > However, at the end, I will update the db schema version and commit the > > new code. After this, you will have to svn update your gar build system > > or it will complains about db schema version difference. > > The procedure followed is described on the > > wiki: http://wiki.opencsw.org/checkpkg#toc > > > > > > I'll keep you updated as soon as it is finished. > > > > If you have any question, don't hesitate. > > > > > > BTW, happy New Year to everybody ! > > > > > > Yann > > > > > > _______________________________________________ > > maintainers mailing list > > maintainers at lists.opencsw.org > > https://lists.opencsw.org/mailman/listinfo/maintainers > > .:: This mailing list's archive is public. ::. > > > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ja at opencsw.org Thu Jan 10 21:14:31 2013 From: ja at opencsw.org (Juergen Arndt) Date: Thu, 10 Jan 2013 21:14:31 +0100 Subject: [csw-maintainers] Error during CSWnsca installation: missing nagios user In-Reply-To: <50EEBE5D.6080703@opencsw.org> References: <50EDA22B.6050800@opencsw.org> <303423DB-8C4D-40F1-954C-5A061926E3C8@opencsw.org> <50EEBE5D.6080703@opencsw.org> Message-ID: On 10.01.2013, at 14:13, Guillaume Rousse wrote: > Le 09/01/2013 18:37, Juergen Arndt a ?crit : >> I - as the maintainer of the package - will take a look tomorrow. It's the first time, that I heard or read about this. > Congratulation, I'm your first user :) A good feeling to have a growing user base at such a high rate :) > More seriously, the problem can be a transient issue on my side (transition from testing to kiel catalog). Nope, the problem was in the package. I - and it seems nobody else too - did never install the package without installing CSWnagios before. So usually the user and group were already installed. As there is no dependency in CSWnsca to CSWnagios, you ran into the failure - maybe because of the transition, maybe you wanted to install CSWnsca before or without CSWnagios. I built a new version of CSWnsca which ensures, that the user and group will be added before installing any files. I uploaded the package a minute ago, so it should be available soon. Thanks for reporting this bug! Regards, Juergen -- Juergen Arndt From jh at opencsw.org Thu Jan 10 21:17:44 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Thu, 10 Jan 2013 21:17:44 +0100 Subject: [csw-maintainers] Checkpkg database update and new checkpkg tests In-Reply-To: References: <50EE9456.4050608@opencsw.org> Message-ID: <50EF21E8.3040102@opencsw.org> Hi, Am 10.01.13 19:01, schrieb Yann Rouillard: > What a nice error message ! (this wil be improved soon ;) ). > > This error happens because ldd encountered an unexpected line. > In that case, we should figure out if this line is the sign of a problem > or not: > - if this is not a problem, we should ignore it when parsing ldd > output (modification to be done in checkpkg code), > - if this is a problem: > - either we let the error be raised so that the maintainer is > warned that something is wrong, > - or better we store the information in the checkpkg database > and add a real check about this issue. > > > > Don't know how it gets AMD_3DNow but thats fine too :) > > > Well I am not sure it is fine. > It usually means that, to be run, your binary requires a system with > hardware capability AMD_3DNOW. > See: http://docs.oracle.com/cd/E19082-01/819-0690/chapter2-20/index.html > I needed to raise the build level for ffmpeg anyway to build. http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/ffmpeg/trunk/Makefile#L176 I'm not sure here if sse is the "same" as AMD_3DNOW but I think they are On the other hand ffmpeg does have cpu autodetect. So iirc it only uses codepath it can use. But builds all code paths. For see I could be wrong as I added it as flags > I am not sure we want that for our binaries. Are there still a lot of > computers without this capability ? And I'm not sure there is still real hardware out that that does not support sse/AMD_3dNOW it's from 98 or so. > > But maybe this is just an optional feature, I have to check exactly how > it works. It's not optional I think see above > Are you able to run the resulting binary on a system without AMD_3DNOW > capabilites ? I don't have any. :) > > > > > package is ffmpeg if you want to test it. > > > Do I have a direct access to the location where you built it so I can > skip the building step ? sure /home/jh/opencsw/ffmpg/trunk Greetings Jan From pfelecan at opencsw.org Fri Jan 11 09:02:16 2013 From: pfelecan at opencsw.org (pfelecan) Date: Fri, 11 Jan 2013 09:02:16 +0100 Subject: [csw-maintainers] inoperant reinplace Message-ID: <664d28fa2aa49fe56e15636a3804216d@opencsw.org> Still struggling to finish the packaging of TeXLive... Here is what I do: cd ~/opencsw/texlive/trunk find work -type f -name 'post-install-reinplace*' -print -exec rm {} \; nohup mgar platforms-remerge platforms-repackage < /dev/null > ~/logs/texlive 2>&1 & I got the following errors reported by checkpkg, with the afferent proposal of overriding: CHECKPKG_OVERRIDES_CSWtexlive-base += file-with-bad-content|/usr/local|root/opt/csw/share/texmf/scripts/simpdftex/simpdftex CHECKPKG_OVERRIDES_CSWtexlive-latex-extra += file-with-bad-content|/usr/local|root/opt/csw/share/texmf-dist/scripts/pax/pdfannotextractor.pl CHECKPKG_OVERRIDES_CSWtexlive-publishers-doc += file-with-bad-content|/usr/local|root/opt/csw/share/texmf-dist/doc/latex/confproc/buildpapers.sh CHECKPKG_OVERRIDES_CSWtexlive-publishers-doc += file-with-bad-content|/usr/local|root/opt/csw/share/texmf-dist/doc/latex/confproc/example/buildpapers.sh However, in the recipe I have the following stanzas: REINPLACE_WHEN_USRLOCAL = postinstall ... REINPLACE_USRLOCAL += /opt/csw/share/texmf/scripts/simpdftex/simpdftex REINPLACE_USRLOCAL += /opt/csw/share/texmf-dist/scripts/pax/pdfannotextractor.pl REINPLACE_USRLOCAL += /opt/csw/share/texmf-dist/doc/latex/confproc/buildpapers.sh REINPLACE_USRLOCAL += /opt/csw/share/texmf-dist/doc/latex/confproc/example/buildpapers.sh ... I don't understand why, on this specific files, the "reinplace" mechanism doesn't work. Of course, I can do the corrections myself as I do for some non trivial cases but this difficulty smells as an issue with our packaging tool chain... Note that everything is available on the build farm, in my home directory. I'm thanking in advance those who will have a look at this issue. From guillomovitch at opencsw.org Fri Jan 11 10:10:37 2013 From: guillomovitch at opencsw.org (Guillaume Rousse) Date: Fri, 11 Jan 2013 10:10:37 +0100 Subject: [csw-maintainers] Error during CSWnsca installation: missing nagios user In-Reply-To: References: <50EDA22B.6050800@opencsw.org> <303423DB-8C4D-40F1-954C-5A061926E3C8@opencsw.org> <50EEBE5D.6080703@opencsw.org> Message-ID: <50EFD70D.20101@opencsw.org> Le 10/01/2013 21:14, Juergen Arndt a ?crit : > Nope, the problem was in the package. I - and it seems nobody else too - did never install the package without installing CSWnagios before. So usually the user and group were already installed. As there is no dependency in CSWnsca to CSWnagios, you ran into the failure - maybe because of the transition, maybe you wanted to install CSWnsca before or without CSWnagios. > > I built a new version of CSWnsca which ensures, that the user and group will be added before installing any files. I uploaded the package a minute ago, so it should be available soon. > > Thanks for reporting this bug! Actually, part of the error was on my side: we need the nsca client, not the nsca server, which is indeed quite useless excepted on the nagios server... -- BOFH excuse #336: the xy axis in the trackball is coordinated with the summer solstice From grzemba at contac-dt.de Fri Jan 11 10:35:17 2013 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Fri, 11 Jan 2013 10:35:17 +0100 Subject: [csw-maintainers] inoperant reinplace In-Reply-To: References: <664d28fa2aa49fe56e15636a3804216d@opencsw.org> Message-ID: Am 11.01.13 schrieb pfelecan : > Still struggling to finish the packaging of TeXLive... > > Here is what I do: > > cd ~/opencsw/texlive/trunk > find work -type f -name 'post-install-reinplace*' -print -exec rm {} \; > nohup mgar platforms-remerge platforms-repackage < /dev/null > ~/logs/texlive 2>&1 & > > I got the following errors reported by checkpkg, with the afferent proposal of overriding: > > CHECKPKG_OVERRIDES_CSWtexlive-base += file-with-bad-content|/usr/local|root/opt/csw/share/texmf/scripts/simpdftex/simpdftex > CHECKPKG_OVERRIDES_CSWtexlive-latex-extra += file-with-bad-content|/usr/local|root/opt/csw/share/texmf-dist/scripts/pax/pdfannotextractor.pl > CHECKPKG_OVERRIDES_CSWtexlive-publishers-doc += file-with-bad-content|/usr/local|root/opt/csw/share/texmf-dist/doc/latex/confproc/buildpapers.sh > CHECKPKG_OVERRIDES_CSWtexlive-publishers-doc += file-with-bad-content|/usr/local|root/opt/csw/share/texmf-dist/doc/latex/confproc/example/buildpapers.sh > > > However, in the recipe I have the following stanzas: > > REINPLACE_WHEN_USRLOCAL = postinstall > ... > REINPLACE_USRLOCAL += /opt/csw/share/texmf/scripts/simpdftex/simpdftex > REINPLACE_USRLOCAL += /opt/csw/share/texmf-dist/scripts/pax/pdfannotextractor.pl > REINPLACE_USRLOCAL += /opt/csw/share/texmf-dist/doc/latex/confproc/buildpapers.sh > REINPLACE_USRLOCAL += /opt/csw/share/texmf-dist/doc/latex/confproc/example/buildpapers.sh > ... > I could use successfully REINPLACE_USRLOCAL only without 'REINPLACE_WHEN_USRLOCAL = postinstall' and then it will done after the extract step/target so the path below $(WORKSRC) has to be used. > > > I don't understand why, on this specific files, the "reinplace" mechanism doesn't work. > > Of course, I can do the corrections myself as I do for some non trivial cases but this difficulty smells as an issue with our packaging tool chain... > > Note that everything is available on the build farm, in my home directory. > > I'm thanking in advance those who will have a look at this issue. > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > > -- Carsten Grzemba Tel.: +49 3677 64740 Mobil: +49 171 9749479 Fax: +49 3677 6474111 Email: carsten.grzemba at contac-dt.de contac Datentechnik GmbH -------------- next part -------------- An HTML attachment was scrubbed... URL: From grzemba at contac-dt.de Fri Jan 11 11:27:53 2013 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Fri, 11 Jan 2013 11:27:53 +0100 Subject: [csw-maintainers] checkpkg error In-Reply-To: References: Message-ID: Whats the problem? What does it mean: INFO:root:Tasting them all at once... Traceback (most recent call last): File "/home/cgrzemba/opencsw/.buildsys/v2/gar/gar//bin/checkpkg", line 197, in main() File "/home/cgrzemba/opencsw/.buildsys/v2/gar/gar//bin/checkpkg", line 158, in main exit_code, screen_report, tags_report = check_manager.Run() File "/home/cgrzemba/opencsw/.buildsys/v2/lib/python/checkpkg_lib.py", line 828, in Run return super(CheckpkgManager2, self).Run() File "/home/cgrzemba/opencsw/.buildsys/v2/lib/python/checkpkg_lib.py", line 236, in Run errors, messages, gar_lines = self.GetAllTags(self.sqo_pkgs_list) File "/home/cgrzemba/opencsw/.buildsys/v2/lib/python/checkpkg_lib.py", line 811, in GetAllTags function(pkgs_data, check_interface, logger=logger, messenger=messenger) File "/home/cgrzemba/opencsw/.buildsys/v2/lib/python/package_checks.py", line 401, in SetCheckLibraries depchecks.Libraries(*check_args) File "/home/cgrzemba/opencsw/.buildsys/v2/lib/python/dependency_checks.py", line 174, in Libraries ldd_info = pkg_data['ldd_info'][binary_info["path"]] KeyError: 'opt/csw/lib/cpu/sparcv8plus/libnspr_flt4.so' gmake: *** [pkgcheck] Error 2 gmake: Leaving directory `/home/cgrzemba/opencsw/nspr/trunk' Connection to unstable10s closed. -- Carsten Grzemba -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Fri Jan 11 14:10:38 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 11 Jan 2013 13:10:38 +0000 Subject: [csw-maintainers] checkpkg error In-Reply-To: References: Message-ID: 2013/1/11 Carsten Grzemba : > File > "/home/cgrzemba/opencsw/.buildsys/v2/lib/python/dependency_checks.py", line > 174, in Libraries > ldd_info = pkg_data['ldd_info'][binary_info["path"]] > KeyError: 'opt/csw/lib/cpu/sparcv8plus/libnspr_flt4.so' This looks like a bug in the code, or an external problem not caught early enough. Whas is the md5 sum of the package that it failed on? Maciej From yann at pleiades.fr.eu.org Fri Jan 11 14:48:27 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Fri, 11 Jan 2013 14:48:27 +0100 Subject: [csw-maintainers] checkpkg error In-Reply-To: References: Message-ID: For every binary, there should be a corresponding ldd_info structure (even if it's an empty dictionnary), so there is something wrong in the code. Yann 2013/1/11 Maciej (Matchek) Blizi?ski > 2013/1/11 Carsten Grzemba : > > File > > "/home/cgrzemba/opencsw/.buildsys/v2/lib/python/dependency_checks.py", > line > > 174, in Libraries > > ldd_info = pkg_data['ldd_info'][binary_info["path"]] > > KeyError: 'opt/csw/lib/cpu/sparcv8plus/libnspr_flt4.so' > > This looks like a bug in the code, or an external problem not caught > early enough. Whas is the md5 sum of the package that it failed on? > > Maciej > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Fri Jan 11 18:06:29 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Fri, 11 Jan 2013 18:06:29 +0100 Subject: [csw-maintainers] Direct binding now active In-Reply-To: References: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> <8B21EC9D-F841-430B-B81E-00F41CE7792F@opencsw.org> <1345911801-sup-2797@pinkfloyd.chass.utoronto.ca> <00CBA899-4CD2-405D-BFB1-BAAB2D8C020D@opencsw.org> <50600FC0.3070104@opencsw.org> <50619729.9050007@opencsw.org> Message-ID: Hi Maciej, I had a look at the problem. The thing is that the socket binary module, _socket.so, is only linked against libpython alhtought it needs symbols from libsocket.so. So importing this module will only work if the importer already loaded these libraries. It worked before because libpython.so.2.6 was linked against libsocket.so even if it doesn't use any of its symbols. But the "-z ignore" removed the useless dependencies from libpython and libsocket was one of them. I am not sure yet what is the proper way to fix this: 1. we can fix the build system to ensure _socket.so is linked against libsocket.so. Some other modules do it, for instance nis.so is linked against libnsl.so.1 even if libpython.so.2.6 can provide it. 2. force libpython to be linked against some libraries even if it doesn't use them. It's possible to do this specifically for libpython, but we need precise control on the build command line which is not always easy. I would think that 1. is the good way to do it, but I don't know what are the best practices for module. That being said, even if we do 1. or 2., we could also run into problems with external modules if they rely on the libpython.so.2.6 having loaded some libraries. So I think we should rather: - disable "-z ignore" for python (which you did) to be sure not to create side effects, moreover they weren't any surplus dependencies caused by useless sonames in this case. - report the problem upstream so that is fixed properly there. What do you think ? Anyway I will document this case on the wiki. BTW, I discovered that Debian also wants to enable the same kind of option for wheezy: http://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries So they might have already created some patches or reported the problem upstream. Yann 2013/1/10 Yann Rouillard > Hi Maciej, > > Does this _socket module import problem happens everytime or just for this > program ? > > FYI, the direct binding error are a side effect of the "unused soname" > error. > The "direct binding" test doesn't find any symbol with a direct binding, > which is normal as the binary doesn't use any of the symbol of the library. > I will fix that case. No need to have two checkpkg errors for one real > error. > > For the real problem, I will try to reproduce it to understand what is > wrong. > > Yann > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Fri Jan 11 18:40:40 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Fri, 11 Jan 2013 18:40:40 +0100 Subject: [csw-maintainers] checkpkg error In-Reply-To: References: Message-ID: I found the bug. A mistake in code indentation but leading to an error in the execution path. It's fixed in revision 20089: http://sourceforge.net/apps/trac/gar/changeset/20089 Update mgar and it should now works fine. It only affected binaries with 0 dependencies. There are probably not a lot of binaries like that but I will have to check that and fix the data in the database for the packages affected. In this case this library was an auxiliary filter which is why it doesn't need even the libc. Yann 2013/1/11 Yann Rouillard > For every binary, there should be a corresponding ldd_info structure (even > if it's an empty dictionnary), so there is something wrong in the code. > > Yann > > > 2013/1/11 Maciej (Matchek) Blizi?ski > > 2013/1/11 Carsten Grzemba : >> > File >> > "/home/cgrzemba/opencsw/.buildsys/v2/lib/python/dependency_checks.py", >> line >> > 174, in Libraries >> > ldd_info = pkg_data['ldd_info'][binary_info["path"]] >> > KeyError: 'opt/csw/lib/cpu/sparcv8plus/libnspr_flt4.so' >> >> This looks like a bug in the code, or an external problem not caught >> early enough. Whas is the md5 sum of the package that it failed on? >> >> Maciej >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers >> .:: This mailing list's archive is public. ::. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Fri Jan 11 18:50:37 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Fri, 11 Jan 2013 18:50:37 +0100 Subject: [csw-maintainers] Checkpkg database update and new checkpkg tests In-Reply-To: <50EF21E8.3040102@opencsw.org> References: <50EE9456.4050608@opencsw.org> <50EF21E8.3040102@opencsw.org> Message-ID: 2013/1/10 Jan Holzhueter > Hi, > > > Well I am not sure it is fine. > > It usually means that, to be run, your binary requires a system with > > hardware capability AMD_3DNOW. > > See: http://docs.oracle.com/cd/E19082-01/819-0690/chapter2-20/index.html > > > I needed to raise the build level for ffmpeg anyway to build. > > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/ffmpeg/trunk/Makefile#L176 > > I'm not sure here if sse is the "same" as AMD_3DNOW but I think they are > So you will have the same problem I suppose. > > On the other hand ffmpeg does have cpu autodetect. So iirc it only uses > codepath it can use. But builds all code paths. For see I could be wrong > as I added it as flags Well ffmpeg may have cpu autodetect but solaris will refuse to load the binary anyway. See what happens when I am trying to run in under Solaris 10 x86 which can run adm64 binaries: yann at unstable10x:~/opencsw/openssl1/trunk$ /home/jh/opencsw/ffmpeg/trunk/work/solaris10-i386/pkgroot/opt/csw/bin/amd64/ffmpeg ld.so.1: ffmpeg: fatal: /home/jh/opencsw/ffmpeg/trunk/work/solaris10-i386/pkgroot/opt/csw/bin/amd64/ffmpeg: hardware capability (CA_SUNW_HW_1) unsupported: 0x100 [ AMD_3DNow ] Killed If you are sure than ffmpeg can use the good code path at runtime, you need to prevent the hardware capability to be stored into the binary during the compilation or you need to remove it after the compilation. I know you can do the latter using elfedit. See http://docs.oracle.com/cd/E23824_01/html/821-1461/elfedit-1.html section "Example 2 Removing a Hardware Capability Bit". I think now that this problem is eligible to a new checkpkg test. Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From jh at opencsw.org Fri Jan 11 19:38:12 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Fri, 11 Jan 2013 19:38:12 +0100 Subject: [csw-maintainers] Checkpkg database update and new checkpkg tests In-Reply-To: References: <50EE9456.4050608@opencsw.org> <50EF21E8.3040102@opencsw.org> Message-ID: <50F05C14.5040704@opencsw.org> Hi, Am 11.01.13 18:50, schrieb Yann Rouillard: > Well ffmpeg may have cpu autodetect but solaris will refuse to load the > binary anyway. > See what happens when I am trying to run in under Solaris 10 x86 which > can run adm64 binaries: > > yann at unstable10x:~/opencsw/openssl1/trunk$ > /home/jh/opencsw/ffmpeg/trunk/work/solaris10-i386/pkgroot/opt/csw/bin/amd64/ffmpeg > > ld.so.1: ffmpeg: fatal: > /home/jh/opencsw/ffmpeg/trunk/work/solaris10-i386/pkgroot/opt/csw/bin/amd64/ffmpeg: > hardware capability (CA_SUNW_HW_1) unsupported: 0x100 [ AMD_3DNow ] > Killed > > > If you are sure than ffmpeg can use the good code path at runtime, you > need to prevent the hardware capability to be stored into the binary > during the compilation or you need to remove it after the compilation. > I know you can do the latter using elfedit. > See http://docs.oracle.com/cd/E23824_01/html/821-1461/elfedit-1.html section > "Example 2 Removing a Hardware Capability Bit". > Oh sorry for the noise :) I should have checked :) It's broken then. (As in the build) The old one Works. See /opt/csw/bin/amd64/ffmpeg on unstable10x. So this needs to be fixed then. Will look into this. I don't know yet where this comes from. > > I think now that this problem is eligible to a new checkpkg test. I would guess so Greetings Jan From maciej at opencsw.org Sat Jan 12 01:29:19 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 12 Jan 2013 00:29:19 +0000 Subject: [csw-maintainers] Python 3.3 in 64 bits In-Reply-To: References: <15E0815A-014D-45EA-9308-43D6A13FE738@opencsw.org> Message-ID: 2013/1/10 Dagobert Michelsen : > Indeed. That means it doesn't honour $libdir which it should, right? Maybe > you can bring this to upstream attention? Upstream did the right thing. See this file: /opt/csw/lib/python3.3/_sysconfigdata.py One difference between pentium_pro and amd64 is this: - 'DESTSHARED': '/opt/csw/lib/python3.3/lib-dynload', + 'DESTSHARED': '/opt/csw/lib/64/python3.3/lib-dynload', Some other differences: - 'SIZEOF_LONG': 4, - 'SIZEOF_LONG_DOUBLE': 12, + 'SIZEOF_LONG': 8, + 'SIZEOF_LONG_DOUBLE': 16, The full diff: http://dpaste.com/872770/ It looks like the upstream did the right thing. To accommodate both 32-bit and 64-bit versions of Python, we'll have to use different _sysconfigdata.py files, which means we'll have to configure it differently. From bwalton at opencsw.org Sat Jan 12 09:47:46 2013 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 12 Jan 2013 08:47:46 +0000 Subject: [csw-maintainers] Python 3.3 in 64 bits In-Reply-To: References: <15E0815A-014D-45EA-9308-43D6A13FE738@opencsw.org> Message-ID: Do you see a sane way to make the file live (and be referenced in) an architecture specific directory? That would solve the problem. Thanks -Ben On Jan 12, 2013 12:30 AM, "Maciej (Matchek) Blizi?ski" wrote: > 2013/1/10 Dagobert Michelsen : > > Indeed. That means it doesn't honour $libdir which it should, right? > Maybe > > you can bring this to upstream attention? > > Upstream did the right thing. See this file: > > /opt/csw/lib/python3.3/_sysconfigdata.py > > One difference between pentium_pro and amd64 is this: > > - 'DESTSHARED': '/opt/csw/lib/python3.3/lib-dynload', > + 'DESTSHARED': '/opt/csw/lib/64/python3.3/lib-dynload', > > Some other differences: > > - 'SIZEOF_LONG': 4, > - 'SIZEOF_LONG_DOUBLE': 12, > + 'SIZEOF_LONG': 8, > + 'SIZEOF_LONG_DOUBLE': 16, > > The full diff: http://dpaste.com/872770/ > > It looks like the upstream did the right thing. > > To accommodate both 32-bit and 64-bit versions of Python, we'll have > to use different _sysconfigdata.py files, which means we'll have to > configure it differently. > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfelecan at opencsw.org Sat Jan 12 10:14:15 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 12 Jan 2013 10:14:15 +0100 Subject: [csw-maintainers] inoperant reinplace In-Reply-To: (Carsten Grzemba's message of "Fri, 11 Jan 2013 10:35:17 +0100") References: <664d28fa2aa49fe56e15636a3804216d@opencsw.org> Message-ID: Carsten Grzemba writes: > Am 11.01.13 schrieb pfelecan : >> Still struggling to finish the packaging of TeXLive... >> >> Here is what I do: >> >> cd ~/opencsw/texlive/trunk >> find work -type f -name 'post-install-reinplace*' -print -exec rm {} \; >> nohup mgar platforms-remerge platforms-repackage < /dev/null > ~/logs/texlive 2>&1 & >> >> I got the following errors reported by checkpkg, with the afferent proposal of overriding: >> >> CHECKPKG_OVERRIDES_CSWtexlive-base += file-with-bad-content|/usr/local|root/opt/csw/share/texmf/scripts/simpdftex/simpdftex >> CHECKPKG_OVERRIDES_CSWtexlive-latex-extra += file-with-bad-content|/usr/local|root/opt/csw/share/texmf-dist/scripts/pax/pdfannotextractor.pl >> CHECKPKG_OVERRIDES_CSWtexlive-publishers-doc += file-with-bad-content|/usr/local|root/opt/csw/share/texmf-dist/doc/latex/confproc/buildpapers.sh >> CHECKPKG_OVERRIDES_CSWtexlive-publishers-doc += file-with-bad-content|/usr/local|root/opt/csw/share/texmf-dist/doc/latex/confproc/example/buildpapers.sh >> >> >> However, in the recipe I have the following stanzas: >> >> REINPLACE_WHEN_USRLOCAL = postinstall >> ... >> REINPLACE_USRLOCAL += /opt/csw/share/texmf/scripts/simpdftex/simpdftex >> REINPLACE_USRLOCAL += /opt/csw/share/texmf-dist/scripts/pax/pdfannotextractor.pl >> REINPLACE_USRLOCAL += /opt/csw/share/texmf-dist/doc/latex/confproc/buildpapers.sh >> REINPLACE_USRLOCAL += /opt/csw/share/texmf-dist/doc/latex/confproc/example/buildpapers.sh >> ... >> > I could use successfully REINPLACE_USRLOCAL only without 'REINPLACE_WHEN_USRLOCAL = postinstall' > and then it will done after the extract step/target so the path below $(WORKSRC) has to be used. I cannot use the default moment for the "reinplace", which is the extraction time, because some components are generated and some other are not part of the extraction from a conservative point of view... What your are saying is that the "postinstall" moment doesn't work? But all the other components are acted upon. Me thinks that there is something rotten in the "reinplace" process. Dago, you put this on your to do list. Is there some hope or I must proceed with my own "reinplace" method? -- Peter From pfelecan at opencsw.org Sat Jan 12 10:21:01 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 12 Jan 2013 10:21:01 +0100 Subject: [csw-maintainers] checkpkg error In-Reply-To: (Yann Rouillard's message of "Fri, 11 Jan 2013 18:40:40 +0100") References: Message-ID: Yann Rouillard writes: > I found the bug. A mistake in code indentation but leading to an error in > the execution path. This why, syntactically, Python throws me back in the glorious times of FORTRAN and COBOL on punched cards in the seventh decade of the last century... Semantically it's all right, the way back effect is lesser. -- Peter From pfelecan at opencsw.org Sat Jan 12 10:58:14 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 12 Jan 2013 10:58:14 +0100 Subject: [csw-maintainers] named catalog "beanie" Message-ID: Out of curiosity: what's the purpose of the catalog named "beanie"? On my local mirror: 6.8Gb. -- Peter From maciej at opencsw.org Sat Jan 12 11:04:37 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 12 Jan 2013 10:04:37 +0000 Subject: [csw-maintainers] named catalog "beanie" In-Reply-To: References: Message-ID: 2013/1/12 Peter FELECAN : > Out of curiosity: what's the purpose of the catalog named "beanie"? On > my local mirror: 6.8Gb. 'beanie' is a catalog which will be used for bigger rebuilds. The files in the beanie catalog, what hard link counts do they have? From bwalton at opencsw.org Sat Jan 12 11:05:49 2013 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 12 Jan 2013 10:05:49 +0000 Subject: [csw-maintainers] checkpkg error In-Reply-To: References: Message-ID: On Sat, Jan 12, 2013 at 9:21 AM, Peter FELECAN wrote: > Yann Rouillard writes: > >> I found the bug. A mistake in code indentation but leading to an error in >> the execution path. > > This why, syntactically, Python throws me back in the glorious times of > FORTRAN and COBOL on punched cards in the seventh decade of the last > century... Semantically it's all right, the way back effect is lesser. I agree with your sentiment. Personally, I'm ok with indentation as syntax but I keep coming back to the fact that Guido didn't go far enough. There is a sigil (colon) involved before indentation can increase but not before it can decrease. Had vertical spacing been made a part of the syntax as well as horizontal, this whole class of (easy to make) mistakes would be avoided. I'd argue that a blank line should have been required before the indentation level could be decreased. I wouldn't have been quite as visible as an "end" token or braces but it would help, I think. Thanks -Ben From pfelecan at opencsw.org Sat Jan 12 11:15:02 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 12 Jan 2013 11:15:02 +0100 Subject: [csw-maintainers] named catalog "beanie" In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sat, 12 Jan 2013 10:04:37 +0000") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/1/12 Peter FELECAN : >> Out of curiosity: what's the purpose of the catalog named "beanie"? On >> my local mirror: 6.8Gb. > > 'beanie' is a catalog which will be used for bigger rebuilds. The > files in the beanie catalog, what hard link counts do they have? Some of them 2. Anyway, thanks for the information. Now, what do you consider "bigger rebuilds"? -- Peter From maciej at opencsw.org Sat Jan 12 11:48:24 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 12 Jan 2013 10:48:24 +0000 Subject: [csw-maintainers] New catalog: 'beanie' Message-ID: Larger rebuilds have been historically difficult because we didn't want to keep any catalog in a broken state. We tried different workarounds, such as building on the test* hosts, but test* hosts are intended only for installing and testing packages, and never for building. A new solution we'll be trying out, is a separate rebuild catalog, with a set of own rebuild hosts. We will use the usual workflow of building, uploading and installing. When the whole rebuild is ready, and packages are working again, we'll integrate the changes back to the unstable catalog. You can upload packages to the beanie catalog the same way you can upload to unstable, with the only difference being that you need to specify which catalog release you're uploading to. csw-upload-pkg --catalog-release beanie [ ... ] It is possible to run more than one rebuild project in beanie, as long as these projects are independent. Ben and I are planning to perform the Python 2.6 rebuild in beanie. If you intend to use beanie, please first write to the list and coordinate with others. Please do not upload to beanie just because you can. Rebuild projects in beanie should be limited in time. If your rebuild takes a month, that's fine. But if it takes a year, it's too long. I hope that this approach will make our rebuilds easier. When we finish the Python release, I'll follow up with a summary of the rebuild project. Maciej From maciej at opencsw.org Sat Jan 12 12:29:06 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 12 Jan 2013 11:29:06 +0000 Subject: [csw-maintainers] Python 3.3 in 64 bits In-Reply-To: References: <15E0815A-014D-45EA-9308-43D6A13FE738@opencsw.org> Message-ID: 2013/1/12 Ben Walton : > Do you see a sane way to make the file live (and be referenced in) an > architecture specific directory? That would solve the problem. Maybe we could combine both versions of the file into one, and have an 'if' statement which would get us to import the right set of values. Maciej From maciej at opencsw.org Sat Jan 12 12:35:48 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 12 Jan 2013 11:35:48 +0000 Subject: [csw-maintainers] New catalog: 'beanie' In-Reply-To: References: Message-ID: To follow up on Peter Felecan's questions; the size taken up by this catalog should be small. You can check that the number of files with the hard link count equal to one is small. To check, you can run this command in e.g. beanie/sparc/5.10: find . -type f -printf '%f %n\n' | awk '$2 == 1' What are 'larger rebuilds'? Larger rebuilds are ones where you need to update a set of packages which: - form a dependency chain, so you can't rebuild everything at once - and the first rebuild breaks other packages - and the effort will span more than 24h Maciej From dam at opencsw.org Sat Jan 12 13:22:04 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 12 Jan 2013 13:22:04 +0100 Subject: [csw-maintainers] Python 3.3 in 64 bits In-Reply-To: References: <15E0815A-014D-45EA-9308-43D6A13FE738@opencsw.org> Message-ID: <9634E070-791C-46F0-B700-5524EB98E31B@opencsw.org> Hi, Am 12.01.2013 um 12:29 schrieb Maciej (Matchek) Blizi?ski: > 2013/1/12 Ben Walton : >> Do you see a sane way to make the file live (and be referenced in) an >> architecture specific directory? That would solve the problem. > > Maybe we could combine both versions of the file into one, and have an > 'if' statement which would get us to import the right set of values. The usual solution is to have one in lib and one in lib/64 being used by the respective python in bin/ and bin/64/ Best regards -- Dago From dam at opencsw.org Sat Jan 12 13:44:10 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 12 Jan 2013 13:44:10 +0100 Subject: [csw-maintainers] inoperant reinplace In-Reply-To: <664d28fa2aa49fe56e15636a3804216d@opencsw.org> References: <664d28fa2aa49fe56e15636a3804216d@opencsw.org> Message-ID: <7E060A2D-E0E4-42D5-8533-6D33E223506E@opencsw.org> Hi Peter, Am 11.01.2013 um 09:02 schrieb pfelecan: > Still struggling to finish the packaging of TeXLive... > > Here is what I do: > > cd ~/opencsw/texlive/trunk > find work -type f -name 'post-install-reinplace*' -print -exec rm {} \; > nohup mgar platforms-remerge platforms-repackage < /dev/null > ~/logs/texlive 2>&1 & > > I got the following errors reported by checkpkg, with the afferent proposal of overriding: > > CHECKPKG_OVERRIDES_CSWtexlive-base += file-with-bad-content|/usr/local|root/opt/csw/share/texmf/scripts/simpdftex/simpdftex > CHECKPKG_OVERRIDES_CSWtexlive-latex-extra += file-with-bad-content|/usr/local|root/opt/csw/share/texmf-dist/scripts/pax/pdfannotextractor.pl > CHECKPKG_OVERRIDES_CSWtexlive-publishers-doc += file-with-bad-content|/usr/local|root/opt/csw/share/texmf-dist/doc/latex/confproc/buildpapers.sh > CHECKPKG_OVERRIDES_CSWtexlive-publishers-doc += file-with-bad-content|/usr/local|root/opt/csw/share/texmf-dist/doc/latex/confproc/example/buildpapers.sh > > However, in the recipe I have the following stanzas: > > REINPLACE_WHEN_USRLOCAL = postinstall > ... > REINPLACE_USRLOCAL += /opt/csw/share/texmf/scripts/simpdftex/simpdftex > REINPLACE_USRLOCAL += /opt/csw/share/texmf-dist/scripts/pax/pdfannotextractor.pl > REINPLACE_USRLOCAL += /opt/csw/share/texmf-dist/doc/latex/confproc/buildpapers.sh > REINPLACE_USRLOCAL += /opt/csw/share/texmf-dist/doc/latex/confproc/example/buildpapers.sh > ... > > I don't understand why, on this specific files, the "reinplace" mechanism doesn't work. There are two things to check: 1. Is the reinplacement called on these files? Please take a look at your build log if this is the case or if there are errors. The command is always printed. 2. Does the replacement work? It is done with a simple perl-replacement here: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/gar.mk#L718 Please try perl -p -i.bak -e 's(/usr/local)(/opt/csw)g' if it works manually. From this outcome we see how to proceed further. Best regards -- Dago From pfelecan at opencsw.org Sat Jan 12 16:31:10 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 12 Jan 2013 16:31:10 +0100 Subject: [csw-maintainers] inoperant reinplace In-Reply-To: <7E060A2D-E0E4-42D5-8533-6D33E223506E@opencsw.org> (Dagobert Michelsen's message of "Sat, 12 Jan 2013 13:44:10 +0100") References: <664d28fa2aa49fe56e15636a3804216d@opencsw.org> <7E060A2D-E0E4-42D5-8533-6D33E223506E@opencsw.org> Message-ID: Dagobert Michelsen writes: > Hi Peter, > > Am 11.01.2013 um 09:02 schrieb pfelecan: >> Still struggling to finish the packaging of TeXLive... >> >> Here is what I do: >> >> cd ~/opencsw/texlive/trunk >> find work -type f -name 'post-install-reinplace*' -print -exec rm {} \; >> nohup mgar platforms-remerge platforms-repackage < /dev/null > ~/logs/texlive 2>&1 & >> >> I got the following errors reported by checkpkg, with the afferent proposal of overriding: >> >> CHECKPKG_OVERRIDES_CSWtexlive-base += file-with-bad-content|/usr/local|root/opt/csw/share/texmf/scripts/simpdftex/simpdftex >> CHECKPKG_OVERRIDES_CSWtexlive-latex-extra += file-with-bad-content|/usr/local|root/opt/csw/share/texmf-dist/scripts/pax/pdfannotextractor.pl >> CHECKPKG_OVERRIDES_CSWtexlive-publishers-doc += file-with-bad-content|/usr/local|root/opt/csw/share/texmf-dist/doc/latex/confproc/buildpapers.sh >> CHECKPKG_OVERRIDES_CSWtexlive-publishers-doc += file-with-bad-content|/usr/local|root/opt/csw/share/texmf-dist/doc/latex/confproc/example/buildpapers.sh >> >> However, in the recipe I have the following stanzas: >> >> REINPLACE_WHEN_USRLOCAL = postinstall >> ... >> REINPLACE_USRLOCAL += /opt/csw/share/texmf/scripts/simpdftex/simpdftex >> REINPLACE_USRLOCAL += /opt/csw/share/texmf-dist/scripts/pax/pdfannotextractor.pl >> REINPLACE_USRLOCAL += /opt/csw/share/texmf-dist/doc/latex/confproc/buildpapers.sh >> REINPLACE_USRLOCAL += /opt/csw/share/texmf-dist/doc/latex/confproc/example/buildpapers.sh >> ... >> >> I don't understand why, on this specific files, the "reinplace" mechanism doesn't work. > > There are two things to check: > > 1. Is the reinplacement called on these files? Please take a look at your build log if this is the case > or if there are errors. The command is always printed. I don't know. Which is the stanza to look for in the log file? Note that the log file is available as /home/pfelecan/logs/texlive > 2. Does the replacement work? It is done with a simple perl-replacement here: > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/gar.mk#L718 > Please try perl -p -i.bak -e 's(/usr/local)(/opt/csw)g' > if it works manually. Yes, tried on: /home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/install-isa-sparcv8plus/opt/csw/share/texmf/web2c/texmf.cnf -- Peter From bwalton at opencsw.org Sat Jan 12 18:32:26 2013 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 12 Jan 2013 17:32:26 +0000 Subject: [csw-maintainers] Python 3.3 in 64 bits In-Reply-To: <9634E070-791C-46F0-B700-5524EB98E31B@opencsw.org> References: <15E0815A-014D-45EA-9308-43D6A13FE738@opencsw.org> <9634E070-791C-46F0-B700-5524EB98E31B@opencsw.org> Message-ID: On Sat, Jan 12, 2013 at 12:22 PM, Dagobert Michelsen wrote: > Hi, > > Am 12.01.2013 um 12:29 schrieb Maciej (Matchek) Blizi?ski: >> 2013/1/12 Ben Walton : >>> Do you see a sane way to make the file live (and be referenced in) an >>> architecture specific directory? That would solve the problem. >> >> Maybe we could combine both versions of the file into one, and have an >> 'if' statement which would get us to import the right set of values. > > The usual solution is to have one in lib and one in lib/64 being used > by the respective python in bin/ and bin/64/ I think this would be a requirement. The lib directory should be separate or else binary modules will collide. Thanks -Ben From maciej at opencsw.org Sat Jan 12 19:39:03 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 12 Jan 2013 18:39:03 +0000 Subject: [csw-maintainers] Python 3.3 in 64 bits In-Reply-To: References: <15E0815A-014D-45EA-9308-43D6A13FE738@opencsw.org> <9634E070-791C-46F0-B700-5524EB98E31B@opencsw.org> Message-ID: 2013/1/12 Ben Walton : > I think this would be a requirement. The lib directory should be > separate or else binary modules will collide. The problem is that Python uses not one, but two different directories as 'lib': ${prefix}/lib/pythonX.Y for *.py files ${libdir} for binary objects From maciej at opencsw.org Sat Jan 12 20:22:08 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 12 Jan 2013 19:22:08 +0000 Subject: [csw-maintainers] named catalog "beanie" In-Reply-To: References: Message-ID: 2013/1/12 Peter FELECAN : > Some of them 2. Anyway, thanks for the information. Now, what do you > consider "bigger rebuilds"? FTR: http://lists.opencsw.org/pipermail/maintainers/2013-January/017593.html From dam at opencsw.org Sun Jan 13 11:36:26 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 13 Jan 2013 11:36:26 +0100 Subject: [csw-maintainers] inoperant reinplace In-Reply-To: References: <664d28fa2aa49fe56e15636a3804216d@opencsw.org> <7E060A2D-E0E4-42D5-8533-6D33E223506E@opencsw.org> Message-ID: <19DD6B54-BFAD-4CF2-A9D5-30B5A24DD674@opencsw.org> Hi Peter, Am 12.01.2013 um 16:31 schrieb Peter FELECAN: > Dagobert Michelsen writes: >> Am 11.01.2013 um 09:02 schrieb pfelecan: >>> Still struggling to finish the packaging of TeXLive... >>> >>> Here is what I do: >>> >>> cd ~/opencsw/texlive/trunk >>> find work -type f -name 'post-install-reinplace*' -print -exec rm {} \; >>> nohup mgar platforms-remerge platforms-repackage < /dev/null > ~/logs/texlive 2>&1 & >>> >>> I got the following errors reported by checkpkg, with the afferent proposal of overriding: >>> >>> CHECKPKG_OVERRIDES_CSWtexlive-base += file-with-bad-content|/usr/local|root/opt/csw/share/texmf/scripts/simpdftex/simpdftex >>> CHECKPKG_OVERRIDES_CSWtexlive-latex-extra += file-with-bad-content|/usr/local|root/opt/csw/share/texmf-dist/scripts/pax/pdfannotextractor.pl >>> CHECKPKG_OVERRIDES_CSWtexlive-publishers-doc += file-with-bad-content|/usr/local|root/opt/csw/share/texmf-dist/doc/latex/confproc/buildpapers.sh >>> CHECKPKG_OVERRIDES_CSWtexlive-publishers-doc += file-with-bad-content|/usr/local|root/opt/csw/share/texmf-dist/doc/latex/confproc/example/buildpapers.sh >>> >>> However, in the recipe I have the following stanzas: >>> >>> REINPLACE_WHEN_USRLOCAL = postinstall >>> ... >>> REINPLACE_USRLOCAL += /opt/csw/share/texmf/scripts/simpdftex/simpdftex >>> REINPLACE_USRLOCAL += /opt/csw/share/texmf-dist/scripts/pax/pdfannotextractor.pl >>> REINPLACE_USRLOCAL += /opt/csw/share/texmf-dist/doc/latex/confproc/buildpapers.sh >>> REINPLACE_USRLOCAL += /opt/csw/share/texmf-dist/doc/latex/confproc/example/buildpapers.sh >>> ... >>> >>> I don't understand why, on this specific files, the "reinplace" mechanism doesn't work. >> >> There are two things to check: >> >> 1. Is the reinplacement called on these files? Please take a look at your build log if this is the case >> or if there are errors. The command is always printed. > > I don't know. Which is the stanza to look for in the log file? > > Note that the log file is available as /home/pfelecan/logs/texlive From what I see there the reinplace is not invoked at all which does not match with your report. I notice however that you have placed the REINPLACEMENT assignments below the include gar.mk which is generally not recommended as some rules require variables to be defined when the Makefile code is read. I suggest moving them before the include. That means all definitions (with the exception of := overrides) before the include, all rules after the include. I have just reproduced the behaviour in a minimal example: postinstall-reinplacemenent does not work at all when the definitions are below the include. Some of that is written down at the coding style. https://sourceforge.net/apps/trac/gar/wiki/GarCodingStyle I have also added a note at https://sourceforge.net/apps/trac/gar/wiki/Reinplace >> 2. Does the replacement work? It is done with a simple perl-replacement here: >> http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/gar.mk#L718 >> Please try perl -p -i.bak -e 's(/usr/local)(/opt/csw)g' >> if it works manually. > > Yes, tried on: > > /home/pfelecan/opencsw/texlive/trunk/work/solaris10-sparc/install-isa-sparcv8plus/opt/csw/share/texmf/web2c/texmf.cnf I can verify that. Best regards -- Dago From dam at opencsw.org Sun Jan 13 11:44:26 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 13 Jan 2013 11:44:26 +0100 Subject: [csw-maintainers] Python 3.3 in 64 bits In-Reply-To: References: <15E0815A-014D-45EA-9308-43D6A13FE738@opencsw.org> <9634E070-791C-46F0-B700-5524EB98E31B@opencsw.org> Message-ID: <1C4C9A75-96DC-4814-958F-680FBF291091@opencsw.org> Hi Maciej, Am 12.01.2013 um 19:39 schrieb Maciej (Matchek) Blizi?ski: > 2013/1/12 Ben Walton : >> I think this would be a requirement. The lib directory should be >> separate or else binary modules will collide. > > The problem is that Python uses not one, but two different directories as 'lib': > ${prefix}/lib/pythonX.Y for *.py files > ${libdir} for binary objects This is... peculiar. Why would upstream put stuff in $(prefix)/lib instead of $(libdir) at all? Best regards -- Dago From pfelecan at opencsw.org Sun Jan 13 13:54:39 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 13 Jan 2013 13:54:39 +0100 Subject: [csw-maintainers] inoperant reinplace In-Reply-To: <19DD6B54-BFAD-4CF2-A9D5-30B5A24DD674@opencsw.org> (Dagobert Michelsen's message of "Sun, 13 Jan 2013 11:36:26 +0100") References: <664d28fa2aa49fe56e15636a3804216d@opencsw.org> <7E060A2D-E0E4-42D5-8533-6D33E223506E@opencsw.org> <19DD6B54-BFAD-4CF2-A9D5-30B5A24DD674@opencsw.org> Message-ID: Dagobert Michelsen writes: > Am 12.01.2013 um 16:31 schrieb Peter FELECAN: >> Dagobert Michelsen writes: >>> Am 11.01.2013 um 09:02 schrieb pfelecan: >>>> Still struggling to finish the packaging of TeXLive... >>>> >>>> Here is what I do: >>>> >>>> cd ~/opencsw/texlive/trunk >>>> find work -type f -name 'post-install-reinplace*' -print -exec rm {} \; >>>> nohup mgar platforms-remerge platforms-repackage < /dev/null > ~/logs/texlive 2>&1 & >>>> >>>> I got the following errors reported by checkpkg, with the afferent proposal of overriding: >>>> >>>> CHECKPKG_OVERRIDES_CSWtexlive-base += file-with-bad-content|/usr/local|root/opt/csw/share/texmf/scripts/simpdftex/simpdftex >>>> CHECKPKG_OVERRIDES_CSWtexlive-latex-extra += file-with-bad-content|/usr/local|root/opt/csw/share/texmf-dist/scripts/pax/pdfannotextractor.pl >>>> CHECKPKG_OVERRIDES_CSWtexlive-publishers-doc += file-with-bad-content|/usr/local|root/opt/csw/share/texmf-dist/doc/latex/confproc/buildpapers.sh >>>> CHECKPKG_OVERRIDES_CSWtexlive-publishers-doc += file-with-bad-content|/usr/local|root/opt/csw/share/texmf-dist/doc/latex/confproc/example/buildpapers.sh >>>> >>>> However, in the recipe I have the following stanzas: >>>> >>>> REINPLACE_WHEN_USRLOCAL = postinstall >>>> ... >>>> REINPLACE_USRLOCAL += /opt/csw/share/texmf/scripts/simpdftex/simpdftex >>>> REINPLACE_USRLOCAL += /opt/csw/share/texmf-dist/scripts/pax/pdfannotextractor.pl >>>> REINPLACE_USRLOCAL += /opt/csw/share/texmf-dist/doc/latex/confproc/buildpapers.sh >>>> REINPLACE_USRLOCAL += /opt/csw/share/texmf-dist/doc/latex/confproc/example/buildpapers.sh >>>> ... >>>> >>>> I don't understand why, on this specific files, the "reinplace" mechanism doesn't work. >>> >>> There are two things to check: >>> >>> 1. Is the reinplacement called on these files? Please take a look at your build log if this is the case >>> or if there are errors. The command is always printed. >> >> I don't know. Which is the stanza to look for in the log file? >> >> Note that the log file is available as /home/pfelecan/logs/texlive > >>From what I see there the reinplace is not invoked at all which does not match with your > report. I notice however that you have placed the REINPLACEMENT assignments below the > include gar.mk which is generally not recommended as some rules require variables to be > defined when the Makefile code is read. I suggest moving them before the include. > That means all definitions (with the exception of := overrides) before the include, > all rules after the include. > > I have just reproduced the behaviour in a minimal example: postinstall-reinplacemenent > does not work at all when the definitions are below the include. > > Some of that is written down at the coding style. > https://sourceforge.net/apps/trac/gar/wiki/GarCodingStyle > > I have also added a note at > https://sourceforge.net/apps/trac/gar/wiki/Reinplace I will modify, retry and keep informed. Thank you. -- Peter From maciej at opencsw.org Sun Jan 13 23:55:40 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 13 Jan 2013 22:55:40 +0000 Subject: [csw-maintainers] FOSDEM 2013 Message-ID: Hi guys, I just booked my flight to FOSDEM 2013, I'll be arriving Friday morning. I missed last camp and I'm hoping to meet you again, the more, the merrier! Is anyone going to FOSDEM this year? How about an OpenCSW social dinner Friday night? Maciej From claudio at opencsw.org Mon Jan 14 20:28:05 2013 From: claudio at opencsw.org (Claudio) Date: Mon, 14 Jan 2013 20:28:05 +0100 Subject: [csw-maintainers] FOSDEM 2013 In-Reply-To: References: Message-ID: <50F45C45.4050708@opencsw.org> On 13-01-13 23:55, Maciej (Matchek) Blizi?ski wrote: > Hi guys, > > I just booked my flight to FOSDEM 2013, I'll be arriving Friday > morning. I missed last camp and I'm hoping to meet you again, the > more, the merrier! > > Is anyone going to FOSDEM this year? How about an OpenCSW social > dinner Friday night? Wonderful news. If we want to have good food, it would be good to make a reservation somewhere. So once we know how many people are coming I can arrange something. C. From dam at opencsw.org Tue Jan 15 10:14:39 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 15 Jan 2013 10:14:39 +0100 Subject: [csw-maintainers] [Opencsw] Preserve smf state and configuration files when you rename a package In-Reply-To: References: Message-ID: <07B07F6F-07BA-49F4-BA7B-5E8690A436C3@opencsw.org> Hi Yann, (moving to maintainers@) Am 15.01.2013 um 00:00 schrieb Yann Rouillard : > I want to release a new openssh package which includes the rename, however I have to take care of preserving configuration and smf state. > > This is done through cswinitsmf and preserveconf classes however they store information in /etc/csw/opt/PKGNAME and as I will change the name of the package, it will not work (and I verified this). > > I want to update the action scripts to handle this case but I would need the information about obsoleted packages available in the scripts. > > I think one way would be to add them in the pkginfo file so I can easily retrieve them through environment variables. > > I think we should also need a way to disable this mecanism as it may probably happen that this behavior is not desired in some cases. > > What do you think about this issue ? Do you see a better way to solve this problem ? Sounds reasonable. I could add OPENCSW_OBSOLETES=CSW in pkginfo which should then picked up in addition to the real package name in cswinitsmf. 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 Jan 15 11:15:37 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 15 Jan 2013 11:15:37 +0100 Subject: [csw-maintainers] Fwd: [csw-pkgrequests] New package request : PDFtk References: <201301142142.r0ELgduR003644@www.opencsw.org> Message-ID: <59876421-B7FB-4F9B-B9D9-EBC94F2DBA9E@opencsw.org> Hi folks, Anfang der weitergeleiteten Nachricht: > Von: pkgrequest at lists.opencsw.org > Betreff: [csw-pkgrequests] New package request : PDFtk > Datum: 14. Januar 2013 22:42:39 MEZ > An: pkgrequests at lists.opencsw.org > > Dear maintainers, > > A new package request has been received from Owen Eng (mailto:owen.eng at rogers.com). PDFtk is requested to be added to our catalog. > > Here is the attached message : > > http://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/ > > This is a package that is commonly available for linux distros. It would be really nice to have a package here for Solaris. What do you think? I wanted to take a look, but stumbled upon a problem with gcj: > dam at unstable10s [unstable10s]:/home/dam/mgar/pkg/pdftk/trunk/work/solaris10-sparc/build-isa-sparcv8plus/pdftk-1.45-dist/pdftk > gmake TOOLPATH=/opt/csw/gcc4/bin/ -f Makefile.Solaris > gmake -f Makefile -iC ../java all > gmake[1]: Entering directory `/home/dam/mgar/pkg/pdftk/trunk/work/solaris10-sparc/build-isa-sparcv8plus/pdftk-1.45-dist/java' > /opt/csw/gcc4/bin/gcj -Wall -Wextra -fsource=1.3 -O2 --encoding=UTF-8 --classpath="/usr/share/java/libgcj.jar:/home/dam/mgar/pkg/pdftk/trunk/work/solaris10-sparc/build-isa-sparcv8plus/pdftk-1.45-dist/java:." -C com/lowagie/text/ElementTags.java > gcj: error trying to exec 'ecj1': execvp: No such file or directory > gmake[1]: [com/lowagie/text/ElementTags.class] Error 1 (ignored) > /opt/csw/gcc4/bin/gcjh -force --classpath="/usr/share/java/libgcj.jar:/home/dam/mgar/pkg/pdftk/trunk/work/solaris10-sparc/build-isa-sparcv8plus/pdftk-1.45-dist/java:." com/lowagie/text/ElementTags > ld.so.1: gcjh-4.7: fatal: relocation error: file /opt/csw/lib/libgcj.so.13: symbol libiconv_open: referenced symbol not found > Killed Indeed, here is -liconv missing: dam at unstable10s [unstable10s]:/home/dam/mgar/pkg/pdftk/trunk/work/solaris10-sparc/build-isa-sparcv8plus/pdftk-1.45-dist/java > ldd -r /opt/csw/lib/libgcj.so.13 libpthread.so.1 => /lib/libpthread.so.1 librt.so.1 => /lib/librt.so.1 libdl.so.1 => /lib/libdl.so.1 libsocket.so.1 => /lib/libsocket.so.1 libnsl.so.1 => /lib/libnsl.so.1 libgcc_s.so.1 => /opt/csw/lib/sparcv8/libgcc_s.so.1 libc.so.1 => /lib/libc.so.1 libaio.so.1 => /lib/libaio.so.1 libmd.so.1 => /lib/libmd.so.1 libmp.so.2 => /lib/libmp.so.2 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 /platform/SUNW,SPARC-Enterprise-T5220/lib/libc_psr.so.1 symbol not found: libiconv_open (/opt/csw/lib/libgcj.so.13) symbol not found: libiconv_close (/opt/csw/lib/libgcj.so.13) symbol not found: libiconv (/opt/csw/lib/libgcj.so.13) /platform/SUNW,SPARC-Enterprise-T5220/lib/libmd_psr.so.1 libm.so.2 => /lib/libm.so.2 dam at unstable10s [unstable10s]:/home/dam/mgar/pkg/pdftk/trunk/work/solaris10-sparc/build-isa-sparcv8plus/pdftk-1.45-dist/java > dump -Lv /opt/csw/lib/libgcj.so.13 /opt/csw/lib/libgcj.so.13: **** DYNAMIC SECTION INFORMATION **** .dynamic: [INDEX] Tag Value [1] POSFLAG_1 LAZYLOAD [2] NEEDED libpthread.so.1 [3] POSFLAG_1 LAZYLOAD [4] NEEDED librt.so.1 [5] POSFLAG_1 LAZYLOAD [6] NEEDED libdl.so.1 [7] POSFLAG_1 LAZYLOAD [8] NEEDED libsocket.so.1 [9] POSFLAG_1 LAZYLOAD [10] NEEDED libnsl.so.1 [11] POSFLAG_1 LAZYLOAD [12] NEEDED libgcc_s.so.1 [13] NEEDED libc.so.1 [14] INIT 0x1884af0 [15] FINI 0x1884b0c [16] SONAME libgcj.so.13 [17] RUNPATH /opt/csw/lib/$ISALIST:/opt/csw/lib [18] RPATH /opt/csw/lib/$ISALIST:/opt/csw/lib [19] HASH 0xa9008 [20] STRTAB 0x22d46c [21] STRSZ 0x44eac3 [22] SYMTAB 0x12a6ec [23] SYMENT 0x10 [24] CHECKSUM 0x50f6 [25] VERDEF 0x67c0e0 [26] VERDEFNUM 0x1 [27] VERNEED 0x67bf30 [28] VERNEEDNUM 0x7 [29] RELACOUNT 0x7857d [30] PLTSZ 0x22548 [31] PLTREL 0x7 [32] JMPREL 0xeafe98 [33] RELA 0x69c6ac [34] RELASZ 0x835d34 [35] RELAENT 0xc [36] SYMINFO 0x684a8 [37] SYMINSZ 0x40b60 [38] SYMINENT 0x4 [39] FLAGS 0 [40] FLAGS_1 0 [41] SUNW_STRPAD 0x200 [42] SUNW_LDMACH EM_SPARC [43] PLTGOT 0x1f09934 > gmake[1]: [com/lowagie/text/ElementTags.h] Error 137 (ignored) > /opt/csw/gcc4/bin/gcj -Wall -Wextra -fsource=1.3 -O2 --encoding=UTF-8 --classpath="/usr/share/java/libgcj.jar:/home/dam/mgar/pkg/pdftk/trunk/work/solaris10-sparc/build-isa-sparcv8plus/pdftk-1.45-dist/java:." -C com/lowagie/text/List.java > gcj: error trying to exec 'ecj1': execvp: No such file or directory We don't seem to have ecj1 at all. > gmake[1]: [com/lowagie/text/List.class] Error 1 (ignored) > /opt/csw/gcc4/bin/gcjh -force --classpath="/usr/share/java/libgcj.jar:/home/dam/mgar/pkg/pdftk/trunk/work/solaris10-sparc/build-isa-sparcv8plus/pdftk-1.45-dist/java:." com/lowagie/text/List > ld.so.1: gcjh-4.7: fatal: relocation error: file /opt/csw/lib/libgcj.so.13: symbol libiconv_open: referenced symbol not found > Killed > gmake[1]: [com/lowagie/text/List.h] Error 137 (ignored) > /opt/csw/gcc4/bin/gcj -Wall -Wextra -fsource=1.3 -O2 --encoding=UTF-8 --classpath="/usr/share/java/libgcj.jar:/home/dam/mgar/pkg/pdftk/trunk/work/solaris10-sparc/build-isa-sparcv8plus/pdftk-1.45-dist/java:." -C com/lowagie/text/Anchor.java > gcj: error trying to exec 'ecj1': execvp: No such file or directory > gmake[1]: [com/lowagie/text/Anchor.class] Error 1 (ignored) > /opt/csw/gcc4/bin/gcjh -force --classpath="/usr/share/java/libgcj.jar:/home/dam/mgar/pkg/pdftk/trunk/work/solaris10-sparc/build-isa-sparcv8plus/pdftk-1.45-dist/java:." com/lowagie/text/Anchor > ^C[gmake[1]: *** wait: No child processes. Stop. > gmake[1]: *** Waiting for unfinished jobs.... > gmake[1]: *** wait: No child processes. Stop. > gmake: *** [javalib] Error 2 Maciej, any idea on how to fix these? 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 Jan 15 12:51:51 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 15 Jan 2013 11:51:51 +0000 Subject: [csw-maintainers] Fwd: [csw-pkgrequests] New package request : PDFtk In-Reply-To: <59876421-B7FB-4F9B-B9D9-EBC94F2DBA9E@opencsw.org> References: <201301142142.r0ELgduR003644@www.opencsw.org> <59876421-B7FB-4F9B-B9D9-EBC94F2DBA9E@opencsw.org> Message-ID: >From quick googling: http://gcc.gnu.org/ml/java/2009-04/msg00026.html GCC uses Eclipse Java parses, which has to be downloaded separately. So it's a GCC packaging issue. Relevant: http://tinyurl.com/3o4zp5k -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Tue Jan 15 13:37:40 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 15 Jan 2013 13:37:40 +0100 Subject: [csw-maintainers] Fwd: [csw-pkgrequests] New package request : PDFtk In-Reply-To: References: <201301142142.r0ELgduR003644@www.opencsw.org> <59876421-B7FB-4F9B-B9D9-EBC94F2DBA9E@opencsw.org> Message-ID: <9864B8D7-BB5E-447F-BCC0-A328D1932528@opencsw.org> Hi Maciej, Am 15.01.2013 um 12:51 schrieb Maciej (Matchek) Blizi?ski : > From quick googling: > > http://gcc.gnu.org/ml/java/2009-04/msg00026.html > > GCC uses Eclipse Java parses, which has to be downloaded separately. So it's a GCC packaging issue. Much better, I now get dam at unstable10s [unstable10s]:/home/dam/mgar/pkg/pdftk/trunk/work/solaris10-sparc/build-isa-sparcv8plus/pdftk-1.45-dist/java > /opt/csw/bin/ecj1 ld.so.1: gcj-dbtool-4.7: fatal: relocation error: file /opt/csw/lib/sparcv8/libgcj.so.13: symbol libiconv_open: referenced symbol not found ld.so.1: gcj-dbtool-4.7: fatal: relocation error: file /opt/csw/lib/sparcv8/libgcj.so.13: symbol libiconv_open: referenced symbol not found which is the same error as before with the missing -liconv. I'll package that up as CSWecj providing /opt/csw/share/java/ecj.jar and /opt/csw/bin/ecj. Would you mind adding that as rdep to CSWgcc4java? > Relevant: http://tinyurl.com/3o4zp5k More like http://www.zinzin.com/wp-content/uploads/2012/10/yak-shaving.jpg 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 Jan 15 14:24:15 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 15 Jan 2013 13:24:15 +0000 Subject: [csw-maintainers] Fwd: [csw-pkgrequests] New package request : PDFtk In-Reply-To: <9864B8D7-BB5E-447F-BCC0-A328D1932528@opencsw.org> References: <201301142142.r0ELgduR003644@www.opencsw.org> <59876421-B7FB-4F9B-B9D9-EBC94F2DBA9E@opencsw.org> <9864B8D7-BB5E-447F-BCC0-A328D1932528@opencsw.org> Message-ID: 2013/1/15 Dagobert Michelsen > > which is the same error as before with the missing -liconv. How did this even link at compile stage? From maciej at opencsw.org Tue Jan 15 14:24:42 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 15 Jan 2013 13:24:42 +0000 Subject: [csw-maintainers] Fwd: [csw-pkgrequests] New package request : PDFtk In-Reply-To: <9864B8D7-BB5E-447F-BCC0-A328D1932528@opencsw.org> References: <201301142142.r0ELgduR003644@www.opencsw.org> <59876421-B7FB-4F9B-B9D9-EBC94F2DBA9E@opencsw.org> <9864B8D7-BB5E-447F-BCC0-A328D1932528@opencsw.org> Message-ID: 2013/1/15 Dagobert Michelsen : > I'll package that up as CSWecj providing /opt/csw/share/java/ecj.jar and /opt/csw/bin/ecj. > Would you mind adding that as rdep to CSWgcc4java? I'm lazy. Please file a bug. :-P From dam at opencsw.org Tue Jan 15 14:27:26 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 15 Jan 2013 14:27:26 +0100 Subject: [csw-maintainers] Fwd: [csw-pkgrequests] New package request : PDFtk In-Reply-To: References: <201301142142.r0ELgduR003644@www.opencsw.org> <59876421-B7FB-4F9B-B9D9-EBC94F2DBA9E@opencsw.org> <9864B8D7-BB5E-447F-BCC0-A328D1932528@opencsw.org> Message-ID: <77727C51-034D-4CB2-9497-DD6FEBDAD484@opencsw.org> Hi Maciej, Am 15.01.2013 um 14:24 schrieb Maciej (Matchek) Blizi?ski : > 2013/1/15 Dagobert Michelsen >> >> which is the same error as before with the missing -liconv. > > How did this even link at compile stage? Don't know. Question about the dependencies: /opt/csw/bin/ecj1 would call gij which is part of CSWgcc4java but that package itself needs the ecj stuff. Circular dependency? I changed the package name for the ecj stuff to CSWjdt-core-batch-compiler 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 maciej at opencsw.org Tue Jan 15 14:32:39 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 15 Jan 2013 13:32:39 +0000 Subject: [csw-maintainers] Fwd: [csw-pkgrequests] New package request : PDFtk In-Reply-To: <77727C51-034D-4CB2-9497-DD6FEBDAD484@opencsw.org> References: <201301142142.r0ELgduR003644@www.opencsw.org> <59876421-B7FB-4F9B-B9D9-EBC94F2DBA9E@opencsw.org> <9864B8D7-BB5E-447F-BCC0-A328D1932528@opencsw.org> <77727C51-034D-4CB2-9497-DD6FEBDAD484@opencsw.org> Message-ID: 2013/1/15 Dagobert Michelsen : > Don't know. Question about the dependencies: /opt/csw/bin/ecj1 would call gij > which is part of CSWgcc4java but that package itself needs the ecj stuff. > Circular dependency? I changed the package name for the ecj stuff to > CSWjdt-core-batch-compiler though. I'd keep the name CSWecj, because it's simpler. That it's a Java parser, can be put into the description. It is a circular dependency, but since CSWecj serves little purpose on its own, I would make CSWgcc4-java depend on CSWecj and not worry about the inner workings. We could explain the reasoning in a README file. From dam at opencsw.org Tue Jan 15 14:39:16 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 15 Jan 2013 14:39:16 +0100 Subject: [csw-maintainers] Fwd: [csw-pkgrequests] New package request : PDFtk In-Reply-To: References: <201301142142.r0ELgduR003644@www.opencsw.org> <59876421-B7FB-4F9B-B9D9-EBC94F2DBA9E@opencsw.org> <9864B8D7-BB5E-447F-BCC0-A328D1932528@opencsw.org> <77727C51-034D-4CB2-9497-DD6FEBDAD484@opencsw.org> Message-ID: Hi Maciej, Am 15.01.2013 um 14:32 schrieb Maciej (Matchek) Blizi?ski : > 2013/1/15 Dagobert Michelsen : >> Don't know. Question about the dependencies: /opt/csw/bin/ecj1 would call gij >> which is part of CSWgcc4java but that package itself needs the ecj stuff. >> Circular dependency? I changed the package name for the ecj stuff to >> CSWjdt-core-batch-compiler though. > > I'd keep the name CSWecj, because it's simpler. That it's a Java > parser, can be put into the description. > > It is a circular dependency, but since CSWecj serves little purpose on > its own, I would make CSWgcc4-java depend on CSWecj and not worry > about the inner workings. We could explain the reasoning in a README > file. CSWecj uploaded. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From grzemba at contac-dt.de Tue Jan 15 17:16:23 2013 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Tue, 15 Jan 2013 17:16:23 +0100 Subject: [csw-maintainers] bad-rpath problem In-Reply-To: References: Message-ID: Can anybody help: why produce this command: cc -G -h libnssutil3.so -z combreloc -z defs -z ignore -z ignore -Bdirect -R/opt/csw/lib/$ISALIST -M SunOS5.10_OPT.OBJ/nssutil.def -o SunOS5.10_OPT.OBJ/libnssutil3.so SunOS5.10_OPT.OBJ/quickder.o SunOS5.10_OPT.OBJ/secdig.o SunOS5.10_OPT.OBJ/derdec.o SunOS5.10_OPT.OBJ/derenc.o SunOS5.10_OPT.OBJ/dersubr.o SunOS5.10_OPT.OBJ/dertime.o SunOS5.10_OPT.OBJ/errstrs.o SunOS5.10_OPT.OBJ/nssb64d.o SunOS5.10_OPT.OBJ/nssb64e.o SunOS5.10_OPT.OBJ/nssrwlk.o SunOS5.10_OPT.OBJ/nssilock.o SunOS5.10_OPT.OBJ/oidstring.o SunOS5.10_OPT.OBJ/portreg.o SunOS5.10_OPT.OBJ/secalgid.o SunOS5.10_OPT.OBJ/secasn1d.o SunOS5.10_OPT.OBJ/secasn1e.o SunOS5.10_OPT.OBJ/secasn1u.o SunOS5.10_OPT.OBJ/secitem.o SunOS5.10_OPT.OBJ/secload.o SunOS5.10_OPT.OBJ/secoid.o SunOS5.10_OPT.OBJ/sectime.o SunOS5.10_OPT.OBJ/secport.o SunOS5.10_OPT.OBJ/templates.o SunOS5.10_OPT.OBJ/utf8.o SunOS5.10_OPT.OBJ/utilmod.o SunOS5.10_OPT.OBJ/utilpars.o -L../../../../dist/SunOS5.10_OPT.OBJ/lib -L/opt/csw/lib -lplc4 -lplds4 -lnspr4 -lthread -lnsl -lsocket -lposix4 -ldl -lc such a rpath, which is in opencsw policy is not allowed: lus/nss-3.14.1/mozilla/security/nss/lib/util$ ldd -s SunOS5.10_OPT.OBJ/libnssutil3.so | more find object=libplc4.so; required by SunOS5.10_OPT.OBJ/libnssutil3.so search path=/opt/csw/lib/$ISALIST:/opt/csw/lib/ (RUNPATH/RPATH from file SunOS5.10_OPT.OBJ/libnssutil3.so) trying path=/opt/csw/lib/sparcv9+vis2/libplc4.so trying path=/opt/csw/lib/sparcv9+vis/libplc4.so trying path=/opt/csw/lib/sparcv9/libplc4.so trying path=/opt/csw/lib/sparcv8plus+vis2/libplc4.so trying path=/opt/csw/lib/sparcv8plus+vis/libplc4.so trying path=/opt/csw/lib/sparcv8plus/libplc4.so trying path=/opt/csw/lib/sparcv8/libplc4.so libplc4.so => /opt/csw/lib/sparcv8/libplc4.so -- Carsten Grzemba -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Tue Jan 15 23:11:14 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 15 Jan 2013 22:11:14 +0000 Subject: [csw-maintainers] bad-rpath problem In-Reply-To: References: Message-ID: 2013/1/15 Carsten Grzemba : > search path=/opt/csw/lib/$ISALIST:/opt/csw/lib/ (RUNPATH/RPATH from > file SunOS5.10_OPT.OBJ/libnssutil3.so) I see -R/opt/csw/lib/$ISALIST in the invocation. If this is expanded in shell, it can result in /opt/csw/lib/. It does no harm, but shows that the build system runs eval against variables an inconsistent number of times. Maciej From dam at opencsw.org Wed Jan 16 12:33:26 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 16 Jan 2013 12:33:26 +0100 Subject: [csw-maintainers] The OpenCSW Manual Message-ID: Hi folks, the manual is now generated once an hour directly on the webserver and is reachable at http://www.opencsw.org/manual We should now link it directly from the webpage, any suggestions? 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 jcraig at opencsw.org Wed Jan 16 13:56:52 2013 From: jcraig at opencsw.org (Jonathan Craig) Date: Wed, 16 Jan 2013 07:56:52 -0500 Subject: [csw-maintainers] The OpenCSW Manual In-Reply-To: References: Message-ID: On Wed, Jan 16, 2013 at 6:33 AM, Dagobert Michelsen wrote: > Hi folks, > > the manual is now generated once an hour directly on the webserver and is reachable at > http://www.opencsw.org/manual > > We should now link it directly from the webpage, any suggestions? Should I be receiving a "forbidden" page when I hit that URL? Jon From dam at opencsw.org Wed Jan 16 14:31:51 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 16 Jan 2013 14:31:51 +0100 Subject: [csw-maintainers] The OpenCSW Manual In-Reply-To: References: Message-ID: <75440FE5-EFEF-48E2-BB67-D5403A880D13@opencsw.org> Hi Jon, Am 16.01.2013 um 13:56 schrieb Jonathan Craig : > On Wed, Jan 16, 2013 at 6:33 AM, Dagobert Michelsen wrote: >> the manual is now generated once an hour directly on the webserver and is reachable at >> http://www.opencsw.org/manual >> >> We should now link it directly from the webpage, any suggestions? > > Should I be receiving a "forbidden" page when I hit that URL? Umh, no. I am still tweaking the cronjob? 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 Jan 16 14:43:01 2013 From: pfelecan at opencsw.org (pfelecan) Date: Wed, 16 Jan 2013 14:43:01 +0100 Subject: [csw-maintainers] there is something rotten around checkpkg Message-ID: Since 2 day, checkpkg is very slow (n ote that I regularly svn up the ~/opencsw/.buildsys/v2 directory). On the bo build farm: - The last re-packaging of TeXLive failed with the message "out of space" when checkpkg. - Guile packaging is one order of magnitude slower than Monday, snailing through checkpkg. On my build farm the update of the database, SQLite version, is much slower than usual, after 24 hours it's only at 47% Me thinks that there is something rotten... From dam at opencsw.org Wed Jan 16 16:10:38 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 16 Jan 2013 16:10:38 +0100 Subject: [csw-maintainers] there is something rotten around checkpkg In-Reply-To: References: Message-ID: <390B872A-7A79-49DC-8E94-877A20D6929B@opencsw.org> Hi Peter, Am 16.01.2013 um 14:43 schrieb pfelecan : > Since 2 day, checkpkg is very slow (n ote that I regularly svn up the ~/opencsw/.buildsys/v2 directory). > > On the bo build farm: > > - The last re-packaging of TeXLive failed with the message "out of space" when checkpkg. > > - Guile packaging is one order of magnitude slower than Monday, snailing through checkpkg. > > On my build farm the update of the database, SQLite version, is much slower than usual, after 24 hours it's only at 47% > > Me thinks that there is something rotten... The new link symbol inspection is in place for some time now, maybe it has some serious drawbacks on database access? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Wed Jan 16 16:42:41 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 16 Jan 2013 15:42:41 +0000 Subject: [csw-maintainers] there is something rotten around checkpkg In-Reply-To: <390B872A-7A79-49DC-8E94-877A20D6929B@opencsw.org> References: <390B872A-7A79-49DC-8E94-877A20D6929B@opencsw.org> Message-ID: 2013/1/16 Dagobert Michelsen : > The new link symbol inspection is in place for some time now, maybe it has > some serious drawbacks on database access? Some packages produce metadata objects serializing to more than 32MB. The out of space error could be a memory leak which I have been fighting over the weekend, but did not manage to find the cause. In my case, I was trying to run a full catalog import. Peter, what operation is causing the out of space error? How much RAM does the machine have? Maciej From pfelecan at opencsw.org Wed Jan 16 20:01:59 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 16 Jan 2013 20:01:59 +0100 Subject: [csw-maintainers] there is something rotten around checkpkg In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Wed, 16 Jan 2013 15:42:41 +0000") References: <390B872A-7A79-49DC-8E94-877A20D6929B@opencsw.org> Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/1/16 Dagobert Michelsen : >> The new link symbol inspection is in place for some time now, maybe it has >> some serious drawbacks on database access? > > Some packages produce metadata objects serializing to more than 32MB. > The out of space error could be a memory leak which I have been > fighting over the weekend, but did not manage to find the cause. In my > case, I was trying to run a full catalog import. > > Peter, what operation is causing the out of space error? How much RAM > does the machine have? The "out of space" issue happened when packaging the *huge* TeXLive hundred packages on the Baltic Online build farm; I think that you know better than me how much RAM unstable10s and its companions have. I'm trying again but one cycle merge-package is long: I start the process in the morning and have the results the other day. You can see the log of the action in progress in ~pfelecan/logs/texlive -- Peter From pfelecan at opencsw.org Fri Jan 18 09:18:38 2013 From: pfelecan at opencsw.org (pfelecan) Date: Fri, 18 Jan 2013 09:18:38 +0100 Subject: [csw-maintainers] there is something rotten around checkpkg Message-ID: Here is the last issue when generating TeXLive packages --- IMHO, there is also something smelly in our infrastructure... quotas anyone? mmkp: exec( rm -rf /home/pfelecan/spool.5.10-sparc/CSWtexpdftricks )ESC[0m INFO:root:Juicing the svr4 package stream files... 0% | | ^M 1% | |^M 2% |# |^M 3% |## |^M 4% |### |^M 5% |### |^M 6% |#### |^M 7% |##### |^M 8% |###### | gzip: /var/tmp/pkg_hIPv8o/texlive_common-20120701,REV=2013.01.16-SunOS5.10-all-CSW.pkg: Disc quota exceeded CRITICAL:root:None CRITICAL:root:None Traceback (most recent call last): File "/home/pfelecan/opencsw/.buildsys/v2/gar//bin/checkpkg", line 197, in main() File "/home/pfelecan/opencsw/.buildsys/v2/gar//bin/checkpkg", line 120, in main stats_list = collector.CollectStatsFromFiles(file_list, None) File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py", line 499, in CollectStatsFromFiles stats.CollectStats(force=force_unpack) File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py", line 175, in CollectStats return self._CollectStats(register_files=register_files) File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py", line 187, in _CollectStats dir_pkg = self.GetInspectivePkg() File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py", line 120, in GetInspectivePkg self.dir_format_pkg = self.srv4_pkg.GetInspectivePkg() File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/inspective_package.py", line 744, in GetInspectivePkg return self.GetDirFormatPkg() File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package.py", line 173, in GetDirFormatPkg self.TransformToDir() File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package.py", line 158, in TransformToDir gunzipped_path = self.GetGunzippedPath() File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package.py", line 95, in GetGunzippedPath unused_retcode = self.ShellCommand(args) File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/shell.py", line 34, in ShellCommand raise Error("Running %s has failed." % repr(args)) shell.Error: Running ['gunzip', '-f', '/var/tmp/pkg_hIPv8o/texlive_common-20120701,REV=2013.01.16-SunOS5.10-all-CSW.pkg.gz'] has failed. gmake[1]: *** [pkgcheck] Error 2 gmake: *** [platforms-repackage] Error 2 From jh at opencsw.org Fri Jan 18 09:23:44 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Fri, 18 Jan 2013 09:23:44 +0100 Subject: [csw-maintainers] there is something rotten around checkpkg In-Reply-To: References: Message-ID: <50F90690.8020207@opencsw.org> Hi, Am 18.01.13 09:18, schrieb pfelecan: > Here is the last issue when generating TeXLive packages --- IMHO, there > is also something smelly in our infrastructure... quotas anyone? > > mmkp: exec( rm -rf /home/pfelecan/spool.5.10-sparc/CSWtexpdftricks )ESC[0m > INFO:root:Juicing the svr4 package stream files... > 0% | > | > ^M 1% | > |^M 2% |# > |^M 3% |## > |^M 4% |### > |^M 5% |### > |^M 6% |#### > |^M 7% |##### > |^M 8% |###### > | > gzip: > /var/tmp/pkg_hIPv8o/texlive_common-20120701,REV=2013.01.16-SunOS5.10-all-CSW.pkg: > Disc quota exceeded <-- will clean this up :) We need to have some cleanjob I guess. :) Greetings Jan From maciej at opencsw.org Fri Jan 18 10:25:58 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 18 Jan 2013 09:25:58 +0000 Subject: [csw-maintainers] there is something rotten around checkpkg In-Reply-To: References: Message-ID: 2013/1/18 pfelecan > Here is the last issue when generating TeXLive packages --- IMHO, there is > also something smelly in our infrastructure... quotas anyone? I used to hit my disk quota when working with GCC. I asked and was given more space. In this case, this is /var/tmp - I recently switched the temporary directory from /tmp to /var/tmp because packages are large. Which quota was exceeded in this case? Is it still per-user? Or is there quota specific to /var/tmp? Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From jh at opencsw.org Fri Jan 18 10:36:46 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Fri, 18 Jan 2013 10:36:46 +0100 Subject: [csw-maintainers] there is something rotten around checkpkg In-Reply-To: References: Message-ID: <50F917AE.1090608@opencsw.org> Hi, Am 18.01.13 10:25, schrieb Maciej (Matchek) Blizi?ski: > In this case, this is /var/tmp - I recently switched the temporary > directory from /tmp to /var/tmp because packages are large. Which quota > was exceeded in this case? Is it still per-user? Or is there quota > specific to /var/tmp? This was the quota for the zone itself. I removed an old snapshot that was still on the zone and added 5 more GB. There are now 9 GB free again. This should help. We still should cleanup /var/tmp from time to time :) @Dago when you have the time please remove the other old snapshots. :) Greetings Jan From maciej at opencsw.org Fri Jan 18 15:46:40 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 18 Jan 2013 14:46:40 +0000 Subject: [csw-maintainers] Checkpkg database update and new checkpkg tests In-Reply-To: <50F05C14.5040704@opencsw.org> References: <50EE9456.4050608@opencsw.org> <50EF21E8.3040102@opencsw.org> <50F05C14.5040704@opencsw.org> Message-ID: Package metadata size stored in the database are now roughly 3 times bigger. The local cache in my home directory has now 2.3GB: maciej at login [login]:~/src/opencsw-gar/v2 > ls -lh *.db -rw-r--r-- 1 maciej csw 62K Jan 14 10:05 pkg.db -rw-r--r-- 1 maciej csw 3.0M Jan 18 02:03 pkgstats-deps.db -rw-r--r-- 1 maciej csw 2.3G Jan 18 02:03 pkgstats.db We're seeing other problems such as timeouts on the restful interface, out-of-memory errors and quota hits. We have to think if this is an acceptable performance on our buildfarm. There's a number of things that we can do to make things better, but since they all have to do with infrastructural changes, they have to be done carefully. I'm on vacations the next week, so I won't do any changes now or next week. The first realistic data I'm doing anything more involved is around the 9th of February, which is roughly 3 weeks from now. For now, let's talk about what options we have. - change from pickles to json as the mysql-side storage format (should speed up the restful interface, no more unpickling+jsonizing) - storing compressed json is also an option, but will require constant decoding, which can be slow on sparc. We'd have to do some measurements to see what's faster; are we I/O bound or processor bound. We could use a lightweight compression library such as snappy. http://code.google.com/p/snappy/ - split out the single blob with everything (per package) into more blobs per package (quite a bit of coding will be involved; requires the rest interface changes); smaller blobs will be easier to handle and we'll avoid retrieving data we don't want; the price we'll pay is more complexity in the code. I've been so far avoiding complexity as much as possible (contrary to what it might look like :-P ), and having one memory structure for all data (per package) allowed us to keep the code simple in a lot of places. - change the underlying storage, although this would be quite involved and the benefit is not certain; I read that using MySQL as a key-value store can work just fine. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sat Jan 19 18:49:15 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 19 Jan 2013 17:49:15 +0000 Subject: [csw-maintainers] Checkpkg database update and new checkpkg tests In-Reply-To: References: <50EE9456.4050608@opencsw.org> <50EF21E8.3040102@opencsw.org> <50F05C14.5040704@opencsw.org> Message-ID: As a temporary measure, I have disabled the full stats data structure dump on the SVR4 package detail page. http://buildfarm.opencsw.org/pkgdb/srv4/765da5685ed2070d9130781d97461587/ It used to be very helpful to look at it that way because you could see everything about the package, but the page got so slow that it wasn't practical to use it any more. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Sun Jan 20 00:11:36 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sun, 20 Jan 2013 00:11:36 +0100 Subject: [csw-maintainers] Checkpkg database update and new checkpkg tests In-Reply-To: References: <50EE9456.4050608@opencsw.org> <50EF21E8.3040102@opencsw.org> <50F05C14.5040704@opencsw.org> Message-ID: 2013/1/18 Maciej (Matchek) Blizi?ski > We're seeing other problems such as timeouts on the restful interface, > out-of-memory errors and quota hits. We have to think if this is an > acceptable performance on our buildfarm. There's a number of things that we > can do to make things better, but since they all have to do with > infrastructural changes, they have to be done carefully. > If the recent changes prevent people from working and can't be fixed quickly, I would say we should disable the new checks and remove the additionnal data from the database until we figure a way to properly solve the problems. Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Sun Jan 20 01:10:21 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sun, 20 Jan 2013 01:10:21 +0100 Subject: [csw-maintainers] Checkpkg database update and new checkpkg tests In-Reply-To: References: <50EE9456.4050608@opencsw.org> <50EF21E8.3040102@opencsw.org> <50F05C14.5040704@opencsw.org> Message-ID: 2013/1/19 Maciej (Matchek) Blizi?ski > As a temporary measure, I have disabled the full stats data structure dump > on the SVR4 package detail page. > > http://buildfarm.opencsw.org/pkgdb/srv4/765da5685ed2070d9130781d97461587/ > I checked this one and most of the time was lost in the pprint.pformat method. It has a hard time working on the large data object. Yann > > > It used to be very helpful to look at it that way because you could see > everything about the package, but the page got so slow that it wasn't > practical to use it any more. > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sun Jan 20 01:15:27 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 20 Jan 2013 00:15:27 +0000 Subject: [csw-maintainers] Checkpkg database update and new checkpkg tests In-Reply-To: References: <50EE9456.4050608@opencsw.org> <50EF21E8.3040102@opencsw.org> <50F05C14.5040704@opencsw.org> Message-ID: 2013/1/19 Yann Rouillard > If the recent changes prevent people from working and can't be fixed quickly, I would say we should disable the new checks and remove the additionnal data from the database until we figure a way to properly solve the problems. We don't have any serious operational problems - ones that would prevent us from building packages - but there's enough degradation that we need to do something about it. For example, I want to be able to view all package metadata via the web interface at http://buildfarm.opencsw.org/pkgdb/. Maciej From maciej at opencsw.org Sun Jan 20 01:18:05 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 20 Jan 2013 00:18:05 +0000 Subject: [csw-maintainers] Checkpkg database update and new checkpkg tests In-Reply-To: References: <50EE9456.4050608@opencsw.org> <50EF21E8.3040102@opencsw.org> <50F05C14.5040704@opencsw.org> Message-ID: 2013/1/20 Yann Rouillard : > 2013/1/19 Maciej (Matchek) Blizi?ski >> >> As a temporary measure, I have disabled the full stats data structure dump >> on the SVR4 package detail page. >> >> http://buildfarm.opencsw.org/pkgdb/srv4/765da5685ed2070d9130781d97461587/ > > > I checked this one and most of the time was lost in the pprint.pformat > method. It has a hard time working on the large data object. Yes, this was a very easy way to render the whole data structure into text without any custom formatting code. Maybe custom formatting / templating would speed it up, but at the same time, I liked to see it raw, because pprint.pformat preserves any oddities with e.g. character encodings, which can be lost when rendering with a template. Maciej From yann at pleiades.fr.eu.org Sun Jan 20 01:43:53 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sun, 20 Jan 2013 01:43:53 +0100 Subject: [csw-maintainers] [Opencsw] Preserve smf state and configuration files when you rename a package In-Reply-To: <07B07F6F-07BA-49F4-BA7B-5E8690A436C3@opencsw.org> References: <07B07F6F-07BA-49F4-BA7B-5E8690A436C3@opencsw.org> Message-ID: 2013/1/15 Dagobert Michelsen > > What do you think about this issue ? Do you see a better way to solve > this problem ? > > Sounds reasonable. I could add > OPENCSW_OBSOLETES=CSW > in pkginfo which should then picked up in addition to the real package > name in cswinitsmf. > Sounds perfect to me. Is that something that you could do quickly ? Yann > > Best regards > > -- Dago > > -- > "You don't become great by trying to be great, you become great by wanting > to do something, > and then doing it so hard that you become great in the process." - xkcd > #896 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sun Jan 20 10:10:33 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 20 Jan 2013 09:10:33 +0000 Subject: [csw-maintainers] there is something rotten around checkpkg In-Reply-To: References: <390B872A-7A79-49DC-8E94-877A20D6929B@opencsw.org> Message-ID: No dia 16/01/2013 19:02, "Peter FELECAN" escreveu: > > "Maciej (Matchek) Blizi?ski" writes: > > > 2013/1/16 Dagobert Michelsen : > >> The new link symbol inspection is in place for some time now, maybe it has > >> some serious drawbacks on database access? > > > > Some packages produce metadata objects serializing to more than 32MB. > > The out of space error could be a memory leak which I have been > > fighting over the weekend, but did not manage to find the cause. In my > > case, I was trying to run a full catalog import. > > > > Peter, what operation is causing the out of space error? How much RAM > > does the machine have? > > The "out of space" issue happened when packaging the *huge* TeXLive > hundred packages on the Baltic Online build farm; I think that you know > better than me how much RAM unstable10s and its companions have. I'm > trying again but one cycle merge-package is long: I start the process in > the morning and have the results the other day. You can see the log of > the action in progress in ~pfelecan/logs/texlive Maybe Yann can look at the logs and figure out what was the immediate problem. The main issue is that we art collecting way more date than previously, and that puts more pressure on the database. Do you think they the problem you had I'd transient? If it's persistent, we can back out the changes and stop collecting the additional data. I would prefer to gradually solve the performance problems without having to roll back, but if people can't build packages, we will have to. I did rebuild GCC with the new code and GCC is a pretty hefty build. But maybe TeX live is so large that it pushes the system off the cliff, while GCC is still small enough. Yann, maybe we can selectively disable the ldd and elfdump data collection for packages that wish to have these checks disabled? The checking code would need to allow for missing ldd and elfdump data. Since all that checkpkg sees is the package file, there would have to be a specific bit of information in the package itself that would instruct checkpkg to skip ldd end elfdump. It could be in pkginfo for example. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sun Jan 20 10:10:55 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 20 Jan 2013 09:10:55 +0000 Subject: [csw-maintainers] bad-rpath problem In-Reply-To: References: Message-ID: To expand a bit more, I think I did try to debug this but the NSS build system is weird and unlike most build systems, and so I didn't find a good way to fix it. If I tried, I'd probably start refactoring it and I didn't want to go there. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfelecan at opencsw.org Sun Jan 20 18:56:07 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 20 Jan 2013 18:56:07 +0100 Subject: [csw-maintainers] there is something rotten around checkpkg In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sun, 20 Jan 2013 09:10:33 +0000") References: <390B872A-7A79-49DC-8E94-877A20D6929B@opencsw.org> Message-ID: "Maciej (Matchek) Blizi?ski" writes: > No dia 16/01/2013 19:02, "Peter FELECAN" escreveu: >> >> "Maciej (Matchek) Blizi?ski" writes: >> >> > 2013/1/16 Dagobert Michelsen : >> >> The new link symbol inspection is in place for some time now, maybe it > has >> >> some serious drawbacks on database access? >> > >> > Some packages produce metadata objects serializing to more than 32MB. >> > The out of space error could be a memory leak which I have been >> > fighting over the weekend, but did not manage to find the cause. In my >> > case, I was trying to run a full catalog import. >> > >> > Peter, what operation is causing the out of space error? How much RAM >> > does the machine have? >> >> The "out of space" issue happened when packaging the *huge* TeXLive >> hundred packages on the Baltic Online build farm; I think that you know >> better than me how much RAM unstable10s and its companions have. I'm >> trying again but one cycle merge-package is long: I start the process in >> the morning and have the results the other day. You can see the log of >> the action in progress in ~pfelecan/logs/texlive > > Maybe Yann can look at the logs and figure out what was the immediate > problem. The main issue is that we art collecting way more date than > previously, and that puts more pressure on the database. Do you think they > the problem you had I'd transient? If it's persistent, we can back out the > changes and stop collecting the additional data. I would prefer to > gradually solve the performance problems without having to roll back, but > if people can't build packages, we will have to. Th issue is not transient as I repeated 3 times the operation. However, having a more important disk quota will delay it. > I did rebuild GCC with the new code and GCC is a pretty hefty build. But > maybe TeX live is so large that it pushes the system off the cliff, while > GCC is still small enough. The difference is in the number of files and, among them, the number of binary executable files which are all candidates for the new checks. > Yann, maybe we can selectively disable the ldd and elfdump data collection > for packages that wish to have these checks disabled? The checking code > would need to allow for missing ldd and elfdump data. Since all that > checkpkg sees is the package file, there would have to be a specific bit of > information in the package itself that would instruct checkpkg to skip ldd > end elfdump. It could be in pkginfo for example. This is an interesting option but I suggest to make it temporary, i.e., until solving the issue. How do you think to set this option, obviously in the recipe. -- Peter From maciej at opencsw.org Sun Jan 20 19:50:05 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 20 Jan 2013 18:50:05 +0000 Subject: [csw-maintainers] there is something rotten around checkpkg In-Reply-To: References: <390B872A-7A79-49DC-8E94-877A20D6929B@opencsw.org> Message-ID: Large number of binaries can probably kill the data collection and storage quite easily because the amount of data per binary is large. I'm starting to think that keeping all elfdump output in one file / one blob might be unworkable in the long run. We might need to keep symbols info from each binary in a separate blob. Unfortunately, this would contribute to code complexity. The hint to skip elfdump and ldd would be in the recipe, yes. Then it would be represented in the package itself, for example in pkginfo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Sun Jan 20 23:04:05 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sun, 20 Jan 2013 23:04:05 +0100 Subject: [csw-maintainers] there is something rotten around checkpkg In-Reply-To: References: <390B872A-7A79-49DC-8E94-877A20D6929B@opencsw.org> Message-ID: Hi Peter, > Maybe Yann can look at the logs and figure out what was the immediate > > problem. The main issue is that we art collecting way more date than > > previously, and that puts more pressure on the database. Do you think > they > > the problem you had I'd transient? If it's persistent, we can back out > the > > changes and stop collecting the additional data. I would prefer to > > gradually solve the performance problems without having to roll back, but > > if people can't build packages, we will have to. > > Th issue is not transient as I repeated 3 times the operation. However, > having a more important disk quota will delay it. > > I will definitely have a look at the log. I don't understand yet what is the real problem here and I need more information. The current log file still contains the gunzip error that seems related to disk space / quota issue. Now that Jan has made some space, could you run again the build so we could get past the gunzip error and see the real problem ? > > I did rebuild GCC with the new code and GCC is a pretty hefty build. But > > maybe TeX live is so large that it pushes the system off the cliff, while > > GCC is still small enough. > > The difference is in the number of files and, among them, the number of > binary executable files which are all candidates for the new checks. > > > Yann, maybe we can selectively disable the ldd and elfdump data > collection > > for packages that wish to have these checks disabled? The checking code > > would need to allow for missing ldd and elfdump data. Since all that > > checkpkg sees is the package file, there would have to be a specific bit > of > > information in the package itself that would instruct checkpkg to skip > ldd > > end elfdump. It could be in pkginfo for example. > > This is an interesting option but I suggest to make it temporary, i.e., > until solving the issue. How do you think to set this option, obviously > in the recipe. > Don't worry it will temporary, but I would first to investigate a bit further before doing this. Yann > -- > Peter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfelecan at opencsw.org Mon Jan 21 09:11:21 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 21 Jan 2013 09:11:21 +0100 Subject: [csw-maintainers] there is something rotten around checkpkg In-Reply-To: (Yann Rouillard's message of "Sun, 20 Jan 2013 23:04:05 +0100") References: <390B872A-7A79-49DC-8E94-877A20D6929B@opencsw.org> Message-ID: Yann Rouillard writes: > > Maybe Yann can look at the logs and figure out what was the immediate >> > problem. The main issue is that we art collecting way more date than >> > previously, and that puts more pressure on the database. Do you think >> they >> > the problem you had I'd transient? If it's persistent, we can back out >> the >> > changes and stop collecting the additional data. I would prefer to >> > gradually solve the performance problems without having to roll back, but >> > if people can't build packages, we will have to. >> >> Th issue is not transient as I repeated 3 times the operation. However, >> having a more important disk quota will delay it. >> >> > I will definitely have a look at the log. I don't understand yet what is > the real problem here and I need more information. > The current log file still contains the gunzip error that seems related to > disk space / quota issue. > > Now that Jan has made some space, could you run again the build so we could > get past the gunzip error and see the real problem ? I'm starting a new packaging. When is finished I'll notify it here. -- Peter From dam at opencsw.org Mon Jan 21 17:22:52 2013 From: dam at opencsw.org (dam) Date: Mon, 21 Jan 2013 17:22:52 +0100 Subject: [csw-maintainers] Problems with symbol detection Message-ID: Hi folks, I get the following error during checkpkg-time, Yann would you mind having a look? ## Packaging one part. /home/dam/spool.5.9-sparc/CSWdi/pkgmap /home/dam/spool.5.9-sparc/CSWdi/pkginfo /home/dam/spool.5.9-sparc/CSWdi/root/opt/csw/bin/di /home/dam/spool.5.9-sparc/CSWdi/root/opt/csw/share/doc/di/license /home/dam/spool.5.9-sparc/CSWdi/root/opt/csw/share/locale/de/LC_MESSAGES/di.mo /home/dam/spool.5.9-sparc/CSWdi/root/opt/csw/share/locale/en/LC_MESSAGES/di.mo /home/dam/spool.5.9-sparc/CSWdi/root/opt/csw/share/locale/es/LC_MESSAGES/di.mo /home/dam/spool.5.9-sparc/CSWdi/root/opt/csw/share/man/man1/di.1 /home/dam/spool.5.9-sparc/CSWdi/install/copyright /home/dam/spool.5.9-sparc/CSWdi/install/depend ## Validating control scripts. ## Packaging complete. mkp: exec( pkgtrans -s /home/dam/spool.5.9-sparc /tmp/di-4.34,REV=2013.01.21-SunOS5.9-sparc-CSW.pkg CSWdi ) Transferring package instance mkp: exec( pigz -9 -f /tmp/di-4.34,REV=2013.01.21-SunOS5.9-sparc-CSW.pkg ) mkp: exec( mv /tmp/di-4.34,REV=2013.01.21-SunOS5.9-sparc-CSW.pkg.gz /home/dam/staging/build-21.Jan.2013 ) mkp: exec( rm -rf /home/dam/spool.5.9-sparc/CSWdi ) INFO:root:Juicing the svr4 package stream files... elfdump out: | Version Needed Section: .SUNW_version file version libnsl.so.1 SUNW_1.6 libc.so.1 SUNW_1.18 SUNWprivate_1.1 Symbol Table Section: .dynsym index value size type bind oth ver shndx name [0] 0x00000000 0x00000000 NOTY LOCL D 0 UNDEF [1] 0x00029d64 0x00000000 FUNC GLOB D 0 UNDEF strncmp [2] 0x00029e18 0x00000000 FUNC GLOB D 0 UNDEF __umul64 [3] 0x00029cec 0x00000000 FUNC GLOB D 0 UNDEF atexit [4] 0x00029d34 0x00000000 FUNC GLOB D 0 UNDEF free [5] 0x00029e0c 0x00000000 FUNC GLOB D 0 UNDEF memset [6] 0x00029d7c 0x00000000 FUNC GLOB D 0 UNDEF perror [7] 0x0002a120 0x00000004 OBJT GLOB D 0 .data _environ [8] 0x00029f98 0x00000000 FUNC GLOB D 0 UNDEF mbrlen [9] 0x0002acc0 0x00000209 OBJT WEAK D 0 .bss _ctype [10] 0x000186f4 0x0000000c FUNC GLOB D 0 .fini _fini [11] 0x000134f0 0x00000088 FUNC GLOB D 0 .text di_isLoopbackFs [12] 0x0001332c 0x00000024 FUNC GLOB D 0 .text di_saveInodeSizes [13] 0x00029fbc 0x00000000 FUNC GLOB D 0 UNDEF atof [14] 0x00011858 0x00000000 FUNC GLOB D 0 .text .ld_llong [15] 0x00029fa4 0x00000000 FUNC GLOB D 0 UNDEF atoi [16] 0x00011a0c 0x00000000 FUNC GLOB D 0 .text .st_llong [17] 0x00029d4c 0x00000000 FUNC GLOB D 0 UNDEF stat64 [18] 0x00011c30 0x0000024c FUNC GLOB D 0 .text main [19] 0x00029ffc 0x00000000 OBJT GLOB D 0 .dynamic _DYNAMIC [20] 0x00029f5c 0x00000000 FUNC GLOB D 0 UNDEF _Q_div [21] 0x00029fb0 0x00000000 FUNC GLOB D 0 UNDEF atol [22] 0x00029e00 0x00000000 FUNC GLOB D 0 UNDEF strspn [23] 0x00029e78 0x00000000 FUNC GLOB D 0 UNDEF hasmntopt [24] 0x0002a12c 0x00000004 OBJT GLOB D 0 .data ___Argv [25] 0x00029de8 0x00000000 FUNC GLOB D 0 UNDEF libintl_textdomain [26] 0x00018700 0x00000004 OBJT GLOB D 0 .rodata _lib_version [27] 0x00029f50 0x00000000 FUNC GLOB D 0 UNDEF _Q_ulltoq [28] 0x0002ab58 0x00000000 OBJT GLOB D 0 .data1 _edata [29] 0x00029e60 0x00000000 FUNC GLOB D 0 UNDEF getmntent [30] 0x0002aed4 0x00000000 OBJT GLOB D 0 .bss _end [31] 0x00013430 0x00000048 FUNC GLOB D 0 .text di_testRemoteDisk [32] 0x00029f44 0x00000000 FUNC GLOB D 0 UNDEF snprintf [33] 0x0002a108 0x00000018 OBJT GLOB D 0 .data __environ_lock [34] 0x0002acc0 0x00000209 OBJT GLOB D 0 .bss __ctype [35] 0x00029efc 0x00000000 FUNC GLOB D 0 UNDEF authsys_create_default [36] 0x00013298 0x00000030 FUNC GLOB D 0 .text di_initDiskInfo [37] 0x00029d58 0x00000000 FUNC GLOB D 0 UNDEF fstat64 [38] 0x00014520 0x00000844 FUNC GLOB D 0 .text printDiskInfo [39] 0x00014d74 0x000001b4 FUNC GLOB D 0 .text sortArray [40] 0x00029d70 0x00000000 FUNC GLOB D 0 UNDEF fprintf [41] 0x0002a128 0x00000004 OBJT GLOB D 0 .data __cg92_used [42] 0x00029e9c 0x00000000 FUNC GLOB D 0 UNDEF ioctl [43] 0x0002a120 0x00000004 OBJT WEAK D 0 .data environ [44] 0x00029dac 0x00000000 FUNC GLOB D 0 UNDEF getegid [45] 0x000186e4 0x00000010 FUNC GLOB D 0 .init _init [46] 0x0002aed0 0x00000004 OBJT GLOB D 0 .bss __xargc [47] 0x0002ab78 0x00000140 OBJT GLOB D 0 .bss __iob [48] 0x00011a7c 0x00000000 FUNC GLOB D 0 .text .st_float [49] 0x0002ab78 0x00000140 OBJT WEAK D 0 .bss _iob [50] 0x00011b6c 0x00000000 FUNC GLOB D 0 .text .st_float_foreff [51] 0x00013578 0x00000064 FUNC GLOB D 0 .text di_mungePoolName [52] 0x00013478 0x00000078 FUNC GLOB D 0 .text di_isPooledFs [53] 0x000118ec 0x00000000 FUNC GLOB D 0 .text .ld_float [54] 0x00029ddc 0x00000000 FUNC GLOB D 0 UNDEF libintl_bindtextdomain [55] 0x00029ea8 0x00000000 FUNC GLOB D 0 UNDEF close [56] 0x00029f38 0x00000000 FUNC GLOB D 0 UNDEF _Q_fle [57] 0x00029fe0 0x00000000 FUNC GLOB D 0 UNDEF realloc [58] 0x00029fec 0x00000000 FUNC WEAK D 0 UNDEF _get_exit_frame_monitor [59] 0x000186a8 0x0000003c FUNC GLOB D 0 .text trimChar [60] 0x00013378 0x00000008 FUNC GLOB D 0 .text convertNFSMountOptions [61] 0x0002acb8 0x00000004 OBJT GLOB D 0 .bss errno [62] 0x00017098 0x00000238 FUNC GLOB D 0 .text getoptn [63] 0x00029d88 0x00000000 FUNC GLOB D 0 UNDEF lstat64 [64] 0x00029d04 0x00000000 FUNC GLOB D 0 UNDEF _exit [65] 0x00029ecc 0x00000000 FUNC GLOB D 0 UNDEF xdr_int [66] 0x00029cf8 0x00000000 FUNC GLOB D 0 UNDEF exit [67] 0x00029f80 0x00000000 FUNC GLOB D 0 UNDEF _Q_flt [68] 0x00029db8 0x00000000 FUNC GLOB D 0 UNDEF strcmp [69] 0x00029e24 0x00000000 FUNC GLOB D 0 UNDEF strdup [70] 0x00029e90 0x00000000 FUNC GLOB D 0 UNDEF strncat [71] 0x000116f0 0x00000120 FUNC GLOB D 0 .text _start [72] 0x00011ba4 0x00000000 FUNC GLOB D 0 .text .st_double_foreff [73] 0x00000000 0x00000000 NOTY WEAK D 0 UNDEF __1cG__CrunMdo_exit_code6F_v_ [74] 0x00029f08 0x00000000 FUNC GLOB D 0 UNDEF libintl_gettext [75] 0x00018684 0x00000024 FUNC GLOB D 0 .text _realloc [76] 0x00029da0 0x00000000 FUNC GLOB D 0 UNDEF geteuid [77] 0x00029e84 0x00000000 FUNC GLOB D 0 UNDEF statvfs64 [78] 0x00029cbc 0x00000000 OBJT GLOB D 0 .plt _PROCEDURE_LINKAGE_TABLE_ [79] 0x00013a80 0x000000bc FUNC GLOB D 0 .text diquota [80] 0x00029f14 0x00000000 FUNC GLOB D 0 UNDEF _Q_feq [81] 0x00013380 0x000000b0 FUNC GLOB D 0 .text chkMountOptions [82] 0x00029f20 0x00000000 FUNC GLOB D 0 UNDEF _Q_fne [83] 0x00029df4 0x00000000 FUNC GLOB D 0 UNDEF strlen [84] 0x00011ad0 0x00000000 FUNC GLOB D 0 .text .st_double [85] 0x00029d28 0x00000000 FUNC GLOB D 0 UNDEF printf [86] 0x00029e3c 0x00000000 FUNC GLOB D 0 UNDEF strstr [87] 0x00029fc8 0x00000000 FUNC GLOB D 0 UNDEF malloc [88] 0x00029f68 0x00000000 FUNC GLOB D 0 UNDEF _Q_mul [89] 0x00029ed8 0x00000000 FUNC GLOB D 0 UNDEF xdr_bool [90] 0x00029ef0 0x00000000 FUNC GLOB D 0 UNDEF clnt_create [91] 0x00029dd0 0x00000000 FUNC GLOB D 0 UNDEF getenv [92] 0x0002a138 0x00000004 OBJT GLOB D 0 .data debug [93] 0x00029d1c 0x00000000 FUNC GLOB D 0 UNDEF strncpy [94] 0x00029ee4 0x00000000 FUNC GLOB D 0 UNDEF xdr_uint32_t [95] 0x00029f74 0x00000000 FUNC GLOB D 0 UNDEF _Q_fge [96] 0x00029fd4 0x00000000 FUNC GLOB D 0 UNDEF memcmp [97] 0x00011938 0x00000000 FUNC GLOB D 0 .text .ld_double [98] 0x00029e6c 0x00000000 FUNC GLOB D 0 UNDEF fclose [99] 0x00029f8c 0x00000000 FUNC GLOB D 0 UNDEF strcoll [100] 0x00029ec0 0x00000000 FUNC GLOB D 0 UNDEF xdr_int32_t [101] 0x00029d40 0x00000000 FUNC GLOB D 0 UNDEF open64 [102] 0x00014f38 0x000000a0 FUNC GLOB D 0 .text getPrintFlagText [103] 0x00029f2c 0x00000000 FUNC GLOB D 0 UNDEF _Q_fgt [104] 0x00000000 0x00000000 NOTY GLOB D 0 ABS __fsr_init_value [105] 0x000173b8 0x000001c0 FUNC GLOB D 0 .text getDIOptions [106] 0x00029d94 0x00000000 FUNC GLOB D 0 UNDEF realpath [107] 0x000132c8 0x00000064 FUNC GLOB D 0 .text di_saveBlockSizes [108] 0x00029e48 0x00000000 FUNC GLOB D 0 UNDEF strchr [109] 0x00029d10 0x00000000 FUNC GLOB D 0 UNDEF _Q_dtoq [110] 0x00019cb8 0x00000000 OBJT GLOB D 0 .rodata1 _etext [111] 0x00029dc4 0x00000000 FUNC GLOB D 0 UNDEF setlocale [112] 0x00011810 0x00000000 FUNC GLOB D 0 .text .ld_int [113] 0x00029eb4 0x00000000 FUNC GLOB D 0 UNDEF xdr_string [114] 0x000135dc 0x00000200 FUNC GLOB D 0 .text di_getDiskEntries [115] 0x000119d4 0x00000000 FUNC GLOB D 0 .text .st_int [116] 0x000137f8 0x000001e8 FUNC GLOB D 0 .text di_getDiskInfo [117] 0x0002aecc 0x00000004 OBJT GLOB D 0 .bss __xargv [118] 0x00013360 0x00000008 FUNC GLOB D 0 .text convertMountOptions [119] 0x00029cb8 0x00000000 OBJT GLOB D 0 .got _GLOBAL_OFFSET_TABLE_ [120] 0x00029e30 0x00000000 FUNC GLOB D 0 UNDEF strtok [121] 0x00029e54 0x00000000 FUNC GLOB D 0 UNDEF fopen64 Syminfo Section: .SUNW_syminfo index flgs bound to symbol [1] DBL [5] libc.so.1 strncmp [2] DBL [5] libc.so.1 __umul64 [3] DBL [5] libc.so.1 atexit [4] DBL [5] libc.so.1 free [5] DBL [5] libc.so.1 memset [6] DBL [5] libc.so.1 perror [7] DB _environ [8] DBL [5] libc.so.1 mbrlen [9] DBC [5] libc.so.1 _ctype [10] DB _fini [11] DB di_isLoopbackFs [12] DB di_saveInodeSizes [13] DBL [5] libc.so.1 atof [14] DB .ld_llong [15] DBL [5] libc.so.1 atoi [16] DB .st_llong [17] DBL [5] libc.so.1 stat64 [18] DB main [19] N _DYNAMIC [20] DBL [5] libc.so.1 _Q_div [21] DBL [5] libc.so.1 atol [22] DBL [5] libc.so.1 strspn [23] DBL [5] libc.so.1 hasmntopt [24] DB ___Argv [25] DBL [1] libintl.so.8 libintl_textdomain [26] DB _lib_version [27] DBL [5] libc.so.1 _Q_ulltoq [28] N _edata [29] DBL [5] libc.so.1 getmntent [30] N _end [31] DB di_testRemoteDisk [32] DBL [5] libc.so.1 snprintf [33] DB __environ_lock [34] DBC [5] libc.so.1 __ctype [35] DBL [3] libnsl.so.1 authsys_create_default [36] DB di_initDiskInfo [37] DBL [5] libc.so.1 fstat64 [38] DB printDiskInfo [39] DB sortArray [40] DBL [5] libc.so.1 fprintf [41] DB __cg92_used [42] DBL [5] libc.so.1 ioctl [43] DB environ [44] DBL [5] libc.so.1 getegid [45] DB _init [46] DB __xargc [47] DBC [5] libc.so.1 __iob [48] DB .st_float [49] DBC [5] libc.so.1 _iob [50] DB .st_float_foreff [51] DB di_mungePoolName [52] DB di_isPooledFs [53] DB .ld_float [54] DBL [1] libintl.so.8 libintl_bindtextdomain [55] DBL [5] libc.so.1 close [56] DBL [5] libc.so.1 _Q_fle [57] DBL [5] libc.so.1 realloc [58] DBL [5] libc.so.1 _get_exit_frame_monitor [59] DB trimChar [60] DB convertNFSMountOptions [61] DBC [5] libc.so.1 errno [62] DB getoptn [63] DBL [5] libc.so.1 lstat64 [64] DBL [5] libc.so.1 _exit [65] DBL [3] libnsl.so.1 xdr_int [66] DBL [5] libc.so.1 exit [67] DBL [5] libc.so.1 _Q_flt [68] DBL [5] libc.so.1 strcmp [69] DBL [5] libc.so.1 strdup [70] DBL [5] libc.so.1 strncat [71] DB _start [72] DB .st_double_foreff [74] DBL [1] libintl.so.8 libintl_gettext [75] DB _realloc [76] DBL [5] libc.so.1 geteuid [77] DBL [5] libc.so.1 statvfs64 [78] N _PROCEDURE_LINKAGE_TABLE_ [79] DB diquota [80] DBL [5] libc.so.1 _Q_feq [81] DB chkMountOptions [82] DBL [5] libc.so.1 _Q_fne [83] DBL [5] libc.so.1 strlen [84] DB .st_double [85] DBL [5] libc.so.1 printf [86] DBL [5] libc.so.1 strstr [87] DBL [5] libc.so.1 malloc [88] DBL [5] libc.so.1 _Q_mul [89] DBL [3] libnsl.so.1 xdr_bool [90] DBL [3] libnsl.so.1 clnt_create [91] DBL [5] libc.so.1 getenv [92] DB debug [93] DBL [5] libc.so.1 strncpy [94] DBL [3] libnsl.so.1 xdr_uint32_t [95] DBL [5] libc.so.1 _Q_fge [96] DBL [5] libc.so.1 memcmp [97] DB .ld_double [98] DBL [5] libc.so.1 fclose [99] DBL [5] libc.so.1 strcoll [100] DBL [3] libnsl.so.1 xdr_int32_t [101] DBL [5] libc.so.1 open64 [102] DB getPrintFlagText [103] DBL [5] libc.so.1 _Q_fgt [104] DB __fsr_init_value [105] DB getDIOptions [106] DBL [5] libc.so.1 realpath [107] DB di_saveBlockSizes [108] DBL [5] libc.so.1 strchr [109] DBL [5] libc.so.1 _Q_dtoq [110] N _etext [111] DBL [5] libc.so.1 setlocale [112] DB .ld_int [113] DBL [3] libnsl.so.1 xdr_string [114] DB di_getDiskEntries [115] DB .st_int [116] DB di_getDiskInfo [117] DB __xargv [118] DB convertMountOptions [119] N _GLOBAL_OFFSET_TABLE_ [120] DBL [5] libc.so.1 strtok [121] DBL [5] libc.so.1 fopen64 Traceback (most recent call last): File "/home/dam/mgar/pkg/.buildsys/v2/gar/gar//bin/checkpkg", line 197, in main() File "/home/dam/mgar/pkg/.buildsys/v2/gar/gar//bin/checkpkg", line 120, in main stats_list = collector.CollectStatsFromFiles(file_list, None) File "/home/dam/mgar/pkg/.buildsys/v2/lib/python/package_stats.py", line 499, in CollectStatsFromFiles stats.CollectStats(force=force_unpack) File "/home/dam/mgar/pkg/.buildsys/v2/lib/python/package_stats.py", line 175, in CollectStats return self._CollectStats(register_files=register_files) File "/home/dam/mgar/pkg/.buildsys/v2/lib/python/package_stats.py", line 212, in _CollectStats "binaries_elf_info": dir_pkg.GetBinaryElfInfo(), File "/home/dam/mgar/pkg/.buildsys/v2/lib/python/inspective_package.py", line 297, in GetBinaryElfInfo elf_info, cur_section = self._ParseElfdumpLine(line, cur_section) File "/home/dam/mgar/pkg/.buildsys/v2/lib/python/inspective_package.py", line 505, in _ParseElfdumpLine raise package.StdoutSyntaxError("Could not parse %s" % (repr(line))) package.StdoutSyntaxError: Could not parse ' index flgs bound to symbol' gmake: *** [pkgcheck] Error 2 gmake: Leaving directory `/home/dam/mgar/pkg/di/trunk' Connection to unstable9s closed. gmake: *** [platforms-repackage] Error 2 zsh: 19143 exit 2 mgar platforms-repackage Best regards -- Dago From dam at opencsw.org Mon Jan 21 17:34:09 2013 From: dam at opencsw.org (dam) Date: Mon, 21 Jan 2013 17:34:09 +0100 Subject: [csw-maintainers] Problems with symbol detection In-Reply-To: References: Message-ID: <0a0c27102d23cd3571c48261a54583b7@opencsw.org> Am 2013-01-21 17:22, schrieb dam: > Hi folks, > > I get the following error during checkpkg-time, Yann would you mind > having a look? > > > ## Packaging one part. > /home/dam/spool.5.9-sparc/CSWdi/pkgmap > /home/dam/spool.5.9-sparc/CSWdi/pkginfo > /home/dam/spool.5.9-sparc/CSWdi/root/opt/csw/bin/di > /home/dam/spool.5.9-sparc/CSWdi/root/opt/csw/share/doc/di/license > > /home/dam/spool.5.9-sparc/CSWdi/root/opt/csw/share/locale/de/LC_MESSAGES/di.mo > > /home/dam/spool.5.9-sparc/CSWdi/root/opt/csw/share/locale/en/LC_MESSAGES/di.mo > > /home/dam/spool.5.9-sparc/CSWdi/root/opt/csw/share/locale/es/LC_MESSAGES/di.mo > /home/dam/spool.5.9-sparc/CSWdi/root/opt/csw/share/man/man1/di.1 > /home/dam/spool.5.9-sparc/CSWdi/install/copyright > /home/dam/spool.5.9-sparc/CSWdi/install/depend > ## Validating control scripts. > ## Packaging complete. > mkp: exec( pkgtrans -s /home/dam/spool.5.9-sparc > /tmp/di-4.34,REV=2013.01.21-SunOS5.9-sparc-CSW.pkg CSWdi ) > Transferring package instance > mkp: exec( pigz -9 -f > /tmp/di-4.34,REV=2013.01.21-SunOS5.9-sparc-CSW.pkg ) > mkp: exec( mv /tmp/di-4.34,REV=2013.01.21-SunOS5.9-sparc-CSW.pkg.gz > /home/dam/staging/build-21.Jan.2013 ) > mkp: exec( rm -rf /home/dam/spool.5.9-sparc/CSWdi ) > INFO:root:Juicing the svr4 package stream files... > elfdump out: > | > > Version Needed Section: .SUNW_version > file version > libnsl.so.1 SUNW_1.6 > libc.so.1 SUNW_1.18 > SUNWprivate_1.1 > > Symbol Table Section: .dynsym > index value size type bind oth ver shndx name > [0] 0x00000000 0x00000000 NOTY LOCL D 0 UNDEF > [1] 0x00029d64 0x00000000 FUNC GLOB D 0 UNDEF > strncmp > [2] 0x00029e18 0x00000000 FUNC GLOB D 0 UNDEF > __umul64 > [3] 0x00029cec 0x00000000 FUNC GLOB D 0 UNDEF > atexit > [4] 0x00029d34 0x00000000 FUNC GLOB D 0 UNDEF free > [5] 0x00029e0c 0x00000000 FUNC GLOB D 0 UNDEF > memset > [6] 0x00029d7c 0x00000000 FUNC GLOB D 0 UNDEF > perror > [7] 0x0002a120 0x00000004 OBJT GLOB D 0 .data > _environ > [8] 0x00029f98 0x00000000 FUNC GLOB D 0 UNDEF > mbrlen > [9] 0x0002acc0 0x00000209 OBJT WEAK D 0 .bss > _ctype > [10] 0x000186f4 0x0000000c FUNC GLOB D 0 .fini > _fini > [11] 0x000134f0 0x00000088 FUNC GLOB D 0 .text > di_isLoopbackFs > [12] 0x0001332c 0x00000024 FUNC GLOB D 0 .text > di_saveInodeSizes > [13] 0x00029fbc 0x00000000 FUNC GLOB D 0 UNDEF atof > [14] 0x00011858 0x00000000 FUNC GLOB D 0 .text > .ld_llong > [15] 0x00029fa4 0x00000000 FUNC GLOB D 0 UNDEF atoi > [16] 0x00011a0c 0x00000000 FUNC GLOB D 0 .text > .st_llong > [17] 0x00029d4c 0x00000000 FUNC GLOB D 0 UNDEF > stat64 > [18] 0x00011c30 0x0000024c FUNC GLOB D 0 .text main > [19] 0x00029ffc 0x00000000 OBJT GLOB D 0 .dynamic > _DYNAMIC > [20] 0x00029f5c 0x00000000 FUNC GLOB D 0 UNDEF > _Q_div > [21] 0x00029fb0 0x00000000 FUNC GLOB D 0 UNDEF atol > [22] 0x00029e00 0x00000000 FUNC GLOB D 0 UNDEF > strspn > [23] 0x00029e78 0x00000000 FUNC GLOB D 0 UNDEF > hasmntopt > [24] 0x0002a12c 0x00000004 OBJT GLOB D 0 .data > ___Argv > [25] 0x00029de8 0x00000000 FUNC GLOB D 0 UNDEF > libintl_textdomain > [26] 0x00018700 0x00000004 OBJT GLOB D 0 .rodata > _lib_version > [27] 0x00029f50 0x00000000 FUNC GLOB D 0 UNDEF > _Q_ulltoq > [28] 0x0002ab58 0x00000000 OBJT GLOB D 0 .data1 > _edata > [29] 0x00029e60 0x00000000 FUNC GLOB D 0 UNDEF > getmntent > [30] 0x0002aed4 0x00000000 OBJT GLOB D 0 .bss _end > [31] 0x00013430 0x00000048 FUNC GLOB D 0 .text > di_testRemoteDisk > [32] 0x00029f44 0x00000000 FUNC GLOB D 0 UNDEF > snprintf > [33] 0x0002a108 0x00000018 OBJT GLOB D 0 .data > __environ_lock > [34] 0x0002acc0 0x00000209 OBJT GLOB D 0 .bss > __ctype > [35] 0x00029efc 0x00000000 FUNC GLOB D 0 UNDEF > authsys_create_default > [36] 0x00013298 0x00000030 FUNC GLOB D 0 .text > di_initDiskInfo > [37] 0x00029d58 0x00000000 FUNC GLOB D 0 UNDEF > fstat64 > [38] 0x00014520 0x00000844 FUNC GLOB D 0 .text > printDiskInfo > [39] 0x00014d74 0x000001b4 FUNC GLOB D 0 .text > sortArray > [40] 0x00029d70 0x00000000 FUNC GLOB D 0 UNDEF > fprintf > [41] 0x0002a128 0x00000004 OBJT GLOB D 0 .data > __cg92_used > [42] 0x00029e9c 0x00000000 FUNC GLOB D 0 UNDEF > ioctl > [43] 0x0002a120 0x00000004 OBJT WEAK D 0 .data > environ > [44] 0x00029dac 0x00000000 FUNC GLOB D 0 UNDEF > getegid > [45] 0x000186e4 0x00000010 FUNC GLOB D 0 .init > _init > [46] 0x0002aed0 0x00000004 OBJT GLOB D 0 .bss > __xargc > [47] 0x0002ab78 0x00000140 OBJT GLOB D 0 .bss > __iob > [48] 0x00011a7c 0x00000000 FUNC GLOB D 0 .text > .st_float > [49] 0x0002ab78 0x00000140 OBJT WEAK D 0 .bss _iob > [50] 0x00011b6c 0x00000000 FUNC GLOB D 0 .text > .st_float_foreff > [51] 0x00013578 0x00000064 FUNC GLOB D 0 .text > di_mungePoolName > [52] 0x00013478 0x00000078 FUNC GLOB D 0 .text > di_isPooledFs > [53] 0x000118ec 0x00000000 FUNC GLOB D 0 .text > .ld_float > [54] 0x00029ddc 0x00000000 FUNC GLOB D 0 UNDEF > libintl_bindtextdomain > [55] 0x00029ea8 0x00000000 FUNC GLOB D 0 UNDEF > close > [56] 0x00029f38 0x00000000 FUNC GLOB D 0 UNDEF > _Q_fle > [57] 0x00029fe0 0x00000000 FUNC GLOB D 0 UNDEF > realloc > [58] 0x00029fec 0x00000000 FUNC WEAK D 0 UNDEF > _get_exit_frame_monitor > [59] 0x000186a8 0x0000003c FUNC GLOB D 0 .text > trimChar > [60] 0x00013378 0x00000008 FUNC GLOB D 0 .text > convertNFSMountOptions > [61] 0x0002acb8 0x00000004 OBJT GLOB D 0 .bss > errno > [62] 0x00017098 0x00000238 FUNC GLOB D 0 .text > getoptn > [63] 0x00029d88 0x00000000 FUNC GLOB D 0 UNDEF > lstat64 > [64] 0x00029d04 0x00000000 FUNC GLOB D 0 UNDEF > _exit > [65] 0x00029ecc 0x00000000 FUNC GLOB D 0 UNDEF > xdr_int > [66] 0x00029cf8 0x00000000 FUNC GLOB D 0 UNDEF exit > [67] 0x00029f80 0x00000000 FUNC GLOB D 0 UNDEF > _Q_flt > [68] 0x00029db8 0x00000000 FUNC GLOB D 0 UNDEF > strcmp > [69] 0x00029e24 0x00000000 FUNC GLOB D 0 UNDEF > strdup > [70] 0x00029e90 0x00000000 FUNC GLOB D 0 UNDEF > strncat > [71] 0x000116f0 0x00000120 FUNC GLOB D 0 .text > _start > [72] 0x00011ba4 0x00000000 FUNC GLOB D 0 .text > .st_double_foreff > [73] 0x00000000 0x00000000 NOTY WEAK D 0 UNDEF > __1cG__CrunMdo_exit_code6F_v_ > [74] 0x00029f08 0x00000000 FUNC GLOB D 0 UNDEF > libintl_gettext > [75] 0x00018684 0x00000024 FUNC GLOB D 0 .text > _realloc > [76] 0x00029da0 0x00000000 FUNC GLOB D 0 UNDEF > geteuid > [77] 0x00029e84 0x00000000 FUNC GLOB D 0 UNDEF > statvfs64 > [78] 0x00029cbc 0x00000000 OBJT GLOB D 0 .plt > _PROCEDURE_LINKAGE_TABLE_ > [79] 0x00013a80 0x000000bc FUNC GLOB D 0 .text > diquota > [80] 0x00029f14 0x00000000 FUNC GLOB D 0 UNDEF > _Q_feq > [81] 0x00013380 0x000000b0 FUNC GLOB D 0 .text > chkMountOptions > [82] 0x00029f20 0x00000000 FUNC GLOB D 0 UNDEF > _Q_fne > [83] 0x00029df4 0x00000000 FUNC GLOB D 0 UNDEF > strlen > [84] 0x00011ad0 0x00000000 FUNC GLOB D 0 .text > .st_double > [85] 0x00029d28 0x00000000 FUNC GLOB D 0 UNDEF > printf > [86] 0x00029e3c 0x00000000 FUNC GLOB D 0 UNDEF > strstr > [87] 0x00029fc8 0x00000000 FUNC GLOB D 0 UNDEF > malloc > [88] 0x00029f68 0x00000000 FUNC GLOB D 0 UNDEF > _Q_mul > [89] 0x00029ed8 0x00000000 FUNC GLOB D 0 UNDEF > xdr_bool > [90] 0x00029ef0 0x00000000 FUNC GLOB D 0 UNDEF > clnt_create > [91] 0x00029dd0 0x00000000 FUNC GLOB D 0 UNDEF > getenv > [92] 0x0002a138 0x00000004 OBJT GLOB D 0 .data > debug > [93] 0x00029d1c 0x00000000 FUNC GLOB D 0 UNDEF > strncpy > [94] 0x00029ee4 0x00000000 FUNC GLOB D 0 UNDEF > xdr_uint32_t > [95] 0x00029f74 0x00000000 FUNC GLOB D 0 UNDEF > _Q_fge > [96] 0x00029fd4 0x00000000 FUNC GLOB D 0 UNDEF > memcmp > [97] 0x00011938 0x00000000 FUNC GLOB D 0 .text > .ld_double > [98] 0x00029e6c 0x00000000 FUNC GLOB D 0 UNDEF > fclose > [99] 0x00029f8c 0x00000000 FUNC GLOB D 0 UNDEF > strcoll > [100] 0x00029ec0 0x00000000 FUNC GLOB D 0 UNDEF > xdr_int32_t > [101] 0x00029d40 0x00000000 FUNC GLOB D 0 UNDEF > open64 > [102] 0x00014f38 0x000000a0 FUNC GLOB D 0 .text > getPrintFlagText > [103] 0x00029f2c 0x00000000 FUNC GLOB D 0 UNDEF > _Q_fgt > [104] 0x00000000 0x00000000 NOTY GLOB D 0 ABS > __fsr_init_value > [105] 0x000173b8 0x000001c0 FUNC GLOB D 0 .text > getDIOptions > [106] 0x00029d94 0x00000000 FUNC GLOB D 0 UNDEF > realpath > [107] 0x000132c8 0x00000064 FUNC GLOB D 0 .text > di_saveBlockSizes > [108] 0x00029e48 0x00000000 FUNC GLOB D 0 UNDEF > strchr > [109] 0x00029d10 0x00000000 FUNC GLOB D 0 UNDEF > _Q_dtoq > [110] 0x00019cb8 0x00000000 OBJT GLOB D 0 .rodata1 > _etext > [111] 0x00029dc4 0x00000000 FUNC GLOB D 0 UNDEF > setlocale > [112] 0x00011810 0x00000000 FUNC GLOB D 0 .text > .ld_int > [113] 0x00029eb4 0x00000000 FUNC GLOB D 0 UNDEF > xdr_string > [114] 0x000135dc 0x00000200 FUNC GLOB D 0 .text > di_getDiskEntries > [115] 0x000119d4 0x00000000 FUNC GLOB D 0 .text > .st_int > [116] 0x000137f8 0x000001e8 FUNC GLOB D 0 .text > di_getDiskInfo > [117] 0x0002aecc 0x00000004 OBJT GLOB D 0 .bss > __xargv > [118] 0x00013360 0x00000008 FUNC GLOB D 0 .text > convertMountOptions > [119] 0x00029cb8 0x00000000 OBJT GLOB D 0 .got > _GLOBAL_OFFSET_TABLE_ > [120] 0x00029e30 0x00000000 FUNC GLOB D 0 UNDEF > strtok > [121] 0x00029e54 0x00000000 FUNC GLOB D 0 UNDEF > fopen64 > > Syminfo Section: .SUNW_syminfo > index flgs bound to symbol > [1] DBL [5] libc.so.1 strncmp > [2] DBL [5] libc.so.1 __umul64 > [3] DBL [5] libc.so.1 atexit > [4] DBL [5] libc.so.1 free > [5] DBL [5] libc.so.1 memset > [6] DBL [5] libc.so.1 perror > [7] DB _environ > [8] DBL [5] libc.so.1 mbrlen > [9] DBC [5] libc.so.1 _ctype > [10] DB _fini > [11] DB di_isLoopbackFs > [12] DB di_saveInodeSizes > [13] DBL [5] libc.so.1 atof > [14] DB .ld_llong > [15] DBL [5] libc.so.1 atoi > [16] DB .st_llong > [17] DBL [5] libc.so.1 stat64 > [18] DB main > [19] N _DYNAMIC > [20] DBL [5] libc.so.1 _Q_div > [21] DBL [5] libc.so.1 atol > [22] DBL [5] libc.so.1 strspn > [23] DBL [5] libc.so.1 hasmntopt > [24] DB ___Argv > [25] DBL [1] libintl.so.8 libintl_textdomain > [26] DB _lib_version > [27] DBL [5] libc.so.1 _Q_ulltoq > [28] N _edata > [29] DBL [5] libc.so.1 getmntent > [30] N _end > [31] DB di_testRemoteDisk > [32] DBL [5] libc.so.1 snprintf > [33] DB __environ_lock > [34] DBC [5] libc.so.1 __ctype > [35] DBL [3] libnsl.so.1 authsys_create_default > [36] DB di_initDiskInfo > [37] DBL [5] libc.so.1 fstat64 > [38] DB printDiskInfo > [39] DB sortArray > [40] DBL [5] libc.so.1 fprintf > [41] DB __cg92_used > [42] DBL [5] libc.so.1 ioctl > [43] DB environ > [44] DBL [5] libc.so.1 getegid > [45] DB _init > [46] DB __xargc > [47] DBC [5] libc.so.1 __iob > [48] DB .st_float > [49] DBC [5] libc.so.1 _iob > [50] DB .st_float_foreff > [51] DB di_mungePoolName > [52] DB di_isPooledFs > [53] DB .ld_float > [54] DBL [1] libintl.so.8 libintl_bindtextdomain > [55] DBL [5] libc.so.1 close > [56] DBL [5] libc.so.1 _Q_fle > [57] DBL [5] libc.so.1 realloc > [58] DBL [5] libc.so.1 _get_exit_frame_monitor > [59] DB trimChar > [60] DB convertNFSMountOptions > [61] DBC [5] libc.so.1 errno > [62] DB getoptn > [63] DBL [5] libc.so.1 lstat64 > [64] DBL [5] libc.so.1 _exit > [65] DBL [3] libnsl.so.1 xdr_int > [66] DBL [5] libc.so.1 exit > [67] DBL [5] libc.so.1 _Q_flt > [68] DBL [5] libc.so.1 strcmp > [69] DBL [5] libc.so.1 strdup > [70] DBL [5] libc.so.1 strncat > [71] DB _start > [72] DB .st_double_foreff > [74] DBL [1] libintl.so.8 libintl_gettext > [75] DB _realloc > [76] DBL [5] libc.so.1 geteuid > [77] DBL [5] libc.so.1 statvfs64 > [78] N _PROCEDURE_LINKAGE_TABLE_ > [79] DB diquota > [80] DBL [5] libc.so.1 _Q_feq > [81] DB chkMountOptions > [82] DBL [5] libc.so.1 _Q_fne > [83] DBL [5] libc.so.1 strlen > [84] DB .st_double > [85] DBL [5] libc.so.1 printf > [86] DBL [5] libc.so.1 strstr > [87] DBL [5] libc.so.1 malloc > [88] DBL [5] libc.so.1 _Q_mul > [89] DBL [3] libnsl.so.1 xdr_bool > [90] DBL [3] libnsl.so.1 clnt_create > [91] DBL [5] libc.so.1 getenv > [92] DB debug > [93] DBL [5] libc.so.1 strncpy > [94] DBL [3] libnsl.so.1 xdr_uint32_t > [95] DBL [5] libc.so.1 _Q_fge > [96] DBL [5] libc.so.1 memcmp > [97] DB .ld_double > [98] DBL [5] libc.so.1 fclose > [99] DBL [5] libc.so.1 strcoll > [100] DBL [3] libnsl.so.1 xdr_int32_t > [101] DBL [5] libc.so.1 open64 > [102] DB getPrintFlagText > [103] DBL [5] libc.so.1 _Q_fgt > [104] DB __fsr_init_value > [105] DB getDIOptions > [106] DBL [5] libc.so.1 realpath > [107] DB di_saveBlockSizes > [108] DBL [5] libc.so.1 strchr > [109] DBL [5] libc.so.1 _Q_dtoq > [110] N _etext > [111] DBL [5] libc.so.1 setlocale > [112] DB .ld_int > [113] DBL [3] libnsl.so.1 xdr_string > [114] DB di_getDiskEntries > [115] DB .st_int > [116] DB di_getDiskInfo > [117] DB __xargv > [118] DB convertMountOptions > [119] N _GLOBAL_OFFSET_TABLE_ > [120] DBL [5] libc.so.1 strtok > [121] DBL [5] libc.so.1 fopen64 > Traceback (most recent call last): > File "/home/dam/mgar/pkg/.buildsys/v2/gar/gar//bin/checkpkg", line > 197, in > main() > File "/home/dam/mgar/pkg/.buildsys/v2/gar/gar//bin/checkpkg", line > 120, in main > stats_list = collector.CollectStatsFromFiles(file_list, None) > File "/home/dam/mgar/pkg/.buildsys/v2/lib/python/package_stats.py", > line 499, in CollectStatsFromFiles > stats.CollectStats(force=force_unpack) > File "/home/dam/mgar/pkg/.buildsys/v2/lib/python/package_stats.py", > line 175, in CollectStats > return self._CollectStats(register_files=register_files) > File "/home/dam/mgar/pkg/.buildsys/v2/lib/python/package_stats.py", > line 212, in _CollectStats > "binaries_elf_info": dir_pkg.GetBinaryElfInfo(), > File > "/home/dam/mgar/pkg/.buildsys/v2/lib/python/inspective_package.py", > line 297, in GetBinaryElfInfo > elf_info, cur_section = self._ParseElfdumpLine(line, cur_section) > File > "/home/dam/mgar/pkg/.buildsys/v2/lib/python/inspective_package.py", > line 505, in _ParseElfdumpLine > raise package.StdoutSyntaxError("Could not parse %s" % > (repr(line))) > package.StdoutSyntaxError: Could not parse ' index flgs > bound to symbol' > gmake: *** [pkgcheck] Error 2 > gmake: Leaving directory `/home/dam/mgar/pkg/di/trunk' > Connection to unstable9s closed. > gmake: *** [platforms-repackage] Error 2 > zsh: 19143 exit 2 mgar platforms-repackage This change seems to fix the issue: dam at unstable10s [unstable10s]:/home/dam/mgar/pkg/.buildsys/v2/lib/python > svn diff Index: inspective_package.py =================================================================== --- inspective_package.py (revision 20178) +++ inspective_package.py (working copy) @@ -445,7 +445,7 @@ |\s*index\s*value\s+size\s+type\s+bind # Symbol table header \s+oth\s+ver\s+shndx\s+name\s*$ - |\s*index\s+flags\s+bound\sto\s+symbol\s*$ # Syminfo header + |\s*index\s+fla?gs\s+bound\sto\s+symbol\s*$ # Syminfo header |\s*$ # There is always a blank # line before a new section Best regards -- Dago From yann at pleiades.fr.eu.org Mon Jan 21 17:38:55 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Mon, 21 Jan 2013 17:38:55 +0100 Subject: [csw-maintainers] Problems with symbol detection In-Reply-To: <0a0c27102d23cd3571c48261a54583b7@opencsw.org> References: <0a0c27102d23cd3571c48261a54583b7@opencsw.org> Message-ID: Yes problem known, Maciej had the same problem and I have a patch pending. You encounter this problem probably because you're building under Solaris 9. It seems the several elfdump error messages were changed somewhere between solaris 9 and solaris 10. The unstable10{x,s} don't have this problem. I noticed that patch 147441-19 is the only patch on the buildfarm containg an update of the elfdump binary. Could you check if there is an equivalent patch for Solaris 9 ? Yann 2013/1/21 dam > Am 2013-01-21 17:22, schrieb dam: > > Hi folks, >> >> I get the following error during checkpkg-time, Yann would you mind >> having a look? >> >> >> ## Packaging one part. >> /home/dam/spool.5.9-sparc/**CSWdi/pkgmap >> /home/dam/spool.5.9-sparc/**CSWdi/pkginfo >> /home/dam/spool.5.9-sparc/**CSWdi/root/opt/csw/bin/di >> /home/dam/spool.5.9-sparc/**CSWdi/root/opt/csw/share/doc/**di/license >> >> /home/dam/spool.5.9-sparc/**CSWdi/root/opt/csw/share/** >> locale/de/LC_MESSAGES/di.mo >> >> /home/dam/spool.5.9-sparc/**CSWdi/root/opt/csw/share/** >> locale/en/LC_MESSAGES/di.mo >> >> /home/dam/spool.5.9-sparc/**CSWdi/root/opt/csw/share/** >> locale/es/LC_MESSAGES/di.mo >> /home/dam/spool.5.9-sparc/**CSWdi/root/opt/csw/share/man/**man1/di.1 >> /home/dam/spool.5.9-sparc/**CSWdi/install/copyright >> /home/dam/spool.5.9-sparc/**CSWdi/install/depend >> ## Validating control scripts. >> ## Packaging complete. >> mkp: exec( pkgtrans -s /home/dam/spool.5.9-sparc >> /tmp/di-4.34,REV=2013.01.21-**SunOS5.9-sparc-CSW.pkg CSWdi ) >> Transferring package instance >> mkp: exec( pigz -9 -f /tmp/di-4.34,REV=2013.01.21-**SunOS5.9-sparc-CSW.pkg >> ) >> mkp: exec( mv /tmp/di-4.34,REV=2013.01.21-**SunOS5.9-sparc-CSW.pkg.gz >> /home/dam/staging/build-21.**Jan.2013 ) >> mkp: exec( rm -rf /home/dam/spool.5.9-sparc/**CSWdi ) >> INFO:root:Juicing the svr4 package stream files... >> elfdump out: >> | >> >> Version Needed Section: .SUNW_version >> file version >> libnsl.so.1 SUNW_1.6 >> libc.so.1 SUNW_1.18 >> SUNWprivate_1.1 >> >> Symbol Table Section: .dynsym >> index value size type bind oth ver shndx name >> [0] 0x00000000 0x00000000 NOTY LOCL D 0 UNDEF >> [1] 0x00029d64 0x00000000 FUNC GLOB D 0 UNDEF strncmp >> [2] 0x00029e18 0x00000000 FUNC GLOB D 0 UNDEF __umul64 >> [3] 0x00029cec 0x00000000 FUNC GLOB D 0 UNDEF atexit >> [4] 0x00029d34 0x00000000 FUNC GLOB D 0 UNDEF free >> [5] 0x00029e0c 0x00000000 FUNC GLOB D 0 UNDEF memset >> [6] 0x00029d7c 0x00000000 FUNC GLOB D 0 UNDEF perror >> [7] 0x0002a120 0x00000004 OBJT GLOB D 0 .data _environ >> [8] 0x00029f98 0x00000000 FUNC GLOB D 0 UNDEF mbrlen >> [9] 0x0002acc0 0x00000209 OBJT WEAK D 0 .bss _ctype >> [10] 0x000186f4 0x0000000c FUNC GLOB D 0 .fini _fini >> [11] 0x000134f0 0x00000088 FUNC GLOB D 0 .text >> di_isLoopbackFs >> [12] 0x0001332c 0x00000024 FUNC GLOB D 0 .text >> di_saveInodeSizes >> [13] 0x00029fbc 0x00000000 FUNC GLOB D 0 UNDEF atof >> [14] 0x00011858 0x00000000 FUNC GLOB D 0 .text .ld_llong >> [15] 0x00029fa4 0x00000000 FUNC GLOB D 0 UNDEF atoi >> [16] 0x00011a0c 0x00000000 FUNC GLOB D 0 .text .st_llong >> [17] 0x00029d4c 0x00000000 FUNC GLOB D 0 UNDEF stat64 >> [18] 0x00011c30 0x0000024c FUNC GLOB D 0 .text main >> [19] 0x00029ffc 0x00000000 OBJT GLOB D 0 .dynamic _DYNAMIC >> [20] 0x00029f5c 0x00000000 FUNC GLOB D 0 UNDEF _Q_div >> [21] 0x00029fb0 0x00000000 FUNC GLOB D 0 UNDEF atol >> [22] 0x00029e00 0x00000000 FUNC GLOB D 0 UNDEF strspn >> [23] 0x00029e78 0x00000000 FUNC GLOB D 0 UNDEF hasmntopt >> [24] 0x0002a12c 0x00000004 OBJT GLOB D 0 .data ___Argv >> [25] 0x00029de8 0x00000000 FUNC GLOB D 0 UNDEF >> libintl_textdomain >> [26] 0x00018700 0x00000004 OBJT GLOB D 0 .rodata >> _lib_version >> [27] 0x00029f50 0x00000000 FUNC GLOB D 0 UNDEF _Q_ulltoq >> [28] 0x0002ab58 0x00000000 OBJT GLOB D 0 .data1 _edata >> [29] 0x00029e60 0x00000000 FUNC GLOB D 0 UNDEF getmntent >> [30] 0x0002aed4 0x00000000 OBJT GLOB D 0 .bss _end >> [31] 0x00013430 0x00000048 FUNC GLOB D 0 .text >> di_testRemoteDisk >> [32] 0x00029f44 0x00000000 FUNC GLOB D 0 UNDEF snprintf >> [33] 0x0002a108 0x00000018 OBJT GLOB D 0 .data >> __environ_lock >> [34] 0x0002acc0 0x00000209 OBJT GLOB D 0 .bss __ctype >> [35] 0x00029efc 0x00000000 FUNC GLOB D 0 UNDEF >> authsys_create_default >> [36] 0x00013298 0x00000030 FUNC GLOB D 0 .text >> di_initDiskInfo >> [37] 0x00029d58 0x00000000 FUNC GLOB D 0 UNDEF fstat64 >> [38] 0x00014520 0x00000844 FUNC GLOB D 0 .text >> printDiskInfo >> [39] 0x00014d74 0x000001b4 FUNC GLOB D 0 .text sortArray >> [40] 0x00029d70 0x00000000 FUNC GLOB D 0 UNDEF fprintf >> [41] 0x0002a128 0x00000004 OBJT GLOB D 0 .data >> __cg92_used >> [42] 0x00029e9c 0x00000000 FUNC GLOB D 0 UNDEF ioctl >> [43] 0x0002a120 0x00000004 OBJT WEAK D 0 .data environ >> [44] 0x00029dac 0x00000000 FUNC GLOB D 0 UNDEF getegid >> [45] 0x000186e4 0x00000010 FUNC GLOB D 0 .init _init >> [46] 0x0002aed0 0x00000004 OBJT GLOB D 0 .bss __xargc >> [47] 0x0002ab78 0x00000140 OBJT GLOB D 0 .bss __iob >> [48] 0x00011a7c 0x00000000 FUNC GLOB D 0 .text .st_float >> [49] 0x0002ab78 0x00000140 OBJT WEAK D 0 .bss _iob >> [50] 0x00011b6c 0x00000000 FUNC GLOB D 0 .text >> .st_float_foreff >> [51] 0x00013578 0x00000064 FUNC GLOB D 0 .text >> di_mungePoolName >> [52] 0x00013478 0x00000078 FUNC GLOB D 0 .text >> di_isPooledFs >> [53] 0x000118ec 0x00000000 FUNC GLOB D 0 .text .ld_float >> [54] 0x00029ddc 0x00000000 FUNC GLOB D 0 UNDEF >> libintl_bindtextdomain >> [55] 0x00029ea8 0x00000000 FUNC GLOB D 0 UNDEF close >> [56] 0x00029f38 0x00000000 FUNC GLOB D 0 UNDEF _Q_fle >> [57] 0x00029fe0 0x00000000 FUNC GLOB D 0 UNDEF realloc >> [58] 0x00029fec 0x00000000 FUNC WEAK D 0 UNDEF >> _get_exit_frame_monitor >> [59] 0x000186a8 0x0000003c FUNC GLOB D 0 .text trimChar >> [60] 0x00013378 0x00000008 FUNC GLOB D 0 .text >> convertNFSMountOptions >> [61] 0x0002acb8 0x00000004 OBJT GLOB D 0 .bss errno >> [62] 0x00017098 0x00000238 FUNC GLOB D 0 .text getoptn >> [63] 0x00029d88 0x00000000 FUNC GLOB D 0 UNDEF lstat64 >> [64] 0x00029d04 0x00000000 FUNC GLOB D 0 UNDEF _exit >> [65] 0x00029ecc 0x00000000 FUNC GLOB D 0 UNDEF xdr_int >> [66] 0x00029cf8 0x00000000 FUNC GLOB D 0 UNDEF exit >> [67] 0x00029f80 0x00000000 FUNC GLOB D 0 UNDEF _Q_flt >> [68] 0x00029db8 0x00000000 FUNC GLOB D 0 UNDEF strcmp >> [69] 0x00029e24 0x00000000 FUNC GLOB D 0 UNDEF strdup >> [70] 0x00029e90 0x00000000 FUNC GLOB D 0 UNDEF strncat >> [71] 0x000116f0 0x00000120 FUNC GLOB D 0 .text _start >> [72] 0x00011ba4 0x00000000 FUNC GLOB D 0 .text >> .st_double_foreff >> [73] 0x00000000 0x00000000 NOTY WEAK D 0 UNDEF >> __1cG__CrunMdo_exit_code6F_v_ >> [74] 0x00029f08 0x00000000 FUNC GLOB D 0 UNDEF >> libintl_gettext >> [75] 0x00018684 0x00000024 FUNC GLOB D 0 .text _realloc >> [76] 0x00029da0 0x00000000 FUNC GLOB D 0 UNDEF geteuid >> [77] 0x00029e84 0x00000000 FUNC GLOB D 0 UNDEF statvfs64 >> [78] 0x00029cbc 0x00000000 OBJT GLOB D 0 .plt >> _PROCEDURE_LINKAGE_TABLE_ >> [79] 0x00013a80 0x000000bc FUNC GLOB D 0 .text diquota >> [80] 0x00029f14 0x00000000 FUNC GLOB D 0 UNDEF _Q_feq >> [81] 0x00013380 0x000000b0 FUNC GLOB D 0 .text >> chkMountOptions >> [82] 0x00029f20 0x00000000 FUNC GLOB D 0 UNDEF _Q_fne >> [83] 0x00029df4 0x00000000 FUNC GLOB D 0 UNDEF strlen >> [84] 0x00011ad0 0x00000000 FUNC GLOB D 0 .text >> .st_double >> [85] 0x00029d28 0x00000000 FUNC GLOB D 0 UNDEF printf >> [86] 0x00029e3c 0x00000000 FUNC GLOB D 0 UNDEF strstr >> [87] 0x00029fc8 0x00000000 FUNC GLOB D 0 UNDEF malloc >> [88] 0x00029f68 0x00000000 FUNC GLOB D 0 UNDEF _Q_mul >> [89] 0x00029ed8 0x00000000 FUNC GLOB D 0 UNDEF xdr_bool >> [90] 0x00029ef0 0x00000000 FUNC GLOB D 0 UNDEF >> clnt_create >> [91] 0x00029dd0 0x00000000 FUNC GLOB D 0 UNDEF getenv >> [92] 0x0002a138 0x00000004 OBJT GLOB D 0 .data debug >> [93] 0x00029d1c 0x00000000 FUNC GLOB D 0 UNDEF strncpy >> [94] 0x00029ee4 0x00000000 FUNC GLOB D 0 UNDEF >> xdr_uint32_t >> [95] 0x00029f74 0x00000000 FUNC GLOB D 0 UNDEF _Q_fge >> [96] 0x00029fd4 0x00000000 FUNC GLOB D 0 UNDEF memcmp >> [97] 0x00011938 0x00000000 FUNC GLOB D 0 .text >> .ld_double >> [98] 0x00029e6c 0x00000000 FUNC GLOB D 0 UNDEF fclose >> [99] 0x00029f8c 0x00000000 FUNC GLOB D 0 UNDEF strcoll >> [100] 0x00029ec0 0x00000000 FUNC GLOB D 0 UNDEF >> xdr_int32_t >> [101] 0x00029d40 0x00000000 FUNC GLOB D 0 UNDEF open64 >> [102] 0x00014f38 0x000000a0 FUNC GLOB D 0 .text >> getPrintFlagText >> [103] 0x00029f2c 0x00000000 FUNC GLOB D 0 UNDEF _Q_fgt >> [104] 0x00000000 0x00000000 NOTY GLOB D 0 ABS >> __fsr_init_value >> [105] 0x000173b8 0x000001c0 FUNC GLOB D 0 .text >> getDIOptions >> [106] 0x00029d94 0x00000000 FUNC GLOB D 0 UNDEF realpath >> [107] 0x000132c8 0x00000064 FUNC GLOB D 0 .text >> di_saveBlockSizes >> [108] 0x00029e48 0x00000000 FUNC GLOB D 0 UNDEF strchr >> [109] 0x00029d10 0x00000000 FUNC GLOB D 0 UNDEF _Q_dtoq >> [110] 0x00019cb8 0x00000000 OBJT GLOB D 0 .rodata1 _etext >> [111] 0x00029dc4 0x00000000 FUNC GLOB D 0 UNDEF setlocale >> [112] 0x00011810 0x00000000 FUNC GLOB D 0 .text .ld_int >> [113] 0x00029eb4 0x00000000 FUNC GLOB D 0 UNDEF >> xdr_string >> [114] 0x000135dc 0x00000200 FUNC GLOB D 0 .text >> di_getDiskEntries >> [115] 0x000119d4 0x00000000 FUNC GLOB D 0 .text .st_int >> [116] 0x000137f8 0x000001e8 FUNC GLOB D 0 .text >> di_getDiskInfo >> [117] 0x0002aecc 0x00000004 OBJT GLOB D 0 .bss __xargv >> [118] 0x00013360 0x00000008 FUNC GLOB D 0 .text >> convertMountOptions >> [119] 0x00029cb8 0x00000000 OBJT GLOB D 0 .got >> _GLOBAL_OFFSET_TABLE_ >> [120] 0x00029e30 0x00000000 FUNC GLOB D 0 UNDEF strtok >> [121] 0x00029e54 0x00000000 FUNC GLOB D 0 UNDEF fopen64 >> >> Syminfo Section: .SUNW_syminfo >> index flgs bound to symbol >> [1] DBL [5] libc.so.1 strncmp >> [2] DBL [5] libc.so.1 __umul64 >> [3] DBL [5] libc.so.1 atexit >> [4] DBL [5] libc.so.1 free >> [5] DBL [5] libc.so.1 memset >> [6] DBL [5] libc.so.1 perror >> [7] DB _environ >> [8] DBL [5] libc.so.1 mbrlen >> [9] DBC [5] libc.so.1 _ctype >> [10] DB _fini >> [11] DB di_isLoopbackFs >> [12] DB di_saveInodeSizes >> [13] DBL [5] libc.so.1 atof >> [14] DB .ld_llong >> [15] DBL [5] libc.so.1 atoi >> [16] DB .st_llong >> [17] DBL [5] libc.so.1 stat64 >> [18] DB main >> [19] N _DYNAMIC >> [20] DBL [5] libc.so.1 _Q_div >> [21] DBL [5] libc.so.1 atol >> [22] DBL [5] libc.so.1 strspn >> [23] DBL [5] libc.so.1 hasmntopt >> [24] DB ___Argv >> [25] DBL [1] libintl.so.8 libintl_textdomain >> [26] DB _lib_version >> [27] DBL [5] libc.so.1 _Q_ulltoq >> [28] N _edata >> [29] DBL [5] libc.so.1 getmntent >> [30] N _end >> [31] DB di_testRemoteDisk >> [32] DBL [5] libc.so.1 snprintf >> [33] DB __environ_lock >> [34] DBC [5] libc.so.1 __ctype >> [35] DBL [3] libnsl.so.1 authsys_create_default >> [36] DB di_initDiskInfo >> [37] DBL [5] libc.so.1 fstat64 >> [38] DB printDiskInfo >> [39] DB sortArray >> [40] DBL [5] libc.so.1 fprintf >> [41] DB __cg92_used >> [42] DBL [5] libc.so.1 ioctl >> [43] DB environ >> [44] DBL [5] libc.so.1 getegid >> [45] DB _init >> [46] DB __xargc >> [47] DBC [5] libc.so.1 __iob >> [48] DB .st_float >> [49] DBC [5] libc.so.1 _iob >> [50] DB .st_float_foreff >> [51] DB di_mungePoolName >> [52] DB di_isPooledFs >> [53] DB .ld_float >> [54] DBL [1] libintl.so.8 libintl_bindtextdomain >> [55] DBL [5] libc.so.1 close >> [56] DBL [5] libc.so.1 _Q_fle >> [57] DBL [5] libc.so.1 realloc >> [58] DBL [5] libc.so.1 _get_exit_frame_monitor >> [59] DB trimChar >> [60] DB convertNFSMountOptions >> [61] DBC [5] libc.so.1 errno >> [62] DB getoptn >> [63] DBL [5] libc.so.1 lstat64 >> [64] DBL [5] libc.so.1 _exit >> [65] DBL [3] libnsl.so.1 xdr_int >> [66] DBL [5] libc.so.1 exit >> [67] DBL [5] libc.so.1 _Q_flt >> [68] DBL [5] libc.so.1 strcmp >> [69] DBL [5] libc.so.1 strdup >> [70] DBL [5] libc.so.1 strncat >> [71] DB _start >> [72] DB .st_double_foreff >> [74] DBL [1] libintl.so.8 libintl_gettext >> [75] DB _realloc >> [76] DBL [5] libc.so.1 geteuid >> [77] DBL [5] libc.so.1 statvfs64 >> [78] N _PROCEDURE_LINKAGE_TABLE_ >> [79] DB diquota >> [80] DBL [5] libc.so.1 _Q_feq >> [81] DB chkMountOptions >> [82] DBL [5] libc.so.1 _Q_fne >> [83] DBL [5] libc.so.1 strlen >> [84] DB .st_double >> [85] DBL [5] libc.so.1 printf >> [86] DBL [5] libc.so.1 strstr >> [87] DBL [5] libc.so.1 malloc >> [88] DBL [5] libc.so.1 _Q_mul >> [89] DBL [3] libnsl.so.1 xdr_bool >> [90] DBL [3] libnsl.so.1 clnt_create >> [91] DBL [5] libc.so.1 getenv >> [92] DB debug >> [93] DBL [5] libc.so.1 strncpy >> [94] DBL [3] libnsl.so.1 xdr_uint32_t >> [95] DBL [5] libc.so.1 _Q_fge >> [96] DBL [5] libc.so.1 memcmp >> [97] DB .ld_double >> [98] DBL [5] libc.so.1 fclose >> [99] DBL [5] libc.so.1 strcoll >> [100] DBL [3] libnsl.so.1 xdr_int32_t >> [101] DBL [5] libc.so.1 open64 >> [102] DB getPrintFlagText >> [103] DBL [5] libc.so.1 _Q_fgt >> [104] DB __fsr_init_value >> [105] DB getDIOptions >> [106] DBL [5] libc.so.1 realpath >> [107] DB di_saveBlockSizes >> [108] DBL [5] libc.so.1 strchr >> [109] DBL [5] libc.so.1 _Q_dtoq >> [110] N _etext >> [111] DBL [5] libc.so.1 setlocale >> [112] DB .ld_int >> [113] DBL [3] libnsl.so.1 xdr_string >> [114] DB di_getDiskEntries >> [115] DB .st_int >> [116] DB di_getDiskInfo >> [117] DB __xargv >> [118] DB convertMountOptions >> [119] N _GLOBAL_OFFSET_TABLE_ >> [120] DBL [5] libc.so.1 strtok >> [121] DBL [5] libc.so.1 fopen64 >> Traceback (most recent call last): >> File "/home/dam/mgar/pkg/.buildsys/**v2/gar/gar//bin/checkpkg", line >> 197, in >> main() >> File "/home/dam/mgar/pkg/.buildsys/**v2/gar/gar//bin/checkpkg", line >> 120, in main >> stats_list = collector.**CollectStatsFromFiles(file_**list, None) >> File "/home/dam/mgar/pkg/.buildsys/**v2/lib/python/package_stats.**py", >> line 499, in CollectStatsFromFiles >> stats.CollectStats(force=**force_unpack) >> File "/home/dam/mgar/pkg/.buildsys/**v2/lib/python/package_stats.**py", >> line 175, in CollectStats >> return self._CollectStats(register_**files=register_files) >> File "/home/dam/mgar/pkg/.buildsys/**v2/lib/python/package_stats.**py", >> line 212, in _CollectStats >> "binaries_elf_info": dir_pkg.GetBinaryElfInfo(), >> File >> "/home/dam/mgar/pkg/.buildsys/**v2/lib/python/inspective_**package.py", >> line 297, in GetBinaryElfInfo >> elf_info, cur_section = self._ParseElfdumpLine(line, cur_section) >> File >> "/home/dam/mgar/pkg/.buildsys/**v2/lib/python/inspective_**package.py", >> line 505, in _ParseElfdumpLine >> raise package.StdoutSyntaxError("**Could not parse %s" % >> (repr(line))) >> package.StdoutSyntaxError: Could not parse ' index flgs >> bound to symbol' >> gmake: *** [pkgcheck] Error 2 >> gmake: Leaving directory `/home/dam/mgar/pkg/di/trunk' >> Connection to unstable9s closed. >> gmake: *** [platforms-repackage] Error 2 >> zsh: 19143 exit 2 mgar platforms-repackage >> > > This change seems to fix the issue: > > > dam at unstable10s [unstable10s]:/home/dam/mgar/**pkg/.buildsys/v2/lib/python > > svn diff > Index: inspective_package.py > ==============================**==============================**======= > --- inspective_package.py (revision 20178) > +++ inspective_package.py (working copy) > @@ -445,7 +445,7 @@ > |\s*index\s*value\s+size\s+**type\s+bind # Symbol table header > \s+oth\s+ver\s+shndx\s+name\s***$ > > - |\s*index\s+flags\s+bound\sto\**s+symbol\s*$ # Syminfo header > + |\s*index\s+fla?gs\s+bound\**sto\s+symbol\s*$ # Syminfo header > > |\s*$ # There is always a > blank > # line before a new > section > > > > > Best regards > > -- Dago > ______________________________**_________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/**mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfelecan at opencsw.org Tue Jan 22 09:39:05 2013 From: pfelecan at opencsw.org (pfelecan) Date: Tue, 22 Jan 2013 09:39:05 +0100 Subject: [csw-maintainers] there is something rotten around checkpkg Message-ID: <2f49beb17c8c2fdb1f60722d53e5a085@opencsw.org> After 15 hour the re-merge and re-packaging failed; the details are available in ~pefelecan/logs/texlive; the relevant excerpt is: elfdump out: Version Needed Section: .SUNW_version index file version [2] libc.so.1 SUNW_1.1 [3] SUNW_0.7 [ INFO ] [4] SUNWprivate_1.1 [5] SYSVABI_1.3 [ INFO ] Symbol Table Section: .SUNW_ldynsym index value size type bind oth ver shndx name [0] 0x00000000 0x00000000 NOTY LOCL D 0 UNDEF [1] 0x00000000 0x00000000 FILE LOCL D 0 ABS ./boot [2] 0x00000000 0x00000000 FILE LOCL D 0 ABS crti.s [3] 0x00000000 0x00000000 FILE LOCL D 0 ABS crt1.o [4] 0x00000000 0x00000000 FILE LOCL D 0 ABS crt1.s [5] 0x00000000 0x00000000 FILE LOCL D 0 ABS fsr.s [6] 0x00000000 0x00000000 FILE LOCL D 0 ABS values-Xa.c [7] 0x00000000 0x00000000 FILE LOCL D 0 ABS boot.c [8] 0x0805159c 0x00000040 FUNC LOCL D 0 .text write_chunks [9] 0x080515dc 0x000000a4 FUNC LOCL D 0 .text __findenv [10] 0x08051680 0x00000014 FUNC LOCL D 0 .text par_getenv [11] 0x08051694 0x000001b4 FUNC LOCL D 0 .text par_setenv [12] 0x08051848 0x00000068 FUNC LOCL D 0 .text par_unsetenv [13] 0x08051e00 0x0000116c FUNC LOCL D 0 .text sha_transfor m [14] 0x08052f6c 0x00000035 FUNC LOCL D 0 .text sha_init [15] 0x08052fa4 0x0000017f FUNC LOCL D 0 .text sha_update [16] 0x08053124 0x0000008f FUNC LOCL D 0 .text sha_transfor m_and_copy [17] 0x080531b4 0x000000c7 FUNC LOCL D 0 .text sha_final [18] 0x080532a4 0x0000006d FUNC LOCL D 0 .text isWritableDi r [19] 0x08053314 0x0000005f FUNC LOCL D 0 .text isSafeDir [20] 0x08053be8 0x0000014f FUNC LOCL D 0 .text par_rmtmpdir [21] 0x08053da4 0x000000c9 FUNC LOCL D 0 .text my_mkfile [22] 0x00000000 0x00000000 FILE LOCL D 0 ABS crtn.s Symbol Table Section: .dynsym index value size type bind oth ver shndx name [0] 0x00000000 0x00000000 NOTY LOCL D 0 UNDEF [1] 0x080513ac 0x00000000 FUNC GLOB D 2 UNDEF open64 [2] 0x08064730 0x00000004 OBJT GLOB D 1 .data _environ [3] 0x08053d38 0x0000006c FUNC GLOB D 1 .text par_cleanup [4] 0x0805128c 0x00000000 FUNC GLOB D 5 UNDEF strlen [5] 0x0805147c 0x00000000 FUNC WEAK D 4 UNDEF _get_exit_fr ame_monitor [6] 0x08064730 0x00000004 OBJT WEAK D 1 .data environ [7] 0x08051bb0 0x0000020b FUNC GLOB D 1 .text par_init_env [8] 0x0805134c 0x00000000 FUNC GLOB D 5 UNDEF memcpy [9] 0x080512dc 0x00000000 FUNC GLOB D 5 UNDEF strtok [10] 0x080513dc 0x00000000 FUNC GLOB D 5 UNDEF read [11] 0x0805129c 0x00000000 FUNC GLOB D 5 UNDEF malloc [12] 0x08053374 0x00000128 FUNC GLOB D 1 .text par_setup_li bpath [13] 0x0805124c 0x00000000 FUNC GLOB D 5 UNDEF atexit [14] 0x0805141c 0x00000000 FUNC GLOB D 2 UNDEF readdir64 [15] 0x0805144c 0x00000000 FUNC GLOB D 5 UNDEF unlink [16] 0x08053e70 0x000002a9 FUNC GLOB D 1 .text main [17] 0x0805146c 0x00000000 FUNC GLOB D 5 UNDEF execvp [18] 0x08051490 0x0000008e FUNC GLOB D 1 .text _start [19] 0x08051aa4 0x0000002d FUNC GLOB D 1 .text par_basename [20] 0x0805121c 0x00000000 OBJT GLOB D 1 .plt _PROCEDURE_L INKAGE_TABLE_ [21] 0x0805135c 0x00000000 FUNC GLOB D 5 UNDEF memset [22] 0x08054158 0x00000004 OBJT GLOB D 1 .rodata _lib_version [23] 0x080518b0 0x00000007 FUNC GLOB D 1 .text par_current_ exec [24] 0x0805327c 0x00000028 FUNC GLOB D 1 .text get_username _from_getpwuid [25] 0x08064734 0x00000018 OBJT GLOB D 1 .data __environ_lo ck [26] 0x08054138 0x0000001b FUNC GLOB D 1 .fini _fini [27] 0x080513cc 0x00000000 FUNC GLOB D 2 UNDEF lseek64 [28] 0x0805138c 0x00000000 FUNC GLOB D 5 UNDEF mkdir [29] 0x080513ec 0x00000000 FUNC GLOB D 5 UNDEF close [30] 0x080512fc 0x00000000 FUNC GLOB D 5 UNDEF sprintf [31] 0x082147f8 0x00000004 OBJT GLOB D 1 .bss errno [32] 0x00000000 0x00000000 NOTY GLOB D 1 ABS __fsr_init_value [33] 0x08054512 0x00000000 OBJT GLOB D 1 .rodata1 _etext [34] 0x0805145c 0x00000000 FUNC GLOB D 5 UNDEF chmod [35] 0x0805411c 0x0000001b FUNC GLOB D 1 .init _init [36] 0x080512ec 0x00000000 FUNC GLOB D 5 UNDEF strcmp [37] 0x0805127c 0x00000000 FUNC GLOB D 5 UNDEF strncmp [38] 0x080645b8 0x00000000 OBJT GLOB D 1 .dynamic _DYNAMIC [39] 0x0805140c 0x00000000 FUNC GLOB D 5 UNDEF opendir [40] 0x08214438 0x000003c0 OBJT GLOB D 1 .bss _iob [41] 0x0805139c 0x00000000 FUNC GLOB D 5 UNDEF fprintf [42] 0x08214438 0x000003c0 OBJT GLOB D 1 .bss __iob [43] 0x0805137c 0x00000000 FUNC GLOB D 5 UNDEF getpwuid [44] 0x080513fc 0x00000000 FUNC GLOB D 5 UNDEF free [45] 0x0805142c 0x00000000 FUNC GLOB D 5 UNDEF closedir [46] 0x0805123c 0x00000000 FUNC GLOB D 5 UNDEF exit [47] 0x080512ac 0x00000000 FUNC GLOB D 5 UNDEF memmove [48] 0x080512bc 0x00000000 FUNC GLOB D 5 UNDEF realloc [49] 0x0805125c 0x00000000 FUNC GLOB D 5 UNDEF _exit [50] 0x0805122c 0x00000000 FUNC GLOB D 5 UNDEF __fpstart [51] 0x08051dbc 0x00000043 FUNC GLOB D 1 .text par_env_clean [52] 0x080512cc 0x00000000 FUNC GLOB D 5 UNDEF strstr [53] 0x08064758 0x00000004 OBJT GLOB D 1 .data __longdouble_used [54] 0x0805130c 0x00000000 FUNC GLOB D 2 UNDEF stat64 [55] 0x08064514 0x00000000 OBJT GLOB P 1 .got _GLOBAL_OFFSET_TABLE_ [56] 0x08051ad4 0x000000d9 FUNC GLOB D 1 .text par_dirname [57] 0x0820c434 0x00000000 OBJT GLOB D 1 .bssf _edata [58] 0x080518b8 0x000001eb FUNC GLOB D 1 .text par_findprog [59] 0x0805131c 0x00000000 FUNC GLOB D 5 UNDEF access [60] 0x0805132c 0x00000000 FUNC GLOB D 5 UNDEF strdup [61] 0x00000000 0x00000000 NOTY WEAK D 0 UNDEF __1cG__CrunMdo_exit_code6F_v_ [62] 0x0806474c 0x00000004 OBJT GLOB D 1 .data ___Argv [63] 0x0805349c 0x0000074c FUNC GLOB D 1 .text par_mktmpdir [64] 0x0805126c 0x00000000 FUNC GLOB D 5 UNDEF write [65] 0x080513bc 0x00000000 FUNC GLOB D 5 UNDEF getpid [66] 0x0805143c 0x00000000 FUNC GLOB D 5 UNDEF rmdir [67] 0x08051520 0x0000007b FUNC GLOB D 1 .text __fsr [68] 0x0805136c 0x00000000 FUNC GLOB D 5 UNDEF getuid [69] 0x082147fc 0x00000000 OBJT GLOB D 1 .bss _end [70] 0x0805133c 0x00000000 FUNC GLOB D 5 UNDEF strncpy Traceback (most recent call last): File "/home/pfelecan/opencsw/.buildsys/v2/gar/gar//bin/checkpkg", line 197, in main() File "/home/pfelecan/opencsw/.buildsys/v2/gar/gar//bin/checkpkg", line 120, in main stats_list = collector.CollectStatsFromFiles(file_list, None) File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py", line 499, in CollectStatsFromFiles stats.CollectStats(force=force_unpack) File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py", line 175, in CollectStats return self._CollectStats(register_files=register_files) File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/package_stats.py", line 212, in _CollectStats "binaries_elf_info": dir_pkg.GetBinaryElfInfo(), File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/inspective_package.py", line 297, in GetBinaryElfInfo elf_info, cur_section = self._ParseElfdumpLine(line, cur_section) File "/home/pfelecan/opencsw/.buildsys/v2/lib/python/inspective_package.py", line 505, in _ParseElfdumpLine raise package.StdoutSyntaxError("Could not parse %s" % (repr(line))) package.StdoutSyntaxError: Could not parse 'Symbol Table Section: .SUNW_ldynsym' From yann at pleiades.fr.eu.org Tue Jan 22 11:40:00 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Tue, 22 Jan 2013 11:40:00 +0100 Subject: [csw-maintainers] there is something rotten around checkpkg In-Reply-To: <2f49beb17c8c2fdb1f60722d53e5a085@opencsw.org> References: <2f49beb17c8c2fdb1f60722d53e5a085@opencsw.org> Message-ID: Problem fixed recently in http://sourceforge.net/apps/trac/gar/changeset/20195/csw/mgar/gar/v2 I was able to checkpkg all your i386 packages without execution error. yann at login:/home/pfelecan/staging/build-21.Jan.2013$ ~/opencsw/.buildsys/v2/bin/checkpkg --catalog-release=unstable -r SunOS5.10 -a i386 *-SunOS5.10-i386-* Can you try it again ? Do not relaunch it from scratch, you should be able to start again from the checkpkg phase so we can quickly check that everything is fine. Yann 2013/1/22 pfelecan > After 15 hour the re-merge and re-packaging failed; the details are > available in ~pefelecan/logs/texlive; the relevant excerpt is: > > elfdump out: > > Version Needed Section: .SUNW_version > index file version > [2] libc.so.1 SUNW_1.1 > [3] SUNW_0.7 [ INFO ] > [4] SUNWprivate_1.1 > [5] SYSVABI_1.3 [ INFO ] > > Symbol Table Section: .SUNW_ldynsym > index value size type bind oth ver shndx name > [0] 0x00000000 0x00000000 NOTY LOCL D 0 UNDEF > [1] 0x00000000 0x00000000 FILE LOCL D 0 ABS ./boot > [2] 0x00000000 0x00000000 FILE LOCL D 0 ABS crti.s > [3] 0x00000000 0x00000000 FILE LOCL D 0 ABS crt1.o > [4] 0x00000000 0x00000000 FILE LOCL D 0 ABS crt1.s > [5] 0x00000000 0x00000000 FILE LOCL D 0 ABS fsr.s > [6] 0x00000000 0x00000000 FILE LOCL D 0 ABS > values-Xa.c > [7] 0x00000000 0x00000000 FILE LOCL D 0 ABS boot.c > [8] 0x0805159c 0x00000040 FUNC LOCL D 0 .text > write_chunks > [9] 0x080515dc 0x000000a4 FUNC LOCL D 0 .text > __findenv > [10] 0x08051680 0x00000014 FUNC LOCL D 0 .text > par_getenv > [11] 0x08051694 0x000001b4 FUNC LOCL D 0 .text > par_setenv > [12] 0x08051848 0x00000068 FUNC LOCL D 0 .text > par_unsetenv > [13] 0x08051e00 0x0000116c FUNC LOCL D 0 .text > sha_transfor > m > [14] 0x08052f6c 0x00000035 FUNC LOCL D 0 .text > sha_init > [15] 0x08052fa4 0x0000017f FUNC LOCL D 0 .text > sha_update > [16] 0x08053124 0x0000008f FUNC LOCL D 0 .text > sha_transfor > m_and_copy > [17] 0x080531b4 0x000000c7 FUNC LOCL D 0 .text > sha_final > [18] 0x080532a4 0x0000006d FUNC LOCL D 0 .text > isWritableDi > r > [19] 0x08053314 0x0000005f FUNC LOCL D 0 .text > isSafeDir > [20] 0x08053be8 0x0000014f FUNC LOCL D 0 .text > par_rmtmpdir > [21] 0x08053da4 0x000000c9 FUNC LOCL D 0 .text > my_mkfile > [22] 0x00000000 0x00000000 FILE LOCL D 0 ABS crtn.s > > Symbol Table Section: .dynsym > index value size type bind oth ver shndx name > [0] 0x00000000 0x00000000 NOTY LOCL D 0 UNDEF > [1] 0x080513ac 0x00000000 FUNC GLOB D 2 UNDEF open64 > [2] 0x08064730 0x00000004 OBJT GLOB D 1 .data > _environ > [3] 0x08053d38 0x0000006c FUNC GLOB D 1 .text > par_cleanup > [4] 0x0805128c 0x00000000 FUNC GLOB D 5 UNDEF strlen > [5] 0x0805147c 0x00000000 FUNC WEAK D 4 UNDEF > _get_exit_fr > ame_monitor > [6] 0x08064730 0x00000004 OBJT WEAK D 1 .data environ > [7] 0x08051bb0 0x0000020b FUNC GLOB D 1 .text > par_init_env > [8] 0x0805134c 0x00000000 FUNC GLOB D 5 UNDEF memcpy > [9] 0x080512dc 0x00000000 FUNC GLOB D 5 UNDEF strtok > [10] 0x080513dc 0x00000000 FUNC GLOB D 5 UNDEF read > [11] 0x0805129c 0x00000000 FUNC GLOB D 5 UNDEF malloc > [12] 0x08053374 0x00000128 FUNC GLOB D 1 .text > par_setup_li > bpath > [13] 0x0805124c 0x00000000 FUNC GLOB D 5 UNDEF atexit > [14] 0x0805141c 0x00000000 FUNC GLOB D 2 UNDEF > readdir64 > [15] 0x0805144c 0x00000000 FUNC GLOB D 5 UNDEF unlink > [16] 0x08053e70 0x000002a9 FUNC GLOB D 1 .text main > [17] 0x0805146c 0x00000000 FUNC GLOB D 5 UNDEF execvp > [18] 0x08051490 0x0000008e FUNC GLOB D 1 .text _start > [19] 0x08051aa4 0x0000002d FUNC GLOB D 1 .text > par_basename > [20] 0x0805121c 0x00000000 OBJT GLOB D 1 .plt > _PROCEDURE_L > INKAGE_TABLE_ > [21] 0x0805135c 0x00000000 FUNC GLOB D 5 UNDEF memset > [22] 0x08054158 0x00000004 OBJT GLOB D 1 .rodata > _lib_version > [23] 0x080518b0 0x00000007 FUNC GLOB D 1 .text > par_current_ > exec > [24] 0x0805327c 0x00000028 FUNC GLOB D 1 .text > get_username > _from_getpwuid > [25] 0x08064734 0x00000018 OBJT GLOB D 1 .data > __environ_lo > ck > [26] 0x08054138 0x0000001b FUNC GLOB D 1 .fini _fini > [27] 0x080513cc 0x00000000 FUNC GLOB D 2 UNDEF lseek64 > [28] 0x0805138c 0x00000000 FUNC GLOB D 5 UNDEF mkdir > [29] 0x080513ec 0x00000000 FUNC GLOB D 5 UNDEF close > [30] 0x080512fc 0x00000000 FUNC GLOB D 5 UNDEF sprintf > [31] 0x082147f8 0x00000004 OBJT GLOB D 1 .bss errno > [32] 0x00000000 0x00000000 NOTY GLOB D 1 ABS > __fsr_init_value > [33] 0x08054512 0x00000000 OBJT GLOB D 1 .rodata1 _etext > [34] 0x0805145c 0x00000000 FUNC GLOB D 5 UNDEF chmod > [35] 0x0805411c 0x0000001b FUNC GLOB D 1 .init _init > [36] 0x080512ec 0x00000000 FUNC GLOB D 5 UNDEF strcmp > [37] 0x0805127c 0x00000000 FUNC GLOB D 5 UNDEF strncmp > [38] 0x080645b8 0x00000000 OBJT GLOB D 1 .dynamic > _DYNAMIC > [39] 0x0805140c 0x00000000 FUNC GLOB D 5 UNDEF opendir > [40] 0x08214438 0x000003c0 OBJT GLOB D 1 .bss _iob > [41] 0x0805139c 0x00000000 FUNC GLOB D 5 UNDEF fprintf > [42] 0x08214438 0x000003c0 OBJT GLOB D 1 .bss __iob > [43] 0x0805137c 0x00000000 FUNC GLOB D 5 UNDEF > getpwuid > [44] 0x080513fc 0x00000000 FUNC GLOB D 5 UNDEF free > [45] 0x0805142c 0x00000000 FUNC GLOB D 5 UNDEF > closedir > [46] 0x0805123c 0x00000000 FUNC GLOB D 5 UNDEF exit > [47] 0x080512ac 0x00000000 FUNC GLOB D 5 UNDEF memmove > [48] 0x080512bc 0x00000000 FUNC GLOB D 5 UNDEF realloc > [49] 0x0805125c 0x00000000 FUNC GLOB D 5 UNDEF _exit > [50] 0x0805122c 0x00000000 FUNC GLOB D 5 UNDEF > __fpstart > [51] 0x08051dbc 0x00000043 FUNC GLOB D 1 .text > par_env_clean > [52] 0x080512cc 0x00000000 FUNC GLOB D 5 UNDEF strstr > [53] 0x08064758 0x00000004 OBJT GLOB D 1 .data > __longdouble_used > [54] 0x0805130c 0x00000000 FUNC GLOB D 2 UNDEF stat64 > [55] 0x08064514 0x00000000 OBJT GLOB P 1 .got > _GLOBAL_OFFSET_TABLE_ > [56] 0x08051ad4 0x000000d9 FUNC GLOB D 1 .text > par_dirname > [57] 0x0820c434 0x00000000 OBJT GLOB D 1 .bssf _edata > [58] 0x080518b8 0x000001eb FUNC GLOB D 1 .text > par_findprog > [59] 0x0805131c 0x00000000 FUNC GLOB D 5 UNDEF access > [60] 0x0805132c 0x00000000 FUNC GLOB D 5 UNDEF strdup > [61] 0x00000000 0x00000000 NOTY WEAK D 0 UNDEF > __1cG__CrunMdo_exit_code6F_v_ > [62] 0x0806474c 0x00000004 OBJT GLOB D 1 .data ___Argv > [63] 0x0805349c 0x0000074c FUNC GLOB D 1 .text > par_mktmpdir > [64] 0x0805126c 0x00000000 FUNC GLOB D 5 UNDEF write > [65] 0x080513bc 0x00000000 FUNC GLOB D 5 UNDEF getpid > [66] 0x0805143c 0x00000000 FUNC GLOB D 5 UNDEF rmdir > [67] 0x08051520 0x0000007b FUNC GLOB D 1 .text __fsr > [68] 0x0805136c 0x00000000 FUNC GLOB D 5 UNDEF getuid > [69] 0x082147fc 0x00000000 OBJT GLOB D 1 .bss _end > [70] 0x0805133c 0x00000000 FUNC GLOB D 5 UNDEF strncpy > Traceback (most recent call last): > File "/home/pfelecan/opencsw/.**buildsys/v2/gar/gar//bin/**checkpkg", > line 197, in > main() > File "/home/pfelecan/opencsw/.**buildsys/v2/gar/gar//bin/**checkpkg", > line 120, in main > stats_list = collector.**CollectStatsFromFiles(file_**list, None) > File "/home/pfelecan/opencsw/.**buildsys/v2/lib/python/**package_stats.py", > line 499, in CollectStatsFromFiles > stats.CollectStats(force=**force_unpack) > File "/home/pfelecan/opencsw/.**buildsys/v2/lib/python/**package_stats.py", > line 175, in CollectStats > return self._CollectStats(register_**files=register_files) > File "/home/pfelecan/opencsw/.**buildsys/v2/lib/python/**package_stats.py", > line 212, in _CollectStats > "binaries_elf_info": dir_pkg.GetBinaryElfInfo(), > File "/home/pfelecan/opencsw/.**buildsys/v2/lib/python/**inspective_package.py", > line 297, in GetBinaryElfInfo > elf_info, cur_section = self._ParseElfdumpLine(line, cur_section) > File "/home/pfelecan/opencsw/.**buildsys/v2/lib/python/**inspective_package.py", > line 505, in _ParseElfdumpLine > raise package.StdoutSyntaxError("**Could not parse %s" % (repr(line))) > package.StdoutSyntaxError: Could not parse 'Symbol Table Section: > .SUNW_ldynsym' > ______________________________**_________________ > 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 Jan 22 15:57:51 2013 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Tue, 22 Jan 2013 15:57:51 +0100 Subject: [csw-maintainers] close on nfs mounted file retruns EINVAL on i386 In-Reply-To: References: Message-ID: Hi, i tried to build ocaml. It builds without any problems on Sparc on our buildfarm. But it raise a annoying error on i386: cgrzemba at unstable10x:~/opencsw/ocaml/trunk/work/solaris10-i386/build-isa-pentium_pro/ocaml-3.12.1$ boot/ocamlrun boot/ocamllex parsing/linenum.mll ### OCaml runtime: debug mode ### Initial minor heap size: 1024k bytes Initial major heap size: 496k bytes Initial space overhead: 80% Initial max overhead: 500% Initial heap increment: 496k bytes Initial allocation policy: 0 Initial stack limit: 4096k bytes <>Starting new major GC cycle ### O'Caml runtime: heap check ### !<>$<>$<>$<>$<>Starting new major GC cycle ### O'Caml runtime: heap check ### !<>!12 states, 323 transitions, table size 1364 bytes Fatal error: exception Sys_error("Invalid argument") The invalid argument caused by a close of a file on NFS mounted FS. It works if I try to write the output to local. It is a known problem: http://caml.inria.fr/mantis/view.php?id=4663 The are is a work around provided which ignores the EINVAL return value from close. Has anybody else seen such problems with NFS. -- Carsten Grzemba -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfelecan at opencsw.org Tue Jan 22 20:02:15 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 22 Jan 2013 20:02:15 +0100 Subject: [csw-maintainers] there is something rotten around checkpkg In-Reply-To: (Yann Rouillard's message of "Tue, 22 Jan 2013 11:40:00 +0100") References: <2f49beb17c8c2fdb1f60722d53e5a085@opencsw.org> Message-ID: Yann Rouillard writes: > Can you try it again ? > Do not relaunch it from scratch, you should be able to start again from the > checkpkg phase so we can quickly check that everything is fine. I checked the SPARC packages and everything went alright. Thank you. Now I will try to finish the checking job and advance a little bit in this endeavor. -- Peter From jh at opencsw.org Wed Jan 23 08:57:33 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Wed, 23 Jan 2013 08:57:33 +0100 Subject: [csw-maintainers] s9_preload.so.1 should be excluded from checkpkg In-Reply-To: References: <2f49beb17c8c2fdb1f60722d53e5a085@opencsw.org> Message-ID: <50FF97ED.7040506@opencsw.org> Hi, on Solaris 9 checkpkg now gives this error: CHECKPKG_OVERRIDES_CSWsudo += soname-unused|s9_preload.so.1|is|needed|by|/opt/csw/libexec/sudoers.so|but|never|used I'm not sure when this is added but I should be excluded from this check . Greetings Jan From maciej at opencsw.org Wed Jan 23 16:58:40 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 23 Jan 2013 15:58:40 +0000 Subject: [csw-maintainers] s9_preload.so.1 should be excluded from checkpkg In-Reply-To: <50FF97ED.7040506@opencsw.org> References: <2f49beb17c8c2fdb1f60722d53e5a085@opencsw.org> <50FF97ED.7040506@opencsw.org> Message-ID: If you are able to locate the file which contains the list of excluded libraries, feel free to commit your change and move on with your packaging. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Wed Jan 23 17:16:13 2013 From: dam at opencsw.org (dam) Date: Wed, 23 Jan 2013 17:16:13 +0100 Subject: [csw-maintainers] maintainer field empty for etty6 Message-ID: <3d1e23d4f7eb56522c210b1897bd5d7e@opencsw.org> Hi folks, I just noticed the "Last uploaded by" for jetty6 is empty although the package is maintained by Trygve: http://www.opencsw.org/packages/jetty6/ Maybe someone has an idea why this happened? Best regards -- Dago From maciej at opencsw.org Wed Jan 23 21:37:28 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 23 Jan 2013 20:37:28 +0000 Subject: [csw-maintainers] maintainer field empty for etty6 In-Reply-To: <3d1e23d4f7eb56522c210b1897bd5d7e@opencsw.org> References: <3d1e23d4f7eb56522c210b1897bd5d7e@opencsw.org> Message-ID: Did you try to look at the package stats? You can no longer see them in HTML but you can still get them via rest and examine in a programming language of choice. Or in a JSON prettifier. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Wed Jan 23 21:56:56 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Wed, 23 Jan 2013 21:56:56 +0100 Subject: [csw-maintainers] s9_preload.so.1 should be excluded from checkpkg In-Reply-To: References: <2f49beb17c8c2fdb1f60722d53e5a085@opencsw.org> <50FF97ED.7040506@opencsw.org> Message-ID: Hi Jan, The list of libraries that are excluded are the base solaris libraries, they are listed here: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/python/dependency_checks.py#L42 I can easily add "s9_preload.so.1" in the list but do you have some information about the purpose of this library ? Yann 2013/1/23 Maciej (Matchek) Blizi?ski > If you are able to locate the file which contains the list of excluded > libraries, feel free to commit your change and move on with your packaging. > > Maciej > > _______________________________________________ > 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 jh at opencsw.org Thu Jan 24 07:38:44 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Thu, 24 Jan 2013 07:38:44 +0100 Subject: [csw-maintainers] s9_preload.so.1 should be excluded from checkpkg In-Reply-To: References: <2f49beb17c8c2fdb1f60722d53e5a085@opencsw.org> <50FF97ED.7040506@opencsw.org> Message-ID: <5100D6F4.8070103@opencsw.org> Hi, Am 23.01.13 21:56, schrieb Yann Rouillard: > Hi Jan, > > The list of libraries that are excluded are the base solaris libraries, > they are listed here: > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/python/dependency_checks.py#L42 ok will add it later > > I can easily add "s9_preload.so.1" in the list but do you have some > information about the purpose of this library ? This is a preload lib that is preloaded on branded solaris 9 zones to translate stuff from Solaris9 calls to Solaris 10. Greetings Jan From yann at pleiades.fr.eu.org Thu Jan 24 09:09:37 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Thu, 24 Jan 2013 09:09:37 +0100 Subject: [csw-maintainers] s9_preload.so.1 should be excluded from checkpkg In-Reply-To: <5100D6F4.8070103@opencsw.org> References: <2f49beb17c8c2fdb1f60722d53e5a085@opencsw.org> <50FF97ED.7040506@opencsw.org> <5100D6F4.8070103@opencsw.org> Message-ID: 2013/1/24 Jan Holzhueter > > > > I can easily add "s9_preload.so.1" in the list but do you have some > > information about the purpose of this library ? > > This is a preload lib that is preloaded on branded solaris 9 zones to > translate stuff from Solaris9 calls to Solaris 10. > Does this mean that a binary linked against s9_preload.so.1 will not work on a real Solaris 9 server because this library is only present on branded solaris 9 zone ? Yann > > > 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 jh at opencsw.org Thu Jan 24 09:12:31 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Thu, 24 Jan 2013 09:12:31 +0100 Subject: [csw-maintainers] s9_preload.so.1 should be excluded from checkpkg In-Reply-To: References: <2f49beb17c8c2fdb1f60722d53e5a085@opencsw.org> <50FF97ED.7040506@opencsw.org> <5100D6F4.8070103@opencsw.org> Message-ID: <5100ECEF.2090502@opencsw.org> Hi, Am 24.01.13 09:09, schrieb Yann Rouillard: > > 2013/1/24 Jan Holzhueter > > > > > > I can easily add "s9_preload.so.1" in the list but do you have some > > information about the purpose of this library ? > > This is a preload lib that is preloaded on branded solaris 9 zones to > translate stuff from Solaris9 calls to Solaris 10. > > > Does this mean that a binary linked against s9_preload.so.1 will not > work on a real Solaris 9 server because this library is only present > on branded solaris 9 zone ? no somewhere is a global LD_PRELOAD so you ldd check is just off Probably better to check via elfdump. It's not linked against it. Greetings Jan From yann at pleiades.fr.eu.org Thu Jan 24 09:23:22 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Thu, 24 Jan 2013 09:23:22 +0100 Subject: [csw-maintainers] s9_preload.so.1 should be excluded from checkpkg In-Reply-To: <5100ECEF.2090502@opencsw.org> References: <2f49beb17c8c2fdb1f60722d53e5a085@opencsw.org> <50FF97ED.7040506@opencsw.org> <5100D6F4.8070103@opencsw.org> <5100ECEF.2090502@opencsw.org> Message-ID: 2013/1/24 Jan Holzhueter > > Does this mean that a binary linked against s9_preload.so.1 will not > > work on a real Solaris 9 server because this library is only present > > on branded solaris 9 zone ? > > no somewhere is a global LD_PRELOAD so you ldd check is just off > Probably better to check via elfdump. > It's not linked against it. > > Yes you're right, s9_preload.so.1 is not registered as the dependency of the binary. So rather than add this library to the exclude list, I should check that the libraries flagged as unused by ldd are indeed linked against the binary. I will make that modification. Yann > > 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 Thu Jan 24 11:00:54 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 24 Jan 2013 11:00:54 +0100 Subject: [csw-maintainers] maintainer field empty for etty6 In-Reply-To: References: <3d1e23d4f7eb56522c210b1897bd5d7e@opencsw.org> Message-ID: <98A3C8B5-55A3-41D8-87AF-6C423D65B8DF@opencsw.org> Hi Maciej, Am 23.01.2013 um 21:37 schrieb Maciej (Matchek) Blizi?ski : > Did you try to look at the package stats? You can no longer see them in HTML but you can still get them via rest and examine in a programming language of choice. Or in a JSON prettifier. Yes, the HTML view has problems. Also I can no longer see sudo: http://www.opencsw.org/packages/sudo/ It is in the catalog however: unstable/sparc/5.10/sudo-1.8.6p4,REV=2013.01.23-SunOS5.10-sparc-CSW.pkg.gz Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Thu Jan 24 11:51:00 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 24 Jan 2013 11:51:00 +0100 Subject: [csw-maintainers] [Opencsw] Preserve smf state and configuration files when you rename a package In-Reply-To: References: <07B07F6F-07BA-49F4-BA7B-5E8690A436C3@opencsw.org> Message-ID: Hi Yann, Am 20.01.2013 um 01:43 schrieb Yann Rouillard : > 2013/1/15 Dagobert Michelsen > > What do you think about this issue ? Do you see a better way to solve this problem ? > > Sounds reasonable. I could add > OPENCSW_OBSOLETES=CSW > in pkginfo which should then picked up in addition to the real package name in cswinitsmf. > > Sounds perfect to me. > Is that something that you could do quickly ? Sorry for the delay, yes, very quick ;-) Done in r20209: http://sourceforge.net/apps/trac/gar/changeset/20209 Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From jh at opencsw.org Fri Jan 25 09:55:03 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Fri, 25 Jan 2013 09:55:03 +0100 Subject: [csw-maintainers] Samba main package missing from http://www.opencsw.org/packages In-Reply-To: References: <2f49beb17c8c2fdb1f60722d53e5a085@opencsw.org> <50FF97ED.7040506@opencsw.org> <5100D6F4.8070103@opencsw.org> <5100ECEF.2090502@opencsw.org> Message-ID: <51024867.5020007@opencsw.org> Hi, I updated samba this week. The main samba package is now missing on the website. Someone knows why and can fix it? :) Greetings Jan From grzemba at contac-dt.de Fri Jan 25 10:09:06 2013 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Fri, 25 Jan 2013 10:09:06 +0100 Subject: [csw-maintainers] static libs Message-ID: Hi, ocaml runtime needs a static lib. It seems to be that gar exclude static libs from packaging. Can I add a static lib to package? -- Carsten Grzemba Tel.: +49 3677 64740 Mobil: +49 171 9749479 Fax: +49 3677 6474111 Email: carsten.grzemba at contac-dt.de contac Datentechnik GmbH -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Fri Jan 25 10:12:39 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 25 Jan 2013 10:12:39 +0100 Subject: [csw-maintainers] static libs In-Reply-To: References: Message-ID: Hi Carsten, Am 25.01.2013 um 10:09 schrieb Carsten Grzemba : > ocaml runtime needs a static lib. It seems to be that gar exclude static libs from packaging. Can I add a static lib to package? Definitely. Just use MERGE_EXCLUDE_STATICLIBS = (which defaults to $(libdir)/.*\.a) and you get the static libs in the tree. Is it really needed at runtime and not the devel package? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From bwalton at opencsw.org Fri Jan 25 16:37:30 2013 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 25 Jan 2013 15:37:30 +0000 Subject: [csw-maintainers] Samba main package missing from http://www.opencsw.org/packages In-Reply-To: <51024867.5020007@opencsw.org> References: <2f49beb17c8c2fdb1f60722d53e5a085@opencsw.org> <50FF97ED.7040506@opencsw.org> <5100D6F4.8070103@opencsw.org> <5100ECEF.2090502@opencsw.org> <51024867.5020007@opencsw.org> Message-ID: It may be due to issues with fetching data from the checkpkg database but I'm not sure...and I'm not in a good position to look until about Tuesday. Thanks -Ben On Fri, Jan 25, 2013 at 8:55 AM, Jan Holzhueter wrote: > Hi, > I updated samba this week. > The main samba package is now missing on the website. > Someone knows why and can fix it? :) > > > Greetings > Jan > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From bwalton at opencsw.org Fri Jan 25 16:52:36 2013 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 25 Jan 2013 15:52:36 +0000 Subject: [csw-maintainers] maintainer field empty for etty6 In-Reply-To: <98A3C8B5-55A3-41D8-87AF-6C423D65B8DF@opencsw.org> References: <3d1e23d4f7eb56522c210b1897bd5d7e@opencsw.org> <98A3C8B5-55A3-41D8-87AF-6C423D65B8DF@opencsw.org> Message-ID: Ok, what's happening is this: The web update scripts are fetching the updated catalog Current catalog is diffed with the old catalog Packages needing to be removed or updated are nuked from the database. Packages being added or updated have info fetched from the rest interface and are inserted into the db. The REST calls are failing and that's leaving the job half done (eg: removal step only). This is easy to fix if the REST interface is made responsive again. Barring that, I'd likely be best to restore a backup of the DB until it can be made responsive. Ihsan: Can you please disable my *update* cron jobs on www.opencsw.org? I'm not in a position to do so for a few days. If you're so inclined, you'll find database backups in my ~/db_updates/ directory. The last catalog that had a successful update is the one that the update process stores, so as soon as the REST interface is back in action, we can enable the scripts and things will "just work" which is a nice property of current setup. I should maybe look at only pre-removing packages that won't be re-added and then only doing a remove-on-update for the packages being updated. That would lessen the impact of things like this. Thanks -Ben On Thu, Jan 24, 2013 at 10:00 AM, Dagobert Michelsen wrote: > Hi Maciej, > > Am 23.01.2013 um 21:37 schrieb Maciej (Matchek) Blizi?ski : >> Did you try to look at the package stats? You can no longer see them in HTML but you can still get them via rest and examine in a programming language of choice. Or in a JSON prettifier. > > Yes, the HTML view has problems. Also I can no longer see sudo: > http://www.opencsw.org/packages/sudo/ > > It is in the catalog however: > unstable/sparc/5.10/sudo-1.8.6p4,REV=2013.01.23-SunOS5.10-sparc-CSW.pkg.gz > > > 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. ::. From maciej at opencsw.org Fri Jan 25 18:56:15 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 25 Jan 2013 17:56:15 +0000 Subject: [csw-maintainers] maintainer field empty for etty6 In-Reply-To: References: <3d1e23d4f7eb56522c210b1897bd5d7e@opencsw.org> <98A3C8B5-55A3-41D8-87AF-6C423D65B8DF@opencsw.org> Message-ID: What's the problem with the rest interface? We know it's slow, but is there something actually broken? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Fri Jan 25 20:35:47 2013 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 25 Jan 2013 19:35:47 +0000 Subject: [csw-maintainers] maintainer field empty for etty6 In-Reply-To: References: <3d1e23d4f7eb56522c210b1897bd5d7e@opencsw.org> <98A3C8B5-55A3-41D8-87AF-6C423D65B8DF@opencsw.org> Message-ID: It's causing timeouts in (at least) some calls to it. Thanks -Ben On Fri, Jan 25, 2013 at 5:56 PM, Maciej (Matchek) Blizi?ski wrote: > What's the problem with the rest interface? We know it's slow, but is there > something actually broken? > > > _______________________________________________ > 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 Fri Jan 25 21:20:58 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 25 Jan 2013 20:20:58 +0000 Subject: [csw-maintainers] maintainer field empty for etty6 In-Reply-To: References: <3d1e23d4f7eb56522c210b1897bd5d7e@opencsw.org> <98A3C8B5-55A3-41D8-87AF-6C423D65B8DF@opencsw.org> Message-ID: No dia 25/01/2013 20:36, "Ben Walton" escreveu: > > It's causing timeouts in (at least) some calls to it. Can the http client be a bit more patient? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Sat Jan 26 13:00:40 2013 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 26 Jan 2013 12:00:40 +0000 Subject: [csw-maintainers] maintainer field empty for etty6 In-Reply-To: References: <3d1e23d4f7eb56522c210b1897bd5d7e@opencsw.org> <98A3C8B5-55A3-41D8-87AF-6C423D65B8DF@opencsw.org> Message-ID: Likely. The ruby http library is (uncharacteristically) painful, but I should be able to adjust that setting. Thanks -Ben On Fri, Jan 25, 2013 at 8:20 PM, Maciej (Matchek) Blizi?ski wrote: > No dia 25/01/2013 20:36, "Ben Walton" escreveu: > > >> >> It's causing timeouts in (at least) some calls to it. > > Can the http client be a bit more patient? > > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From yann at pleiades.fr.eu.org Tue Jan 29 00:18:14 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Tue, 29 Jan 2013 00:18:14 +0100 Subject: [csw-maintainers] Fwd: Re: [csw-users] openssh ecdsa key-gen In-Reply-To: References: Message-ID: Hi Data, Do you know how this happened in testing ? Yann ---------- Message transf?r? ---------- De : "Yann Rouillard" Date : 29 janv. 2013 00:17 Objet : Re: [csw-users] openssh ecdsa key-gen ? : "Questions and discussions" Cc : Hi, Indeed someone else reported the same problem recently. It seems ssh and ssh_client weren't synchronized together in testing. Until this is fixed, you can download the corresponding ssh client package at the following url: http://mirror.opencsw.org/opencsw/allpkgs/openssh_client-6.0p1%2cREV%3d2012.05.04-SunOS5.9-sparc-CSW.pkg.gz Yann Le 29 janv. 2013 00:10, "jeremiasz rebelka" a ?crit : > Hello I'm getting the sshd complaining about > /etc/opt/csw/ssh/ssh_host_ecdsa_key - cannot load > > I tried to generate it - with /opt/csw/bin/ssh-keygen -t ecdsa -f ..... > > no luck -> unknown key type ecdsa > > openssh 6.0p1,REV=2012.05.04 > openssh_client 5.4p1,REV=2010.03.25 > > > Is this a bug - or am I doing something stupidly wrong ? > > --thanks > _______________________________________________ > users mailing list > users at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Wed Jan 30 12:18:34 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 30 Jan 2013 11:18:34 +0000 Subject: [csw-maintainers] OpenCSW packaging screencast In-Reply-To: References: Message-ID: 2013/1/6 Peter Bonivart : > I've already seen it and I liked the interviewing style but showing > the different screens below made the main text harder to read. I would > have preferred switching between full screens instead of having > miniatures at the bottom. This layout is realized by the G+ hangouts, so there isn't much we can do. We could switch to own video, but that would mean a lot of additional work with video editing. Having the hangout tech do it for us is a huge relief. From maciej at opencsw.org Wed Jan 30 12:24:51 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 30 Jan 2013 11:24:51 +0000 Subject: [csw-maintainers] Populating private checkpkg databases via REST Message-ID: 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? Pros: - simpler on the local buildfarm - could work around the current memory leak problem Cons: - currently slow as hell because of the REST interface slowness - more stress on the buildfarm, with a potential of inadvertently DOSing the buildfarm remotely by sending too many requests at once - more stress on the buildfarm network connection, because downloading all the data would take up a lot of network bandwidth Maciej From bonivart at opencsw.org Wed Jan 30 14:31:17 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 30 Jan 2013 14:31:17 +0100 Subject: [csw-maintainers] OpenCSW packaging screencast In-Reply-To: References: Message-ID: On Wed, Jan 30, 2013 at 12:18 PM, Maciej (Matchek) Blizi?ski wrote: > 2013/1/6 Peter Bonivart : >> I've already seen it and I liked the interviewing style but showing >> the different screens below made the main text harder to read. I would >> have preferred switching between full screens instead of having >> miniatures at the bottom. > > This layout is realized by the G+ hangouts, so there isn't much we can > do. We could switch to own video, but that would mean a lot of > additional work with video editing. Having the hangout tech do it for > us is a huge relief. I understand. I thought that maybe there were options for this like having picture-in-picture or just switch full screen. No worries. From dam at opencsw.org Wed Jan 30 16:03:05 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 30 Jan 2013 16:03:05 +0100 Subject: [csw-maintainers] Populating private checkpkg databases via REST In-Reply-To: References: Message-ID: Hi Maciej, Am 30.01.2013 um 12:24 schrieb Maciej (Matchek) Blizi?ski : > 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? > > Pros: > - simpler on the local buildfarm > - could work around the current memory leak problem > > Cons: > - currently slow as hell because of the REST interface slowness > - more stress on the buildfarm, with a potential of inadvertently > DOSing the buildfarm remotely by sending too many requests at once > - more stress on the buildfarm network connection, because downloading > all the data would take up a lot of network bandwidth I have no clue how much traffic that would be. We can carry some more, but we are limited to 6 mbps total. We probably have a chance to deploy a much faster machine soon on much faster network where stuff could be replicated to. 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 Jan 30 19:13:25 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 30 Jan 2013 19:13:25 +0100 Subject: [csw-maintainers] Populating private checkpkg databases via REST In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Wed, 30 Jan 2013 11:24:51 +0000") References: Message-ID: "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. -- Peter