From jh at opencsw.org Mon Oct 1 09:59:32 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Mon, 01 Oct 2012 09:59:32 +0200 Subject: [csw-maintainers] bad rpath In-Reply-To: References: <5059B4F2.1020108@opencsw.org> <505EE0CF.3040809@opencsw.org> Message-ID: <50694D64.1040705@opencsw.org> Hi Am 29.09.12 21:22, schrieb Yann Rouillard: > 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. thank you for looking into it. Greetings Jan From grzemba at contac-dt.de Mon Oct 1 14:03:45 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Mon, 01 Oct 2012 14:03:45 +0200 Subject: [csw-maintainers] openssl migration: group 1 packages uploaded In-Reply-To: <742085d46aac.50698670@contac-dt.de> References: <742085d46aac.50698670@contac-dt.de> Message-ID: <7420f964f00.5069a2c1@contac-dt.de> I'll have a lock Am 29.09.12, schrieb Yann Rouillard : > > ?- 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 ? > > -- Carsten Grzemba -------------- next part -------------- An HTML attachment was scrubbed... URL: From opk at opencsw.org Tue Oct 2 18:56:50 2012 From: opk at opencsw.org (Oliver Kiddle) Date: Tue, 02 Oct 2012 18:56:50 +0200 Subject: [csw-maintainers] dbus machine IDs Message-ID: <29489.1349197010@thecus.kiddle.eu> On a newly installed server, I tried running gvim and it pops up with this message: Failed to contact configuration server; the most common cause is a missing or misconfigured D-Bus session bus daemon. See http://projects.gnome.org/gconf/ for information. (Details - 1: Failed to get connection to session: Cannot spawn a message bus without a machine-id: Unable to load /var/opt/csw/lib/dbus/machine-id: Failed to open file '/var/opt/csw/lib/dbus/machine-id': No such file or directory) Should that perhaps have been setup from the dbus package's postinstall. Or do I need to enable the dbus service somehow? Thanks Oliver From yann at pleiades.fr.eu.org Tue Oct 2 22:19:57 2012 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Tue, 2 Oct 2012 22:19:57 +0200 Subject: [csw-maintainers] Some direct binding "side effets" Message-ID: Hi everybody, FYI, I discovered two sort of side effects with direct binding: * Chrooted daemons Direct binding also enables lazy loading. This can cause problem with chrooted daemons, because they may try to load a library after the chroot step and, of course, they will not find the .so file in the chrooted environment (unless you put it on purpose). One fix is to just disable lazy loading: EXTRA_LD_OPTIONS += -z nolazyload Problem encountered with openssh: https://www.opencsw.org/mantis/view.php?id=5006 * Problem with GNU strip Some packages binaries are stripped using GNU strip, usually because they added /opt/csw/gnu in the path (to help with build systems requiring GNU tools). Unfortunately, GNU strip seems to corrupt the elf section added when direct binding is enabled (bug opened for that: https://www.opencsw.org/mantis/view.php?id=4994 ). I don't think it renders the binaries unusable but direct binding probably doesn't work as elfdump can't properly display the section anymore. The solution is to make sure GNU strip is not used. As it can corrupt a elf section, it's probably not a good idea to use it anyway. You can usually do this by defining STRIP=/usr/ccs/bin/strip in the build environment. Problem encountered with libgnomeprint and ffmpeg. I added some info about this on the wiki: http://wiki.opencsw.org/checkpkg-error-tags#no-direct-binding Yann From grzemba at contac-dt.de Thu Oct 4 08:12:31 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Thu, 04 Oct 2012 08:12:31 +0200 Subject: [csw-maintainers] dbus machine IDs In-Reply-To: <7420ca97a03.506d28af@contac-dt.de> References: <7420ca97a03.506d28af@contac-dt.de> Message-ID: <742093db5f09.506d44ef@contac-dt.de> I think postinstall is a good solution. There is the same (unsolved problem) an other(all) gnome products like evince, QT4, ... Am 02.10.12, schrieb Oliver Kiddle : > On a newly installed server, I tried running gvim and it pops up with this message: > > Failed to contact configuration server; the most common cause is a missing or misconfigured D-Bus session bus daemon. See http://projects.gnome.org/gconf/ for information. (Details -? 1: Failed to get connection to session: Cannot spawn a message bus without a machine-id: Unable to load /var/opt/csw/lib/dbus/machine-id: Failed to open file '/var/opt/csw/lib/dbus/machine-id': No such file or directory) > > Should that perhaps have been setup from the dbus package's postinstall. > Or do I need to enable the dbus service somehow? > > Thanks > > Oliver > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > > -- Carsten -------------- next part -------------- An HTML attachment was scrubbed... URL: From grzemba at contac-dt.de Thu Oct 4 15:27:27 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Thu, 04 Oct 2012 15:27:27 +0200 Subject: [csw-maintainers] can/should checkpkg prevent such problems? Message-ID: <7420ccbb2103.506daadf@contac-dt.de> on an installation after 4 months of build the package I got the following error: grzemba at test:~$ /opt/csw/gxx/bin/librecad ld.so.1: librecad: Schwerer Fehler: libgcc_s.so.1: Version 'GCC_4.0.0' nicht gefunden (ben?tigt von Datei /opt/csw/gxx/bin/librecad) ld.so.1: librecad: Schwerer Fehler: libgcc_s.so.1: ?ffnen fehlgeschlagen: Datei oder Verzeichnis nicht gefunden Killed (Abgebrochen) Can or should checkpkg recognise such problems? -- Carsten Grzemba -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Thu Oct 4 17:04:48 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 4 Oct 2012 16:04:48 +0100 Subject: [csw-maintainers] can/should checkpkg prevent such problems? In-Reply-To: <7420ccbb2103.506daadf@contac-dt.de> References: <7420ccbb2103.506daadf@contac-dt.de> Message-ID: 2012/10/4 Carsten Grzemba > on an installation after 4 months of build the package I got the following > error: > grzemba at test:~$ /opt/csw/gxx/bin/librecad > ld.so.1: librecad: Schwerer Fehler: libgcc_s.so.1: Version 'GCC_4.0.0' > nicht gefunden (ben?tigt von Datei /opt/csw/gxx/bin/librecad) > ld.so.1: librecad: Schwerer Fehler: libgcc_s.so.1: ?ffnen fehlgeschlagen: > Datei oder Verzeichnis nicht gefunden > Killed (Abgebrochen) > > Can or should checkpkg recognise such problems? > TL;DR while not impossible, it's not trivial and would require a change to the checkpkg database schema. Presumably an update to gcc broke librecad. To prevent this problem from happening, you would have to do one of these things: - check librecad during gcc update, which means the need to check the whole catalog - remember the state of the libgcc_s.so.1 file and e.g. throw an error when a symbol version goes away As a compromise, you could perform regular whole-catalog checks to see of there are any packages that haven't been updated, but are now broken. Also, to check the symbol versions, the database would need a direct, in-table representation of symbol versions. We don't have that at the moment. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Sun Oct 7 10:05:04 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 7 Oct 2012 09:05:04 +0100 Subject: [csw-maintainers] board vote Message-ID: Hi All, This is way overdue. It slipped through several cracks for a long time. Apologies for that. I mailed out the ballot to ack/nack the new board composition last night. Mine landed in the spam bin though, so if you're a member of the foundation, please check for a mail there. It will be From "Maciej at members3.stsa.info" with a subject "Board Composition (Acclamation Acceptance)." The vote will run from the 8th to the 15th. It's a single question ballot in a yes/no format. Thanks for voting! -Ben From jgoerzen at opencsw.org Tue Oct 9 00:27:43 2012 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Mon, 08 Oct 2012 15:27:43 -0700 Subject: [csw-maintainers] openssl migration: group 1 packages uploaded In-Reply-To: References: Message-ID: <5073535F.1080100@opencsw.org> On 09/29/12 05:48, Yann Rouillard wrote: > 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 ? It has to do with the ssl certificate generation during package generation. The section of the build recipe that does the cert generation needs to be reworked. I haven't changed that part since I took over the package/recipe. I will look into it. Thanks for your efforts! Here is a snippet of output of checkpkg: * Dependency issues of CSWdovecot: * CSWlibssl0-9-8 is needed by CSWdovecot, because: * - CSWdovecot contains u'/opt/csw/ssl/certs/dovecot.pem.CSW' which needs a base directory: u'/opt/csw/ssl/certs'. * - CSWdovecot contains u'/opt/csw/ssl/private/dovecot.pem.CSW' which needs a base directory: u'/opt/csw/ssl/private'. Jake From bwalton at opencsw.org Tue Oct 9 09:52:18 2012 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 9 Oct 2012 08:52:18 +0100 Subject: [csw-maintainers] openssl migration: group 1 packages uploaded In-Reply-To: <5073535F.1080100@opencsw.org> References: <5073535F.1080100@opencsw.org> Message-ID: > * Dependency issues of CSWdovecot: > * CSWlibssl0-9-8 is needed by CSWdovecot, because: > * - CSWdovecot contains u'/opt/csw/ssl/certs/dovecot.pem.CSW' which needs > a > base directory: u'/opt/csw/ssl/certs'. > * - CSWdovecot contains u'/opt/csw/ssl/private/dovecot.pem.CSW' which > needs > a base directory: u'/opt/csw/ssl/private'. Should that directory (and it's content) be split out from CSWlibssl-0-9-8 into a generic package then? I also wonder if the */dovecot.pem.CSW should be moved from a delivered file to a generated one? Also, is there any interest in a CAS to handle creating SSL certificates at installation time? I'd put one together if so. I have a few packages that could use it... Thanks -Ben From dam at opencsw.org Tue Oct 9 09:55:30 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 9 Oct 2012 09:55:30 +0200 Subject: [csw-maintainers] openssl migration: group 1 packages uploaded In-Reply-To: References: <5073535F.1080100@opencsw.org> Message-ID: <754DDBCB-E934-46DD-BAB3-C7C2EB505252@opencsw.org> Hi Ben, Am 09.10.2012 um 09:52 schrieb Ben Walton : >> * Dependency issues of CSWdovecot: >> * CSWlibssl0-9-8 is needed by CSWdovecot, because: >> * - CSWdovecot contains u'/opt/csw/ssl/certs/dovecot.pem.CSW' which needs >> a >> base directory: u'/opt/csw/ssl/certs'. >> * - CSWdovecot contains u'/opt/csw/ssl/private/dovecot.pem.CSW' which >> needs >> a base directory: u'/opt/csw/ssl/private'. > > Should that directory (and it's content) be split out from > CSWlibssl-0-9-8 into a generic package then? Why not let the directory be provided by both CSWlibssl0-9-8 and CSWlibssl1-0-0 ? If the permissions are the same it wouldn't matter. > I also wonder if the */dovecot.pem.CSW should be moved from a > delivered file to a generated one? > > Also, is there any interest in a CAS to handle creating SSL > certificates at installation time? I'd put one together if so. I > have a few packages that could use it Excellent idea! How would you handle the cn as it should match the DNS? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From bwalton at opencsw.org Tue Oct 9 10:39:13 2012 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 9 Oct 2012 09:39:13 +0100 Subject: [csw-maintainers] openssl migration: group 1 packages uploaded In-Reply-To: <754DDBCB-E934-46DD-BAB3-C7C2EB505252@opencsw.org> References: <5073535F.1080100@opencsw.org> <754DDBCB-E934-46DD-BAB3-C7C2EB505252@opencsw.org> Message-ID: Hi Dago, On Tue, Oct 9, 2012 at 8:55 AM, Dagobert Michelsen wrote: >> Should that directory (and it's content) be split out from >> CSWlibssl-0-9-8 into a generic package then? > > Why not let the directory be provided by both CSWlibssl0-9-8 and CSWlibssl1-0-0 ? > If the permissions are the same it wouldn't matter. If it were only the directory I'd agree with you. It's the files in the directory that make it worth splitting it out, I think. >> I also wonder if the */dovecot.pem.CSW should be moved from a >> delivered file to a generated one? >> >> Also, is there any interest in a CAS to handle creating SSL >> certificates at installation time? I'd put one together if so. I >> have a few packages that could uTSse it > > Excellent idea! How would you handle the cn as it should match the DNS? We should let the admins set that via a config file as we couldn't reliably determine this. Maybe they want the SSL cert to be defined with a a CN that is only CNAME'd to the primary DNS name of the system? The approach I took in apache for the dummy certificate was to feed it some obviously fake info. Maybe what we should do is setup basic dummy info and then allow overrides from a system config file: CN=$(hostname) COUNTRY=... STATE=... ... if [ -f /etc/opt/csw/cas-ssl.conf ]; then . /etc/opt/csw/cas-ssl.conf else echo "WARNING!!!" ... ... fi $do_the_cert_gen_stuff The locations for the private and public halves of the certificate would either need to be standardized into some directory or be configurable in the package. Also, we'd need to handle the package upgrade case where either the package generated file exists or has been replaced...neither case should see the files changed. I'm thinking that the file tagged with the cswssl CAS could specify the locations for the public/private locations and the CAS script would just install this file and take no action if the targets exist. Removal would never touch the certificates. The only real benefit to this approach over what we're currently doing is that it removes the postinstall or other delivery mechanism to a standardized framework. Many (most?) sites will likely place their own certs with proper signature chains so our delivery of the original file is only a nicety. Thoughts? Thanks -Ben From dam at opencsw.org Tue Oct 9 10:56:42 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 9 Oct 2012 10:56:42 +0200 Subject: [csw-maintainers] openssl migration: group 1 packages uploaded In-Reply-To: References: <5073535F.1080100@opencsw.org> <754DDBCB-E934-46DD-BAB3-C7C2EB505252@opencsw.org> Message-ID: Hi Ben, Am 09.10.2012 um 10:39 schrieb Ben Walton : > On Tue, Oct 9, 2012 at 8:55 AM, Dagobert Michelsen wrote: >>> Should that directory (and it's content) be split out from >>> CSWlibssl-0-9-8 into a generic package then? >> >> Why not let the directory be provided by both CSWlibssl0-9-8 and CSWlibssl1-0-0 ? >> If the permissions are the same it wouldn't matter. > > If it were only the directory I'd agree with you. It's the files in > the directory that make it worth splitting it out, I think. Ok. >>> I also wonder if the */dovecot.pem.CSW should be moved from a >>> delivered file to a generated one? >>> >>> Also, is there any interest in a CAS to handle creating SSL >>> certificates at installation time? I'd put one together if so. I >>> have a few packages that could uTSse it >> >> Excellent idea! How would you handle the cn as it should match the DNS? > > We should let the admins set that via a config file as we couldn't > reliably determine this. Like ssl_hostname in /etc/opt/csw/csw.conf defaulting to `hostname`.`domainname` ? > Maybe they want the SSL cert to be defined > with a a CN that is only CNAME'd to the primary DNS name of the > system? The approach I took in apache for the dummy certificate was > to feed it some obviously fake info. Maybe what we should do is setup > basic dummy info and then allow overrides from a system config file: > > CN=$(hostname) > COUNTRY=... > STATE=... > ... > > if [ -f /etc/opt/csw/cas-ssl.conf ]; then > . /etc/opt/csw/cas-ssl.conf Ah, ok, a specific ssl config file. Would also be ok. > else > echo "WARNING!!!" > ... > ... > fi > > $do_the_cert_gen_stuff > > The locations for the private and public halves of the certificate > would either need to be standardized into some directory or be > configurable in the package. I would put the certificate in the same directory as the CAS containing the cert descriptions > Also, we'd need to handle the package > upgrade case where either the package generated file exists or has > been replaced...neither case should see the files changed. I'm > thinking that the file tagged with the cswssl CAS could specify the > locations for the public/private locations and the CAS script would > just install this file and take no action if the targets exist. > Removal would never touch the certificates. Yes. And: Yes. > The only real benefit to this approach over what we're currently doing > is that it removes the postinstall or other delivery mechanism to a > standardized framework. Many (most?) sites will likely place their > own certs with proper signature chains so our delivery of the original > file is only a nicety. > > Thoughts? ATM lots of packages don't go the extra mile of generating a cert. I would think having secure-by-default would be good. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From grzemba at contac-dt.de Tue Oct 9 10:59:27 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Tue, 09 Oct 2012 10:59:27 +0200 Subject: [csw-maintainers] board vote In-Reply-To: References: Message-ID: <748092db48c6.5074038f@contac-dt.de> Sorry, I can't find this Email. Am 07.10.12, schrieb Ben Walton : > Hi All, > > This is way overdue.? It slipped through several cracks for a long > time.? Apologies for that. > > I mailed out the ballot to ack/nack the new board composition last > night.? Mine landed in the spam bin though, so if you're a member of > the foundation, please check for a mail there.? It will be From > "Maciej at members3.stsa.info" with a subject "Board Composition > (Acclamation Acceptance)." > > The vote will run from the 8th to the 15th.? It's a single question > ballot in a yes/no format. > > Thanks for voting! > -Ben > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > > -- Carsten Grzemba Tel.:?? +49 3677 64740 Mobil: +49 171 9749479 Fax:?? +49 3677 6474111 Email: carsten.grzemba at contac-dt.de contac Datentechnik GmbH -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilbury at opencsw.org Tue Oct 9 11:02:03 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Tue, 09 Oct 2012 11:02:03 +0200 Subject: [csw-maintainers] board vote In-Reply-To: <748092db48c6.5074038f@contac-dt.de> References: <748092db48c6.5074038f@contac-dt.de> Message-ID: <5073E80B.8060704@opencsw.org> On 10/09/2012 10:59 AM, Carsten Grzemba wrote: > Sorry, I can't find this Email. Me neither. -- Juraj Lutter From dam at opencsw.org Tue Oct 9 11:02:40 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 9 Oct 2012 11:02:40 +0200 Subject: [csw-maintainers] board vote In-Reply-To: <748092db48c6.5074038f@contac-dt.de> References: <748092db48c6.5074038f@contac-dt.de> Message-ID: <271F0345-D139-4501-8190-A8F64AE5AEE1@opencsw.org> Hi Carsten, Am 09.10.2012 um 10:59 schrieb Carsten Grzemba : > Sorry, I can't find this Email. This is because you don't seem to be a member of the association: http://wiki.opencsw.org/open-community-software-project-members Traditionally there has been a distinction of maintainers and members. You can apply informally by writing to board "I want to be a member" and it has never been declined ;-) @board: Should we unify the process that full maintainers are member by default? Best regards -- Dago > > Am 07.10.12, schrieb Ben Walton : >> >> Hi All, >> >> This is way overdue. It slipped through several cracks for a long >> time. Apologies for that. >> >> I mailed out the ballot to ack/nack the new board composition last >> night. Mine landed in the spam bin though, so if you're a member of >> the foundation, please check for a mail there. It will be From >> "Maciej at members3.stsa.info" with a subject "Board Composition >> (Acclamation Acceptance)." >> >> The vote will run from the 8th to the 15th. It's a single question >> ballot in a yes/no format. >> >> Thanks for voting! >> -Ben >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers >> .:: This mailing list's archive is public. ::. > -- > Carsten Grzemba > Tel.: +49 3677 64740 > Mobil: +49 171 9749479 > Fax: +49 3677 6474111 > Email: carsten.grzemba at contac-dt.de > contac Datentechnik GmbH _______________________________________________ > 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: From bwalton at opencsw.org Tue Oct 9 12:02:59 2012 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 9 Oct 2012 11:02:59 +0100 Subject: [csw-maintainers] board vote In-Reply-To: <271F0345-D139-4501-8190-A8F64AE5AEE1@opencsw.org> References: <748092db48c6.5074038f@contac-dt.de> <271F0345-D139-4501-8190-A8F64AE5AEE1@opencsw.org> Message-ID: > This is because you don't seem to be a member of the association: > http://wiki.opencsw.org/open-community-software-project-members > Traditionally there has been a distinction of maintainers and members. You > can apply > informally by writing to board "I want to be a member" and it has never been > declined ;-) > > @board: Should we unify the process that full maintainers are member by > default? I would say yes. I can't think of a situation where we'd like to exclude a maintainer from voting by default...and the opposite is easy to handle as the maintainer can simply not vote. The only precondition for voting, in my understanding, is that the maintainer must have at least one released package...By making these two groups overlap almost entirely, we could generate a voting roster with an SQL query in the web database which would be nice. Ihsan: I wonder if there is anything in the way the association was founded that precludes extending membership by default? Thanks -Ben From dam at opencsw.org Tue Oct 9 12:05:10 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 9 Oct 2012 12:05:10 +0200 Subject: [csw-maintainers] board vote In-Reply-To: References: <748092db48c6.5074038f@contac-dt.de> <271F0345-D139-4501-8190-A8F64AE5AEE1@opencsw.org> Message-ID: <285EDA4F-34A5-43F5-A135-54F7F709BF50@opencsw.org> Hi Ben, Am 09.10.2012 um 12:02 schrieb Ben Walton : >> This is because you don't seem to be a member of the association: >> http://wiki.opencsw.org/open-community-software-project-members >> Traditionally there has been a distinction of maintainers and members. You >> can apply >> informally by writing to board "I want to be a member" and it has never been >> declined ;-) >> >> @board: Should we unify the process that full maintainers are member by >> default? > > I would say yes. I can't think of a situation where we'd like to > exclude a maintainer from voting by default...and the opposite is easy > to handle as the maintainer can simply not vote. The only > precondition for voting, in my understanding, is that the maintainer > must have at least one released package...By making these two groups > overlap almost entirely, we could generate a voting roster with an SQL > query in the web database which would be nice. > > Ihsan: I wonder if there is anything in the way the association was > founded that precludes extending membership by default? The association can not "grab" you, you must apply for it by yourself. We could add this to maintainership application that you also apply for the association which will be granted after release of the first package. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From bwalton at opencsw.org Tue Oct 9 12:10:31 2012 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 9 Oct 2012 11:10:31 +0100 Subject: [csw-maintainers] board vote In-Reply-To: <285EDA4F-34A5-43F5-A135-54F7F709BF50@opencsw.org> References: <748092db48c6.5074038f@contac-dt.de> <271F0345-D139-4501-8190-A8F64AE5AEE1@opencsw.org> <285EDA4F-34A5-43F5-A135-54F7F709BF50@opencsw.org> Message-ID: > The association can not "grab" you, you must apply for it by yourself. We could > add this to maintainership application that you also apply for the association > which will be granted after release of the first package. Maybe we should make it so that you're not applying to be a maintainer at all. You're applying to be a member which grants the rights to be a maintainer? It's a change in the semantics of an application. This would remove the distinction almost entirely, which I think would be a good thing. Does anyone see an issue with such a change? Thanks -Ben From pfelecan at opencsw.org Tue Oct 9 19:30:57 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 09 Oct 2012 19:30:57 +0200 Subject: [csw-maintainers] board vote In-Reply-To: (Ben Walton's message of "Tue, 9 Oct 2012 11:10:31 +0100") References: <748092db48c6.5074038f@contac-dt.de> <271F0345-D139-4501-8190-A8F64AE5AEE1@opencsw.org> <285EDA4F-34A5-43F5-A135-54F7F709BF50@opencsw.org> Message-ID: Ben Walton writes: >> The association can not "grab" you, you must apply for it by yourself. We could >> add this to maintainership application that you also apply for the association >> which will be granted after release of the first package. > > Maybe we should make it so that you're not applying to be a maintainer > at all. You're applying to be a member which grants the rights to be > a maintainer? It's a change in the semantics of an application. This > would remove the distinction almost entirely, which I think would be a > good thing. > > Does anyone see an issue with such a change? I think that an active maintainer can apply for membership which grants the right of vote in the foundation. It must be a voluntary adhesion and not a by default one. -- Peter From bwalton at opencsw.org Tue Oct 9 23:02:23 2012 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 9 Oct 2012 22:02:23 +0100 Subject: [csw-maintainers] board vote In-Reply-To: References: <748092db48c6.5074038f@contac-dt.de> <271F0345-D139-4501-8190-A8F64AE5AEE1@opencsw.org> <285EDA4F-34A5-43F5-A135-54F7F709BF50@opencsw.org> Message-ID: > I think that an active maintainer can apply for membership which grants > the right of vote in the foundation. It must be a voluntary adhesion and > not a by default one. Ok, so this is essentially status quo. If people knew that becoming a maintainer also meant becoming a member do you see that as a problem or a deterrent to becoming a maintainer? Thanks -Ben From bwalton at opencsw.org Tue Oct 9 23:27:39 2012 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 9 Oct 2012 22:27:39 +0100 Subject: [csw-maintainers] openssl migration: group 1 packages uploaded In-Reply-To: References: <5073535F.1080100@opencsw.org> <754DDBCB-E934-46DD-BAB3-C7C2EB505252@opencsw.org> Message-ID: > ATM lots of packages don't go the extra mile of generating a cert. I would > think having secure-by-default would be good. Ok, I'll work on this over the next few days, including the GAR integration/documentation. Thanks -Ben From ihsan at opencsw.org Wed Oct 10 12:10:19 2012 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuIERvxJ9hbg==?=) Date: Wed, 10 Oct 2012 12:10:19 +0200 Subject: [csw-maintainers] board vote In-Reply-To: <285EDA4F-34A5-43F5-A135-54F7F709BF50@opencsw.org> References: <748092db48c6.5074038f@contac-dt.de> <271F0345-D139-4501-8190-A8F64AE5AEE1@opencsw.org> <285EDA4F-34A5-43F5-A135-54F7F709BF50@opencsw.org> Message-ID: <5075498B.6000208@opencsw.org> On 10/09/2012 12:05 PM, Dagobert Michelsen wrote: >>> @board: Should we unify the process that full maintainers are member by >>> default? >> >> I would say yes. I can't think of a situation where we'd like to >> exclude a maintainer from voting by default...and the opposite is easy >> to handle as the maintainer can simply not vote. The only >> precondition for voting, in my understanding, is that the maintainer >> must have at least one released package...By making these two groups >> overlap almost entirely, we could generate a voting roster with an SQL >> query in the web database which would be nice. >> >> Ihsan: I wonder if there is anything in the way the association was >> founded that precludes extending membership by default? > > The association can not "grab" you, you must apply for it by yourself. We could > add this to maintainership application that you also apply for the association > which will be granted after release of the first package. This would probably the bests solution. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From grzemba at contac-dt.de Wed Oct 10 12:48:26 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Wed, 10 Oct 2012 12:48:26 +0200 Subject: [csw-maintainers] file with bad content Message-ID: <7480a22e2e6e.50756e9a@contac-dt.de> checkpkg reports: CHECKPKG_OVERRIDES_CSWlibqtgui4-gxx += file-with-bad-content|/usr/local|root/opt/csw/gxx/lib/libQtGui.so.4.8.1 CHECKPKG_OVERRIDES_CSWlibqtgui4-gxx += file-with-bad-content|/usr/share|root/opt/csw/gxx/lib/libQtGui.so.4.8.1 but if I do: $ find . -name libQtGui.so.4.8.1 | xargs grep -w local $ find . -name libQtGui.so.4.8.1 | xargs grep -w share nothing is found. How is that possible? -- Carsten -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Wed Oct 10 12:50:02 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 10 Oct 2012 12:50:02 +0200 Subject: [csw-maintainers] file with bad content In-Reply-To: <7480a22e2e6e.50756e9a@contac-dt.de> References: <7480a22e2e6e.50756e9a@contac-dt.de> Message-ID: Hi Carsten, Am 10.10.2012 um 12:48 schrieb Carsten Grzemba : > checkpkg reports: > > CHECKPKG_OVERRIDES_CSWlibqtgui4-gxx += file-with-bad-content|/usr/local|root/opt/csw/gxx/lib/libQtGui.so.4.8.1 > CHECKPKG_OVERRIDES_CSWlibqtgui4-gxx += file-with-bad-content|/usr/share|root/opt/csw/gxx/lib/libQtGui.so.4.8.1 > > but if I do: > $ find . -name libQtGui.so.4.8.1 | xargs grep -w local > $ find . -name libQtGui.so.4.8.1 | xargs grep -w share > nothing is found. > > How is that possible? Grep only searches some sections, try fgrep. And use | strings if necessary :-) Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Wed Oct 10 13:23:46 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 10 Oct 2012 13:23:46 +0200 Subject: [csw-maintainers] file with bad content In-Reply-To: <7480a22e2e6e.50756e9a@contac-dt.de> References: <7480a22e2e6e.50756e9a@contac-dt.de> Message-ID: 2012/10/10 Carsten Grzemba : > checkpkg reports: > > CHECKPKG_OVERRIDES_CSWlibqtgui4-gxx += > file-with-bad-content|/usr/local|root/opt/csw/gxx/lib/libQtGui.so.4.8.1 > CHECKPKG_OVERRIDES_CSWlibqtgui4-gxx += > file-with-bad-content|/usr/share|root/opt/csw/gxx/lib/libQtGui.so.4.8.1 > > > but if I do: > $ find . -name libQtGui.so.4.8.1 | xargs grep -w local > $ find . -name libQtGui.so.4.8.1 | xargs grep -w share > nothing is found. > > How is that possible? I vaguely remember that Sun grep handles ELF files in a special way. Try GNU grep. From grzemba at contac-dt.de Wed Oct 10 14:05:51 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Wed, 10 Oct 2012 14:05:51 +0200 Subject: [csw-maintainers] file with bad content In-Reply-To: References: <7480a22e2e6e.50756e9a@contac-dt.de> Message-ID: <7420a5cd7c8.507580bf@contac-dt.de> Thanks, fgrep has it found. Am 10.10.12, schrieb Maciej (Matchek) Blizi?ski : > 2012/10/10 Carsten Grzemba : > > checkpkg reports: > > > > CHECKPKG_OVERRIDES_CSWlibqtgui4-gxx += > > file-with-bad-content|/usr/local|root/opt/csw/gxx/lib/libQtGui.so.4.8.1 > > CHECKPKG_OVERRIDES_CSWlibqtgui4-gxx += > > file-with-bad-content|/usr/share|root/opt/csw/gxx/lib/libQtGui.so.4.8.1 > > > > > > but if I do: > > $ find . -name libQtGui.so.4.8.1 | xargs grep -w local > > $ find . -name libQtGui.so.4.8.1 | xargs grep -w share > > nothing is found. > > > > How is that possible? > > I vaguely remember that Sun grep handles ELF files in a special way. > Try GNU grep. > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > > -- Carsten Grzemba Tel.:?? +49 3677 64740 Mobil: +49 171 9749479 Fax:?? +49 3677 6474111 Email: carsten.grzemba at contac-dt.de contac Datentechnik GmbH -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillomovitch at opencsw.org Wed Oct 10 14:39:48 2012 From: guillomovitch at opencsw.org (Guillaume Rousse) Date: Wed, 10 Oct 2012 14:39:48 +0200 Subject: [csw-maintainers] openssl migration: group 1 packages uploaded In-Reply-To: References: <5073535F.1080100@opencsw.org> <754DDBCB-E934-46DD-BAB3-C7C2EB505252@opencsw.org> Message-ID: <50756C94.4060206@opencsw.org> Le 09/10/2012 23:27, Ben Walton a ?crit : >> ATM lots of packages don't go the extra mile of generating a cert. I would >> think having secure-by-default would be good. > > Ok, I'll work on this over the next few days, including the GAR > integration/documentation. As an inspiration source, here is the post-install helper used in mageia linux distribution for this purpose: http://svnweb.mageia.org/soft/rpm/rpm-helper/trunk/create-ssl-certificate?revision=2106&view=markup -- BOFH excuse #361: Communist revolutionaries taking over the server room and demanding all the computers in the building or they shoot the sysadmin. Poor misguided fools. From pfelecan at opencsw.org Wed Oct 10 19:56:30 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 10 Oct 2012 19:56:30 +0200 Subject: [csw-maintainers] board vote In-Reply-To: (Ben Walton's message of "Tue, 9 Oct 2012 22:02:23 +0100") References: <748092db48c6.5074038f@contac-dt.de> <271F0345-D139-4501-8190-A8F64AE5AEE1@opencsw.org> <285EDA4F-34A5-43F5-A135-54F7F709BF50@opencsw.org> Message-ID: Ben Walton writes: >> I think that an active maintainer can apply for membership which grants >> the right of vote in the foundation. It must be a voluntary adhesion and >> not a by default one. > > Ok, so this is essentially status quo. If people knew that becoming a > maintainer also meant becoming a member do you see that as a problem > or a deterrent to becoming a maintainer? I am for the status quo because I value the voluntary action. No, I don't think that becoming a member is a deterrent. -- Peter From bwalton at opencsw.org Wed Oct 10 20:35:27 2012 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 10 Oct 2012 19:35:27 +0100 Subject: [csw-maintainers] board vote In-Reply-To: References: <748092db48c6.5074038f@contac-dt.de> <271F0345-D139-4501-8190-A8F64AE5AEE1@opencsw.org> <285EDA4F-34A5-43F5-A135-54F7F709BF50@opencsw.org> Message-ID: On Wed, Oct 10, 2012 at 6:56 PM, Peter FELECAN wrote: > > I am for the status quo because I value the voluntary action. > > No, I don't think that becoming a member is a deterrent. Ok then let's do this: Maintain the current system but ensure we advertise the difference between maintainer and member status at maintainer signup. Juraj, Carsten: Would you like be become members? Thanks -Ben From pfelecan at opencsw.org Thu Oct 11 10:02:44 2012 From: pfelecan at opencsw.org (pfelecan at opencsw.org) Date: Thu, 11 Oct 2012 10:02:44 +0200 (CEST) Subject: [csw-maintainers] ld: fatal: file /lib/libresolv.so: version 'SUNW_2.2.2' is unavailable Message-ID: <2b63e6791fb80689b99f0b82813a90a7.squirrel@mail.opencsw.org> During the packaging of the new release of Emacs I get the following message: ld: fatal: file /lib/libresolv.so: version 'SUNW_2.2.2' is unavailable: required by file /opt/csw/lib/libORBit-2.so.0 ld: fatal: file processing errors. No output written to temacs I tried to understand what's the issue with the map file but to no avail. Note that I succeeded to link by setting the following variables: LINKER_MAPS = LINKER_DIRECT = LINKER_IGNORE = Here is the full output for those interested: /opt/csw/bin/gcc-4.7 -std=gnu99 -Demacs -DHAVE_CONFIG_H -I. -I/peter/opencsw/emacs/trunk/work/build-isa-pentium_pro-features-gtk/emacs-24.2/src -I../lib -I/peter/opencsw/emacs/trunk/work/build-isa-pentium_pro-features-gtk/emacs-24.2/src/../lib -I/usr/openwin/include -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS -DXTHREADS -DXUSE_MTSAFE_API -I/opt/csw/include/gtk-2.0 -I/opt/csw/lib/gtk-2.0/include -I/opt/csw/include/atk-1.0 -I/opt/csw/include/cairo -I/opt/csw/include/gdk-pixbuf-2.0 -I/opt/csw/include/pango-1.0 -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -I/opt/csw/include/pixman-1 -I/opt/csw/include -I/opt/csw/include/freetype2 -I/opt/csw/include/libpng12 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DXTHREADS -DXUSE_MTSAFE_API -I/opt/csw/include -I/opt/csw/include/freetype2 -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS -DXTHREADS -DXUSE_MTSAFE_API -I/opt/csw/include/librsvg-2.0 -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -I/opt/csw/include/gdk-pixbuf-2.0 -I/opt/csw/include/cairo -I/opt/csw/include/libpng12 -I/opt/csw/include/pixman-1 -I/opt/csw/include -I/opt/csw/include/freetype2 -I/opt/csw/include/ImageMagick -I/opt/csw/include/libxml2 -I/opt/csw/include/dbus-1.0 -I/opt/csw/lib/dbus-1.0/include -D_REENTRANT -D_PTHREADS -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -DORBIT2=1 -D_REENTRANT -D_PTHREADS -I/opt/csw/include/gconf/2 -I/opt/csw/include/orbit-2.0 -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -I/opt/csw/include/freetype2 -I/opt/csw/include -I/opt/csw/include -I/opt/csw/include/freetype2 -I/opt/csw/include -I/opt/csw/include -I/opt/csw/include -Wimplicit-function-declaration -Wold-style-definition -Wdeclaration-after-statement -O2 -pipe -m32 -march=pentiumpro -m32 -march=pentiumpro -L/opt/csw/lib -Wl,-znocombreloc -L/usr/openwin/lib \ -o temacs dispnew.o frame.o scroll.o xdisp.o menu.o xmenu.o window.o charset.o coding.o category.o ccl.o character.o chartab.o bidi.o cm.o term.o terminal.o xfaces.o xterm.o xfns.o xselect.o xrdb.o fontset.o xsmfns.o fringe.o image.o xsettings.o xgselect.o gtkutil.o dbusbind.o emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o font.o print.o lread.o syntax.o unexsol.o bytecode.o process.o gnutls.o callproc.o region-cache.o sound.o atimer.o doprnt.o intervals.o textprop.o composite.o xml.o xfont.o ftfont.o xftfont.o ftxfont.o terminfo.o lastfile.o ../lib/libgnu.a -L/opt/csw/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lpthread -lthread -lrt -lglib-2.0 -lintl -lSM -lICE -ltiff -ljpeg -lpng -lz -lm -lgif -lXpm -lX11 -lXrender -L/opt/csw/lib -lXft -lXrender -lfontconfig -lfreetype -lX11 -L/opt/csw/lib -lrsvg-2 -lm -lgio-2.0 -lgdk_pixbuf-2.0 -lcairo -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lpthread -lthread -lrt -lglib-2.0 -lintl -L/opt/csw/lib -lMagickWand -lMagickCore -L/opt/csw/lib -ldbus-1 -L/opt/csw/lib -lxml2 -lresolv -lsocket -lnsl -lncurses -L/opt/csw/lib -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lpthread -lthread -lrt -lglib-2.0 -lintl -L/opt/csw/lib -lgconf-2 -lglib-2.0 -lintl -L/opt/csw/lib -lfreetype -L/opt/csw/lib -lfontconfig -L/opt/csw/lib -lz -lbz2 -lotf -lfreetype -L/opt/csw/lib -lm17n-flt -lm17n-core -L/opt/csw/lib -lgnutls -lpthread -lm ld: fatal: file /lib/libresolv.so: version 'SUNW_2.2.2' is unavailable: required by file /opt/csw/lib/libORBit-2.so.0 ld: fatal: file processing errors. No output written to temacs From jh at opencsw.org Thu Oct 11 10:17:11 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Thu, 11 Oct 2012 10:17:11 +0200 Subject: [csw-maintainers] ld: fatal: file /lib/libresolv.so: version 'SUNW_2.2.2' is unavailable In-Reply-To: <2b63e6791fb80689b99f0b82813a90a7.squirrel@mail.opencsw.org> References: <2b63e6791fb80689b99f0b82813a90a7.squirrel@mail.opencsw.org> Message-ID: <50768087.3070909@opencsw.org> Hi, Am 11.10.12 10:02, schrieb pfelecan at opencsw.org: > During the packaging of the new release of Emacs I get the following message: > > ld: fatal: file /lib/libresolv.so: version 'SUNW_2.2.2' is unavailable: > required by file /opt/csw/lib/libORBit-2.so.0 > ld: fatal: file processing errors. No output written to temacs > > I tried to understand what's the issue with the map file but to no avail. > The Problem here is that libORBit-2.so (CSWorbit2) needs a rebuild since it uses functions that are not allowed by the mapfile. Greetings Jan From jh at opencsw.org Thu Oct 11 17:11:46 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Thu, 11 Oct 2012 17:11:46 +0200 Subject: [csw-maintainers] GCC Problem compile problem: was [csw-users] Is unstable catalog broken? In-Reply-To: References: <50755F2F.7020501@tbricks.com> <3F66FFB7-2A45-4AB8-A31F-33E340BBDA0B@opencsw.org> <50756E4E.2050504@tbricks.com> <519D9FA0-573F-4BA3-B080-19F1B6464BAF@opencsw.org> <55CE9B8F-94F3-4E8E-A45E-7E5B398BF2F8@opencsw.org> Message-ID: <5076E1B2.4090904@opencsw.org> Hi, lets take this back to maintainers. Am 10.10.12 17:14, schrieb Maciej (Matchek) Blizi?ski: > ld: fatal: relocation error: R_SPARC_32: file .libs/compatibility.o: > symbol __gxx_personality_v0: offset 0xe29b3 is non-aligned > ld: fatal: relocation error: R_SPARC_32: file > .libs/compatibility-atomic-c++0x.o: symbol __gxx_personality_v0: > offset 0xe2d9f is non-aligned Using google skills I found that most of the time a -g flag in gcc creates this problem. (e.g. http://stackoverflow.com/questions/7566044/error-when-compiling-simple-sparc-asm-math-code or http://prefetch.net/blog/index.php/2006/03/27/unaligned-symbols/ ) From bwalton at opencsw.org Fri Oct 12 21:32:22 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 12 Oct 2012 20:32:22 +0100 Subject: [csw-maintainers] [csw-pkgrequests] New package request : rsyslog In-Reply-To: <201210121921.q9CJLHRT013021@www.opencsw.org> References: <201210121921.q9CJLHRT013021@www.opencsw.org> Message-ID: Hi Sean, On Fri, Oct 12, 2012 at 8:21 PM, wrote: > Greetings! Love your work, just started using OpenCSW and it is sooo much nicer than the old sunfreeware I used to use. > > I was hoping you might be able to build rsyslog for Solaris with SMF hooks someday. There\'s a wiki at rsylog\'s site on solairs that mentions using opencsw tools for building - http://wiki.rsyslog.com/index.php/Solaris, but I\'m not a good package maintainer and I\'m not deep in the SMF stuff. I\'ve got both sparc and x64 platforms to deal with. I hope I\'m not the only one who\'s ever asked for this, but it would be nice to get all my systems running the same syslog daemon. There is a recent rsyslog package in our unstable catalog already: http://www.opencsw.org/packages/rsyslog/ We'll hopefully be able to move it to the dublin catalog in the near future but we're currently working our way through a large ssl rebuilding/relinking project. Thanks -Ben From bwalton at opencsw.org Tue Oct 16 10:55:20 2012 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 16 Oct 2012 09:55:20 +0100 Subject: [csw-maintainers] board vote In-Reply-To: References: Message-ID: Hi All, > The vote will run from the 8th to the 15th. It's a single question > ballot in a yes/no format. The vote ended last night at midnight. The results were 100% in favour of the new board composition (11 voters). Thanks to those who voted! We should arrange a meeting to do the financial "year" end summary that we did the last time. Maybe it could coincide with the summercamp? Thanks -Ben From jh at opencsw.org Wed Oct 17 12:49:27 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Wed, 17 Oct 2012 12:49:27 +0200 Subject: [csw-maintainers] need a custom map-file Message-ID: <507E8D37.8060900@opencsw.org> Hi, for mysql5.5 I need a custom mapfile. Since I need to bump libnsl to 1.9.1. Looking at http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/gar.conf.mk#L696 I don't get how to set it. If I set $(EXTRA_LINKER_MAPS-$(GAROSREL)) what do I need to set it to? just the mapfile or -M mapfile? and is -M $(abspath $(GARDIR)/lib/map.$(LINKER_MAP_RELEASE)) added too? so I have 2 map files used? That is to much magic for me :) Greetings Jan From dam at opencsw.org Wed Oct 17 21:07:20 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 17 Oct 2012 21:07:20 +0200 Subject: [csw-maintainers] Away from 19. to 29. October Message-ID: <9EAC4635-71BE-4710-BD2C-6FD227A3267D@opencsw.org> Hi folks, I will be away from 19. October to 29. October and probably have no time to take care of things. Please ask Woody for buildfarm issues. If there are any bug reports or package request it would be nice if any of you gentlemen could take care of it in the meantime :-) Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From bwalton at opencsw.org Wed Oct 17 23:18:27 2012 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 17 Oct 2012 22:18:27 +0100 Subject: [csw-maintainers] openssl migration: group 1 packages uploaded In-Reply-To: References: <5073535F.1080100@opencsw.org> <754DDBCB-E934-46DD-BAB3-C7C2EB505252@opencsw.org> Message-ID: Hi All, On Tue, Oct 9, 2012 at 10:27 PM, Ben Walton wrote: >> ATM lots of packages don't go the extra mile of generating a cert. I would >> think having secure-by-default would be good. > > Ok, I'll work on this over the next few days, including the GAR > integration/documentation. I think this is in reasonable shape now. Documentation here: http://wiki.opencsw.org/cswclassutils-package#toc31 I'm willing to pilot its use in the upcoming apache 2.4 packages but feel free to try it in your own packages. Feedback welcome. Thanks -Ben From jh at opencsw.org Thu Oct 18 17:41:34 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Thu, 18 Oct 2012 17:41:34 +0200 Subject: [csw-maintainers] map-file getpagesizes vs. getpagesizes2 In-Reply-To: References: <5073535F.1080100@opencsw.org> <754DDBCB-E934-46DD-BAB3-C7C2EB505252@opencsw.org> Message-ID: <5080232E.8000504@opencsw.org> Hi, I have a funny problem again: /usr/include/sys/mman.h defines this: #ifdef __PRAGMA_REDEFINE_EXTNAME #pragma redefine_extname getpagesizes getpagesizes2 #else #define getpagesizes getpagesizes2 #endif Which if I'm not wrong results in all getpagesizes calls be remapped to getpagesizes2 which the mapfile of libc does not allow since this is in version 1.22.5 Since I'm not good at this stuff. How do I unset this pragma? I would guess I should unset it in the code that uses getpagesizes? Greetings Jan From wilbury at opencsw.org Thu Oct 18 18:38:40 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Thu, 18 Oct 2012 18:38:40 +0200 Subject: [csw-maintainers] map-file getpagesizes vs. getpagesizes2 In-Reply-To: <5080232E.8000504@opencsw.org> References: <5073535F.1080100@opencsw.org> <754DDBCB-E934-46DD-BAB3-C7C2EB505252@opencsw.org> <5080232E.8000504@opencsw.org> Message-ID: <50803090.8080401@opencsw.org> On 10/18/2012 05:41 PM, Jan Holzhueter wrote: > > Hi, > I have a funny problem again: > > /usr/include/sys/mman.h > > defines this: > #ifdef __PRAGMA_REDEFINE_EXTNAME > #pragma redefine_extname getpagesizes getpagesizes2 > #else > #define getpagesizes getpagesizes2 > #endif > > Which if I'm not wrong results in all getpagesizes calls be remapped to > getpagesizes2 which the mapfile of libc does not allow since this is in > version 1.22.5 > > Since I'm not good at this stuff. How do I unset this pragma? > I would guess I should unset it in the code that uses getpagesizes? try to #define __STDC__ just my wild guess. -- Juraj Lutter From dam at opencsw.org Thu Oct 18 20:04:55 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 18 Oct 2012 20:04:55 +0200 Subject: [csw-maintainers] map-file getpagesizes vs. getpagesizes2 In-Reply-To: <50803090.8080401@opencsw.org> References: <5073535F.1080100@opencsw.org> <754DDBCB-E934-46DD-BAB3-C7C2EB505252@opencsw.org> <5080232E.8000504@opencsw.org> <50803090.8080401@opencsw.org> Message-ID: <5A87AC38-A4C4-4309-BDBB-288E0318B51F@opencsw.org> Hi, Am 18.10.2012 um 18:38 schrieb Juraj Lutter : > On 10/18/2012 05:41 PM, Jan Holzhueter wrote: >> I have a funny problem again: >> >> /usr/include/sys/mman.h >> >> defines this: >> #ifdef __PRAGMA_REDEFINE_EXTNAME >> #pragma redefine_extname getpagesizes getpagesizes2 >> #else >> #define getpagesizes getpagesizes2 >> #endif >> >> Which if I'm not wrong results in all getpagesizes calls be remapped to >> getpagesizes2 which the mapfile of libc does not allow since this is in >> version 1.22.5 >> >> Since I'm not good at this stuff. How do I unset this pragma? >> I would guess I should unset it in the code that uses getpagesizes? > > try to #define __STDC__ > > just my wild guess. I guess it is not that easy: If the pragma is available the definition is made as described in http://docs.oracle.com/cd/E19205-01/819-5265/bjacu/index.html The header basically means "use always get pagesizes2 where getpagesizes is used". It does not look like it is possible to revert this. It may be necessary to use a custom header first or one from an older Solaris release matching the older SUNW linker contract. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Thu Oct 18 20:06:27 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 18 Oct 2012 20:06:27 +0200 Subject: [csw-maintainers] map-file getpagesizes vs. getpagesizes2 In-Reply-To: <5A87AC38-A4C4-4309-BDBB-288E0318B51F@opencsw.org> References: <5073535F.1080100@opencsw.org> <754DDBCB-E934-46DD-BAB3-C7C2EB505252@opencsw.org> <5080232E.8000504@opencsw.org> <50803090.8080401@opencsw.org> <5A87AC38-A4C4-4309-BDBB-288E0318B51F@opencsw.org> Message-ID: Am 18.10.2012 um 20:04 schrieb Dagobert Michelsen : > Hi, > > Am 18.10.2012 um 18:38 schrieb Juraj Lutter : >> On 10/18/2012 05:41 PM, Jan Holzhueter wrote: >>> I have a funny problem again: >>> >>> /usr/include/sys/mman.h >>> >>> defines this: >>> #ifdef __PRAGMA_REDEFINE_EXTNAME >>> #pragma redefine_extname getpagesizes getpagesizes2 >>> #else >>> #define getpagesizes getpagesizes2 >>> #endif >>> >>> Which if I'm not wrong results in all getpagesizes calls be remapped to >>> getpagesizes2 which the mapfile of libc does not allow since this is in >>> version 1.22.5 >>> >>> Since I'm not good at this stuff. How do I unset this pragma? >>> I would guess I should unset it in the code that uses getpagesizes? >> >> try to #define __STDC__ >> >> just my wild guess. > > > I guess it is not that easy: If the pragma is available the definition is made as > described in > http://docs.oracle.com/cd/E19205-01/819-5265/bjacu/index.html > The header basically means "use always get pagesizes2 where getpagesizes is used". > It does not look like it is possible to revert this. It may be necessary to use a custom > header first or one from an older Solaris release matching the older SUNW linker contract. I guess you could try to use ?Xs mode and then redefine getpagesize2 back to getpagesize. Or provide a copy of the header file locally and add -I to EXTRA_CPPFLAGS. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From jh at opencsw.org Fri Oct 19 08:34:58 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Fri, 19 Oct 2012 08:34:58 +0200 Subject: [csw-maintainers] checkpkg error In-Reply-To: References: <5073535F.1080100@opencsw.org> <754DDBCB-E934-46DD-BAB3-C7C2EB505252@opencsw.org> <5080232E.8000504@opencsw.org> <50803090.8080401@opencsw.org> <5A87AC38-A4C4-4309-BDBB-288E0318B51F@opencsw.org> Message-ID: <5080F492.7000004@opencsw.org> Hi, on solaris 9 x86 checkpkg fails: NFO:root:Juicing the svr4 package stream files... WARNING:root:Error in hachoir_parser processing /tmp/pkg_0pG1H8/CSWlibmysqlclient18/root/opt/csw/lib/libmysqlclient.so.18.0.0: MissingField() 100% |#######################################################################################################| INFO:root:Unwrapping candies... 100% |#######################################################################################################| INFO:root:Tasting candies one by one... Traceback (most recent call last):######################################################################### | File "/home/jh/opencsw/.buildsys/v2/gar//bin/checkpkg", line 197, in main() File "/home/jh/opencsw/.buildsys/v2/gar//bin/checkpkg", line 158, in main exit_code, screen_report, tags_report = check_manager.Run() File "/home/jh/opencsw/.buildsys/v2/lib/python/checkpkg_lib.py", line 828, in Run return super(CheckpkgManager2, self).Run() File "/home/jh/opencsw/.buildsys/v2/lib/python/checkpkg_lib.py", line 236, in Run errors, messages, gar_lines = self.GetAllTags(self.sqo_pkgs_list) File "/home/jh/opencsw/.buildsys/v2/lib/python/checkpkg_lib.py", line 785, in GetAllTags function(pkg_data, check_interface, logger=logger, messenger=messenger) File "/home/jh/opencsw/.buildsys/v2/lib/python/package_checks.py", line 1024, in CheckWrongArchitecture machine = HACHOIR_MACHINES[file_metadata["machine_id"]] KeyError: 'machine_id' gmake: *** [pkgcheck] Error 2 Greetings Jan From jh at opencsw.org Fri Oct 19 08:43:43 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Fri, 19 Oct 2012 08:43:43 +0200 Subject: [csw-maintainers] map-file getpagesizes vs. getpagesizes2 In-Reply-To: References: <5073535F.1080100@opencsw.org> <754DDBCB-E934-46DD-BAB3-C7C2EB505252@opencsw.org> <5080232E.8000504@opencsw.org> <50803090.8080401@opencsw.org> <5A87AC38-A4C4-4309-BDBB-288E0318B51F@opencsw.org> Message-ID: <5080F69F.4080702@opencsw.org> Am 18.10.12 20:06, schrieb Dagobert Michelsen: > I guess you could try to use ?Xs mode and then redefine getpagesize2 back to getpagesize. > Or provide a copy of the header file locally and add -I to EXTRA_CPPFLAGS. -Xs did not work or I did not use it the right way. It broke lot of stuff :) I pulled the old header file from http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/mman.h?r=4426%3A1b5c93035912 looks like this is working. No error in the test suite of memchached (which has a big one) http://sourceforge.net/apps/trac/gar/changeset/19468 This hack should probably not be used for stuff like databases. Because this prevents to alloc e.g. real big pages like 1GB on AMD64 Systems etc. So atm mysql is build with getpagesizes2 and probably should stay this way. Database servers should be patched anyway :) Greetings Jan From maciej at opencsw.org Fri Oct 19 09:16:11 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 19 Oct 2012 09:16:11 +0200 Subject: [csw-maintainers] checkpkg error In-Reply-To: <5080F492.7000004@opencsw.org> References: <5073535F.1080100@opencsw.org> <754DDBCB-E934-46DD-BAB3-C7C2EB505252@opencsw.org> <5080232E.8000504@opencsw.org> <50803090.8080401@opencsw.org> <5A87AC38-A4C4-4309-BDBB-288E0318B51F@opencsw.org> <5080F492.7000004@opencsw.org> Message-ID: What is the missing machine id? All that needs to be done is adding the id to the hachoir machines dict. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jh at opencsw.org Fri Oct 19 09:22:40 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Fri, 19 Oct 2012 09:22:40 +0200 Subject: [csw-maintainers] checkpkg error In-Reply-To: References: <5073535F.1080100@opencsw.org> <754DDBCB-E934-46DD-BAB3-C7C2EB505252@opencsw.org> <5080232E.8000504@opencsw.org> <50803090.8080401@opencsw.org> <5A87AC38-A4C4-4309-BDBB-288E0318B51F@opencsw.org> <5080F492.7000004@opencsw.org> Message-ID: <5080FFC0.2010805@opencsw.org> Am 19.10.12 09:16, schrieb Maciej (Matchek) Blizi?ski: > What is the missing machine id? All that needs to be done is adding the > id to the hachoir machines dict. I don't know :) ? What does the id define? jh at unstable9x :/home/jh > uname -a SunOS unstable9x 5.9 Generic_122301-52 i86pc i386 i86pc Greetings Jan From maciej at opencsw.org Fri Oct 19 09:26:56 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 19 Oct 2012 09:26:56 +0200 Subject: [csw-maintainers] checkpkg error In-Reply-To: <5080FFC0.2010805@opencsw.org> References: <5073535F.1080100@opencsw.org> <754DDBCB-E934-46DD-BAB3-C7C2EB505252@opencsw.org> <5080232E.8000504@opencsw.org> <50803090.8080401@opencsw.org> <5A87AC38-A4C4-4309-BDBB-288E0318B51F@opencsw.org> <5080F492.7000004@opencsw.org> <5080FFC0.2010805@opencsw.org> Message-ID: You can find out by adding a print statement above the failing line. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jh at opencsw.org Fri Oct 19 09:55:33 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Fri, 19 Oct 2012 09:55:33 +0200 Subject: [csw-maintainers] ld: fatal: file /lib/libresolv.so: version 'SUNW_2.2.2' is unavailable In-Reply-To: <50768087.3070909@opencsw.org> References: <2b63e6791fb80689b99f0b82813a90a7.squirrel@mail.opencsw.org> <50768087.3070909@opencsw.org> Message-ID: <50810775.8040806@opencsw.org> Am 11.10.12 10:17, schrieb Jan Holzhueter: > > Hi, > > Am 11.10.12 10:02, schrieb pfelecan at opencsw.org: >> During the packaging of the new release of Emacs I get the following message: >> >> ld: fatal: file /lib/libresolv.so: version 'SUNW_2.2.2' is unavailable: >> required by file /opt/csw/lib/libORBit-2.so.0 >> ld: fatal: file processing errors. No output written to temacs >> >> I tried to understand what's the issue with the map file but to no avail. >> > > The Problem here is that libORBit-2.so (CSWorbit2) needs a rebuild since > it uses functions that are not allowed by the mapfile. I tried to rebuild it. But it fails since it uses inet_aton without any checks if it's there. inet_aton ("127.0.0.1", &ipv4_def_addr); Any special thoughts. Except to bump up the map file? Greetings Jan From bwalton at opencsw.org Fri Oct 19 10:11:30 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 19 Oct 2012 09:11:30 +0100 Subject: [csw-maintainers] ld: fatal: file /lib/libresolv.so: version 'SUNW_2.2.2' is unavailable In-Reply-To: <50810775.8040806@opencsw.org> References: <2b63e6791fb80689b99f0b82813a90a7.squirrel@mail.opencsw.org> <50768087.3070909@opencsw.org> <50810775.8040806@opencsw.org> Message-ID: > Any special thoughts. Except to bump up the map file? Are we possibly causing more problems than we're solving by using a mapfile to mimick the older solaris 10 environment? We've always "required" a current solaris version in the past and that has included update levels. Maybe we should just stick to that and drop the map files? Thanks -Ben From Joerg.Schilling at fokus.fraunhofer.de Fri Oct 19 10:22:21 2012 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Fri, 19 Oct 2012 10:22:21 +0200 Subject: [csw-maintainers] map-file getpagesizes vs. getpagesizes2 In-Reply-To: <50803090.8080401@opencsw.org> References: <5073535F.1080100@opencsw.org> <754DDBCB-E934-46DD-BAB3-C7C2EB505252@opencsw.org> <5080232E.8000504@opencsw.org> <50803090.8080401@opencsw.org> Message-ID: <50810dbd.+IpDyEJDVxQy5zzn%Joerg.Schilling@fokus.fraunhofer.de> Juraj Lutter wrote: > try to #define __STDC__ What do you expect from this? 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 wilbury at opencsw.org Fri Oct 19 10:26:07 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Fri, 19 Oct 2012 10:26:07 +0200 Subject: [csw-maintainers] map-file getpagesizes vs. getpagesizes2 In-Reply-To: <50810dbd.+IpDyEJDVxQy5zzn%Joerg.Schilling@fokus.fraunhofer.de> References: <5073535F.1080100@opencsw.org> <754DDBCB-E934-46DD-BAB3-C7C2EB505252@opencsw.org> <5080232E.8000504@opencsw.org> <50803090.8080401@opencsw.org> <50810dbd.+IpDyEJDVxQy5zzn%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <50810E9F.3010009@opencsw.org> On 10/19/2012 10:22 AM, Joerg Schilling wrote: > Juraj Lutter wrote: > >> try to #define __STDC__ > > What do you expect from this? I expect getpagesize not being redefined. But, it was just a quick guess after having a short glance into mman.h. > > J?rg > -- Juraj Lutter From bonivart at opencsw.org Fri Oct 19 10:26:56 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 19 Oct 2012 10:26:56 +0200 Subject: [csw-maintainers] ld: fatal: file /lib/libresolv.so: version 'SUNW_2.2.2' is unavailable In-Reply-To: References: <2b63e6791fb80689b99f0b82813a90a7.squirrel@mail.opencsw.org> <50768087.3070909@opencsw.org> <50810775.8040806@opencsw.org> Message-ID: On Fri, Oct 19, 2012 at 10:11 AM, Ben Walton wrote: >> Any special thoughts. Except to bump up the map file? > > Are we possibly causing more problems than we're solving by using a > mapfile to mimick the older solaris 10 environment? We've always > "required" a current solaris version in the past and that has included > update levels. Maybe we should just stick to that and drop the map > files? I also think we should simplify matters by building with the level we require of the users instead of faking it but I think it's important that current don't mean latest, it should be a few updates back. The update level we require should be announced on the web site. From bwalton at opencsw.org Fri Oct 19 10:45:13 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 19 Oct 2012 09:45:13 +0100 Subject: [csw-maintainers] ld: fatal: file /lib/libresolv.so: version 'SUNW_2.2.2' is unavailable In-Reply-To: References: <2b63e6791fb80689b99f0b82813a90a7.squirrel@mail.opencsw.org> <50768087.3070909@opencsw.org> <50810775.8040806@opencsw.org> Message-ID: > I also think we should simplify matters by building with the level we > require of the users instead of faking it but I think it's important > that current don't mean latest, it should be a few updates back. The > update level we require should be announced on the web site. Overall this is a good approach but it leaves us with the issue that if we build for u8, someone would need u5. What if, instead, we always build unstable on "current == latest" and then when we carve a stable release, we note the minimum level required there? The drawback to that is that we'd actually need to start carving the releases so that people could reasonably be expected to not run unstable on their production boxes. Thanks -Ben From bonivart at opencsw.org Fri Oct 19 11:11:51 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 19 Oct 2012 11:11:51 +0200 Subject: [csw-maintainers] ld: fatal: file /lib/libresolv.so: version 'SUNW_2.2.2' is unavailable In-Reply-To: References: <2b63e6791fb80689b99f0b82813a90a7.squirrel@mail.opencsw.org> <50768087.3070909@opencsw.org> <50810775.8040806@opencsw.org> Message-ID: On Fri, Oct 19, 2012 at 10:45 AM, Ben Walton wrote: > Overall this is a good approach but it leaves us with the issue that > if we build for u8, someone would need u5. I think the main problem today is that we don't state anywhere what we require of the user, that's what leads to problems for users, they don't get why this is happening and they ask of us to fix it because we never said they had to be up to date all the time. I think there should be a simple summary on the web site describing this and other things they may have to accept when using our packages. I asked for this from Phil too but it had to be super complicated so nothing ever happened. From jh at opencsw.org Fri Oct 19 11:47:42 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Fri, 19 Oct 2012 11:47:42 +0200 Subject: [csw-maintainers] ld: fatal: file /lib/libresolv.so: version 'SUNW_2.2.2' is unavailable In-Reply-To: References: <2b63e6791fb80689b99f0b82813a90a7.squirrel@mail.opencsw.org> <50768087.3070909@opencsw.org> <50810775.8040806@opencsw.org> Message-ID: <508121BE.7070605@opencsw.org> Hi, Am 19.10.12 11:11, schrieb Peter Bonivart: > On Fri, Oct 19, 2012 at 10:45 AM, Ben Walton wrote: >> Overall this is a good approach but it leaves us with the issue that >> if we build for u8, someone would need u5. > > I think the main problem today is that we don't state anywhere what we > require of the user, that's what leads to problems for users, they > don't get why this is happening and they ask of us to fix it because > we never said they had to be up to date all the time. > > I think there should be a simple summary on the web site describing > this and other things they may have to accept when using our packages. > I asked for this from Phil too but it had to be super complicated so > nothing ever happened. After I did look more into fixing it there is no way to get around the libresolv.so which depends on libnsl 1.9.1 (This is the case since update 5) unless we would downgrade our whole buildfarm. (Which will not work since we need T CPU Server Support which is not present in Update 5 iirc) So I agree we should put on the page that for all packages to function you need Update 5 Kernel installed. We should leave the map files in place though since if libresolv/libnsl is not used it then would work on an older Kernel Version. Greetings Jan From jh at opencsw.org Fri Oct 19 12:43:57 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Fri, 19 Oct 2012 12:43:57 +0200 Subject: [csw-maintainers] ld: fatal: file /lib/libresolv.so: version 'SUNW_2.2.2' is unavailable In-Reply-To: <50810775.8040806@opencsw.org> References: <2b63e6791fb80689b99f0b82813a90a7.squirrel@mail.opencsw.org> <50768087.3070909@opencsw.org> <50810775.8040806@opencsw.org> Message-ID: <50812EED.6030400@opencsw.org> Hi, Am 19.10.12 09:55, schrieb Jan Holzhueter: > Am 11.10.12 10:17, schrieb Jan Holzhueter: >> >> Hi, >> >> Am 11.10.12 10:02, schrieb pfelecan at opencsw.org: >>> During the packaging of the new release of Emacs I get the following message: >>> >>> ld: fatal: file /lib/libresolv.so: version 'SUNW_2.2.2' is unavailable: >>> required by file /opt/csw/lib/libORBit-2.so.0 >>> ld: fatal: file processing errors. No output written to temacs >>> >>> I tried to understand what's the issue with the map file but to no avail. >>> >> >> The Problem here is that libORBit-2.so (CSWorbit2) needs a rebuild since >> it uses functions that are not allowed by the mapfile. > > I tried to rebuild it. But it fails since it uses inet_aton without any > checks if it's there. > inet_aton ("127.0.0.1", &ipv4_def_addr); since there is no solution to the problem I changed the mapfile. so should be able to build Emacs now :) Greetings Jan From bwalton at opencsw.org Sat Oct 20 19:03:57 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 20 Oct 2012 18:03:57 +0100 Subject: [csw-maintainers] python library directory Message-ID: Hi All, I'm planning to tackle the python library directory move from /opt/csw/lib/python to /opt/csw/lib/python2.6 in order to remove some of the hurdles that modules may experience when working within the CSW environment. This will require rebuilding any package that delivers files into /opt/csw/lib/python. (Project page on the wiki is forthcoming.) In order to not hurt users of the package, I think that site.py will need to include /opt/csw/lib/python{,/site-packages} too. This could remove the need for a world rebuild but I'd rather that things we control don't depend on this hack. Some of our packages deliver files to the proper location already. I haven't looked at why this is yet but my suspicion is that it's due to them simply expecting the standard location rather than querying python to ask for it...these may or may not need to be re-rolled. Hopefully not. I'm willing to put in a pile of effort on this but once I have the base python packages re-rolled, I'd love it if you re-rolled any python modules you look after. I know that Maciej is already looking at python 3.x as the way forward and that's definitely the right choice for the long term...I'm hoping that this 2.x series fix will be a worthwhile effort for the short to medium term. Comments or feedback? Thanks -Ben From romeotheriault at opencsw.org Mon Oct 22 22:02:05 2012 From: romeotheriault at opencsw.org (Romeo Theriault) Date: Mon, 22 Oct 2012 10:02:05 -1000 Subject: [csw-maintainers] python library directory In-Reply-To: References: Message-ID: On Sat, Oct 20, 2012 at 7:03 AM, Ben Walton wrote: > Hi All, > > I'm planning to tackle the python library directory move from > /opt/csw/lib/python to /opt/csw/lib/python2.6 in order to remove some > of the hurdles that modules may experience when working within the CSW > environment. I'm not really clear on what the issue is. (?) Is it that some modules/tools expect the python2.6 directory but it's not there? This will require rebuilding any package that delivers > files into /opt/csw/lib/python. (Project page on the wiki is > forthcoming.) In order to not hurt users of the package, I think that > site.py will need to include /opt/csw/lib/python{,/site-packages} too. > This could remove the need for a world rebuild but I'd rather that > things we control don't depend on this hack. > This sounds fine to me. I'll keep an eye out for a email letting us know it's time to rebuild the modules. Thanks, Romeo > > Some of our packages deliver files to the proper location already. I > haven't looked at why this is yet but my suspicion is that it's due to > them simply expecting the standard location rather than querying > python to ask for it...these may or may not need to be re-rolled. > Hopefully not. > > I'm willing to put in a pile of effort on this but once I have the > base python packages re-rolled, I'd love it if you re-rolled any > python modules you look after. > > I know that Maciej is already looking at python 3.x as the way forward > and that's definitely the right choice for the long term...I'm hoping > that this 2.x series fix will be a worthwhile effort for the short to > medium term. > > Comments or feedback? > > Thanks > -Ben > _______________________________________________ > 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 romeotheriault at opencsw.org Mon Oct 22 22:03:32 2012 From: romeotheriault at opencsw.org (Romeo Theriault) Date: Mon, 22 Oct 2012 10:03:32 -1000 Subject: [csw-maintainers] python library directory In-Reply-To: References: Message-ID: On Mon, Oct 22, 2012 at 10:02 AM, Romeo Theriault < romeotheriault at opencsw.org> wrote: > On Sat, Oct 20, 2012 at 7:03 AM, Ben Walton wrote: > >> Hi All, >> >> I'm planning to tackle the python library directory move from >> /opt/csw/lib/python to /opt/csw/lib/python2.6 in order to remove some >> of the hurdles that modules may experience when working within the CSW >> environment. > > > I'm not really clear on what the issue is. (?) Is it that some > modules/tools expect the python2.6 directory but it's not there? > Nevermind, I just read your other email about the hack to get virtualenv working. :) Romeo -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Mon Oct 22 22:27:29 2012 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 22 Oct 2012 21:27:29 +0100 Subject: [csw-maintainers] python library directory In-Reply-To: References: Message-ID: On Mon, Oct 22, 2012 at 9:03 PM, Romeo Theriault wrote: > On Mon, Oct 22, 2012 at 10:02 AM, Romeo Theriault > wrote: >> >> On Sat, Oct 20, 2012 at 7:03 AM, Ben Walton wrote: >>> >>> Hi All, >>> >>> I'm planning to tackle the python library directory move from >>> /opt/csw/lib/python to /opt/csw/lib/python2.6 in order to remove some >>> of the hurdles that modules may experience when working within the CSW >>> environment. >> >> >> I'm not really clear on what the issue is. (?) Is it that some >> modules/tools expect the python2.6 directory but it's not there? > > > Nevermind, I just read your other email about the hack to get virtualenv > working. :) Yeah, it's a poor assumption that the modules are making but...I think the original idea to have a non-versioned python library directory is that it would alleviate the need to rebuild every module for a major version upgrade as most thins would work on newer versions (binary modules exempted). Either way, it's better to fix our python layout even though it will mean a lot of rebuilding. I extracted the list of affected packages today and will post them to the wiki project page shortly. Thanks -Ben -- --------------------------------------------------------------------------------------------------------------------------- Take the risk of thinking for yourself. Much more happiness, truth, beauty and wisdom will come to you that way. -Christopher Hitchens --------------------------------------------------------------------------------------------------------------------------- From claudio at opencsw.org Mon Oct 22 22:36:38 2012 From: claudio at opencsw.org (Claudio) Date: Mon, 22 Oct 2012 22:36:38 +0200 Subject: [csw-maintainers] python library directory In-Reply-To: References: Message-ID: On Mon, Oct 22, 2012 at 10:27 PM, Ben Walton wrote: > Yeah, it's a poor assumption that the modules are making but...I think > the original idea to have a non-versioned python library directory is > that it would alleviate the need to rebuild every module for a major > version upgrade as most thins would work on newer versions (binary > modules exempted). I am probably way off, but wouldn't non-versioned libraries/trees not lead to weird crashes? I imagine not all python releases are binary compatible... C. From bwalton at opencsw.org Mon Oct 22 22:55:50 2012 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 22 Oct 2012 21:55:50 +0100 Subject: [csw-maintainers] python library directory In-Reply-To: References: Message-ID: On Mon, Oct 22, 2012 at 9:36 PM, Claudio wrote: > On Mon, Oct 22, 2012 at 10:27 PM, Ben Walton wrote: >> Yeah, it's a poor assumption that the modules are making but...I think >> the original idea to have a non-versioned python library directory is >> that it would alleviate the need to rebuild every module for a major >> version upgrade as most thins would work on newer versions (binary >> modules exempted). > > I am probably way off, but wouldn't non-versioned libraries/trees not > lead to weird crashes? I imagine not all python releases are binary > compatible... I would expect so, yes. We're either lucky that all of our binary modules are built against 2.6 or nobody is using the ones that aren't. Thanks -Ben -- --------------------------------------------------------------------------------------------------------------------------- Take the risk of thinking for yourself. Much more happiness, truth, beauty and wisdom will come to you that way. -Christopher Hitchens --------------------------------------------------------------------------------------------------------------------------- From bwalton at opencsw.org Tue Oct 23 09:29:56 2012 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 23 Oct 2012 08:29:56 +0100 Subject: [csw-maintainers] python library directory In-Reply-To: References: Message-ID: On Sat, Oct 20, 2012 at 6:03 PM, Ben Walton wrote: > Hi All, > > I'm planning to tackle the python library directory move from > /opt/csw/lib/python to /opt/csw/lib/python2.6 in order to remove some > of the hurdles that modules may experience when working within the CSW > environment. This will require rebuilding any package that delivers > files into /opt/csw/lib/python. (Project page on the wiki is > forthcoming.) In order to not hurt users of the package, I think that > site.py will need to include /opt/csw/lib/python{,/site-packages} too. > This could remove the need for a world rebuild but I'd rather that > things we control don't depend on this hack. The project page for the python 2.x library directory fix is here: http://wiki.opencsw.org/project-python2libdir I have the base python packages rolled already. I'm planning to install it on one of testing boxes and then build some of the base module packages against it. Notably this base set would include anything required by checkpkg. Is anyone doing "python stuff" on the testing* boxes that this might affect? Details to follow as things get rolling... Thanks -Ben -- --------------------------------------------------------------------------------------------------------------------------- Take the risk of thinking for yourself. Much more happiness, truth, beauty and wisdom will come to you that way. -Christopher Hitchens --------------------------------------------------------------------------------------------------------------------------- From ghenry at opencsw.org Tue Oct 23 10:15:48 2012 From: ghenry at opencsw.org (Gerard Henry) Date: Tue, 23 Oct 2012 10:15:48 +0200 Subject: [csw-maintainers] python library directory In-Reply-To: References: Message-ID: <50865234.9030603@opencsw.org> On 10/20/12 19:03, Ben Walton wrote: > I know that Maciej is already looking at python 3.x as the way forward > and that's definitely the right choice for the long term...I'm hoping i hope that you'll continue to maintain python 2.X, because, actually, allthe scientific modules are not available for 3.x i guess thzat in our community, python is essentially used with scientific goals (matplotlib, numpy, scipy, etc...) thanks gerard From bwalton at opencsw.org Tue Oct 23 11:25:54 2012 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 23 Oct 2012 10:25:54 +0100 Subject: [csw-maintainers] python library directory In-Reply-To: <50865234.9030603@opencsw.org> References: <50865234.9030603@opencsw.org> Message-ID: On Tue, Oct 23, 2012 at 9:15 AM, Gerard Henry wrote: > On 10/20/12 19:03, Ben Walton wrote: >> >> I know that Maciej is already looking at python 3.x as the way forward >> and that's definitely the right choice for the long term...I'm hoping > > > i hope that you'll continue to maintain python 2.X, because, actually, > allthe scientific modules are not available for 3.x > i guess thzat in our community, python is essentially used with scientific > goals (matplotlib, numpy, scipy, etc...) This is my sense of the python world too. Python3 is definitely an improvement but it will be a long while yet before things are all either python3 or compatible with both 2 and 3. A former colleague has documented this in a few blog postings: http://utcc.utoronto.ca/~cks/space/blog/python/Python3MigrationMagnitude http://utcc.utoronto.ca/~cks/space/blog/python/MyPythonVersions So, at the very least, we'll want side by side 2 and 3 for some time. Thanks -Ben -- --------------------------------------------------------------------------------------------------------------------------- Take the risk of thinking for yourself. Much more happiness, truth, beauty and wisdom will come to you that way. -Christopher Hitchens --------------------------------------------------------------------------------------------------------------------------- From jh at opencsw.org Tue Oct 23 16:15:54 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Tue, 23 Oct 2012 16:15:54 +0200 Subject: [csw-maintainers] [csw-users] Node.js JavaScript interpreter missing In-Reply-To: References: <5085B1B3.40609@buffalo.edu> <5085B5EA.3040502@buffalo.edu> <5085BC82.5060804@buffalo.edu> <508634E4.1030706@opencsw.org> <50868543.7050203@buffalo.edu> Message-ID: <5086A69A.20704@opencsw.org> Am 23.10.12 16:11, schrieb Maciej (Matchek) Blizi?ski: > 2012/10/23 Ben Walton > > > We're planning to provide info for all catalogs in a nice web ui but > so far nobody has had the time/willingness to craft such a thing. > It's on the discussion list for our "summer" camp that is coming up > shortly though. In the meantime, I'll see about adding info to the > display pages to make the current situation clear. > > > I had this demo I wrote some time > ago: http://quinoa.blizinski.pl/~maciej/opencsw/test.html > > It's purely client-side, we can just drop that into the website and it > will work. The problem I see here is that the db is on the buildfarm :) Which if down would kill the webpage too. Greetings Jan From maciej at opencsw.org Tue Oct 23 16:31:40 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 23 Oct 2012 15:31:40 +0100 Subject: [csw-maintainers] [csw-users] Node.js JavaScript interpreter missing In-Reply-To: <5086A69A.20704@opencsw.org> References: <5085B1B3.40609@buffalo.edu> <5085B5EA.3040502@buffalo.edu> <5085BC82.5060804@buffalo.edu> <508634E4.1030706@opencsw.org> <50868543.7050203@buffalo.edu> <5086A69A.20704@opencsw.org> Message-ID: 2012/10/23 Jan Holzhueter > > > It's purely client-side, we can just drop that into the website and it > > will work. > > The problem I see here is that the db is on the buildfarm :) > Which if down would kill the webpage too. It wouldn't kill the page, it would be a graceful degradation - some fields would not show up, that's all. The website would still work just fine. From bonivart at opencsw.org Tue Oct 23 16:53:53 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 23 Oct 2012 16:53:53 +0200 Subject: [csw-maintainers] [csw-users] Node.js JavaScript interpreter missing In-Reply-To: References: <5085B1B3.40609@buffalo.edu> <5085B5EA.3040502@buffalo.edu> <5085BC82.5060804@buffalo.edu> <508634E4.1030706@opencsw.org> <50868543.7050203@buffalo.edu> <5086A69A.20704@opencsw.org> Message-ID: The package page itself fetches data from the database, doesn't it? Or is it statically generated? I know Phil thought we had so much hits we needed maximum performance but it would be so much simpler to let a php script do this dynamically. I think the looks of Maciej's demo is right with a clear table of available packages, the download links are a bonus. The list above the table should only contain generic package data, not data displayed in the table (typically version). /peter From bwalton at opencsw.org Wed Oct 24 00:53:55 2012 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 23 Oct 2012 23:53:55 +0100 Subject: [csw-maintainers] python library directory In-Reply-To: References: Message-ID: > Is anyone doing "python stuff" on the testing* boxes that this might affect? ...of course that means "anything" on those boxes as checkpkg is affected. I'm most of the way through the dep stack for it to function again but it's currently not working. If you need to revert these updates, please feel free to do so...otherwise I'll complete the python dependencies first thing tomorrow to get this working again. Thanks -Ben From dam at opencsw.org Mon Oct 29 15:16:57 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 29 Oct 2012 15:16:57 +0100 Subject: [csw-maintainers] dnssec and unbound Message-ID: Hi, I am just fiddling with the latest gnutls and got a configure time error: > DNSSEC root key file: /etc/unbound/root.key > > configure: WARNING: > *** > *** The DNSSEC root key file in /etc/unbound/root.key was not found. > *** This file is needed for the verification of DNSSEC responses. > *** Use the command: unbound-anchor -a "/etc/unbound/root.key" > *** to generate or update it. > *** Any advice on how we should handle this? Add the key to libunbound2? Ihsan? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From bwalton at opencsw.org Mon Oct 29 17:20:08 2012 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 29 Oct 2012 16:20:08 +0000 Subject: [csw-maintainers] dnssec and unbound In-Reply-To: References: Message-ID: Hi Dago, > I am just fiddling with the latest gnutls and got a configure time error: > >> DNSSEC root key file: /etc/unbound/root.key Aside: Is gnutls assuming this path or picking it up from something delivered by the unbound packages? >> >> configure: WARNING: >> *** >> *** The DNSSEC root key file in /etc/unbound/root.key was not found. >> *** This file is needed for the verification of DNSSEC responses. >> *** Use the command: unbound-anchor -a "/etc/unbound/root.key" >> *** to generate or update it. >> *** > > Any advice on how we should handle this? Add the key to libunbound2? > Ihsan? My initial reaction to this was that including the "config" file in the library package wasn't the right thing to do, but after reading about it and thinking some more, I think your suggestion is ok. Originally I thought a -data package to deliver this (and similar files from unbound if they exist) might be a better option but that seems to heavy and counter-productive. The recipe for unbound could automate creating root.key at every re-spin using the procedure described here: http://www.unbound.net/documentation/howto_anchor.html Ihsan? Thanks -Ben From bwalton at opencsw.org Tue Oct 30 15:24:39 2012 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 30 Oct 2012 14:24:39 +0000 Subject: [csw-maintainers] libsunperf Message-ID: Hi All, Following up on the thread below, I've just pushed a pair of libsunperf packages to unstable. The .so versions are different between i386 and sparc but I opted to use the standard naming convention with a version number in the package name. This gives CSWlibsunperf2 (i386 -> amd64 only, actually) and CSWlibsunperf7 (sparc). If you'd like a generic name or a dummy package to pull in the appropriate version depending on platform, let me know. http://lists.opencsw.org/pipermail/maintainers/2010-October/012975.html I'll be doing time in a 9x9 cell with Dago and James if things go sour. :) Thanks -Ben From pfelecan at opencsw.org Tue Oct 30 19:57:45 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 30 Oct 2012 19:57:45 +0100 Subject: [csw-maintainers] libsunperf In-Reply-To: (Ben Walton's message of "Tue, 30 Oct 2012 14:24:39 +0000") References: Message-ID: Ben Walton writes: > I'll be doing time in a 9x9 cell with Dago and James if things go sour. :) What's that 9x9 cell ? -- Peter From dam at opencsw.org Tue Oct 30 20:28:05 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 30 Oct 2012 20:28:05 +0100 Subject: [csw-maintainers] libsunperf In-Reply-To: References: Message-ID: <68D92C32-1CC0-4923-8B7F-2C6BFF58F960@opencsw.org> Hi Peter, Am 30.10.2012 um 19:57 schrieb Peter FELECAN : > Ben Walton writes: > >> I'll be doing time in a 9x9 cell with Dago and James if things go sour. :) > > What's that 9x9 cell ? Hehe, just read the post from the link (hint: wearing stripes :-) Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From pfelecan at opencsw.org Wed Oct 31 11:09:18 2012 From: pfelecan at opencsw.org (pfelecan at opencsw.org) Date: Wed, 31 Oct 2012 11:09:18 +0100 (CET) Subject: [csw-maintainers] spam spam spam Message-ID: <38a36adbab16e39e8c09faaaca7d4531.squirrel@mail.opencsw.org> Lately we have a lot of spam on the buildfarm mailing list; the board's one is also full of it. Can we do something about? How can I help ? From jh at opencsw.org Wed Oct 31 14:27:27 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Wed, 31 Oct 2012 14:27:27 +0100 Subject: [csw-maintainers] [csw-users] Mozilla SpiderMonkey JavaScript interpreter binary missing In-Reply-To: <50902203.9040104@buffalo.edu> References: <508950B7.8040608@buffalo.edu> <5089559E.5010804@opencsw.org> <508A7AC8.3020807@opencsw.org> <508A7AF1.1090108@opencsw.org> <508B0393.9090607@buffalo.edu> <50902203.9040104@buffalo.edu> Message-ID: <5091273F.2060309@opencsw.org> Hi, could someone do that please? Or is dublin total frozen atm? The packages has no deps so should be fine to push the lib and the js bin. Thank you Greetings Jan Am 30.10.12 19:52, schrieb Lenny Miceli: > Hi Jan, > > Any idea when this will move to the current/stable branch? > > Thanks, > Lenny > > On 10/26/2012 05:41 PM, Lenny Miceli wrote: >> Thanks for working on this Jan. I now see the software in the unstable >> branch. When will it move to the current/stable branch? >> >> Thanks, >> Lenny >> >> On 10/26/2012 07:58 AM, Jan Holzhueter wrote: >>> Am 26.10.12 13:58, schrieb Jan Holzhueter: >>>> Hi, >>>> there is no a cswspidermonkey package in the unstable cataloge. >>> >>> This is a "now" >>> Coffee Time :) >>> >>> Greetings >>> >>> Jan >>> >>>> >>>> Am 25.10.12 18:55, schrieb Maciej (Matchek) Blizi?ski: >>>>> 2012/10/25 Ben Walton : >>>>>> Hi Jan, >>>>>> >>>>>>> I don't know why we don't have the spidermonkey shell in a package. >>>>>>> I see no reason why not. If I have the time tomorrow I will try to >>>>>>> include it. (It seems to build fine) >>>>>>> Maybe someone else will pick it up earlier. >>>>>> >>>>>> It looks like the CSWspidermonkey package was simply never >>>>>> released...? If I get a chance tonight I'll crank them out to save >>>>>> you the cycles tomorrow. >>>>> >>>>> It's my fault, I wrote the build. I was only interested in the library >>>>> and didn't pay attention to other files. One problem is that the >>>>> spidermonkey build does not have the install target, so I had to write >>>>> my own. See "install-custom" in this file: >>>>> >>>>> https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/spidermonkey/branches/js-1.7/Makefile >>>>> >>>>> >>>>> >>>>> So it's simply an omission, and if the file is there, it simple to add >>>>> a ginstall invocation and put the file into a package. I'll let Jan do >>>>> it. >>>>> >>>>> Maciej >>>>> _______________________________________________ >>>>> users mailing list >>>>> users at lists.opencsw.org >>>>> https://lists.opencsw.org/mailman/listinfo/users >>>>> >>>> >>> >>> _______________________________________________ >>> users mailing list >>> users at lists.opencsw.org >>> https://lists.opencsw.org/mailman/listinfo/users >>> >> _______________________________________________ >> users mailing list >> users at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/users > _______________________________________________ > users mailing list > users at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/users From bwalton at opencsw.org Wed Oct 31 18:31:29 2012 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 31 Oct 2012 17:31:29 +0000 Subject: [csw-maintainers] spam spam spam In-Reply-To: <38a36adbab16e39e8c09faaaca7d4531.squirrel@mail.opencsw.org> References: <38a36adbab16e39e8c09faaaca7d4531.squirrel@mail.opencsw.org> Message-ID: Hi Peter, On Wed, Oct 31, 2012 at 10:09 AM, wrote: > Lately we have a lot of spam on the buildfarm mailing list; the board's > one is also full of it. Can we do something about? How can I help ? > I don't see this spam but my mail goes to gmail so I get those filters working for me. Even when it was going to a non-gmail final destination though, I saw very little spam on those lists with my trained spamassassin filter. What filters are you using? Ihsan: Could we hook spamassassin into the mail flow on mail.opencsw.org if it's not there already? I could supply a fairly well trained bayes db if so...Even with this in the pipeline though, I still prefer tagged delivery to discarding. Thanks -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: