From dam at opencsw.org Thu Mar 1 11:04:10 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 1 Mar 2012 11:04:10 +0100 Subject: [csw-maintainers] Updating photos for the camps Message-ID: Hi folks, I would like to ask everyone to provide missing photos for the camps: http://www.flickr.com/photos/opencsw/sets/ Especially there have been no pictures for the following camps: ? Summercamp 2010: 14.-15. August 2010 in Paris ? Wintercamp 2010: 18.-20. January 2011 in Dublin ? Summercamp 2011: 24.-25. September 2011 in Kiel I have some pictures from Kiel, but probably not all. This page says that only William has access to Flickr, is this still true? I would suggest to have some kind of escrow to the board just in case. http://wiki.opencsw.org/3rd-party-services Also I would like to ask to insert the pictures from Othmar to Flickr because there is a direct integration to wikidot. Othmar: Would that be ok for you? I feel like adding some pictures to the camp wiki pages is a nice thing for new maintainers to get a feeling what is going on. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From bwalton at opencsw.org Fri Mar 2 02:01:07 2012 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 01 Mar 2012 20:01:07 -0500 Subject: [csw-maintainers] Updating photos for the camps In-Reply-To: References: Message-ID: <1330650030-sup-3374@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Thu Mar 01 05:04:10 -0500 2012: > ? Wintercamp 2010: 18.-20. January 2011 in Dublin I'll happily upload my shots from Dublin (or pass them to someone else to post). > This page says that only William has access to Flickr, is this still true? > I would suggest to have some kind of escrow to the board just in case. > http://wiki.opencsw.org/3rd-party-services I think so, but I'm not sure. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Fri Mar 2 10:15:50 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 2 Mar 2012 09:15:50 +0000 Subject: [csw-maintainers] [csw-devel] [PATCH 1/4] Test for O_DIRECTORY In-Reply-To: <4f4e3b42.W+3ZA3bVj8qPyOYv%Joerg.Schilling@fokus.fraunhofer.de> References: <1330508909-16469-1-git-send-email-maciej@opencsw.org> <1330508909-16469-2-git-send-email-maciej@opencsw.org> <4f4e3b42.W+3ZA3bVj8qPyOYv%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: Hello maintainers, Here's a porting topic. It started with me working on a VLC build. O_DIRECTORY is not available on Solaris 10 and my patch to set it to 0 has been rejected. I'm looking for a better solution. More below. 2012/2/29 Joerg Schilling : > Maciej Blizinski wrote: > >> O_DIRECTORY is not declared on Solaris 10. Test for it and only use it when >> available. >> --- >> ?configure.ac ? ? ? ? ?| ? ?1 + >> ?modules/misc/gnutls.c | ? ?6 +++++- >> ?2 files changed, 6 insertions(+), 1 deletions(-) >> >> diff --git a/configure.ac b/configure.ac >> index efb2e99..6ce41f5 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -492,6 +492,7 @@ dnl Check for usual libc functions >> ?AC_CHECK_DECLS([nanosleep],,,[#include ]) >> ?AC_CHECK_FUNCS([daemon fcntl fstatvfs fork getenv getpwuid_r if_nameindex if_nametoindex isatty lstat memalign mmap openat pread posix_fadvise posix_madvise setlocale stricmp strnicmp strptime uselocale]) >> ?AC_REPLACE_FUNCS([atof atoll dirfd fdopendir flockfile fsync getdelim getpid gmtime_r inet_pton lldiv localtime_r nrand48 poll rewind setenv strcasecmp strcasestr strdup strlcpy strncasecmp strndup strnlen strsep strtof strtok_r strtoll swab tdestroy strverscmp]) >> +AC_CHECK_DECLS([O_DIRECTORY]) >> ?AC_CHECK_FUNCS(fdatasync,, >> ? ?[AC_DEFINE(fdatasync, fsync, [Alias fdatasync() to fsync() if missing.]) >> ?]) > > Why? General incompetence on my part. I'm still looking for a solution. > POSIX grants this to be a #define, so you may safely use: > > #ifdef ?O_DIRECTORY My patch to set O_DIRECTORY to 0 was rejected: http://mailman.videolan.org/pipermail/vlc-devel/2012-March/086989.html What else can we do? We can't check first and open second, because that would introduce a race condition. Can we open first, and then test the file descriptor if it's a directory? I'm thinking that if this were possible or easy, the O_DIRECTORY flag wouldn't have been created in the first place. Maciej From maciej at opencsw.org Fri Mar 2 10:24:40 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 2 Mar 2012 09:24:40 +0000 Subject: [csw-maintainers] Boost Message-ID: Hello maintainers, I started looking at the new Boost. My first attempt to build from subversion trunk resulted in a build log which counted 5584 occurrences of the word "error"[1]. There are bits of assembler code that expect v9 and don't build for v8 or v8+ /var/tmp//ccAYaEJg.s: Assembler messages: /var/tmp//ccAYaEJg.s:1320: Error: Architecture mismatch on "cas". /var/tmp//ccAYaEJg.s:1320: (Requires v9|v9a|v9b; requested architecture is v8.) Generally, the state of the Solaris build seem to be poor. I asked a question on the boost-build mailing list[2], but got no answers. My repost to the general Boost devel mailing list is awaiting moderation. Maybe I'll have more luck over there. Has anyone here attempted a Boost build recently? Do you have any tips&trick, e.g. how to integrate a function from gnulib? Maciej [1] http://buildfarm.opencsw.org/~maciej/boost-2012-02-29-09-51.log [2] http://lists.boost.org/boost-build/2012/02/25680.php From dam at opencsw.org Fri Mar 2 10:32:57 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 2 Mar 2012 10:32:57 +0100 Subject: [csw-maintainers] Boost In-Reply-To: References: Message-ID: <45905183-AC70-46BF-8D64-DAAB6D74398E@opencsw.org> Hi Maciej, Am 02.03.2012 um 10:24 schrieb Maciej (Matchek) Blizi?ski: > I started looking at the new Boost. My first attempt to build from > subversion trunk resulted in a build log which counted 5584 > occurrences of the word "error"[1]. There are bits of assembler code > that expect v9 and don't build for v8 or v8+ > > /var/tmp//ccAYaEJg.s: Assembler messages: > /var/tmp//ccAYaEJg.s:1320: Error: Architecture mismatch on "cas". > /var/tmp//ccAYaEJg.s:1320: (Requires v9|v9a|v9b; requested architecture is v8.) We go the path of providing 64 bit only for boost enabled stuff. In GAR there is the idiom BUILD64_ONLY = 1 which should allow this, but currently has issues with detecting isaexecable binaries. > Generally, the state of the Solaris build seem to be poor. I asked a > question on the boost-build mailing list[2], but got no answers. My > repost to the general Boost devel mailing list is awaiting moderation. > Maybe I'll have more luck over there. > > Has anyone here attempted a Boost build recently? Do you have any > tips&trick, e.g. how to integrate a function from gnulib? I doubt this is possible as boost has a special license similar to the BSD and MIT licenses and I doubt the project will allow code under GPL: http://www.boost.org/users/license.html So regardless of the fix gnulib chose, you would either need to rewrite it or find a replacement under the appropriate license. Best regards -- Dago > > Maciej > > [1] http://buildfarm.opencsw.org/~maciej/boost-2012-02-29-09-51.log > [2] http://lists.boost.org/boost-build/2012/02/25680.php > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Fri Mar 2 10:34:24 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 2 Mar 2012 10:34:24 +0100 Subject: [csw-maintainers] Boost In-Reply-To: <45905183-AC70-46BF-8D64-DAAB6D74398E@opencsw.org> References: <45905183-AC70-46BF-8D64-DAAB6D74398E@opencsw.org> Message-ID: <05DE8C9C-65FD-44F3-A663-8FECDADC8626@opencsw.org> Hi, I just noticed I missed an (important) word :-) Am 02.03.2012 um 10:32 schrieb Dagobert Michelsen: > Am 02.03.2012 um 10:24 schrieb Maciej (Matchek) Blizi?ski: >> I started looking at the new Boost. My first attempt to build from >> subversion trunk resulted in a build log which counted 5584 >> occurrences of the word "error"[1]. There are bits of assembler code >> that expect v9 and don't build for v8 or v8+ >> >> /var/tmp//ccAYaEJg.s: Assembler messages: >> /var/tmp//ccAYaEJg.s:1320: Error: Architecture mismatch on "cas". >> /var/tmp//ccAYaEJg.s:1320: (Requires v9|v9a|v9b; requested architecture is v8.) > > We can > go the path of providing 64 bit only for boost enabled stuff. > In GAR there is the idiom BUILD64_ONLY = 1 which should allow this, > but currently has issues with detecting isaexecable binaries. > >> Generally, the state of the Solaris build seem to be poor. I asked a >> question on the boost-build mailing list[2], but got no answers. My >> repost to the general Boost devel mailing list is awaiting moderation. >> Maybe I'll have more luck over there. >> >> Has anyone here attempted a Boost build recently? Do you have any >> tips&trick, e.g. how to integrate a function from gnulib? > > I doubt this is possible as boost has a special license similar to the BSD and > MIT licenses and I doubt the project will allow code under GPL: > http://www.boost.org/users/license.html > So regardless of the fix gnulib chose, you would either need to rewrite it > or find a replacement under the appropriate license. > > > Best regards > > -- Dago > >> >> Maciej >> >> [1] http://buildfarm.opencsw.org/~maciej/boost-2012-02-29-09-51.log >> [2] http://lists.boost.org/boost-build/2012/02/25680.php >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers >> .:: This mailing list's archive is public. ::. > > -- > "You don't become great by trying to be great, you become great by wanting to do something, > and then doing it so hard that you become great in the process." - xkcd #896 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -- "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 Joerg.Schilling at fokus.fraunhofer.de Fri Mar 2 11:14:49 2012 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Fri, 02 Mar 2012 11:14:49 +0100 Subject: [csw-maintainers] [csw-devel] [PATCH 1/4] Test for O_DIRECTORY In-Reply-To: References: <1330508909-16469-1-git-send-email-maciej@opencsw.org> <1330508909-16469-2-git-send-email-maciej@opencsw.org> <4f4e3b42.W+3ZA3bVj8qPyOYv%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <4f509d99.EPjnpw4HBN8HqUQ+%Joerg.Schilling@fokus.fraunhofer.de> Maciej (Matchek) Blizi??ski wrote: > Hello maintainers, > > Here's a porting topic. It started with me working on a VLC build. > O_DIRECTORY is not available on Solaris 10 and my patch to set it to 0 > has been rejected. I'm looking for a better solution. More below. So they reject the best possible solution? This sounds really strange. 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 maciej at opencsw.org Fri Mar 2 11:32:23 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 2 Mar 2012 10:32:23 +0000 Subject: [csw-maintainers] [csw-devel] [PATCH 1/4] Test for O_DIRECTORY In-Reply-To: <4f509d99.EPjnpw4HBN8HqUQ+%Joerg.Schilling@fokus.fraunhofer.de> References: <1330508909-16469-1-git-send-email-maciej@opencsw.org> <1330508909-16469-2-git-send-email-maciej@opencsw.org> <4f4e3b42.W+3ZA3bVj8qPyOYv%Joerg.Schilling@fokus.fraunhofer.de> <4f509d99.EPjnpw4HBN8HqUQ+%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: 2012/3/2 Joerg Schilling : >> Here's a porting topic. It started with me working on a VLC build. >> O_DIRECTORY is not available on Solaris 10 and my patch to set it to 0 >> has been rejected. I'm looking for a better solution. More below. > > So they reject the best possible solution? > > This sounds really strange. It does sound strange, doesn't it? I've asked for suggestions[1], but got no answers. Is there anything online that I could refer to in order to demonstrate that this is a sane approach? Maciej [1] http://mailman.videolan.org/pipermail/vlc-devel/2012-March/086993.html From maciej at opencsw.org Fri Mar 2 11:37:16 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 2 Mar 2012 10:37:16 +0000 Subject: [csw-maintainers] Boost In-Reply-To: <05DE8C9C-65FD-44F3-A663-8FECDADC8626@opencsw.org> References: <45905183-AC70-46BF-8D64-DAAB6D74398E@opencsw.org> <05DE8C9C-65FD-44F3-A663-8FECDADC8626@opencsw.org> Message-ID: 2012/3/2 Dagobert Michelsen : > I just noticed I missed an (important) word :-) I liked how definitive that sentence originally sounded. ;-) Okay, let's work on the 64-bit build first. If the 32-bit build is too hard (e.g. requiring assembly programming), we'll skip it. Maciej From Joerg.Schilling at fokus.fraunhofer.de Fri Mar 2 11:51:51 2012 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Fri, 02 Mar 2012 11:51:51 +0100 Subject: [csw-maintainers] [csw-devel] [PATCH 1/4] Test for O_DIRECTORY In-Reply-To: References: <1330508909-16469-1-git-send-email-maciej@opencsw.org> <1330508909-16469-2-git-send-email-maciej@opencsw.org> <4f4e3b42.W+3ZA3bVj8qPyOYv%Joerg.Schilling@fokus.fraunhofer.de> <4f509d99.EPjnpw4HBN8HqUQ+%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <4f50a647./1Z6aCqo27+ahJ3L%Joerg.Schilling@fokus.fraunhofer.de> Maciej (Matchek) Blizi??ski wrote: > 2012/3/2 Joerg Schilling : > >> Here's a porting topic. It started with me working on a VLC build. > >> O_DIRECTORY is not available on Solaris 10 and my patch to set it to 0 > >> has been rejected. I'm looking for a better solution. More below. > > > > So they reject the best possible solution? > > > > This sounds really strange. > > It does sound strange, doesn't it? I've asked for suggestions[1], but > got no answers. Is there anything online that I could refer to in > order to demonstrate that this is a sane approach? As mentioned before, POSIX grants that O_* are #defined, so you can safely rely on #ifdef O_XXX. > Maciej > > [1] http://mailman.videolan.org/pipermail/vlc-devel/2012-March/086993.html Sorry, it seems that I confused O_DIRECTORY with O_SEARCH I entered O_SEARCH into POSIX in order to permit: int f = open(name, O_SEARCH); result = fstat(f, &sb); or f2 = openat(f, name2, flags); to work with no restrictions compared to a filename-only case. The correct way to deal with O_DIRECTORY is: #ifndef O_DIRECTORY /* Fail if not a directory */ # define O_DIRECTORY 0 #endif int f = open(dirname, O_DIRECTORY); #if O_DIRECTORY != 0 if (f >= 0) { fstat(f, &sb); if (!S_ISDIR(sb.st_mode)) { flose(f); f = -1; errno = ENOTDIR; } } #endif if (f < 0) err(..); 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 maciej at opencsw.org Fri Mar 2 11:59:19 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 2 Mar 2012 10:59:19 +0000 Subject: [csw-maintainers] [csw-devel] [PATCH 1/4] Test for O_DIRECTORY In-Reply-To: <4f50a647./1Z6aCqo27+ahJ3L%Joerg.Schilling@fokus.fraunhofer.de> References: <1330508909-16469-1-git-send-email-maciej@opencsw.org> <1330508909-16469-2-git-send-email-maciej@opencsw.org> <4f4e3b42.W+3ZA3bVj8qPyOYv%Joerg.Schilling@fokus.fraunhofer.de> <4f509d99.EPjnpw4HBN8HqUQ+%Joerg.Schilling@fokus.fraunhofer.de> <4f50a647./1Z6aCqo27+ahJ3L%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: 2012/3/2 Joerg Schilling : > ? ? ? ? ? ? ? ?if (!S_ISDIR(sb.st_mode)) { Cool, this is what I've been looking for. Thanks, J?rg! I'll roll it into a patch and resubmit to vlc-devel. Maciej From Joerg.Schilling at fokus.fraunhofer.de Fri Mar 2 12:05:46 2012 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Fri, 02 Mar 2012 12:05:46 +0100 Subject: [csw-maintainers] [csw-devel] [PATCH 1/4] Test for O_DIRECTORY In-Reply-To: <4f50a647./1Z6aCqo27+ahJ3L%Joerg.Schilling@fokus.fraunhofer.de> References: <1330508909-16469-1-git-send-email-maciej@opencsw.org> <1330508909-16469-2-git-send-email-maciej@opencsw.org> <4f4e3b42.W+3ZA3bVj8qPyOYv%Joerg.Schilling@fokus.fraunhofer.de> <4f509d99.EPjnpw4HBN8HqUQ+%Joerg.Schilling@fokus.fraunhofer.de> <4f50a647./1Z6aCqo27+ahJ3L%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <4f50a98a.9pKZ78gzOA2c+M16%Joerg.Schilling@fokus.fraunhofer.de> Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) wrote: > The correct way to deal with O_DIRECTORY is: > > #ifndef O_DIRECTORY /* Fail if not a directory */ > # define O_DIRECTORY 0 > #endif > > int f = open(dirname, O_DIRECTORY); > #if O_DIRECTORY != 0 > if (f >= 0) { > fstat(f, &sb); > if (!S_ISDIR(sb.st_mode)) { > flose(f); > f = -1; > errno = ENOTDIR; > } > } > #endif > if (f < 0) > err(..); Sorry for the typo, this should be: #if O_DIRECTORY == 0 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 maciej at opencsw.org Fri Mar 2 16:44:10 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 2 Mar 2012 15:44:10 +0000 Subject: [csw-maintainers] [csw-devel] [PATCH 1/4] Test for O_DIRECTORY In-Reply-To: <4f50a98a.9pKZ78gzOA2c+M16%Joerg.Schilling@fokus.fraunhofer.de> References: <1330508909-16469-1-git-send-email-maciej@opencsw.org> <1330508909-16469-2-git-send-email-maciej@opencsw.org> <4f4e3b42.W+3ZA3bVj8qPyOYv%Joerg.Schilling@fokus.fraunhofer.de> <4f509d99.EPjnpw4HBN8HqUQ+%Joerg.Schilling@fokus.fraunhofer.de> <4f50a647./1Z6aCqo27+ahJ3L%Joerg.Schilling@fokus.fraunhofer.de> <4f50a98a.9pKZ78gzOA2c+M16%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: In the meantime, R?mi rewrote this bit of code and got rid of O_DIRECTORY: http://git.videolan.org/?p=vlc.git;a=commitdiff;h=54ff6997ce186837319168090a588d543fa35a3e;hp=7222ec271911a579b95ed57b48956787f850e0a7 So there's no need for patching it any more. Maciej From dam at opencsw.org Fri Mar 2 22:04:41 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 2 Mar 2012 22:04:41 +0100 Subject: [csw-maintainers] Problem with GIT repository cloning at github Message-ID: <9DE9EA53-F59C-492E-99EA-2A9CB572FE2F@opencsw.org> Hi, I wanted to update a package which pulls a treeish directly from github and it doesn't seem to work any more. The mechanism in GAR is based on "git archive" something like git archive --remote=git://github.com/blair/orca.git The answer from the upstream repo is fatal: git archive: protocol error and when I truss the git command the upstream server communication looks like this: 7563: write(5, 0x001E1E71, 55) = 55 7563: 0 0 3 7 g i t - u p l o a d - a r c h i v e / b l a i r / o r 7563: c a . g i t\0 h o s t = g i t h u b . c o m\0 7563: write(5, " 0 0 0 0", 4) = 4 7563: read(4, " 0 0 9 5", 4) = 4 7563: read(4, 0xFFBEF678, 145) = 145 7563: E R R \n Y o u r G i t c l i e n t h a s m a d e 7563: a n i n v a l i d r e q u e s t :\n 0 0 3 7 g i t - u p 7563: l o a d - a r c h i v e / b l a i r / o r c a . g i t\0 h o s 7563: t = g i t h u b . c o m\0\n E m a i l s u p p o r t @ g i 7563: t h u b . c o m f o r h e l p Has this been disabled for github? Or has something else changed? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From bwalton at opencsw.org Fri Mar 2 22:08:31 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 02 Mar 2012 16:08:31 -0500 Subject: [csw-maintainers] Problem with GIT repository cloning at github In-Reply-To: <9DE9EA53-F59C-492E-99EA-2A9CB572FE2F@opencsw.org> References: <9DE9EA53-F59C-492E-99EA-2A9CB572FE2F@opencsw.org> Message-ID: <1330722397-sup-9243@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Fri Mar 02 16:04:41 -0500 2012: Hi Dago, > I wanted to update a package which pulls a treeish directly from > github and it doesn't seem to work any more. The mechanism in GAR is > based on "git archive" something like git archive > --remote=git://github.com/blair/orca.git The answer from the > upstream repo is fatal: git archive: protocol error and when I truss > the git command the upstream server communication looks like this: I had talked with Sebastian about removing this but it didn't get yanked out yet. So if it's not working then either a change in git or some other error is the cause. The path should be (pseudo): git fetch --bare /path/to/local.git git archive --bare /path/to/local.git --stdout | tar -xvf $(WORKSRC) or something similar. I can look at this in the evening. I assume it's the orca package? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Fri Mar 2 22:14:27 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 2 Mar 2012 22:14:27 +0100 Subject: [csw-maintainers] Problem with GIT repository cloning at github In-Reply-To: <1330722397-sup-9243@pinkfloyd.chass.utoronto.ca> References: <9DE9EA53-F59C-492E-99EA-2A9CB572FE2F@opencsw.org> <1330722397-sup-9243@pinkfloyd.chass.utoronto.ca> Message-ID: <56014925-F311-4832-8FB8-3DE287614196@opencsw.org> Hi Ben, Am 02.03.2012 um 22:08 schrieb Ben Walton: > Excerpts from Dagobert Michelsen's message of Fri Mar 02 16:04:41 -0500 2012: >> I wanted to update a package which pulls a treeish directly from >> github and it doesn't seem to work any more. The mechanism in GAR is >> based on "git archive" something like git archive >> --remote=git://github.com/blair/orca.git The answer from the >> upstream repo is fatal: git archive: protocol error and when I truss >> the git command the upstream server communication looks like this: > > I had talked with Sebastian about removing this but it didn't get > yanked out yet. So if it's not working then either a change in git or > some other error is the cause. > > The path should be (pseudo): > > git fetch --bare /path/to/local.git ...and the local git should be in /home/src? And if it there should an update be done? > git archive --bare /path/to/local.git --stdout | tar -xvf $(WORKSRC) > > or something similar. > > I can look at this in the evening. I assume it's the orca package? Yes, indeed. Would be cool. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From bwalton at opencsw.org Fri Mar 2 22:17:33 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 02 Mar 2012 16:17:33 -0500 Subject: [csw-maintainers] Problem with GIT repository cloning at github In-Reply-To: <56014925-F311-4832-8FB8-3DE287614196@opencsw.org> References: <9DE9EA53-F59C-492E-99EA-2A9CB572FE2F@opencsw.org> <1330722397-sup-9243@pinkfloyd.chass.utoronto.ca> <56014925-F311-4832-8FB8-3DE287614196@opencsw.org> Message-ID: <1330722959-sup-8620@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Fri Mar 02 16:14:27 -0500 2012: Hi Dago, > ...and the local git should be in /home/src? And if it there should > an update be done? Yes, a fetch should happen. If someone else created this, there is a possibility for file access issues. You might want to take a look at /home/src/$(NAME).git and see if there is something you don't have rights to as 'dam'...But given the error you saw, I don't expect so. > > git archive --bare /path/to/local.git --stdout | tar -xvf $(WORKSRC) > > > > or something similar. > > > > I can look at this in the evening. I assume it's the orca package? > > Yes, indeed. Would be cool. Ok. It'll fit in the middle of php fixing and rss hacking. :) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Mar 3 03:01:39 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 02 Mar 2012 21:01:39 -0500 Subject: [csw-maintainers] Problem with GIT repository cloning at github In-Reply-To: <9DE9EA53-F59C-492E-99EA-2A9CB572FE2F@opencsw.org> References: <9DE9EA53-F59C-492E-99EA-2A9CB572FE2F@opencsw.org> Message-ID: <1330739859-sup-1271@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Fri Mar 02 16:04:41 -0500 2012: Hi Dago, > I wanted to update a package which pulls a treeish directly from > github and it doesn't seem to work any more. The mechanism in GAR is > based on "git archive" something like git archive > --remote=git://github.com/blair/orca.git The answer from the Ok, I cleaned up a bit of the pull code as git now sets up the origin remote properly in the way we use it. That leaves the problem that the extract step still fails. The VERSION in that recipe is set to a sha1 and GIT_TREEISH is set to VERSION. That would work if the sha1 existed but it doesn't. I'd set the version to a 'normal' value and then reference a tag in the repo from GIT_TREEISH (possibly automatically leveraging VERSION still). I don't know what that is, but you can see the available tags with: cd /home/src/orca.git; git --bare tag It should work once you've updated to a usable treeish. Now why the old sha1 disappeared, I don't know. This can only happen if they removed a published commit (rewrite history; push -f). Let me know if you hit more problems with this. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sat Mar 3 10:28:48 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 3 Mar 2012 09:28:48 +0000 Subject: [csw-maintainers] Python pyconfig.h headers Message-ID: Python installs a file called pyconfig.h which contains information it has gathered about the OS during build time. This includes bits like _XOPEN_SOURCE, which are determined by what standards does the build host support. That changes from one Solaris version to another, and I've verified that if you build on Solaris 9, you get different contents of pyconfig.h than when you build on Solaris 10. This seems to me like we should supply at least separate python_dev packages for 9 and 10, if not the whole package. Thoughts? Maciej From pfelecan at opencsw.org Sat Mar 3 11:05:12 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 03 Mar 2012 11:05:12 +0100 Subject: [csw-maintainers] Python pyconfig.h headers In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sat, 3 Mar 2012 09:28:48 +0000") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > Thoughts? Drop Solaris 9 support! -- Peter From bwalton at opencsw.org Sat Mar 3 13:59:59 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 03 Mar 2012 07:59:59 -0500 Subject: [csw-maintainers] Python pyconfig.h headers In-Reply-To: References: Message-ID: <1330779348-sup-69@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Sat Mar 03 04:28:48 -0500 2012: > Python installs a file called pyconfig.h which contains information > it has gathered about the OS during build time. This includes bits > like _XOPEN_SOURCE, which are determined by what standards does the > build host support. That changes from one Solaris version to > another, and I've verified that if you build on Solaris 9, you get > different contents of pyconfig.h than when you build on Solaris > 10. This seems to me like we should supply at least separate > python_dev packages for 9 and 10, if not the whole package. Does it negatively impact the ability of a user to build a binary egg locally? If so, I'd say it's worth either dropping 9 support[1] or providing platform specific packages. If not, I'd just carry on as is. Does python have an equivalent of rbconfig.rb to help build binary eggs? Thanks -Ben [1] I understand Peter's sentiment here too but if it builds easily on 9 then it's still a benefit to some sites. The rule of thumb I'm using is that if it isn't clean on 9 but is on 10, I drop 9 without hestiation. If it builds cleanly on 9 (or the fix for 10 would also help 9), I still build for 9. -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Sat Mar 3 16:25:11 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 03 Mar 2012 16:25:11 +0100 Subject: [csw-maintainers] Python pyconfig.h headers In-Reply-To: <1330779348-sup-69@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Sat, 03 Mar 2012 07:59:59 -0500") References: <1330779348-sup-69@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > [1] I understand Peter's sentiment here too but if it builds easily on > 9 then it's still a benefit to some sites. The rule of thumb I'm > using is that if it isn't clean on 9 but is on 10, I drop 9 > without hestiation. If it builds cleanly on 9 (or the fix for 10 > would also help 9), I still build for 9. It's not only about building cleanly, but also about effort spent for an antique release of the operating system when that effort can be used for more useful things. Again, my 2 oboloi worth of opinion -- Peter From bwalton at opencsw.org Sat Mar 3 17:35:17 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 03 Mar 2012 11:35:17 -0500 Subject: [csw-maintainers] Python pyconfig.h headers In-Reply-To: References: <1330779348-sup-69@pinkfloyd.chass.utoronto.ca> Message-ID: <1330792463-sup-5879@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Sat Mar 03 10:25:11 -0500 2012: > It's not only about building cleanly, but also about effort spent > for an antique release of the operating system when that effort can > be used for more useful things. Agreed. In this case, if effort to modify the build recipe is required to make this clean for 9 and 10 it's not likely worth it...at least I wouldn't invest the time. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sat Mar 3 22:17:34 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 3 Mar 2012 21:17:34 +0000 Subject: [csw-maintainers] Boost In-Reply-To: References: <45905183-AC70-46BF-8D64-DAAB6D74398E@opencsw.org> <05DE8C9C-65FD-44F3-A663-8FECDADC8626@opencsw.org> Message-ID: 2012/3/2 Maciej (Matchek) Blizi?ski : > 2012/3/2 Dagobert Michelsen : >> I just noticed I missed an (important) word :-) > > I liked how definitive that sentence originally sounded. ;-) > > Okay, let's work on the 64-bit build first. If the 32-bit build is too > hard (e.g. requiring assembly programming), we'll skip it. Update: By disabling the Python module (which we can't build because we have no 64-bit Python), I have succeeded in a proof-of-concept build outside GAR. The next step is to build it under GAR. I'm giving the build64only branch a go, but I know that it's not finished. Dago, please feel nudged about the 64-bit-only build in GAR! :-) Maciej From maciej at opencsw.org Sat Mar 3 22:31:56 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 3 Mar 2012 21:31:56 +0000 Subject: [csw-maintainers] Subversion: ld: fatal: library -lsvn_client-1: not found Message-ID: Hello maintainers, Here's a build conundrum from the land of Subversion. Warning: Lots of ugly error messages in this email. When setting --libdir to /opt/csw/lib (which seems sane to me), the build fails as follows: libtool: install: warning: relinking `libsvn_swig_py-1.la' libtool: install: (cd /home/maciej/src/opencsw/pkg/subversion/trunk/work/solaris10-sparc/build-isa-sparcv8plus/subversion-1.7.3/subversion/bindings/swig/python/libsvn_swig_py; /bin/bash /home/maciej/src/opencsw/pkg/subversion/trunk/work/solaris10-sparc/build-isa-sparcv8plus/subversion-1.7.3/libtool --tag CC --silent --mode=relink /opt/SUNWspro/bin/cc -xO3 -m32 -xarch=sparc -mt -D_LARGEFILE64_SOURCE -DNE_LFS -m32 -xarch=sparc -L/opt/csw/bdb48/lib -L/opt/csw/lib -L/opt/csw/lib -lintl -liconv -L/opt/csw/bdb48/lib/. -L/opt/csw/lib -L/opt/csw/lib -rpath /opt/csw/lib -o libsvn_swig_py-1.la swigutil_py.lo ../../../../../subversion/libsvn_client/libsvn_client-1.la ../../../../../subversion/libsvn_wc/libsvn_wc-1.la ../../../../../subversion/libsvn_ra/libsvn_ra-1.la ../../../../../subversion/libsvn_delta/libsvn_delta-1.la ../../../../../subversion/libsvn_subr/libsvn_subr-1.la -L/opt/csw/lib -laprutil-1 -L/opt/csw/lib -lapr-1 -lsocket -inst-prefix-dir /home/maciej/src/opencsw/pkg/subversion/trunk/work/solaris10-sparc/install-isa-sparcv8plus/lib/python) ld: fatal: library -lsvn_client-1: not found ld: fatal: File processing errors. No output written to .libs/libsvn_swig_py-1.so.0.0.0 libtool: install: error: relink `libsvn_swig_py-1.la' with the above command before installing it gmake[2]: *** [install-swig-py-lib] Error 1 gmake[2]: Leaving directory `/home/maciej/src/opencsw/pkg/subversion/trunk/work/solaris10-sparc/build-isa-sparcv8plus/subversion-1.7.3' gmake[1]: *** [svn-python] Error 2 gmake[1]: Leaving directory `/home/maciej/src/opencsw/pkg/subversion/trunk' gmake: *** [merge-isa-sparcv8plus] Error 2 The problem is probably that the compiler invocation does not find the libsvn_client-1.so file. The file itself exists: work/solaris10-sparc/build-isa-sparcv8plus/subversion-1.7.3/subversion/libsvn_client/.libs/libsvn_client-1.so The failing compiler invocation is a long one: (cd /home/maciej/src/opencsw/pkg/subversion/trunk/work/solaris10-sparc/build-isa-sparcv8plus/subversion-1.7.3/subversion/bindings/swig/python/libsvn_swig_py; /opt/SUNWspro/bin/cc -G -h libsvn_swig_py-1.so.0 -o .libs/libsvn_swig_py-1.so.0.0.0 .libs/swigutil_py.o -R/opt/csw/lib -L/home/maciej/src/opencsw/pkg/subversion/trunk/work/solaris10-sparc/build-isa-sparcv8plus/subversion-1.7.3/subversion/libsvn_wc/.libs -L/home/maciej/src/opencsw/pkg/subversion/trunk/work/solaris10-sparc/build-isa-sparcv8plus/subversion-1.7.3/subversion/libsvn_ra/.libs -L/home/maciej/src/opencsw/pkg/subversion/trunk/work/solaris10-sparc/build-isa-sparcv8plus/subversion-1.7.3/subversion/libsvn_diff/.libs -L/home/maciej/src/opencsw/pkg/subversion/trunk/work/solaris10-sparc/build-isa-sparcv8plus/subversion-1.7.3/subversion/libsvn_ra_local/.libs -L/home/maciej/src/opencsw/pkg/subversion/trunk/work/solaris10-sparc/build-isa-sparcv8plu s/subversion-1.7.3/subversion/libsvn_repos/.libs -L/home/maciej/src/opencsw/pkg/subversion/trunk/work/solaris10-sparc/build-isa-sparcv8plus/subversion-1.7.3/subversion/libsvn_fs/.libs -L/home/maciej/src/opencsw/pkg/subversion/trunk/work/solaris10-sparc/build-isa-sparcv8plus/subversion-1.7.3/subversion/libsvn_fs_fs/.libs -L/home/maciej/src/opencsw/pkg/subversion/trunk/work/solaris10-sparc/build-isa-sparcv8plus/subversion-1.7.3/subversion/libsvn_fs_base/.libs -L/home/maciej/src/opencsw/pkg/subversion/trunk/work/solaris10-sparc/build-isa-sparcv8plus/subversion-1.7.3/subversion/libsvn_fs_util/.libs -L/home/maciej/src/opencsw/pkg/subversion/trunk/work/solaris10-sparc/build-isa-sparcv8plus/subversion-1.7.3/subversion/libsvn_ra_svn/.libs -L/home/maciej/src/opencsw/pkg/subversion/trunk/work/solaris10-sparc/build-isa-sparcv8plus/subversion-1.7.3/subversion/libsvn_ra_neon/.libs -L/home/maciej/src/opencsw/pkg/subversion/trunk/work/solaris10-sparc/build-isa-sparcv8plus/subversion-1.7.3/subversion/libsvn_delta/.libs -L/home/maciej/src/opencsw/pkg/subversion/trunk/work/solaris10-sparc/build-isa-sparcv8plus/subversion-1.7.3/subversion/libsvn_subr/.libs -L/opt/csw/bdb48/lib -L/opt/csw/lib -L/opt/csw/bdb48/lib/. -L/home/maciej/src/opencsw/pkg/subversion/trunk/work/solaris10-sparc/install-isa-sparcv8plus/lib/python/opt/csw/lib -lsvn_client-1 -lsvn_wc-1 -lsvn_diff-1 -lsvn_ra-1 -lsvn_ra_local-1 -lsvn_repos-1 -lsvn_fs-1 -lsvn_fs_fs-1 -lsvn_fs_base-1 -ldb-4.8 -lsvn_fs_util-1 -lsvn_ra_svn-1 -lsasl2 -lsvn_ra_neon-1 -lneon -lssl -lcrypto -lnsl -ldl -lsvn_delta-1 -lsvn_subr-1 -lintl -liconv -lexpat -lz -lsqlite3 -lmagic -laprutil-1 -lapr-1 -lsocket -lc -m32 -xarch=sparc -mt -m32 -xarch=sparc -mt) The libsvn_client/.libs directory is prominently absent from the invocation, so that explains the failure. The question is, why is this directory absent from the invocation. To reproduce the problem, it's enough to apply this change to the Makefile: -SVNLIB = $(prefix)/lib/svn +SVNLIB = $(libdir) If anyone's interested in figuring this puzzle out, the challenge is open. The prize is, as usual, eternal fame and glory. Maciej From maciej at opencsw.org Sun Mar 4 01:36:41 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 4 Mar 2012 00:36:41 +0000 Subject: [csw-maintainers] Wintercamp 2011 In-Reply-To: References: <4F169DE1.10904@lutter.sk> Message-ID: I've booked my flights. I'm arriving on Friday morning and leaving Monday early morning. Where do we stay in Bratislava? Do you have any hotel recommendations? Maciej From maciej at opencsw.org Sun Mar 4 11:21:59 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 4 Mar 2012 10:21:59 +0000 Subject: [csw-maintainers] [checkpkg] Change to the shared library suggestions Message-ID: Heads up: I've just committed http://sourceforge.net/apps/trac/gar/changeset/17285 TL;DR: If you rebuild a package which bundles multiple shared libraries together, you will see new error tags. On the upside, checkpkg's brain became simpler and easier to understand. The long read from the commit log: checkpkg: Remove soname grouping guesswork Checkpkg used to guess that if multiple libraries share the same soname version, they should go into a single package. libfoo-something.so.1 libfoo-otherthing.so.1 => CSWlibfoo suggested This caused increased checkpkg code complexity and guesses were often wrong and/or confusing. It is simpler to take each soname separately without trying to create package groups. Less magic in checkpkg allows maintainers to have a clearer understanding of what and why checkpkg suggests. In the rather rare cases when multiple libraries are bundled in one package, overrides can be used. These cases are rather rare, because the main package which used to bundle libraries is Boost, and it will be split into one-lib-per-package anyway. Other cases are rather marginal, and often involve bundling libraries with different soname versions (e.g. Kerberos private libs). Maciej From maciej at opencsw.org Mon Mar 5 00:18:58 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 4 Mar 2012 23:18:58 +0000 Subject: [csw-maintainers] C++ libraries built with GCC In-Reply-To: <1330440134-sup-9283@pinkfloyd.chass.utoronto.ca> References: <1330278296-sup-7303@pinkfloyd.chass.utoronto.ca> <20120226191929.GA8597@quince.home.blizinski.pl> <1330440134-sup-9283@pinkfloyd.chass.utoronto.ca> Message-ID: 2012/2/28 Ben Walton : >> +1 for gxx > > That works. Cool. What about package names. Is CSWlibfoo1-gxx a sane convention? More broadly, if is the convention with CSW- a workable general idea? Maciej From maciej at opencsw.org Mon Mar 5 10:12:47 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 5 Mar 2012 09:12:47 +0000 Subject: [csw-maintainers] Tiers Message-ID: I'm resuming my work on tiers. I still have some mixed feelings about it, because the code will be more complicated and harder to maintain when we implement them. The plans involve an update to the buildfarm database and the RESTful interface. Also, updates will be needed to the release procedure. Now, csw-upload-pkg only releases packages into unstable. After the change, it will be into unstable/core or unstable/active. Which is it? It has to be decided somehow. Also, moving packages between tiers must be implemented, and dependency tracking / checking. Sometimes I'm thinking it's going to just fall apart. But we've decided that we want tiers, so I'm sticking to the plan. While I'm at it, the code and db update is not enough. Somebody has to actually go through our catalog and assign our 3000 or so packages to tiers. The work could happen on a less granular level, instead of processing individual packages, bundles can be processed instead. To those unfamiliar with the concept, tiers are about slicing our package catalog into three tiers: core - packages that we all care about. If a maintainer of a core package retires, we find a new maintainer for it. active - packages that have active maintainers and are receiving updates unmaintained - packages that do not receive updates (e.g. orphaned) but might be useful to users, so we don't want to drop them completely The main motivation behind tiers is user expectation setting. Currently, our catalogs are a big bag of old cruft and new shininess. We don't want a situation when a user downloads an old package which doesn't work and infers that the whole catalog is of the same quality. Dividing packages into tiers will allow us to set the expectations right. If you're installing from unmaintained, it's obvious that you're walking in a minefield. If you're installing from core, then your expectations are much higher. I'm calling for volunteers - I'm looking for someone to take the our catalogs and slice them up into tiers. The result will be three lists of package names, e.g. in a text file of some sensible format. JSON would be great. Any takers? Maciej From bonivart at opencsw.org Mon Mar 5 11:06:31 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 5 Mar 2012 11:06:31 +0100 Subject: [csw-maintainers] Tiers In-Reply-To: References: Message-ID: I suggest that we agree on the core packages, there shouldn't be too many of those, especially on the top level (not counting the dependencies that are dragged in). Active we could see what packages have been updated within a reasonable time (a year?) or has a maintainer that updates other packages (not all packages need updates). The rest are unmaintained. /peter From maciej at opencsw.org Mon Mar 5 12:24:18 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 5 Mar 2012 11:24:18 +0000 Subject: [csw-maintainers] Tiers In-Reply-To: References: Message-ID: 2012/3/5 Peter Bonivart : > I suggest that we agree on the core packages, there shouldn't be too > many of those, especially on the top level (not counting the > dependencies that are dragged in). Active we could see what packages > have been updated within a reasonable time (a year?) or has a > maintainer that updates other packages (not all packages need > updates). The rest are unmaintained. I agree. It's the matter of actually doing the research. All data are available via HTTP. Getting a catalog: curl -s http://buildfarm.opencsw.org/pkgdb/rest/catalogs/unstable/sparc/SunOS5.9/?quick=true | python -m json.tool This contains a list of packages identified by md5 sums. Getting full information about a package file: curl -s http://buildfarm.opencsw.org/pkgdb/rest/srv4/65d595581fa37117643375674838b9a3/ | python -m json.tool Maciej From bonivart at opencsw.org Mon Mar 5 19:00:13 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 5 Mar 2012 19:00:13 +0100 Subject: [csw-maintainers] Tiers In-Reply-To: References: Message-ID: 2012/3/5 Maciej (Matchek) Blizi?ski : > I agree. It's the matter of actually doing the research. To me, core is a variety of high profile packages one would expect to find if new to Solaris or often install as a more experienced Solaris admin. Obviously AMP but also a compiler and a couple of languages, mail, DNS and some security related packages. It can be debated which packages are most "popular" of course but this is my initial selection to start with. apache2 - A high performance Unix-based HTTP server. bind - ISC BIND DNS main package cas_cpsampleconf - Class action script cpsampleconf cas_cptemplates - Class action script cptemplates cas_crontab - Class action script crontab cas_etcservices - Class action script etcservices cas_etcshells - Class action script etcshells cas_inetd - Class action script inetd cas_initsmf - Class action script initsmf cas_migrateconf - Class action script migrateconf cas_postmsg - Class action script postmsg cas_preserveconf - Class action script preserveconf cas_pycompile - Class action script pycompile cas_texinfo - Class action script texinfo cas_usergroup - Class action script usergroup common - common files and dirs for CSW packages cswpki - The OpenCSW PKI Collection gcc4core - GNU C compiler mysql5 - Multithreaded SQL database openssh - OpenSSH Secure Shell server openssl - Openssl meta package perl - A high-level, general-purpose programming language php5 - A High-Level Scripting Language pkgutil - Installs Solaris packages easily python - A high-level scripting language, 2.6 series samba - Tools to access a servers filespace and printers via SMB (server) sendmail - Sendmail MTA These 27 packages with the dependencies needed results in 127 packages. I think it's best to populate core manually. Please everyone, chime in with your suggestions to remove/add to the above list. Active however, I think one way to populate it would be to look at all packages submitted the last 12 months and extract all maintainers from those. Now all packages owned by those maintainers (minus core packages) are active packages. The rest, all minus active minus core, are unmaintained. Can you Maciej with some db magic do what I suggest for active? /peter From bwalton at opencsw.org Mon Mar 5 22:20:56 2012 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 05 Mar 2012 16:20:56 -0500 Subject: [csw-maintainers] Tiers In-Reply-To: References: Message-ID: <1330982419-sup-4303@pinkfloyd.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Mon Mar 05 13:00:13 -0500 2012: > Active however, I think one way to populate it would be to look at > all packages submitted the last 12 months and extract all > maintainers from those. Now all packages owned by those maintainers > (minus core packages) are active packages. The rest, all minus > active minus core, are unmaintained. I very much like this idea. It's much simpler and should make maintenance easier. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert.thurner at gmail.com Fri Mar 2 20:19:08 2012 From: rupert.thurner at gmail.com (rupert THURNER) Date: Fri, 2 Mar 2012 20:19:08 +0100 Subject: [csw-maintainers] error on pkg upload? Message-ID: hi, currently i get the following: rupert @ login : ~ $ csw-upload-pkg pkgs/02.Mar.2012/cmake-2.8.7\,REV\=2012.03.02-SunOS5.9-* Processing 2 file(s). Please wait. Uploading 'pkgs/02.Mar.2012/cmake-2.8.7,REV=2012.03.02-SunOS5.9-i386-CSW.pkg.gz' WARNING:root:http://buildfarm.opencsw.org/pkgdb/rest/srv4/9e795be5eff6282b95bf8e1234bbdd0e/ -- HTTP Error 404: Not Found WARNING:root:pkgs/02.Mar.2012/cmake-2.8.7,REV=2012.03.02-SunOS5.9-sparc-CSW.pkg.gz (9e795be5eff6282b95bf8e1234bbdd0e) is not known to the database. INFO:root:Juicing the srv4 package stream files... Traceback (most recent call last): | File "/opt/csw/bin/pkgdb", line 684, in main() File "/opt/csw/bin/pkgdb", line 442, in main force_unpack=options.force_unpack) File "/opt/csw/lib/python/csw/package_stats.py", line 494, in CollectStatsFromFiles rupert. From juraj at lutter.sk Mon Mar 5 19:12:35 2012 From: juraj at lutter.sk (Juraj Lutter) Date: Mon, 5 Mar 2012 19:12:35 +0100 Subject: [csw-maintainers] Tiers In-Reply-To: References: Message-ID: Does this aim to be similar to Solatis' metaclusters? (SUNWreq .. SUNWCXall) On 5 Mar 2012, at 19:00, Peter Bonivart wrote: > 2012/3/5 Maciej (Matchek) Blizi?ski : >> I agree. It's the matter of actually doing the research. > > To me, core is a variety of high profile packages one would expect to > find if new to Solaris or often install as a more experienced Solaris > admin. Obviously AMP but also a compiler and a couple of languages, > mail, DNS and some security related packages. It can be debated which > packages are most "popular" of course but this is my initial selection > to start with. > > apache2 - A high performance Unix-based HTTP server. > bind - ISC BIND DNS main package > cas_cpsampleconf - Class action script cpsampleconf > cas_cptemplates - Class action script cptemplates > cas_crontab - Class action script crontab > cas_etcservices - Class action script etcservices > cas_etcshells - Class action script etcshells > cas_inetd - Class action script inetd > cas_initsmf - Class action script initsmf > cas_migrateconf - Class action script migrateconf > cas_postmsg - Class action script postmsg > cas_preserveconf - Class action script preserveconf > cas_pycompile - Class action script pycompile > cas_texinfo - Class action script texinfo > cas_usergroup - Class action script usergroup > common - common files and dirs for CSW packages > cswpki - The OpenCSW PKI Collection > gcc4core - GNU C compiler > mysql5 - Multithreaded SQL database > openssh - OpenSSH Secure Shell server > openssl - Openssl meta package > perl - A high-level, general-purpose programming language > php5 - A High-Level Scripting Language > pkgutil - Installs Solaris packages easily > python - A high-level scripting language, 2.6 series > samba - Tools to access a servers filespace and printers via SMB (server) > sendmail - Sendmail MTA > > These 27 packages with the dependencies needed results in 127 > packages. I think it's best to populate core manually. Please > everyone, chime in with your suggestions to remove/add to the above > list. > > Active however, I think one way to populate it would be to look at all > packages submitted the last 12 months and extract all maintainers from > those. Now all packages owned by those maintainers (minus core > packages) are active packages. The rest, all minus active minus core, > are unmaintained. > > Can you Maciej with some db magic do what I suggest for active? > > /peter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From maciej at opencsw.org Tue Mar 6 00:17:13 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 5 Mar 2012 23:17:13 +0000 Subject: [csw-maintainers] Tiers In-Reply-To: <1330982419-sup-4303@pinkfloyd.chass.utoronto.ca> References: <1330982419-sup-4303@pinkfloyd.chass.utoronto.ca> Message-ID: 2012/3/5 Ben Walton > > Excerpts from Peter Bonivart's message of Mon Mar 05 13:00:13 -0500 2012: > > > Active however, I think one way to populate it would be to look at > > all packages submitted the last 12 months and extract all > > maintainers from those. Now all packages owned by those maintainers > > (minus core packages) are active packages. The rest, all minus > > active minus core, are unmaintained. > > I very much like this idea. ?It's much simpler and should make > maintenance easier. Agreed. One more thing I just remembered from the last time I looked at it. Packages from one bundle might end up in different tiers. Mainly because of dependencies. Take PHP for example. We want PHP to be in core, but there are multiple modules that might depend on other packages that are in practice unmaintained. You don't want to include into core all the packages that PHP modules depend on. So some PHP modules will be in core, but some won't be. Maciej From maciej at opencsw.org Tue Mar 6 00:24:30 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 5 Mar 2012 23:24:30 +0000 Subject: [csw-maintainers] error on pkg upload? In-Reply-To: References: Message-ID: 2012/3/2 rupert THURNER : > hi, > > currently i get the following: > > rupert @ login : ~ > $ csw-upload-pkg pkgs/02.Mar.2012/cmake-2.8.7\,REV\=2012.03.02-SunOS5.9-* > Processing 2 file(s). Please wait. > Uploading 'pkgs/02.Mar.2012/cmake-2.8.7,REV=2012.03.02-SunOS5.9-i386-CSW.pkg.gz' > WARNING:root:http://buildfarm.opencsw.org/pkgdb/rest/srv4/9e795be5eff6282b95bf8e1234bbdd0e/ > -- HTTP Error 404: Not Found > WARNING:root:pkgs/02.Mar.2012/cmake-2.8.7,REV=2012.03.02-SunOS5.9-sparc-CSW.pkg.gz > (9e795be5eff6282b95bf8e1234bbdd0e) is not known to the database. > INFO:root:Juicing the srv4 package stream files... > Traceback (most recent call last): ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | > ?File "/opt/csw/bin/pkgdb", line 684, in > ? ?main() > ?File "/opt/csw/bin/pkgdb", line 442, in main > ? ?force_unpack=options.force_unpack) > ?File "/opt/csw/lib/python/csw/package_stats.py", line 494, in > CollectStatsFromFiles Do you still have the line with which you built the package? Was it by any chance anything like "mgar ENABLE_CHECK=0 package"? Maciej From rupert at opencsw.org Tue Mar 6 01:44:04 2012 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 6 Mar 2012 01:44:04 +0100 Subject: [csw-maintainers] error on pkg upload? In-Reply-To: References: Message-ID: oh ... i did not get the error any more ... no idea where it came from 2012/3/6 Maciej (Matchek) Blizi?ski : > 2012/3/2 rupert THURNER : >> hi, >> >> currently i get the following: >> >> rupert @ login : ~ >> $ csw-upload-pkg pkgs/02.Mar.2012/cmake-2.8.7\,REV\=2012.03.02-SunOS5.9-* >> Processing 2 file(s). Please wait. >> Uploading 'pkgs/02.Mar.2012/cmake-2.8.7,REV=2012.03.02-SunOS5.9-i386-CSW.pkg.gz' >> WARNING:root:http://buildfarm.opencsw.org/pkgdb/rest/srv4/9e795be5eff6282b95bf8e1234bbdd0e/ >> -- HTTP Error 404: Not Found >> WARNING:root:pkgs/02.Mar.2012/cmake-2.8.7,REV=2012.03.02-SunOS5.9-sparc-CSW.pkg.gz >> (9e795be5eff6282b95bf8e1234bbdd0e) is not known to the database. >> INFO:root:Juicing the srv4 package stream files... >> Traceback (most recent call last): ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | >> ?File "/opt/csw/bin/pkgdb", line 684, in >> ? ?main() >> ?File "/opt/csw/bin/pkgdb", line 442, in main >> ? ?force_unpack=options.force_unpack) >> ?File "/opt/csw/lib/python/csw/package_stats.py", line 494, in >> CollectStatsFromFiles > > Do you still have the line with which you built the package? Was it by > any chance anything like "mgar ENABLE_CHECK=0 package"? > > Maciej > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From maciej at opencsw.org Tue Mar 6 01:55:54 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 6 Mar 2012 00:55:54 +0000 Subject: [csw-maintainers] error on pkg upload? In-Reply-To: References: Message-ID: 2012/3/6 rupert THURNER : > oh ... i did not get the error any more ... no idea where it came from This error usually comes up if you try to upload without first checkpkg'ing it. From dam at opencsw.org Tue Mar 6 15:12:47 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 6 Mar 2012 15:12:47 +0100 Subject: [csw-maintainers] webzone restarted on the buildfarm Message-ID: <97A99F43-2D4C-49D9-87DE-F6EB14227CFA@opencsw.org> Hi, someone filled up /var/tmp on the webzone on the buildfarm. I cleaned that up and restarted the zone. Please make sure to not fill up the filesystems whoever that 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 From maciej at opencsw.org Tue Mar 6 19:44:13 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 6 Mar 2012 18:44:13 +0000 Subject: [csw-maintainers] webzone restarted on the buildfarm In-Reply-To: <97A99F43-2D4C-49D9-87DE-F6EB14227CFA@opencsw.org> References: <97A99F43-2D4C-49D9-87DE-F6EB14227CFA@opencsw.org> Message-ID: 2012/3/6 Dagobert Michelsen : > someone filled up /var/tmp on the webzone on the buildfarm. I cleaned that up > and restarted the zone. Please make sure to not fill up the filesystems whoever > that was. I'm not aware of anything that I might have done to /var/tmp, but I am fiddling with the web zone every now and then, so it could be me, without knowing. I'll mind the /var/tmp state in the future. Maciej From maciej at opencsw.org Wed Mar 7 00:44:13 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 6 Mar 2012 23:44:13 +0000 Subject: [csw-maintainers] The dublin release: remaining tasks In-Reply-To: References: <20111013090121.GA15669@bender.opencsw.org> <20111013101714.GB15669@bender.opencsw.org> <1328462253-sup-3570@pinkfloyd.chass.utoronto.ca> <1328921545-sup-4762@pinkfloyd.chass.utoronto.ca> Message-ID: What's the current status of PHP? There have been some bugs filed, so I suppose that PHP is not ready yet for final release? From bwalton at opencsw.org Wed Mar 7 02:06:10 2012 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 06 Mar 2012 20:06:10 -0500 Subject: [csw-maintainers] The dublin release: remaining tasks In-Reply-To: References: <20111013090121.GA15669@bender.opencsw.org> <20111013101714.GB15669@bender.opencsw.org> <1328462253-sup-3570@pinkfloyd.chass.utoronto.ca> <1328921545-sup-4762@pinkfloyd.chass.utoronto.ca> Message-ID: <1331082289-sup-2275@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Tue Mar 06 18:44:13 -0500 2012: Hi Maciej, > What's the current status of PHP? There have been some bugs filed, > so I suppose that PHP is not ready yet for final release? Well, there was a bit of 'the sky is falling' one day and the bugs are legit although not nearly so bad as I'd have thought initially. I do have some open issues that I'm addressing. Sadly it takes ages to build and package so it's slow going... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Wed Mar 7 08:49:06 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 7 Mar 2012 07:49:06 +0000 Subject: [csw-maintainers] Autoconf 2.13 Message-ID: One of packages I want to build, requires autoconf-2.13 (1999), and nothing later. I built a package with autoconf-2.13: http://buildfarm.opencsw.org/pkgdb/srv4/c34a5709eefd009df031358dbdb38db9/ The package works well for my purposes (coexists peacefully with the main autoconf package). I would like to release autoconf-2.13 to unstable, what do people think about the idea and file layout, any thoughts or objections? Maciej From dam at opencsw.org Wed Mar 7 09:09:25 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 7 Mar 2012 09:09:25 +0100 Subject: [csw-maintainers] webzone restarted on the buildfarm In-Reply-To: References: <97A99F43-2D4C-49D9-87DE-F6EB14227CFA@opencsw.org> Message-ID: Hi Maciej, Am 06.03.2012 um 19:44 schrieb Maciej (Matchek) Blizi?ski: > 2012/3/6 Dagobert Michelsen : >> someone filled up /var/tmp on the webzone on the buildfarm. I cleaned that up >> and restarted the zone. Please make sure to not fill up the filesystems whoever >> that was. > > I'm not aware of anything that I might have done to /var/tmp, but I am > fiddling with the web zone every now and then, so it could be me, > without knowing. I'll mind the /var/tmp state in the future. I know set up a quota for web (which I should have done from the first place). Additionally, the files looked like artifacts of pkgtrans not being cleaned up, however, I am not sure why this happens. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Wed Mar 7 09:18:39 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 7 Mar 2012 09:18:39 +0100 Subject: [csw-maintainers] The dublin release: remaining tasks In-Reply-To: <1331082289-sup-2275@pinkfloyd.chass.utoronto.ca> References: <20111013090121.GA15669@bender.opencsw.org> <20111013101714.GB15669@bender.opencsw.org> <1328462253-sup-3570@pinkfloyd.chass.utoronto.ca> <1328921545-sup-4762@pinkfloyd.chass.utoronto.ca> <1331082289-sup-2275@pinkfloyd.chass.utoronto.ca> Message-ID: <46459F52-E56A-4447-80CB-E1D7E96C6254@opencsw.org> Hi Ben, Am 07.03.2012 um 02:06 schrieb Ben Walton: > Excerpts from Maciej (Matchek) Blizi?ski's message of Tue Mar 06 18:44:13 -0500 2012: >> What's the current status of PHP? There have been some bugs filed, >> so I suppose that PHP is not ready yet for final release? > > Well, there was a bit of 'the sky is falling' one day and the bugs are > legit although not nearly so bad as I'd have thought initially. I do > have some open issues that I'm addressing. Sadly it takes ages to > build and package so it's slow going... We still have the V240 from Gore which you can access from the buildfarm with ssh build9s.go I am just updating it to unstable/. Wow, we were busy! :-) Total size: 405.8 MB Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From dam at opencsw.org Wed Mar 7 10:44:01 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 7 Mar 2012 10:44:01 +0100 Subject: [csw-maintainers] Autoconf 2.13 In-Reply-To: References: Message-ID: <8C8EC04D-0C4B-4EF4-AE3B-D55AD1CA5DE9@opencsw.org> Hi Maciej, Am 07.03.2012 um 08:49 schrieb Maciej (Matchek) Blizi?ski: > One of packages I want to build, requires autoconf-2.13 (1999), and > nothing later. I built a package with autoconf-2.13: > > http://buildfarm.opencsw.org/pkgdb/srv4/c34a5709eefd009df031358dbdb38db9/ > > The package works well for my purposes (coexists peacefully with the > main autoconf package). I would like to release autoconf-2.13 to > unstable, what do people think about the idea and file layout, any > thoughts or objections? Well, automake is a combined package where all old versions are in it and facilitating alternatives to switch it. This is mostly because automake is build to use the specific version where autoconf is usually not. In general the versionsuffix is sane IMHO and in this specific context also probably acceptable. 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 Mar 7 14:50:30 2012 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 07 Mar 2012 08:50:30 -0500 Subject: [csw-maintainers] The dublin release: remaining tasks In-Reply-To: <46459F52-E56A-4447-80CB-E1D7E96C6254@opencsw.org> References: <20111013090121.GA15669@bender.opencsw.org> <20111013101714.GB15669@bender.opencsw.org> <1328462253-sup-3570@pinkfloyd.chass.utoronto.ca> <1328921545-sup-4762@pinkfloyd.chass.utoronto.ca> <1331082289-sup-2275@pinkfloyd.chass.utoronto.ca> <46459F52-E56A-4447-80CB-E1D7E96C6254@opencsw.org> Message-ID: <1331128177-sup-7394@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Mar 07 03:18:39 -0500 2012: Hi Dago, > We still have the V240 from Gore which you can access from the > buildfarm with ssh build9s.go I moved php to sol10 as the test suite turns into a fork bomb on 9 and I didn't have the cycles to debug it... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Wed Mar 7 14:59:28 2012 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 07 Mar 2012 08:59:28 -0500 Subject: [csw-maintainers] webzone restarted on the buildfarm In-Reply-To: References: <97A99F43-2D4C-49D9-87DE-F6EB14227CFA@opencsw.org> Message-ID: <1331128689-sup-2411@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Mar 07 03:09:25 -0500 2012: > I know set up a quota for web (which I should have done from the > first place). Additionally, the files looked like artifacts of > pkgtrans not being cleaned up, however, I am not sure why this > happens. Having looked at the old checkpkg code, I know that Phil found that pkgtrans would leave files like this around as the result of some bug. He implemented a custom pkgtrans to avoid this. If any of the processes on the web zone are pkgtrans-ing lots of files (and I imagine this is common there), then this is the likely culprit. Maybe we could point tmpwatch at the directory it clutters up? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From schwindt at dfki.uni-kl.de Thu Mar 8 09:59:26 2012 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Thu, 08 Mar 2012 09:59:26 +0100 Subject: [csw-maintainers] Subversion: ld: fatal: library -lsvn_client-1: not found In-Reply-To: Your message of "Sat, 03 Mar 2012 21:31:56 GMT." Message-ID: <201203080859.q288xQJP022539@dfki.uni-kl.de> [...] > > -SVNLIB = $(prefix)/lib/svn This contains the needed lib, actually an old version > +SVNLIB = $(libdir) This does not. As you are staging into /home/maciej/src/opencsw/pkg/subversion/trunk/work/solaris10-sparc/pkgroot/ maybe setting -inst-prefix-dir for libtool to this dir would help? All the *.la's contain this reference. BTW : Did you see the Ticket in mantis I reopened ? In the current version of svn the python binding end up in /opt/csw/lib/svn/python/site-packages/ . Which is by default not included in python. And lookin into /home/maciej/src/opencsw/pkg/subversion/trunk/work/solaris10-sparc/pkgroot/ gives me the feeling this could happen again. Nicolai From maciej at opencsw.org Thu Mar 8 10:07:49 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 8 Mar 2012 09:07:49 +0000 Subject: [csw-maintainers] Subversion: ld: fatal: library -lsvn_client-1: not found In-Reply-To: <201203080859.q288xQJP022539@dfki.uni-kl.de> References: <201203080859.q288xQJP022539@dfki.uni-kl.de> Message-ID: 2012/3/8 Nicolai Schwindt : > [...] >> >> -SVNLIB ? ? = $(prefix)/lib/svn > > This contains the needed lib, actually an old version > >> +SVNLIB ? ? = $(libdir) > > This does not. I don't understand - SVNLIB is a private variable in GAR which is used to configure some directory settings. If it were set to something else, the subversion build would follow. No other packages install anything to /opt/csw/lib/svn, do they? > As you are staging into /home/maciej/src/opencsw/pkg/subversion/trunk/work/solaris10-sparc/pkgroot/ > maybe setting ?-inst-prefix-dir for libtool to this dir would help? > All the *.la's contain this reference. Rupert, how about trying that? > BTW : Did you see the Ticket in mantis I reopened ? In the current version of > svn the python binding end up in /opt/csw/lib/svn/python/site-packages/ . > Which is by default not included in python. > > And lookin into /home/maciej/src/opencsw/pkg/subversion/trunk/work/solaris10-sparc/pkgroot/ > gives me the feeling this could happen again. Yes, this is the case. From maciej at opencsw.org Thu Mar 8 10:30:38 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 8 Mar 2012 09:30:38 +0000 Subject: [csw-maintainers] webzone restarted on the buildfarm In-Reply-To: <1331128689-sup-2411@pinkfloyd.chass.utoronto.ca> References: <97A99F43-2D4C-49D9-87DE-F6EB14227CFA@opencsw.org> <1331128689-sup-2411@pinkfloyd.chass.utoronto.ca> Message-ID: 2012/3/7 Ben Walton : > Having looked at the old checkpkg code, I know that Phil found that > pkgtrans would leave files like this around as the result of some > bug. ?He implemented a custom pkgtrans to avoid this. We're using a custom pkgtrans. > If any of the > processes on the web zone are pkgtrans-ing lots of files (and I > imagine this is common there), then this is the likely culprit. ?Maybe > we could point tmpwatch at the directory it clutters up? Sounds like a good idea. From schwindt at dfki.uni-kl.de Thu Mar 8 10:56:32 2012 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Thu, 08 Mar 2012 10:56:32 +0100 Subject: [csw-maintainers] Subversion: ld: fatal: library -lsvn_client-1: not found In-Reply-To: Your message of "Thu, 08 Mar 2012 09:07:49 GMT." Message-ID: <201203080956.q289uWFS029537@dfki.uni-kl.de> > 2012/3/8 Nicolai Schwindt : > > [...] > >> > >> -SVNLIB ?? ?? = $(prefix)/lib/svn > > > > This contains the needed lib, actually an old version > > > >> +SVNLIB ?? ?? = $(libdir) > > > > This does not. > > I don't understand - SVNLIB is a private variable in GAR which is used > to configure some directory settings. If it were set to something > else, the subversion build would follow. No other packages install > anything to /opt/csw/lib/svn, do they? The variable gets used to configure : CONFIGURE_ARGS = $(DIRPATHS) --libdir=$(SVNLIB) --libexecdir=$(SVNLIB) With SVNLIB=$(prefix)/lib/svn the linker got -L/opt/csw/lib/svn and used the old libraries. With SVNLIB=$(libdir) the linker gets -L/opt/csw anf fails. While staging to DESTIDR you would need : -L/home/maciej/src/opencsw/pkg/subversion/trunk/work/solaris10-sparc/pkgroot/opt /csw/lib/svn Doing this on a machine which does not contain an old version of subversion would fail for both settings of SVNLIB. Subversion seems generally broken - the code and the build. Nicolai From rupert at opencsw.org Thu Mar 8 12:32:43 2012 From: rupert at opencsw.org (rupert THURNER) Date: Thu, 8 Mar 2012 12:32:43 +0100 Subject: [csw-maintainers] Subversion: ld: fatal: library -lsvn_client-1: not found In-Reply-To: <201203080956.q289uWFS029537@dfki.uni-kl.de> References: <201203080956.q289uWFS029537@dfki.uni-kl.de> Message-ID: what would you suggest to report upstream? On Mar 8, 2012 10:56 AM, "Nicolai Schwindt" wrote: > > 2012/3/8 Nicolai Schwindt : > > > [...] > > >> > > >> -SVNLIB ? ? = $(prefix)/lib/svn > > > > > > This contains the needed lib, actually an old version > > > > > >> +SVNLIB ? ? = $(libdir) > > > > > > This does not. > > > > I don't understand - SVNLIB is a private variable in GAR which is used > > to configure some directory settings. If it were set to something > > else, the subversion build would follow. No other packages install > > anything to /opt/csw/lib/svn, do they? > > The variable gets used to configure : > CONFIGURE_ARGS = $(DIRPATHS) --libdir=$(SVNLIB) --libexecdir=$(SVNLIB) > > With SVNLIB=$(prefix)/lib/svn the linker got -L/opt/csw/lib/svn and used > the old > libraries. > > With SVNLIB=$(libdir) the linker gets -L/opt/csw anf fails. > > While staging to DESTIDR you would need : > > -L/home/maciej/src/opencsw/pkg/subversion/trunk/work/solaris10-sparc/pkgroot/opt > /csw/lib/svn > > Doing this on a machine which does not contain an old version of subversion > would fail for both settings of SVNLIB. > > Subversion seems generally broken - the code and the build. > > > Nicolai > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Thu Mar 8 15:37:54 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 8 Mar 2012 15:37:54 +0100 Subject: [csw-maintainers] Problem with GIT repository cloning at github In-Reply-To: <1330739859-sup-1271@pinkfloyd.chass.utoronto.ca> References: <9DE9EA53-F59C-492E-99EA-2A9CB572FE2F@opencsw.org> <1330739859-sup-1271@pinkfloyd.chass.utoronto.ca> Message-ID: Hi Ben, Am 03.03.2012 um 03:01 schrieb Ben Walton: > Excerpts from Dagobert Michelsen's message of Fri Mar 02 16:04:41 -0500 2012: >> I wanted to update a package which pulls a treeish directly from >> github and it doesn't seem to work any more. The mechanism in GAR is >> based on "git archive" something like git archive >> --remote=git://github.com/blair/orca.git The answer from the > > Ok, I cleaned up a bit of the pull code as git now sets up the origin > remote properly in the way we use it. That leaves the problem that > the extract step still fails. > > The VERSION in that recipe is set to a sha1 and GIT_TREEISH is set to > VERSION. That would work if the sha1 existed but it doesn't. I'd set > the version to a 'normal' value and then reference a tag in the repo > from GIT_TREEISH (possibly automatically leveraging VERSION still). I > don't know what that is, but you can see the available tags with: > > cd /home/src/orca.git; git --bare tag There is no usable tag for me, upstream just doesn't do it so I am forced to package the treeish. > It should work once you've updated to a usable treeish. > > Now why the old sha1 disappeared, I don't know. This can only happen > if they removed a published commit (rewrite history; push -f). > > Let me know if you hit more problems with this. Indeed I have. It should work as my treeish is directly visible from the log: > dam at login [login]:/home/src/orca.git > git log | less > commit ef85fa3541a6ffe83b0dacb72254056514a9e05b > Merge: 1f8d89e f831d9b > Author: Blair Zajac > Date: Thu May 5 10:45:11 2011 -0700 > > Merge pull request #1 from dago/master > > Add support for nxge NICs > ... VERSION = ef85fa3541 The extract phase still fails for me. Do you have any idea how I can fix this? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Thu Mar 8 17:18:57 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 8 Mar 2012 16:18:57 +0000 Subject: [csw-maintainers] Subversion: ld: fatal: library -lsvn_client-1: not found In-Reply-To: References: <201203080956.q289uWFS029537@dfki.uni-kl.de> Message-ID: 2012/3/8 rupert THURNER : > what would you suggest to report upstream? Make a small shellscript with "set -x" that downloads the source and tries to build it, exposing the problem. Record the run of your script: mkdir -p ~/public_html your_script.sh 2>&1 | tee ~/public_html/subversion-$(gdate +%Y-%m-%d-%H-%M).log Then attach the log to your bug report. Or link to http://buildfarm.opencsw.org/~rupert/subversion-${timestamp}.log Maciej From bwalton at opencsw.org Thu Mar 8 17:38:23 2012 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 08 Mar 2012 11:38:23 -0500 Subject: [csw-maintainers] Problem with GIT repository cloning at github In-Reply-To: References: <9DE9EA53-F59C-492E-99EA-2A9CB572FE2F@opencsw.org> <1330739859-sup-1271@pinkfloyd.chass.utoronto.ca> Message-ID: <1331224668-sup-7132@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Thu Mar 08 09:37:54 -0500 2012: > There is no usable tag for me, upstream just doesn't do it so I am > forced to package the treeish. Ok, that's workable still. I'll look at this over my lunch break. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Mar 8 18:08:46 2012 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 08 Mar 2012 12:08:46 -0500 Subject: [csw-maintainers] Problem with GIT repository cloning at github In-Reply-To: <1331224668-sup-7132@pinkfloyd.chass.utoronto.ca> References: <9DE9EA53-F59C-492E-99EA-2A9CB572FE2F@opencsw.org> <1330739859-sup-1271@pinkfloyd.chass.utoronto.ca> <1331224668-sup-7132@pinkfloyd.chass.utoronto.ca> Message-ID: <1331226385-sup-4240@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Thu Mar 08 11:38:23 -0500 2012: > > There is no usable tag for me, upstream just doesn't do it so I am > > forced to package the treeish. > > Ok, that's workable still. I'll look at this over my lunch break. I made a small tweak to the extraction code so that it now do (cd $bare_repo; git --bar archive ...) instead of git --bare archive --remote=file:///path/to/bare.git. This seems to work now. When I get a chance, I'll try to investigate why the --remote parameter stopped working in this use case. (I think this feature was always intended for git:// or http:// urls and not for local stuff, so maybe the oversight was corrected and file:// access was never meant to work?) Let me know if it still causes you any grief. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From schwindt at dfki.uni-kl.de Fri Mar 9 11:29:23 2012 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Fri, 09 Mar 2012 11:29:23 +0100 Subject: [csw-maintainers] Subversion: ld: fatal: library -lsvn_client-1: not found In-Reply-To: Your message of "Thu, 08 Mar 2012 12:32:43 +0100." Message-ID: <201203091029.q29ATNav006511@dfki.uni-kl.de> [...] > > what would you suggest to report upstream? I am not sure, "I" would do nothing. As I had 5min of time I toyed around with subversion. As the developers usually only do linux, I took a opensuse 12.1. Configured like this : ./configure --prefix=/opt/svn build and tested : ldd ./subversion/bindings/swig/python/libsvn_swig_py/.libs/libsvn_swig_py-1.so | grep svn libsvn_client-1.so.0 => /root/subversion-1.7.3/subversion/libsvn_client/.libs/libsvn_client-1.so.0 (0x00007fbd3754b000) libsvn_wc-1.so.0 => /root/subversion-1.7.3/subversion/libsvn_wc/.libs/libsvn_wc-1.so.0 (0x00007fbd372bb000) libsvn_ra-1.so.0 => /root/subversion-1.7.3/subversion/libsvn_ra/.libs/libsvn_ra-1.so.0 (0x00007fbd370ad000) libsvn_diff-1.so.0 => /root/subversion-1.7.3/subversion/libsvn_diff/.libs/libsvn_diff-1.so.0 (0x00007fbd36e9c000) libsvn_ra_local-1.so.0 => /root/subversion-1.7.3/subversion/libsvn_ra_local/.libs/libsvn_ra_local-1.so.0 (0x00007fbd36c93000) libsvn_repos-1.so.0 => /root/subversion-1.7.3/subversion/libsvn_repos/.libs/libsvn_repos-1.so.0 (0x00007fbd36a65000) libsvn_fs-1.so.0 => /root/subversion-1.7.3/subversion/libsvn_fs/.libs/libsvn_fs-1.so.0 (0x00007fbd3685d000) libsvn_fs_fs-1.so.0 => /root/subversion-1.7.3/subversion/libsvn_fs_fs/.libs/libsvn_fs_fs-1.so.0 (0x00007fbd36632000) libsvn_fs_base-1.so.0 => /root/subversion-1.7.3/subversion/libsvn_fs_base/.libs/libsvn_fs_base-1.so.0 (0x00007fbd36402000) libsvn_fs_util-1.so.0 => /root/subversion-1.7.3/subversion/libsvn_fs_util/.libs/libsvn_fs_util-1.so.0 (0x00007fbd35e52000) libsvn_ra_svn-1.so.0 => /root/subversion-1.7.3/subversion/libsvn_ra_svn/.libs/libsvn_ra_svn-1.so.0 (0x00007fbd35c39000) libsvn_ra_neon-1.so.0 => /root/subversion-1.7.3/subversion/libsvn_ra_neon/.libs/libsvn_ra_neon-1.so.0 (0x00007fbd357f7000) libsvn_delta-1.so.0 => /root/subversion-1.7.3/subversion/libsvn_delta/.libs/libsvn_delta-1.so.0 (0x00007fbd353be000) libsvn_subr-1.so.0 => /root/subversion-1.7.3/subversion/libsvn_subr/.libs/libsvn_subr-1.so.0 (0x00007fbd3515a000) Staged it , like this export DESTDIR=/opt/test ; gmake install and guess what happens : ldd /opt/test/opt/svn/lib64/libsvn_client-1.so | grep svn libsvn_wc-1.so.0 => /usr/lib64/libsvn_wc-1.so.0 (0x00007ffebf27b000) libsvn_ra-1.so.0 => /usr/lib64/libsvn_ra-1.so.0 (0x00007ffebf06f000) libsvn_ra_local-1.so.0 => /usr/lib64/libsvn_ra_local-1.so.0 (0x00007ffebee66000) libsvn_repos-1.so.0 => /usr/lib64/libsvn_repos-1.so.0 (0x00007ffebec3b000) libsvn_fs-1.so.0 => /usr/lib64/libsvn_fs-1.so.0 (0x00007ffebea32000) libsvn_fs_fs-1.so.0 => /usr/lib64/libsvn_fs_fs-1.so.0 (0x00007ffebe809000) libsvn_fs_base-1.so.0 => /usr/lib64/libsvn_fs_base-1.so.0 (0x00007ffebe5d9000) libsvn_fs_util-1.so.0 => /usr/lib64/libsvn_fs_util-1.so.0 (0x00007ffebe059000) libsvn_ra_svn-1.so.0 => /usr/lib64/libsvn_ra_svn-1.so.0 (0x00007ffebde41000) libsvn_ra_neon-1.so.0 => /usr/lib64/libsvn_ra_neon-1.so.0 (0x00007ffebda00000) libsvn_delta-1.so.0 => /usr/lib64/libsvn_delta-1.so.0 (0x00007ffebd5c9000) libsvn_diff-1.so.0 => /usr/lib64/libsvn_diff-1.so.0 (0x00007ffebd3bd000) libsvn_subr-1.so.0 => /usr/lib64/libsvn_subr-1.so.0 (0x00007ffebd0fc000) Well, skipping -R in the linker call and using ldconfig makes life easy. So who to blaim ? libtool ? Good luck with that . Maybe one can work out a workaround for the relink_command, there you find @inst_prefix_dir at . Simply using -R/opt/csw/lib/svn seems not be an adequate solution. But at least a quick hack .) Which are used way to often ,( Nicolai From Joerg.Schilling at fokus.fraunhofer.de Fri Mar 9 12:59:29 2012 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Fri, 09 Mar 2012 12:59:29 +0100 Subject: [csw-maintainers] Autoconf 2.13 In-Reply-To: References: Message-ID: <4f59f0a1.rUQSDTUOTaJtwcGa%Joerg.Schilling@fokus.fraunhofer.de> Maciej (Matchek) Blizi??ski wrote: > One of packages I want to build, requires autoconf-2.13 (1999), and > nothing later. I built a package with autoconf-2.13: > > http://buildfarm.opencsw.org/pkgdb/srv4/c34a5709eefd009df031358dbdb38db9/ > > The package works well for my purposes (coexists peacefully with the > main autoconf package). I would like to release autoconf-2.13 to > unstable, what do people think about the idea and file layout, any > thoughts or objections? autoconf 2.13 is the last correctly working autoconf. This is the release where the schily autoconf was derived from. So why not have a package? 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 bwalton at opencsw.org Fri Mar 9 15:14:13 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 09 Mar 2012 09:14:13 -0500 Subject: [csw-maintainers] Autoconf 2.13 In-Reply-To: <4f59f0a1.rUQSDTUOTaJtwcGa%Joerg.Schilling@fokus.fraunhofer.de> References: <4f59f0a1.rUQSDTUOTaJtwcGa%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <1331302350-sup-1709@pinkfloyd.chass.utoronto.ca> Excerpts from Joerg.Schilling's message of Fri Mar 09 06:59:29 -0500 2012: Hi J?rg, > autoconf 2.13 is the last correctly working autoconf. This is the > release where the schily autoconf was derived from. So why not have > a package? For my own interest, I'd love to hear your thoughts on this in terms of what you consider broken after v2.13. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From Joerg.Schilling at fokus.fraunhofer.de Fri Mar 9 16:22:49 2012 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Fri, 09 Mar 2012 16:22:49 +0100 Subject: [csw-maintainers] Autoconf 2.13 In-Reply-To: <1331302350-sup-1709@pinkfloyd.chass.utoronto.ca> References: <4f59f0a1.rUQSDTUOTaJtwcGa%Joerg.Schilling@fokus.fraunhofer.de> <1331302350-sup-1709@pinkfloyd.chass.utoronto.ca> Message-ID: <4f5a2049.az/Osu6Zejg2IEiM%Joerg.Schilling@fokus.fraunhofer.de> Ben Walton wrote: > Excerpts from Joerg.Schilling's message of Fri Mar 09 06:59:29 -0500 2012: > > Hi J?rg, > > > autoconf 2.13 is the last correctly working autoconf. This is the > > release where the schily autoconf was derived from. So why not have > > a package? > > For my own interest, I'd love to hear your thoughts on this in terms > of what you consider broken after v2.13. A configure run on SunOS-4.x and other older systems for a medium sized configurations typpically takes 4 hours. The code for config.guess has been completely reordered so that it is not possible to tell whether thare are bad changes inside (note that I added and forwared many patches to support various additional platforms). In general, the created shell codes is no longer portable and seems to at least partially depend on bash bugs. BTW: schily autoconf fully supports cross compilation (since aprox. a year) and GNU autoconf still doesn't. 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 maciej at opencsw.org Fri Mar 9 23:30:58 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 9 Mar 2012 22:30:58 +0000 Subject: [csw-maintainers] C++ libraries built with GCC In-Reply-To: References: <1330278296-sup-7303@pinkfloyd.chass.utoronto.ca> <20120226191929.GA8597@quince.home.blizinski.pl> <1330440134-sup-9283@pinkfloyd.chass.utoronto.ca> Message-ID: 2012/3/4 Maciej (Matchek) Blizi?ski > > 2012/2/28 Ben Walton : > >> +1 for gxx > > > > That works. > > Cool. What about package names. Is CSWlibfoo1-gxx a sane convention? > More broadly, if is the convention with > CSW- a workable general idea? Alright, since there were no objections, I've committed the change to checkpkg. http://sourceforge.net/apps/trac/gar/changeset/17348 Maciej From maciej at opencsw.org Fri Mar 9 23:47:58 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 9 Mar 2012 22:47:58 +0000 Subject: [csw-maintainers] Boost In-Reply-To: References: <45905183-AC70-46BF-8D64-DAAB6D74398E@opencsw.org> <05DE8C9C-65FD-44F3-A663-8FECDADC8626@opencsw.org> Message-ID: Update: I've build both 32-bit and 64-bit libraries and put the packages into experimental. http://buildfarm.opencsw.org/experimental.html#boost Feedback is welcome! From maciej at opencsw.org Fri Mar 9 23:50:02 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 9 Mar 2012 22:50:02 +0000 Subject: [csw-maintainers] Python pyconfig.h headers In-Reply-To: <1330792463-sup-5879@pinkfloyd.chass.utoronto.ca> References: <1330779348-sup-69@pinkfloyd.chass.utoronto.ca> <1330792463-sup-5879@pinkfloyd.chass.utoronto.ca> Message-ID: 2012/3/3 Ben Walton : >> It's not only about building cleanly, but also about effort spent >> for an antique release of the operating system when that effort can >> be used for more useful things. > > Agreed. ?In this case, if effort to modify the build recipe is > required to make this clean for 9 and 10 it's not likely worth it...at > least I wouldn't invest the time. I suppose that we could simply do this: PACKAGING_PLATFORMS = solaris9-sparc solaris9-i386 PACKAGING_PLATFORMS += solaris10-sparc solaris10-i386 This way, each platforms gets matching header files, and it requires almost no work on my part. From william at wbonnet.net Sat Mar 10 22:36:41 2012 From: william at wbonnet.net (William Bonnet) Date: Sat, 10 Mar 2012 22:36:41 +0100 Subject: [csw-maintainers] Updating photos for the camps In-Reply-To: <4F5BC856.6010807@opencsw.org> References: <4F5BC856.6010807@opencsw.org> Message-ID: <4F5BC969.2020504@wbonnet.net> Hi > This page says that only William has access to Flickr, is this still > true? It should not, the board should have the password. I resend it. Should i send it to someone else ? cheers W. -- William http://www.wbonnet.net http://www.opencsw.org Community SoftWare for Solaris From bwalton at opencsw.org Sun Mar 11 15:16:04 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 11 Mar 2012 10:16:04 -0400 Subject: [csw-maintainers] [board] Fwd: OpenCSW account on flickr In-Reply-To: References: <4A9454B1.90401@wbonnet.net> Message-ID: <1331475321-sup-8255@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Fri Mar 09 04:57:53 -0500 2012: > Ben, Maciej: Would you mind uploading your pictures from the camps? Done. I started a set for the Dublin camp. It was fun to look back through the photos too! Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From ja at opencsw.org Sun Mar 11 18:46:54 2012 From: ja at opencsw.org (Juergen Arndt) Date: Sun, 11 Mar 2012 18:46:54 +0100 Subject: [csw-maintainers] Renaming CSWnagiosp Message-ID: Hi all, the package for the nagios plugins is called CSWnagiosp and the catalog name is nagios_plugins. Is it ok to rename it to CSWnagios-plugins and to keep the catalog name? In this case, would the following lines be correct? OBSOLETED_BY_CSWnagios-plugins = CSWnagiosp #SPKG_CATALOG_NAME_CSWnagiosp = nagios_plugins_stub <-- not needed, because the the catalog name should not change Thanks! Juergen -- Juergen Arndt From maciej at opencsw.org Sun Mar 11 18:58:10 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 11 Mar 2012 17:58:10 +0000 Subject: [csw-maintainers] Solaris Studio vs GCC Message-ID: I recently spent some time building a couple of libraries with GCC, in the /opt/csw/gxx prefix. I was surprised how easy that was. Yes, there were some issues, but most of them because of stupid hardcoded stuff of the type of "you're on Solaris so you must be compiling with something else", and removing Solaris-specific #define bits made problems go away. I managed to build Boost 1.49.0 with GCC, but not with Solaris Studio - I got about a screenful of templating errors. When interacting with upstreams, using Studio often gets in the way. I often get responses that if I'm building with Studio, I'm on my own as far building is concerned. Overall, using it seems to add workload rather than removing it. If we plan on keeping on being standardized on Solaris Studio, we should have some kind of rationale written up. If it is about performance, we should have some numbers put out to show how big the benefit is. If it is about helpful error messages, we should have an example or two out. Whatever the reason is, some kind of example should be put up on one of our web sites. Thoughts? Maciej From maciej at opencsw.org Sun Mar 11 19:27:15 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 11 Mar 2012 18:27:15 +0000 Subject: [csw-maintainers] Renaming CSWnagiosp In-Reply-To: References: Message-ID: 2012/3/11 Juergen Arndt : > the package for the nagios plugins is called CSWnagiosp and the catalog name is nagios_plugins. Is it ok to rename it to CSWnagios-plugins and to keep the catalog name? > > In this case, would the following lines be correct? > > OBSOLETED_BY_CSWnagios-plugins ?= CSWnagiosp > #SPKG_CATALOG_NAME_CSWnagiosp ? = nagios_plugins_stub ?<-- not needed, because the the catalog name should not change Catalognames have to be unique in a single catalog, I think you do need to rename the old package to nagios_plugins_stub. Unless you declare CSWnagios-plugins incompatible with CSWnagiosp, which will cause it to be uninstalled during upgrade, and you'll remove CSWnagiosp from the catalog. From bwalton at opencsw.org Sun Mar 11 20:31:54 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 11 Mar 2012 15:31:54 -0400 Subject: [csw-maintainers] Renaming CSWnagiosp In-Reply-To: References: Message-ID: <1331494270-sup-5209@pinkfloyd.chass.utoronto.ca> Excerpts from Juergen Arndt's message of Sun Mar 11 13:46:54 -0400 2012: Hi Juergen, > the package for the nagios plugins is called CSWnagiosp and the > catalog name is nagios_plugins. Is it ok to rename it to > CSWnagios-plugins and to keep the catalog name? That's a much nicer name for the pacakge. > OBSOLETED_BY_CSWnagios-plugins = CSWnagiosp > #SPKG_CATALOG_NAME_CSWnagiosp = nagios_plugins_stub <-- not > needed, because the the catalog name should not change You'll definitely want to use SPKG_CATALOG_NAME_CSWnagiosp here as the stub name must be old catalog name with _stub appended. The db update code uses this feature and it also lines up old and new more closely. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Sun Mar 11 20:34:29 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 11 Mar 2012 20:34:29 +0100 Subject: [csw-maintainers] Renaming CSWnagiosp In-Reply-To: References: Message-ID: Hi J?rgen, Am 11.03.2012 um 18:46 schrieb Juergen Arndt: > the package for the nagios plugins is called CSWnagiosp and the catalog name is nagios_plugins. Is it ok to rename it to CSWnagios-plugins and to keep the catalog name? > > In this case, would the following lines be correct? > > OBSOLETED_BY_CSWnagios-plugins = CSWnagiosp > #SPKG_CATALOG_NAME_CSWnagiosp = nagios_plugins_stub <-- not needed, because the the catalog name should not change As Macien and Ben alrady ourlined you would definitely need CATALOGNAME_CSWnagiosp = nagios_plugins_stub This is needed because the obsoleted package name is different from its catalog name. 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 wilbury at opencsw.org Sun Mar 11 23:08:19 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Sun, 11 Mar 2012 23:08:19 +0100 Subject: [csw-maintainers] build recipe for Courier-IMAP Message-ID: <4F5D2253.6080101@opencsw.org> Dear fellow maintainers, Please, do you have (somewhere) saved build recipe for Courier IMAP? It is in catalog but I can't seem to find it in SVN. Thanks. -- Juraj Lutter From wilbury at opencsw.org Sun Mar 11 23:16:55 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Sun, 11 Mar 2012 23:16:55 +0100 Subject: [csw-maintainers] build recipe for Courier-IMAP In-Reply-To: <4F5D2253.6080101@opencsw.org> References: <4F5D2253.6080101@opencsw.org> Message-ID: <4F5D2457.7060808@opencsw.org> On 03/11/2012 11:08 PM, Juraj Lutter wrote: > Dear fellow maintainers, > > Please, do you have (somewhere) saved build recipe for Courier IMAP? It > is in catalog but I can't seem to find it in SVN. To reply to myself: Yes, I have scripts from Alex Moore, he sent them to me on 30. of April, 2007. > > Thanks. > -- Juraj Lutter From bwalton at opencsw.org Sun Mar 11 23:48:05 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 11 Mar 2012 18:48:05 -0400 Subject: [csw-maintainers] Solaris Studio vs GCC In-Reply-To: References: Message-ID: <1331505713-sup-655@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Sun Mar 11 13:58:10 -0400 2012: > If we plan on keeping on being standardized on Solaris Studio, we > should have some kind of rationale written up. If it is about > performance, we should have some numbers put out to show how big the > benefit is. If it is about helpful error messages, we should have an > example or two out. Whatever the reason is, some kind of example > should be put up on one of our web sites. There is a really big win we'd get by standardizing on gcc instead of studio. Our .pc files, binaries like mysql_config and other miscellaneous things that embed compiler flags (rbconfig.rb, etc) would be useful to a wider audience in the user community. It would also benefit us when building things that only compile with gcc but rely on build flags supplied by some of the aforementioned things. I understand that performance of the binaries generated by studio used to be superior, but I don't know if that's still the case. Aside from this (possible) win for studio, what are some of the other reasons we've traditionally preferred it to gcc? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bonivart at opencsw.org Mon Mar 12 00:21:30 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 12 Mar 2012 00:21:30 +0100 Subject: [csw-maintainers] Solaris Studio vs GCC In-Reply-To: <1331505713-sup-655@pinkfloyd.chass.utoronto.ca> References: <1331505713-sup-655@pinkfloyd.chass.utoronto.ca> Message-ID: On Sun, Mar 11, 2012 at 11:48 PM, Ben Walton wrote: > I understand that performance of the binaries generated by studio used > to be superior, but I don't know if that's still the case. ?Aside from > this (possible) win for studio, what are some of the other reasons > we've traditionally preferred it to gcc? I'd like to switch the _default_ compiler only. :) Today quite some packages are built with gcc anyway due to being too hard to build with Studio. If someone feels that Studio will give them faster binaries they can still use it. I would like to see some actual numbers though for the sake of the discussion. James Lee used to provide some back in the day. /peter From maciej at opencsw.org Mon Mar 12 08:58:20 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 12 Mar 2012 07:58:20 +0000 Subject: [csw-maintainers] C++ libraries built with GCC In-Reply-To: References: <1330278296-sup-7303@pinkfloyd.chass.utoronto.ca> <20120226191929.GA8597@quince.home.blizinski.pl> <1330440134-sup-9283@pinkfloyd.chass.utoronto.ca> Message-ID: I'm about to submit a batch of C++ libraries build with GCC, into the /opt/csw/gxx prefix: pcre (including pcrecpp) boost snappy I also built libjs (spidermonkey 1.7.0) into /opt/csw/gxx, to discover that it ignored the CC and CXX setting and built with /usr/bin/cc which is a symlink to Solaris Studio, and turned out to be written in C rather than C++. Okay, I'll go with it and rebuild it into /opt/csw. Maciej From grzemba at contac-dt.de Mon Mar 12 09:34:49 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Mon, 12 Mar 2012 09:34:49 +0100 Subject: [csw-maintainers] Fwd: CSW outstanding bugs py-gobject Message-ID: <7430aff17bf0.4f5dc339@contac-dt.de> This is a bug for a old version. Unfortunately the bug record contains no version information, at least I haven't found any. We have released a new version last week. The bug contains also no information for reproduce so we can't check quickly is the problem solved or not in the new version. Should we keep the bug open or can we close this? -- Carsten -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: Bug Reminder Subject: CSW outstanding bugs Date: Sun, 11 Mar 2012 04:47:21 +0100 (CET) Size: 2110 URL: From dam at opencsw.org Mon Mar 12 09:37:30 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 12 Mar 2012 09:37:30 +0100 Subject: [csw-maintainers] Fwd: CSW outstanding bugs py-gobject In-Reply-To: <7430aff17bf0.4f5dc339@contac-dt.de> References: <7430aff17bf0.4f5dc339@contac-dt.de> Message-ID: <75CD266D-7940-4BE4-9533-9ECE55060A77@opencsw.org> Hi Carsten, Am 12.03.2012 um 09:34 schrieb Carsten Grzemba: > This is a bug for a old version. Unfortunately the bug record contains no version information, at least I haven't found any. > We have released a new version last week. The bug contains also no information for reproduce so we can't check quickly is the problem solved or not in the new version. The bug is about mixed spaces and tabs. > Should we keep the bug open or can we close this? If you install the new package and there are no warning during pycompile I would 1. assign the bug to you 2. close the bug as "fixed" with a note about the revision, like "This has been fixed in 3.14,REV=2012.01.01 and released to unstable/" Best regards -- Dago > > -- > Carsten > Von: Bug Reminder > Datum: 11. M?rz 2012 04:47:21 MEZ > An: Carsten Grzemba > Betreff: CSW outstanding bugs > > > Here is a summary of your open CSW Mantis issues. If you are not the > maintainer of these projects please inform . > > These reports have severity "minor" or below: > > py_gobject_dev : pygobject install issues with cswpycompile > http://www.opencsw.org/bugtrack/view.php?id=3850 > > > > > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From grzemba at contac-dt.de Mon Mar 12 10:00:23 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Mon, 12 Mar 2012 10:00:23 +0100 Subject: [csw-maintainers] release pygtk 2.17.0 Message-ID: <7490b80167d2.4f5dc937@contac-dt.de> Hi, I have build a new version py-gtk 2.17.0, the old was 2.12.1 and not properly packaged. With pygtk can GUI designed with glade and implemented in python. I have do some tests and I am happy with the results so that I recommend to push this package to unstable. For that the packages py_gobject (2.21.1), py_cairo (1.8.10) was also updated and already pushed to unstable. Comments are welcome. -- Carsten -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Mon Mar 12 10:46:58 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 12 Mar 2012 09:46:58 +0000 Subject: [csw-maintainers] release pygtk 2.17.0 In-Reply-To: <7490b80167d2.4f5dc937@contac-dt.de> References: <7490b80167d2.4f5dc937@contac-dt.de> Message-ID: 2012/3/12 Carsten Grzemba : > I have build a new version py-gtk 2.17.0, the old was 2.12.1 and not > properly packaged. > With pygtk can GUI designed with glade and implemented in python. > I have do some tests and I am happy with the results so that I recommend to > push this package to unstable. Looks good. Please do. One thing to think about is whether this update might break other existing packages. If not, feel free to push. If you know of how it could break something (e.g. through a backward-incompatibility of a library), you need to think about a plan how to make it go smoothly. Looking at http://www.opencsw.org/packages/pygtk/ I see gnome and skencil as dependencies. You can see if skencil still works. Gnome is a metapackage, so there might be something that uses pygtk and is pulled in by CSWgnome, but I don't know about specific applications of that kind. Maybe the gnome_python package would suffer. I was built in 2004, and who knows if it even works any more. Use your best judgement. > For that the packages py_gobject (2.21.1), py_cairo (1.8.10) was also > updated and already pushed to unstable. > Comments are welcome. Good job! From dam at opencsw.org Mon Mar 12 11:07:20 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 12 Mar 2012 11:07:20 +0100 Subject: [csw-maintainers] Updating photos for the camps In-Reply-To: <4F5BC969.2020504@wbonnet.net> References: <4F5BC856.6010807@opencsw.org> <4F5BC969.2020504@wbonnet.net> Message-ID: <3A6F0427-3901-4807-91AC-AC6E8C8EBA50@opencsw.org> Hi William, Am 10.03.2012 um 22:36 schrieb William Bonnet: >> This page says that only William has access to Flickr, is this still >> true? > > It should not, the board should have the password. I resend it. Should i > send it to someone else ? Looks all good now, could you please upload the pictures of the Camp is Paris? 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 Mar 12 15:47:23 2012 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 12 Mar 2012 10:47:23 -0400 Subject: [csw-maintainers] Solaris Studio vs GCC In-Reply-To: References: <1331505713-sup-655@pinkfloyd.chass.utoronto.ca> Message-ID: <1331563601-sup-7922@pinkfloyd.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Sun Mar 11 19:21:30 -0400 2012: > On Sun, Mar 11, 2012 at 11:48 PM, Ben Walton wrote: > > I understand that performance of the binaries generated by studio > > used to be superior, but I don't know if that's still the > > case. ?Aside from this (possible) win for studio, what are some of > > the other reasons we've traditionally preferred it to gcc? > > I'd like to switch the _default_ compiler only. :) Yes, this is important. It was implicit in my mind, but it's good to be explicit. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From rupert at opencsw.org Mon Mar 12 16:41:22 2012 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 12 Mar 2012 16:41:22 +0100 Subject: [csw-maintainers] Fwd: Re: svn ingores DESTDIR, was: link error with 1.7.3 In-Reply-To: <20120312085129.GG14044@ted.stsp.name> References: <6a4daaf9-78ae-4105-b10b-d9dcb76c5c1f@gi10g2000vbb.googlegroups.com> <20120312085129.GG14044@ted.stsp.name> Message-ID: Fyi ---------- Forwarded message ---------- From: "Stefan Sperling" Date: Mar 12, 2012 9:51 AM Subject: Re: svn ingores DESTDIR, was: link error with 1.7.3 To: "rupert.thurner" Cc: , On Sun, Mar 11, 2012 at 09:09:20PM -0700, rupert.thurner wrote: > nikolai did a quick test run, allow me to copy his comment. what > should we do about this "location resistence"? > > Configured like this : > ./configure --prefix=/opt/svn > > build and tested : > > ldd ./subversion/bindings/swig/python/libsvn_swig_py/.libs/ > libsvn_swig_py-1.so | grep svn > libsvn_client-1.so.0 => /root/subversion-1.7.3/subversion/ > libsvn_client/.libs/libsvn_client-1.so.0 (0x00007fbd3754b000) > libsvn_wc-1.so.0 => /root/subversion-1.7.3/subversion/ > libsvn_wc/.libs/libsvn_wc-1.so.0 (0x00007fbd372bb000) > libsvn_ra-1.so.0 => /root/subversion-1.7.3/subversion/ > libsvn_ra/.libs/libsvn_ra-1.so.0 (0x00007fbd370ad000) > libsvn_diff-1.so.0 => /root/subversion-1.7.3/subversion/ > libsvn_diff/.libs/libsvn_diff-1.so.0 (0x00007fbd36e9c000) > libsvn_ra_local-1.so.0 => /root/subversion-1.7.3/subversion/ > libsvn_ra_local/.libs/libsvn_ra_local-1.so.0 (0x00007fbd36c93000) > libsvn_repos-1.so.0 => /root/subversion-1.7.3/subversion/ > libsvn_repos/.libs/libsvn_repos-1.so.0 (0x00007fbd36a65000) > libsvn_fs-1.so.0 => /root/subversion-1.7.3/subversion/ > libsvn_fs/.libs/libsvn_fs-1.so.0 (0x00007fbd3685d000) > libsvn_fs_fs-1.so.0 => /root/subversion-1.7.3/subversion/ > libsvn_fs_fs/.libs/libsvn_fs_fs-1.so.0 (0x00007fbd36632000) > libsvn_fs_base-1.so.0 => /root/subversion-1.7.3/subversion/ > libsvn_fs_base/.libs/libsvn_fs_base-1.so.0 (0x00007fbd36402000) > libsvn_fs_util-1.so.0 => /root/subversion-1.7.3/subversion/ > libsvn_fs_util/.libs/libsvn_fs_util-1.so.0 (0x00007fbd35e52000) > libsvn_ra_svn-1.so.0 => /root/subversion-1.7.3/subversion/ > libsvn_ra_svn/.libs/libsvn_ra_svn-1.so.0 (0x00007fbd35c39000) > libsvn_ra_neon-1.so.0 => /root/subversion-1.7.3/subversion/ > libsvn_ra_neon/.libs/libsvn_ra_neon-1.so.0 (0x00007fbd357f7000) > libsvn_delta-1.so.0 => /root/subversion-1.7.3/subversion/ > libsvn_delta/.libs/libsvn_delta-1.so.0 (0x00007fbd353be000) > libsvn_subr-1.so.0 => /root/subversion-1.7.3/subversion/ > libsvn_subr/.libs/libsvn_subr-1.so.0 (0x00007fbd3515a000) > > Staged it , like this > export DESTDIR=/opt/test ; gmake install > and guess what happens : > > ldd /opt/test/opt/svn/lib64/libsvn_client-1.so | grep svn > libsvn_wc-1.so.0 => /usr/lib64/libsvn_wc-1.so.0 > (0x00007ffebf27b000) > libsvn_ra-1.so.0 => /usr/lib64/libsvn_ra-1.so.0 > (0x00007ffebf06f000) > libsvn_ra_local-1.so.0 => /usr/lib64/libsvn_ra_local-1.so.0 > (0x00007ffebee66000) > libsvn_repos-1.so.0 => /usr/lib64/libsvn_repos-1.so.0 > (0x00007ffebec3b000) > libsvn_fs-1.so.0 => /usr/lib64/libsvn_fs-1.so.0 > (0x00007ffebea32000) > libsvn_fs_fs-1.so.0 => /usr/lib64/libsvn_fs_fs-1.so.0 > (0x00007ffebe809000) > libsvn_fs_base-1.so.0 => /usr/lib64/libsvn_fs_base-1.so.0 > (0x00007ffebe5d9000) > libsvn_fs_util-1.so.0 => /usr/lib64/libsvn_fs_util-1.so.0 > (0x00007ffebe059000) > libsvn_ra_svn-1.so.0 => /usr/lib64/libsvn_ra_svn-1.so.0 > (0x00007ffebde41000) > libsvn_ra_neon-1.so.0 => /usr/lib64/libsvn_ra_neon-1.so.0 > (0x00007ffebda00000) > libsvn_delta-1.so.0 => /usr/lib64/libsvn_delta-1.so.0 > (0x00007ffebd5c9000) > libsvn_diff-1.so.0 => /usr/lib64/libsvn_diff-1.so.0 > (0x00007ffebd3bd000) > libsvn_subr-1.so.0 => /usr/lib64/libsvn_subr-1.so.0 > (0x00007ffebd0fc000) > > > Well, skipping -R in the linker call and using ldconfig makes life > easy. > > > So who to blaim ? libtool ? Good luck with that . Well,is libtool is constructing a linker command that which contains -L /usr/lib64 which causes the linker to pick up svn libraries that are already installed there. You should uninstall previously installed subversion libraries before the build. You could also try to force a shared library version number increment. Both sets of libraries have number 1 so are considered equal by the linker. I think I brought up the question about whether we should do this before. But every downstream packager handles this differently so there is no point in us doing this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Mon Mar 12 17:17:31 2012 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 12 Mar 2012 12:17:31 -0400 Subject: [csw-maintainers] Fwd: Re: svn ingores DESTDIR, was: link error with 1.7.3 In-Reply-To: References: <6a4daaf9-78ae-4105-b10b-d9dcb76c5c1f@gi10g2000vbb.googlegroups.com> <20120312085129.GG14044@ted.stsp.name> Message-ID: <1331568941-sup-4441@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Mon Mar 12 11:41:22 -0400 2012: Hi Rupert, After the build has completed, but before the installation step, is the string usr/lib64 visible anywhere in the build tree? In order to work around it, we'll need to know when it leaks in and from where. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From schwindt at dfki.uni-kl.de Mon Mar 12 18:03:03 2012 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Mon, 12 Mar 2012 18:03:03 +0100 Subject: [csw-maintainers] Fwd: Re: svn ingores DESTDIR, was: link error with 1.7.3 In-Reply-To: Your message of "Mon, 12 Mar 2012 12:17:31 -0400." <1331568941-sup-4441@pinkfloyd.chass.utoronto.ca> Message-ID: <201203121703.q2CH33kl019662@dfki.uni-kl.de> > Excerpts from rupert THURNER's message of Mon Mar 12 11:41:22 -0400 2012: > > Hi Rupert, > > After the build has completed, but before the installation step, is > the string usr/lib64 visible anywhere in the build tree? > > In order to work around it, we'll need to know when it leaks in and > from where. To clarifiy this, I did a test on linux ( as these developers only use linux ). That's why there is a /usr/lib64 involved. This does not concern the solaris build - it was just to show that this problem also exists on linux. Nicolai From bwalton at opencsw.org Mon Mar 12 18:09:27 2012 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 12 Mar 2012 13:09:27 -0400 Subject: [csw-maintainers] Fwd: Re: svn ingores DESTDIR, was: link error with 1.7.3 In-Reply-To: <201203121703.q2CH33kl019662@dfki.uni-kl.de> References: <201203121703.q2CH33kl019662@dfki.uni-kl.de> Message-ID: <1331572124-sup-5396@pinkfloyd.chass.utoronto.ca> Excerpts from Nicolai Schwindt's message of Mon Mar 12 13:03:03 -0400 2012: Hi Nicolai, > To clarifiy this, I did a test on linux ( as these developers only > use linux ). That's why there is a /usr/lib64 involved. This does > not concern the solaris build - it was just to show that this > problem also exists on linux. Ah thanks. You did say that before, I'd just forgotten. Sorry for confusing the topic. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Mon Mar 12 19:01:41 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 12 Mar 2012 18:01:41 +0000 Subject: [csw-maintainers] SMF integration for package that misses a startup script Message-ID: I'm working on packaging a daemon for which there is no startup script available upstream. Which way should I go: - write my own from scratch - steal and port a script from another distribution - use some kind of a gold standard template if we have one around - write my own SMF manifest in XML Any recommendations? Maciej From bwalton at opencsw.org Mon Mar 12 19:16:49 2012 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 12 Mar 2012 14:16:49 -0400 Subject: [csw-maintainers] SMF integration for package that misses a startup script In-Reply-To: References: Message-ID: <1331576151-sup-1518@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Mon Mar 12 14:01:41 -0400 2012: Hi Maciej, > - steal and port a script from another distribution This is how I'd approach it. It'll still need some tweaking, but you can avoid making some of the same mistakes that other distros have already made by leveraging their work. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bonivart at opencsw.org Mon Mar 12 19:35:32 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 12 Mar 2012 19:35:32 +0100 Subject: [csw-maintainers] SMF integration for package that misses a startup script In-Reply-To: References: Message-ID: 2012/3/12 Maciej (Matchek) Blizi?ski : > I'm working on packaging a daemon for which there is no startup script > available upstream. Which way should I go: > > - write my own from scratch > - steal and port a script from another distribution Any of those above or take a look at others, e.g. http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/bind/trunk/files/CSWbind.cswnamed. > - use some kind of a gold standard template if we have one around Don't think one exists. > - write my own SMF manifest in XML If you do need a custom manifest it doesn't cancel out your need for a startup (method) script, unless it's super simple. SMF = manifest (XML) + method (script). From dam at opencsw.org Mon Mar 12 19:50:30 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 12 Mar 2012 19:50:30 +0100 Subject: [csw-maintainers] SMF integration for package that misses a startup script In-Reply-To: References: Message-ID: Hi Maciej, Am 12.03.2012 um 19:01 schrieb Maciej (Matchek) Blizi?ski: > I'm working on packaging a daemon for which there is no startup script > available upstream. Which way should I go: > > - write my own from scratch > - steal and port a script from another distribution > - use some kind of a gold standard template if we have one around > - write my own SMF manifest in XML > > Any recommendations? Contrary to Ben and Peter I would go with a custom manifest only if possible. I suggest using "manifold" which generates xml manifests on-the-fly. As we are more and more approaching Solaris 10 only / 11 it may be useful to integrate automatic SMF generation without having a boilerplate RC script. 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 rupert at opencsw.org Mon Mar 12 23:23:46 2012 From: rupert at opencsw.org (rupert THURNER) Date: Mon, 12 Mar 2012 23:23:46 +0100 Subject: [csw-maintainers] Fwd: Re: svn ingores DESTDIR, was: link error with 1.7.3 In-Reply-To: <1331572124-sup-5396@pinkfloyd.chass.utoronto.ca> References: <201203121703.q2CH33kl019662@dfki.uni-kl.de> <1331572124-sup-5396@pinkfloyd.chass.utoronto.ca> Message-ID: Our problems can t be caused by an already installed subversion? Am 12.03.2012 18:09 schrieb "Ben Walton" : > Excerpts from Nicolai Schwindt's message of Mon Mar 12 13:03:03 -0400 2012: > > Hi Nicolai, > > > To clarifiy this, I did a test on linux ( as these developers only > > use linux ). That's why there is a /usr/lib64 involved. This does > > not concern the solaris build - it was just to show that this > > problem also exists on linux. > > Ah thanks. You did say that before, I'd just forgotten. > > Sorry for confusing the topic. > > Thanks > -Ben > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Mon Mar 12 23:27:32 2012 From: maciej at opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?=) Date: Mon, 12 Mar 2012 22:27:32 +0000 Subject: [csw-maintainers] SMF integration for package that misses a startup script In-Reply-To: References: Message-ID: <20120312222732.GB4452@quince.home.blizinski.pl> Dagobert Michelsen wrote: > Hi Maciej, > > Am 12.03.2012 um 19:01 schrieb Maciej (Matchek) Blizi?ski: > > I'm working on packaging a daemon for which there is no startup script > > available upstream. Which way should I go: > > > > - write my own from scratch > > - steal and port a script from another distribution > > - use some kind of a gold standard template if we have one around > > - write my own SMF manifest in XML > > > > Any recommendations? > > Contrary to Ben and Peter I would go with a custom manifest only if possible. > I suggest using "manifold" which generates xml manifests on-the-fly. As we are > more and more approaching Solaris 10 only / 11 it may be useful to integrate > automatic SMF generation without having a boilerplate RC script. I tried out manifold, it did produce something that was later validated by svccfg. It looks easy enough to get started. SMF does abstract out a couple of typically annoying things, such as tracking pids or process groups. I'll give it a go. From bwalton at opencsw.org Tue Mar 13 01:48:36 2012 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 12 Mar 2012 20:48:36 -0400 Subject: [csw-maintainers] whole catalog feeds Message-ID: <1331599643-sup-3316@pinkfloyd.chass.utoronto.ca> Hi All, The whole catalog atom feeds are just about ready. I'd like to solicit feedback for formatting and which info you'd like to see included before I open it up. Here is the current output: http://www.opencsw.org/catalogfeeds/feed.mirror.opencsw.org.opencsw.unstable.atom Let me know. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Tue Mar 13 15:19:05 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 13 Mar 2012 15:19:05 +0100 Subject: [csw-maintainers] whole catalog feeds In-Reply-To: <1331599643-sup-3316@pinkfloyd.chass.utoronto.ca> References: <1331599643-sup-3316@pinkfloyd.chass.utoronto.ca> Message-ID: <921CBC4F-28EE-4499-8C41-ED7CA10E5C3B@opencsw.org> Hi Ben, Am 13.03.2012 um 01:48 schrieb Ben Walton: > The whole catalog atom feeds are just about ready. I'd like to > solicit feedback for formatting and which info you'd like to see > included before I open it up. > > Here is the current output: > http://www.opencsw.org/catalogfeeds/feed.mirror.opencsw.org.opencsw.unstable.atom It looks like this rendered: > Updated sudo_ldap 1.8.3p2,REV=2012.02.14 > Dagobert Michelsen > Heute, 1:38 > Updated package sudo_ldap 1.8.3p2,REV=2012.02.14. > > Catalog info: SunOS5.11: sparc,i386, SunOS5.9: sparc,i386, SunOS5.10: sparc,i386 Collapsing this last line is the crucial thing: I suggest collapsing it to Solaris 9+ Sparc/i386 to indicate it has been added to the catalogs for Solaris 9, 10 and 11 both ISAs. A package only for Solaris 9 would be Solaris 9 Sparc/i386 followed by a Solaris 10 only package Solaris 10 Sparc/i386 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 Mar 14 09:14:38 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 14 Mar 2012 08:14:38 +0000 Subject: [csw-maintainers] The dublin release: remaining tasks In-Reply-To: <1331128177-sup-7394@pinkfloyd.chass.utoronto.ca> References: <20111013090121.GA15669@bender.opencsw.org> <20111013101714.GB15669@bender.opencsw.org> <1328462253-sup-3570@pinkfloyd.chass.utoronto.ca> <1328921545-sup-4762@pinkfloyd.chass.utoronto.ca> <1331082289-sup-2275@pinkfloyd.chass.utoronto.ca> <46459F52-E56A-4447-80CB-E1D7E96C6254@opencsw.org> <1331128177-sup-7394@pinkfloyd.chass.utoronto.ca> Message-ID: Please let me know if you're submitting fixes to unstable. For example, there was a recent fix in sudo, I also fixed a problem with libmagic1, and I also pushed postfix rebuilt against bdb48 (so that it matches with SASL). From jh at opencsw.org Wed Mar 14 09:58:58 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Wed, 14 Mar 2012 09:58:58 +0100 Subject: [csw-maintainers] libsigc++ and studio vs. gcc In-Reply-To: References: <20111013101714.GB15669@bender.opencsw.org> <1328462253-sup-3570@pinkfloyd.chass.utoronto.ca> <1328921545-sup-4762@pinkfloyd.chass.utoronto.ca> <1331082289-sup-2275@pinkfloyd.chass.utoronto.ca> <46459F52-E56A-4447-80CB-E1D7E96C6254@opencsw.org> <1331128177-sup-7394@pinkfloyd.chass.utoronto.ca> Message-ID: <4F605DD2.4040201@opencsw.org> Hi, since we have a new boost I though I would give rtorrent a new try :) First thing is to build libtorrent which depends on libsigc++. This is build with sun studio atm. The last time I looked at it you will get other header files when you build with gcc. Which now hit's me as I build libtorrent with gcc. It fails with erros in the header files: libtool: compile: /opt/csw/bin/g++-4.6 -DHAVE_CONFIG_H -I. -I../../.. -I. -I./.. -I./../.. -I../../.. -I/opt/csw/include -O2 -pipe -m32 -march=pentiumpro -DNDEBUG -fvisibility=hidden -I/opt/csw/include -I/opt/csw/include/sigc++-2.0 -I/opt/csw/lib/sigc++-2.0/include -MT block.lo -MD -MP -MF .deps/block.Tpo -c block.cc -fPIC -DPIC -o .libs/block.o In file included from /opt/csw/include/sigc++-2.0/sigc++/signal_base.h:29:0, from /opt/csw/include/sigc++-2.0/sigc++/signal.h:8, from ./../../torrent/download_info.h:43, from ./../../protocol/extensions.h:47, from ./../../protocol/peer_connection_base.h:47, from block.cc:44: /opt/csw/include/sigc++-2.0/sigc++/functors/slot.h: In static member function 'static T_return sigc::internal::slot_call1::call_it(sigc::internal::slot_rep*, typename sigc::type_trait::take)': /opt/csw/include/sigc++-2.0/sigc++/functors/slot.h:136:106: error: expected '(' before '>' token /opt/csw/include/sigc++-2.0/sigc++/functors/slot.h: In static member function 'static T_return sigc::internal::slot_call2::call_it(sigc::internal::slot_rep*, typename sigc::type_trait::take, typename sigc::type_trait::take)': /opt/csw/include/sigc++-2.0/sigc++/functors/slot.h:172:106: error: expected '(' before ',' token In file included from /opt/csw/include/sigc++-2.0/sigc++/signal_base.h:29:0, from /opt/csw/include/sigc++-2.0/sigc++/signal.h:8, from ./../../torrent/download_info.h:43, from ./../../protocol/extensions.h:47, from ./../../protocol/peer_connection_base.h:47, from block.cc:44: /opt/csw/include/sigc++-2.0/sigc++/functors/slot.h:172:141: error: expected '(' before '>' token ...... Should we build a second libsigc++ in /opt/csw/gxx or just rebuild with gcc to /opt/csw/gxx as I think we should default C++ stuff to gcc anyway? Greetings Jan From dam at opencsw.org Wed Mar 14 10:31:57 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 14 Mar 2012 10:31:57 +0100 Subject: [csw-maintainers] Inconsistency on package database In-Reply-To: <1330091058-sup-811@pinkfloyd.chass.utoronto.ca> References: <1330091058-sup-811@pinkfloyd.chass.utoronto.ca> Message-ID: Hi Ben, Am 24.02.2012 um 14:46 schrieb Ben Walton: > Excerpts from Dagobert Michelsen's message of Thu Feb 23 08:32:08 -0500 2012: >> While the SUNW deps can be safely ignored by the package database >> the missing deps to the other packages is really bad: these are >> obsoleted packages transformed to _stub which are no longer in the >> package database. I think either the display needs to be adjusted >> to view by what it has been obsoleted or the stub packages need to >> be re-added to the database. > > Yes, this is a problem. I'll look at it over the weekend. It should > be fairly easy to either add all _stubs and setup the deps again or to > use the stub info to register the transitive dependency instead. I just noticed the problem still exists: e.g. the page for libidn is still missing: http://www.opencsw.org/packages/libidn/ although the libidn_stub package is in the catalog: /opencsw-official/unstable/sparc/5.10/libidn_stub-1.24,REV=2012.01.17-SunOS5.9-all-CSW.pkg.gz The result is that package having lots of _stub dependencies don't have them shown like icecast, which also depends on the legacy libidn: http://www.opencsw.org/packages/icecast/ Would you mind having a look? 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 Mar 14 18:10:51 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 14 Mar 2012 17:10:51 +0000 Subject: [csw-maintainers] Killing the stable release Message-ID: We've kept the stable release for people to use, calling it backward compatibility. But it's not obvious to users that it's dead. We've written this in a couple places, but in practice many people will not notice, and try to use stable, which will most likely give a bad impression of the state of the project. Therefore, I'd like to propose this radical change: Rename it to 'stable-dead'. It will break what we called backward compatibility, but here, it's a meaningless concept. Consider these points: - people who'll try to update from stable, will get errors - but there will be no updates anyway - people who are new, will see that it's dead and won't subscribe to it, unless they want to subscribe to a dead catalog So I see no real loss in doing that, and I see a gain in that the death of stable will be impossible to miss. With time, we'll introduce stable by creating a symlink from 'stable' to 'dublin', but not earlier than 6 or 12 months after breaking the old 'stable' directory. Thoughts? Maciej From bonivart at opencsw.org Wed Mar 14 18:17:01 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 14 Mar 2012 18:17:01 +0100 Subject: [csw-maintainers] Killing the stable release In-Reply-To: References: Message-ID: 2012/3/14 Maciej (Matchek) Blizi?ski : > Thoughts? +1 ...or as we say in Sweden - ?ntligen! From bwalton at opencsw.org Wed Mar 14 18:30:38 2012 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 14 Mar 2012 13:30:38 -0400 Subject: [csw-maintainers] Killing the stable release In-Reply-To: References: Message-ID: <1331745920-sup-3791@pinkfloyd.chass.utoronto.ca> Excerpts from Peter Bonivart's message of Wed Mar 14 13:17:01 -0400 2012: > 2012/3/14 Maciej (Matchek) Blizi?ski : > > Thoughts? > > +1 +1 from me too. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Wed Mar 14 20:18:39 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 14 Mar 2012 20:18:39 +0100 Subject: [csw-maintainers] Killing the stable release In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Wed, 14 Mar 2012 17:10:51 +0000") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 'stable-dead' ++ -- Peter From pfelecan at opencsw.org Wed Mar 14 20:19:58 2012 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 14 Mar 2012 20:19:58 +0100 Subject: [csw-maintainers] Solaris Studio vs GCC In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sun, 11 Mar 2012 17:58:10 +0000") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > Thoughts? make gcc the default compiler for OpenCSW -- Peter From markp at opencsw.org Wed Mar 14 21:56:08 2012 From: markp at opencsw.org (Mark Phillips) Date: Wed, 14 Mar 2012 20:56:08 +0000 Subject: [csw-maintainers] Test - please ignore Message-ID: Sorry folks, just testing something. From markp at opencsw.org Wed Mar 14 22:37:39 2012 From: markp at opencsw.org (Mark Phillips) Date: Wed, 14 Mar 2012 21:37:39 +0000 Subject: [csw-maintainers] Solaris Studio vs GCC In-Reply-To: References: <1331505713-sup-655@pinkfloyd.chass.utoronto.ca> Message-ID: <909EF7E6-2C2C-41E5-BAC3-A4B937F2B385@opencsw.org> On 11 Mar 2012, at 23:21, Peter Bonivart wrote: > On Sun, Mar 11, 2012 at 11:48 PM, Ben Walton wrote: >> I understand that performance of the binaries generated by studio used >> to be superior, but I don't know if that's still the case. Aside from >> this (possible) win for studio, what are some of the other reasons >> we've traditionally preferred it to gcc? > > I'd like to switch the _default_ compiler only. :) > > Today quite some packages are built with gcc anyway due to being too > hard to build with Studio. If someone feels that Studio will give them > faster binaries they can still use it. I would like to see some actual > numbers though for the sake of the discussion. James Lee used to > provide some back in the day. I've always wondered why we've never done any tests to prove one way or the other. It seems we've dogmatically followed the wisdom that Studio produces faster binaries. I'm sure that was the case, but I'd like to see if it's still *that* significant these days. It would make life a lot easier if we were using GCC for sure. From bwalton at opencsw.org Thu Mar 15 01:34:36 2012 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 14 Mar 2012 20:34:36 -0400 Subject: [csw-maintainers] whole catalog feeds In-Reply-To: <921CBC4F-28EE-4499-8C41-ED7CA10E5C3B@opencsw.org> References: <1331599643-sup-3316@pinkfloyd.chass.utoronto.ca> <921CBC4F-28EE-4499-8C41-ED7CA10E5C3B@opencsw.org> Message-ID: <1331771648-sup-8350@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Tue Mar 13 10:19:05 -0400 2012: > Hi Ben, > Collapsing this last line is the crucial thing: I suggest collapsing > it to Solaris 9+ Sparc/i386 to indicate it has been added to the > catalogs for Solaris 9, 10 and 11 both ISAs. > > A package only for Solaris 9 would be > Solaris 9 Sparc/i386 > followed by a Solaris 10 only package > Solaris 10 Sparc/i386 Ok, I'll make the entries more consise as you've described. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Mar 15 01:35:17 2012 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 14 Mar 2012 20:35:17 -0400 Subject: [csw-maintainers] Inconsistency on package database In-Reply-To: References: <1330091058-sup-811@pinkfloyd.chass.utoronto.ca> Message-ID: <1331771691-sup-4120@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Mar 14 05:31:57 -0400 2012: Hi Dago, > I just noticed the problem still exists: e.g. the page for libidn is > still missing: Yes, and 'still' is the keyword. I'm looking at implementing the required fixes now. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Thu Mar 15 07:59:06 2012 From: maciej at opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?=) Date: Thu, 15 Mar 2012 06:59:06 +0000 Subject: [csw-maintainers] Solaris Studio vs GCC In-Reply-To: <1331563601-sup-7922@pinkfloyd.chass.utoronto.ca> References: <1331505713-sup-655@pinkfloyd.chass.utoronto.ca> <1331563601-sup-7922@pinkfloyd.chass.utoronto.ca> Message-ID: <20120315065906.GA3877@quince.home.blizinski.pl> Ben Walton wrote: > Excerpts from Peter Bonivart's message of Sun Mar 11 19:21:30 -0400 2012: > > On Sun, Mar 11, 2012 at 11:48 PM, Ben Walton wrote: > > > > I understand that performance of the binaries generated by studio > > > used to be superior, but I don't know if that's still the > > > case. ?Aside from this (possible) win for studio, what are some of > > > the other reasons we've traditionally preferred it to gcc? > > > > I'd like to switch the _default_ compiler only. :) > > Yes, this is important. It was implicit in my mind, but it's good to > be explicit. If we wanted to do this, we need to plan how to transition. If we rebuild a C++ library sitting in /opt/csw/lib, we'll break all the clients that are built with Studio. We probably don't want that. We need to find a way to automatically check which libraries are built with Studio and which with GCC (by only looking at the binary and maybe doing some pattern searches on symbols). This will allow us to assess the situation better. If the target is to have GCC-built C++ libs in /opt/csw/lib, it would have to look something like this: 1. Identify all Studio C++ libs and their dependencies 2. Build the GCC versions of these libs into /opt/csw/gxx 3. Rebuild the dependencies using the libs in /opt/csw/gxx 4. Move the Studio libs from /opt/csw/lib to /opt/csw/studio or remove them altogether 5. Rebuild the GCC libs into /opt/csw/lib 6. Rebuild the dependencies It's not a trivial task. As an alternative, we could see if we can do a gradual migration, meaning that once we rebuild something, we follow this path. We could probably come up with a set of checks that would ensure the right order of operations. But then we'd have a mix of Studio and GCC C++ libraries in /opt/csw/lib, which could be royally confusing. Thoughts? Maciej From maciej at opencsw.org Thu Mar 15 08:20:01 2012 From: maciej at opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?=) Date: Thu, 15 Mar 2012 07:20:01 +0000 Subject: [csw-maintainers] libsigc++ and studio vs. gcc In-Reply-To: <4F605DD2.4040201@opencsw.org> References: <1328462253-sup-3570@pinkfloyd.chass.utoronto.ca> <1328921545-sup-4762@pinkfloyd.chass.utoronto.ca> <1331082289-sup-2275@pinkfloyd.chass.utoronto.ca> <46459F52-E56A-4447-80CB-E1D7E96C6254@opencsw.org> <1331128177-sup-7394@pinkfloyd.chass.utoronto.ca> <4F605DD2.4040201@opencsw.org> Message-ID: <20120315072001.GC3877@quince.home.blizinski.pl> Jan Holzhueter wrote: > Hi, > since we have a new boost I though I would give rtorrent a new try :) > First thing is to build libtorrent which depends on libsigc++. > This is build with sun studio atm. The last time I looked at it you will > get other header files when you build with gcc. > Which now hit's me as I build libtorrent with gcc. I'm curious how it ever worked. Did you actually link GCC-built rtorrent with Studio-built libsigc++? > It fails with erros in the header files: > > libtool: compile: /opt/csw/bin/g++-4.6 -DHAVE_CONFIG_H -I. -I../../.. > -I. -I./.. -I./../.. -I../../.. -I/opt/csw/include -O2 -pipe -m32 > -march=pentiumpro -DNDEBUG -fvisibility=hidden -I/opt/csw/include > -I/opt/csw/include/sigc++-2.0 -I/opt/csw/lib/sigc++-2.0/include -MT > block.lo -MD -MP -MF .deps/block.Tpo -c block.cc -fPIC -DPIC -o > .libs/block.o > In file included from /opt/csw/include/sigc++-2.0/sigc++/signal_base.h:29:0, > from /opt/csw/include/sigc++-2.0/sigc++/signal.h:8, > from ./../../torrent/download_info.h:43, > from ./../../protocol/extensions.h:47, > from ./../../protocol/peer_connection_base.h:47, > from block.cc:44: > /opt/csw/include/sigc++-2.0/sigc++/functors/slot.h: In static member > function 'static T_return sigc::internal::slot_call1 T_return, T_arg1>::call_it(sigc::internal::slot_rep*, typename > sigc::type_trait::take)': > /opt/csw/include/sigc++-2.0/sigc++/functors/slot.h:136:106: error: > expected '(' before '>' token > /opt/csw/include/sigc++-2.0/sigc++/functors/slot.h: In static member > function 'static T_return sigc::internal::slot_call2 T_return, T_arg1, T_arg2>::call_it(sigc::internal::slot_rep*, typename > sigc::type_trait::take, typename sigc::type_trait::take)': > /opt/csw/include/sigc++-2.0/sigc++/functors/slot.h:172:106: error: > expected '(' before ',' token > In file included from /opt/csw/include/sigc++-2.0/sigc++/signal_base.h:29:0, > from /opt/csw/include/sigc++-2.0/sigc++/signal.h:8, > from ./../../torrent/download_info.h:43, > from ./../../protocol/extensions.h:47, > from ./../../protocol/peer_connection_base.h:47, > from block.cc:44: > /opt/csw/include/sigc++-2.0/sigc++/functors/slot.h:172:141: error: > expected '(' before '>' token > ...... > > > Should we build a second libsigc++ in /opt/csw/gxx or just rebuild with > gcc to /opt/csw/gxx > as I think we should default C++ stuff to gcc anyway? The current idea is to build GCC stuff into /opt/csw/gxx, so you can go with that and have a GCC libsigc++ version. GARCOMPILER = GNU prefix = $(BUILD_PREFIX)/gxx Maciej From maciej at opencsw.org Thu Mar 15 09:12:13 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 15 Mar 2012 08:12:13 +0000 Subject: [csw-maintainers] The dublin release: remaining tasks In-Reply-To: References: <20111013090121.GA15669@bender.opencsw.org> <20111013101714.GB15669@bender.opencsw.org> <1328462253-sup-3570@pinkfloyd.chass.utoronto.ca> <1328921545-sup-4762@pinkfloyd.chass.utoronto.ca> <1331082289-sup-2275@pinkfloyd.chass.utoronto.ca> <46459F52-E56A-4447-80CB-E1D7E96C6254@opencsw.org> <1331128177-sup-7394@pinkfloyd.chass.utoronto.ca> Message-ID: I've seen that there were fixes pushed for php5, cool. This is the last major blocker for closing off dublin. I implemented a new small feature in my integration script: it now discerns between version upgrades and revision changes. The idea is that when we stabilize a catalog, we want to push fixes to the packaging, but no version upgrades. Maciej From dam at opencsw.org Thu Mar 15 09:20:53 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 15 Mar 2012 09:20:53 +0100 Subject: [csw-maintainers] Killing the stable release In-Reply-To: References: Message-ID: <41A15E2D-E4AF-478F-8857-7EBF174A094D@opencsw.org> Hi, Am 14.03.2012 um 18:10 schrieb Maciej (Matchek) Blizi?ski: > We've kept the stable release for people to use, calling it backward > compatibility. But it's not obvious to users that it's dead. We've > written this in a couple places, but in practice many people will not > notice, and try to use stable, which will most likely give a bad > impression of the state of the project. > > Therefore, I'd like to propose this radical change: Rename it to > 'stable-dead'. It will break what we called backward compatibility, > but here, it's a meaningless concept. Consider these points: > > - people who'll try to update from stable, will get errors > - but there will be no updates anyway > - people who are new, will see that it's dead and won't subscribe to > it, unless they want to subscribe to a dead catalog > > So I see no real loss in doing that, and I see a gain in that the > death of stable will be impossible to miss. > > With time, we'll introduce stable by creating a symlink from 'stable' > to 'dublin', but not earlier than 6 or 12 months after breaking the > old 'stable' directory. > > Thoughts? As I outlined during the camp I would favor a solution where pkgutil tries to download some kind of message-of-the-day from the catalog and display it. We can add such a notice in stable/ while moving all packages to a different directory. This gives everybody the chance to relocate without breakage. 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 Mar 15 09:37:53 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 15 Mar 2012 09:37:53 +0100 Subject: [csw-maintainers] Solaris Studio vs GCC In-Reply-To: <20120315065906.GA3877@quince.home.blizinski.pl> References: <1331505713-sup-655@pinkfloyd.chass.utoronto.ca> <1331563601-sup-7922@pinkfloyd.chass.utoronto.ca> <20120315065906.GA3877@quince.home.blizinski.pl> Message-ID: <93083786-79E9-4AA8-97E8-277C0DE13A65@opencsw.org> Hi Maciej, Am 15.03.2012 um 07:59 schrieb Maciej Blizi?ski: > Ben Walton wrote: >> Excerpts from Peter Bonivart's message of Sun Mar 11 19:21:30 -0400 2012: >>> On Sun, Mar 11, 2012 at 11:48 PM, Ben Walton wrote: >> >>>> I understand that performance of the binaries generated by studio >>>> used to be superior, but I don't know if that's still the >>>> case. Aside from this (possible) win for studio, what are some of >>>> the other reasons we've traditionally preferred it to gcc? >>> >>> I'd like to switch the _default_ compiler only. :) >> >> Yes, this is important. It was implicit in my mind, but it's good to >> be explicit. > > If we wanted to do this, we need to plan how to transition. If we > rebuild a C++ library sitting in /opt/csw/lib, we'll break all the > clients that are built with Studio. We probably don't want that. > > We need to find a way to automatically check which libraries are built > with Studio and which with GCC (by only looking at the binary and maybe > doing some pattern searches on symbols). This will allow us to assess > the situation better. If the target is to have GCC-built C++ libs in > /opt/csw/lib, it would have to look something like this: What if something requires Sun Studio? (I have no example at hand, but it is thinkable for some more proprietary stuff) > 1. Identify all Studio C++ libs and their dependencies > 2. Build the GCC versions of these libs into /opt/csw/gxx > 3. Rebuild the dependencies using the libs in /opt/csw/gxx > 4. Move the Studio libs from /opt/csw/lib to /opt/csw/studio or remove > them altogether > 5. Rebuild the GCC libs into /opt/csw/lib > 6. Rebuild the dependencies > > It's not a trivial task. > > As an alternative, we could see if we can do a gradual migration, > meaning that once we rebuild something, we follow this path. We could > probably come up with a set of checks that would ensure the right order > of operations. But then we'd have a mix of Studio and GCC C++ libraries > in /opt/csw/lib, which could be royally confusing. > > Thoughts? I don't think it is a real gain. The current model allows building C code with the compiler of the maintainers choice (which is good IMHO), whereas C++ code needs to be compiled twice. While this is more work it is only needed for C++ projects which are a limited set. Additionally, I prefer Sun Studio because it is stricter and helps upstream to keep a portable codebase. Most upstream projects are indeed concerned about this. To summarize, I see a lot of work for the transition with little gain. We have probably more important things to do. Just my 0,02 ? 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 Mar 15 09:45:58 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 15 Mar 2012 09:45:58 +0100 Subject: [csw-maintainers] The dublin release: remaining tasks In-Reply-To: References: <20111013090121.GA15669@bender.opencsw.org> <20111013101714.GB15669@bender.opencsw.org> <1328462253-sup-3570@pinkfloyd.chass.utoronto.ca> <1328921545-sup-4762@pinkfloyd.chass.utoronto.ca> <1331082289-sup-2275@pinkfloyd.chass.utoronto.ca> <46459F52-E56A-4447-80CB-E1D7E96C6254@opencsw.org> <1331128177-sup-7394@pinkfloyd.chass.utoronto.ca> Message-ID: <47BEB36E-1D2C-4559-8D6F-43100D283016@opencsw.org> Hi Maciej, Am 15.03.2012 um 09:12 schrieb Maciej (Matchek) Blizi?ski: > I've seen that there were fixes pushed for php5, cool. This is the > last major blocker for closing off dublin. > > I implemented a new small feature in my integration script: it now > discerns between version upgrades and revision changes. The idea is > that when we stabilize a catalog, we want to push fixes to the > packaging, but no version upgrades. This should be fairly easy to automate: Push if the version is the same and just REV has changed. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Thu Mar 15 10:43:15 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 15 Mar 2012 09:43:15 +0000 Subject: [csw-maintainers] Killing the stable release In-Reply-To: <41A15E2D-E4AF-478F-8857-7EBF174A094D@opencsw.org> References: <41A15E2D-E4AF-478F-8857-7EBF174A094D@opencsw.org> Message-ID: 2012/3/15 Dagobert Michelsen : > As I outlined during the camp I would favor a solution where pkgutil tries to > download some kind of message-of-the-day from the catalog and display it. > We can add such a notice in stable/ while moving all packages to a different > directory. This gives everybody the chance to relocate without breakage. I like the message-of-the-day idea, I think it's a good thing to have anyway. Do you have a concrete idea of how exactly would it work? In the case of stable, there is not much breakage. Maybe the only breakage would be when someone has a machine running stable, and they want to install a new package that they haven't installed before. That wouldn't work after the rename. They'd have to reconfigure pkgutil.conf to point at stable-dead, that's all. What I like about the rename idea is that there is no possible way you can miss this. Also, it forces people to resubscribe to stable-dead if they want to continue using it, creating room for the new stable we'll eventually produce. Maciej From bonivart at opencsw.org Thu Mar 15 10:57:32 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 15 Mar 2012 10:57:32 +0100 Subject: [csw-maintainers] Killing the stable release In-Reply-To: References: <41A15E2D-E4AF-478F-8857-7EBF174A094D@opencsw.org> Message-ID: 2012/3/15 Maciej (Matchek) Blizi?ski : > In the case of stable, there is not much breakage. Maybe the only > breakage would be when someone has a machine running stable, and they > want to install a new package that they haven't installed before. That > wouldn't work after the rename. They'd have to reconfigure > pkgutil.conf to point at stable-dead, that's all. Pkgutil will fail without "injury". I see two cases, you have an up to date catalog, then the actual file fetching will fail and pkgutil aborts. Otherwise, the catalog fetching will fail and pkgutil aborts. In both cases no changes are made to your system. How about pkg-get? How does that work if download don't work? Is it possible that it removes packages first, tries to download new ones, fails and you end up without some packages you had? I assume lots of users of stable are still on pkg-get. From dam at opencsw.org Thu Mar 15 11:13:42 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 15 Mar 2012 11:13:42 +0100 Subject: [csw-maintainers] Killing the stable release In-Reply-To: References: <41A15E2D-E4AF-478F-8857-7EBF174A094D@opencsw.org> Message-ID: Hi, Am 15.03.2012 um 10:57 schrieb Peter Bonivart: > 2012/3/15 Maciej (Matchek) Blizi?ski : >> In the case of stable, there is not much breakage. Maybe the only >> breakage would be when someone has a machine running stable, and they >> want to install a new package that they haven't installed before. That >> wouldn't work after the rename. They'd have to reconfigure >> pkgutil.conf to point at stable-dead, that's all. > > Pkgutil will fail without "injury". I see two cases, you have an up to > date catalog, then the actual file fetching will fail and pkgutil > aborts. Otherwise, the catalog fetching will fail and pkgutil aborts. > In both cases no changes are made to your system. I suggest having three extra file 00PACKAGENOTFOUND 00CATALOGNOTFOUND 00MOTD If a package could not be found the first is tried to be download and displayed. If it is not there nothing happens. If a catalog could not be found the second is displayed. The third is tried and displayed on every update (-U). > How about pkg-get? How does that work if download don't work? Is it > possible that it removes packages first, tries to download new ones, > fails and you end up without some packages you had? I assume lots of > users of stable are still on pkg-get. Hum. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From maciej at opencsw.org Thu Mar 15 12:48:44 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 15 Mar 2012 11:48:44 +0000 Subject: [csw-maintainers] The dublin release: remaining tasks In-Reply-To: <47BEB36E-1D2C-4559-8D6F-43100D283016@opencsw.org> References: <20111013090121.GA15669@bender.opencsw.org> <20111013101714.GB15669@bender.opencsw.org> <1328462253-sup-3570@pinkfloyd.chass.utoronto.ca> <1328921545-sup-4762@pinkfloyd.chass.utoronto.ca> <1331082289-sup-2275@pinkfloyd.chass.utoronto.ca> <46459F52-E56A-4447-80CB-E1D7E96C6254@opencsw.org> <1331128177-sup-7394@pinkfloyd.chass.utoronto.ca> <47BEB36E-1D2C-4559-8D6F-43100D283016@opencsw.org> Message-ID: 2012/3/15 Dagobert Michelsen : > This should be fairly easy to automate: Push if the version is the same > and just REV has changed. I would be cautious in making it automatic just yet. What if you up the rev, because you split the packages? The split packages would not be integrated, and the old packages would be missing files. From dam at opencsw.org Thu Mar 15 12:51:15 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 15 Mar 2012 12:51:15 +0100 Subject: [csw-maintainers] The dublin release: remaining tasks In-Reply-To: References: <20111013090121.GA15669@bender.opencsw.org> <20111013101714.GB15669@bender.opencsw.org> <1328462253-sup-3570@pinkfloyd.chass.utoronto.ca> <1328921545-sup-4762@pinkfloyd.chass.utoronto.ca> <1331082289-sup-2275@pinkfloyd.chass.utoronto.ca> <46459F52-E56A-4447-80CB-E1D7E96C6254@opencsw.org> <1331128177-sup-7394@pinkfloyd.chass.utoronto.ca> <47BEB36E-1D2C-4559-8D6F-43100D283016@opencsw.org> Message-ID: <9B345009-B5DE-45DA-84C6-452976310A17@opencsw.org> Hi Maciej, Am 15.03.2012 um 12:48 schrieb Maciej (Matchek) Blizi?ski: > 2012/3/15 Dagobert Michelsen : >> This should be fairly easy to automate: Push if the version is the same >> and just REV has changed. > > I would be cautious in making it automatic just yet. What if you up > the rev, because you split the packages? The split packages would not > be integrated, and the old packages would be missing files. That means we must have the concept of "bundle" first :-) Integration of bundles is alrady pretty much mandatory. 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 Thu Mar 15 15:36:11 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Thu, 15 Mar 2012 15:36:11 +0100 Subject: [csw-maintainers] libsigc++ and studio vs. gcc In-Reply-To: <20120315072001.GC3877@quince.home.blizinski.pl> References: <1328462253-sup-3570@pinkfloyd.chass.utoronto.ca> <1328921545-sup-4762@pinkfloyd.chass.utoronto.ca> <1331082289-sup-2275@pinkfloyd.chass.utoronto.ca> <46459F52-E56A-4447-80CB-E1D7E96C6254@opencsw.org> <1331128177-sup-7394@pinkfloyd.chass.utoronto.ca> <4F605DD2.4040201@opencsw.org> <20120315072001.GC3877@quince.home.blizinski.pl> Message-ID: <4F61FE5B.3040909@opencsw.org> Am 15.03.12 08:20, schrieb Maciej Blizi?ski: > Jan Holzhueter wrote: >> Hi, >> since we have a new boost I though I would give rtorrent a new try :) >> First thing is to build libtorrent which depends on libsigc++. >> This is build with sun studio atm. The last time I looked at it you will >> get other header files when you build with gcc. >> Which now hit's me as I build libtorrent with gcc. > > I'm curious how it ever worked. Did you actually link GCC-built rtorrent > with Studio-built libsigc++? It never worked :) well libtorrent I did manage to build with sun studio. Lot's of crazy pachtes. But rtorrent did fail. Just thought I give it another try. Jan From bwalton at opencsw.org Fri Mar 16 02:40:14 2012 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 15 Mar 2012 21:40:14 -0400 Subject: [csw-maintainers] pine vs alpine Message-ID: <1331861959-sup-2030@pinkfloyd.chass.utoronto.ca> Hi All, I'm cleaning up the web db as part of fixing the stub dependency issue Dago found. I've detected a path conflict between pine and alpine. As alpine supercedes pine, I think we should just remove pine...maybe with a pine_stub to transition people. Any objections? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Fri Mar 16 03:04:23 2012 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 15 Mar 2012 22:04:23 -0400 Subject: [csw-maintainers] more file conflicts... In-Reply-To: <1331861959-sup-2030@pinkfloyd.chass.utoronto.ca> References: <1331861959-sup-2030@pinkfloyd.chass.utoronto.ca> Message-ID: <1331863391-sup-4927@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Thu Mar 15 21:40:14 -0400 2012: Another conflict: +----------------+----------------------------------------------+ | pkgname | fullpath | +----------------+----------------------------------------------+ | CSWpmapachetst | /opt/csw/share/man/man3/Apache::TestMM.3perl | | CSWap2modperl | /opt/csw/share/man/man3/Apache::TestMM.3perl | +----------------+----------------------------------------------+ pm_apachetst appears to be a legacy item too. Does anyone know if this is still useful? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Fri Mar 16 03:33:20 2012 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 15 Mar 2012 22:33:20 -0400 Subject: [csw-maintainers] more file conflicts... In-Reply-To: <1331863391-sup-4927@pinkfloyd.chass.utoronto.ca> References: <1331861959-sup-2030@pinkfloyd.chass.utoronto.ca> <1331863391-sup-4927@pinkfloyd.chass.utoronto.ca> Message-ID: <1331865129-sup-2491@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Thu Mar 15 22:04:23 -0400 2012: It looks like each of the gcc2 packages pulled in the same file: mysql> select pkgname, fullpath from pathnames where filename = mysql> 'specs.noncsw'; +--------------+--------------------------------------------------------------------+ | pkgname | fullpath mysql> | +--------------+--------------------------------------------------------------------+ | CSWgcc2g++ | mysql> /opt/csw/gcc2/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/specs.noncsw mysql> | | CSWgcc2core | mysql> /opt/csw/gcc2/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/specs.noncsw mysql> | | CSWgcc2chill | mysql> /opt/csw/gcc2/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/specs.noncsw mysql> | | CSWgcc2objc | mysql> /opt/csw/gcc2/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/specs.noncsw mysql> | | CSWgcc2java | mysql> /opt/csw/gcc2/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/specs.noncsw mysql> | | CSWgcc2g77 | mysql> /opt/csw/gcc2/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/specs.noncsw mysql> | +--------------+--------------------------------------------------------------------+ Other than packages that may depend on libgcc_s.so from gcc2, is there any reason to hold onto this? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From jeff at cjsa.com Fri Mar 16 04:48:24 2012 From: jeff at cjsa.com (Jeffery Small) Date: Fri, 16 Mar 2012 03:48:24 GMT Subject: [csw-maintainers] Killing the stable release References: <41A15E2D-E4AF-478F-8857-7EBF174A094D@opencsw.org> Message-ID: Peter Bonivart writes: >How about pkg-get? How does that work if download don't work? Is it >possible that it removes packages first, tries to download new ones, >fails and you end up without some packages you had? I assume lots of >users of stable are still on pkg-get. Yes, please explain the status of pkg-get. I have a complex UI front-end that I use based upon pkg-get, so I have been reluctant to migrate to pkgutil. What are the ramifications of continuing to use pkg-get? Also, could you explain just how stable "current/testing" is? I see that a bunch of packages were recently added, but I'm wondering just how safe it is to update against this. I really don't have a clear picture of what is happening with opencsw these days. Are there any plans for resuming the weekly status updates for new and updated packages that Phil use to issue? Regards, -- Jeff C. Jeffery Small CJSA LLC 206-232-3338 jeff at cjsa.com 7000 E Mercer Way, Mercer Island, WA 98040 From maciej at opencsw.org Fri Mar 16 08:51:01 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 16 Mar 2012 07:51:01 +0000 Subject: [csw-maintainers] pine vs alpine In-Reply-To: <1331861959-sup-2030@pinkfloyd.chass.utoronto.ca> References: <1331861959-sup-2030@pinkfloyd.chass.utoronto.ca> Message-ID: 2012/3/16 Ben Walton > > I'm cleaning up the web db as part of fixing the stub dependency issue > Dago found. > > I've detected a path conflict between pine and alpine. ?As alpine > supercedes pine, I think we should just remove pine...maybe with a > pine_stub to transition people. > > Any objections? Is the problem that the scripts can't handle path conflicts? From dam at opencsw.org Fri Mar 16 09:01:02 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 16 Mar 2012 09:01:02 +0100 Subject: [csw-maintainers] pine vs alpine In-Reply-To: <1331861959-sup-2030@pinkfloyd.chass.utoronto.ca> References: <1331861959-sup-2030@pinkfloyd.chass.utoronto.ca> Message-ID: <232A550E-8E52-47CC-A836-AF8F5918653B@opencsw.org> Hi Ben, Am 16.03.2012 um 02:40 schrieb Ben Walton: > I'm cleaning up the web db as part of fixing the stub dependency issue > Dago found. > > I've detected a path conflict between pine and alpine. As alpine > supercedes pine, I think we should just remove pine...maybe with a > pine_stub to transition people. > > Any objections? No :-) Do you think it would be good to add a symlink of bin/pine to alpine? 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 Fri Mar 16 09:01:41 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 16 Mar 2012 09:01:41 +0100 Subject: [csw-maintainers] more file conflicts... In-Reply-To: <1331863391-sup-4927@pinkfloyd.chass.utoronto.ca> References: <1331861959-sup-2030@pinkfloyd.chass.utoronto.ca> <1331863391-sup-4927@pinkfloyd.chass.utoronto.ca> Message-ID: <133CBA00-600B-4940-A137-1D0618061C12@opencsw.org> Hi Ben, Am 16.03.2012 um 03:04 schrieb Ben Walton: > Another conflict: > > +----------------+----------------------------------------------+ > | pkgname | fullpath | > +----------------+----------------------------------------------+ > | CSWpmapachetst | /opt/csw/share/man/man3/Apache::TestMM.3perl | > | CSWap2modperl | /opt/csw/share/man/man3/Apache::TestMM.3perl | > +----------------+----------------------------------------------+ > > pm_apachetst appears to be a legacy item too. Does anyone know if > this is still useful? No. Lets drop CSWpmapachetst. 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 Fri Mar 16 09:21:44 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Fri, 16 Mar 2012 09:21:44 +0100 Subject: [csw-maintainers] The dublin release: remaining tasks In-Reply-To: <7490fe1e4762.4f62f80c@contac-dt.de> References: <7490fe1e4762.4f62f80c@contac-dt.de> Message-ID: <7490d3d657bb.4f630628@contac-dt.de> some days ago I have done some tests with cups 1.5.0 and was satisfied with the results. I would recommend? this version push to unstable. Also I have added hplip pakage to experimental witch contains the mostly used HP PPD's for cups. This can [we|I] add to the unstable too. Best regards Carsten -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Fri Mar 16 09:27:49 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 16 Mar 2012 09:27:49 +0100 Subject: [csw-maintainers] The dublin release: remaining tasks In-Reply-To: <7490d3d657bb.4f630628@contac-dt.de> References: <7490fe1e4762.4f62f80c@contac-dt.de> <7490d3d657bb.4f630628@contac-dt.de> Message-ID: Hi Carsten, Am 16.03.2012 um 09:21 schrieb Carsten Grzemba: > some days ago I have done some tests with cups 1.5.0 and was satisfied with the results. I would recommend this version push to unstable. > Also I have added hplip pakage to experimental witch contains the mostly used HP PPD's for cups. This can [we|I] add to the unstable too. Excellent! Would you mind adopting CUPS as it was a courtesy rebuild for me and I don't use CUPS myself? 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 Fri Mar 16 09:33:12 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 16 Mar 2012 08:33:12 +0000 Subject: [csw-maintainers] more file conflicts... In-Reply-To: <1331863391-sup-4927@pinkfloyd.chass.utoronto.ca> References: <1331861959-sup-2030@pinkfloyd.chass.utoronto.ca> <1331863391-sup-4927@pinkfloyd.chass.utoronto.ca> Message-ID: 2012/3/16 Ben Walton : > Another conflict: I'm concerned that you're playing whackamole, while the real problem is that there will always be conflicting paths in the real world, and the automation has to be able to cope with it. From maciej at opencsw.org Fri Mar 16 09:48:06 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 16 Mar 2012 08:48:06 +0000 Subject: [csw-maintainers] The dublin release: remaining tasks In-Reply-To: <7490d3d657bb.4f630628@contac-dt.de> References: <7490fe1e4762.4f62f80c@contac-dt.de> <7490d3d657bb.4f630628@contac-dt.de> Message-ID: 2012/3/16 Carsten Grzemba : > some days ago I have done some tests with cups 1.5.0 and was satisfied with > the results. I would recommend? this version push to unstable. > Also I have added hplip pakage to experimental witch contains the mostly > used HP PPD's for cups. This can [we|I] add to the unstable too. Cool. The last time I tried 1.5.0, it didn't work for me. If you tested it and it worked, please push to unstable. I wouldn't include it in dublin though. From bwalton at opencsw.org Fri Mar 16 14:00:32 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 16 Mar 2012 09:00:32 -0400 Subject: [csw-maintainers] more file conflicts... In-Reply-To: References: <1331861959-sup-2030@pinkfloyd.chass.utoronto.ca> <1331863391-sup-4927@pinkfloyd.chass.utoronto.ca> Message-ID: <1331902468-sup-6579@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Fri Mar 16 04:33:12 -0400 2012: > I'm concerned that you're playing whackamole, while the real problem > is that there will always be conflicting paths in the real world, > and the automation has to be able to cope with it. Well, I could certainly pre-identify these with an appropriate query. As there aren't that many and it's useful to test this part of the machinery, I've opted to just let it be found ad-hoc for now...(I just add an override flag for the right packages and run the job again, so I'm not being held up on this, I'm just flagging them as they're found.) So in a way, it is whack-a-mole...I'm honouring the current policy which says that packages can't deliver the same file. As I've said previously, I dislike this policy. We have I-deps in the catalog and as long as a package with a conflicting file declares itself I with other packages delivering the same file, I don't have a problem with it. I do agree with the intent of the current policy, but I think it's implemented incorrectly. It wouldn't be nice to have two packages deliver /opt/csw/bin/imap (for example) as the system doesn't handle that very nicely. So there is merit in enforcing some sort of sanity check on this, but I agree that the current method isn't the right choice. This should ultimately be handled at the checkpkg level where the files and I-deps could more easily be considered against the whole catalog. Is that easy to add to checkpkg? If so, I'll drop the uniquepaths checks that occur at db registration time and bury my head in the sand for now. :) Thoughts? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Fri Mar 16 14:01:31 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 16 Mar 2012 09:01:31 -0400 Subject: [csw-maintainers] pine vs alpine In-Reply-To: <232A550E-8E52-47CC-A836-AF8F5918653B@opencsw.org> References: <1331861959-sup-2030@pinkfloyd.chass.utoronto.ca> <232A550E-8E52-47CC-A836-AF8F5918653B@opencsw.org> Message-ID: <1331902839-sup-987@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Fri Mar 16 04:01:02 -0400 2012: > No :-) Do you think it would be good to add a symlink of bin/pine to > alpine? Probably. Alpine was done by Mike so it will have a recipe that should be easy to update. I'll see about a respin with the obsoletions. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Fri Mar 16 14:12:10 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 16 Mar 2012 13:12:10 +0000 Subject: [csw-maintainers] more file conflicts... In-Reply-To: <1331902468-sup-6579@pinkfloyd.chass.utoronto.ca> References: <1331861959-sup-2030@pinkfloyd.chass.utoronto.ca> <1331863391-sup-4927@pinkfloyd.chass.utoronto.ca> <1331902468-sup-6579@pinkfloyd.chass.utoronto.ca> Message-ID: 2012/3/16 Ben Walton : > This should ultimately be handled at the checkpkg level where the > files and I-deps could more easily be considered against the whole > catalog. ?Is that easy to add to checkpkg? ?If so, I'll drop the > uniquepaths checks that occur at db registration time and bury my head > in the sand for now. :) Checkpkg currently alerts on any file conflicts, but as with any other error tag, you can override it if you believe that this is the right thing to do. The error tag is thrown regardless of i-deps. I could implement the following: If there is a file conflict with a package which is not in i-deps, throw an error and suggest either moving the file away or adding an i-dep entry. I think you can drop the unique paths check - this is already handled by checkpkg. From bwalton at opencsw.org Fri Mar 16 14:28:39 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 16 Mar 2012 09:28:39 -0400 Subject: [csw-maintainers] more file conflicts... In-Reply-To: References: <1331861959-sup-2030@pinkfloyd.chass.utoronto.ca> <1331863391-sup-4927@pinkfloyd.chass.utoronto.ca> <1331902468-sup-6579@pinkfloyd.chass.utoronto.ca> Message-ID: <1331904434-sup-4391@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Fri Mar 16 09:12:10 -0400 2012: > Checkpkg currently alerts on any file conflicts, but as with any > other error tag, you can override it if you believe that this is the > right thing to do. The error tag is thrown regardless of i-deps. I > could implement the following: Ok. Could it hard error (no override) unless your modification below is made and there is an I-dep? > If there is a file conflict with a package which is not in i-deps, > throw an error and suggest either moving the file away or adding an > i-dep entry. +1 for this. > I think you can drop the unique paths check - this is already > handled by checkpkg. Gladly. I'll implement this quick fix and kick the global re-import again. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Fri Mar 16 16:01:43 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 16 Mar 2012 15:01:43 +0000 Subject: [csw-maintainers] more file conflicts... In-Reply-To: <1331904434-sup-4391@pinkfloyd.chass.utoronto.ca> References: <1331861959-sup-2030@pinkfloyd.chass.utoronto.ca> <1331863391-sup-4927@pinkfloyd.chass.utoronto.ca> <1331902468-sup-6579@pinkfloyd.chass.utoronto.ca> <1331904434-sup-4391@pinkfloyd.chass.utoronto.ca> Message-ID: 2012/3/16 Ben Walton : > Excerpts from Maciej (Matchek) Blizi?ski's message of Fri Mar 16 09:12:10 -0400 2012: > >> Checkpkg currently alerts on any file conflicts, but as with any >> other error tag, you can override it if you believe that this is the >> right thing to do. The error tag is thrown regardless of i-deps. I >> could implement the following: > > Ok. ?Could it hard error (no override) unless your modification below > is made and there is an I-dep? I've been resisting any hard errors. The machine should not assume it's always smarter than a human. If you want to nag maintainers during future builds, you can modify the build recipes and remove all the overrides for the file conficts. Otherwise, we can introduce a new error tag name for which there will be no overrides in the code base, e.g. incompatible-pkg-missing or something similar. >> If there is a file conflict with a package which is not in i-deps, >> throw an error and suggest either moving the file away or adding an >> i-dep entry. > > +1 for this. > >> I think you can drop the unique paths check - this is already >> handled by checkpkg. > > Gladly. ?I'll implement this quick fix and kick the global re-import > again. Cool! From bwalton at opencsw.org Fri Mar 16 16:04:16 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 16 Mar 2012 11:04:16 -0400 Subject: [csw-maintainers] more file conflicts... In-Reply-To: References: <1331861959-sup-2030@pinkfloyd.chass.utoronto.ca> <1331863391-sup-4927@pinkfloyd.chass.utoronto.ca> <1331902468-sup-6579@pinkfloyd.chass.utoronto.ca> <1331904434-sup-4391@pinkfloyd.chass.utoronto.ca> Message-ID: <1331910203-sup-2783@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Fri Mar 16 11:01:43 -0400 2012: > I've been resisting any hard errors. The machine should not assume > it's always smarter than a human. If you want to nag maintainers > during future builds, you can modify the build recipes and remove > all the overrides for the file conficts. Otherwise, we can introduce > a new error tag name for which there will be no overrides in the > code base, e.g. incompatible-pkg-missing or something similar. Ok, I'm good with that rationale. > > Gladly. ?I'll implement this quick fix and kick the global > > re-import again. And I'm running the bulk registration process now without uniquepaths so we're winning all over! :) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Fri Mar 16 18:14:01 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 16 Mar 2012 13:14:01 -0400 Subject: [csw-maintainers] Inconsistency on package database In-Reply-To: <1331771691-sup-4120@pinkfloyd.chass.utoronto.ca> References: <1330091058-sup-811@pinkfloyd.chass.utoronto.ca> <1331771691-sup-4120@pinkfloyd.chass.utoronto.ca> Message-ID: <1331918003-sup-8437@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Wed Mar 14 20:35:17 -0400 2012: > > I just noticed the problem still exists: e.g. the page for libidn is > > still missing: > > Yes, and 'still' is the keyword. I'm looking at implementing the > required fixes now. I've just fishined a bulk import of the entire catalog (sol10/sparc) in my sandbox. I'll look at updating live tonight. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Fri Mar 16 18:36:13 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 16 Mar 2012 13:36:13 -0400 Subject: [csw-maintainers] Killing the stable release In-Reply-To: References: <41A15E2D-E4AF-478F-8857-7EBF174A094D@opencsw.org> Message-ID: <1331918913-sup-5027@pinkfloyd.chass.utoronto.ca> Excerpts from jeff's message of Thu Mar 15 23:48:24 -0400 2012: Hi Jeff, > Yes, please explain the status of pkg-get. I have a complex UI > front-end that I use based upon pkg-get, so I have been reluctant to > migrate to pkgutil. What are the ramifications of continuing to use > pkg-get? The pkg-get tool is deprecated. It's still there if you really want it but it's not supported and if we ever made incompatible catalog changes (not planned right now, but...) you'd need to update pkgutil to get the new functionality. Any of the proposed changes to catalog that I've seen generally centre around changing the format to something like xml or json or yaml. In that case, we could likely do a side-by-side (2 catalogs) and have tools use the one they know how to handle, with reduced functionality for the tradtional formats as the consequence. (Don't hold me to this, it's all just hypothetical right now. :) ) > Also, could you explain just how stable "current/testing" is? I see > that a bunch of packages were recently added, but I'm wondering just > how safe it is to update against this. I really don't have a clear > picture of what is happening with opencsw these days. Most users should stick to the dublin branch at this point. It's going to provide the most stability. I run my stuff on unstable but I don't update it to bleeding edge all the time... > Are there any plans for resuming the weekly status updates for new > and updated packages that Phil use to issue? This would be easy to hack up, I think but it's not a priority for me. Is it something you'd tackle? It could be as simple as parsing the atom feed weekly for any entries within the last week and reformatting them for an email broadcast... Hope this helps. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Mar 17 02:00:38 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 16 Mar 2012 21:00:38 -0400 Subject: [csw-maintainers] Inconsistency on package database In-Reply-To: <1331918003-sup-8437@pinkfloyd.chass.utoronto.ca> References: <1330091058-sup-811@pinkfloyd.chass.utoronto.ca> <1331771691-sup-4120@pinkfloyd.chass.utoronto.ca> <1331918003-sup-8437@pinkfloyd.chass.utoronto.ca> Message-ID: <1331945934-sup-6797@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Fri Mar 16 13:14:01 -0400 2012: > I've just fishined a bulk import of the entire catalog (sol10/sparc) > in my sandbox. I'll look at updating live tonight. This updated database is now live. I think I'm also going to switch the default architecture for this purpose from sparc to i386 as problem packages tend to be i386-only as opposed to sparc-only. For now, _stub packages are visible on the web site main package listing. When I have a moment, I'll mask them from the main view making them only visible if you browse to them from a dependency list. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Mar 17 03:03:41 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 16 Mar 2012 22:03:41 -0400 Subject: [csw-maintainers] Inconsistency on package database In-Reply-To: <1331945934-sup-6797@pinkfloyd.chass.utoronto.ca> References: <1330091058-sup-811@pinkfloyd.chass.utoronto.ca> <1331771691-sup-4120@pinkfloyd.chass.utoronto.ca> <1331918003-sup-8437@pinkfloyd.chass.utoronto.ca> <1331945934-sup-6797@pinkfloyd.chass.utoronto.ca> Message-ID: <1331949772-sup-6101@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Fri Mar 16 21:00:38 -0400 2012: > This updated database is now live. I think I'm also going to switch > the default architecture for this purpose from sparc to i386 as > problem packages tend to be i386-only as opposed to sparc-only. After comparing unstable/10/sparc with unstable/10/i386, I've made the switch for both web and mantis db maintenance. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Mar 17 03:31:27 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 16 Mar 2012 22:31:27 -0400 Subject: [csw-maintainers] Inconsistency on package database In-Reply-To: <1331945934-sup-6797@pinkfloyd.chass.utoronto.ca> References: <1330091058-sup-811@pinkfloyd.chass.utoronto.ca> <1331771691-sup-4120@pinkfloyd.chass.utoronto.ca> <1331918003-sup-8437@pinkfloyd.chass.utoronto.ca> <1331945934-sup-6797@pinkfloyd.chass.utoronto.ca> Message-ID: <1331951370-sup-4382@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Fri Mar 16 21:00:38 -0400 2012: > For now, _stub packages are visible on the web site main package > listing. When I have a moment, I'll mask them from the main view > making them only visible if you browse to them from a dependency > list. This was easier than I expected so the change is now implemented. The global package listing at http://opencsw.org/packages omits _stub packages, but viewing an individual package lists the _stub dependencies allowing people to browse through properly. For example: http://www.opencsw.org/packages/CSWapache2/ Let me know if you spot anything that isn't right after this change. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sat Mar 17 10:28:13 2012 From: maciej at opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?=) Date: Sat, 17 Mar 2012 09:28:13 +0000 Subject: [csw-maintainers] Inconsistency on package database In-Reply-To: <1331949772-sup-6101@pinkfloyd.chass.utoronto.ca> References: <1330091058-sup-811@pinkfloyd.chass.utoronto.ca> <1331771691-sup-4120@pinkfloyd.chass.utoronto.ca> <1331918003-sup-8437@pinkfloyd.chass.utoronto.ca> <1331945934-sup-6797@pinkfloyd.chass.utoronto.ca> <1331949772-sup-6101@pinkfloyd.chass.utoronto.ca> Message-ID: <20120317092813.GA29664@quince.home.blizinski.pl> Ben Walton wrote: > Excerpts from Ben Walton's message of Fri Mar 16 21:00:38 -0400 2012: > > > This updated database is now live. I think I'm also going to switch > > the default architecture for this purpose from sparc to i386 as > > problem packages tend to be i386-only as opposed to sparc-only. > > After comparing unstable/10/sparc with unstable/10/i386, I've made the > switch for both web and mantis db maintenance. Ideally we would show the union of both, but there currently is no loss in showing the x86 packages. = x86 only = libhashkit1 libmemcached libmemcached8 libmemcachedprotocol0 libmemcachedutil2 libquadmath0 mongodb = sparc only = ncsa_mosaic pm_dbd_sybase_ocs From bwalton at opencsw.org Sat Mar 17 14:30:07 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 17 Mar 2012 09:30:07 -0400 Subject: [csw-maintainers] Autoconf 2.13 In-Reply-To: <4f5a2049.az/Osu6Zejg2IEiM%Joerg.Schilling@fokus.fraunhofer.de> References: <4f59f0a1.rUQSDTUOTaJtwcGa%Joerg.Schilling@fokus.fraunhofer.de> <1331302350-sup-1709@pinkfloyd.chass.utoronto.ca> <4f5a2049.az/Osu6Zejg2IEiM%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <1331990995-sup-582@pinkfloyd.chass.utoronto.ca> Excerpts from Joerg.Schilling's message of Fri Mar 09 10:22:49 -0500 2012: Hi J?rg, > A configure run on SunOS-4.x and other older systems for a medium > sized configurations typpically takes 4 hours. Is this not simply a product of old, small hardware? > The code for config.guess has been completely reordered so that it > is not possible to tell whether thare are bad changes inside (note > that I added and forwared many patches to support various additional > platforms). Interesting. That does seem to be a downside. > In general, the created shell codes is no longer portable and seems > to at least partially depend on bash bugs. I don't understand this. It runs in POSIX sh on any of the Solaris platforms I've tried (admittedly I'm not doing SunOS archaelogy). The core autoconf stuff is supposed to be fully portable. It's certainly possible for a project to directly include non-portable shell code (and I do see this from time to time), but the stuff generated from autoconf-delivered m4 has always been clean in my experience... > BTW: schily autoconf fully supports cross compilation (since > aprox. a year) and GNU autoconf still doesn't. Cool! Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Sat Mar 17 14:36:55 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 17 Mar 2012 09:36:55 -0400 Subject: [csw-maintainers] Inconsistency on package database In-Reply-To: <20120317092813.GA29664@quince.home.blizinski.pl> References: <1330091058-sup-811@pinkfloyd.chass.utoronto.ca> <1331771691-sup-4120@pinkfloyd.chass.utoronto.ca> <1331918003-sup-8437@pinkfloyd.chass.utoronto.ca> <1331945934-sup-6797@pinkfloyd.chass.utoronto.ca> <1331949772-sup-6101@pinkfloyd.chass.utoronto.ca> <20120317092813.GA29664@quince.home.blizinski.pl> Message-ID: <1331991359-sup-7212@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej Blizi?ski's message of Sat Mar 17 05:28:13 -0400 2012: > Ideally we would show the union of both, but there currently is no > loss in showing the x86 packages. Agreed. I'm going to wrap up the global atom feeds and then look at revamping our package browser. (Unless anyone else wants to jump on it first, that is.) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sat Mar 17 21:24:21 2012 From: maciej at opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?=) Date: Sat, 17 Mar 2012 20:24:21 +0000 Subject: [csw-maintainers] Killing the stable release In-Reply-To: References: <41A15E2D-E4AF-478F-8857-7EBF174A094D@opencsw.org> Message-ID: <20120317202421.GA6624@quince.home.blizinski.pl> Dagobert Michelsen wrote: > Am 15.03.2012 um 10:57 schrieb Peter Bonivart: > > 2012/3/15 Maciej (Matchek) Blizi?ski : > >> In the case of stable, there is not much breakage. Maybe the only > >> breakage would be when someone has a machine running stable, and they > >> want to install a new package that they haven't installed before. That > >> wouldn't work after the rename. They'd have to reconfigure > >> pkgutil.conf to point at stable-dead, that's all. > > > > Pkgutil will fail without "injury". I see two cases, you have an up to > > date catalog, then the actual file fetching will fail and pkgutil > > aborts. Otherwise, the catalog fetching will fail and pkgutil aborts. > > In both cases no changes are made to your system. > > I suggest having three extra file > 00PACKAGENOTFOUND > 00CATALOGNOTFOUND > 00MOTD Would that be in the catalog leve? E.g. unstable/sparc/5.10 Why have them split into separate files? This could be all folded into one record based file with a simple syntax. > If a package could not be found the first is tried to be download and > displayed. If it is not there nothing happens. If a catalog could not > be found the second is displayed. The third is tried and displayed on > every update (-U). I also thought that the message for package not found could vary depending on the package. For example, a note for a removed package could be added. From maciej at opencsw.org Sun Mar 18 08:47:12 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 18 Mar 2012 07:47:12 +0000 Subject: [csw-maintainers] Processing csw.conf Message-ID: What's the best way to process the csw.conf file? I looked into pkg/cswclassutils/trunk/files/CSWcswclassutils.i.cswinitsmf and slow this: # Source csw.conf, if it exists if [ -f $PKG_INSTALL_ROOT/opt/csw/etc/csw.conf ] ; then . $PKG_INSTALL_ROOT/opt/csw/etc/csw.conf fi if [ -f $PKG_INSTALL_ROOT/etc/opt/csw/csw.conf ] ; then . $PKG_INSTALL_ROOT/etc/opt/csw/csw.conf fi (...) # Determine if service should be started or not daemon=yes if [ "$autoenable_daemons" = "no" ]; then daemon=no fi eval autoenable_service="\$autoenable_$service" if [ "$autoenable_service" = "no" ]; then daemon=no elif [ "$autoenable_service" = "yes" ]; then daemon=yes fi Is the idea that each and every postinstall script that needs to determine the settings, must on their own figure out: - the location of the file - how to read the file (source or parse) - how to extract specific variables I thought we had some kind of a library that solves this once for good. Do we have anything like it? (more context: https://www.opencsw.org/mantis/view.php?id=4409) Maciej From bonivart at opencsw.org Sun Mar 18 09:00:20 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 18 Mar 2012 09:00:20 +0100 Subject: [csw-maintainers] Processing csw.conf In-Reply-To: References: Message-ID: 2012/3/18 Maciej (Matchek) Blizi?ski : > What's the best way to process the csw.conf file? > > I looked into pkg/cswclassutils/trunk/files/CSWcswclassutils.i.cswinitsmf > and slow this: > > # Source csw.conf, if it exists > if [ -f $PKG_INSTALL_ROOT/opt/csw/etc/csw.conf ] ; then > ?. $PKG_INSTALL_ROOT/opt/csw/etc/csw.conf > fi > if [ -f $PKG_INSTALL_ROOT/etc/opt/csw/csw.conf ] ; then > ?. $PKG_INSTALL_ROOT/etc/opt/csw/csw.conf > fi > (...) > ?# Determine if service should be started or not > ?daemon=yes > ?if [ "$autoenable_daemons" = "no" ]; then > ? ?daemon=no > ?fi > ?eval autoenable_service="\$autoenable_$service" > ?if [ "$autoenable_service" = "no" ]; then > ? ?daemon=no > ?elif [ "$autoenable_service" = "yes" ]; then > ? ?daemon=yes > ?fi > > Is the idea that each and every postinstall script that needs to > determine the settings, must on their own figure out: > > - the location of the file > - how to read the file (source or parse) > - how to extract specific variables > > I thought we had some kind of a library that solves this once for > good. Do we have anything like it? > > (more context: https://www.opencsw.org/mantis/view.php?id=4409) How csw.conf should be processed was documented clearly on the old web site, maybe it got lost on the new one? We had a dedicated page for that. Regarding the bug mentioned, just remove the disable command in syslog-ng like Sebastian said. I don't think there's a need to act smart here, we should never touch Solaris stuff. From maciej at opencsw.org Sun Mar 18 11:15:33 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 18 Mar 2012 10:15:33 +0000 Subject: [csw-maintainers] Processing csw.conf In-Reply-To: References: Message-ID: No dia 18 de Mar?o de 2012 08:00, Peter Bonivart escreveu: > How csw.conf should be processed was documented clearly on the old web > site, maybe it got lost on the new one? We had a dedicated page for > that. The archived version is here: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/opencsw-manual/trunk/files/archive.txt It suggests copy/pasting the if/then code. > Regarding the bug mentioned, just remove the disable command in > syslog-ng like Sebastian said. I don't think there's a need to act > smart here, we should never touch Solaris stuff. OK. From ihsan at opencsw.org Sun Mar 18 14:15:41 2012 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Sun, 18 Mar 2012 14:15:41 +0100 Subject: [csw-maintainers] Killing the stable release In-Reply-To: <1331745920-sup-3791@pinkfloyd.chass.utoronto.ca> References: <1331745920-sup-3791@pinkfloyd.chass.utoronto.ca> Message-ID: <4F65DFFD.2010403@opencsw.org> Am 14.03.2012 18:30, schrieb Ben Walton: >>> Thoughts? >> +1 > > +1 from me too. +1 -- ihsan at dogan.ch http://blog.dogan.ch/ From james at opencsw.org Sun Mar 18 14:17:06 2012 From: james at opencsw.org (James Lee) Date: Sun, 18 Mar 2012 13:17:06 GMT Subject: [csw-maintainers] Solaris Studio vs GCC In-Reply-To: References: Message-ID: <20120318.13170600.3130832762@gyor.oxdrove.co.uk> On 11/03/12, 17:58:10, =?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?= wrote regarding [csw-maintainers] Solaris Studio vs GCC: > I recently spent some time building a couple of libraries with GCC, in > the /opt/csw/gxx prefix. I was surprised how easy that was. Yes, there > were some issues, but most of them because of stupid hardcoded stuff > of the type of "you're on Solaris so you must be compiling with > something else", and removing Solaris-specific #define bits made > problems go away. I managed to build Boost 1.49.0 with GCC, but not > with Solaris Studio - I got about a screenful of templating errors. > When interacting with upstreams, using Studio often gets in the way. I > often get responses that if I'm building with Studio, I'm on my own as > far building is concerned. Overall, using it seems to add workload > rather than removing it. > If we plan on keeping on being standardized on Solaris Studio, we > should have some kind of rationale written up. If it is about > performance, we should have some numbers put out to show how big the > benefit is. If it is about helpful error messages, we should have an > example or two out. Whatever the reason is, some kind of example > should be put up on one of our web sites. > Thoughts? This only matters for C++ linking due differing schemes for name mangling otherwise we can freely move between cc and gcc - and there's the rub. It's not about the compiler as such, it's what the question reveals about openness and freedom. The joke goes "How many Microsoft engineers does it take to change a light bulb? None, Bill Gates declares darkness the standard." This can just as easily be applied to GNU, "How many programmers does it take to debug GNU software? None, Richard Stallman declares the software the reference implementation." GNU system was developed to be 100% free software, free in the sense that it respects the user's freedom. This includes users exercising the freedom to not use gcc. As most of the projects causing problems are run by people with a quasi-religious fanaticism to openness and freedom the best hope in effecting change to the upstream software is to play on this and point out that software that is locked in to one compiler or system is not open and contravenes their own beliefs. >From practical point I always welcomed the feedback by compiling on more than one system. This improved my code. My work on free software is motivated by an idealistic goal: spreading freedom and cooperation. I want to encourage free software to spread, replacing proprietary software that forbids cooperation, and thus make our society better. *Also* using cc contributes to software by excluding any particular compiler's quirks and extensions thus ensuring software's freedom and increasing cooperation. If neither improving code nor playing to irrational beliefs work try: CC -compat=g ... Now see which system is cooperative. Only for x86, I can't see why but there it is. James. From james at opencsw.org Sun Mar 18 14:17:08 2012 From: james at opencsw.org (James Lee) Date: Sun, 18 Mar 2012 13:17:08 GMT Subject: [csw-maintainers] Solaris Studio vs GCC In-Reply-To: References: <1331505713-sup-655@pinkfloyd.chass.utoronto.ca> Message-ID: <20120318.13170800.4044152606@gyor.oxdrove.co.uk> On 11/03/12, 23:21:30, Peter Bonivart wrote regarding Re: [csw-maintainers] Solaris Studio vs GCC: > On Sun, Mar 11, 2012 at 11:48 PM, Ben Walton wrote: > > I understand that performance of the binaries generated by studio used > > to be superior, but I don't know if that's still the case. ?Aside from > > this (possible) win for studio, what are some of the other reasons > > we've traditionally preferred it to gcc? > I'd like to switch the _default_ compiler only. :) > Today quite some packages are built with gcc anyway due to being too > hard to build with Studio. If someone feels that Studio will give them > faster binaries they can still use it. I would like to see some actual > numbers though for the sake of the discussion. James Lee used to > provide some back in the day. Some of this is historic, at one time gcc was faster than cc but that was when gcc was 2.3 and cc was the one bundled with SunOS4. Some of gcc's poor reputation comes from the lacking of 64bit support; using the AMD64 instructions really helps. This doesn't apply any more and I tried a like-for-like speed test with a newer gcc however gcc failed to compile my test code and I didn't waste time on the causes. The latest speed evidence I have is that my results using cc and Solaris beat other people's using gcc and either of Linux or MacOSX. There are 3 differences so we can't tell if it's the compiler, nevertheless my cc results are faster. I'm using a highly repetitive floating point test. This matters because it's the type of program that runs for a long time hence worth saving even a tiny amount of time however I'm not the mode user and there is no need to speed up things that aren't slow which brings me to a second conclusion: most of the time it is not important which compiler creates the faster code. You are free to compile twice and obtain your own results relevant to your own needs. James. From bonivart at opencsw.org Sun Mar 18 15:30:42 2012 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 18 Mar 2012 15:30:42 +0100 Subject: [csw-maintainers] Solaris Studio vs GCC In-Reply-To: <20120318.13170600.3130832762@gyor.oxdrove.co.uk> References: <20120318.13170600.3130832762@gyor.oxdrove.co.uk> Message-ID: Great to hear from you again James. On Sun, Mar 18, 2012 at 2:17 PM, James Lee wrote: > *Also* using cc contributes to software by excluding any particular > compiler's quirks and extensions thus ensuring software's freedom and > increasing cooperation. So we should make it harder on ourselves for the greater good? Isn't that what we're already doing by using Solaris in a world of Linux? How much self-inflicted pain is enough? If we consider lowering the bar we may get more active maintainers which is critical to _this_ project. /peter From maciej at opencsw.org Sun Mar 18 16:41:35 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 18 Mar 2012 15:41:35 +0000 Subject: [csw-maintainers] Tiers and metadata support progress Message-ID: I've spent some time developing the next version of pkgdb, checkpkg and the surrounding tools. There are two relatively large subjects I'm dealing with: 1. More metadata in MySQL tables, allowing checkpkg to look into things like e.g. two packages shipping the same directory with two different ownership/permission settings. 2. Tiers support I'll bundle up both updates into one rollout. It'll be a major one, involving a complete rebuild of the buildfarm database. I could try to update the current database, but I want this process to be reproducible in case we want to build a new buildfarm, or someone else wants do to so (Peter Felecan comes to mind). If anyone is even remotely interested in how all this works, I encourage you to look at my work in progress. http://codereview.appspot.com/5730057/ It can be helpful to look at the tests, too. They are nice in that they show one aspect of the code. For example, the new test in the following file tests a function which consumes data coming from filesystem indexing and produces fake package representations. http://codereview.appspot.com/5730057/diff/2001/gar/v2/lib/python/system_pkgmap_test.py I'll be happy to answer any questions about the code. Maciej From maciej at opencsw.org Sun Mar 18 20:19:17 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 18 Mar 2012 19:19:17 +0000 Subject: [csw-maintainers] Wintercamp 2011 In-Reply-To: References: <4F169DE1.10904@lutter.sk> Message-ID: No dia 4 de Mar?o de 2012 00:36, Maciej (Matchek) Blizi?ski escreveu: > I've booked my flights. I'm arriving on Friday morning and leaving > Monday early morning. > > Where do we stay in Bratislava? Do you have any hotel recommendations? Ping? I want to book this. From grzemba at contac-dt.de Mon Mar 19 09:28:10 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Mon, 19 Mar 2012 09:28:10 +0100 Subject: [csw-maintainers] Fwd: CSW outstanding bugs Message-ID: <7490a2517433.4f66fc2a@contac-dt.de> Hi, https://www.opencsw.org/mantis/view.php?id=4649 the problems till exist: bash-3.00# pkgchk CSWcupsd ERROR: /etc/opt/csw/cups ??? group name expected actual ERROR: /etc/opt/csw/cups/ppd ??? group name expected actual ERROR: /etc/opt/csw/cups/ssl ??? permissions <0755> expected <0700> actual ??? group name expected actual ERROR: /var/opt/csw/cache/cups ??? permissions <0755> expected <0775> actual ERROR: /var/opt/csw/cache/cups/rss ??? permissions <0755> expected <0775> actual ERROR: /var/opt/csw/run/cups/certs ??? permissions <0755> expected <0511> actual ??? group name expected actual ??? owner name expected actual ERROR: /var/opt/csw/spool/cups ??? permissions <0755> expected <0710> actual ERROR: /var/opt/csw/spool/cups/tmp ??? permissions <0755> expected <1770> actual How we want to handle this? -- Carsten Grzemba -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Mon Mar 19 09:56:42 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 19 Mar 2012 09:56:42 +0100 Subject: [csw-maintainers] Fwd: CSW outstanding bugs In-Reply-To: <7490a2517433.4f66fc2a@contac-dt.de> References: <7490a2517433.4f66fc2a@contac-dt.de> Message-ID: <76ED6E3F-FD9F-4B9E-8827-F8BFE04299E5@opencsw.org> Hi Carsten, Am 19.03.2012 um 09:28 schrieb Carsten Grzemba: > https://www.opencsw.org/mantis/view.php?id=4649 > > the problems till exist: > > bash-3.00# pkgchk CSWcupsd > ERROR: /etc/opt/csw/cups > group name expected actual > ERROR: /etc/opt/csw/cups/ppd > group name expected actual > ERROR: /etc/opt/csw/cups/ssl > permissions <0755> expected <0700> actual > group name expected actual > ERROR: /var/opt/csw/cache/cups > permissions <0755> expected <0775> actual > ERROR: /var/opt/csw/cache/cups/rss > permissions <0755> expected <0775> actual > ERROR: /var/opt/csw/run/cups/certs > permissions <0755> expected <0511> actual > group name expected actual > owner name expected actual > ERROR: /var/opt/csw/spool/cups > permissions <0755> expected <0710> actual > ERROR: /var/opt/csw/spool/cups/tmp > permissions <0755> expected <1770> actual > > How we want to handle this? I suggest reworking CSWfconfig to CSWfontconfig while fixing the cache location to /var/opt/csw/fontconfig/cache. 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 Mon Mar 19 10:15:47 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 19 Mar 2012 10:15:47 +0100 Subject: [csw-maintainers] Inconsistency on package database In-Reply-To: <20120317092813.GA29664@quince.home.blizinski.pl> References: <1330091058-sup-811@pinkfloyd.chass.utoronto.ca> <1331771691-sup-4120@pinkfloyd.chass.utoronto.ca> <1331918003-sup-8437@pinkfloyd.chass.utoronto.ca> <1331945934-sup-6797@pinkfloyd.chass.utoronto.ca> <1331949772-sup-6101@pinkfloyd.chass.utoronto.ca> <20120317092813.GA29664@quince.home.blizinski.pl> Message-ID: <5F2FB823-AC2F-4173-8D52-FB297659D081@opencsw.org> Hi Maciej, Am 17.03.2012 um 10:28 schrieb Maciej Blizi?ski: > Ben Walton wrote: >> Excerpts from Ben Walton's message of Fri Mar 16 21:00:38 -0400 2012: >> >>> This updated database is now live. I think I'm also going to switch >>> the default architecture for this purpose from sparc to i386 as >>> problem packages tend to be i386-only as opposed to sparc-only. >> >> After comparing unstable/10/sparc with unstable/10/i386, I've made the >> switch for both web and mantis db maintenance. > > Ideally we would show the union of both, but there currently is no loss > in showing the x86 packages. > > = x86 only = > > libhashkit1 > libmemcached > libmemcached8 > libmemcachedprotocol0 > libmemcachedutil2 > libquadmath0 > mongodb > > = sparc only = > > ncsa_mosaic Is there a reason why libmemcached and ncsa_mosaic are only for one ISA? > pm_dbd_sybase_ocs This is because I didn't have a 32 bit i386 Sybase version. 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 Mon Mar 19 10:18:29 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 19 Mar 2012 10:18:29 +0100 Subject: [csw-maintainers] Killing the stable release In-Reply-To: <20120317202421.GA6624@quince.home.blizinski.pl> References: <41A15E2D-E4AF-478F-8857-7EBF174A094D@opencsw.org> <20120317202421.GA6624@quince.home.blizinski.pl> Message-ID: <1164597C-ECF0-43CC-81C5-0652AD58A223@opencsw.org> Hi Maciej, Am 17.03.2012 um 21:24 schrieb Maciej Blizi?ski: > Dagobert Michelsen wrote: >> Am 15.03.2012 um 10:57 schrieb Peter Bonivart: >>> 2012/3/15 Maciej (Matchek) Blizi?ski : >>>> In the case of stable, there is not much breakage. Maybe the only >>>> breakage would be when someone has a machine running stable, and they >>>> want to install a new package that they haven't installed before. That >>>> wouldn't work after the rename. They'd have to reconfigure >>>> pkgutil.conf to point at stable-dead, that's all. >>> >>> Pkgutil will fail without "injury". I see two cases, you have an up to >>> date catalog, then the actual file fetching will fail and pkgutil >>> aborts. Otherwise, the catalog fetching will fail and pkgutil aborts. >>> In both cases no changes are made to your system. >> >> I suggest having three extra file >> 00PACKAGENOTFOUND >> 00CATALOGNOTFOUND >> 00MOTD > > Would that be in the catalog leve? E.g. unstable/sparc/5.10 Yes. > Why have them split into separate files? This could be all folded into > one record based file with a simple syntax. That would also be possible if necessary, but this was the simplest possible form also usable if someone browses a ftp share. >> If a package could not be found the first is tried to be download and >> displayed. If it is not there nothing happens. If a catalog could not >> be found the second is displayed. The third is tried and displayed on >> every update (-U). > > I also thought that the message for package not found could vary > depending on the package. For example, a note for a removed package > could be added. Yes, like .info containing stuff printed if the corresponding package could no be found. Good point. 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 Mon Mar 19 10:35:52 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 19 Mar 2012 10:35:52 +0100 Subject: [csw-maintainers] Solaris Studio vs GCC In-Reply-To: References: <20120318.13170600.3130832762@gyor.oxdrove.co.uk> Message-ID: Hi folks, Am 18.03.2012 um 15:30 schrieb Peter Bonivart: > Great to hear from you again James. > > On Sun, Mar 18, 2012 at 2:17 PM, James Lee wrote: >> *Also* using cc contributes to software by excluding any particular >> compiler's quirks and extensions thus ensuring software's freedom and >> increasing cooperation. > > So we should make it harder on ourselves for the greater good? Isn't > that what we're already doing by using Solaris in a world of Linux? > How much self-inflicted pain is enough? > > If we consider lowering the bar we may get more active maintainers > which is critical to _this_ project. Every maintainer can use gcc any time as he wants, by own preference or when problems occur. Having Sun Studio to aid porting is a good thing IMHO. Maybe we should refocus to bringing an environment to users where they can easily build their own modules for Perl and Ruby. 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 Mon Mar 19 10:37:44 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 19 Mar 2012 09:37:44 +0000 Subject: [csw-maintainers] Inconsistency on package database In-Reply-To: <5F2FB823-AC2F-4173-8D52-FB297659D081@opencsw.org> References: <1330091058-sup-811@pinkfloyd.chass.utoronto.ca> <1331771691-sup-4120@pinkfloyd.chass.utoronto.ca> <1331918003-sup-8437@pinkfloyd.chass.utoronto.ca> <1331945934-sup-6797@pinkfloyd.chass.utoronto.ca> <1331949772-sup-6101@pinkfloyd.chass.utoronto.ca> <20120317092813.GA29664@quince.home.blizinski.pl> <5F2FB823-AC2F-4173-8D52-FB297659D081@opencsw.org> Message-ID: No dia 19 de Mar?o de 2012 09:15, Dagobert Michelsen escreveu: >> = x86 only = >> >> libhashkit1 >> libmemcached >> libmemcached8 >> libmemcachedprotocol0 >> libmemcachedutil2 >> libquadmath0 >> mongodb >> >> = sparc only = >> >> ncsa_mosaic > > Is there a reason why libmemcached and ncsa_mosaic are only for one ISA? Not sure. I had it for both architectures. Maybe a failed push. I removed it, I'll rather keep it in my experimental, it's of little value in the catalog. I don't know about libmemchached. From Joerg.Schilling at fokus.fraunhofer.de Mon Mar 19 12:10:04 2012 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Mon, 19 Mar 2012 12:10:04 +0100 Subject: [csw-maintainers] Solaris Studio vs GCC In-Reply-To: <20120318.13170600.3130832762@gyor.oxdrove.co.uk> References: <20120318.13170600.3130832762@gyor.oxdrove.co.uk> Message-ID: <4f67140c.Nuem86fd4E3dXyig%Joerg.Schilling@fokus.fraunhofer.de> James Lee wrote: > > GNU system was developed to be 100% free software, free in the sense that > it respects the user's freedom. > > > This includes users exercising the freedom to not use gcc. As most of > the projects causing problems are run by people with a quasi-religious > fanaticism to openness and freedom the best hope in effecting change to > the upstream software is to play on this and point out that software > that is locked in to one compiler or system is not open and contravenes > their own beliefs. Well said! Unfortunately Sun did not publish cc as OSS even though the legal process was ready years ago. Did someone look for gcc alternatives? I am asking this as it may become important for compiling Schilix-ON in the future. 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 trygvis at opencsw.org Mon Mar 19 12:18:02 2012 From: trygvis at opencsw.org (trygvis at opencsw.org) Date: Mon, 19 Mar 2012 11:18:02 +0000 Subject: [csw-maintainers] Solaris Studio vs GCC In-Reply-To: <4f67140c.Nuem86fd4E3dXyig%Joerg.Schilling@fokus.fraunhofer.de> References: <20120318.13170600.3130832762@gyor.oxdrove.co.uk> <4f67140c.Nuem86fd4E3dXyig%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <000001362aad9bf0-8dfa1126-37b6-4e40-bfc9-ff10b9cf6af3-000000@email.amazonses.com> On Mon, Mar 19, 2012 at 12:10:04PM +0100, Joerg Schilling wrote: > James Lee wrote: > > > > > GNU system was developed to be 100% free software, free in the sense that > > it respects the user's freedom. > > > > > > This includes users exercising the freedom to not use gcc. As most of > > the projects causing problems are run by people with a quasi-religious > > fanaticism to openness and freedom the best hope in effecting change to > > the upstream software is to play on this and point out that software > > that is locked in to one compiler or system is not open and contravenes > > their own beliefs. > > Well said! > > Unfortunately Sun did not publish cc as OSS even though the legal process was > ready years ago. Did someone look for gcc alternatives? > > I am asking this as it may become important for compiling Schilix-ON in the > future. One alternative that I'm following (mainly for other reasons but still) is the generic compiler/virtual machine infrastructure LLVM and it's C frontend Clang. -- Trygve From bwalton at opencsw.org Tue Mar 20 02:39:33 2012 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 19 Mar 2012 21:39:33 -0400 Subject: [csw-maintainers] pine vs alpine In-Reply-To: <232A550E-8E52-47CC-A836-AF8F5918653B@opencsw.org> References: <1331861959-sup-2030@pinkfloyd.chass.utoronto.ca> <232A550E-8E52-47CC-A836-AF8F5918653B@opencsw.org> Message-ID: <1332207530-sup-7700@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Fri Mar 16 04:01:02 -0400 2012: > > I've detected a path conflict between pine and alpine. As alpine > > supercedes pine, I think we should just remove pine...maybe with a > > pine_stub to transition people. > > > > Any objections? > > No :-) Do you think it would be good to add a symlink of bin/pine to > alpine? I just pushed alpine-2.00,REV=2012.03.20 and pine_stub-2.00,REV=2012.03.20 to unstable. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Tue Mar 20 02:53:02 2012 From: bwalton at opencsw.org (Ben Walton) Date: Mon, 19 Mar 2012 21:53:02 -0400 Subject: [csw-maintainers] whole catalog feeds In-Reply-To: <921CBC4F-28EE-4499-8C41-ED7CA10E5C3B@opencsw.org> References: <1331599643-sup-3316@pinkfloyd.chass.utoronto.ca> <921CBC4F-28EE-4499-8C41-ED7CA10E5C3B@opencsw.org> Message-ID: <1332208179-sup-3602@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Tue Mar 13 10:19:05 -0400 2012: > > http://www.opencsw.org/catalogfeeds/feed.mirror.opencsw.org.opencsw.unstable.atom Ok, try: http://www.opencsw.org/catalogfeeds/feed.new.atom. I've collapsed the release info as suggested except in the case where only one arch (or some other non-uniform combination) is seen. Examples are: libpcre16_0_gxx -> Catalog info: Solaris 9+ sparc/i386 libsigc2_0_0_gxx -> Catalog info: Solaris 10+ sparc/i386 mongodb -> Catalog info: SunOS5.10: i386, SunOS5.11: i386 Take a look and let me know if other changes are desired/required. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Tue Mar 20 07:03:38 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 20 Mar 2012 07:03:38 +0100 Subject: [csw-maintainers] whole catalog feeds In-Reply-To: <1332208179-sup-3602@pinkfloyd.chass.utoronto.ca> References: <1331599643-sup-3316@pinkfloyd.chass.utoronto.ca> <921CBC4F-28EE-4499-8C41-ED7CA10E5C3B@opencsw.org> <1332208179-sup-3602@pinkfloyd.chass.utoronto.ca> Message-ID: Hi Ben, Am 20.03.2012 um 02:53 schrieb Ben Walton: > Excerpts from Dagobert Michelsen's message of Tue Mar 13 10:19:05 -0400 2012: > >>> http://www.opencsw.org/catalogfeeds/feed.mirror.opencsw.org.opencsw.unstable.atom > > Ok, try: http://www.opencsw.org/catalogfeeds/feed.new.atom. > > I've collapsed the release info as suggested except in the case where > only one arch (or some other non-uniform combination) is seen. > > Examples are: > > libpcre16_0_gxx -> Catalog info: Solaris 9+ sparc/i386 > libsigc2_0_0_gxx -> Catalog info: Solaris 10+ sparc/i386 > mongodb -> Catalog info: SunOS5.10: i386, SunOS5.11: i386 > > Take a look and let me know if other changes are desired/required. The first one looks like you described, but the second one looks a bit strange: > > Updated x264 snapshot_20120211_2245,REV=2012.02.16 > Jan Holzhueter > Heute, 2:45 > Updated package x264 snapshot_20120211_2245,REV=2012.02.16. > > Catalog info: Solaris 10+ sparc/i386 > > Updated ruby191 1.9.3,pp0,REV=2012.02.26 > Ben Walton > Heute, 2:45 > Updated package ruby191 1.9.3,pp0,REV=2012.02.26. > > Catalog info: SunOS5.10: sparc,i386 Is this intended? I like the first one better. Best regards -- Dago From maciej at opencsw.org Tue Mar 20 11:57:48 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 20 Mar 2012 10:57:48 +0000 Subject: [csw-maintainers] whole catalog feeds In-Reply-To: References: <1331599643-sup-3316@pinkfloyd.chass.utoronto.ca> <921CBC4F-28EE-4499-8C41-ED7CA10E5C3B@opencsw.org> <1332208179-sup-3602@pinkfloyd.chass.utoronto.ca> Message-ID: No dia 20 de Mar?o de 2012 06:03, Dagobert Michelsen escreveu: > > > Catalog info: SunOS5.10: sparc,i386 > > Is this intended? I like the first one better. You mean, "SunOS5.10" vs "Solaris 10"? For publishing purposes (as opposed to APIs) I also like the latter better. From bwalton at opencsw.org Tue Mar 20 12:03:09 2012 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 20 Mar 2012 07:03:09 -0400 Subject: [csw-maintainers] whole catalog feeds In-Reply-To: References: <1331599643-sup-3316@pinkfloyd.chass.utoronto.ca> <921CBC4F-28EE-4499-8C41-ED7CA10E5C3B@opencsw.org> <1332208179-sup-3602@pinkfloyd.chass.utoronto.ca> Message-ID: <2921048c-1c93-4df6-bc1b-2ae32f88b460@email.android.com> Yes, this is a bug. I'll fix it up shortly. Thanks -Ben "Maciej (Matchek) Blizi?ski" wrote: No dia 20 de Mar?o de 2012 06:03, Dagobert Michelsen escreveu: > > > Catalog info: SunOS5.10: sparc,i386 > > Is this intended? I like the first one better. You mean, "SunOS5.10" vs "Solaris 10"? For publishing purposes (as opposed to APIs) I also like the latter better. _____________________________________________ maintainers mailing list maintainers at lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::. -------------- next part -------------- An HTML attachment was scrubbed... URL: From grzemba at contac-dt.de Tue Mar 20 13:46:07 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Tue, 20 Mar 2012 13:46:07 +0100 Subject: [csw-maintainers] new evince version Message-ID: <73f0835a5c3a.4f688a1f@contac-dt.de> Hi, I test if we can get a newer version of evince 2.30.3. It looks good so far, but we need an newer version of libpoppler. We have 0.12.4. witch produce compile and/or link problems. Solaris 11 and openindiana use 0.14.4 for evince 2.30.3. the version 0.14.4 builds and has the missing labels but builds not on solaris9: Error: The function "strtok_r" must have a prototype Reverse dependencies for libpoppler beside evience are: - claws_pdfviewer(http://www.opencsw.org/packages/claws_pdfviewer) - poppler_data @Roger: Can we update libpoppler (without Solaris9)? Should we take into account the dependency of claws_pdfviewer? Regards -- Carsten -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Tue Mar 20 13:58:56 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 20 Mar 2012 13:58:56 +0100 Subject: [csw-maintainers] new evince version In-Reply-To: <73f0835a5c3a.4f688a1f@contac-dt.de> References: <73f0835a5c3a.4f688a1f@contac-dt.de> Message-ID: Hi Carsten, Am 20.03.2012 um 13:46 schrieb Carsten Grzemba: > I test if we can get a newer version of evince 2.30.3. It looks good so far, but we need an newer version of libpoppler. > We have 0.12.4. witch produce compile and/or link problems. > Solaris 11 and openindiana use 0.14.4 for evince 2.30.3. > the version 0.14.4 builds and has the missing labels but builds not on solaris9: > Error: The function "strtok_r" must have a prototype > > Reverse dependencies for libpoppler beside evience are: > - claws_pdfviewer > - poppler_data > > @Roger: Can we update libpoppler (without Solaris9)? > Should we take into account the dependency of claws_pdfviewer? Roger is on sabbatical. Feel free to take over the 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From igalic at opencsw.org Tue Mar 20 19:06:23 2012 From: igalic at opencsw.org (Igor =?utf-8?Q?Gali=C4=87?=) Date: Tue, 20 Mar 2012 18:06:23 -0000 (UTC) Subject: [csw-maintainers] v2-build64only In-Reply-To: <8C8EC04D-0C4B-4EF4-AE3B-D55AD1CA5DE9@opencsw.org> Message-ID: Hey folks, hey Dago. Maciej told me to specifically write *you* - but this might be interesting for more folks: Some software doesn't build or is otherwise unsuitable on 32bit hardware, so we build it 64bit only. GAR however will, right now, strip out all the silly stuff that would otherwise be duplicate: Configuration files, log directories, etc. These things are very useful, though, especially if there is no 32bit version of the package in question. What can we do to hint GAR that we'd like to keep those? And further down the line: What can we do to automate that step, so in the future it's just a switch in the Makefile? So long, i From dam at opencsw.org Tue Mar 20 19:21:52 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 20 Mar 2012 19:21:52 +0100 Subject: [csw-maintainers] v2-build64only In-Reply-To: References: Message-ID: Hi Igor, Am 20.03.2012 um 19:06 schrieb Igor Gali?: > Hey folks, hey Dago. > > Maciej told me to specifically write *you* - but this might > be interesting for more folks: > > Some software doesn't build or is otherwise unsuitable on > 32bit hardware, so we build it 64bit only. GAR however will, > right now, strip out all the silly stuff that would otherwise > be duplicate: Configuration files, log directories, etc. > These things are very useful, though, especially if there is > no 32bit version of the package in question. > > What can we do to hint GAR that we'd like to keep those? > And further down the line: What can we do to automate that > step, so in the future it's just a switch in the Makefile? Please do not use the v2-build64only branch as I already merged and enhanced the functionality in the main v2 branch. Do you still see this behaviour in v2 with BUILD64_ONLY? If yes I would consider this a bug as things other than in the MERGE_DIRS should be excluded for extra ISAs *only* if they are provided by the default ISA. Best regards -- Dago From igalic at opencsw.org Tue Mar 20 19:35:51 2012 From: igalic at opencsw.org (Igor =?utf-8?Q?Gali=C4=87?=) Date: Tue, 20 Mar 2012 18:35:51 -0000 (UTC) Subject: [csw-maintainers] v2-build64only In-Reply-To: <5c859f7d-4c90-4b23-a9fc-9707deed669c@iris> Message-ID: <1a404386-9487-4108-b260-96a8ee30e7d4@iris> ----- Original Message ----- > Hi Igor, > > Am 20.03.2012 um 19:06 schrieb Igor Gali?: > > Hey folks, hey Dago. > > > > Maciej told me to specifically write *you* - but this might > > be interesting for more folks: > > > > Some software doesn't build or is otherwise unsuitable on > > 32bit hardware, so we build it 64bit only. GAR however will, > > right now, strip out all the silly stuff that would otherwise > > be duplicate: Configuration files, log directories, etc. > > These things are very useful, though, especially if there is > > no 32bit version of the package in question. > > > > What can we do to hint GAR that we'd like to keep those? > > And further down the line: What can we do to automate that > > step, so in the future it's just a switch in the Makefile? > > Please do not use the v2-build64only branch as I already merged and > enhanced the functionality in the main v2 branch. Do you still see > this behaviour in v2 with BUILD64_ONLY? If yes I would consider this > a bug as things other than in the MERGE_DIRS should be excluded for > extra ISAs *only* if they are provided by the default ISA. Trying this now, also removing SKIP_MODULATIONS Will report back when it built. > Best regards > > -- Dago -- Igor Gali? Tel: +43 (0) 664 886 22 883 Mail: i.galic at brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE From igalic at opencsw.org Tue Mar 20 22:05:22 2012 From: igalic at opencsw.org (Igor =?utf-8?Q?Gali=C4=87?=) Date: Tue, 20 Mar 2012 21:05:22 -0000 (UTC) Subject: [csw-maintainers] v2-build64only In-Reply-To: <1a404386-9487-4108-b260-96a8ee30e7d4@iris> Message-ID: Hey folks, hey Dago > > Please do not use the v2-build64only branch as I already merged and > > enhanced the functionality in the main v2 branch. Do you still see > > this behaviour in v2 with BUILD64_ONLY? If yes I would consider > > this > > a bug as things other than in the MERGE_DIRS should be excluded for > > extra ISAs *only* if they are provided by the default ISA. > > Trying this now, also removing SKIP_MODULATIONS > > Will report back when it built. BUILD64_ONLY = 1 indeed builds 64bit only, SKIP_MODULATIIONS is not needed. However it completely ignores all files that lie outside of $bindir, $libdir and $libexec, unless I add them via MERGE_EXTRA_DIRS Now the problem with this is that it completely ignores this part: CLASSES = none cswpreserveconf PROTOTYPE_MODIFIERS = config data PROTOTYPE_FILES_config = $(sysconfdir) PRESERVECONF = $(PROTOTYPE_FILES_config) PROTOTYPE_CLASS_config = cswpreserveconf PROTOTYPE_USER_config = nobody PROTOTYPE_GROUP_config = $(shell id -ng nobody) PROTOTYPE_FILES_data = $(datadir) PROTOTYPE_USER_data = nobody PROTOTYPE_GROUP_data = $(shell id -ng nobody) So the files are a) class none, and b) belong to root:bin > > Best regards > > > > -- Dago > So long, i -- Igor Gali? Tel: +43 (0) 664 886 22 883 Mail: i.galic at brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE From bondarenko.av at mmk.ru Wed Mar 21 04:01:54 2012 From: bondarenko.av at mmk.ru (=?koi8-r?B?4s/OxMHSxc7LzyDhzsTSxcog98nUwczYxdfJ3g==?=) Date: Wed, 21 Mar 2012 09:01:54 +0600 Subject: [csw-maintainers] gar.lib.mk default for PATCHDIR Message-ID: <8F048E189BF2D84C8F2604829BFC4C8AC6E1C2CE68@MSE-CCR-MB2.hq.corp.mmk.chel.su> Hi all, File gar.lib.mk as of revision 17456 has following definition for PATCHDIR PATCHDIR ?= $(WORKDIR)/$(DISTNAME) Is it ok? I see "gpatch: **** Can't change to directory" error messages if WORKSRC is changed from default. May be it should be: PATCHDIR ?= $(WORKSRC) Best regards, Andrey Bondarenko -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Wed Mar 21 11:35:38 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 21 Mar 2012 11:35:38 +0100 Subject: [csw-maintainers] v2-build64only In-Reply-To: References: Message-ID: Hi Igor, Am 20.03.2012 um 22:05 schrieb Igor Gali?: >>> Please do not use the v2-build64only branch as I already merged and >>> enhanced the functionality in the main v2 branch. Do you still see >>> this behaviour in v2 with BUILD64_ONLY? If yes I would consider >>> this >>> a bug as things other than in the MERGE_DIRS should be excluded for >>> extra ISAs *only* if they are provided by the default ISA. >> >> Trying this now, also removing SKIP_MODULATIONS >> >> Will report back when it built. > > BUILD64_ONLY = 1 indeed builds 64bit only, SKIP_MODULATIIONS is not > needed. However it completely ignores all files that lie outside of > $bindir, $libdir and $libexec, unless I add them via MERGE_EXTRA_DIRS This should be fixed now with r17487. > Now the problem with this is that it completely ignores this part: > > CLASSES = none cswpreserveconf Please do not tinker with CLASSES, this is always set correctly automatically. (and it is named SPKG_CLASSES btw.) In this next block there are numerous problems: > PROTOTYPE_MODIFIERS = config data I suggest using PROTOYPE_MODIFIERS += config and blocking them together with the specifications. This way it is easy and straight forward to add/remove whole blocks. I updated the documentation to make this clearer: https://sourceforge.net/apps/trac/gar/wiki/Prototypes > PROTOTYPE_FILES_config = $(sysconfdir) This is a regex and now matches the directory only, otherwise use PROTOTYPE_FILES_config += $(sysconfdir)/.* IIRC you can only use direct files here, like PRESERVECONF = $(sysconfdir)/myconf > PROTOTYPE_CLASS_config = cswpreserveconf This is automatically set when using PRESERVECONF. > PROTOTYPE_USER_config = nobody > PROTOTYPE_GROUP_config = $(shell id -ng nobody) Why don't you use just "nobody" ? > PROTOTYPE_FILES_data = $(datadir) Same regex as above. $(datadir) is /opt/csw/share btw. https://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/gar.conf.mk#L132 > PROTOTYPE_USER_data = nobody > PROTOTYPE_GROUP_data = $(shell id -ng nobody) > > So the files are a) class none, and b) belong to root:bin After all I suggest changing this to PRESERVECONF += $(sysconfdir)/myconf PROTOTYPE_MODIFIERS += data PROTOTYPE_FILES_data += $(datarootdir)/.* PROTOTYPE_USER_data = nobody PROTOYPE_GROUP_data = nobody Best regards -- Dago From dam at opencsw.org Wed Mar 21 13:46:50 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 21 Mar 2012 13:46:50 +0100 Subject: [csw-maintainers] gar.lib.mk default for PATCHDIR In-Reply-To: <8F048E189BF2D84C8F2604829BFC4C8AC6E1C2CE68@MSE-CCR-MB2.hq.corp.mmk.chel.su> References: <8F048E189BF2D84C8F2604829BFC4C8AC6E1C2CE68@MSE-CCR-MB2.hq.corp.mmk.chel.su> Message-ID: Hi Andrey, Am 21.03.2012 um 04:01 schrieb ?????????? ?????? ??????????: > File gar.lib.mk as of revision 17456 has following definition for PATCHDIR > > PATCHDIR ?= $(WORKDIR)/$(DISTNAME) > > Is it ok? I see ?gpatch: **** Can't change to directory? error messages if WORKSRC is changed from default. May be it should be: > > PATCHDIR ?= $(WORKSRC) No, it is intended this way. The rationale goes like this: - Upstream packages stuff which is unpacked to $(WORKDIR) in the directory $(DISTNAME) - The stuff to build is in $(WORKSRC) which defaults to $(WORKDIR)/$(DISTNAME), but may be a subdirectory like $(WORKDIR)/$(DISTNAME)/unix - If you work on patches you will most certainly do so for the whole package in $(PATCHDIR), even if you have modified $(WORKSRC) This also means that you need to adjust $(DISTNAME) even if you have adjusted $(WORKSRC). Additionally, it is recommended to also use $(DISTNAME) in $(DISTFILES). Also $(WORKDIR)/$(DISTNAME) is used to find the file $(LICENSE). Best regards -- Dago From igalic at opencsw.org Wed Mar 21 14:13:04 2012 From: igalic at opencsw.org (Igor =?utf-8?Q?Gali=C4=87?=) Date: Wed, 21 Mar 2012 13:13:04 -0000 (UTC) Subject: [csw-maintainers] v2-build64only In-Reply-To: Message-ID: <2750771c-a108-4efc-8438-a76e7f6f618c@iris> ----- Original Message ----- > Hi Igor, > > Am 20.03.2012 um 22:05 schrieb Igor Gali?: > >>> Please do not use the v2-build64only branch as I already merged > >>> and > >>> enhanced the functionality in the main v2 branch. Do you still > >>> see > >>> this behaviour in v2 with BUILD64_ONLY? If yes I would consider > >>> this > >>> a bug as things other than in the MERGE_DIRS should be excluded > >>> for > >>> extra ISAs *only* if they are provided by the default ISA. > >> > >> Trying this now, also removing SKIP_MODULATIONS > >> > >> Will report back when it built. > > > > BUILD64_ONLY = 1 indeed builds 64bit only, SKIP_MODULATIIONS is not > > needed. However it completely ignores all files that lie outside of > > $bindir, $libdir and $libexec, unless I add them via > > MERGE_EXTRA_DIRS > > This should be fixed now with r17487. > > > Now the problem with this is that it completely ignores this part: > > > > CLASSES = none cswpreserveconf > > Please do not tinker with CLASSES, this is always set correctly > automatically. > (and it is named SPKG_CLASSES btw.) > > In this next block there are numerous problems: > > > PROTOTYPE_MODIFIERS = config data > > I suggest using PROTOYPE_MODIFIERS += config and blocking them > together with > the specifications. This way it is easy and straight forward to > add/remove > whole blocks. I updated the documentation to make this clearer: > https://sourceforge.net/apps/trac/gar/wiki/Prototypes > > > PROTOTYPE_FILES_config = $(sysconfdir) > > This is a regex and now matches the directory only, otherwise use > PROTOTYPE_FILES_config += $(sysconfdir)/.* > > IIRC you can only use direct files here, like > PRESERVECONF = $(sysconfdir)/myconf > > > PROTOTYPE_CLASS_config = cswpreserveconf > > This is automatically set when using PRESERVECONF. > > > PROTOTYPE_USER_config = nobody > > PROTOTYPE_GROUP_config = $(shell id -ng nobody) > > Why don't you use just "nobody" ? Because nobody's group isn't always nobody, sometimes it's nogroup > > PROTOTYPE_FILES_data = $(datadir) > > Same regex as above. $(datadir) is /opt/csw/share btw. > https://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/gar.conf.mk#L132 ACK! > > PROTOTYPE_USER_data = nobody > > PROTOTYPE_GROUP_data = $(shell id -ng nobody) > > > > So the files are a) class none, and b) belong to root:bin > > After all I suggest changing this to > > PRESERVECONF += $(sysconfdir)/myconf This won't work, since the files are.. 3209 at a rough estimate. So I'll just.. *not* preserve the config. > PROTOTYPE_MODIFIERS += data > PROTOTYPE_FILES_data += $(datarootdir)/.* > PROTOTYPE_USER_data = nobody > PROTOYPE_GROUP_data = nobody Even so, /etc/opt/csw/trafficserver and /var/opt/csw/.*?/?trafficserver do not belong to nobody (according to work/solaris10-i386/build-global/prototype) But it's great progress, because it does the right thing now! The righter thing. ;) > Best regards > > -- Dago So long, i From bwalton at opencsw.org Thu Mar 22 02:07:24 2012 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 21 Mar 2012 21:07:24 -0400 Subject: [csw-maintainers] whole catalog feeds In-Reply-To: References: <1331599643-sup-3316@pinkfloyd.chass.utoronto.ca> <921CBC4F-28EE-4499-8C41-ED7CA10E5C3B@opencsw.org> <1332208179-sup-3602@pinkfloyd.chass.utoronto.ca> Message-ID: <1332378266-sup-6480@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Tue Mar 20 02:03:38 -0400 2012: > > Ok, try: http://www.opencsw.org/catalogfeeds/feed.new.atom. I've corrected the SunOS display glitch and a few other display bugs I found while poking around. For packages that are only released/updated for a single architecture, the display notes things like: Solaris 10 i386, Solaris 11 i386. I didn't collapse this down. I will if people prefer it, but I thought it was nicer to be explicit in this case. I simplified the article titles so they don't include the version number, and added package name in addition to catalog name in the article body. How does it look now? Any other bugs or requested changes? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From grzemba at contac-dt.de Thu Mar 22 16:46:58 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Thu, 22 Mar 2012 16:46:58 +0100 Subject: [csw-maintainers] shoud STRIP_LIBTOOL = 1 solve the problem? Message-ID: <73f0949954ce.4f6b5782@contac-dt.de> Hi, I have the following linking problem: ? CCLD?? libevince-properties-page.la /opt/csw/gnu/grep: /opt/csw/lib/libgtk-x11-2.0.la: No such file or directory /opt/csw/gnu/sed: can't read /opt/csw/lib/libgtk-x11-2.0.la: No such file or directory libtool: link: `/opt/csw/lib/libgtk-x11-2.0.la' is not a valid libtool archive gmake[2]: *** [libevince-properties-page.la] Error 1 gmake[2]: Leaving directory `/home/cgrzemba/opencsw/evince/trunk/work/build-ISA-sparcv8plus/evince-2.30.3/properties' gmake[1]: *** [all-recursive] Error 1 STRIP_LIBTOOL = 1 is already set but the .la files are still used. Any ideas? -- 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 bwalton at opencsw.org Thu Mar 22 16:50:08 2012 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 22 Mar 2012 11:50:08 -0400 Subject: [csw-maintainers] shoud STRIP_LIBTOOL = 1 solve the problem? In-Reply-To: <73f0949954ce.4f6b5782@contac-dt.de> References: <73f0949954ce.4f6b5782@contac-dt.de> Message-ID: <1332431360-sup-1031@pinkfloyd.chass.utoronto.ca> Excerpts from Carsten Grzemba's message of Thu Mar 22 11:46:58 -0400 2012: Hi Carsten, > STRIP_LIBTOOL = 1 > > is already set but the .la files are still used. Strip libtool 'fixes' libtool in many cases but doesn't preclude it from being used entirely. In your case it looks as though a .la file you're relying on isn't playing nicely. As it's outside of the control of your package, you should see about fixing it in the package that owns it. Looking to see what's wrong with it first might save some time. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From wilbury at opencsw.org Thu Mar 22 22:08:43 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Thu, 22 Mar 2012 22:08:43 +0100 Subject: [csw-maintainers] boost update Message-ID: <4F6B94DB.7000908@opencsw.org> Please, will someone update Boost libraries on unstable* boxes? Thanks. -- Juraj Lutter From maciej at opencsw.org Thu Mar 22 22:35:11 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 22 Mar 2012 22:35:11 +0100 Subject: [csw-maintainers] boost update In-Reply-To: <4F6B94DB.7000908@opencsw.org> References: <4F6B94DB.7000908@opencsw.org> Message-ID: There is Boost 1.49.0 installed already, isn't it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilbury at opencsw.org Thu Mar 22 22:39:15 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Thu, 22 Mar 2012 22:39:15 +0100 Subject: [csw-maintainers] boost update In-Reply-To: References: <4F6B94DB.7000908@opencsw.org> Message-ID: <4F6B9C03.9070707@opencsw.org> On 03/22/2012 10:35 PM, Maciej (Matchek) Blizi?ski wrote: > There is Boost 1.49.0 installed already, isn't it? Boost libraries are reporting 1_33_1 #define BOOST_LIB_VERSION "1_33_1" -- Juraj Lutter From maciej at opencsw.org Thu Mar 22 22:50:21 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 22 Mar 2012 22:50:21 +0100 Subject: [csw-maintainers] boost update In-Reply-To: <4F6B9C03.9070707@opencsw.org> References: <4F6B94DB.7000908@opencsw.org> <4F6B9C03.9070707@opencsw.org> Message-ID: That's the studio boost. If you examine installed packages, you will see the new gcc boost too. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilbury at opencsw.org Thu Mar 22 23:12:55 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Thu, 22 Mar 2012 23:12:55 +0100 Subject: [csw-maintainers] boost update In-Reply-To: References: <4F6B94DB.7000908@opencsw.org> <4F6B9C03.9070707@opencsw.org> Message-ID: <4F6BA3E7.5080803@opencsw.org> On 03/22/2012 10:50 PM, Maciej (Matchek) Blizi?ski wrote: > That's the studio boost. If you examine installed packages, you will see > the new gcc boost too. configure:16104: checking for the Boost program_options library configure:16146: /opt/csw/bin/g++-4.6 -c -O2 -pipe -mcpu=v8 -mv8plus -Wall -O2 -I/opt/csw/include -I/opt/csw/gxx/include conftest.cpp >&5 {standard input}: Assembler messages: {standard input}:75: Error: Architecture mismatch on "cas". {standard input}:75: (Requires v9|v9a|v9b; requested architecture is v8.) How to get rid of this? -- Juraj Lutter From grzemba at contac-dt.de Fri Mar 23 08:12:32 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Fri, 23 Mar 2012 08:12:32 +0100 Subject: [csw-maintainers] shoud STRIP_LIBTOOL = 1 solve the problem? In-Reply-To: <7490f47f1e96.4f6c2239@contac-dt.de> References: <7490f47f1e96.4f6c2239@contac-dt.de> Message-ID: <7490b7235379.4f6c3070@contac-dt.de> curiously it works (no problem) on the second run. I will observe the problem. Thanks Carsten Am 22.03.12, schrieb Ben Walton : > Excerpts from Carsten Grzemba's message of Thu Mar 22 11:46:58 -0400 2012: > > Hi Carsten, > > > STRIP_LIBTOOL = 1 > > > > is already set but the .la files are still used. > > Strip libtool 'fixes' libtool in many cases but doesn't preclude it > from being used entirely.? In your case it looks as though a .la file > you're relying on isn't playing nicely.? As it's outside of the > control of your package, you should see about fixing it in the package > that owns it.? Looking to see what's wrong with it first might save > some time. > > Thanks > -Ben > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilbury at opencsw.org Fri Mar 23 15:00:46 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Fri, 23 Mar 2012 15:00:46 +0100 Subject: [csw-maintainers] boost update In-Reply-To: <4F6BA3E7.5080803@opencsw.org> References: <4F6B94DB.7000908@opencsw.org> <4F6B9C03.9070707@opencsw.org> <4F6BA3E7.5080803@opencsw.org> Message-ID: <4F6C820E.80704@opencsw.org> "mgar spotless" helped. On 03/22/2012 11:12 PM, Juraj Lutter wrote: > On 03/22/2012 10:50 PM, Maciej (Matchek) Blizi?ski wrote: >> That's the studio boost. If you examine installed packages, you will see >> the new gcc boost too. > > > configure:16104: checking for the Boost program_options library > configure:16146: /opt/csw/bin/g++-4.6 -c -O2 -pipe -mcpu=v8 -mv8plus > -Wall -O2 -I/opt/csw/include -I/opt/csw/gxx/include conftest.cpp >&5 > {standard input}: Assembler messages: > {standard input}:75: Error: Architecture mismatch on "cas". > {standard input}:75: (Requires v9|v9a|v9b; requested architecture is v8.) > > How to get rid of this? > > > -- Juraj Lutter From wilbury at opencsw.org Fri Mar 23 15:47:34 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Fri, 23 Mar 2012 15:47:34 +0100 Subject: [csw-maintainers] broken BOOST Message-ID: <4F6C8D06.3080700@opencsw.org> Hi, while compiling PowerDNS (a Boost program) I am getting following error: configure:16203: /opt/csw/bin/g++-4.6 -o conftest -m64 -Wall -O2 -I/opt/csw/include -I/opt/csw/gxx/include -m64 -L/opt/gxx/lib -L/opt/csw/gxx/lib conftest.o -lboost_program_options >&5 Undefined first referenced symbol in file _ZN5boost15program_options19options_description21m_default_line_lengthE conftest.o _ZN5boost15program_options19options_descriptionC1ERKSsjj conftest.o ld: fatal: Symbol referencing errors. No output written to conftest configure:16212: $? = 1 Can please someone (Maciej?) have a look at BOOST recompilation using recent GCC? Thanks. -- Juraj Lutter From wilbury at opencsw.org Fri Mar 23 17:12:29 2012 From: wilbury at opencsw.org (Juraj Lutter) Date: Fri, 23 Mar 2012 17:12:29 +0100 Subject: [csw-maintainers] broken BOOST In-Reply-To: <4F6C8D06.3080700@opencsw.org> References: <4F6C8D06.3080700@opencsw.org> Message-ID: <4F6CA0ED.1080408@opencsw.org> On 03/23/2012 03:47 PM, Juraj Lutter wrote: > Hi, > > while compiling PowerDNS (a Boost program) I am getting following error: Problem seems to be: https://svn.boost.org/trac/boost/ticket/1904 -- Juraj Lutter From bwalton at opencsw.org Fri Mar 23 18:13:14 2012 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 23 Mar 2012 13:13:14 -0400 Subject: [csw-maintainers] broken BOOST In-Reply-To: <4F6CA0ED.1080408@opencsw.org> References: <4F6C8D06.3080700@opencsw.org> <4F6CA0ED.1080408@opencsw.org> Message-ID: <1332522759-sup-1793@pinkfloyd.chass.utoronto.ca> Excerpts from Juraj Lutter's message of Fri Mar 23 12:12:29 -0400 2012: > Problem seems to be: > https://svn.boost.org/trac/boost/ticket/1904 This would suggest that our boost needs a patch then, I guess...until it's fixed upstream, anyway. Did you want to validate this on a testing* box? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sat Mar 24 11:33:53 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 24 Mar 2012 11:33:53 +0100 Subject: [csw-maintainers] broken BOOST In-Reply-To: <4F6C8D06.3080700@opencsw.org> References: <4F6C8D06.3080700@opencsw.org> Message-ID: You included /opt/csw/include first (result: old boost headers) and used -L/opt/csw/gxx/lib first (result: new boost libs). You need to decide which you are using, you cannot mix old and new. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Sat Mar 24 18:46:39 2012 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 24 Mar 2012 13:46:39 -0400 Subject: [csw-maintainers] whole catalog feeds In-Reply-To: <1332378266-sup-6480@pinkfloyd.chass.utoronto.ca> References: <1331599643-sup-3316@pinkfloyd.chass.utoronto.ca> <921CBC4F-28EE-4499-8C41-ED7CA10E5C3B@opencsw.org> <1332208179-sup-3602@pinkfloyd.chass.utoronto.ca> <1332378266-sup-6480@pinkfloyd.chass.utoronto.ca> Message-ID: <1332611157-sup-4093@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Wed Mar 21 21:07:24 -0400 2012: > How does it look now? Any other bugs or requested changes? Ok. Tonight I'm going to switch the individual rel/arch feeds for the whole catalog version. I'll update the links on the web pages and send a note to users at . Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Sun Mar 25 14:51:14 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 25 Mar 2012 14:51:14 +0200 Subject: [csw-maintainers] boost update In-Reply-To: <4F6C820E.80704@opencsw.org> References: <4F6B94DB.7000908@opencsw.org> <4F6B9C03.9070707@opencsw.org> <4F6BA3E7.5080803@opencsw.org> <4F6C820E.80704@opencsw.org> Message-ID: I don't understand why spotless would help. One thing I noticed is that in the invocation you showed, /opt/cse/include is first, and that will cause the old Boost headers to be used. -------------- next part -------------- An HTML attachment was scrubbed... URL: From grzemba at contac-dt.de Mon Mar 26 17:17:41 2012 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Mon, 26 Mar 2012 17:17:41 +0200 Subject: [csw-maintainers] new evince Message-ID: <7470f9a37f52.4f70a4b5@contac-dt.de> I have a new evince 2.30.3 built. Packages are on experimental. Some notes I have made here: http://wiki.opencsw.org/project-evince Happy testing ;-) Comments are welcome. -- Carsten Grzemba -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Wed Mar 28 09:38:58 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 28 Mar 2012 08:38:58 +0100 Subject: [csw-maintainers] GCC 4.7 vs sparcv8 Message-ID: I've spent some time building GCC-4.7 and discovered that it contains sparcv8+ assembler and doesn't build when you try to set the architecture to be sparcv8. A simple solution is to build for sparcv8+ as the base achitecture. With GCC it's a bigger deal that with other software, because once we build libgcc_s.so.1 for sparcv8+, anything built with GCC will no longer work on sparcv8. I've already compiled libgmp for sparcv8+, but this only causes the compiler itself not work on sparcv8. The change I'm talking about here, goes deeper, and affects anything built with GCC. For me, who joined the project in 2009 and worked with modern hardware, it's a rather abstract idea to support hardware that was last built in 1996. I've never worked with such hardware and it's hard for me to assess how important it is to keep this compatibility. I'm considering following options: - using sparcv8+ as the base architecture for GCC and breaking the compatibility - not building GCC-4.7 for Solaris 9; we've agreed on sparcv8+ for Solaris 10 - trying to patch the assembler code not to use compare-and-swap - trying to hack the build process to build libgcc_s and libstdc++ for sparcv8 Thoughts? Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From jh at opencsw.org Wed Mar 28 09:56:32 2012 From: jh at opencsw.org (Jan Holzhueter) Date: Wed, 28 Mar 2012 09:56:32 +0200 Subject: [csw-maintainers] GCC 4.7 vs sparcv8 In-Reply-To: References: Message-ID: <4F72C430.8080200@opencsw.org> Hi, Am 28.03.12 09:38, schrieb Maciej (Matchek) Blizi?ski: > - not building GCC-4.7 for Solaris 9; we've agreed on sparcv8+ for > Solaris 10 +1 for that. Everything else doesn't sound right to me. Jan From dam at opencsw.org Wed Mar 28 10:15:30 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 28 Mar 2012 10:15:30 +0200 Subject: [csw-maintainers] GCC 4.7 vs sparcv8 In-Reply-To: References: Message-ID: <257CBB38-590B-405E-8B64-1178AEB7526E@opencsw.org> Hi Maciej, Am 28.03.2012 um 09:38 schrieb Maciej (Matchek) Blizi?ski: > I've spent some time building GCC-4.7 and discovered that it contains sparcv8+ assembler and doesn't build when you try to set the architecture to be sparcv8. A simple solution is to build for sparcv8+ as the base achitecture. With GCC it's a bigger deal that with other software, because once we build libgcc_s.so.1 for sparcv8+, anything built with GCC will no longer work on sparcv8. I've already compiled libgmp for sparcv8+, but this only causes the compiler itself not work on sparcv8. The change I'm talking about here, goes deeper, and affects anything built with GCC. > > For me, who joined the project in 2009 and worked with modern hardware, it's a rather abstract idea to support hardware that was last built in 1996. I've never worked with such hardware and it's hard for me to assess how important it is to keep this compatibility. I'm considering following options: > > - using sparcv8+ as the base architecture for GCC and breaking the compatibility > - not building GCC-4.7 for Solaris 9; we've agreed on sparcv8+ for Solaris 10 > - trying to patch the assembler code not to use compare-and-swap > - trying to hack the build process to build libgcc_s and libstdc++ for sparcv8 > > Thoughts? I'll agree with Jan, supporting gcc backends upstream considers obsolete for a compiler is probably too much work if no absolutely needed. As we already made the decision to go for v8+ for Solaris 10 and Solaris 10 as base anyway is probably the sanest way to go. 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 Mar 28 12:21:59 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 28 Mar 2012 11:21:59 +0100 Subject: [csw-maintainers] GCC 4.7 vs sparcv8 In-Reply-To: <257CBB38-590B-405E-8B64-1178AEB7526E@opencsw.org> References: <257CBB38-590B-405E-8B64-1178AEB7526E@opencsw.org> Message-ID: No dia 28 de Mar?o de 2012 09:15, Dagobert Michelsen escreveu: > > I'll agree with Jan, supporting gcc backends upstream considers obsolete > for a compiler is probably too much work if no absolutely needed. As we > already made the decision to go for v8+ for Solaris 10 and Solaris 10 as > base anyway is probably the sanest way to go. Okay, I'll go down that route. One more question: Do we want GCC-4.7 to be installable alongside GCC-4.6 or to replace it? For now, I'm assuming the latter, because it's easier to do. It's probably possible to have them both, but it'd require something like a month of fiddling with it to get it right, so I'm not going there right now. Maciej From bwalton at opencsw.org Wed Mar 28 14:35:25 2012 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 28 Mar 2012 08:35:25 -0400 Subject: [csw-maintainers] GCC 4.7 vs sparcv8 In-Reply-To: <4F72C430.8080200@opencsw.org> References: <4F72C430.8080200@opencsw.org> Message-ID: <1332938088-sup-6442@pinkfloyd.chass.utoronto.ca> Excerpts from Jan Holzhueter's message of Wed Mar 28 03:56:32 -0400 2012: > Hi, > > Am 28.03.12 09:38, schrieb Maciej (Matchek) Blizi?ski: > > > - not building GCC-4.7 for Solaris 9; we've agreed on sparcv8+ for > > Solaris 10 > > +1 for that. > Everything else doesn't sound right to me. +1 for this. It seems like the best option all around and doesn't detract from any of the absolute minimums that we've set at this point. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Wed Mar 28 21:48:02 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 28 Mar 2012 20:48:02 +0100 Subject: [csw-maintainers] Wintercamp 2011 In-Reply-To: References: <4F169DE1.10904@lutter.sk> Message-ID: No dia 18 de Mar?o de 2012 19:19, Maciej (Matchek) Blizi?ski escreveu: > No dia 4 de Mar?o de 2012 00:36, Maciej (Matchek) Blizi?ski > escreveu: >> I've booked my flights. I'm arriving on Friday morning and leaving >> Monday early morning. >> >> Where do we stay in Bratislava? Do you have any hotel recommendations? > > Ping? I want to book this. Have we settled on a hotel where we're staying? From maciej at opencsw.org Thu Mar 29 08:35:06 2012 From: maciej at opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?=) Date: Thu, 29 Mar 2012 07:35:06 +0100 Subject: [csw-maintainers] new evince In-Reply-To: <7470f9a37f52.4f70a4b5@contac-dt.de> References: <7470f9a37f52.4f70a4b5@contac-dt.de> Message-ID: <20120329063505.GB7792@quince.home.blizinski.pl> Carsten Grzemba wrote: > I have a new evince 2.30.3 built. Packages are on experimental. Some notes I have made here: > > http://wiki.opencsw.org/project-evince > > Happy testing ;-) > Comments are welcome. Hi Carsten, I installed evince with pkgutil and tried to run it: maciej at vsol05 ~ $ evince ld.so.1: evince: fatal: libpoppler-glib.so.3: open failed: No such file or directory Killed I looked into /var/sadm/pkg/CSWevince/save/pspool/CSWevince/install/depend and saw that it does depend on CSWpoppler, but maybe CSWpoppler doesn't pull in all the required libraries? Maciej From maciej at opencsw.org Sat Mar 31 10:48:18 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 31 Mar 2012 09:48:18 +0100 Subject: [csw-maintainers] Away until Bratislava Message-ID: Hello maintainers, I'll be generally unavailable, with little email access until the Wintercamp in Bratislava. By the way, there are currently 4 people signed up for the camp. There is still some time left, I'd like to encourage every maintainer, junior or senior, to participate! We've chosen a hotel: Saffron Hotel. The details are posted on the wiki: http://wiki.opencsw.org/wintercamp-2011 If you can, come and see us! Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: