From dam at opencsw.org Mon Dec 2 08:41:52 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 2 Dec 2013 08:41:52 +0100 Subject: Cleanup of experimental, long: please read anyway! In-Reply-To: References: <201311230310.rAN3A5xZ028433@web.bo.opencsw.org> Message-ID: <7DB81793-D682-4280-9E44-7127B6B6BD6D@opencsw.org> Hi folks, Am 23.11.2013 um 16:28 schrieb Maciej (Matchek) Blizi?ski : > 2013/11/23 Dagobert Michelsen > > If we have consensus > > I can add the removal instead of the note any time. Just delete older packages or also > > identical name but other checksum? > > Yes. We also need to set maintainers' expectations right: experimental is a volatile place. Done. Now file from experimental are removed under three conditions: 1. The identical package has been released and reached the catalog 2. A package with the same rev but different content has been released 3. A package with a newer rev has been released Empty directories are not removed, files not being a package are also kept. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From pfelecan at opencsw.org Wed Dec 11 20:14:19 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 11 Dec 2013 20:14:19 +0100 Subject: issue when committing to sourceforge Message-ID: I'm having issues committing to SourceForge: Authentication realm: SourceForge Subversion area svn: E170001: Commit failed (details follow): svn: E170001: MKACTIVITY of '/svnroot/gar/!svn/act/ede9338f-9d0e-e71b-83fc-b722b37016c2': authorization failed: Could not authenticate to server: rejected Basic challenge (https://gar.svn.sourceforge.net) Nothing changed since the last successful commit. I'm the only one to have this kind of behavior? -- Peter From dam at opencsw.org Thu Dec 12 12:35:14 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 12 Dec 2013 12:35:14 +0100 Subject: issue when committing to sourceforge In-Reply-To: References: Message-ID: <9DF4772A-E56B-426B-9DE4-314649CF7F59@opencsw.org> Hi Peter, Am 11.12.2013 um 20:14 schrieb Peter FELECAN: > I'm having issues committing to SourceForge: > > Authentication realm: SourceForge Subversion area > svn: E170001: Commit failed (details follow): > svn: E170001: MKACTIVITY of '/svnroot/gar/!svn/act/ede9338f-9d0e-e71b-83fc-b722b37016c2': authorization failed: Could not authenticate to server: rejected Basic challenge (https://gar.svn.sourceforge.net) > > Nothing changed since the last successful commit. I'm the only one to > have this kind of behavior? Doesn't work for me either any more :-( I opened a service request at sourceforge: https://sourceforge.net/p/forge/site-support/6235/ Best regards -- Dago From dam at opencsw.org Thu Dec 12 16:30:59 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 12 Dec 2013 16:30:59 +0100 Subject: issue when committing to sourceforge In-Reply-To: <9DF4772A-E56B-426B-9DE4-314649CF7F59@opencsw.org> References: <9DF4772A-E56B-426B-9DE4-314649CF7F59@opencsw.org> Message-ID: Hi, Am 12.12.2013 um 12:35 schrieb Dagobert Michelsen: > Am 11.12.2013 um 20:14 schrieb Peter FELECAN: >> I'm having issues committing to SourceForge: >> >> Authentication realm: SourceForge Subversion area >> svn: E170001: Commit failed (details follow): >> svn: E170001: MKACTIVITY of '/svnroot/gar/!svn/act/ede9338f-9d0e-e71b-83fc-b722b37016c2': authorization failed: Could not authenticate to server: rejected Basic challenge (https://gar.svn.sourceforge.net) >> >> Nothing changed since the last successful commit. I'm the only one to >> have this kind of behavior? > > Doesn't work for me either any more :-( I opened a service request at sourceforge: > https://sourceforge.net/p/forge/site-support/6235/ I just got an email from the Sourceforge support team that we need to migrate our GAR Trac to Allura ASAP. Maybe the subversion migration to Allura is tied to that. I'll keep you posted. Best regards -- Dago From grzemba at contac-dt.de Thu Dec 12 17:20:44 2013 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Thu, 12 Dec 2013 17:20:44 +0100 Subject: libgobject In-Reply-To: References: <20130910053613.GG27086@bender.opencsw.org> Message-ID: Hi, I have tried to build evince 2.32.0 but it stops and cores: grzemba at testcsw:~$ evince failed to find gam_server Failed to connect to socket /tmp/fam-grzemba/fam- (evince:3971): GLib-GIO-WARNING **: FAMOpen failed, FAMErrno=3 failed to find gam_server Failed to connect to socket /tmp/fam-grzemba/fam- (evince:3971): GLib-GIO-WARNING **: FAMOpen failed, FAMErrno=3 (evince:3971): GLib-GIO-ERROR **: Settings schema 'org.gnome.Evince.Default' is not installed Trace/Breakpoint Trap (core dumped) grzemba at testcsw:~$ ls Do you have an idea? > ::stack libc.so.1`_lwp_kill+8(5, 732f0, 1e9648, 1e9684, 1ed200, 1eddb8) libglib-2.0.so.0.3600.3`g_logv+0x210(fe597608, 4, 0, 6, 4, 2) libglib-2.0.so.0.3600.3`g_log+0x20(fe597608, 4, fe5976f8, 1e8c98, 0, 0) libgio-2.0.so.0.3600.3`g_settings_set_property+0x1a4(1de340, 2, ffbff678, 1e5c58, 1de350, 1e8c98) libgobject-2.0.so.0.3600.3`g_object_constructor+0x170(1de340, 5, 1e9508, 1e9300 , ffbff678, 1e5c58) libgobject-2.0.so.0.3600.3`g_object_newv+0x254(1ed610, 1e5c90, 1e9530, 4, 1e9518, 5) libgobject-2.0.so.0.3600.3`g_object_new_valist+0x1e8(1ed610, 0, 0, 1e92f8, 1e9300, 10) libgobject-2.0.so.0.3600.3`g_object_new+0x78(1ed610, fe597b08, 59330, 0, 1d87ac , 6) 0x3cd14(ba1a0, af578, b9f58, ac848, 1d3820, ba258) libgobject-2.0.so.0.3600.3`g_type_create_instance+0x220(ba1a0, ff1f8f38, ff1f8f34, af708, adf68, ff1f8dcc) libgobject-2.0.so.0.3600.3`g_object_constructor+0x10(af708, 2, b64f0, 76578, 75f60, 76980) libgobject-2.0.so.0.3600.3`g_object_newv+0x254(af708, 81ec8, adf28, 1, adf10, 2 ) libgobject-2.0.so.0.3600.3`g_object_new_valist+0x1e8(af708, 0, 0, b9408, b9410, 10) libgobject-2.0.so.0.3600.3`g_object_new+0x78(af708, 59440, 0, 0, 73198, 73000) ev_window_new+0x18(c, 0, 4, 1, fea87f68, 0) ev_application_open_window+4(9c0a8, 8e0c8, 0, 0, 9a688, 73000) main+0x400(1, ffbffd3c, ffbffd44, 732f4, 0, 5bc00) _start+0x5c(0, 0, 0, 0, 0, 0) -------------- next part -------------- An HTML attachment was scrubbed... URL: From slowfranklin at opencsw.org Thu Dec 12 17:46:47 2013 From: slowfranklin at opencsw.org (slowfranklin) Date: Thu, 12 Dec 2013 17:46:47 +0100 Subject: libgobject In-Reply-To: References: <20130910053613.GG27086@bender.opencsw.org> Message-ID: <2C3ACF90-EDCD-4A0D-8D9D-18C99A806ADE@opencsw.org> Hi Carsten Am 12.12.2013 um 17:20 schrieb Carsten Grzemba : > I have tried to build evince 2.32.0 but it stops and cores: > > grzemba at testcsw:~$ evince > failed to find gam_server > Failed to connect to socket /tmp/fam-grzemba/fam- > > (evince:3971): GLib-GIO-WARNING **: FAMOpen failed, FAMErrno=3 > > failed to find gam_server > Failed to connect to socket /tmp/fam-grzemba/fam- > > (evince:3971): GLib-GIO-WARNING **: FAMOpen failed, FAMErrno=3 > > > (evince:3971): GLib-GIO-ERROR **: Settings schema 'org.gnome.Evince.Default' is not installed > > Trace/Breakpoint Trap (core dumped) > grzemba at testcsw:~$ ls > > Do you have an idea? Do you have the schema in /opt/csw/share/glib-2.0/schemas/ ? What says: $ gsettings list-schemas Have you run glib-compile-schemas? $ sudo glib-compile-schemas /opt/csw/share/glib-2.0/schemas/ -slow From dam at opencsw.org Thu Dec 12 18:09:02 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 12 Dec 2013 18:09:02 +0100 Subject: FIXED: issue when committing to sourceforge In-Reply-To: References: <9DF4772A-E56B-426B-9DE4-314649CF7F59@opencsw.org> Message-ID: <7775F385-D6C5-4BC0-9FA4-CECD80E613DD@opencsw.org> Hi, Am 12.12.2013 um 16:30 schrieb Dagobert Michelsen: > Am 12.12.2013 um 12:35 schrieb Dagobert Michelsen: >> Am 11.12.2013 um 20:14 schrieb Peter FELECAN: >>> I'm having issues committing to SourceForge: >>> >>> Authentication realm: SourceForge Subversion area >>> svn: E170001: Commit failed (details follow): >>> svn: E170001: MKACTIVITY of '/svnroot/gar/!svn/act/ede9338f-9d0e-e71b-83fc-b722b37016c2': authorization failed: Could not authenticate to server: rejected Basic challenge (https://gar.svn.sourceforge.net) >>> >>> Nothing changed since the last successful commit. I'm the only one to >>> have this kind of behavior? >> >> Doesn't work for me either any more :-( I opened a service request at sourceforge: >> https://sourceforge.net/p/forge/site-support/6235/ > > I just got an email from the Sourceforge support team that we need to migrate our GAR Trac to Allura ASAP. > Maybe the subversion migration to Allura is tied to that. I'll keep you posted. It was indeed related. To be able to commit again please do the following: cd svn info (See what URL is, e.g. URL: https://gar.svn.sf.net/svnroot/gar/csw/mgar) svn relocate https://svn.code.sf.net/p/gar/code/csw/mgar Make sure to have the same suffix (here csw/mgar) or the relocate won't work. You should be able to commit again with username and password. There is now also the possibility to commit via svn+ssh. Unfortunately there are some more changes: - The Trac tickets have been converted to Allura tickets https://sourceforge.net/p/gar/tickets/ - The Trac wiki has been converted to Allura wiki: https://sourceforge.net/p/gar/tracwiki/Home/ The existing Trac at http://gar.opencsw.org will continue some time, but not too long. Please don't write there any more as changes will be lost! Commits won't enter Trac any more too. Commits should be trackable with the feeds on the code page when the analyzing is finished: https://sourceforge.net/p/gar/code/ I made a backup of the Trac database and the Trac files just in case we want to setup our own Trac again. Generally I don't like the Allura wiki and tracker. Trac was more crisp and concise and had a nicer markup IMHO. I'll try to update the other links accordingly in the next few days. Please let me know if anything suspicious happens or you see outdated links or information. Best regards -- Dago From pfelecan at opencsw.org Thu Dec 12 18:30:15 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 12 Dec 2013 18:30:15 +0100 Subject: FIXED: issue when committing to sourceforge In-Reply-To: <7775F385-D6C5-4BC0-9FA4-CECD80E613DD@opencsw.org> (Dagobert Michelsen's message of "Thu, 12 Dec 2013 18:09:02 +0100") References: <9DF4772A-E56B-426B-9DE4-314649CF7F59@opencsw.org> <7775F385-D6C5-4BC0-9FA4-CECD80E613DD@opencsw.org> Message-ID: Dagobert Michelsen writes: > Am 12.12.2013 um 16:30 schrieb Dagobert Michelsen: >> Am 12.12.2013 um 12:35 schrieb Dagobert Michelsen: >>> Am 11.12.2013 um 20:14 schrieb Peter FELECAN: >>>> I'm having issues committing to SourceForge: >>>> >>>> Authentication realm: SourceForge Subversion area >>>> svn: E170001: Commit failed (details follow): >>>> svn: E170001: MKACTIVITY of >>>> /svnroot/gar/!svn/act/ede9338f-9d0e-e71b-83fc-b722b37016c2': >>>> authorization failed: Could not authenticate to server: rejected >>>> Basic challenge (https://gar.svn.sourceforge.net) >>>> >>>> Nothing changed since the last successful commit. I'm the only one to >>>> have this kind of behavior? >>> >>> Doesn't work for me either any more :-( I opened a service request at sourceforge: >>> https://sourceforge.net/p/forge/site-support/6235/ >> >> I just got an email from the Sourceforge support team that we need to migrate our GAR Trac to Allura ASAP. >> Maybe the subversion migration to Allura is tied to that. I'll keep you posted. > > It was indeed related. To be able to commit again please do the following: > cd > svn info > (See what URL is, e.g. URL: https://gar.svn.sf.net/svnroot/gar/csw/mgar) > svn relocate https://svn.code.sf.net/p/gar/code/csw/mgar It works. The only caveat is that you need to re-enter your user name and password for the first time and after that everything works as before. Thank you for you intervention: quick and efficient. -- Peter From dam at opencsw.org Thu Dec 12 20:00:42 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 12 Dec 2013 20:00:42 +0100 Subject: ld has been inconsistently upgraded on the buildfarm In-Reply-To: <52AA062B.2050901@opencsw.org> References: <52834049.5080104@opencsw.org> <52AA062B.2050901@opencsw.org> Message-ID: Hi Jake, Am 12.12.2013 um 19:53 schrieb Jake Goerzen via buildfarm: > On 11/13/13 06:16, Dagobert Michelsen via buildfarm wrote: >> Am 13.11.2013 um 10:03 schrieb Laurent Blume via buildfarm : >>> Regularly, I'm having silly issues with linking on the buildfarm with different behaviour on x86 and sparc. >>> This time, in krb5-lib: with the same recipe, some binaries get linked to libintl.so on unstable10s, and they don't on unstable10x. >>> On my home system, x86, they do get linked. >>> >>> I'm noticing that ld on the buildfarm is not at all consistent: >>> >>> At home: >>> -rwxr-xr-x 1 root bin 10300 janv 14 2013 /usr/ccs/bin/ld >>> >>> unstable10s: >>> $ ls -l /usr/ccs/bin/ld >>> -rwxr-xr-x 1 root bin 10788 Jan 16 2013 /usr/ccs/bin/ld >>> >>> unstable10x: >>> $ ls -l /usr/ccs/bin/ld >>> -rwxr-xr-x 1 root bin 10172 Jul 4 2011 /usr/ccs/bin/ld >>> >>> >>> Since it's part of the kernel patch, I gather that unstable10x was kept back for some reason, as its kernel is older. >>> >>> Can unstable10x be upgraded? I am reasonably sure it would fix some of the linking issues I'm hitting right now. >> >> I would prefer not to unless we fully understand the issue as discussed on irc. > > Hi Dago, > > Has there been any update on the issue of ld being inconsistent on the buildfarm yet? I have been putting off working on some things until a resolution has been found. Yann has a case open at Oracle, but I doubt we get anything useful out of it. For now I recommend just adding the extra deps and unconditionally overriding them for i386. For mid-term William told me he will get some T5220 and he would be willing to give one to the project. This would allow me another build-only machine which is not going to be updated. Then we could also really stick to u8 (or u5?) for all packaging zones. But don't expect this before q2 2014. Sorry for the inconvenience -- Dago From yann at pleiades.fr.eu.org Thu Dec 12 21:00:49 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Thu, 12 Dec 2013 21:00:49 +0100 Subject: ld has been inconsistently upgraded on the buildfarm In-Reply-To: References: <52834049.5080104@opencsw.org> <52AA062B.2050901@opencsw.org> Message-ID: No significant answer from Oracle for 3 weeks now. I am asking for update on a weekly basis but I don't have matter to increase the priority of this issue as there is not production impact and an easy workaround. I do think we will eventually get an answer. Yann 2013/12/12 Dagobert Michelsen via buildfarm > Hi Jake, > > Am 12.12.2013 um 19:53 schrieb Jake Goerzen via buildfarm: > > On 11/13/13 06:16, Dagobert Michelsen via buildfarm wrote: > >> Am 13.11.2013 um 10:03 schrieb Laurent Blume via buildfarm < > buildfarm at lists.opencsw.org>: > >>> Regularly, I'm having silly issues with linking on the buildfarm with > different behaviour on x86 and sparc. > >>> This time, in krb5-lib: with the same recipe, some binaries get linked > to libintl.so on unstable10s, and they don't on unstable10x. > >>> On my home system, x86, they do get linked. > >>> > >>> I'm noticing that ld on the buildfarm is not at all consistent: > >>> > >>> At home: > >>> -rwxr-xr-x 1 root bin 10300 janv 14 2013 /usr/ccs/bin/ld > >>> > >>> unstable10s: > >>> $ ls -l /usr/ccs/bin/ld > >>> -rwxr-xr-x 1 root bin 10788 Jan 16 2013 /usr/ccs/bin/ld > >>> > >>> unstable10x: > >>> $ ls -l /usr/ccs/bin/ld > >>> -rwxr-xr-x 1 root bin 10172 Jul 4 2011 /usr/ccs/bin/ld > >>> > >>> > >>> Since it's part of the kernel patch, I gather that unstable10x was > kept back for some reason, as its kernel is older. > >>> > >>> Can unstable10x be upgraded? I am reasonably sure it would fix some of > the linking issues I'm hitting right now. > >> > >> I would prefer not to unless we fully understand the issue as discussed > on irc. > > > > Hi Dago, > > > > Has there been any update on the issue of ld being inconsistent on the > buildfarm yet? I have been putting off working on some things until a > resolution has been found. > > Yann has a case open at Oracle, but I doubt we get anything useful out of > it. > For now I recommend just adding the extra deps and unconditionally > overriding > them for i386. For mid-term William told me he will get some T5220 and he > would > be willing to give one to the project. This would allow me another > build-only > machine which is not going to be updated. Then we could also really stick > to > u8 (or u5?) for all packaging zones. But don't expect this before q2 2014. > > Sorry for the inconvenience > > -- Dago -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgoerzen at opencsw.org Fri Dec 13 01:16:48 2013 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Thu, 12 Dec 2013 16:16:48 -0800 Subject: ld has been inconsistently upgraded on the buildfarm In-Reply-To: References: <52834049.5080104@opencsw.org> <52AA062B.2050901@opencsw.org> Message-ID: <52AA51F0.70500@opencsw.org> On 12/12/13 12:00, Yann Rouillard wrote: > No significant answer from Oracle for 3 weeks now. > I am asking for update on a weekly basis but I don't have matter to > increase the priority of this issue as there is not production impact > and an easy workaround. > > I do think we will eventually get an answer. > > Yann > > > > 2013/12/12 Dagobert Michelsen via buildfarm > > > > Hi Jake, > > Am 12.12.2013 um 19:53 schrieb Jake Goerzen via buildfarm: > > On 11/13/13 06:16, Dagobert Michelsen via buildfarm wrote: > >> Am 13.11.2013 um 10:03 schrieb Laurent Blume via buildfarm > >: > >>> Regularly, I'm having silly issues with linking on the > buildfarm with different behaviour on x86 and sparc. > >>> This time, in krb5-lib: with the same recipe, some binaries > get linked to libintl.so on unstable10s, and they don't on > unstable10x. > >>> On my home system, x86, they do get linked. > >>> > >>> I'm noticing that ld on the buildfarm is not at all consistent: > >>> > >>> At home: > >>> -rwxr-xr-x 1 root bin 10300 janv 14 2013 > /usr/ccs/bin/ld > >>> > >>> unstable10s: > >>> $ ls -l /usr/ccs/bin/ld > >>> -rwxr-xr-x 1 root bin 10788 Jan 16 2013 > /usr/ccs/bin/ld > >>> > >>> unstable10x: > >>> $ ls -l /usr/ccs/bin/ld > >>> -rwxr-xr-x 1 root bin 10172 Jul 4 2011 > /usr/ccs/bin/ld > >>> > >>> > >>> Since it's part of the kernel patch, I gather that unstable10x > was kept back for some reason, as its kernel is older. > >>> > >>> Can unstable10x be upgraded? I am reasonably sure it would fix > some of the linking issues I'm hitting right now. > >> > >> I would prefer not to unless we fully understand the issue as > discussed on irc. > > > > Hi Dago, > > > > Has there been any update on the issue of ld being inconsistent > on the buildfarm yet? I have been putting off working on some > things until a resolution has been found. > > Yann has a case open at Oracle, but I doubt we get anything useful > out of it. > For now I recommend just adding the extra deps and unconditionally > overriding > them for i386. For mid-term William told me he will get some T5220 > and he would > be willing to give one to the project. This would allow me another > build-only > machine which is not going to be updated. Then we could also > really stick to > u8 (or u5?) for all packaging zones. But don't expect this before > q2 2014. > > Sorry for the inconvenience > > -- Dago > > Thank you all for your efforts and contributions! I will use the work around as suggested. Great idea about setting up the T5220 build-only host! Best Regards, /Jake -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfelecan at opencsw.org Fri Dec 13 09:42:22 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 13 Dec 2013 09:42:22 +0100 Subject: ld has been inconsistently upgraded on the buildfarm In-Reply-To: (Dagobert Michelsen's message of "Thu, 12 Dec 2013 20:00:42 +0100") References: <52834049.5080104@opencsw.org> <52AA062B.2050901@opencsw.org> Message-ID: Dagobert Michelsen writes: > This would allow me another build-only machine which is not going to > be updated. Then we could also really stick to u8 (or u5?) for all > packaging zones. What's a "build only" host? -- Peter From dam at opencsw.org Fri Dec 13 09:52:32 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 13 Dec 2013 09:52:32 +0100 Subject: ld has been inconsistently upgraded on the buildfarm In-Reply-To: References: <52834049.5080104@opencsw.org> <52AA062B.2050901@opencsw.org> Message-ID: Hi, Am 13.12.2013 um 09:42 schrieb Peter FELECAN : > Dagobert Michelsen writes: >> This would allow me another build-only machine which is not going to >> be updated. Then we could also really stick to u8 (or u5?) for all >> packaging zones. > > What's a "build only" host? At the moment the farm consists of two servers: A T5229 which has three ldoms, one control domain, one Solaris 11 and one Solaris 10. The Solaris 10 ldom has the zpools for everything on the farm either via lofs or nfs and also the build zones unstable* either 8/9 branded or native. We had to upgrade Solaris or we could no longer make zfs backups, this large kernel patch also updated the linker. A second T5220 could be used for the building zones whereas the existing machine could carry zpools and solaris 11. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From dam at opencsw.org Fri Dec 13 10:12:57 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 13 Dec 2013 10:12:57 +0100 Subject: New tools: buildbot and OpenGrok Message-ID: <8310123D-9A06-448D-BBC0-7FAD857BC0C6@opencsw.org> Hi, as the compatibility with Solaris is getting harder these days I finally set up buildbot to give upstream a chance to detect problems long before release. If you have contact with upstream and know that they would benefit from this just let me know: http://buildfarm.opencsw.org/buildbot/waterfall Additionally, if anyone has cycles to bring socat to 100% testsuite that would be really cool. Second, to aid code awareness I added OpenGrok on the buildfarm for the buildbot projects and also our GAR tree: http://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/ The browsing is really fast, much faster then Trac at SourceForge was. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From markp at opencsw.org Tue Dec 17 11:43:34 2013 From: markp at opencsw.org (Mark Phillips) Date: Tue, 17 Dec 2013 10:43:34 +0000 Subject: Removal Message-ID: <5A97CCCA-B3CA-4B80-B534-C17D7109520C@opencsw.org> Folks, I'm no longer able to keep up maintaining Puppet & Puppet3, so I'm looking for a new owner. If nobody comes forward straight away then I'll continue to roll them as I find time. Basically, I won't be as reactive as I have been in the past. I'd like to be removed from the maintainers list too please. Thanks, --Mark [freenode: phips] From opk at opencsw.org Thu Dec 19 16:07:04 2013 From: opk at opencsw.org (Oliver Kiddle) Date: Thu, 19 Dec 2013 16:07:04 +0100 Subject: help with octave (libsunperf) Message-ID: <52B30B98.2060006@opencsw.org> I've been trying to get octave to build and have been fairly successful by using libsunperf to get blas/lapack and using the Solaris Studio Fortran compiler but g++ for the C++. The problem is that the end result won't work without setting LD_LIBRARY_PATH. I think it has something todo with the locations of our copies of things like libsunperf under /opt/csw. Note the following: ldd /opt/csw/lib/sparcv8/libsunperf.so.7 libfsu.so.1 => (file not found) etc... You can get a clearer picture of what is going on by setting LD_DEBUG=libs for this. I don't really understand what is going on: why doesn't $ORIGIN/.. work for finding libfsu.so.1? Do we perhaps need to closer mirror the directory structure from below /opt/SUNWspro for these libraries? Thanks Oliver From opk at opencsw.org Thu Dec 19 16:09:54 2013 From: opk at opencsw.org (Oliver Kiddle) Date: Thu, 19 Dec 2013 16:09:54 +0100 Subject: isaexec and Tcl/Tk Message-ID: <52B30C42.3020702@opencsw.org> An upgrade to opencsw has broken our various Tcl/Tk applications. This appears to be a consequence of tclsh now being a link to isaexec. Running tclsh gets us the 64-bit version and then we can't load 32-bit libraries. Building our software 64-bit is not an option. Is there a way such as via an environment variable to tell isaexec to prefer a 32-bit binary? Or is there some other solution like perhaps using the alternatives mechanism to point tclsh8.5 at sparcv8plus/tclsh8.5 instead of at isaexec? I know that as a last resort, we can change the #! line of our scripts but there's a lot. The feature of running 64-bit in preference seems somewhat ill-advised on sparc systems in general. Unlike for x86, it doesn't result in improved performance. Oliver From dam at opencsw.org Thu Dec 19 16:26:40 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 19 Dec 2013 16:26:40 +0100 Subject: isaexec and Tcl/Tk In-Reply-To: <52B30C42.3020702@opencsw.org> References: <52B30C42.3020702@opencsw.org> Message-ID: <79B2C570-50AB-4FA0-A27E-4BDA74BBDB8C@opencsw.org> Hi Oliver, Am 19.12.2013 um 16:09 schrieb Oliver Kiddle : > An upgrade to opencsw has broken our various Tcl/Tk applications. > > This appears to be a consequence of tclsh now being a link to isaexec. > Running tclsh gets us the 64-bit version and then we can't load 32-bit > libraries. Building our software 64-bit is not an option. > > Is there a way such as via an environment variable to tell isaexec to > prefer a 32-bit binary? Or is there some other solution like perhaps using > the alternatives mechanism to point tclsh8.5 at sparcv8plus/tclsh8.5 > instead of at isaexec? I know that as a last resort, we can change the > #! line of our scripts but there's a lot. Or alternatively I could just exclude tclsh from isaexec and require explicit calling. You can do this also right now by explicitly calling /opt/csw/bin/sparcv8plus/tclsh Thoughts? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From dam at opencsw.org Thu Dec 19 16:28:09 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 19 Dec 2013 16:28:09 +0100 Subject: help with octave (libsunperf) In-Reply-To: <52B30B98.2060006@opencsw.org> References: <52B30B98.2060006@opencsw.org> Message-ID: <77B50869-BD5E-41DE-B202-3BD88CE802A3@opencsw.org> Hi Oliver, Am 19.12.2013 um 16:07 schrieb Oliver Kiddle : > I've been trying to get octave to build and have been fairly successful > by using libsunperf to get blas/lapack and using the Solaris Studio > Fortran compiler but g++ for the C++. > > The problem is that the end result won't work without setting > LD_LIBRARY_PATH. I think it has something todo with the locations of our > copies of things like libsunperf under /opt/csw. Note the following: > > ldd /opt/csw/lib/sparcv8/libsunperf.so.7 > libfsu.so.1 => (file not found) > etc... > > You can get a clearer picture of what is going on by setting > LD_DEBUG=libs for this. I don't really understand what is going on: why > doesn't $ORIGIN/.. work for finding libfsu.so.1? Do we perhaps need to > closer mirror the directory structure from below /opt/SUNWspro for these > libraries? Please check the linker RPATH with "dump -Lv ", the library placement should be good as it is. If the issue persists please commit what you have and post where in the tree it is so I can reproduce it. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From pfelecan at opencsw.org Thu Dec 19 16:55:44 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 19 Dec 2013 16:55:44 +0100 Subject: isaexec and Tcl/Tk In-Reply-To: <79B2C570-50AB-4FA0-A27E-4BDA74BBDB8C@opencsw.org> (Dagobert Michelsen's message of "Thu, 19 Dec 2013 16:26:40 +0100") References: <52B30C42.3020702@opencsw.org> <79B2C570-50AB-4FA0-A27E-4BDA74BBDB8C@opencsw.org> Message-ID: Dagobert Michelsen writes: > Hi Oliver, > > Am 19.12.2013 um 16:09 schrieb Oliver Kiddle : >> An upgrade to opencsw has broken our various Tcl/Tk applications. >> >> This appears to be a consequence of tclsh now being a link to isaexec. >> Running tclsh gets us the 64-bit version and then we can't load 32-bit >> libraries. Building our software 64-bit is not an option. >> >> Is there a way such as via an environment variable to tell isaexec to >> prefer a 32-bit binary? Or is there some other solution like perhaps using >> the alternatives mechanism to point tclsh8.5 at sparcv8plus/tclsh8.5 >> instead of at isaexec? I know that as a last resort, we can change the >> #! line of our scripts but there's a lot. > > Or alternatively I could just exclude tclsh from isaexec and require > explicit calling. You can do this also right now by explicitly calling > /opt/csw/bin/sparcv8plus/tclsh > > Thoughts? IMHO, excluding tclsh form isaexec is not a great idea as it break orthogonality. If Oliver cannot find a solution I'll opt in favor of alternatives but this brings other issues, at least for me, as how to declare internal, viz same package, alternatives. -- Peter From dam at opencsw.org Fri Dec 20 15:07:35 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Dec 2013 15:07:35 +0100 Subject: Unstable network connection Message-ID: Hi, we are experiencing some problems with our network connection where also the farm is connected. Sorry for the inconvenience. -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From yann at pleiades.fr.eu.org Fri Dec 20 15:39:26 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Fri, 20 Dec 2013 15:39:26 +0100 Subject: chkpkg and soname-unused In-Reply-To: <2A496DBE-9B7B-4A12-A32D-9ADD498C2727@opencsw.org> References: <20131104155028.GX4199@bender.opencsw.org> <20131104164121.GY4199@bender.opencsw.org> <8E58FBDD-53AD-4BDF-8300-07B8DCDBF330@opencsw.org> <20131104170301.GZ4199@bender.opencsw.org> <20131104171710.GB4199@bender.opencsw.org> <2A496DBE-9B7B-4A12-A32D-9ADD498C2727@opencsw.org> Message-ID: Hi everyone, I had some news about Oracle support for this problem (libraries dependencies incorrectly kept in binaries in spite of the "-z ignore" flags) that leads to soname-unused errors. More details soon but to do some fact checking I would like need to see if it is really the same bug that explains the different cases we have. Could you tell me a list of packages for which you had to override the soname-unused to override this bug ? Yann 2013/11/5 slowfranklin > > Am 04.11.2013 um 22:45 schrieb Yann Rouillard : > > > Ok, it seems that this is caused by a recent patch, 147147-26, which > changed the behaviour of the "-z ignore" option. > > Indeed the changelog contains the following line: > > 7051963 ld's -z ignore processing is too simplistic > > > > I opened a bug on Oracle support to have more information, meanwhile I > will disable the check so everybody doesn't have to add overrides for this > problem. The messages about soname-unused will still be printed for > information but they will not cause an error in the packaging process. > > > > So you can "mgar update" and remove the overrides on tracker and gamin. > > Thanks Yann! I?ll be curious to know what 7051963 is about too. > > -slow -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Fri Dec 20 19:00:23 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 20 Dec 2013 18:00:23 +0000 Subject: chkpkg and soname-unused In-Reply-To: References: <20131104155028.GX4199@bender.opencsw.org> <20131104164121.GY4199@bender.opencsw.org> <8E58FBDD-53AD-4BDF-8300-07B8DCDBF330@opencsw.org> <20131104170301.GZ4199@bender.opencsw.org> <20131104171710.GB4199@bender.opencsw.org> <2A496DBE-9B7B-4A12-A32D-9ADD498C2727@opencsw.org> Message-ID: 2013/12/20 Yann Rouillard > Could you tell me a list of packages for which you had to override the soname-unused to override this bug ? We have this: http://buildfarm.opencsw.org/pkgdb/error-tags/soname-unused/ Caution, it's an enormous page which takes ages to load. It does work, it's just super slow. Maybe it's best to pull it down with curl instead of opening in a browser. The information there is not exactly what you need, but with a little bit of text processing you can probably get there. Maciej From rupert at opencsw.org Sat Dec 28 07:36:21 2013 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 28 Dec 2013 07:36:21 +0100 Subject: genshi, subvertpy not in catalog? Message-ID: hi, i tried to make new versions of genshi, and subvertpy, but they do not show up in the catalog? rupert. From maciej at opencsw.org Sat Dec 28 10:11:20 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 28 Dec 2013 10:11:20 +0100 Subject: genshi, subvertpy not in catalog? In-Reply-To: References: Message-ID: Not sure what you're asking - did you attempt to build and upload these packages and you didn't get a confirmation email? What exactly didn't work as expected? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert at opencsw.org Sat Dec 28 15:16:47 2013 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 28 Dec 2013 15:16:47 +0100 Subject: genshi, subvertpy not in catalog? In-Reply-To: References: Message-ID: i did not get a confirmation mail, and the newest verisons do not show up, yes. On Sat, Dec 28, 2013 at 10:11 AM, Maciej (Matchek) Blizi?ski wrote: > Not sure what you're asking - did you attempt to build and upload these > packages and you didn't get a confirmation email? What exactly didn't work > as expected? From dam at opencsw.org Sat Dec 28 16:06:27 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 28 Dec 2013 16:06:27 +0100 Subject: genshi, subvertpy not in catalog? In-Reply-To: References: Message-ID: <2702ADC5-6C42-4A3C-9872-2116BB7D92D8@opencsw.org> Hi Rupert, > Am 28.12.2013 um 15:16 schrieb rupert THURNER : > > i did not get a confirmation mail, and the newest verisons do not show up, yes. Looks like a network problem, I'll have a look. Best regards -- Dago > > On Sat, Dec 28, 2013 at 10:11 AM, Maciej (Matchek) Blizi?ski > wrote: >> Not sure what you're asking - did you attempt to build and upload these >> packages and you didn't get a confirmation email? What exactly didn't work >> as expected? From dam at opencsw.org Sat Dec 28 16:42:22 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 28 Dec 2013 16:42:22 +0100 Subject: genshi, subvertpy not in catalog? In-Reply-To: <2702ADC5-6C42-4A3C-9872-2116BB7D92D8@opencsw.org> References: <2702ADC5-6C42-4A3C-9872-2116BB7D92D8@opencsw.org> Message-ID: <6372F069-005F-4A0D-A856-4BA86CA1F11B@opencsw.org> Hi, Am 28.12.2013 um 16:06 schrieb Dagobert Michelsen : >> Am 28.12.2013 um 15:16 schrieb rupert THURNER : >> >> i did not get a confirmation mail, and the newest verisons do not show up, yes. > > Looks like a network problem, I'll have a look. Nope, some else to blame ;-) ERROR! Cyclic dependency detected in package CSWlibkrb5-3 because of CSWlibkrb5-3 -> CSWlibkrb5-priv -> CSWlibgssapi-krb5-2 -> CSWlibkrb5-3. ERROR! Cyclic dependency detected in package CSWlibkrb5-priv because of CSWlibkrb5-priv -> CSWlibgssapi-krb5-2 -> CSWlibkrb5-3 -> CSWlibkrb5-priv. Laurent, just by a strange coincidence do you happen to know someone who would have both the capability and kindness of crafting another set of kerberos packages? ;-) Best regards -- Dago PS: How about a new rule? Whoever breaks the catalog is up for a round of beer at the next camp! PPS: I'll throw the first one for the monitoring email not reaching me before someone notices... -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From laurent at opencsw.org Sun Dec 29 00:58:07 2013 From: laurent at opencsw.org (Laurent Blume) Date: Sun, 29 Dec 2013 00:58:07 +0100 Subject: genshi, subvertpy not in catalog? In-Reply-To: <6372F069-005F-4A0D-A856-4BA86CA1F11B@opencsw.org> References: <2702ADC5-6C42-4A3C-9872-2116BB7D92D8@opencsw.org> <6372F069-005F-4A0D-A856-4BA86CA1F11B@opencsw.org> Message-ID: <52BF658F.1040200@opencsw.org> On 12/28/2013 04:42 PM, Dagobert Michelsen wrote: > Nope, some else to blame ;-) > > ERROR! Cyclic dependency detected in package CSWlibkrb5-3 because of CSWlibkrb5-3 -> CSWlibkrb5-priv -> CSWlibgssapi-krb5-2 -> CSWlibkrb5-3. > ERROR! Cyclic dependency detected in package CSWlibkrb5-priv because of CSWlibkrb5-priv -> CSWlibgssapi-krb5-2 -> CSWlibkrb5-3 -> CSWlibkrb5-priv. > > Laurent, just by a strange coincidence do you happen to know someone who > would have both the capability and kindness of crafting another set of > kerberos packages? ;-) Bit messy, I'm not even sure how it got in partially. I've pushed a new version that upgraded fine from experimental. Basically I merged packages that depend one on the other so they won't create circular deps anymore. Some day, I'll remake the whole recipe to look just like . > PS: How about a new rule? Whoever breaks the catalog is up for a round of beer at the next camp! > PPS: I'll throw the first one for the monitoring email not reaching me before someone notices... Heh, when is it going to be? My trip schedule for next year is filling up already :-) Joyeuses f?tes! Laurent