From dam at opencsw.org Mon Aug 6 15:46:07 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 6 Aug 2012 15:46:07 +0200 Subject: [csw-maintainers] OpenCSW buildfarm maintenance on 8. August Message-ID: <7BAE0F3A-5880-4538-BF94-D2165487A362@opencsw.org> Hi, the OpenCSW buildfarm needs some patching which I plan to do on 8. August. During that time the farm will not be available for building. Additionally, the following hosts are affected: login.opencsw.org buildfarm.opencsw.org ns3csw.opencsw.org I will keep you posted when the update is finished. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From yann at pleiades.fr.eu.org Tue Aug 7 22:43:08 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Tue, 7 Aug 2012 22:43:08 +0200 Subject: [csw-maintainers] Proposal: direct binding for all the opencsw software stack Message-ID: Hi everybody, As you may have noticed, updating libssl from 0.9.8 to 1.0.0 is proving to be quite a pain. As the linker tries by default to link a symbol against the first library loaded that provides the symbol, in our case that could easily lead to situation where a binary or a library is linked against the wrong library, leading to subtle bugs or crashes. Linux uses symbol versioning to solve this problem but in the Solaris world, even if symbol versioning does exist, that is not the solution to this problem and it turns that a solaris linker feature called direct binding is a right approach (see the thread http://lists.opencsw.org/pipermail/maintainers/2012-July/017064.html and the explanation in oracle manual: http://docs.oracle.com/cd/E19963-01/html/819-0690/aehzq.html ). Direct Binding changes the behaviour of the linker at runtime, when a program or a library has a direct binding against a library, the linker will now link a symbol against the exact library that provided the symbol at compile time. That exactly solves the problem we have here because openssl 0.9.8 symbols will be linked against libssl0.9.8 and not libssl1.0.0 (and vice versa?. So to avoid futures difficulties of the same kind, I am proposing to enable direct binding by default for all opencsw software !) One day or the other we will to handle an new ABI incompatible library which still provides the same functions (but maybe with subtle difference as ABI is not compatible). Openssl is the first big one but we will have others problem like this (libpng or libjpeg ?). Currently, we have to pretty much upload together all the packages linked against the library, which turns out to be difficult to do as it requires a lot of coordination and blocks the upload of new packages in unstable. Enable direct binding will definitely solve this problem and is also supposed to be more efficient, as it doesn't have to search for a symbol in all libraries. I don't see a lot of cons, maybe these ones: - sometimes, it seems some programs do need the original linker behaviour but that could be fixed by some other ld options, - we never enabled it so maybe we will uncover some problems, - it works only with Sun ld (we don't use GNU ld somewhere do we ?) To be it seems to have been enabled for opensolaris in the past: https://blogs.oracle.com/rie/entry/direct_binding_now_the_default I am no expert in linking so I welcome any comment on that proposal. But if everybody is ok with it, here is how we could try to enable it to gradually: 1. write a checkpkg test to test if direct binding if properly enabled in a package, 2. enable Direct Binding manually for a reduced set of packages (at least my packages :) ) (we just have to pass "-Bdirect" to SUN ld) 3. wait a bit to see if something unexpected happens :) 3. if it works, enable it by globally adding the option to LINKER_FLAGS 4. enable the checkpkg direct binding test by default so we can catch even packages that don't use LDFLAGS Thanks in advance for your comments, Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Tue Aug 7 23:27:55 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Tue, 7 Aug 2012 23:27:55 +0200 Subject: [csw-maintainers] Openssl migration: status update 2 for group 1 Message-ID: Hi everybody, Here a new status update about the big ssl migration group 1 which is still waiting to come out. Now only 14 packages are now waiting to be updated or dropped, before we can release the already updated packages. We are close !! :) Here are the remaining packages: - *boincclient, boinclibs and boincmanager*: Eric, the maintainer, answered my ping and he will be able to push updated packages around mid-August. - *gnucash: *Peter, have you been able to made some progress on this package ? - *libgnomecups, libgnomeprint, libbonoboui and gnomevfs2: *gnomevfs2 compiles, libbonoboui also. I don't remember the state of the other packages - *libneon26*: pysvn successfully builds now so we are close to dropping this package. - *dovecot:* Jake answered and will rebuild the package against openssl 1.0 soon, - *postfix / courier_imap: *Juraj, have you made some progress on that packages ? - *hobbit: *J?rgen, do you still want to take over this package ? Maybe we can still drop it now while waiting for a new version so that - *libpq:* the following packages still need to be rebuilt so we can drop it: courier_auth, dovecot and pm_dbdpg. Thanks in advance for your answers and feedbacks, Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Wed Aug 8 14:55:27 2012 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 08 Aug 2012 08:55:27 -0400 Subject: [csw-maintainers] Proposal: direct binding for all the opencsw software stack In-Reply-To: References: Message-ID: <1344430486-sup-7367@pinkfloyd.chass.utoronto.ca> Excerpts from Yann Rouillard's message of Tue Aug 07 16:43:08 -0400 2012: Hi Yann, > Linux uses symbol versioning to solve this problem but in the > Solaris world, even if symbol versioning does exist, that is not the > solution to this problem and it turns that a solaris linker feature > called direct binding is a right approach (see the thread > http://lists.opencsw.org/pipermail/maintainers/2012-July/017064.html > and the explanation in oracle manual: > http://docs.oracle.com/cd/E19963-01/html/819-0690/aehzq.html ). I need to read about this, but it sounds like it might be a good approach. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Wed Aug 8 18:29:31 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 08 Aug 2012 18:29:31 +0200 Subject: [csw-maintainers] Openssl migration: status update 2 for group 1 In-Reply-To: (Yann Rouillard's message of "Tue, 7 Aug 2012 23:27:55 +0200") References: Message-ID: Yann Rouillard writes: > - *gnucash: *Peter, have you been able to made some progress on > this package ? I made progress. However I'm stuck in webkit and glib dependencies which are not yet solved by lack of maintainers reaction. The package can be drooped and when I solved all the remaining issues I can resubmit. -- Peter From bwalton at opencsw.org Wed Aug 8 18:33:08 2012 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 08 Aug 2012 12:33:08 -0400 Subject: [csw-maintainers] Openssl migration: status update 2 for group 1 In-Reply-To: References: Message-ID: <1344443574-sup-5603@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Wed Aug 08 12:29:31 -0400 2012: Hi Peter, > The package can be drooped and when I solved all the remaining issues I > can resubmit. I think that sounds like a good compromise. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Wed Aug 8 23:00:36 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 8 Aug 2012 23:00:36 +0200 Subject: [csw-maintainers] OpenCSW buildfarm maintenance on 8. August In-Reply-To: <7BAE0F3A-5880-4538-BF94-D2165487A362@opencsw.org> References: <7BAE0F3A-5880-4538-BF94-D2165487A362@opencsw.org> Message-ID: Hi, Am 06.08.2012 um 15:46 schrieb Dagobert Michelsen : > the OpenCSW buildfarm needs some patching which I plan to do on 8. August. > During that time the farm will not be available for building. Additionally, > the following hosts are affected: > > login.opencsw.org > buildfarm.opencsw.org > ns3csw.opencsw.org > > I will keep you posted when the update is finished. Just a quick heads up: I had some problems with LiveUpgrade but decided to go forward. Unfortunately the update is still running for some zones, I keep you posted. Hopefully I finish up tomorrow. Sorry for the inconvenience -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From dam at opencsw.org Thu Aug 9 19:46:31 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 9 Aug 2012 19:46:31 +0200 Subject: [csw-maintainers] OpenCSW buildfarm maintenance on 8. August In-Reply-To: References: <7BAE0F3A-5880-4538-BF94-D2165487A362@opencsw.org> Message-ID: <82F6049E-C1AF-4012-834E-FFC4B8A8D988@opencsw.org> Hi, Am 08.08.2012 um 23:00 schrieb Dagobert Michelsen : > Just a quick heads up: I had some problems with LiveUpgrade but decided to > go forward. Unfortunately the update is still running for some zones, > I keep you posted. Hopefully I finish up tomorrow. Most of the zones are up and running again. Some updates are still running, so the disks are more loaded than usual at the moment. Apart from that we are running now a fully patched Solaris 10u10. Please let me know if you encounter any issues. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From rupert at opencsw.org Sun Aug 12 12:08:00 2012 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 12 Aug 2012 12:08:00 +0200 Subject: [csw-maintainers] libserf 1.0 --> libserf 1.1 Message-ID: hi, recently a new minor version 1.1 of libserf got released. what would be the procedure to include this in the opencsw package catalog? rupert. From bwalton at opencsw.org Sun Aug 12 21:33:20 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 12 Aug 2012 15:33:20 -0400 Subject: [csw-maintainers] libserf 1.0 --> libserf 1.1 In-Reply-To: References: Message-ID: <1344799943-sup-6669@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Sun Aug 12 06:08:00 -0400 2012: Hi Rupert, > recently a new minor version 1.1 of libserf got released. what would > be the procedure to include this in the opencsw package catalog? You can build and push it like normal as it will have a different name which allows it to coexist with the old version. The dev package will see new build s done against the new version while the old version will only be available for runtime. The only time this would be bad is if it's likely to end in a situation like openssl where multiple versions might be simultaneously used at runtime. In the case of libserf, this isn't likely, but I could be wrong. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert at opencsw.org Thu Aug 16 21:11:13 2012 From: rupert at opencsw.org (rupert THURNER) Date: Thu, 16 Aug 2012 21:11:13 +0200 Subject: [csw-maintainers] libserf, checkpkg errors, e.g. use ssl-0.9.8 instead of ssl-1.0.0 Message-ID: hi, i tried to upgrade libserf to version 1.1.0. the checkpkg errors seem strange, e.g. it suggests to use the old ssl package? # Checkpkg suggests adding the following lines to the GAR recipe: # This is a summary; see above for details. # The following lines define a new package: CSWlibserf1-0 PACKAGES += CSWlibserf1-0 CATALOGNAME_CSWlibserf1-0 = libserf1_0 PKGFILES_CSWlibserf1-0 += $(call baseisadirs,$(libdir),libserf-1\.so\.0\.0\.0) PKGFILES_CSWlibserf1-0 += $(call baseisadirs,$(libdir),libserf-1\.so\.0(\.\d+)*) SPKG_DESC_CSWlibserf1-0 += $(DESCRIPTION), libserf-1.so.0 RUNTIME_DEP_PKGS_CSWlibserf1-1 += CSWlibserf1-0 # The end of CSWlibserf1-0 definition RUNTIME_DEP_PKGS_CSWlibserf1-1 += CSWlibssl0-9-8 If any of the reported errors were false positives, you can override them pasting the lines below to the GAR recipe. CHECKPKG_OVERRIDES_CSWlibserf1-1 += shared-lib-pkgname-mismatch|file=opt/csw/lib/libserf-1.so.0.0.0|soname=libserf-1.so.0|pkgname=CSWlibserf1-1|expected=CSWlibserf1-0 CHECKPKG_OVERRIDES_CSWlibserf1-1 += file-collision|/opt/csw/lib/libserf-1.so.0.0.0|CSWlibserf1-0|CSWlibserf1-1 CHECKPKG_OVERRIDES_CSWlibserf1-1 += file-collision|/opt/csw/lib/libserf-1.so.0|CSWlibserf1-0|CSWlibserf1-1 CHECKPKG_OVERRIDES_CSWlibserf1-1 += missing-dependency|CSWlibssl0-9-8 CHECKPKG_OVERRIDES_CSWlibserf1-1 += surplus-dependency|CSWlibssl1-0-0 Please note that checkpkg isn't suggesting you should simply add these overrides do the Makefile. It only informs what the overrides could look like. You need to understand what are the reported issues about and use your best judgement to decide whether to fix the underlying problems or override them. For more information, scroll up and read the detailed messages. gmake: *** [pkgcheck] Error 2 rupert From bwalton at opencsw.org Thu Aug 16 21:18:02 2012 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 16 Aug 2012 15:18:02 -0400 Subject: [csw-maintainers] libserf, checkpkg errors, e.g. use ssl-0.9.8 instead of ssl-1.0.0 In-Reply-To: References: Message-ID: <1345144646-sup-4509@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Thu Aug 16 15:11:13 -0400 2012: Hi Rupert, > i tried to upgrade libserf to version 1.1.0. the checkpkg errors seem > strange, e.g. it suggests to use the old ssl package? Which system(s) did you build it on? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert at opencsw.org Thu Aug 16 21:18:56 2012 From: rupert at opencsw.org (rupert THURNER) Date: Thu, 16 Aug 2012 21:18:56 +0200 Subject: [csw-maintainers] libserf, checkpkg errors, e.g. use ssl-0.9.8 instead of ssl-1.0.0 In-Reply-To: <1345144646-sup-4509@pinkfloyd.chass.utoronto.ca> References: <1345144646-sup-4509@pinkfloyd.chass.utoronto.ca> Message-ID: oh .. it got cut off. unstable9s, unstable9x. On Thu, Aug 16, 2012 at 9:18 PM, Ben Walton wrote: > Excerpts from rupert THURNER's message of Thu Aug 16 15:11:13 -0400 2012: > > Hi Rupert, > >> i tried to upgrade libserf to version 1.1.0. the checkpkg errors seem >> strange, e.g. it suggests to use the old ssl package? > > Which system(s) did you build it on? > > Thanks > -Ben > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > _______________________________________________ > 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 Thu Aug 16 21:26:47 2012 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 16 Aug 2012 15:26:47 -0400 Subject: [csw-maintainers] libserf, checkpkg errors, e.g. use ssl-0.9.8 instead of ssl-1.0.0 In-Reply-To: References: <1345144646-sup-4509@pinkfloyd.chass.utoronto.ca> Message-ID: <1345144962-sup-6191@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Thu Aug 16 15:18:56 -0400 2012: > oh .. it got cut off. unstable9s, unstable9x. The ssl 1.0 update was only for solaris 10. I'd suggest abandoning solaris 9 for this library unless you want to add the dependency based on a variable and build for both platforms separately. That would look something like: PACKAGING_PLATFORMS = solaris9-i386 solaris9-sparc solaris10-i386 solaris10-sparc RUNTIME_DEP_PKGS_SunOS5.9 = CSWlibssl0-9-8 RUNTIME_DEP_PKGS_SunOS5.10 = CSWlibssl1-0-0 RUNTIME_DEP_PKGS += RUNTIME_DEP_PKGS_$(GAROSREL) (Not checked, it might need a small tweak.) It's up to you whether you go this route or not though. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From yann at pleiades.fr.eu.org Thu Aug 16 22:40:08 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Thu, 16 Aug 2012 22:40:08 +0200 Subject: [csw-maintainers] New checkpkg test: detect useless libraries links Message-ID: Hi everyone, I am on the verge on committing the addition of a new check in checkpkg which is likely to fire some new warnings in a lot of builds, so I am posting the and requesting some comments before proceeding. This new check will trigger an error each time a binary is linked against libraries it doesn't really use. I worked on this check because I discovered that some programs were linked against libssl although they didn't really use them, which complicates even more the upgrade process. But avoiding useless libraries linking has other advantages: - it reduces the number of dependancies to install. For exemple, I was able to remove three dependencies from ssh client, it was dependencies on libraries required by the server and not by the client. - it allows to detect some build errors. For exemple, imapproxy was compiled against libwrap but there was an error in the build system and the libwrap code was not enabled although imapproxy was linked against libwrap. - it reduces the number of reverse dependencies impacted when a library is upgraded and also when it is removed. This situation seems to happens a lot either because: 1. There is a problem in a configure script which incorrectly add useless libraries to the linker flags. For exemple, some programs tries to link with more base libraries that necessary to be on the safe side, or they tries to link with libraries that are in fact only needed by their dependencies. 2. There is an error in the pkg-config configuration file of a dependency which incorrectly requests to link against a larger set of libraries that needed, sometimes becauses no difference is made between static case and dynamic case. That was for exemple a problem with neon, the neon-config tool incorrectly says that every programs linked against neon should also be linked against libssl. 3. There are a bunch of binaries provided in a package and the build system links all of them against the same set of libraries althought some of them need only to be linked to only a subset of these libraries. The proper way to fix cases 1 and 2 is a fix in the configure script or pkg-config script. The case 3 is harder to fix as build system seldomly make distinction between the link options of binaries (and this is not a big problem for Opencsw except if the package is split). But there is a also direct and easy way to solve all these cases: just add "-z ignore" to the linker flags and ld will automatically ignore "-llibrary" option when no symbol of the library is used. As soon as I commit the patch, a lot of build will trigger this new checkpkg error so I am thinking about first trying to promote the "-z ignore" option as a default linker flags for all opencsw builds (following the same path I proposed for "-B direct" http://lists.opencsw.org/pipermail/maintainers/2012-August/017113.html ). I welcome any comment on that. FYI, the new checkpkg error is documented in the wiki: http://wiki.opencsw.org/checkpkg-error-tags#toc50 the full patch is attached and you'll find below the patch content without the tests for comments. Maciej already reviewed it and gave me useful feedback (thanks to him). Thanks in advance for your feedbacks, Yann Index: lib/python/dependency_checks.py =================================================================== --- lib/python/dependency_checks.py (revision 18898) +++ lib/python/dependency_checks.py (working copy) @@ -39,6 +39,12 @@ PREFERRED_DIRECTORY_PROVIDERS = set([u"CSWcommon"]) +BASE_SOLARIS_LIBRARIES = ( + "libsocket.so.1", "libnsl.so.1", "libdl.so.1", "librt.so.1", "libresolv.so.2", "libpthread.so.1", + # linked by default with C++, see "Default C++ Libraries" in Solaris Studio C++ User'sGuide + "libCstd.so.1", "libCrun.so.1", "libm.so.1", "libm.so.2", "libw.so.1", "libcx.so.1", "libc.so.1", "libC.so.3", "libC.so.5" +) + def ProcessSoname( ldd_emulator, soname, path_and_pkg_by_basename, binary_info, isalist, binary_path, logger, @@ -147,6 +153,20 @@ error_mgr, pkgname, messenger) orphan_sonames.extend(orphan_sonames_tmp) + + ldd_info = pkg_data['ldd_info'][binary_info["path"]] + for ldd_response in ldd_info: + if ldd_response['state'] == 'soname-unused' and ldd_response['soname'] not in BASE_SOLARIS_LIBRARIES: + messenger.Message( + "Binary %s links to library %s but doesn't seem to use any of its symbols. " + "It usually happens because superfluous libraries were added to the linker options, " + "either because of the configure script itself or because of the \"pkg-config --libs\"" + " output of one the dependency." + % ("/" + binary_info["path"], ldd_response['soname'])) + error_mgr.ReportError( + pkgname, "soname-unused", + "%s is needed by %s but never used" % (ldd_response['soname'], "/" + binary_info["path"])) + orphan_sonames = set(orphan_sonames) for soname, binary_path in orphan_sonames: if soname not in ALLOWED_ORPHAN_SONAMES: Index: lib/python/package_stats.py =================================================================== --- lib/python/package_stats.py (revision 18898) +++ lib/python/package_stats.py (working copy) @@ -208,6 +208,7 @@ "basic_stats": basic_stats, "files_metadata": dir_pkg.GetFilesMetadata(), "mtime": self.GetMtime(), + "ldd_info": dir_pkg.GetLddMinusRlines(), } self.SaveStats(pkg_stats) logging.debug("Statistics of %s have been collected.", repr(dir_pkg.pkgname)) Index: lib/python/inspective_package.py =================================================================== --- lib/python/inspective_package.py (revision 18898) +++ lib/python/inspective_package.py (working copy) @@ -231,15 +231,14 @@ def GetLddMinusRlines(self): """Returns ldd -r output.""" - dir_pkg = self.GetInspectivePkg() - binaries = dir_pkg.ListBinaries() + binaries = self.ListBinaries() ldd_output = {} for binary in binaries: - binary_abspath = os.path.join(dir_pkg.directory, "root", binary) + binary_abspath = os.path.join(self.directory, "root", binary) # this could be potentially moved into the DirectoryFormatPackage class. # ldd needs the binary to be executable os.chmod(binary_abspath, 0755) - args = ["ldd", "-r", binary_abspath] + args = ["ldd", "-Ur", binary_abspath] ldd_proc = subprocess.Popen( args, stdout=subprocess.PIPE, @@ -250,7 +249,9 @@ logging.error("%s returned an error: %s", args, stderr) ldd_info = [] for line in stdout.splitlines(): - ldd_info.append(self._ParseLddDashRline(line)) + result = self._ParseLddDashRline(line, binary_abspath) + if result: + ldd_info.append(result) ldd_output[binary] = ldd_info return ldd_output @@ -263,7 +264,7 @@ sym = { 'address': fields[0], 'type': fields[1], 'name': fields[2] } return sym - def _ParseLddDashRline(self, line): + def _ParseLddDashRline(self, line, binary=None): found_re = r"^\t(?P\S+)\s+=>\s+(?P\S+)" symbol_not_found_re = (r"^\tsymbol not found:\s(?P\S+)\s+" r"\((?P\S+)\)") @@ -280,12 +281,17 @@ r'file (?P\S+) size=(?P0x\w+)\)$') sizes_one_used = (r'^\t\t(?P\S+) size used; ' r'possible insufficient data copied$') - common_re = (r"(%s|%s|%s|%s|%s|%s|%s|%s)" - % (found_re, symbol_not_found_re, only_so, version_so, - stv_protected, sizes_differ, sizes_info, sizes_one_used)) + unreferenced_object = (r'^\s*unreferenced object=(?P.*); unused dependency of (?P.*)$') + unused_object = (r'^\s*unused object=.*$') + unused_search_path = (r'^\s*unused search path=.* \(RUNPATH/RPATH from file .*\)$') + blank_line = (r'^\s*$') + common_re = (r"(%s|%s|%s|%s|%s|%s|%s|%s|%s|%s|%s|%s)" + % (found_re, symbol_not_found_re, only_so, version_so, stv_protected, sizes_differ, sizes_info, + sizes_one_used, unreferenced_object, unused_object, unused_search_path, blank_line)) m = re.match(common_re, line) - response = {} + response = None if m: + response = {} d = m.groupdict() if "soname" in d and d["soname"]: # it was found @@ -298,6 +304,11 @@ response["soname"] = None response["path"] = d["path_not_found"] response["symbol"] = d["symbol"] + elif "binary" in d and d["binary"] and binary == d["binary"]: + response["state"] = "soname-unused" + response["soname"] = os.path.basename(d["object"]) + response["path"] = None + response["symbol"] = None elif d["path_only"]: response["state"] = "OK" response["soname"] = None @@ -328,12 +339,11 @@ response["soname"] = None response["path"] = "%s" % (d["sizediffused_file"]) response["symbol"] = None - else: - raise StdoutSyntaxError("Could not parse %s with %s" - % (repr(line), common_re)) + else: - raise StdoutSyntaxError("Could not parse %s with %s" - % (repr(line), common_re)) + raise package.StdoutSyntaxError("Could not parse %s with %s" + % (repr(line), common_re)) + return response def GetDependencies(self): Index: lib/python/package.py =================================================================== --- lib/python/package.py (revision 18898) +++ lib/python/package.py (working copy) @@ -42,6 +42,8 @@ class PackageError(Error): pass +class StdoutSyntaxError(Error): + pass class CswSrv4File(shell.ShellMixin, object): """Represents a package in the srv4 format (pkg).""" -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: enable_ldd_r.patch Type: application/octet-stream Size: 31539 bytes Desc: not available URL: From rupert at opencsw.org Thu Aug 16 23:34:42 2012 From: rupert at opencsw.org (rupert THURNER) Date: Thu, 16 Aug 2012 23:34:42 +0200 Subject: [csw-maintainers] libserf, checkpkg errors, e.g. use ssl-0.9.8 instead of ssl-1.0.0 In-Reply-To: <1345144962-sup-6191@pinkfloyd.chass.utoronto.ca> References: <1345144646-sup-4509@pinkfloyd.chass.utoronto.ca> <1345144962-sup-6191@pinkfloyd.chass.utoronto.ca> Message-ID: you are right. subverison is only for solaris 10, and its fine for serf as well. on unstable10s it gives: # Checkpkg suggests adding the following lines to the GAR recipe: # This is a summary; see above for details. # The following lines define a new package: CSWlibserf1-0 PACKAGES += CSWlibserf1-0 CATALOGNAME_CSWlibserf1-0 = libserf1_0 PKGFILES_CSWlibserf1-0 += $(call baseisadirs,$(libdir),libserf-1\.so\.0\.0\.0) PKGFILES_CSWlibserf1-0 += $(call baseisadirs,$(libdir),libserf-1\.so\.0(\.\d+)*) SPKG_DESC_CSWlibserf1-0 += $(DESCRIPTION), libserf-1.so.0 RUNTIME_DEP_PKGS_CSWlibserf1-1 += CSWlibserf1-0 # The end of CSWlibserf1-0 definition why checkpkg thinks there should be a reference from 1.1 to 1.0? On Thu, Aug 16, 2012 at 9:26 PM, Ben Walton wrote: > Excerpts from rupert THURNER's message of Thu Aug 16 15:18:56 -0400 2012: > >> oh .. it got cut off. unstable9s, unstable9x. > > The ssl 1.0 update was only for solaris 10. I'd suggest abandoning > solaris 9 for this library unless you want to add the dependency based > on a variable and build for both platforms separately. > > That would look something like: > > PACKAGING_PLATFORMS = solaris9-i386 solaris9-sparc solaris10-i386 solaris10-sparc > > RUNTIME_DEP_PKGS_SunOS5.9 = CSWlibssl0-9-8 > RUNTIME_DEP_PKGS_SunOS5.10 = CSWlibssl1-0-0 > > RUNTIME_DEP_PKGS += RUNTIME_DEP_PKGS_$(GAROSREL) > > (Not checked, it might need a small tweak.) > > It's up to you whether you go this route or not though. > > Thanks > -Ben > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > _______________________________________________ > 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 Aug 17 00:52:16 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 16 Aug 2012 23:52:16 +0100 Subject: [csw-maintainers] libserf, checkpkg errors, e.g. use ssl-0.9.8 instead of ssl-1.0.0 In-Reply-To: References: <1345144646-sup-4509@pinkfloyd.chass.utoronto.ca> <1345144962-sup-6191@pinkfloyd.chass.utoronto.ca> Message-ID: 2012/8/16 rupert THURNER > you are right. subverison is only for solaris 10, and its fine for > serf as well. on unstable10s it gives: > > # Checkpkg suggests adding the following lines to the GAR recipe: > # This is a summary; see above for details. > This line right here ? You need to scroll up and read. > # The following lines define a new package: CSWlibserf1-0 > PACKAGES += CSWlibserf1-0 > CATALOGNAME_CSWlibserf1-0 = libserf1_0 > PKGFILES_CSWlibserf1-0 += $(call > baseisadirs,$(libdir),libserf-1\.so\.0\.0\.0) > PKGFILES_CSWlibserf1-0 += $(call > baseisadirs,$(libdir),libserf-1\.so\.0(\.\d+)*) > SPKG_DESC_CSWlibserf1-0 += $(DESCRIPTION), libserf-1.so.0 > RUNTIME_DEP_PKGS_CSWlibserf1-1 += CSWlibserf1-0 > # The end of CSWlibserf1-0 definition > > why checkpkg thinks there should be a reference from 1.1 to 1.0? > See the comment above. > > > On Thu, Aug 16, 2012 at 9:26 PM, Ben Walton wrote: > > Excerpts from rupert THURNER's message of Thu Aug 16 15:18:56 -0400 2012: > > > >> oh .. it got cut off. unstable9s, unstable9x. > > > > The ssl 1.0 update was only for solaris 10. I'd suggest abandoning > > solaris 9 for this library unless you want to add the dependency based > > on a variable and build for both platforms separately. > > > > That would look something like: > > > > PACKAGING_PLATFORMS = solaris9-i386 solaris9-sparc solaris10-i386 > solaris10-sparc > > > > RUNTIME_DEP_PKGS_SunOS5.9 = CSWlibssl0-9-8 > > RUNTIME_DEP_PKGS_SunOS5.10 = CSWlibssl1-0-0 > > > > RUNTIME_DEP_PKGS += RUNTIME_DEP_PKGS_$(GAROSREL) > > > > (Not checked, it might need a small tweak.) > > > > It's up to you whether you go this route or not though. > > > > Thanks > > -Ben > > -- > > Ben Walton > > Systems Programmer - CHASS > > University of Toronto > > C:416.407.5610 | W:416.978.4302 > > > > _______________________________________________ > > 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 rupert at opencsw.org Fri Aug 17 04:54:17 2012 From: rupert at opencsw.org (rupert THURNER) Date: Fri, 17 Aug 2012 04:54:17 +0200 Subject: [csw-maintainers] libserf, checkpkg errors, e.g. use ssl-0.9.8 instead of ssl-1.0.0 In-Reply-To: References: <1345144646-sup-4509@pinkfloyd.chass.utoronto.ca> <1345144962-sup-6191@pinkfloyd.chass.utoronto.ca> Message-ID: On Fri, Aug 17, 2012 at 12:52 AM, Maciej (Matchek) Blizi?ski wrote: > 2012/8/16 rupert THURNER >> >> you are right. subverison is only for solaris 10, and its fine for >> serf as well. on unstable10s it gives: >> >> # Checkpkg suggests adding the following lines to the GAR recipe: >> # This is a summary; see above for details. > > > This line right here ? > > You need to scroll up and read. |^M 63% |##################################################### |^M 65% |###################################################### |^M 66% |####################################################### |^M 67% |######################################################## |^M 68% |######################################################### |^M 69% |####################################################### ### |^M 70% |##################################################### ###### |^M 72% |################################################### ######### |^M 73% |################################################# ############ |^M 74% |############################################### ############### |^M 75% |############################################# ################## |^M 76% |########################################### ##################### |^M 77% |######################################### ######################## |^M 79% |####################################### ########################### |^M 80% |##################################### ############################## |^M 81% |################################### ################################# |^M 82% |################################# #################################### |^M 83% |############################### ####################################### |^M 84% |############################# ########################################## |^M 86% |########################### ############################################# |^M 87% |######################### ################################################ |^M 88% |####################### ################################################### |^M 89% |##################### ###################################################### |^M 90% |################### ######################################################### |^M 91% |################# ############################################################ |^M 93% |############### ############################################################### |^M 94% |############# ################################################################## |^M 95% |########### ##################################################################### |^M 96% |######### ######################################################################## |^M 97% |####### ########################################################################### |^M 98% |################################################################################### |^M100% |####################################################################################| INFO:root:Tasting them all at once... INFO:root:Stuffing the candies under the pillow... 0% | |^M 33% |############################ |^MWARNING:root:Not saving an error for CSWlibserf1-0. WARNING:root:Not saving an error for CSWlibserf1-0. 66% |######################################################## |^M100% |####################################################################################| CSWlibserf1-1: CSWlibserf1-0: * This shared library (opt/csw/lib/libserf-1.so.0.0.0) is in a directory indicating that it is likely to be linked to by other programs. If this is the case, the library is best packaged separately, in a package with a library-specific name. Examples of such names include: ['CSWlibserf1-0']. If this library is not meant to be linked to by other packages, it's best moved to a 'private' directory. For example, instead of /opt/csw/lib/foo.so, try /opt/csw/lib/projectname/foo.so. More information: http://wiki.opencsw.org/checkpkg-error-tags # Checkpkg suggests adding the following lines to the GAR recipe: # This is a summary; see above for details. # The following lines define a new package: CSWlibserf1-0 PACKAGES += CSWlibserf1-0 CATALOGNAME_CSWlibserf1-0 = libserf1_0 From maciej at opencsw.org Fri Aug 17 08:09:22 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 17 Aug 2012 07:09:22 +0100 Subject: [csw-maintainers] libserf, checkpkg errors, e.g. use ssl-0.9.8 instead of ssl-1.0.0 In-Reply-To: References: <1345144646-sup-4509@pinkfloyd.chass.utoronto.ca> <1345144962-sup-6191@pinkfloyd.chass.utoronto.ca> Message-ID: 2012/8/17 rupert THURNER > > On Fri, Aug 17, 2012 at 12:52 AM, Maciej (Matchek) Blizi?ski > wrote: > > 2012/8/16 rupert THURNER > >> > >> you are right. subverison is only for solaris 10, and its fine for > >> serf as well. on unstable10s it gives: > >> > >> # Checkpkg suggests adding the following lines to the GAR recipe: > >> # This is a summary; see above for details. > > > > > > This line right here ? > > > > You need to scroll up and read. > > |^M 63% > |##################################################### > |^M 65% > |###################################################### > |^M 66% > |####################################################### > |^M 67% > |######################################################## > |^M 68% > |######################################################### > |^M 69% > |####################################################### > ### |^M 70% > |##################################################### > ###### |^M 72% > |################################################### > ######### |^M 73% > |################################################# > ############ |^M 74% > |############################################### > ############### |^M 75% > |############################################# > ################## |^M 76% > |########################################### > ##################### |^M 77% > |######################################### > ######################## |^M 79% > |####################################### > ########################### |^M 80% > |##################################### > ############################## |^M 81% > |################################### > ################################# |^M 82% > |################################# > #################################### |^M 83% > |############################### > ####################################### |^M 84% > |############################# > ########################################## |^M 86% > |########################### > ############################################# |^M 87% > |######################### > ################################################ |^M 88% > |####################### > ################################################### |^M 89% > |##################### > ###################################################### |^M 90% > |################### > ######################################################### |^M > 91% |################# > ############################################################ |^M > 93% |############### > ############################################################### > |^M 94% |############# > ################################################################## > |^M 95% |########### > ##################################################################### > |^M 96% |######### > ######################################################################## > |^M 97% |####### > > > ########################################################################### > |^M 98% > |################################################################################### > |^M100% > |####################################################################################| Haha, nice ascii art! > INFO:root:Tasting them all at once... > INFO:root:Stuffing the candies under the pillow... > 0% | > |^M 33% |############################ > |^MWARNING:root:Not saving an > error for CSWlibserf1-0. > WARNING:root:Not saving an error for CSWlibserf1-0. > 66% |######################################################## > |^M100% > > |####################################################################################| > CSWlibserf1-1: > CSWlibserf1-0: > * This shared library (opt/csw/lib/libserf-1.so.0.0.0) is in a directory > indicating that it is likely to be linked to by other programs. If > this is > the case, the library is best packaged separately, in a package with a > library-specific name. Examples of such names include: > ['CSWlibserf1-0']. > If this library is not meant to be linked to by other packages, it's > best > moved to a 'private' directory. For example, instead of > /opt/csw/lib/foo.so, try /opt/csw/lib/projectname/foo.so. More > information: > http://wiki.opencsw.org/checkpkg-error-tags > > # Checkpkg suggests adding the following lines to the GAR recipe: > # This is a summary; see above for details. > # The following lines define a new package: CSWlibserf1-0 > PACKAGES += CSWlibserf1-0 > CATALOGNAME_CSWlibserf1-0 = libserf1_0 I think this report above is missing something. I re-ran checkpkg myself, and this is the complete output: maciej at login [login]:~/src/opencsw/pkg/libserf/trunk > ~/src/opencsw-git/gar/v2/bin/checkpkg --os-releases SunOS5.10 --architecture sparc --catalog-release unstable 2416e1115e2cd3d721419458dbfd0d18 f5a59f7569fbb18edb717beeb1adc9fd INFO:root:Unwrapping candies... 100% |################################################################################################################################################| INFO:root:Tasting candies one by one... 100% |################################################################################################################################################| INFO:root:Tasting them all at once... INFO:root:Stuffing the candies under the pillow... WARNING:root:Not saving an error for CSWlibserf1-0.### | WARNING:root:Not saving an error for CSWlibserf1-0. 100% |################################################################################################################################################| CSWlibserf1-1: CSWlibserf1-0: * This shared library (opt/csw/lib/libserf-1.so.0.0.0) is in a directory indicating that it is likely to be linked to by other programs. If this is the case, the library is best packaged separately, in a package with a library-specific name. Examples of such names include: ['CSWlibserf1-0']. If this library is not meant to be linked to by other packages, it's best moved to a 'private' directory. For example, instead of /opt/csw/lib/foo.so, try /opt/csw/lib/projectname/foo.so. More information: http://wiki.opencsw.org/checkpkg-error-tags # Checkpkg suggests adding the following lines to the GAR recipe: # This is a summary; see above for details. # The following lines define a new package: CSWlibserf1-0 PACKAGES += CSWlibserf1-0 CATALOGNAME_CSWlibserf1-0 = libserf1_0 PKGFILES_CSWlibserf1-0 += $(call baseisadirs,$(libdir),libserf-1\.so\.0\.0\.0) PKGFILES_CSWlibserf1-0 += $(call baseisadirs,$(libdir),libserf-1\.so\.0(\.\d+)*) SPKG_DESC_CSWlibserf1-0 += $(DESCRIPTION), libserf-1.so.0 RUNTIME_DEP_PKGS_CSWlibserf1-1 += CSWlibserf1-0 # The end of CSWlibserf1-0 definition If any of the reported errors were false positives, you can override them pasting the lines below to the GAR recipe. CHECKPKG_OVERRIDES_CSWlibserf1-1 += file-collision|/opt/csw/lib/libserf-1.so.0|CSWlibserf1-0|CSWlibserf1-1 CHECKPKG_OVERRIDES_CSWlibserf1-1 += file-collision|/opt/csw/lib/libserf-1.so.0.0.0|CSWlibserf1-0|CSWlibserf1-1 CHECKPKG_OVERRIDES_CSWlibserf1-1 += shared-lib-pkgname-mismatch|file=opt/csw/lib/libserf-1.so.0.0.0|soname=libserf-1.so.0|pkgname=CSWlibserf1-1|expected=CSWlibserf1-0 Please note that checkpkg isn't suggesting you should simply add these overrides to the Makefile. It only informs what the overrides could look like. You need to understand what are the reported issues about and use your best judgement to decide whether to fix the underlying problems or override them. For more information, scroll up and read the detailed messages. To easily inspect packages you've just built, visit: http://buildfarm.opencsw.org/pkgdb/srv4/ So what are we seeing here? There are two error tags: file-collision and shared-lib-pkgname-mismatch. There are two collisions, one is that file /opt/csw/lib/libserf-1.so.0 is present in two packages: CSWlibserf1-0 and CSWlibserf1-1. The second one is similar, involving the /opt/csw/lib/libserf-1.so.0.0.0 file. The CSWlibserf1-0 pkgname should, in a deterministic fashion (as much as possible), depend on the file inside the package. If the file is named libserf-1.so.0, the corresponding package name should be CSWlibserf1-0. If we check the catalog content, this is what's in the catalog right now. The other package, CSWlibserf1-1 is the new package being built. CSWlibserf1-1 would suggest that the soname has changed to something like libserf-1.so.1. But if we look at the file, we see that the soname stayed the same, so there's a mismatch between the package name and the soname. And this is what the second error tag tells us: shared-lib-pkgname-mismatch file=opt/csw/lib/libserf-1.so.0.0.0 soname=libserf-1.so.0 pkgname=CSWlibserf1-1 expected=CSWlibserf1-0 The /opt/csw/lib/libserf-1.so.0.0.0 file has the soname of libserf-1.so.0 and it's expected to be in CSWlibserf1-0, but it's currently in CSWlibserf1-1. Above that we also see the suggested lines to create the CSWlibserf1-0 package. Is the situation more clear now? Maciej From jh at opencsw.org Fri Aug 17 12:58:00 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Fri, 17 Aug 2012 12:58:00 +0200 Subject: [csw-maintainers] openssh client binds to a newest libc.so.1 Message-ID: <502E23B8.6050500@opencsw.org> Hi, the newest CSWosshclient which was build after buildfarm update binds to a to new libc.so.1. Version SUNW_1.22.7 which is Solaris 10 Update 10 if I'm not wrong. The function used should be avoided an rebuild to have it run on older Kernels. Version VERSION: 6.0p1,REV=2012.05.17 does not suffer from this: ldd -v /opt/csw/bin/ssh |grep libc |grep 22 libc.so.1 (SUNW_1.22) => /lib/libc.so.1 libc.so.1 (SUNW_1.22) => /lib/libc.so.1 libc.so.1 (SUNW_1.22.2) => /lib/libc.so.1 libc.so.1 (SUNW_1.22) => /lib/libc.so.1 libc.so.1 (SUNW_1.22.1) => /lib/libc.so.1 libc.so.1 (SUNW_1.22.2) => /lib/libc.so.1 pvs -s /usr/lib/libc.so.1 |more SUNW_1.23: SUNW_1.22.7: vasprintf; smt_pause; fdatasync; asprintf; SUNW_1.22.6: utimensat; futimens; SUNW_1.22.5: getpagesizes2; What you can do see the samba package: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/samba/trunk/Makefile#L326 Dago did wanted to hack up a mapfile so this won't happen. Don't know the state of that. So this is a workaround. Greetings Jan From yann at pleiades.fr.eu.org Fri Aug 17 14:52:56 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Fri, 17 Aug 2012 14:52:56 +0200 Subject: [csw-maintainers] openssh client binds to a newest libc.so.1 In-Reply-To: <502E23B8.6050500@opencsw.org> References: <502E23B8.6050500@opencsw.org> Message-ID: Hi Jan, According to pvs, ssh is linked against SUNW_1.22 and SUNW_1.22.7 root at solaris11-vm:~# pvs /opt/csw/bin/ssh [...] libc.so.1 (SUNW_1.22, SUNWprivate_1.1); How do you see the 1.22.7 ? What is the interface version of the first Solaris 10 release ? Yann 2012/8/17 Jan Holzhueter > Hi, > the newest CSWosshclient which was build after buildfarm update binds to > a to new libc.so.1. > > Version SUNW_1.22.7 which is Solaris 10 Update 10 if I'm not wrong. > > The function used should be avoided an rebuild to have it run on older > Kernels. > > Version VERSION: 6.0p1,REV=2012.05.17 does not suffer from this: > > ldd -v /opt/csw/bin/ssh |grep libc |grep 22 > libc.so.1 (SUNW_1.22) => /lib/libc.so.1 > libc.so.1 (SUNW_1.22) => /lib/libc.so.1 > libc.so.1 (SUNW_1.22.2) => /lib/libc.so.1 > libc.so.1 (SUNW_1.22) => /lib/libc.so.1 > libc.so.1 (SUNW_1.22.1) => /lib/libc.so.1 > libc.so.1 (SUNW_1.22.2) => /lib/libc.so.1 > > > pvs -s /usr/lib/libc.so.1 |more > > SUNW_1.23: > SUNW_1.22.7: > vasprintf; > smt_pause; > fdatasync; > asprintf; > SUNW_1.22.6: > utimensat; > futimens; > SUNW_1.22.5: > getpagesizes2; > > What you can do see the samba package: > > > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/samba/trunk/Makefile#L326 > > > Dago did wanted to hack up a mapfile so this won't happen. > Don't know the state of that. So this is a workaround. > > > 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 Fri Aug 17 14:55:10 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Fri, 17 Aug 2012 14:55:10 +0200 Subject: [csw-maintainers] openssh client binds to a newest libc.so.1 In-Reply-To: References: <502E23B8.6050500@opencsw.org> Message-ID: <502E3F2E.8000401@opencsw.org> Hi, was reported on irc: [ 12:53:11 ] [ bulletmark ] http://pastebin.com/yL350GtK is the ld -v output [ 12:55:56 ] [ bulletmark ] http://pastebin.com/Bp3iGtLR is the pkginfo -l CSWosshclient output Greetings Jan Am 17.08.12 14:52, schrieb Yann Rouillard: > Hi Jan, > > According to pvs, ssh is linked against SUNW_1.22 and SUNW_1.22.7 > > root at solaris11-vm:~# pvs /opt/csw/bin/ssh > [...] > libc.so.1 (SUNW_1.22, SUNWprivate_1.1); > > How do you see the 1.22.7 ? > > What is the interface version of the first Solaris 10 release ? > > Yann > > > 2012/8/17 Jan Holzhueter > > > Hi, > the newest CSWosshclient which was build after buildfarm update binds to > a to new libc.so.1. > > Version SUNW_1.22.7 which is Solaris 10 Update 10 if I'm not wrong. > > The function used should be avoided an rebuild to have it run on older > Kernels. > > Version VERSION: 6.0p1,REV=2012.05.17 does not suffer from this: > > ldd -v /opt/csw/bin/ssh |grep libc |grep 22 > libc.so.1 (SUNW_1.22) => /lib/libc.so.1 > libc.so.1 (SUNW_1.22) => /lib/libc.so.1 > libc.so.1 (SUNW_1.22.2) => /lib/libc.so.1 > libc.so.1 (SUNW_1.22) => /lib/libc.so.1 > libc.so.1 (SUNW_1.22.1) => /lib/libc.so.1 > libc.so.1 (SUNW_1.22.2) => /lib/libc.so.1 > > > pvs -s /usr/lib/libc.so.1 |more > > SUNW_1.23: > SUNW_1.22.7: > vasprintf; > smt_pause; > fdatasync; > asprintf; > SUNW_1.22.6: > utimensat; > futimens; > SUNW_1.22.5: > getpagesizes2; > > What you can do see the samba package: > > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/samba/trunk/Makefile#L326 > > > Dago did wanted to hack up a mapfile so this won't happen. > Don't know the state of that. So this is a workaround. > > > Greetings > Jan > > > > > _______________________________________________ > 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. ::. > From dam at opencsw.org Fri Aug 17 16:49:16 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 17 Aug 2012 16:49:16 +0200 Subject: [csw-maintainers] SummperCamp 2012 Message-ID: <03D6D21B-9B01-4133-9C6E-E71B3C74C742@opencsw.org> Hi, for the upcoming Summercamp there are two possible locations: - Zurich (hosted by Ihsan, Swisscom) - Munich (Lengries, same location where we were in winter 2009) http://wiki.opencsw.org/wintercamp-2009 I would like to start a discussion about the location and also about the timing, the Doodle poll is open: http://doodle.com/avkirhi68hzptwuu Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From yann at pleiades.fr.eu.org Sat Aug 18 10:16:53 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sat, 18 Aug 2012 10:16:53 +0200 Subject: [csw-maintainers] openssh client binds to a newest libc.so.1 In-Reply-To: <502E3F2E.8000401@opencsw.org> References: <502E23B8.6050500@opencsw.org> <502E3F2E.8000401@opencsw.org> Message-ID: Hi Jan, Ok this problem happened only on sparc (for now). I build a new package linked against an older interface of libc.so but it would be better to agree on the maximum version. Does someone know the interface version available on the first release of Solaris 10 ? I used the following mapfile: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/openssh/trunk/files/map.openssh?rev=19006 Changes are here: http://sourceforge.net/apps/trac/gar/changeset/18999/csw/mgar/pkg/openssh/trunk I suppose all of our packages could suffer from the same problem so we should probably enable some kind of global mapfile. Yann 2012/8/17 Jan Holzhueter > Hi, > was reported on irc: > > [ 12:53:11 ] [ bulletmark ] http://pastebin.com/yL350GtK is the ld -v > output > [ 12:55:56 ] [ bulletmark ] http://pastebin.com/Bp3iGtLR is the > pkginfo -l CSWosshclient output > > Greetings > Jan > > > Am 17.08.12 14:52, schrieb Yann Rouillard: > > Hi Jan, > > > > According to pvs, ssh is linked against SUNW_1.22 and SUNW_1.22.7 > > > > root at solaris11-vm:~# pvs /opt/csw/bin/ssh > > [...] > > libc.so.1 (SUNW_1.22, SUNWprivate_1.1); > > > > How do you see the 1.22.7 ? > > > > What is the interface version of the first Solaris 10 release ? > > > > Yann > > > > > > 2012/8/17 Jan Holzhueter > > > > > Hi, > > the newest CSWosshclient which was build after buildfarm update > binds to > > a to new libc.so.1. > > > > Version SUNW_1.22.7 which is Solaris 10 Update 10 if I'm not wrong. > > > > The function used should be avoided an rebuild to have it run on > older > > Kernels. > > > > Version VERSION: 6.0p1,REV=2012.05.17 does not suffer from this: > > > > ldd -v /opt/csw/bin/ssh |grep libc |grep 22 > > libc.so.1 (SUNW_1.22) => /lib/libc.so.1 > > libc.so.1 (SUNW_1.22) => /lib/libc.so.1 > > libc.so.1 (SUNW_1.22.2) => /lib/libc.so.1 > > libc.so.1 (SUNW_1.22) => /lib/libc.so.1 > > libc.so.1 (SUNW_1.22.1) => /lib/libc.so.1 > > libc.so.1 (SUNW_1.22.2) => /lib/libc.so.1 > > > > > > pvs -s /usr/lib/libc.so.1 |more > > > > SUNW_1.23: > > SUNW_1.22.7: > > vasprintf; > > smt_pause; > > fdatasync; > > asprintf; > > SUNW_1.22.6: > > utimensat; > > futimens; > > SUNW_1.22.5: > > getpagesizes2; > > > > What you can do see the samba package: > > > > > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/samba/trunk/Makefile#L326 > > > > > > Dago did wanted to hack up a mapfile so this won't happen. > > Don't know the state of that. So this is a workaround. > > > > > > Greetings > > Jan > > > > > > > > > > _______________________________________________ > > 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. ::. > > > > _______________________________________________ > 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 Sat Aug 18 11:52:55 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Sat, 18 Aug 2012 11:52:55 +0200 Subject: [csw-maintainers] openssh client binds to a newest libc.so.1 In-Reply-To: References: <502E23B8.6050500@opencsw.org> <502E3F2E.8000401@opencsw.org> Message-ID: <502F65F7.6030302@opencsw.org> Hi, Am 18.08.12 10:16, schrieb Yann Rouillard: > Hi Jan, > > Ok this problem happened only on sparc (for now). > I build a new package linked against an older interface of libc.so but > it would be better to agree on the maximum version. > Does someone know the interface version available on the first release > of Solaris 10 ? > > I used the following > mapfile: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/openssh/trunk/files/map.openssh?rev=19006 > Changes are > here: http://sourceforge.net/apps/trac/gar/changeset/18999/csw/mgar/pkg/openssh/trunk > > I suppose all of our packages could suffer from the same problem so we > should probably enable some kind of global mapfile. yes we should use a global mapfile. Dago did start to hack one a while back I don't know the state though. I don't think we should go back all the way to Solaris 10 GA but use something like Update 5 as the baseline. I do suggest this do to libresolv2 having it's last bump at update 5. http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libresolv2/common/mapfile-vers The libc mapfile is here: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/mapfile-vers The commends are not so good be the one you choose is probably ok. 2.2.7 is missing do to beeing closed source. So I would go back on libc to version 2.2.3 or 2.2.2. Going back to Solaris 10 GA interface I don't know if that would not brake some builds. Or we build a dynamic map file where we could define the Version in the Makefile to bump it up if it does not build. Greetings Jan From pfelecan at opencsw.org Mon Aug 20 14:35:03 2012 From: pfelecan at opencsw.org (pfelecan at opencsw.org) Date: Mon, 20 Aug 2012 14:35:03 +0200 (CEST) Subject: [csw-maintainers] linker version on unstable10* Message-ID: <4d0a448ac64d487bb554248b3e472452.squirrel@mail.opencsw.org> I started to have issues with the Solaris provided linker some times ago. Lately I stumbled again on a different behavior of the public build farm and the one that I'm using privately. On the public build-farm the linker version is: ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.500 On my build-farm the linker version is: ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.1505 Their behavior is different, with the oldest version I have undefined symbols when with the newer one those symbols are, rightly, found and consequently defined. I analyzed the context/environment and everything is similar on both platforms with the linkers exceptions. Even the debugging options are different, e.g., -Doutput=file is not supported. I have a test case, quite convoluted, that I can provide if somebody bother to assess. Remark 1: on my build farm, Solaris release is 10 8/11 s10x_u10wos_17b X86 Remark 2: the same issues raises on the SPARC based systems. TIA From dam at opencsw.org Mon Aug 20 17:58:01 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 20 Aug 2012 17:58:01 +0200 Subject: [csw-maintainers] linker version on unstable10* In-Reply-To: <4d0a448ac64d487bb554248b3e472452.squirrel@mail.opencsw.org> References: <4d0a448ac64d487bb554248b3e472452.squirrel@mail.opencsw.org> Message-ID: <39EA704C-9CF0-46DD-BBAD-003F9BC5E593@opencsw.org> Hi Peter, Am 20.08.2012 um 14:35 schrieb pfelecan at opencsw.org: > I started to have issues with the Solaris provided linker some times ago. > Lately I stumbled again on a different behavior of the public build farm > and the one that I'm using privately. > > On the public build-farm the linker version is: > > ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.500 On which host are you executing this? I just have update the Sparc 10 machines to u10. > On my build-farm the linker version is: > > ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.1505 > > Their behavior is different, with the oldest version I have undefined > symbols when with the newer one those symbols are, rightly, found and > consequently defined. > > I analyzed the context/environment and everything is similar on both > platforms with the linkers exceptions. > > Even the debugging options are different, e.g., -Doutput=file is not > supported. > > I have a test case, quite convoluted, that I can provide if somebody > bother to assess. > > Remark 1: on my build farm, Solaris release is 10 8/11 s10x_u10wos_17b X86 > > Remark 2: the same issues raises on the SPARC based systems. Should I do some more patching on x86? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From pfelecan at opencsw.org Mon Aug 20 19:41:26 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 20 Aug 2012 19:41:26 +0200 Subject: [csw-maintainers] linker version on unstable10* In-Reply-To: <39EA704C-9CF0-46DD-BBAD-003F9BC5E593@opencsw.org> (Dagobert Michelsen's message of "Mon, 20 Aug 2012 17:58:01 +0200") References: <4d0a448ac64d487bb554248b3e472452.squirrel@mail.opencsw.org> <39EA704C-9CF0-46DD-BBAD-003F9BC5E593@opencsw.org> Message-ID: Dagobert Michelsen writes: > Am 20.08.2012 um 14:35 schrieb pfelecan at opencsw.org: >> I started to have issues with the Solaris provided linker some times ago. >> Lately I stumbled again on a different behavior of the public build farm >> and the one that I'm using privately. >> >> On the public build-farm the linker version is: >> >> ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.500 > > On which host are you executing this? I just have update the Sparc 10 > machines to u10. unstable10x and unstable10s; /etc/release doesn't reflect that it's u10... > Should I do some more patching on x86? I don't see it as a x86 issue. -- Peter From dam at opencsw.org Mon Aug 20 20:04:15 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 20 Aug 2012 20:04:15 +0200 Subject: [csw-maintainers] linker version on unstable10* In-Reply-To: References: <4d0a448ac64d487bb554248b3e472452.squirrel@mail.opencsw.org> <39EA704C-9CF0-46DD-BBAD-003F9BC5E593@opencsw.org> Message-ID: Hi Peter, Am 20.08.2012 um 19:41 schrieb Peter FELECAN : > Dagobert Michelsen writes: >> Am 20.08.2012 um 14:35 schrieb pfelecan at opencsw.org: >>> I started to have issues with the Solaris provided linker some times ago. >>> Lately I stumbled again on a different behavior of the public build farm >>> and the one that I'm using privately. >>> >>> On the public build-farm the linker version is: >>> >>> ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.500 >> >> On which host are you executing this? I just have update the Sparc 10 >> machines to u10. > > unstable10x and unstable10s; /etc/release doesn't reflect that it's u10? Umh? dam at unstable10s [unstable10s]:/home/dam > more /etc/release Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved. Assembled 23 August 2011 >> Should I do some more patching on x86? > > I don't see it as a x86 issue. In fact it is, as I recently patched only the sparc machines and then went out of time, so the x86 machines are u9 at most. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From bwalton at opencsw.org Tue Aug 21 02:19:29 2012 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 20 Aug 2012 20:19:29 -0400 Subject: [csw-maintainers] SummperCamp 2012 In-Reply-To: <03D6D21B-9B01-4133-9C6E-E71B3C74C742@opencsw.org> References: <03D6D21B-9B01-4133-9C6E-E71B3C74C742@opencsw.org> Message-ID: <1345508264-sup-2592@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Fri Aug 17 10:49:16 -0400 2012: Hi Dago, > - Zurich (hosted by Ihsan, Swisscom) > - Munich (Lengries, same location where we were in winter 2009) > http://wiki.opencsw.org/wintercamp-2009 Hopefully I'll be able to make this camp, although I can't be 100% positive until later on. The later dates are better for me though. I don't have a preference for the location. Who would be hosting in Munich? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Tue Aug 21 19:32:09 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 21 Aug 2012 19:32:09 +0200 Subject: [csw-maintainers] linker version on unstable10* In-Reply-To: (Dagobert Michelsen's message of "Mon, 20 Aug 2012 20:04:15 +0200") References: <4d0a448ac64d487bb554248b3e472452.squirrel@mail.opencsw.org> <39EA704C-9CF0-46DD-BBAD-003F9BC5E593@opencsw.org> Message-ID: Dagobert Michelsen writes: > Hi Peter, > > Am 20.08.2012 um 19:41 schrieb Peter FELECAN : >> Dagobert Michelsen writes: >>> Am 20.08.2012 um 14:35 schrieb pfelecan at opencsw.org: >>>> I started to have issues with the Solaris provided linker some times ago. >>>> Lately I stumbled again on a different behavior of the public build farm >>>> and the one that I'm using privately. >>>> >>>> On the public build-farm the linker version is: >>>> >>>> ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.500 >>> >>> On which host are you executing this? I just have update the Sparc 10 >>> machines to u10. >> >> unstable10x and unstable10s; /etc/release doesn't reflect that it's u10? > > Umh? > > dam at unstable10s [unstable10s]:/home/dam > more /etc/release > Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC > Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved. > Assembled 23 August 2011 Yep, but quite recently, isn't it? >>> Should I do some more patching on x86? >> >> I don't see it as a x86 issue. > > In fact it is, as I recently patched only the sparc machines and then went > out of time, so the x86 machines are u9 at most. You're right. Do you plan to upgrade the x86 systems also? -- Peter From dam at opencsw.org Tue Aug 21 22:35:14 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 21 Aug 2012 22:35:14 +0200 Subject: [csw-maintainers] linker version on unstable10* In-Reply-To: References: <4d0a448ac64d487bb554248b3e472452.squirrel@mail.opencsw.org> <39EA704C-9CF0-46DD-BBAD-003F9BC5E593@opencsw.org> Message-ID: <0E018C4A-781F-454E-B696-5F8BDFAF338D@opencsw.org> Hi Peter, Am 21.08.2012 um 19:32 schrieb Peter FELECAN : > Dagobert Michelsen writes: >> Am 20.08.2012 um 19:41 schrieb Peter FELECAN : >>> Dagobert Michelsen writes: >>>> Am 20.08.2012 um 14:35 schrieb pfelecan at opencsw.org: >>>>> I started to have issues with the Solaris provided linker some times ago. >>>>> Lately I stumbled again on a different behavior of the public build farm >>>>> and the one that I'm using privately. >>>>> >>>>> On the public build-farm the linker version is: >>>>> >>>>> ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.500 >>>> >>>> On which host are you executing this? I just have update the Sparc 10 >>>> machines to u10. >>> >>> unstable10x and unstable10s; /etc/release doesn't reflect that it's u10? >> >> Umh? >> >> dam at unstable10s [unstable10s]:/home/dam > more /etc/release >> Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC >> Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved. >> Assembled 23 August 2011 > > Yep, but quite recently, isn't it? Yes, some weeks ago, I announced the update on maintainers, remember? >>>> Should I do some more patching on x86? >>> >>> I don't see it as a x86 issue. >> >> In fact it is, as I recently patched only the sparc machines and then went >> out of time, so the x86 machines are u9 at most. > > You're right. Do you plan to upgrade the x86 systems also? In fact I have, but the volumes of the VMs are too small and I need to migrate to some bigger LUNs first. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From dam at opencsw.org Wed Aug 22 22:32:14 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 22 Aug 2012 22:32:14 +0200 Subject: [csw-maintainers] SummperCamp 2012 In-Reply-To: <1345508264-sup-2592@pinkfloyd.chass.utoronto.ca> References: <03D6D21B-9B01-4133-9C6E-E71B3C74C742@opencsw.org> <1345508264-sup-2592@pinkfloyd.chass.utoronto.ca> Message-ID: <8F75FB4A-0B40-4AFD-8C30-6D669E48B462@opencsw.org> Hi Ben, Am 21.08.2012 um 02:19 schrieb Ben Walton : > Excerpts from Dagobert Michelsen's message of Fri Aug 17 10:49:16 -0400 2012: >> - Zurich (hosted by Ihsan, Swisscom) >> - Munich (Lengries, same location where we were in winter 2009) >> http://wiki.opencsw.org/wintercamp-2009 > > Hopefully I'll be able to make this camp, although I can't be 100% > positive until later on. The later dates are better for me though. I > don't have a preference for the location. Who would be hosting in > Munich? I would organize it, most of the infrastructure is already there as we saw last time. Ihsan: Would you be still in to host the next camp? My suggestion is to choose the location where more people would attend. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From wilbury at opencsw.org Wed Aug 22 22:34:32 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Wed, 22 Aug 2012 22:34:32 +0200 Subject: [csw-maintainers] SummperCamp 2012 In-Reply-To: <8F75FB4A-0B40-4AFD-8C30-6D669E48B462@opencsw.org> References: <03D6D21B-9B01-4133-9C6E-E71B3C74C742@opencsw.org> <1345508264-sup-2592@pinkfloyd.chass.utoronto.ca> <8F75FB4A-0B40-4AFD-8C30-6D669E48B462@opencsw.org> Message-ID: <50354258.70702@opencsw.org> On 08/22/2012 10:32 PM, Dagobert Michelsen wrote: > Hi Ben, > > Am 21.08.2012 um 02:19 schrieb Ben Walton : >> Excerpts from Dagobert Michelsen's message of Fri Aug 17 10:49:16 -0400 2012: >>> - Zurich (hosted by Ihsan, Swisscom) >>> - Munich (Lengries, same location where we were in winter 2009) >>> http://wiki.opencsw.org/wintercamp-2009 >> >> Hopefully I'll be able to make this camp, although I can't be 100% >> positive until later on. The later dates are better for me though. I >> don't have a preference for the location. Who would be hosting in >> Munich? For me, MUC would be a very decent car trip ;-) Perhaps I could then pick someone up from Vienna or like that. otis -- Juraj Lutter From dam at opencsw.org Fri Aug 24 10:26:47 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 24 Aug 2012 10:26:47 +0200 Subject: [csw-maintainers] OpenCSW buildfarm maintenance on 8. August In-Reply-To: <82F6049E-C1AF-4012-834E-FFC4B8A8D988@opencsw.org> References: <7BAE0F3A-5880-4538-BF94-D2165487A362@opencsw.org> <82F6049E-C1AF-4012-834E-FFC4B8A8D988@opencsw.org> Message-ID: <5B9BC7DF-2BE9-4A77-8258-F19321418A6D@opencsw.org> Fellow maintainers, Am 09.08.2012 um 19:46 schrieb Dagobert Michelsen : > Am 08.08.2012 um 23:00 schrieb Dagobert Michelsen : >> Just a quick heads up: I had some problems with LiveUpgrade but decided to >> go forward. Unfortunately the update is still running for some zones, >> I keep you posted. Hopefully I finish up tomorrow. > > Most of the zones are up and running again. Some updates are still running, so the > disks are more loaded than usual at the moment. Apart from that we are running now > a fully patched Solaris 10u10. I now did the last batch and updated unstable10x testing10x (=experimental10x) dublin10x to Solaris 10u10 and Critical Patch Update cluster 2012-07. Please let me know if you encounter any issues. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From bwalton at opencsw.org Fri Aug 24 21:04:16 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 24 Aug 2012 15:04:16 -0400 Subject: [csw-maintainers] Proposal: direct binding for all the opencsw software stack In-Reply-To: References: Message-ID: <1345835000-sup-6416@pinkfloyd.chass.utoronto.ca> Excerpts from Yann Rouillard's message of Tue Aug 07 16:43:08 -0400 2012: Hi Yann, Sorry it took me so long to get back to this...It's an interesting topic and I think you've outlined a good solution. > Direct Binding changes the behaviour of the linker at runtime, when > a program or a library has a direct binding against a library, the > linker will now link a symbol against the exact library that > provided the symbol at compile time. That exactly solves the problem > we have here because openssl 0.9.8 symbols will be linked against > libssl0.9.8 and not libssl1.0.0 (and vice versa?. I think that for 99% of our use cases this is definitely a good thing to turn on. In my understanding, the only place that having it on globally (-B direct) as opposed to toggling on and off per shared object (-z direct) is if something was relying on interposition (using the first symbol found in the default search algorithm -> normal runtime binding). The only case I could think of where that would be desirable behaviour is in something that dlopen()'s multiple objects for a plugin system where one plugin could redefine an interface and a second plugin could re-redefine it and so on. It's like that there are other cases where it _might_ be desirable behaviour but I have to think it's by far the minority. > So to avoid futures difficulties of the same kind, I am proposing to > enable direct binding by default for all opencsw software !) I think this is a good change to add. > I don't see a lot of cons, maybe these ones: > - sometimes, it seems some programs do need the original linker behaviour > but that could be fixed by some other ld options, Yes, in those cases, either turning off direct linking or somehow inserting the on/off toggles to only use direct linking for some objects. > - we never enabled it so maybe we will uncover some problems, > - it works only with Sun ld (we don't use GNU ld somewhere do we > - ?) I'd almost be surprised if there wasn't some package that used gnu ld but I'm not currently aware of any. > 1. write a checkpkg test to test if direct binding if properly enabled in > a package, How do you envision this check being implemented? As a positive or negative check? > 2. enable Direct Binding manually for a reduced set of packages (at least > my packages :) ) > (we just have to pass "-Bdirect" to SUN ld) I see you're doing this already! +1 > 3. wait a bit to see if something unexpected happens :) > 3. if it works, enable it by globally adding the option to LINKER_FLAGS > 4. enable the checkpkg direct binding test by default so we can catch even > packages that don't use LDFLAGS +1. I think it's a sound plan. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Aug 25 01:21:16 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 24 Aug 2012 19:21:16 -0400 Subject: [csw-maintainers] Proposal: direct binding for all the opencsw software stack In-Reply-To: <1345835000-sup-6416@pinkfloyd.chass.utoronto.ca> References: <1345835000-sup-6416@pinkfloyd.chass.utoronto.ca> Message-ID: <1345850379-sup-7472@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Fri Aug 24 15:04:16 -0400 2012: > runtime binding). The only case I could think of where that would > be desirable behaviour is in something that dlopen()'s multiple > objects for a plugin system where one plugin could redefine an > interface and a second plugin could re-redefine it and so on. It's > like that there are other cases where it _might_ be desirable > behaviour but I have to think it's by far the minority. This isn't even valid. I'm not sure where I was going with that. dlopen()'d things wouldn't be directly applicable here. I can't think of a case where something would prefer the current behaviour if given direct linking as an option. There is likely something that does care but as long as we can disable in that case, I think direct linking is definitely the way to go. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Sat Aug 25 09:43:43 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 25 Aug 2012 09:43:43 +0200 Subject: [csw-maintainers] OpenCSW primary mirror is down Message-ID: <51C21C20-378B-4014-97B5-B49BDA171245@opencsw.org> Hi, as you may have noticed the OpenCSW primary mirror mirror.opencsw.org rsync.opencsw.org is down at the moment. I am in contact with the colocation provider to investigate the issue. Sorry for the inconvenience -- Dago From pfelecan at opencsw.org Sat Aug 25 11:57:59 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 25 Aug 2012 11:57:59 +0200 Subject: [csw-maintainers] Proposal: direct binding for all the opencsw software stack In-Reply-To: (Yann Rouillard's message of "Tue, 7 Aug 2012 22:43:08 +0200") References: Message-ID: Yann Rouillard writes: > But if everybody is ok with it, here is how we could try to enable it to > gradually: > > 1. write a checkpkg test to test if direct binding if properly enabled in > a package, > 2. enable Direct Binding manually for a reduced set of packages (at least > my packages :) ) > (we just have to pass "-Bdirect" to SUN ld) > 3. wait a bit to see if something unexpected happens :) > 3. if it works, enable it by globally adding the option to LINKER_FLAGS > 4. enable the checkpkg direct binding test by default so we can catch even > packages that don't use LDFLAGS Fully agree with the sole condition that there must be a mechanism to inhibit this behavior; by consequence, the check can be also overridden. -- Peter From yann at pleiades.fr.eu.org Sat Aug 25 16:55:28 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sat, 25 Aug 2012 16:55:28 +0200 Subject: [csw-maintainers] Proposal: direct binding for all the opencsw software stack In-Reply-To: <1345835000-sup-6416@pinkfloyd.chass.utoronto.ca> References: <1345835000-sup-6416@pinkfloyd.chass.utoronto.ca> Message-ID: Hi Ben, > 1. write a checkpkg test to test if direct binding if properly enabled in > > a package, > > How do you envision this check being implemented? As a positive or > negative check? > Well I think negative check is a better way to make sure direct binding is enabled in packages ;) Besides it's the way checkpkg works, doesn't it ? Of course, maintainers will be able to override the check (like other checkpkg tests), but at least they will need to do it on purpose. > > 2. enable Direct Binding manually for a reduced set of packages (at > least > > my packages :) ) > > (we just have to pass "-Bdirect" to SUN ld) > > I see you're doing this already! +1 > Want to join me on this so we have a wider packages set ? :) > > 3. wait a bit to see if something unexpected happens :) > > 3. if it works, enable it by globally adding the option to LINKER_FLAGS > > 4. enable the checkpkg direct binding test by default so we can catch > even > > packages that don't use LDFLAGS > > +1. I think it's a sound plan. > Thank you for your feedback ! Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Sat Aug 25 17:03:10 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 25 Aug 2012 11:03:10 -0400 Subject: [csw-maintainers] Proposal: direct binding for all the opencsw software stack In-Reply-To: References: <1345835000-sup-6416@pinkfloyd.chass.utoronto.ca> Message-ID: <1345906836-sup-3640@pinkfloyd.chass.utoronto.ca> Excerpts from Yann Rouillard's message of Sat Aug 25 10:55:28 -0400 2012: Hi Yann, > > How do you envision this check being implemented? As a positive > > or negative check? > > Well I think negative check is a better way to make sure direct > binding is enabled in packages ;) Besides it's the way checkpkg > works, doesn't it ? Yes, I'm just thinking about a transition phase where it will be really noisy (as you mentioned). If it's the way we're going to go though, the negative check is proper and to be overridden by maintainers if the package doesn't comply. > Of course, maintainers will be able to override the check (like > other checkpkg tests), but at least they will need to do it on > purpose. > > > > 2. enable Direct Binding manually for a reduced set of packages > > (at least > my packages :) ) > (we just have to pass "-Bdirect" to > > SUN ld) > > > > I see you're doing this already! +1 > > > > Want to join me on this so we have a wider packages set ? :) Sure. I'll toggle it on for a few packages as I rebuild them in the next while. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From yann at pleiades.fr.eu.org Sat Aug 25 17:07:15 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sat, 25 Aug 2012 17:07:15 +0200 Subject: [csw-maintainers] Proposal: direct binding for all the opencsw software stack In-Reply-To: <1345850379-sup-7472@pinkfloyd.chass.utoronto.ca> References: <1345835000-sup-6416@pinkfloyd.chass.utoronto.ca> <1345850379-sup-7472@pinkfloyd.chass.utoronto.ca> Message-ID: I can think of a case where it would be a problem with plugin but I don't know if it's a real life case. If the plugin needs some symbols from the binary loading it (for exemple the binary provides some API to the plugin) and if a plugin can be loaded by different binary, I suppose that would be a problem because the plugin will only try to bind against the binary it was linked with at compilation time. I also wonder if direct binding works well with auxiliary filters ( http://docs.oracle.com/cd/E19683-01/816-1386/chapter4-5/index.html ), it is another linker feature that has been used in the neon package to be able to provide an alternative neon library with more feature. It would be interesting to have neon in the test package set. Yann 2012/8/25 Ben Walton > Excerpts from Ben Walton's message of Fri Aug 24 15:04:16 -0400 2012: > > > runtime binding). The only case I could think of where that would > > be desirable behaviour is in something that dlopen()'s multiple > > objects for a plugin system where one plugin could redefine an > > interface and a second plugin could re-redefine it and so on. It's > > like that there are other cases where it _might_ be desirable > > behaviour but I have to think it's by far the minority. > > This isn't even valid. I'm not sure where I was going with that. > dlopen()'d things wouldn't be directly applicable here. I can't think > of a case where something would prefer the current behaviour if given > direct linking as an option. There is likely something that does care > but as long as we can disable in that case, I think direct linking is > definitely the way to go. > > Thanks > -Ben > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > _______________________________________________ > 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 Sat Aug 25 17:10:57 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sat, 25 Aug 2012 17:10:57 +0200 Subject: [csw-maintainers] Proposal: direct binding for all the opencsw software stack In-Reply-To: References: Message-ID: 2012/8/25 Peter FELECAN > > Fully agree with the sole condition that there must be a mechanism to > inhibit this behavior; by consequence, the check can be also overridden. > > Yes, this is the intent: 1. be able to override the check, 2. be able to remove this options from the LDFLAGS For 1. that is the way checkpkg works so there is no problem. For 2., I don't know yet. I would like some input from Dago on the best way to add distribution wide LDFLAGS while still allowing to override them. I was thinking about adding a COMMON_LDFLAGS mgar variable that could easily be overriden in the Makefile. What do you think Dago ? Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Sat Aug 25 17:19:27 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sat, 25 Aug 2012 17:19:27 +0200 Subject: [csw-maintainers] Proposal: direct binding for all the opencsw software stack In-Reply-To: <1345906836-sup-3640@pinkfloyd.chass.utoronto.ca> References: <1345835000-sup-6416@pinkfloyd.chass.utoronto.ca> <1345906836-sup-3640@pinkfloyd.chass.utoronto.ca> Message-ID: 2012/8/25 Ben Walton > > Yes, I'm just thinking about a transition phase where it will be > really noisy (as you mentioned). If it's the way we're going to go > though, the negative check is proper and to be overridden by > maintainers if the package doesn't comply. > > Oh ok ! I was thinking about enabling the checkpkg checks only after we sufficiently tested that the option would not cause problem on the first set of package. That was the transition phase :) But we could add another transition phase like you said as long as it is not too long. The problem with informative only messages is that it could easily be missed in all checkpkg messages. Maciej, can I do this by just removing the error_mgr.ReportError call while keeping the messenger.Message call ? Yann > > Of course, maintainers will be able to override the check (like > > other checkpkg tests), but at least they will need to do it on > > purpose. > > > > > > 2. enable Direct Binding manually for a reduced set of packages > > > (at least > my packages :) ) > (we just have to pass "-Bdirect" to > > > SUN ld) > > > > > > I see you're doing this already! +1 > > > > > > > Want to join me on this so we have a wider packages set ? :) > > Sure. I'll toggle it on for a few packages as I rebuild them in the > next while. > > Thanks > -Ben > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > _______________________________________________ > 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 bwalton at opencsw.org Sat Aug 25 17:34:36 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 25 Aug 2012 11:34:36 -0400 Subject: [csw-maintainers] Proposal: direct binding for all the opencsw software stack In-Reply-To: References: Message-ID: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> Excerpts from Yann Rouillard's message of Sat Aug 25 11:10:57 -0400 2012: Hi Yann, > For 2., I don't know yet. I would like some input from Dago on the > best way to add distribution wide LDFLAGS while still allowing to > override them. I was thinking about adding a COMMON_LDFLAGS mgar > variable that could easily be overriden in the Makefile. What about: bwalton @ unstable10s : ~/opencsw/.buildsys/v2 $ svn diff Index: gar.conf.mk =================================================================== --- gar.conf.mk (revision 19080) +++ gar.conf.mk (working copy) @@ -706,7 +706,7 @@ CFLAGS ?= $(strip $($(GARCOMPILER)_CC_FLAGS) $(_CATEGORY_CFLAGS) $(EXTRA_CFLAGS)) CXXFLAGS ?= $(strip $($(GARCOMPILER)_CXX_FLAGS) $(_CATEGORY_CXXFLAGS) $(EXTRA_CXXFLAGS)) CPPFLAGS ?= $(strip $($(GARCOMPILER)_CPP_FLAGS) $(_CATEGORY_CPPFLAGS) $(EXTRA_CPPFLAGS) $(INCLUDE_FLAGS)) -LDFLAGS ?= $(strip $($(GARCOMPILER)_LD_FLAGS) $(_CATEGORY_LDFLAGS) $(EXTRA_LDFLAGS) $(LINKER_FLAGS)) +LDFLAGS ?= $(strip $($(GARCOMPILER)_LD_FLAGS) $(_CATEGORY_LDFLAGS) $(EXTRA_LDFLAGS) $(LINKER_FLAGS) $(ifeq $(NO_LD_DIRECT),,-Bdirect)) ASFLAGS ?= $(strip $($(GARCOMPILER)_AS_FLAGS) $(_CATEGORY_ASFLAGS) $(EXTRA_ASFLAGS)) OPTFLAGS ?= $(strip $($(GARCOMPILER)_CC_FLAGS) $(_CATEGORY_OPTFLAGS) $(EXTRA_OPTFLAGS)) FFLAGS ?= $(strip $($(GARCOMPILER)_FFLAGS) $(_CATEGORY_FFLAGS) $(EXTRA_FFLAGS)) That would allow a maintainer to set NO_LD_DIRECT in the recipe to skip that flag but for everything else it would be set. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Aug 25 17:35:41 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 25 Aug 2012 11:35:41 -0400 Subject: [csw-maintainers] Proposal: direct binding for all the opencsw software stack In-Reply-To: References: <1345835000-sup-6416@pinkfloyd.chass.utoronto.ca> <1345906836-sup-3640@pinkfloyd.chass.utoronto.ca> Message-ID: <1345908902-sup-2927@pinkfloyd.chass.utoronto.ca> Excerpts from Yann Rouillard's message of Sat Aug 25 11:19:27 -0400 2012: > 2012/8/25 Ben Walton > > > > > Yes, I'm just thinking about a transition phase where it will be > > really noisy (as you mentioned). If it's the way we're going to go > > though, the negative check is proper and to be overridden by > > maintainers if the package doesn't comply. > > > > > Oh ok ! I was thinking about enabling the checkpkg checks only after we > sufficiently tested that the option would not cause problem on the first > set of package. That was the transition phase :) Sure, that's fine too. We don't want the check to be noisy before we're fairly confident that it will be a worthwhile switch. > The problem with informative only messages is that it could easily be > missed in all checkpkg messages. True. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From yann at pleiades.fr.eu.org Sat Aug 25 17:37:38 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sat, 25 Aug 2012 17:37:38 +0200 Subject: [csw-maintainers] Checkpkg test for direct binding Message-ID: Hi everybody, As discussed previously in the direct binding discussion, here is the new checkpkg test I am proposing to add to ensure direct binding is enabled in packages. Of course the idea is to enable this check when we agree on enabling direct binding and after having tested it on a first set of package. The full patch is attached, and I put an inline version without the unit test part for easy commenting. Feedbacks are welcome. Yann diff -ur v2.orig//lib/python/dependency_checks.py v2/lib/python/dependency_checks.py --- v2.orig//lib/python/dependency_checks.py Thu Aug 16 12:05:42 2012 +++ v2/lib/python/dependency_checks.py Sat Aug 25 16:14:45 2012 @@ -47,8 +47,8 @@ def ProcessSoname( ldd_emulator, - soname, path_and_pkg_by_basename, binary_info, isalist, binary_path, logger, - error_mgr, + soname, path_and_pkg_by_basename, binary_info, isalist, binary_path, needed_symbols, + logger, error_mgr, pkgname, messenger): """This is not an ideal name for this function. @@ -57,6 +57,28 @@ """ logging.debug("ProcessSoname(), %s %s" % (binary_info["path"], soname)) + + # Even when direct binding is enabled, some symbols might not be + # directly bound because the library explicitely requested the symbol + # not to be drectly bound to. + # For example, libc.so.1 does it for symbol sigaction, free, malloc and realloc + # So we consider that direct binding is enabled if at least one symbol is directly + # bound to because that definitely means that -B direct or -z direct was used. + direct_bind = False + for syminfo in needed_symbols: + if ('D' in syminfo['flags'] and 'B' in syminfo['flags']): + direct_bind = True + break + + if not direct_bind: + messenger.Message( + "No symbol of binary %s is directly binded against library %s. " + "Please make sure the binaries are compiled using the \"-Bdirect\" linker option." + % ("/" + binary_info["path"], soname)) + error_mgr.ReportError( + pkgname, "no-direct-binding", + "%s is not directly binded to soname %s" % ("/" + binary_info["path"], soname)) + orphan_sonames = [] resolved = False path_list = path_and_pkg_by_basename[soname].keys() @@ -146,11 +168,22 @@ orphan_sonames = [] for binary_info in pkg_data["binaries_dump_info"]: binary_path, binary_basename = os.path.split(binary_info["path"]) + + binary_needed_symbols = pkg_data["needed_symbols"][binary_info["path"]] for soname in binary_info["needed sonames"]: + if soname in binary_needed_symbols: + needed_symbols = binary_needed_symbols[soname] + else: + # If we are here, that means we got no information on symbols. + # No syminfo section was present in the elf file, that definitely + # imply that -Bdirect or -z direct was not used and the subsequent + # check on direct binding will catch it because it will find not symbols + needed_symbols = [] + orphan_sonames_tmp = ProcessSoname( ldd_emulator, - soname, path_and_pkg_by_basename, binary_info, isalist, binary_path, logger, - error_mgr, + soname, path_and_pkg_by_basename, binary_info, isalist, binary_path, needed_symbols, + logger, error_mgr, pkgname, messenger) orphan_sonames.extend(orphan_sonames_tmp) diff -ur v2.orig//lib/python/dependency_checks_test.py v2/lib/python/dependency_checks_test.py --- v2.orig//lib/python/dependency_checks_test.py Tue Jun 5 23:52:51 2012 +++ v2/lib/python/dependency_checks_test.py Sat Aug 25 13:37:57 2012 @@ -258,6 +258,8 @@ '/opt/csw/share/man': [u'CSWcommon', u'CSWgnuplot'], '/opt/csw/share/man/man1': ['CSWtree'], '/opt/csw/share/man/man1/tree.1': ['CSWtree']} + self.error_mgr_mock.ReportError('CSWtree', 'no-direct-binding', + '/opt/csw/bin/tree is not directly binded to soname libc.so.1') self.error_mgr_mock.NeedFile('CSWtree', u'/usr/lib/libc.so.1', 'opt/csw/bin/tree needs the libc.so.1 soname') self.mox.ReplayAll() diff -ur v2.orig//lib/python/inspective_package.py v2/lib/python/inspective_package.py --- v2.orig//lib/python/inspective_package.py Thu Aug 23 23:56:57 2012 +++ v2/lib/python/inspective_package.py Sat Aug 25 16:17:17 2012 @@ -229,6 +229,45 @@ return defined_symbols + + def GetNeededSymbols(self): + """Returns symbols needed for packaged ELF objects to work + + To do this we parse output lines from elfdump -y, that command + will give us the content of the .SUNW_syminfo section which + contains additionnal informations on symbols linking. + """ + binaries = self.ListBinaries() + needed_symbols = {} + + for binary in binaries: + binary_abspath = os.path.join(self.directory, "root", binary) + # elfdump is the only tool that give us the syminfo flags + args = ["/usr/ccs/bin/elfdump", "-y", binary_abspath] + elfdump_proc = subprocess.Popen( + args, + stdout=subprocess.PIPE, + stderr=subprocess.PIPE) + stdout, stderr = elfdump_proc.communicate() + retcode = elfdump_proc.wait() + if retcode: + logging.error("%s returned an error: %s", args, stderr) + continue + elfdump_out = stdout.splitlines() + + needed_symbols[binary] = {} + for line in elfdump_out: + syminfo = self._ParseElfdumpSyminfoLine(line) + if not syminfo: + continue + if syminfo['library']: + library = syminfo['library'] + del syminfo['library'] + symbols = needed_symbols[binary].setdefault(library, []) + symbols.append(syminfo) + + return needed_symbols + def GetLddMinusRlines(self): """Returns ldd -r output.""" binaries = self.ListBinaries() @@ -274,6 +313,22 @@ sym = { 'address': fields[0], 'type': fields[1], 'name': fields[2] } return sym + def _ParseElfdumpSyminfoLine(self, line): + blank_line = (r'^\s*$') + header_line = (r'^(?:Syminfo Section:\s+.SUNW_syminfo|\s*index\s+flags\s+bound\s+to\s+symbol)\s*$') + needed_symbol = (r'\s*\[\d+\]\s+(?P[ABCDFILNPS]+)\s*(\[\d+\]\s+(?P.*\S)|)?\s+(?P.*\S)\s*') + common_re = (r"(?:%s|%s|%s)" % (blank_line, header_line, needed_symbol)) + + m = re.match(common_re, line) + if not m: + raise package.StdoutSyntaxError("Could not parse %s with %s" + % (repr(line), common_re)) + syminfo = m.groupdict() + if 'library' in syminfo and syminfo['library']: + return syminfo + else: + return None + def _ParseLddDashRline(self, line, binary=None): found_re = r"^\t(?P\S+)\s+=>\s+(?P\S+)" symbol_not_found_re = (r"^\tsymbol not found:\s(?P\S+)\s+" diff -ur v2.orig//lib/python/package_stats.py v2/lib/python/package_stats.py --- v2.orig//lib/python/package_stats.py Fri Aug 10 02:12:10 2012 +++ v2/lib/python/package_stats.py Sat Aug 25 15:58:49 2012 @@ -209,6 +209,7 @@ "files_metadata": dir_pkg.GetFilesMetadata(), "mtime": self.GetMtime(), "ldd_info": dir_pkg.GetLddMinusRlines(), + "needed_symbols": dir_pkg.GetNeededSymbols(), } self.SaveStats(pkg_stats) logging.debug("Statistics of %s have been collected.", repr(dir_pkg.pkgname)) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: direct_binding_test.patch Type: application/octet-stream Size: 33473 bytes Desc: not available URL: From dam at opencsw.org Sat Aug 25 17:40:59 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 25 Aug 2012 17:40:59 +0200 Subject: [csw-maintainers] Proposal: direct binding for all the opencsw software stack In-Reply-To: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> References: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> Message-ID: <8B21EC9D-F841-430B-B81E-00F41CE7792F@opencsw.org> Hi Ben, Am 25.08.2012 um 17:34 schrieb Ben Walton: > Excerpts from Yann Rouillard's message of Sat Aug 25 11:10:57 -0400 2012: > What about: > > bwalton @ unstable10s : ~/opencsw/.buildsys/v2 > $ svn diff > Index: gar.conf.mk > =================================================================== > --- gar.conf.mk (revision 19080) > +++ gar.conf.mk (working copy) > @@ -706,7 +706,7 @@ > CFLAGS ?= $(strip $($(GARCOMPILER)_CC_FLAGS) $(_CATEGORY_CFLAGS) > $(EXTRA_CFLAGS)) > CXXFLAGS ?= $(strip $($(GARCOMPILER)_CXX_FLAGS) $(_CATEGORY_CXXFLAGS) > $(EXTRA_CXXFLAGS)) > CPPFLAGS ?= $(strip $($(GARCOMPILER)_CPP_FLAGS) $(_CATEGORY_CPPFLAGS) > $(EXTRA_CPPFLAGS) $(INCLUDE_FLAGS)) > -LDFLAGS ?= $(strip $($(GARCOMPILER)_LD_FLAGS) $(_CATEGORY_LDFLAGS) > $(EXTRA_LDFLAGS) $(LINKER_FLAGS)) > +LDFLAGS ?= $(strip $($(GARCOMPILER)_LD_FLAGS) $(_CATEGORY_LDFLAGS) > $(EXTRA_LDFLAGS) $(LINKER_FLAGS) $(ifeq $(NO_LD_DIRECT),,-Bdirect)) > ASFLAGS ?= $(strip $($(GARCOMPILER)_AS_FLAGS) $(_CATEGORY_ASFLAGS) > $(EXTRA_ASFLAGS)) > OPTFLAGS ?= $(strip $($(GARCOMPILER)_CC_FLAGS) $(_CATEGORY_OPTFLAGS) > $(EXTRA_OPTFLAGS)) > FFLAGS ?= $(strip $($(GARCOMPILER)_FFLAGS) $(_CATEGORY_FFLAGS) > $(EXTRA_FFLAGS)) > > That would allow a maintainer to set NO_LD_DIRECT in the recipe to > skip that flag but for everything else it would be set. I see two drawbacks here: 1. autoconf etc. could filter it as it is passed in the build chain 2. A magic variable is introduced Therefore I suggest using LD_OPTIONS with LD_OPTIONS_DIRECT ?= -Bdirect and LD_OPTIONS ?= $(strip $($(GARCOMPILER)_LD_OPTIONS) $(RUNPATH_LINKER_FLAGS) $(LD_OPTIONS_DIRECT) $(EXTRA_LD_OPTIONS) $(_CATEGORY_LD_OPTIONS)) with a possible override LD_OPTIONS_DIRECT = Thoughts? Best regards -- Dago From yann at pleiades.fr.eu.org Sat Aug 25 17:48:23 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sat, 25 Aug 2012 17:48:23 +0200 Subject: [csw-maintainers] Proposal: direct binding for all the opencsw software stack In-Reply-To: <8B21EC9D-F841-430B-B81E-00F41CE7792F@opencsw.org> References: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> <8B21EC9D-F841-430B-B81E-00F41CE7792F@opencsw.org> Message-ID: Hi Dago, How is LD_OPTIONS handled in the build process ? I do know very much this environment variable. Concerning the mecanism proposed: is this a general thing we will be able to apply to any new opencsw wide variable ? I would also like to enable "-z ignore" for all package, so I could create a LD_OPTIONS_IGNORE (or LD_OPTIONS_AS_NEEDED) to do the same thing but I wonder if is ok if we begin to add more variables. Yann 2012/8/25 Dagobert Michelsen > Hi Ben, > > Am 25.08.2012 um 17:34 schrieb Ben Walton: > > Excerpts from Yann Rouillard's message of Sat Aug 25 11:10:57 -0400 2012 > : > > What about: > > > > bwalton @ unstable10s : ~/opencsw/.buildsys/v2 > > $ svn diff > > Index: gar.conf.mk > > =================================================================== > > --- gar.conf.mk (revision 19080) > > +++ gar.conf.mk (working copy) > > @@ -706,7 +706,7 @@ > > CFLAGS ?= $(strip $($(GARCOMPILER)_CC_FLAGS) $(_CATEGORY_CFLAGS) > > $(EXTRA_CFLAGS)) > > CXXFLAGS ?= $(strip $($(GARCOMPILER)_CXX_FLAGS) $(_CATEGORY_CXXFLAGS) > > $(EXTRA_CXXFLAGS)) > > CPPFLAGS ?= $(strip $($(GARCOMPILER)_CPP_FLAGS) $(_CATEGORY_CPPFLAGS) > > $(EXTRA_CPPFLAGS) $(INCLUDE_FLAGS)) > > -LDFLAGS ?= $(strip $($(GARCOMPILER)_LD_FLAGS) $(_CATEGORY_LDFLAGS) > > $(EXTRA_LDFLAGS) $(LINKER_FLAGS)) > > +LDFLAGS ?= $(strip $($(GARCOMPILER)_LD_FLAGS) $(_CATEGORY_LDFLAGS) > > $(EXTRA_LDFLAGS) $(LINKER_FLAGS) $(ifeq $(NO_LD_DIRECT),,-Bdirect)) > > ASFLAGS ?= $(strip $($(GARCOMPILER)_AS_FLAGS) $(_CATEGORY_ASFLAGS) > > $(EXTRA_ASFLAGS)) > > OPTFLAGS ?= $(strip $($(GARCOMPILER)_CC_FLAGS) $(_CATEGORY_OPTFLAGS) > > $(EXTRA_OPTFLAGS)) > > FFLAGS ?= $(strip $($(GARCOMPILER)_FFLAGS) $(_CATEGORY_FFLAGS) > > $(EXTRA_FFLAGS)) > > > > That would allow a maintainer to set NO_LD_DIRECT in the recipe to > > skip that flag but for everything else it would be set. > > I see two drawbacks here: > 1. autoconf etc. could filter it as it is passed in the build chain > 2. A magic variable is introduced > > Therefore I suggest using LD_OPTIONS with > LD_OPTIONS_DIRECT ?= -Bdirect > and > LD_OPTIONS ?= $(strip $($(GARCOMPILER)_LD_OPTIONS) > $(RUNPATH_LINKER_FLAGS) $(LD_OPTIONS_DIRECT) $(EXTRA_LD_OPTIONS) > $(_CATEGORY_LD_OPTIONS)) > with a possible override > LD_OPTIONS_DIRECT = > > Thoughts? > > > 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 Sat Aug 25 17:48:26 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 25 Aug 2012 17:48:26 +0200 Subject: [csw-maintainers] Proposal: direct binding for all the opencsw software stack In-Reply-To: <8B21EC9D-F841-430B-B81E-00F41CE7792F@opencsw.org> (Dagobert Michelsen's message of "Sat, 25 Aug 2012 17:40:59 +0200") References: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> <8B21EC9D-F841-430B-B81E-00F41CE7792F@opencsw.org> Message-ID: Dagobert Michelsen writes: > Therefore I suggest using LD_OPTIONS with > LD_OPTIONS_DIRECT ?= -Bdirect > and > LD_OPTIONS ?= $(strip $($(GARCOMPILER)_LD_OPTIONS) $(RUNPATH_LINKER_FLAGS) $(LD_OPTIONS_DIRECT) $(EXTRA_LD_OPTIONS) $(_CATEGORY_LD_OPTIONS)) > with a possible override > LD_OPTIONS_DIRECT = > > Thoughts? This is what I personally prefer. -- Peter From yann at pleiades.fr.eu.org Sat Aug 25 18:03:17 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sat, 25 Aug 2012 18:03:17 +0200 Subject: [csw-maintainers] Proposal: direct binding for all the opencsw software stack In-Reply-To: References: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> <8B21EC9D-F841-430B-B81E-00F41CE7792F@opencsw.org> Message-ID: 2012/8/25 Yann Rouillard > Hi Dago, > > How is LD_OPTIONS handled in the build process ? I do know very much this > environment variable. > I meant "I do not know". Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Sat Aug 25 18:24:03 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 25 Aug 2012 12:24:03 -0400 Subject: [csw-maintainers] Proposal: direct binding for all the opencsw software stack In-Reply-To: <8B21EC9D-F841-430B-B81E-00F41CE7792F@opencsw.org> References: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> <8B21EC9D-F841-430B-B81E-00F41CE7792F@opencsw.org> Message-ID: <1345911801-sup-2797@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Sat Aug 25 11:40:59 -0400 2012: > I see two drawbacks here: > 1. autoconf etc. could filter it as it is passed in the build chain > 2. A magic variable is introduced > > Therefore I suggest using LD_OPTIONS with > LD_OPTIONS_DIRECT ?= -Bdirect > and > LD_OPTIONS ?= $(strip $($(GARCOMPILER)_LD_OPTIONS) $(RUNPATH_LINKER_FLAGS) $(LD_OPTIONS_DIRECT) $(EXTRA_LD_OPTIONS) $(_CATEGORY_LD_OPTIONS)) > with a possible override > LD_OPTIONS_DIRECT = Sure, this should be more robust. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sat Aug 25 18:24:55 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 25 Aug 2012 17:24:55 +0100 Subject: [csw-maintainers] Checkpkg test for direct binding In-Reply-To: References: Message-ID: 2012/8/25 Yann Rouillard > Hi everybody, > > As discussed previously in the direct binding discussion, here is the new > checkpkg test I am proposing to add to ensure direct binding is enabled in > packages. > Of course the idea is to enable this check when we agree on enabling > direct binding and after having tested it on a first set of package. > > The full patch is attached, and I put an inline version without the unit > test part for easy commenting. > > Feedbacks are welcome. > > Yann > > diff -ur v2.orig//lib/python/dependency_checks.py > v2/lib/python/dependency_checks.py > --- v2.orig//lib/python/dependency_checks.py Thu Aug 16 12:05:42 2012 > +++ v2/lib/python/dependency_checks.py Sat Aug 25 16:14:45 2012 > @@ -47,8 +47,8 @@ > > def ProcessSoname( > ldd_emulator, > - soname, path_and_pkg_by_basename, binary_info, isalist, binary_path, > logger, > - error_mgr, > + soname, path_and_pkg_by_basename, binary_info, isalist, binary_path, > needed_symbols, > + logger, error_mgr, > pkgname, messenger): > """This is not an ideal name for this function. > > @@ -57,6 +57,28 @@ > """ > logging.debug("ProcessSoname(), %s %s" > % (binary_info["path"], soname)) > + > + # Even when direct binding is enabled, some symbols might not be > + # directly bound because the library explicitely requested the symbol > + # not to be drectly bound to. > + # For example, libc.so.1 does it for symbol sigaction, free, malloc and > realloc > + # So we consider that direct binding is enabled if at least one symbol > is directly > + # bound to because that definitely means that -B direct or -z direct > was used. > + direct_bind = False > + for syminfo in needed_symbols: > + if ('D' in syminfo['flags'] and 'B' in syminfo['flags']): > The parentheses are not necessary. > + direct_bind = True > + break > + > + if not direct_bind: > + messenger.Message( > + "No symbol of binary %s is directly binded against library %s. " > + "Please make sure the binaries are compiled using the \"-Bdirect\" > linker option." > + % ("/" + binary_info["path"], soname)) > + error_mgr.ReportError( > + pkgname, "no-direct-binding", > + "%s is not directly binded to soname %s" % ("/" + > binary_info["path"], soname)) > + > orphan_sonames = [] > resolved = False > path_list = path_and_pkg_by_basename[soname].keys() > @@ -146,11 +168,22 @@ > orphan_sonames = [] > for binary_info in pkg_data["binaries_dump_info"]: > binary_path, binary_basename = os.path.split(binary_info["path"]) > + > + binary_needed_symbols = > pkg_data["needed_symbols"][binary_info["path"]] > We need to think whether we will reindex all packages, or we'll accept older data structures without throwing IndexError in the line above. > for soname in binary_info["needed sonames"]: > + if soname in binary_needed_symbols: > + needed_symbols = binary_needed_symbols[soname] > + else: > + # If we are here, that means we got no information on symbols. > + # No syminfo section was present in the elf file, that definitely > + # imply that -Bdirect or -z direct was not used and the subsequent > + # check on direct binding will catch it because it will find not symbols > + needed_symbols = [] > + > orphan_sonames_tmp = ProcessSoname( > ldd_emulator, > - soname, path_and_pkg_by_basename, binary_info, isalist, > binary_path, logger, > - error_mgr, > + soname, path_and_pkg_by_basename, binary_info, isalist, > binary_path, needed_symbols, > + logger, error_mgr, > pkgname, messenger) > orphan_sonames.extend(orphan_sonames_tmp) > > diff -ur v2.orig//lib/python/dependency_checks_test.py > v2/lib/python/dependency_checks_test.py > --- v2.orig//lib/python/dependency_checks_test.py Tue Jun 5 23:52:51 2012 > +++ v2/lib/python/dependency_checks_test.py Sat Aug 25 13:37:57 2012 > @@ -258,6 +258,8 @@ > '/opt/csw/share/man': [u'CSWcommon', u'CSWgnuplot'], > '/opt/csw/share/man/man1': ['CSWtree'], > '/opt/csw/share/man/man1/tree.1': ['CSWtree']} > + self.error_mgr_mock.ReportError('CSWtree', 'no-direct-binding', > + '/opt/csw/bin/tree is not directly binded to soname libc.so.1') > self.error_mgr_mock.NeedFile('CSWtree', u'/usr/lib/libc.so.1', > 'opt/csw/bin/tree needs the libc.so.1 soname') > self.mox.ReplayAll() > diff -ur v2.orig//lib/python/inspective_package.py > v2/lib/python/inspective_package.py > --- v2.orig//lib/python/inspective_package.py Thu Aug 23 23:56:57 2012 > +++ v2/lib/python/inspective_package.py Sat Aug 25 16:17:17 2012 > @@ -229,6 +229,45 @@ > > return defined_symbols > > + > + def GetNeededSymbols(self): > + """Returns symbols needed for packaged ELF objects to work > + > + To do this we parse output lines from elfdump -y, that command > + will give us the content of the .SUNW_syminfo section which > + contains additionnal informations on symbols linking. > + """ > + binaries = self.ListBinaries() > + needed_symbols = {} > + > + for binary in binaries: > + binary_abspath = os.path.join(self.directory, "root", binary) > + # elfdump is the only tool that give us the syminfo flags > + args = ["/usr/ccs/bin/elfdump", "-y", binary_abspath] > + elfdump_proc = subprocess.Popen( > + args, > + stdout=subprocess.PIPE, > + stderr=subprocess.PIPE) > + stdout, stderr = elfdump_proc.communicate() > + retcode = elfdump_proc.wait() > + if retcode: > + logging.error("%s returned an error: %s", args, stderr) > + continue > + elfdump_out = stdout.splitlines() > + > + needed_symbols[binary] = {} > + for line in elfdump_out: > + syminfo = self._ParseElfdumpSyminfoLine(line) > + if not syminfo: > + continue > In what circumstances does syminfo come back empty? Is it when we can't parse the text output? > + if syminfo['library']: > + library = syminfo['library'] > + del syminfo['library'] > Will the del above actually free anything? If the whole syminfo stays around, all its elements will too. > + symbols = needed_symbols[binary].setdefault(library, []) > + symbols.append(syminfo) > + > + return needed_symbols > + > def GetLddMinusRlines(self): > """Returns ldd -r output.""" > binaries = self.ListBinaries() > @@ -274,6 +313,22 @@ > sym = { 'address': fields[0], 'type': fields[1], 'name': fields[2] } > return sym > > + def _ParseElfdumpSyminfoLine(self, line): > + blank_line = (r'^\s*$') > + header_line = (r'^(?:Syminfo > Section:\s+.SUNW_syminfo|\s*index\s+flags\s+bound\s+to\s+symbol)\s*$') > + needed_symbol = > (r'\s*\[\d+\]\s+(?P[ABCDFILNPS]+)\s*(\[\d+\]\s+(?P.*\S)|)?\s+(?P.*\S)\s*') > + common_re = (r"(?:%s|%s|%s)" % (blank_line, header_line, > needed_symbol)) > + > + m = re.match(common_re, line) > + if not m: > + raise package.StdoutSyntaxError("Could not parse %s with %s" > + % (repr(line), common_re)) > + syminfo = m.groupdict() > + if 'library' in syminfo and syminfo['library']: > + return syminfo > + else: > + return None > + > def _ParseLddDashRline(self, line, binary=None): > found_re = r"^\t(?P\S+)\s+=>\s+(?P\S+)" > symbol_not_found_re = (r"^\tsymbol not found:\s(?P\S+)\s+" > diff -ur v2.orig//lib/python/package_stats.py > v2/lib/python/package_stats.py > --- v2.orig//lib/python/package_stats.py Fri Aug 10 02:12:10 2012 > +++ v2/lib/python/package_stats.py Sat Aug 25 15:58:49 2012 > @@ -209,6 +209,7 @@ > "files_metadata": dir_pkg.GetFilesMetadata(), > "mtime": self.GetMtime(), > "ldd_info": dir_pkg.GetLddMinusRlines(), > + "needed_symbols": dir_pkg.GetNeededSymbols(), > } > self.SaveStats(pkg_stats) > logging.debug("Statistics of %s have been collected.", > repr(dir_pkg.pkgname)) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Sat Aug 25 18:51:52 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sat, 25 Aug 2012 18:51:52 +0200 Subject: [csw-maintainers] Checkpkg test for direct binding In-Reply-To: References: Message-ID: Hi Maciej, >> + >> + binary_needed_symbols = >> pkg_data["needed_symbols"][binary_info["path"]] >> > > We need to think whether we will reindex all packages, or we'll accept > older data structures without throwing IndexError in the line above. > What are the cases where the new checkpkg code is called on an older structure data ? I can easily ignore the test if needed_symbols is not present. What is your advice ? Is is costly to reindex all packages ? > + needed_symbols[binary] = {} > >> + for line in elfdump_out: >> + syminfo = self._ParseElfdumpSyminfoLine(line) >> + if not syminfo: >> + continue >> > > In what circumstances does syminfo come back empty? Is it when we can't > parse the text output? > Two cases: - when an header line was parsed as there are no information in it :), - when a self symbol reference is found, i.e. a symbol belonging to the binary itself and not a needed symbol provided by a dynamic library. We could store the self symbol reference in case it will be used by another check but that's not the case currently (and I should rename the function then because it would not be only the needed symbols :) ). In other cases, an exception is triggered. > > >> + if syminfo['library']: >> + library = syminfo['library'] >> + del syminfo['library'] >> > > Will the del above actually free anything? If the whole syminfo stays > around, all its elements will too. > We know which library a syminfo belongs to because we store a syminfo in a dictionary with the library as the key. So this reference to the library is not useful anymore but we will only free the reference (and I am not sure it will really free some space as it depends how python handle the data structure). But on the other hand: - you will gain some space in the database, - there will be less data to transfer and parse when using the rest interface. For package like openoffice I suppose this would make a significant difference as it needs a lot of symbols from what I heard (but anyway it is not anymore in the repository). Thanks for your feedback, Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Sat Aug 25 19:38:51 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 25 Aug 2012 19:38:51 +0200 Subject: [csw-maintainers] Proposal: direct binding for all the opencsw software stack In-Reply-To: References: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> <8B21EC9D-F841-430B-B81E-00F41CE7792F@opencsw.org> Message-ID: <99071AB4-FCB4-4CF2-B0EE-9CCBB04D6441@opencsw.org> Hi Yann, Am 25.08.2012 um 18:03 schrieb Yann Rouillard : >> How is LD_OPTIONS handled in the build process ? I do know very much this environment variable. > > I meant "I do not know". LD_OPTIONS is passed as environment variable directly to the linker and processed before any other option on the command line. Most of the time this works for runtime paths and it is especially important to pass $ISALIST in RPATH as '$' is sensitive to evaluation when passed with LDFLAGS - depending on the build system the '$' needs to be quoted two or even three times. The downside is that prepending /opt/csw/lib can brake the test suite because the installed library is preferred over the newly built one: http://wiki.opencsw.org/porting-faq#toc10 For the discussed variables like direct or ignore it would be perfect as it is not order relevant. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From maciej at opencsw.org Sat Aug 25 23:33:51 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 25 Aug 2012 22:33:51 +0100 Subject: [csw-maintainers] Checkpkg test for direct binding In-Reply-To: References: Message-ID: 2012/8/25 Yann Rouillard > Hi Maciej, > > >>> + >>> + binary_needed_symbols = >>> pkg_data["needed_symbols"][binary_info["path"]] >>> >> >> We need to think whether we will reindex all packages, or we'll accept >> older data structures without throwing IndexError in the line above. >> > > What are the cases where the new checkpkg code is called on an older > structure data ? > This will happen immediately after someone checks out the updated code. > > I can easily ignore the test if needed_symbols is not present. What is > your advice ? Is is costly to reindex all packages ? > Costly ? yes, but it's a one time operation. I've done it a couple of times already. It can be done in parallel with normal operation; you import into a new database, and then you swap databases together with checking in the code. > > > >> + needed_symbols[binary] = {} >> >>> + for line in elfdump_out: >>> + syminfo = self._ParseElfdumpSyminfoLine(line) >>> + if not syminfo: >>> + continue >>> >> >> In what circumstances does syminfo come back empty? Is it when we can't >> parse the text output? >> > > Two cases: > - when an header line was parsed as there are no information in it :), > - when a self symbol reference is found, i.e. a symbol belonging to > the binary itself and not a needed symbol provided by a dynamic library. > > We could store the self symbol reference in case it will be used by > another check but that's not the case currently (and I should rename the > function then because it would not be only the needed symbols :) ). > > In other cases, an exception is triggered. > OK, sounds good. > > >> >> >>> + if syminfo['library']: >>> + library = syminfo['library'] >>> + del syminfo['library'] >>> >> >> Will the del above actually free anything? If the whole syminfo stays >> around, all its elements will too. >> > > We know which library a syminfo belongs to because we store a syminfo in a > dictionary with the library as the key. So this reference to the library is > not useful anymore but we will only free the reference (and I am not sure > it will really free some space as it depends how python handle the data > structure). > > But on the other hand: > - you will gain some space in the database, > - there will be less data to transfer and parse when using the rest > interface. > > For package like openoffice I suppose this would make a significant > difference as it needs a lot of symbols from what I heard (but anyway it is > not anymore in the repository). > Aha, so this is about saving space in the database, not about saving memory at runtime. Cool. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Sun Aug 26 18:00:58 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sun, 26 Aug 2012 18:00:58 +0200 Subject: [csw-maintainers] Openssl migration: status update 3 for group 1 Message-ID: Hi everybody, Here is the last status update about the big ssl migration group 1 which is still waiting to come out. Now only 11 packages are now waiting to be updated or dropped, before we can release the already updated packages. And 5 of these packages are just waiting to be tested before being put in openssl-relinking-group1. We have never been so close !! :) Here are the remaining packages: - *boincclient, boinclibs and boincmanager*: Eric, the maintainer, should work soon on these packages. - *libgnomecups, libgnomeprint, libbonoboui and gnomevfs2:* I continued the work on theses packages initiated by Dago. Updated packages are now waiting in my experimental repository ready to be tested. pkgutil -t http://buildfarm.opencsw.org/opencsw/experimental/yann -i gnomevfs2 gnomevfs2_dev libbonoboui libgnomecups libgnomeprint libgnomeprint_devel libgnomeprint_doc I personnally don't use graphical stuffs under Solaris. Dago, Peter and Carsten, could you test that theses libraries correctly work with your packages (gthumb, gvim, grip, gnucash) ? - *postfix / courier_imap: *No recent answer from Juraj. As discussed previously with him, I updated the package recipe and rebuilt it to gain some time. While waiting for Juraj, it would be nice if someone that uses postfix on Solaris could test if the package is ok. It is also in my experimental repository: pkgutil -t http://buildfarm.opencsw.org/opencsw/experimental/yann -i postfix - *hobbit: *I pinged Jurgen but no answer so far. I propose to drop this package, if no one takes over its maintenance quickly. - *libpq:* only courier_auth still need to be rebuilt so we can drop this package. Here is what else happened since the last update: - *gnucash: *I removed gnucash as Peter proposed. Note however that it will not solve the problem for users who already installed gnucash. - *libneon26: *pysvn has been compiled and pushed to openssl-relinking-group1 so this package can now be dropped. BTW, this package never needed neon in fact, there is probably an error in the build system configuration of pysvn, but the "-z ignore" linker option worarounds it. - *dovecot:* it has been rebuilt and put openssl-relinking-group1 by Jake. Thanks in advance for your help so we can we push this update soon. Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joerg.Schilling at fokus.fraunhofer.de Mon Aug 27 12:29:11 2012 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Mon, 27 Aug 2012 12:29:11 +0200 Subject: [csw-maintainers] Proposal: direct binding for all the opencsw software stack In-Reply-To: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> References: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> Message-ID: <503b4bf7.sA6xqVz+p6WXg+Bv%Joerg.Schilling@fokus.fraunhofer.de> Ben Walton wrote: > Excerpts from Yann Rouillard's message of Sat Aug 25 11:10:57 -0400 2012: > > Hi Yann, > > > For 2., I don't know yet. I would like some input from Dago on the > > best way to add distribution wide LDFLAGS while still allowing to > > override them. I was thinking about adding a COMMON_LDFLAGS mgar > > variable that could easily be overriden in the Makefile. > > What about: > > bwalton @ unstable10s : ~/opencsw/.buildsys/v2 > $ svn diff > Index: gar.conf.mk > =================================================================== > --- gar.conf.mk (revision 19080) > +++ gar.conf.mk (working copy) > @@ -706,7 +706,7 @@ > CFLAGS ?= $(strip $($(GARCOMPILER)_CC_FLAGS) $(_CATEGORY_CFLAGS) > $(EXTRA_CFLAGS)) > CXXFLAGS ?= $(strip $($(GARCOMPILER)_CXX_FLAGS) $(_CATEGORY_CXXFLAGS) > $(EXTRA_CXXFLAGS)) > CPPFLAGS ?= $(strip $($(GARCOMPILER)_CPP_FLAGS) $(_CATEGORY_CPPFLAGS) > $(EXTRA_CPPFLAGS) $(INCLUDE_FLAGS)) > -LDFLAGS ?= $(strip $($(GARCOMPILER)_LD_FLAGS) $(_CATEGORY_LDFLAGS) > $(EXTRA_LDFLAGS) $(LINKER_FLAGS)) > +LDFLAGS ?= $(strip $($(GARCOMPILER)_LD_FLAGS) $(_CATEGORY_LDFLAGS) I hope, you only use LDFLAGS in case of a known defective upstream build system. Note that using LDFLAGS may cause a sane build system to missbehave. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From dam at opencsw.org Mon Aug 27 13:12:13 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 27 Aug 2012 13:12:13 +0200 Subject: [csw-maintainers] Proposal: direct binding for all the opencsw software stack In-Reply-To: <503b4bf7.sA6xqVz+p6WXg+Bv%Joerg.Schilling@fokus.fraunhofer.de> References: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> <503b4bf7.sA6xqVz+p6WXg+Bv%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: Hi J?rg, Am 27.08.2012 um 12:29 schrieb Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling): > Ben Walton wrote: >> Excerpts from Yann Rouillard's message of Sat Aug 25 11:10:57 -0400 2012: >>> For 2., I don't know yet. I would like some input from Dago on the >>> best way to add distribution wide LDFLAGS while still allowing to >>> override them. I was thinking about adding a COMMON_LDFLAGS mgar >>> variable that could easily be overriden in the Makefile. >> >> What about: >> >> bwalton @ unstable10s : ~/opencsw/.buildsys/v2 >> $ svn diff >> Index: gar.conf.mk >> =================================================================== >> --- gar.conf.mk (revision 19080) >> +++ gar.conf.mk (working copy) >> @@ -706,7 +706,7 @@ >> CFLAGS ?= $(strip $($(GARCOMPILER)_CC_FLAGS) $(_CATEGORY_CFLAGS) >> $(EXTRA_CFLAGS)) >> CXXFLAGS ?= $(strip $($(GARCOMPILER)_CXX_FLAGS) $(_CATEGORY_CXXFLAGS) >> $(EXTRA_CXXFLAGS)) >> CPPFLAGS ?= $(strip $($(GARCOMPILER)_CPP_FLAGS) $(_CATEGORY_CPPFLAGS) >> $(EXTRA_CPPFLAGS) $(INCLUDE_FLAGS)) >> -LDFLAGS ?= $(strip $($(GARCOMPILER)_LD_FLAGS) $(_CATEGORY_LDFLAGS) >> $(EXTRA_LDFLAGS) $(LINKER_FLAGS)) >> +LDFLAGS ?= $(strip $($(GARCOMPILER)_LD_FLAGS) $(_CATEGORY_LDFLAGS) > > I hope, you only use LDFLAGS in case of a known defective upstream build > system. Note that using LDFLAGS may cause a sane build system to misbehave. I think you mean LD_OPTIONS to misbehave and LDFLAGS is ok? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From Joerg.Schilling at fokus.fraunhofer.de Mon Aug 27 14:49:47 2012 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Mon, 27 Aug 2012 14:49:47 +0200 Subject: [csw-maintainers] Proposal: direct binding for all the opencsw software stack In-Reply-To: References: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> <503b4bf7.sA6xqVz+p6WXg+Bv%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <503b6ceb.4PSnFft71DT+ifVv%Joerg.Schilling@fokus.fraunhofer.de> Dagobert Michelsen wrote: > > > > I hope, you only use LDFLAGS in case of a known defective upstream build > > system. Note that using LDFLAGS may cause a sane build system to misbehave. > > I think you mean LD_OPTIONS to misbehave and LDFLAGS is ok? You are right - sorry for my confusion. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From jh at opencsw.org Tue Aug 28 11:44:34 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Tue, 28 Aug 2012 11:44:34 +0200 Subject: [csw-maintainers] another bad libc binding (bash) In-Reply-To: <503b6ceb.4PSnFft71DT+ifVv%Joerg.Schilling@fokus.fraunhofer.de> References: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> <503b4bf7.sA6xqVz+p6WXg+Bv%Joerg.Schilling@fokus.fraunhofer.de> <503b6ceb.4PSnFft71DT+ifVv%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <503C9302.2070806@opencsw.org> Hi, Another to new libc binding has been reported again. This time bash. (So Yann it's your turn again :) ) bash: ld.so.1: bash: fatal: libc.so.1: version `SUNW_1.22.7' not found (required by file /opt/csw/bin/bash) We should get a global map-file in place soon :) Greetings Jan From yann at pleiades.fr.eu.org Tue Aug 28 12:28:27 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Tue, 28 Aug 2012 12:28:27 +0200 Subject: [csw-maintainers] another bad libc binding (bash) In-Reply-To: <503C9302.2070806@opencsw.org> References: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> <503b4bf7.sA6xqVz+p6WXg+Bv%Joerg.Schilling@fokus.fraunhofer.de> <503b6ceb.4PSnFft71DT+ifVv%Joerg.Schilling@fokus.fraunhofer.de> <503C9302.2070806@opencsw.org> Message-ID: Argh, I forgot this. I wil fix this this evening. I will have to recheck all my packages. Dago have you begin to work on something for a global map in GAR ? Yann 2012/8/28 Jan Holzhueter > Hi, > > Another to new libc binding has been reported again. > This time bash. (So Yann it's your turn again :) ) > > bash: ld.so.1: bash: fatal: libc.so.1: version `SUNW_1.22.7' not found > (required by file /opt/csw/bin/bash) > > > We should get a global map-file in place soon :) > > 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 yann at pleiades.fr.eu.org Tue Aug 28 12:29:41 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Tue, 28 Aug 2012 12:29:41 +0200 Subject: [csw-maintainers] another bad libc binding (bash) In-Reply-To: References: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> <503b4bf7.sA6xqVz+p6WXg+Bv%Joerg.Schilling@fokus.fraunhofer.de> <503b6ceb.4PSnFft71DT+ifVv%Joerg.Schilling@fokus.fraunhofer.de> <503C9302.2070806@opencsw.org> Message-ID: It would not be too hard to create another checkpkg test for that but we should agree on the Solaris minimum patch version to support. Yann 2012/8/28 Yann Rouillard > Argh, I forgot this. > I wil fix this this evening. > I will have to recheck all my packages. > > Dago have you begin to work on something for a global map in GAR ? > > Yann > > > 2012/8/28 Jan Holzhueter > >> Hi, >> >> Another to new libc binding has been reported again. >> This time bash. (So Yann it's your turn again :) ) >> >> bash: ld.so.1: bash: fatal: libc.so.1: version `SUNW_1.22.7' not found >> (required by file /opt/csw/bin/bash) >> >> >> We should get a global map-file in place soon :) >> >> Greetings >> Jan >> >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers >> .:: This mailing list's archive is public. ::. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Tue Aug 28 12:47:43 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 28 Aug 2012 12:47:43 +0200 Subject: [csw-maintainers] another bad libc binding (bash) In-Reply-To: References: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> <503b4bf7.sA6xqVz+p6WXg+Bv%Joerg.Schilling@fokus.fraunhofer.de> <503b6ceb.4PSnFft71DT+ifVv%Joerg.Schilling@fokus.fraunhofer.de> <503C9302.2070806@opencsw.org> Message-ID: <5F701AB2-2465-4D4C-905E-49B5329235CB@opencsw.org> Hi Yann, Am 28.08.2012 um 12:28 schrieb Yann Rouillard : > Argh, I forgot this. > I wil fix this this evening. > I will have to recheck all my packages. > > Dago have you begin to work on something for a global map in GAR ? There is not much more to do then the few lines I posted some days ago. We can enable them any time. Best regards -- Dago > > Yann > > 2012/8/28 Jan Holzhueter > Hi, > > Another to new libc binding has been reported again. > This time bash. (So Yann it's your turn again :) ) > > bash: ld.so.1: bash: fatal: libc.so.1: version `SUNW_1.22.7' not found > (required by file /opt/csw/bin/bash) > > > We should get a global map-file in place soon :) > > Greetings > Jan > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From jh at opencsw.org Tue Aug 28 14:02:05 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Tue, 28 Aug 2012 14:02:05 +0200 Subject: [csw-maintainers] another bad libc binding (bash) In-Reply-To: <5F701AB2-2465-4D4C-905E-49B5329235CB@opencsw.org> References: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> <503b4bf7.sA6xqVz+p6WXg+Bv%Joerg.Schilling@fokus.fraunhofer.de> <503b6ceb.4PSnFft71DT+ifVv%Joerg.Schilling@fokus.fraunhofer.de> <503C9302.2070806@opencsw.org> <5F701AB2-2465-4D4C-905E-49B5329235CB@opencsw.org> Message-ID: <503CB33D.2050606@opencsw.org> Am 28.08.12 12:47, schrieb Dagobert Michelsen: > Hi Yann, > > Am 28.08.2012 um 12:28 schrieb Yann Rouillard >: >> Argh, I forgot this. >> I wil fix this this evening. >> I will have to recheck all my packages. >> >> Dago have you begin to work on something for a global map in GAR ? > > There is not much more to do then the few lines I posted some days ago. > We can enable > them any time. we should integrate this asap. This will hit us probably more often now. Greetings Jan From dam at opencsw.org Fri Aug 31 13:14:58 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 31 Aug 2012 13:14:58 +0200 Subject: [csw-maintainers] Openssl migration: status update 3 for group 1 In-Reply-To: References: Message-ID: <03EF4A55-9100-48C8-966B-C5531C7EF598@opencsw.org> Hi Yann, Am 26.08.2012 um 18:00 schrieb Yann Rouillard : > Here is the last status update about the big ssl migration group 1 which is still waiting to come out. > > Now only 11 packages are now waiting to be updated or dropped, before we can release the already updated packages. > And 5 of these packages are just waiting to be tested before being put in openssl-relinking-group1. > We have never been so close !! :) > > Here are the remaining packages: > ? boincclient, boinclibs and boincmanager: Eric, the maintainer, should work soon on these packages. > ? libgnomecups, libgnomeprint, libbonoboui and gnomevfs2: I continued the work on theses packages initiated by Dago. Updated packages are now waiting in my experimental repository ready to be tested. > pkgutil -t http://buildfarm.opencsw.org/opencsw/experimental/yann -i gnomevfs2 gnomevfs2_dev libbonoboui libgnomecups libgnomeprint libgnomeprint_devel libgnomeprint_doc > I personnally don't use graphical stuffs under Solaris. Dago, Peter and Carsten, could you test that theses libraries correctly work with your packages (gthumb, gvim, grip, gnucash) ? Yep, looks good with vvim. > ? postfix / courier_imap: No recent answer from Juraj. As discussed previously with him, I updated the package recipe and rebuilt it to gain some time. While waiting for Juraj, it would be nice if someone that uses postfix on Solaris could test if the package is ok. It is also in my experimental repository: > pkgutil -t http://buildfarm.opencsw.org/opencsw/experimental/yann -i postfix > ? hobbit: I pinged Jurgen but no answer so far. I propose to drop this package, if no one takes over its maintenance quickly. > ? libpq: only courier_auth still need to be rebuilt so we can drop this package. > > Here is what else happened since the last update: > ? gnucash: I removed gnucash as Peter proposed. Note however that it will not solve the problem for users who already installed gnucash. > ? libneon26: pysvn has been compiled and pushed to openssl-relinking-group1 so this package can now be dropped. BTW, this package never needed neon in fact, there is probably an error in the build system configuration of pysvn, but the "-z ignore" linker option worarounds it. Excellent, after the push we can remove neon_stub and libneon26 and libneon26_feature. > ? dovecot: it has been rebuilt and put openssl-relinking-group1 by Jake. > > Thanks in advance for your help so we can we push this update soon. I am looking forward to it. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: