From yann at pleiades.fr.eu.org Sat Sep 1 12:20:43 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sat, 1 Sep 2012 12:20:43 +0200 Subject: [csw-maintainers] Checkpkg test for direct binding In-Reply-To: References: Message-ID: Hi Maciej, >> 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. > When I recompile a package with my code, it seems to update the data on my package and I don't have errors about that. What do I get wrong ? > > >> >> 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. > Ok, how and when can we do this ? Before I may want to do some changes in the way the data are stored. Currently I store them in a dictionnary with the soname as the key. The problem is that this information is not always present in binaries. I only know they are at least present if direct binding is enabled. As I wanted to check if direct binding was enabled, this was not a problem but I wonder if it wouldn't be a better to store the list of symbol as a simple list contains for each symbol the name of the symbol, the soname and version interface providing it if available. This will take more space in databases (and in rest transfers) but if for some reasons, we need to add some checks which just are interested in symbol presence, they would work whether direct binding is enabled or not. I also wonder if we should use "elfdump -v" rather than "dump -Lv" to extract soname needed as we get in addition the version information of the soname with elfdump. That would allow us to easily add a check to make sure our binary don't work only on the last solaris update. What do you think about all this ? Yann Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sat Sep 1 22:32:37 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 1 Sep 2012 21:32:37 +0100 Subject: [csw-maintainers] Checkpkg test for direct binding In-Reply-To: References: Message-ID: 2012/9/1 Yann Rouillard > Hi Maciej, > > >>> 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. >> > > When I recompile a package with my code, it seems to update the data on my > package and I don't have errors about that. > What do I get wrong ? > For new packages it'll work, but if you want to check a previously indexed package, you'll get a crash. It makes sense to check the whole catalog after adding a new check, because it's useful to analyze already existing packages for issues we might have previously missed. > > >> >> >>> >>> 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. >> > > Ok, how and when can we do this ? > It's been a while since I last did it, so I don't recall all the steps; I had a shell script to do it. It was calling pkgdb to import packages one by one, over catalogs one by one. The operation is IO bound I think, so there isn't much point in making it parallel. > > > Before I may want to do some changes in the way the data are stored. > Currently I store them in a dictionnary with the soname as the key. The > problem is that this information is not always present in binaries. I only > know they are at least present if direct binding is enabled. > As I wanted to check if direct binding was enabled, this was not a problem > but I wonder if it wouldn't be a better to store the list of symbol as a > simple list contains for each symbol the name of the symbol, the soname and > version interface providing it if available. > > This will take more space in databases (and in rest transfers) but if for > some reasons, we need to add some checks which just are interested in > symbol presence, they would work whether direct binding is enabled or not. > Yes, this is a good approach. If you store the data in a way that well resembles the original structure, it'll be easier to make write future checks. > > I also wonder if we should use "elfdump -v" rather than "dump -Lv" to > extract soname needed as we get in addition the version information of the > soname with elfdump. That would allow us to easily add a check to make sure > our binary don't work only on the last solaris update. > Sounds good. > > What do you think about all this ? > We need to plan the database update. The rough outline of steps to take, from memory: - increment the data structure version in the code so that checkpkg knows we're messing with it - create a new empty database, named checkpkg2 (will be renamed later) - alter ~/.checkpkg/... config in your home directory to make checkpkg use the new database (needs to use the relmgr credentials, I'll give them to you) - stop the catalog generation to avoid race conditions - using the new code import the complete catalog into the database - submit the code into the repository - send a notification to maintainers@ that people should update the code and not use the buildfarm for the next 2h or so (to have some margin) - move the old checkpkg database out of the way, rename the 'checkpkg2' database to 'checkpkg' (I'm quoting because I mean the literals) - now people with the old code can't do anything, will be getting error messages about data mismatches (they shouldn't index new packages and storing the old data structure, there's a safety check to prevent that) - people with the new code should be able to work normally - revert ~/.checkpkg (your homedir only) to the old state (or remove it altogether) Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From romeotheriault at opencsw.org Tue Sep 4 23:14:36 2012 From: romeotheriault at opencsw.org (Romeo Theriault) Date: Tue, 04 Sep 2012 11:14:36 -1000 Subject: [csw-maintainers] Use of is valid only in a c99 compilation environment. In-Reply-To: References: <20120708142816.GA15609@sebastiankayser.de> Message-ID: On Sun, Jul 15, 2012 at 2:36 PM, Romeo Theriault wrote: > On Sun, Jul 8, 2012 at 8:24 PM, Romeo Theriault > wrote: > Thought I'd follow up on this. I'm unfortunately still unable to > figure out how to get msgpack-python to compile with SunStudio cc. I > asked this here [1] and got some suggestions that got me a bit further > (I think) but am still unable to fully compile the software. > Basically, I'm able to get past the stdbool.h error by using these > EXTRA_CPPFLAGS += -D_XPG6 -xc99 but now seem to be running into other > errors that to my junior eye seems to be related to some C standard > compatibility. > > Errors like so: > > "msgpack/unpack_template.h", line 205: "default" outside switch > "msgpack/unpack_template.h", line 207: undefined label: _fixed_trail_again > Finally, got this going with Sun's cc with a patch to one of the source files. The source was expecting a gcc feature (case ranges) that aren't supported with Sun's cc. Once I patched that, it build and runs fine. Romeo -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Thu Sep 6 08:02:25 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Thu, 6 Sep 2012 08:02:25 +0200 Subject: [csw-maintainers] Checkpkg test for direct binding In-Reply-To: References: Message-ID: Hi Maciej, > >> >> Yes, this is a good approach. If you store the data in a way that well > resembles the original structure, it'll be easier to make write future > checks. > I made the modifications. The elfdump output is not so easy to parse correctly, I wonder if we should rather directly some python library that can directly read the elf headers, but anyway the full patch contains all new checks and stats is attached, and I put the new part at the end of this mail for comment. I added a new check to make sure that binaries don't use interface version available only on recent Solaris releases. > >> What do you think about all this ? >> > > We need to plan the database update. The rough outline of steps to take, > from memory: > I don't know how to do at least some of these steps. Maybe we can do this live on irc and document on the wiki at the same time ? Yann > > - increment the data structure version in the code so that checkpkg knows > we're messing with it > - create a new empty database, named checkpkg2 (will be renamed later) > - alter ~/.checkpkg/... config in your home directory to make checkpkg use > the new database (needs to use the relmgr credentials, I'll give them to > you) > - stop the catalog generation to avoid race conditions > - using the new code import the complete catalog into the database > - submit the code into the repository > - send a notification to maintainers@ that people should update the code > and not use the buildfarm for the next 2h or so (to have some margin) > - move the old checkpkg database out of the way, rename the 'checkpkg2' > database to 'checkpkg' (I'm quoting because I mean the literals) > - now people with the old code can't do anything, will be getting error > messages about data mismatches (they shouldn't index new packages and > storing the old data structure, there's a safety check to prevent that) > - people with the new code should be able to work normally > - revert ~/.checkpkg (your homedir only) to the old state (or remove it > altogether) > > Maciej > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > --- dependency_checks.py (revision 19130) +++ dependency_checks.py (working copy) @@ -39,6 +39,24 @@ PREFERRED_DIRECTORY_PROVIDERS = set([u"CSWcommon"]) [...] + +ALLOWED_VERSION_DEPENDENCIES = { "libc.so.1": [ 'SYSVABI_1.3', 'SUNWprivate_1.1', 'SUNW_1.22.6', 'SUNW_1.22.5', + 'SUNW_1.22.4', 'SUNW_1.22.3', 'SUNW_1.22.2', 'SUNW_1.22.1', + 'SUNW_1.22', 'SUNW_1.21.3', 'SUNW_1.21.2', 'SUNW_1.21.1', + 'SUNW_1.21', 'SUNW_1.20.4', 'SUNW_1.20.1', 'SUNW_1.20', + 'SUNW_1.19', 'SUNW_1.18.1', 'SUNW_1.18', 'SUNW_1.17', + 'SUNW_1.16', 'SUNW_1.15', 'SUNW_1.14', 'SUNW_1.13', + 'SUNW_1.12', 'SUNW_1.11', 'SUNW_1.10', 'SUNW_1.9', + 'SUNW_1.8', 'SUNW_1.7', 'SUNW_1.6', 'SUNW_1.5', + 'SUNW_1.4', 'SUNW_1.3', 'SUNW_1.2', 'SUNW_1.1', + 'SUNW_0.9', 'SUNW_0.8', 'SUNW_0.7', 'SISCD_2.3' ] } + + @@ -147,6 +165,57 @@ 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"])) + + # 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. + directly_binded = set() + for syminfo in pkg_data["binaries_elf_info"][binary_info["path"]]['symbol table']: + if syminfo['external'] and syminfo['flags'] and 'D' in syminfo['flags'] and 'B' in syminfo['flags']: + directly_binded.add(syminfo['soname']) + not_directly_binded = directly_binded.symmetric_difference(binary_info["needed sonames"]) + + if not_directly_binded: + messenger.Message( + "No symbol of binary %s is directly binded against the following libraries: %s. " + "Please make sure the binaries are compiled using the \"-Bdirect\" linker option." + % ("/" + binary_info["path"], ", ".join(not_directly_binded))) + for soname in not_directly_binded: + error_mgr.ReportError( + pkgname, "no-direct-binding", + "%s is not directly binded to soname %s" % ("/" + binary_info["path"], soname)) + + + for version_dep in pkg_data["binaries_elf_info"][binary_info["path"]]['version needed']: + if (version_dep['soname'] in ALLOWED_VERSION_DEPENDENCIES and + not version_dep['version'] in ALLOWED_VERSION_DEPENDENCIES[version_dep['soname']]): + messenger.Message( + "Binary %s requires interface version %s in library %s which is only available " + "in recent Solaris releases." + % ("/" + binary_info["path"], version_dep['version'], version_dep['soname'])) + error_mgr.ReportError( + pkgname, "forbidden-version-interface-dependencies", + "%s requires forbidden interface version %s in library %s" + % ("/" + binary_info["path"], version_dep['version'], version_dep['soname'])) + + orphan_sonames = set(orphan_sonames) for soname, binary_path in orphan_sonames: if soname not in ALLOWED_ORPHAN_SONAMES: --- inspective_package.py (revision 19130) +++ inspective_package.py (working copy) @@ -229,17 +229,132 @@ return defined_symbols + + def GetBinaryElfInfo(self): + """Returns various informations symbol and version present in elf header + + To do this we parse output lines from elfdump -syv, it's the + only command that will give us all informations we need on symbols and versions. + We will analyse 3 sections: + - version section: contains soname needed, version interface required for each soname, + and version definition + - symbol table section: contains list of symbol and soname/version interface providing it + (the latter is an index in the version section) + - syminfo section: contains special linking flags for each symbol + """ + binaries = self.ListBinaries() + binaries_elf_info = {} + + for binary in binaries: + binary_abspath = os.path.join(self.directory, "root", binary) + # elfdump is the only tool that give us all informations + args = ["/usr/ccs/bin/elfdump", "-svy", binary_abspath] + elfdump_proc = subprocess.Popen( + args, + stdout=subprocess.PIPE, + stderr=subprocess.PIPE) + stdout, stderr = elfdump_proc.communicate() + retcode = elfdump_proc.wait() + if retcode or stderr: + logging.error("%s returned one or more errors: %s", args, stderr.splitlines()[0]) + continue + elfdump_out = stdout.splitlines() + + symbols = {} + binary_info = { 'version definition': [], + 'version needed': [], + 'symbol table': [] } + # we will merge syminfo and symbol table information in one list + # so the syminfo list is the same as the symbol table one + binary_info['syminfo'] = binary_info['symbol table'] + + # The list of fields we want to retrieve in the elfdump output by section + # if the field is a tuple, it means we will map the original field name + # to another name in the final data structure + elf_fields = { 'version defined': [ 'version', 'dependency' ], + 'version needed': [ ('file', 'soname'), 'version' ], + 'symbol table': [ ('name', 'symbol'), ('ver', 'version'), + 'bind', ('shndx', 'external') ], + 'syminfo': [ ('library', 'soname'), 'symbol', 'flags' ] } + + cur_section = None + for line in elfdump_out: + + elfdump_data, cur_section = self._ParseElfdumpLine(line, cur_section) + + # header or blank line contains no information + if not elfdump_data: + continue + + elf_info = {} + for field in elf_fields[cur_section]: + if type(field) == tuple: + elf_info[field[1]] = elfdump_data[field[0]] + else: + elf_info[field] = elfdump_data[field] + + # we merge symbol table and syminfo informations so we have to check + # if the symbol has not already been added + if cur_section in ('symbol table', 'syminfo'): + if elf_info['symbol'] in symbols: + symbols[elf_info['symbol']].update(elf_info) + continue + else: + symbols[elf_info['symbol']] = elf_info + + binary_info[cur_section].append(elf_info) + + # elfdump doesn't repeat the name of the soname in the version section + # if it's the same on two contiguous line, so we have to make sure + # the information is present in each entry + for i, version in enumerate(binary_info['version needed'][1:]): + if not version['soname']: + version['soname'] = binary_info['version needed'][i]['soname'] + + # if it exists, the first "version definition" entry is the base soname + # we don't need this information + if binary_info['version definition']: + binary_info['version definition'].pop(0) + + # To not rely of the section order output of elfdump, we resolve symbol version + # informations here after having parsed all elfdump output + nb_versions_definition = len(binary_info['version definition']) + for sym_info in binary_info['symbol table']: + version_index = int(sym_info['version']) - 2 + if version_index > 1: + if version_index < nb_versions_definition: + version = binary_info['version definition'][version_index] + else: + version = binary_info['version needed'][version_index - nb_versions_definition] + sym_info['version'] = version['version'] + sym_info['soname'] = version['soname'] + else: + sym_info['version'] = None + + if sym_info['external'] == 'UNDEF': + sym_info['external'] = True + else: + sym_info['external'] = False + + # we make sure the field are present even if the syminfo section is not + sym_info.setdefault('soname') + sym_info.setdefault('flags') + + binaries_elf_info[binary] = binary_info + + return binaries_elf_info + + @@ -263,7 +390,38 @@ sym = { 'address': fields[0], 'type': fields[1], 'name': fields[2] } return sym - def _ParseLddDashRline(self, line): + + def _ParseElfdumpLine(self, line, section = None): + + headers_re = (r'(?P
Version Needed|Version Definition|Symbol Table|Syminfo) Section:\s+(?:\.SUNW_version|\.dynsym|\.SUNW_syminfo)\s*$|' + '\s*(?:index\s+)?version\s+dependency\s*$|' + '\s*(?:index\s+)?file\s+version\s*$|' + '\s*index\s*value\s+size\s+type\s+bind\s+oth\s+ver\s+shndx\s+name\s*$|' + '\s*index\s+flags\s+bound to\s+symbol\s*$|' + '\s*$') + + re_by_section = { 'version definition': (r'\s*(?:\[(?P\d+)\]\s+)?(?P.*\S)\s+(?P\S+)?\s*$'), + 'version needed': (r'\s*(?:\[(?P\d+)\]\s+)?(?:(?P\S+)\s+(?!\[ (?:INFO|WEAK) \]))?(?P\S+)(?:\s+\[ (?:INFO|WEAK) \])?\s*$'), + 'symbol table': (r'\s*\[\d+\]\s+0x[0-9a-f]+\s+0x[0-9a-f]+\s+\S+\s+(?P\S+)\s+\S+\s+(?P\S+)\s+(?P\S+)\s+(?P\S+)?\s*$'), + 'syminfo': (r'\s*\[\d+\]\s+(?P[ABCDFILNPS]+)\s+(?:(?:\[\d+\]\s+(?P.*\S)|)\s+)?(?P.*\S)\s*') } + + if section: + m = re.match(re_by_section[section], line) + if m: + elfdump_data = m.groupdict() + return elfdump_data, section + + m = re.match(headers_re, line) + if not m: + raise package.StdoutSyntaxError("Could not parse %s" % (repr(line))) + + if m.lastindex: + section = m.group('section').lower() + + return None, section + -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: unused_soname_+_direct_binding_+_version_interface_checks.patch Type: application/octet-stream Size: 98359 bytes Desc: not available URL: From yann at pleiades.fr.eu.org Sat Sep 8 11:39:25 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sat, 8 Sep 2012 11:39:25 +0200 Subject: [csw-maintainers] Openssl migration: status update 4 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 6 packages are now waiting to be updated or dropped. Here are the remaining packages: - *boincclient, boinclibs and boincmanager*: Eric, the maintainer, didn't have time to work on the package as he wanted but he will start again on monday. - *postfix: *I had no answer from Juraj. As the updated package is just like the current one with the ssl dependy updated, it is likely that there will be no problem with the package. I will ping Juraj again, ask some tests for the new package on the user list (if I get no answer from Juraj), proceed to uploading the package (if I have positive or no feedback on the user mailinst-list). If someone has some time to test the package in my experimental repository, it would be great: pkgutil -t http://buildfarm.opencsw.org/opencsw/experimental/yann -i postfix - *courier_imap / courier_auth**: *no one stepped up to take over the se packages. I propose to drop them unless someone quickly takes over the maintenance. That will include maildrop as well. Here is what else happened since the last update: - *libgnomecups, libgnomeprint, libbonoboui and gnomevfs2: Only Dago tested the new packages. Well that was enough for me considering the number of packages concerned and I put them in openssl-relinking-group1. Tests by other maintainers would still be great to make sure we don't have problem. * - *hobbit: *Juergen told me we could drop hobbit now. He is working on xymon, hobbit's successor, but this could take some time. Thanks in advance for your help so we can we push this update soon. Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sat Sep 8 17:34:45 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 8 Sep 2012 16:34:45 +0100 Subject: [csw-maintainers] Openssl migration: status update 4 for group 1 In-Reply-To: References: Message-ID: Excellent work, thanks for the update! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Sun Sep 9 09:05:20 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 9 Sep 2012 09:05:20 +0200 Subject: [csw-maintainers] Buildfarm problem tonight fixed Message-ID: Hi, there was a problem with the buildfarm which I just fixed. The farm should be operable again. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From jh at opencsw.org Mon Sep 10 13:26:25 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Mon, 10 Sep 2012 13:26:25 +0200 Subject: [csw-maintainers] "Catalog not signed ..." Message-ID: <504DCE61.1080409@opencsw.org> Hi, who ever has the key. Please start the daemon again :) Greetings Jan From jh at opencsw.org Mon Sep 10 15:29:04 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Mon, 10 Sep 2012 15:29:04 +0200 Subject: [csw-maintainers] /opt/csw/ssl/openssl.cnf in CSWopenssl-utils In-Reply-To: References: Message-ID: <504DEB20.2010007@opencsw.org> Hi, what is the reason that CSWopenssl-utils still has an /opt/csw/ssl/openssl.cnf file and /etc/opt/csw/ssl/openssl.cnf.CSW. Just for compatibility? Or is this some hardcoded stuff somewhere that needs this?. Greetings Jan From dam at opencsw.org Thu Sep 13 13:23:54 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 13 Sep 2012 13:23:54 +0200 Subject: [csw-maintainers] Summercamp 9. - 11. November in Munich Message-ID: <3300C95C-341E-44F7-BAB9-BFBA3717795A@opencsw.org> Hi folks, I guess we have a date for the summer camp. It will be Friday, 9. November to Sunday 11. November in Lenggries near Munich, Germany. I have a rate of 124? per day including accommodation, all meals, room, beamer, wlan etc. It is valid until 29. September. Currently the following maintainers are positive on Doodle: - Me :-) - Peter Bonivart - Carsten Grzemba - Ben Walton If you intend to come please add yourself to the doodle poll during the next two weeks. Looking forward to meet you guys again! Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From dam at opencsw.org Fri Sep 14 12:55:47 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 14 Sep 2012 12:55:47 +0200 Subject: [csw-maintainers] Wiki page for camp is open Message-ID: Hi folks, I created the wiki page for the camp, feel free to edit it as you see fit: http://wiki.opencsw.org/summercamp-2012 Please everyone update their statuses and arrivals times. I also made some buzz on Munichs local Solaris user group. 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 Fri Sep 14 13:41:28 2012 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Fri, 14 Sep 2012 13:41:28 +0200 Subject: [csw-maintainers] Wiki page for camp is open In-Reply-To: References: Message-ID: <505317e8.dU6ELvhwZc7YcCYF%Joerg.Schilling@fokus.fraunhofer.de> Dagobert Michelsen wrote: > Hi folks, > > I created the wiki page for the camp, feel free to edit it as you see fit: > http://wiki.opencsw.org/summercamp-2012 > > Please everyone update their statuses and arrivals times. I also made some buzz on > Munichs local Solaris user group. Is this a summercap or a wintercamp? 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 Fri Sep 14 13:52:19 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 14 Sep 2012 13:52:19 +0200 Subject: [csw-maintainers] Wiki page for camp is open In-Reply-To: <505317e8.dU6ELvhwZc7YcCYF%Joerg.Schilling@fokus.fraunhofer.de> References: <505317e8.dU6ELvhwZc7YcCYF%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <1C16A43A-97FC-49BA-A13D-37B20C971088@opencsw.org> Hi J?rg, Am 14.09.2012 um 13:41 schrieb Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling): > Dagobert Michelsen wrote: >> I created the wiki page for the camp, feel free to edit it as you see fit: >> http://wiki.opencsw.org/summercamp-2012 >> >> Please everyone update their statuses and arrivals times. I also made some buzz on >> Munichs local Solaris user group. > > Is this a summercap or a wintercamp? It is in winter, but as the summer camp follow technically a winter camp and the last camp was a winter camp this is what I meant: http://wiki.opencsw.org/camps We are however 3 month late this year? Maybe we continue with a Summer Camp in summer again :-) Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From maciej at opencsw.org Mon Sep 17 15:03:36 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 17 Sep 2012 14:03:36 +0100 Subject: [csw-maintainers] ascii.io for packaging tutorials Message-ID: http://ascii.io/ ? We could use this to create a packaging tutorial. What do you think, Dago? From dam at opencsw.org Mon Sep 17 15:12:04 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 17 Sep 2012 15:12:04 +0200 Subject: [csw-maintainers] ascii.io for packaging tutorials In-Reply-To: References: Message-ID: <043E3798-DFC0-47BB-831D-DF25F7A7BAB5@opencsw.org> Hi Maciej, Am 17.09.2012 um 15:03 schrieb Maciej (Matchek) Blizi?ski : > http://ascii.io/ ? We could use this to create a packaging tutorial. > What do you think, Dago? Haha, this looks cool! Might be admin-like than the window-grab videocast. 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 Mon Sep 17 16:03:06 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 17 Sep 2012 16:03:06 +0200 Subject: [csw-maintainers] Direct binding now active In-Reply-To: <1345911801-sup-2797@pinkfloyd.chass.utoronto.ca> References: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> <8B21EC9D-F841-430B-B81E-00F41CE7792F@opencsw.org> <1345911801-sup-2797@pinkfloyd.chass.utoronto.ca> Message-ID: <00CBA899-4CD2-405D-BFB1-BAAB2D8C020D@opencsw.org> Hi, I just activated the proposed changes to linking in r19219. http://sourceforge.net/apps/trac/gar/changeset/19219 1. Stick to Solaris 10u8 by using a linker map: LINKER_MAPS ?= $(foreach MAP,$(LINKER_MAP_RELEASE) $(EXTRA_LINKER_MAPS),-M $(abspath $(GARDIR)/lib/map.$(LINKER_MAP_RELEASE))) # http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/mapfile-vers#301 libc.so - SUNW_1.22.5 SUNWprivate_1.1 $ADDVERS=SUNW_1.22.5; # http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libresolv2/common/mapfile-vers libresolv.so - SUNW_2.2 SUNWprivate_2.1 $ADDVERS=SUNW_2.2; # http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libnsl/common/mapfile-vers libnsl.so - SUNW_1.9.1 SUNWprivate_1.5 $ADDVERS=SUNW_1.9.1; 2. Default to direct linking LINKER_DIRECT ?= -B direct 3. Default to ignore unused library bindings LINKER_IGNORE ?= -z ignore The flags are documented in the variable reference and https://sourceforge.net/apps/trac/gar/wiki/Mapfiles 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 Mon Sep 17 21:54:48 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Mon, 17 Sep 2012 21:54:48 +0200 Subject: [csw-maintainers] Direct binding now active In-Reply-To: <00CBA899-4CD2-405D-BFB1-BAAB2D8C020D@opencsw.org> References: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> <8B21EC9D-F841-430B-B81E-00F41CE7792F@opencsw.org> <1345911801-sup-2797@pinkfloyd.chass.utoronto.ca> <00CBA899-4CD2-405D-BFB1-BAAB2D8C020D@opencsw.org> Message-ID: Great Dago ! I have rebuilt my packages with these options three weeks ago and I had no problem so far, so I don't think we will discover a lot of corner cases. It would be interesting to know the number of unecessary dependencies we will be able to remove thanks to the "-z ignore" option. Yann 2012/9/17 Dagobert Michelsen > Hi, > > I just activated the proposed changes to linking in r19219. > http://sourceforge.net/apps/trac/gar/changeset/19219 > > 1. Stick to Solaris 10u8 by using a linker map: > > LINKER_MAPS ?= $(foreach MAP,$(LINKER_MAP_RELEASE) $(EXTRA_LINKER_MAPS),-M > $(abspath $(GARDIR)/lib/map.$(LINKER_MAP_RELEASE))) > > # > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/mapfile-vers#301 > libc.so - SUNW_1.22.5 SUNWprivate_1.1 $ADDVERS=SUNW_1.22.5; > # > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libresolv2/common/mapfile-vers > libresolv.so - SUNW_2.2 SUNWprivate_2.1 $ADDVERS=SUNW_2.2; > # > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libnsl/common/mapfile-vers > libnsl.so - SUNW_1.9.1 SUNWprivate_1.5 $ADDVERS=SUNW_1.9.1; > > 2. Default to direct linking > > LINKER_DIRECT ?= -B direct > > 3. Default to ignore unused library bindings > > LINKER_IGNORE ?= -z ignore > > > > The flags are documented in the variable reference and > https://sourceforge.net/apps/trac/gar/wiki/Mapfiles > > > Best regards > > -- Dago > > > -- > "You don't become great by trying to be great, you become great by wanting > to do something, > and then doing it so hard that you become great in the process." - xkcd > #896 > > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jh at opencsw.org Tue Sep 18 09:27:01 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Tue, 18 Sep 2012 09:27:01 +0200 Subject: [csw-maintainers] Problems with mapfile and linking In-Reply-To: References: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> <8B21EC9D-F841-430B-B81E-00F41CE7792F@opencsw.org> <1345911801-sup-2797@pinkfloyd.chass.utoronto.ca> <00CBA899-4CD2-405D-BFB1-BAAB2D8C020D@opencsw.org> Message-ID: <50582245.4020309@opencsw.org> Hi, now with mapfile for libc 1.22.5 in place I have a problem with linking. The function fdatasync is defined in 1.22.7 but also since forever in librt. The auto* tool for samba do detect that correctly and add -lrt for linking. The Linker does still fails though with: Undefined first referenced symbol in file fdatasync ../lib/tdb/common/transaction.o (symbol belongs to unavailable version /lib/libc.so (SUNW_1.22.7)) First thought was that -ignore might be a problem here so I removed it didn't help. I can build samba without fdatasync but this might hit us again so I'm looking for a solution. There probably is none and it's a linker bug but I don't know for sure :) Greetings Jan From bwalton at opencsw.org Tue Sep 18 17:54:01 2012 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 18 Sep 2012 11:54:01 -0400 Subject: [csw-maintainers] Problems with mapfile and linking In-Reply-To: <50582245.4020309@opencsw.org> References: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> <8B21EC9D-F841-430B-B81E-00F41CE7792F@opencsw.org> <1345911801-sup-2797@pinkfloyd.chass.utoronto.ca> <00CBA899-4CD2-405D-BFB1-BAAB2D8C020D@opencsw.org> <50582245.4020309@opencsw.org> Message-ID: Hi Jan, Is autoconf detecting this properly for certain or just by happenstance due to other requirements? Is -lrt passed on the command line that is trying to build transaction.o? I wonder what the configure environment is doing with regard to the new linker maps? (It's likely doing the right thing but I haven't looked...) > The function fdatasync is defined in 1.22.7 but also since forever in > librt. The auto* tool for samba do detect that correctly and add -lrt > for linking. > The Linker does still fails though with: > > Undefined first referenced > symbol in file > fdatasync ../lib/tdb/common/transaction.o > (symbol belongs to unavailable version /lib/libc.so (SUNW_1.22.7)) > First thought was that -ignore might be a problem here so I removed it > didn't help. I wonder if this is an ordering issue of the -l parameters and the implicit -lc ? > I can build samba without fdatasync but this might hit us again so I'm > looking for a solution. There probably is none and it's a linker bug but > I don't know for sure :) And presumably that's a useful function for samba to use so disabling it doesn't seem like the best option either. Thanks -Ben From jh at opencsw.org Wed Sep 19 08:31:29 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Wed, 19 Sep 2012 08:31:29 +0200 Subject: [csw-maintainers] Problems with mapfile and linking In-Reply-To: References: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> <8B21EC9D-F841-430B-B81E-00F41CE7792F@opencsw.org> <1345911801-sup-2797@pinkfloyd.chass.utoronto.ca> <00CBA899-4CD2-405D-BFB1-BAAB2D8C020D@opencsw.org> <50582245.4020309@opencsw.org> Message-ID: <505966C1.9030004@opencsw.org> Hi, Am 18.09.12 17:54, schrieb Ben Walton: > Hi Jan, > > Is autoconf detecting this properly for certain or just by > happenstance due to other requirements? Is -lrt passed on the command > line that is trying to build transaction.o? I wonder what the > configure environment is doing with regard to the new linker maps? > (It's likely doing the right thing but I haven't looked...) What autoconf does is first check for it in libc. This fails do to mapfiles. Then it checks for it in -lrt which is positive and set to yes. So the checks here are doing the right thing. On not sure right now if autoconf does a linking check with -lrt or uses some other method. Because this should fail too which the same error I would guess. So something is done different here. I will have Dago poke at it :) > >> The function fdatasync is defined in 1.22.7 but also since forever in >> librt. The auto* tool for samba do detect that correctly and add -lrt >> for linking. >> The Linker does still fails though with: >> >> Undefined first referenced >> symbol in file >> fdatasync ../lib/tdb/common/transaction.o >> (symbol belongs to unavailable version /lib/libc.so (SUNW_1.22.7)) > >> First thought was that -ignore might be a problem here so I removed it >> didn't help. > > I wonder if this is an ordering issue of the -l parameters and the > implicit -lc ? > It might be. But I would guess -lc is always at first place so I don't know who you would order that. >> I can build samba without fdatasync but this might hit us again so I'm >> looking for a solution. There probably is none and it's a linker bug but >> I don't know for sure :) > > And presumably that's a useful function for samba to use so disabling > it doesn't seem like the best option either. Well it uses irrc fsync instead of fdatasync if it can't find it. If I looks at the right place of code fdatasync does call fsync in the end anyway it just takes other args or something. So I don't see any real difference here. Greetings Jan From jh at opencsw.org Wed Sep 19 14:05:06 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Wed, 19 Sep 2012 14:05:06 +0200 Subject: [csw-maintainers] bad rpath Message-ID: <5059B4F2.1020108@opencsw.org> Hi, having fun again with funny stuff. checkpkg failed with bad rpath: Checking the with elfdump I have: [26] RUNPATH 0xb4ae /opt/csw/lib/$ISALIST:/opt/csw/lib:/opt/csw/lib:-link=libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil:libavresample:/opt/csw/lib is this -link stuff something new? How to handle that? Greetings Jan From daniel at opencsw.org Thu Sep 20 15:55:30 2012 From: daniel at opencsw.org (Daniel Pocock) Date: Thu, 20 Sep 2012 15:55:30 +0200 Subject: [csw-maintainers] another attempt at reSIProcate / OpenSSL issue Message-ID: <505B2052.8020307@opencsw.org> I've had another go at building reSIProcte It fails with this (dislikes something from OpenSSL) on unstable10[xs] boxes: Error: Different types for "?:" (extern "C" void(*)(GENERAL_NAME_st*) and void(*)(GENERAL_NAME_st*)). and Google found other people having this issue with other projects: http://echelog.com/logs/browse/illumos/1324594800 Can anyone comment on this or the status of the OpenSSL package? libtool: compile: /opt/SUNWspro/bin/CC -DHAVE_CONFIG_H -I. -I../.. -I/opt/csw/bdb48/include -I/opt/csw/include -DRESIP_OSTYPE_SUNOS -DRESIP_ARCH_I386 -DRESIP_LARCH_IA32 -D_REENTRANT -DRESIP_TOOLCHAIN_SUNPRO -xO3 -m32 -xarch=pentium_pro -xchip=pentium_pro -c ssl/Security.cxx -KPIC -DPIC -o .libs/Security.o "ssl/Security.cxx", line 2315: Error: Different types for "?:" (extern "C" void(*)(GENERAL_NAME_st*) and void(*)(GENERAL_NAME_st*)). "ssl/Security.cxx", line 2315: Warning (Anachronism): Formal argument func of type extern "C" void(*)(void*) in call to sk_pop_free(stack_st*, extern "C" void(*)(void*)) is being passed void(*)(void*). "ssl/Security.cxx", line 2591: Error: Different types for "?:" (extern "C" void(*)(GENERAL_NAME_st*) and void(*)(GENERAL_NAME_st*)). "ssl/Security.cxx", line 2591: Warning (Anachronism): Formal argument func of type extern "C" void(*)(void*) in call to sk_pop_free(stack_st*, extern "C" void(*)(void*)) is being passed void(*)(void*). 2 Error(s) and 2 Warning(s) detected. gmake[4]: *** [Security.lo] Error 1 gmake[4]: Leaving directory `/home/daniel/opencsw/resiprocate/trunk/work/solaris10-i386/build-isa-pentium_pro/resiprocate-1.8.5/resip/stack' From dam at opencsw.org Sat Sep 22 16:21:58 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 22 Sep 2012 16:21:58 +0200 Subject: [csw-maintainers] Buildfarm inactive again Message-ID: <2535F718-9D40-4A6F-A148-5DD57E02D28B@opencsw.org> Hi folks, the buildfarm was unresponsive again and I had to reboot the machine carrying "login" and all sparc zones. I guess I need to set up resource controls now as it was the second time this happened, this will probably require another zone reboot in the next few days. Luckily I had just set up monitoring for the farm which notified me immediately... Best regards -- Dago From yann at pleiades.fr.eu.org Sat Sep 22 19:34:18 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sat, 22 Sep 2012 19:34:18 +0200 Subject: [csw-maintainers] another attempt at reSIProcate / OpenSSL issue In-Reply-To: <505B2052.8020307@opencsw.org> References: <505B2052.8020307@opencsw.org> Message-ID: Hi Daniel, What do you want to know about the status of Openssl ? I am not sure your problem is directly related to openssl. It seems to look like a type declaration mismatch. You could try to relaunch the command line used to compile ssl/Security.cxx with "-o .libs/Security.o" replaced with -E. This will output you the source code after preprocessing, you will be able to check more easily if there are some duplicate definition found in various headers file. Yann 2012/9/20 Daniel Pocock > > > > I've had another go at building reSIProcte > > It fails with this (dislikes something from OpenSSL) on unstable10[xs] > boxes: > > > Error: Different types for "?:" (extern "C" void(*)(GENERAL_NAME_st*) > and void(*)(GENERAL_NAME_st*)). > > > and Google found other people having this issue with other projects: > > http://echelog.com/logs/browse/illumos/1324594800 > > > Can anyone comment on this or the status of the OpenSSL package? > > > > > libtool: compile: /opt/SUNWspro/bin/CC -DHAVE_CONFIG_H -I. -I../.. > -I/opt/csw/bdb48/include -I/opt/csw/include -DRESIP_OSTYPE_SUNOS > -DRESIP_ARCH_I386 -DRESIP_LARCH_IA32 -D_REENTRANT > -DRESIP_TOOLCHAIN_SUNPRO -xO3 -m32 -xarch=pentium_pro -xchip=pentium_pro > -c ssl/Security.cxx -KPIC -DPIC -o .libs/Security.o > "ssl/Security.cxx", line 2315: Error: Different types for "?:" (extern > "C" void(*)(GENERAL_NAME_st*) and void(*)(GENERAL_NAME_st*)). > "ssl/Security.cxx", line 2315: Warning (Anachronism): Formal argument > func of type extern "C" void(*)(void*) in call to sk_pop_free(stack_st*, > extern "C" void(*)(void*)) is being passed void(*)(void*). > "ssl/Security.cxx", line 2591: Error: Different types for "?:" (extern > "C" void(*)(GENERAL_NAME_st*) and void(*)(GENERAL_NAME_st*)). > "ssl/Security.cxx", line 2591: Warning (Anachronism): Formal argument > func of type extern "C" void(*)(void*) in call to sk_pop_free(stack_st*, > extern "C" void(*)(void*)) is being passed void(*)(void*). > 2 Error(s) and 2 Warning(s) detected. > gmake[4]: *** [Security.lo] Error 1 > gmake[4]: Leaving directory > > `/home/daniel/opencsw/resiprocate/trunk/work/solaris10-i386/build-isa-pentium_pro/resiprocate-1.8.5/resip/stack' > _______________________________________________ > 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 Sep 22 20:37:32 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sat, 22 Sep 2012 20:37:32 +0200 Subject: [csw-maintainers] bad rpath In-Reply-To: <5059B4F2.1020108@opencsw.org> References: <5059B4F2.1020108@opencsw.org> Message-ID: Hi Jan, This part seems really strange. How do you produce the binary with this RUNPATH ? Yann 2012/9/19 Jan Holzhueter > Hi, > having fun again with funny stuff. > > checkpkg failed with bad rpath: > > Checking the with elfdump I have: > > [26] RUNPATH 0xb4ae > > /opt/csw/lib/$ISALIST:/opt/csw/lib:/opt/csw/lib:-link=libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil:libavresample:/opt/csw/lib > > is this -link stuff something new? > How to handle that? > > 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 Sat Sep 22 20:50:28 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sat, 22 Sep 2012 20:50:28 +0200 Subject: [csw-maintainers] Openssl migration: status update 5 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 3 packages are now waiting to be updated or dropped and they all belong to one software. it's *boincclient, boinclibs and boincmanager*. I will ping Eric again but I think I will tell him that we will release the group 1 without waiting for its packages if he can't work on them quickly. This is not a critical package like postfix and the risk of side effects will be limited to its packages after we release all the softwares from group 1. Since the last update Juraj compiled and released *postfix* and I am currently removing *courier_imap, courier_auth and maildrop* from the mirrors as no one stepped up to take over the packages. So I will release the group 1 really soon. If you want to make sure that everything is ok, just install them on your computers: pkgutil -t http://buildfarm.opencsw.org/opencsw/experimental/openssl-relinking-group1-Uu Best regards, Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Sat Sep 22 21:36:13 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 22 Sep 2012 15:36:13 -0400 Subject: [csw-maintainers] Openssl migration: status update 5 for group 1 In-Reply-To: References: Message-ID: Hi Yann, Thanks for the update. I'm looking forward to the release if this set. Thanks -Ben On Sep 22, 2012 2:50 PM, "Yann Rouillard" wrote: > Hi everybody, > > Here is the last status update about the big ssl migration group 1 which > is still waiting to come out. > > Now only 3 packages are now waiting to be updated or dropped and they all > belong to one software. it's *boincclient, boinclibs and boincmanager*. > I will ping Eric again but I think I will tell him that we will release > the group 1 without waiting for its packages if he can't work on them > quickly. > This is not a critical package like postfix and the risk of side effects > will be limited to its packages after we release all the softwares from > group 1. > > Since the last update Juraj compiled and released *postfix* and I am > currently removing *courier_imap, courier_auth and maildrop* from the > mirrors as no one stepped up to take over the packages. > > > So I will release the group 1 really soon. If you want to make sure that > everything is ok, just install them on your computers: > pkgutil -t > http://buildfarm.opencsw.org/opencsw/experimental/openssl-relinking-group1-Uu > > > Best regards, > > Yann > > _______________________________________________ > 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 daniel at opencsw.org Sun Sep 23 12:07:25 2012 From: daniel at opencsw.org (Daniel Pocock) Date: Sun, 23 Sep 2012 12:07:25 +0200 Subject: [csw-maintainers] another attempt at reSIProcate / OpenSSL issue In-Reply-To: References: <505B2052.8020307@opencsw.org> Message-ID: <505EDF5D.3080504@opencsw.org> On 22/09/12 19:34, Yann Rouillard wrote: > Hi Daniel, > > What do you want to know about the status of Openssl ? I'm not certain it is any OpenSSL issue, but three things come to mind: - the code compiles on Linux and Windows - the same error was found in other projects (as per the Google results) - this code previously compiled on the OpenCSW build farm (about 3 months ago) although I agree that none of these things proves the code is fault-free > I am not sure your problem is directly related to openssl. It seems to look > like a type declaration mismatch. > You could try to relaunch the command line used to compile ssl/Security.cxx > with "-o .libs/Security.o" replaced with -E. This is the original code (line 2315): sk_GENERAL_NAME_pop_free(gens, GENERAL_NAME_free); This is the section of pre-processor output, I notice it puts the line number in the middle of the statement: sk_pop_free ( ( ( _STACK * ) ( 1 ? ( gens ) : ( struct stack_st_GENERAL_NAME * ) 0 ) ) , ( ( void ( * ) ( void * ) ) ( ( #2315 1 ? ( GENERAL_NAME_free ) : ( void ( * ) ( GENERAL_NAME * ) ) 0 ) ) ) ) ; and the error refers to `extern "C"', which leaves me thinking this has something to do with the way C code is mixed with C++. > > 2012/9/20 Daniel Pocock > >> >> >> >> I've had another go at building reSIProcte >> >> It fails with this (dislikes something from OpenSSL) on unstable10[xs] >> boxes: >> >> >> Error: Different types for "?:" (extern "C" void(*)(GENERAL_NAME_st*) >> and void(*)(GENERAL_NAME_st*)). >> >> >> and Google found other people having this issue with other projects: >> >> http://echelog.com/logs/browse/illumos/1324594800 >> >> >> Can anyone comment on this or the status of the OpenSSL package? >> >> >> >> >> libtool: compile: /opt/SUNWspro/bin/CC -DHAVE_CONFIG_H -I. -I../.. >> -I/opt/csw/bdb48/include -I/opt/csw/include -DRESIP_OSTYPE_SUNOS >> -DRESIP_ARCH_I386 -DRESIP_LARCH_IA32 -D_REENTRANT >> -DRESIP_TOOLCHAIN_SUNPRO -xO3 -m32 -xarch=pentium_pro -xchip=pentium_pro >> -c ssl/Security.cxx -KPIC -DPIC -o .libs/Security.o >> "ssl/Security.cxx", line 2315: Error: Different types for "?:" (extern >> "C" void(*)(GENERAL_NAME_st*) and void(*)(GENERAL_NAME_st*)). >> "ssl/Security.cxx", line 2315: Warning (Anachronism): Formal argument >> func of type extern "C" void(*)(void*) in call to sk_pop_free(stack_st*, >> extern "C" void(*)(void*)) is being passed void(*)(void*). >> "ssl/Security.cxx", line 2591: Error: Different types for "?:" (extern >> "C" void(*)(GENERAL_NAME_st*) and void(*)(GENERAL_NAME_st*)). >> "ssl/Security.cxx", line 2591: Warning (Anachronism): Formal argument >> func of type extern "C" void(*)(void*) in call to sk_pop_free(stack_st*, >> extern "C" void(*)(void*)) is being passed void(*)(void*). >> 2 Error(s) and 2 Warning(s) detected. >> gmake[4]: *** [Security.lo] Error 1 >> gmake[4]: Leaving directory >> >> `/home/daniel/opencsw/resiprocate/trunk/work/solaris10-i386/build-isa-pentium_pro/resiprocate-1.8.5/resip/stack' >> _______________________________________________ >> 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 jh at opencsw.org Sun Sep 23 12:13:35 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Sun, 23 Sep 2012 12:13:35 +0200 Subject: [csw-maintainers] bad rpath In-Reply-To: References: <5059B4F2.1020108@opencsw.org> Message-ID: <505EE0CF.3040809@opencsw.org> Hi, Am 22.09.12 20:37, schrieb Yann Rouillard: > This part seems really strange. > How do you produce the binary with this RUNPATH ? > I don't have an exact how :) Need to check next week what the linking options are. But it's lastet ffmpeg with gcc compiler and default gar settings :) I did add build64 and isaexec to the config since I wanted 64 bit binary. So no clue if this messed it up. Greetings Jan > > 2012/9/19 Jan Holzhueter > > > Hi, > having fun again with funny stuff. > > checkpkg failed with bad rpath: > > Checking the with elfdump I have: > > [26] RUNPATH 0xb4ae > /opt/csw/lib/$ISALIST:/opt/csw/lib:/opt/csw/lib:-link=libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil:libavresample:/opt/csw/lib > > is this -link stuff something new? > How to handle that? > > 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 daniel at opencsw.org Sun Sep 23 15:19:08 2012 From: daniel at opencsw.org (Daniel Pocock) Date: Sun, 23 Sep 2012 15:19:08 +0200 Subject: [csw-maintainers] another attempt at reSIProcate / OpenSSL issue In-Reply-To: <505EDF5D.3080504@opencsw.org> References: <505B2052.8020307@opencsw.org> <505EDF5D.3080504@opencsw.org> Message-ID: <505F0C4C.80202@opencsw.org> On 23/09/12 12:07, Daniel Pocock wrote: > On 22/09/12 19:34, Yann Rouillard wrote: >> Hi Daniel, >> >> What do you want to know about the status of Openssl ? > > > I'm not certain it is any OpenSSL issue, but three things come to mind: > - the code compiles on Linux and Windows > - the same error was found in other projects (as per the Google results) > - this code previously compiled on the OpenCSW build farm (about 3 > months ago) > > although I agree that none of these things proves the code is fault-free > >> I am not sure your problem is directly related to openssl. It seems to look >> like a type declaration mismatch. >> You could try to relaunch the command line used to compile ssl/Security.cxx >> with "-o .libs/Security.o" replaced with -E. > > This is the original code (line 2315): > > sk_GENERAL_NAME_pop_free(gens, GENERAL_NAME_free); > > This is the section of pre-processor output, I notice it puts the line > number in the middle of the statement: > > > sk_pop_free ( ( ( _STACK * ) ( 1 ? ( gens ) : ( struct > stack_st_GENERAL_NAME * ) 0 ) ) , ( ( void ( * ) ( void * ) ) ( ( > #2315 > 1 ? ( GENERAL_NAME_free ) : ( void ( * ) ( GENERAL_NAME * ) ) 0 ) ) ) ) ; > > and the error refers to `extern "C"', which leaves me thinking this has > something to do with the way C code is mixed with C++. > Just some further observations: GENERAL_NAME_free is defined using macros, particularly IMPLEMENT_ASN1_FUNCTIONS in v3_genn.c which eventually calls IMPLEMENT_ASN1_ALLOC_FUNCTIONS_fname in asn1t.h There is an existing OpenSSL bug report about OpenSSL not playing nicely with C++ on Solaris Sun Pro toolchain: http://rt.openssl.org/Ticket/Display.html?id=2308&user=guest&pass=guest and more examples of people running into similar types of problem... http://stackoverflow.com/questions/9402778/upgrading-openssl-results-in-compiler-error-with-sk-x509-pop-free I tried wrapping all the #include statements in extern "C" {}; but that didn't help me. > >> >> 2012/9/20 Daniel Pocock >> >>> >>> >>> >>> I've had another go at building reSIProcte >>> >>> It fails with this (dislikes something from OpenSSL) on unstable10[xs] >>> boxes: >>> >>> >>> Error: Different types for "?:" (extern "C" void(*)(GENERAL_NAME_st*) >>> and void(*)(GENERAL_NAME_st*)). >>> >>> >>> and Google found other people having this issue with other projects: >>> >>> http://echelog.com/logs/browse/illumos/1324594800 >>> >>> >>> Can anyone comment on this or the status of the OpenSSL package? >>> >>> >>> >>> >>> libtool: compile: /opt/SUNWspro/bin/CC -DHAVE_CONFIG_H -I. -I../.. >>> -I/opt/csw/bdb48/include -I/opt/csw/include -DRESIP_OSTYPE_SUNOS >>> -DRESIP_ARCH_I386 -DRESIP_LARCH_IA32 -D_REENTRANT >>> -DRESIP_TOOLCHAIN_SUNPRO -xO3 -m32 -xarch=pentium_pro -xchip=pentium_pro >>> -c ssl/Security.cxx -KPIC -DPIC -o .libs/Security.o >>> "ssl/Security.cxx", line 2315: Error: Different types for "?:" (extern >>> "C" void(*)(GENERAL_NAME_st*) and void(*)(GENERAL_NAME_st*)). >>> "ssl/Security.cxx", line 2315: Warning (Anachronism): Formal argument >>> func of type extern "C" void(*)(void*) in call to sk_pop_free(stack_st*, >>> extern "C" void(*)(void*)) is being passed void(*)(void*). >>> "ssl/Security.cxx", line 2591: Error: Different types for "?:" (extern >>> "C" void(*)(GENERAL_NAME_st*) and void(*)(GENERAL_NAME_st*)). >>> "ssl/Security.cxx", line 2591: Warning (Anachronism): Formal argument >>> func of type extern "C" void(*)(void*) in call to sk_pop_free(stack_st*, >>> extern "C" void(*)(void*)) is being passed void(*)(void*). >>> 2 Error(s) and 2 Warning(s) detected. >>> gmake[4]: *** [Security.lo] Error 1 >>> gmake[4]: Leaving directory >>> >>> `/home/daniel/opencsw/resiprocate/trunk/work/solaris10-i386/build-isa-pentium_pro/resiprocate-1.8.5/resip/stack' >>> _______________________________________________ >>> 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. ::. From bwalton at opencsw.org Mon Sep 24 03:46:00 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 23 Sep 2012 21:46:00 -0400 Subject: [csw-maintainers] offline for a few days Message-ID: Hi All, I'll be offline for a few days while I move so please be patient with any build farm requests as we'll have less time zone coverage. Thanks -Ben From jh at opencsw.org Mon Sep 24 09:46:08 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Mon, 24 Sep 2012 09:46:08 +0200 Subject: [csw-maintainers] Direct binding now active In-Reply-To: <00CBA899-4CD2-405D-BFB1-BAAB2D8C020D@opencsw.org> References: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> <8B21EC9D-F841-430B-B81E-00F41CE7792F@opencsw.org> <1345911801-sup-2797@pinkfloyd.chass.utoronto.ca> <00CBA899-4CD2-405D-BFB1-BAAB2D8C020D@opencsw.org> Message-ID: <50600FC0.3070104@opencsw.org> Hi, I got another bug because of libc Version. https://www.opencsw.org/mantis/view.php?id=5003 This time against 1.22.5 which is not present on Update 7. I did a quick check on which version of libc is used most of the time. Which is 1.22.2. I could not find any lib that uses .3 or .4 .5 is used again a few times. So I would suggest setting the mapfile for libc on default to 1.22.2 Greetings Jan Am 17.09.12 16:03, schrieb Dagobert Michelsen: > Hi, > > I just activated the proposed changes to linking in r19219. > http://sourceforge.net/apps/trac/gar/changeset/19219 > > 1. Stick to Solaris 10u8 by using a linker map: > > LINKER_MAPS ?= $(foreach MAP,$(LINKER_MAP_RELEASE) $(EXTRA_LINKER_MAPS),-M $(abspath $(GARDIR)/lib/map.$(LINKER_MAP_RELEASE))) > > # http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/mapfile-vers#301 > libc.so - SUNW_1.22.5 SUNWprivate_1.1 $ADDVERS=SUNW_1.22.5; > # http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libresolv2/common/mapfile-vers > libresolv.so - SUNW_2.2 SUNWprivate_2.1 $ADDVERS=SUNW_2.2; > # http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libnsl/common/mapfile-vers > libnsl.so - SUNW_1.9.1 SUNWprivate_1.5 $ADDVERS=SUNW_1.9.1; > > 2. Default to direct linking > > LINKER_DIRECT ?= -B direct > > 3. Default to ignore unused library bindings > > LINKER_IGNORE ?= -z ignore > > > > The flags are documented in the variable reference and > https://sourceforge.net/apps/trac/gar/wiki/Mapfiles > > > 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. ::. > From bonivart at opencsw.org Mon Sep 24 09:51:55 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 24 Sep 2012 09:51:55 +0200 Subject: [csw-maintainers] Direct binding now active In-Reply-To: <50600FC0.3070104@opencsw.org> References: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> <8B21EC9D-F841-430B-B81E-00F41CE7792F@opencsw.org> <1345911801-sup-2797@pinkfloyd.chass.utoronto.ca> <00CBA899-4CD2-405D-BFB1-BAAB2D8C020D@opencsw.org> <50600FC0.3070104@opencsw.org> Message-ID: On Mon, Sep 24, 2012 at 9:46 AM, Jan Holzhueter wrote: > Hi, > I got another bug because of libc Version. > https://www.opencsw.org/mantis/view.php?id=5003 > > This time against 1.22.5 which is not present on Update 7. > > I did a quick check on which version of libc is used most of the time. > Which is 1.22.2. > > I could not find any lib that uses .3 or .4 > .5 is used again a few times. > > So I would suggest setting the mapfile for libc on default to 1.22.2 I also think we shouldn't be so aggressive with this, after all it seems it's pretty common people don't update their systems that often. :) /peter From jh at opencsw.org Mon Sep 24 14:35:53 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Mon, 24 Sep 2012 14:35:53 +0200 Subject: [csw-maintainers] Buildfarm inactive again In-Reply-To: <2535F718-9D40-4A6F-A148-5DD57E02D28B@opencsw.org> References: <2535F718-9D40-4A6F-A148-5DD57E02D28B@opencsw.org> Message-ID: <506053A9.3070503@opencsw.org> Hi, as the farm is laggy somehow again. I looked what is causing this. I found one cause :) PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 15272 yann 25G 12G sleep 60 0 0:01:59 1.3% ar/1 root at ncsw [global]:/opt/bop/share/DTraceToolkit/Mem > ps -ef |grep 15272 yann 15272 15229 1 14:22:44 pts/12 2:11 ar r ../../libcrypto.a ui_err.o ui_lib.o ui_openssl.o ui_util.o ui_compat.o I guess yann needs some ressources limits when he builds openssl :) Greetings Jan Am 22.09.12 16:21, schrieb Dagobert Michelsen: > Hi folks, > > the buildfarm was unresponsive again and I had to reboot the machine carrying "login" > and all sparc zones. I guess I need to set up resource controls now as it was the second > time this happened, this will probably require another zone reboot in the next few days. > > Luckily I had just set up monitoring for the farm which notified me immediately... > > > 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. ::. > From jh at opencsw.org Mon Sep 24 16:24:12 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Mon, 24 Sep 2012 16:24:12 +0200 Subject: [csw-maintainers] openssl-relinking-group1 moved In-Reply-To: <506053A9.3070503@opencsw.org> References: <2535F718-9D40-4A6F-A148-5DD57E02D28B@opencsw.org> <506053A9.3070503@opencsw.org> Message-ID: <50606D0C.90308@opencsw.org> Hi, do to the long runtime introduced by the big group of packages the directory has been moved to: /home/experimental/openssl-relinking/openssl-relinking-group1 this will not generate a experimental catalog. If it's needed again let me know. Greetings Jan From dam at opencsw.org Mon Sep 24 19:09:23 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 24 Sep 2012 19:09:23 +0200 Subject: [csw-maintainers] Summercamp 9. - 11. November in Munich In-Reply-To: <3300C95C-341E-44F7-BAB9-BFBA3717795A@opencsw.org> References: <3300C95C-341E-44F7-BAB9-BFBA3717795A@opencsw.org> Message-ID: <42C62183-2B58-424E-ADF0-2615CE7DF03B@opencsw.org> Hi folks, Am 13.09.2012 um 13:23 schrieb Dagobert Michelsen : > I guess we have a date for the summer camp. It will be > Friday, 9. November to Sunday 11. November > in Lenggries near Munich, Germany. I have a rate of 124? per day > including accommodation, all meals, room, beamer, wlan etc. > It is valid until 29. September. The 29. is nearing and I need the definitive answers soon. Currently I have the following list from Doodle and Mail: - Peter Bonivart - Carsten Grzemba - Maciej Blizinski - Juraj Lutter - Ben Walton (maybe can't come) - Me :-) Please let me know in the next few days if you come so I can make the reservation. If you plan to come just for a day please let me know also so I can add you to the agenda. 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 jh at opencsw.org Tue Sep 25 13:36:09 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Tue, 25 Sep 2012 13:36:09 +0200 Subject: [csw-maintainers] Direct binding now active In-Reply-To: <50600FC0.3070104@opencsw.org> References: <1345908789-sup-3998@pinkfloyd.chass.utoronto.ca> <8B21EC9D-F841-430B-B81E-00F41CE7792F@opencsw.org> <1345911801-sup-2797@pinkfloyd.chass.utoronto.ca> <00CBA899-4CD2-405D-BFB1-BAAB2D8C020D@opencsw.org> <50600FC0.3070104@opencsw.org> Message-ID: <50619729.9050007@opencsw.org> With rev19286 the libc Version is now set to 1.22.2 Greetings Jan Am 24.09.12 09:46, schrieb Jan Holzhueter: > Hi, > I got another bug because of libc Version. > https://www.opencsw.org/mantis/view.php?id=5003 > > This time against 1.22.5 which is not present on Update 7. > > I did a quick check on which version of libc is used most of the time. > Which is 1.22.2. > > I could not find any lib that uses .3 or .4 > .5 is used again a few times. > > So I would suggest setting the mapfile for libc on default to 1.22.2 > > Greetings > Jan > > > > > > Am 17.09.12 16:03, schrieb Dagobert Michelsen: >> Hi, >> >> I just activated the proposed changes to linking in r19219. >> http://sourceforge.net/apps/trac/gar/changeset/19219 >> >> 1. Stick to Solaris 10u8 by using a linker map: >> >> LINKER_MAPS ?= $(foreach MAP,$(LINKER_MAP_RELEASE) $(EXTRA_LINKER_MAPS),-M $(abspath $(GARDIR)/lib/map.$(LINKER_MAP_RELEASE))) >> >> # http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/mapfile-vers#301 >> libc.so - SUNW_1.22.5 SUNWprivate_1.1 $ADDVERS=SUNW_1.22.5; >> # http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libresolv2/common/mapfile-vers >> libresolv.so - SUNW_2.2 SUNWprivate_2.1 $ADDVERS=SUNW_2.2; >> # http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libnsl/common/mapfile-vers >> libnsl.so - SUNW_1.9.1 SUNWprivate_1.5 $ADDVERS=SUNW_1.9.1; >> >> 2. Default to direct linking >> >> LINKER_DIRECT ?= -B direct >> >> 3. Default to ignore unused library bindings >> >> LINKER_IGNORE ?= -z ignore >> >> >> >> The flags are documented in the variable reference and >> https://sourceforge.net/apps/trac/gar/wiki/Mapfiles >> >> >> 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. ::. >> > From ihsan at opencsw.org Fri Sep 28 13:51:52 2012 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuIERvxJ9hbg==?=) Date: Fri, 28 Sep 2012 13:51:52 +0200 Subject: [csw-maintainers] Mail Services unavailable Message-ID: <50658F58.7010209@opencsw.org> Hi, I will update the packages on mail.opencsw.org this evening. That means, for about 30 minutes the services will be not available. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Fri Sep 28 21:40:09 2012 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Fri, 28 Sep 2012 21:40:09 +0200 Subject: [csw-maintainers] Mail Services unavailable In-Reply-To: <50658F58.7010209@opencsw.org> References: <50658F58.7010209@opencsw.org> Message-ID: <5065FD19.2020702@opencsw.org> Hi, Am 28.09.2012 13:51, schrieb ?hsan Do?an: > I will update the packages on mail.opencsw.org this evening. That means, > for about 30 minutes the services will be not available. Everything is up and running again. I've did a major clean up on the machine. If something isn't as you expect, please drop me a mail. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From yann at pleiades.fr.eu.org Sat Sep 29 14:48:44 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sat, 29 Sep 2012 14:48:44 +0200 Subject: [csw-maintainers] openssl migration: group 1 packages uploaded Message-ID: Unbelievable ! Incredible ! The dream comes true ! After nearly four months of efforts, the big first group of packages to update is now released ! I just uploaded the whole set in the unstable repository. Big thanks to every packagers involved !! I hope this is the last time we have this kind of migration thanks to direct binding. However there are still some glitches: - the dovecot package depends on both openssl 0.9.8 and openssl 1.0.0. Jake do you know the reason for this ? - the gnomeprint package now triggers an error with checkpkg (I don't understand why as it worked before) and during recompilation it now asks for a more recent libgnomecups (this is dark magic ! I suppose something changed in the build environment). I am currently fixing this. - the gthumb package also tiggers checkpkg errors because of a modification in the name of the libgnome and libgnomecanvas I think. Carsten, could you have a look at it ? Of course, it doesn't mean the migration is finished, there a lot of remaining package but most can be uploaded independently, which makes things easier. I will soon post an update about the status of these packages. Best regards, Yann From yann at pleiades.fr.eu.org Sat Sep 29 21:22:55 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sat, 29 Sep 2012 21:22:55 +0200 Subject: [csw-maintainers] bad rpath In-Reply-To: <505EE0CF.3040809@opencsw.org> References: <5059B4F2.1020108@opencsw.org> <505EE0CF.3040809@opencsw.org> Message-ID: Hi Jan, Here is your problem, the following option is used by gcc when linking ffmpeg: -Wl,-rpath-link=libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil:libavresample This will pass the following option to the linker: ,"-rpath-link=libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil:libavresample" The problem is that it is a GNU ld option and not a SUN ld option. However the "-rpath" option exists in SUN ld, so this option is understood by SUN ld as "-rpath -link=libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil:libavresample", hence the bad rpath. I committed a patch to remove the option which doesn't seem useful here. I also forced SUN strip to be used instead of GNU strip as the latter corrupts seems to corrupt a SUN specific elf section. I tested and it build fine, tell me if it works for you. Yann 2012/9/23 Jan Holzhueter : > Hi, > > Am 22.09.12 20:37, schrieb Yann Rouillard: >> This part seems really strange. >> How do you produce the binary with this RUNPATH ? >> > > I don't have an exact how :) Need to check next week what the linking > options are. But it's lastet ffmpeg with gcc compiler and default gar > settings :) > I did add build64 and isaexec to the config since I wanted 64 bit > binary. So no clue if this messed it up. > > Greetings > > Jan > > > > >> >> 2012/9/19 Jan Holzhueter > >> >> Hi, >> having fun again with funny stuff. >> >> checkpkg failed with bad rpath: >> >> Checking the with elfdump I have: >> >> [26] RUNPATH 0xb4ae >> /opt/csw/lib/$ISALIST:/opt/csw/lib:/opt/csw/lib:-link=libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil:libavresample:/opt/csw/lib >> >> is this -link stuff something new? >> How to handle that? >> >> 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. ::. From romeotheriault at opencsw.org Sat Sep 29 23:21:47 2012 From: romeotheriault at opencsw.org (Romeo Theriault) Date: Sat, 29 Sep 2012 11:21:47 -1000 Subject: [csw-maintainers] openssl migration: group 1 packages uploaded In-Reply-To: References: Message-ID: On Sat, Sep 29, 2012 at 2:48 AM, Yann Rouillard wrote: > Unbelievable ! Incredible ! The dream comes true ! > > After nearly four months of efforts, the big first group of packages > to update is now released ! > Great work! Thanks for your efforts. Romeo -------------- next part -------------- An HTML attachment was scrubbed... URL: