From pfelecan at opencsw.org Fri Mar 1 13:26:49 2013 From: pfelecan at opencsw.org (pfelecan) Date: Fri, 01 Mar 2013 13:26:49 +0100 Subject: [csw-maintainers] incoherent checkpkg result related to libXaw Message-ID: I packaged TeXLive on February 25th and there were no errors during the checkpkg phase. Trying to upload the packages I get an error about a shared library not existing: * libXaw.so.5 could not be resolved for opt/csw/bin/xdvi-xaw, with rpath ('/opt/csw/lib/$ISALIST', '/opt/csw/lib', '/opt/csw/lib', '/usr/openwin/lib', '/opt/csw/lib', '/usr/lib/$ISALIST', '/usr/lib', '/lib/$ISALIST', '/lib'), expanded to ['/opt/csw/lib', '/opt/csw/lib/amd64', '/opt/csw/lib/pentium+mmx', '/opt/csw/lib/pentium', '/opt/csw/lib/i486', '/opt/csw/lib/i386', '/opt/csw/lib/pentium_pro', '/opt/csw/lib/i86', '/opt/csw/lib/pentium_pro+mmx', '/opt/csw/lib', '/opt/csw/lib', '/usr/openwin/lib', '/opt/csw/lib', '/usr/lib', '/usr/lib/amd64', '/usr/lib/pentium+mmx', '/usr/lib/pentium', '/usr/lib/i486', '/usr/lib/i386', '/usr/lib/pentium_pro', '/usr/lib/i86', '/usr/lib/pentium_pro+mmx', '/usr/lib', '/lib', '/lib/amd64', '/lib/pentium+mmx', '/lib/pentium', '/lib/i486', '/lib/i386', '/lib/pentium_pro', '/lib/i86', '/lib/pentium_pro+mmx', '/lib'], while the file was not present on the filesystem, nor in the packages under examination. for the texlive-binaries package. However, the library libXaw.so.5 exits in /usr/openwin/lib on a Solaris 10 installation. At the end of the upload output there is the usual phrase saying that: To see errors, run: /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.11 --architecture i386 ... This makes me think that this can be specific to Solaris 11 but it's just a supposition. In conclusion, as I wrote in the subject line, there is an incoherency somewhere and not only about the incriminated library. Can a knowledgeable person have a look and suggest a corrective path? TIA From dam at opencsw.org Fri Mar 1 13:30:46 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 1 Mar 2013 13:30:46 +0100 Subject: [csw-maintainers] incoherent checkpkg result related to libXaw In-Reply-To: References: Message-ID: <75A205C2-90AD-4760-A3FA-BC6362AF5908@opencsw.org> Hi Peter, Am 01.03.2013 um 13:26 schrieb pfelecan : > I packaged TeXLive on February 25th and there were no errors during the checkpkg phase. > > Trying to upload the packages I get an error about a shared library not existing: > > * libXaw.so.5 could not be resolved for opt/csw/bin/xdvi-xaw, with rpath > ('/opt/csw/lib/$ISALIST', '/opt/csw/lib', '/opt/csw/lib', > '/usr/openwin/lib', '/opt/csw/lib', '/usr/lib/$ISALIST', '/usr/lib', > '/lib/$ISALIST', '/lib'), expanded to ['/opt/csw/lib', > '/opt/csw/lib/amd64', '/opt/csw/lib/pentium+mmx', '/opt/csw/lib/pentium', > '/opt/csw/lib/i486', '/opt/csw/lib/i386', '/opt/csw/lib/pentium_pro', > '/opt/csw/lib/i86', '/opt/csw/lib/pentium_pro+mmx', '/opt/csw/lib', > '/opt/csw/lib', '/usr/openwin/lib', '/opt/csw/lib', '/usr/lib', > '/usr/lib/amd64', '/usr/lib/pentium+mmx', '/usr/lib/pentium', > '/usr/lib/i486', '/usr/lib/i386', '/usr/lib/pentium_pro', '/usr/lib/i86', > '/usr/lib/pentium_pro+mmx', '/usr/lib', '/lib', '/lib/amd64', > '/lib/pentium+mmx', '/lib/pentium', '/lib/i486', '/lib/i386', > '/lib/pentium_pro', '/lib/i86', '/lib/pentium_pro+mmx', '/lib'], while the > file was not present on the filesystem, nor in the packages under > examination. > > for the texlive-binaries package. > > However, the library libXaw.so.5 exits in /usr/openwin/lib on a Solaris 10 installation. > > At the end of the upload output there is the usual phrase saying that: > > To see errors, run: > /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.11 --architecture i386 ... > > This makes me think that this can be specific to Solaris 11 but it's just a supposition. This is indeed the case. libXaw.so.5 is part of pkg:/x11/library/toolkit/libxaw5 which is specifically an addon: "This package provides a libXaw.so.5 binary for backwards compatibility with programs compiled on older releases of Solaris.". > In conclusion, as I wrote in the subject line, there is an incoherency somewhere and not only about the incriminated library. > > Can a knowledgeable person have a look and suggest a corrective path? As we can't specify dependencies to such IPS packages yet I suggest that I reregister the packages from unstable11* now the package is installed. This should lead to checkpkg to pass. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From pfelecan at opencsw.org Fri Mar 1 14:03:16 2013 From: pfelecan at opencsw.org (pfelecan) Date: Fri, 01 Mar 2013 14:03:16 +0100 Subject: [csw-maintainers] incoherent checkpkg result related to libXaw In-Reply-To: References: Message-ID: <46cf037ced9c64b4b9a82708326b2ea3@opencsw.org> >Am 01.03.2013 um 13:26 schrieb pfelecan : >> I packaged TeXLive on February 25th and there were no errors during >> the checkpkg phase. >> >> Trying to upload the packages I get an error about a shared library >> not existing: >> >> * libXaw.so.5 could not be resolved for opt/csw/bin/xdvi-xaw, with >> rpath >> ('/opt/csw/lib/$ISALIST', '/opt/csw/lib', '/opt/csw/lib', >> '/usr/openwin/lib', '/opt/csw/lib', '/usr/lib/$ISALIST', >> '/usr/lib', >> '/lib/$ISALIST', '/lib'), expanded to ['/opt/csw/lib', >> '/opt/csw/lib/amd64', '/opt/csw/lib/pentium+mmx', >> '/opt/csw/lib/pentium', >> '/opt/csw/lib/i486', '/opt/csw/lib/i386', >> '/opt/csw/lib/pentium_pro', >> '/opt/csw/lib/i86', '/opt/csw/lib/pentium_pro+mmx', >> '/opt/csw/lib', >> '/opt/csw/lib', '/usr/openwin/lib', '/opt/csw/lib', '/usr/lib', >> '/usr/lib/amd64', '/usr/lib/pentium+mmx', '/usr/lib/pentium', >> '/usr/lib/i486', '/usr/lib/i386', '/usr/lib/pentium_pro', >> '/usr/lib/i86', >> '/usr/lib/pentium_pro+mmx', '/usr/lib', '/lib', '/lib/amd64', >> '/lib/pentium+mmx', '/lib/pentium', '/lib/i486', '/lib/i386', >> '/lib/pentium_pro', '/lib/i86', '/lib/pentium_pro+mmx', '/lib'], >> while the >> file was not present on the filesystem, nor in the packages under >> examination. >> >> for the texlive-binaries package. >> >> However, the library libXaw.so.5 exits in /usr/openwin/lib on a >> Solaris 10 installation. >> >> At the end of the upload output there is the usual phrase saying >> that: >> >> To see errors, run: >> /opt/csw/bin/checkpkg --catalog-release unstable --os-release >> SunOS5.11 --architecture i386 ... >> >> This makes me think that this can be specific to Solaris 11 but it's >> just a supposition. > > This is indeed the case. libXaw.so.5 is part of > pkg:/x11/library/toolkit/libxaw5 which is > specifically an addon: "This package provides a libXaw.so.5 binary > for backwards compatibility > with programs compiled on older releases of Solaris.". > >> In conclusion, as I wrote in the subject line, there is an >> incoherency somewhere and not only about the incriminated library. >> >> Can a knowledgeable person have a look and suggest a corrective >> path? > As we can't specify dependencies to such IPS packages yet I suggest > that I reregister > the packages from unstable11* now the package is installed. This > should lead to checkpkg > to pass. Thank you Dag. When the re-registering is done let me know so as I can try to upload again. From dam at opencsw.org Fri Mar 1 14:19:47 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 1 Mar 2013 14:19:47 +0100 Subject: [csw-maintainers] mgar: platforms-repackage output In-Reply-To: <1667E6A3-04C9-4231-A44B-8F5CAA422E8E@opencsw.org> References: <1667E6A3-04C9-4231-A44B-8F5CAA422E8E@opencsw.org> Message-ID: Hi Peter, Am 15.02.2013 um 15:43 schrieb Dagobert Michelsen : > Am 14.02.2013 um 10:02 schrieb pfelecan : >> When I "platforms-repackage", the output is misleading, only the names of the packages generated for one architecture and "all" are printed out: >> >> $ mgar platforms-remerge platforms-repackage >> [...] >> CSWautogen /home/pfelecan/staging/build-14.Feb.2013/autogen-5.17.1,REV=2013.02.14-SunOS5.10-i386-CSW.pkg.gz >> CSWautogen-dev /home/pfelecan/staging/build-14.Feb.2013/autogen_dev-5.17.1,REV=2013.02.14-SunOS5.10-all-CSW.pkg.gz >> CSWautogen-doc /home/pfelecan/staging/build-14.Feb.2013/autogen_doc-5.17.1,REV=2013.02.14-SunOS5.10-all-CSW.pkg.gz >> CSWautogendoc /home/pfelecan/staging/build-14.Feb.2013/autogen_doc_stub-5.17.1,REV=2013.02.14-SunOS5.10-all-CSW.pkg.gz >> CSWautogenrt /home/pfelecan/staging/build-14.Feb.2013/autogenrt_stub-5.17.1,REV=2013.02.14-SunOS5.10-all-CSW.pkg.gz >> CSWlibopts25 /home/pfelecan/staging/build-14.Feb.2013/libopts25-5.17.1,REV=2013.02.14-SunOS5.10-i386-CSW.pkg.gz >> >> but in the stagging directory we have: >> >> autogen-5.17.1,REV=2013.02.14-SunOS5.10-i386-CSW.pkg.gz >> autogen-5.17.1,REV=2013.02.14-SunOS5.10-sparc-CSW.pkg.gz >> autogen_dev-5.17.1,REV=2013.02.14-SunOS5.10-all-CSW.pkg.gz >> autogen_doc-5.17.1,REV=2013.02.14-SunOS5.10-all-CSW.pkg.gz >> autogen_doc_stub-5.17.1,REV=2013.02.14-SunOS5.10-all-CSW.pkg.gz >> autogenrt_stub-5.17.1,REV=2013.02.14-SunOS5.10-all-CSW.pkg.gz >> libopts25-5.17.1,REV=2013.02.14-SunOS5.10-i386-CSW.pkg.gz >> libopts25-5.17.1,REV=2013.02.14-SunOS5.10-sparc-CSW.pkg.gz >> >> all this is done from unstable10s > > Right. This is because the generated files are printed after each platform, so the other > packages are printed after sparc and before i386. But you are right, it would be better > to collect the output until the end. I have created a ticket so I can fix it next time I'll work on the code: https://sourceforge.net/apps/trac/gar/ticket/74 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 1 14:21:32 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 1 Mar 2013 14:21:32 +0100 Subject: [csw-maintainers] surprising set of packages when build spans 2 days In-Reply-To: References: <0245410b7b06e1e33a9f4bc5a45e829a@opencsw.org> <04AEBEEC-D8F7-48A8-9697-980506DA8560@opencsw.org> Message-ID: <98D8A555-5F31-4672-B37C-764A3813D8B0@opencsw.org> Hi Peter, Am 26.02.2013 um 19:27 schrieb Peter FELECAN : > Dagobert Michelsen writes: >> Am 26.02.2013 um 13:19 schrieb pfelecan : >>> As we can see, all the architecture neutral packages, infix "all", >>> are duplicated. This is not only a waste of space but also of >>> time: it means that for each platform they are generated >>> even though once is enough. >> >> This is only true if you build both architectures at the same time. > > Yes: "platforms" target which is the most frequent use case, isn't it? > >> Ideally they should be the same between sparc and i386, so if you >> build both sparc and i386 on the same day, yes, it gets rewritten. > > From the outside they are not the same... > >> It could be excluded from all but the first requested arch, but >> up to now it was not an issue. > > This is quite simple to test: start before midnight and instrument a > recipe such as to wait until after midnight at the end of the packaging. > >>> Can this be optimized by generating only once the "all" packages >>> when using the "platforms" target? >>> >>> I don't know which is the effect of this on the packages upload >>> but I'll test it very soon. >> >> You will get collisions, so just throw away the packages from one arch >> with archall. > > Thanks. I'll remove one set of architecture neutral packages. I have created a ticket so I don't forget it when I next work on the code: https://sourceforge.net/apps/trac/gar/ticket/75 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 1 14:23:43 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 1 Mar 2013 14:23:43 +0100 Subject: [csw-maintainers] cannot upload update of class action script texhash package In-Reply-To: References: <1b05bdccbafda9ecde9884bc84f4045e@opencsw.org> <6d4dd1d5f4b478fd2beea73044c5a2cc@opencsw.org>

<0D6867CF-47F7-4C68-A795-17F80DBB8917@opencsw.org> Message-ID: <71C718ED-FCA3-447D-A6A9-ED9CB6CB8929@opencsw.org> Hi Peter, Am 22.02.2013 um 19:35 schrieb Peter FELECAN : > Dagobert Michelsen writes: >> Am 21.02.2013 um 10:24 schrieb Maciej (Matchek) Blizi?ski : >>>> Finally, when I'm writing "luxury" I think to what was suggested by Dag, >>>> i.e. when using only the "packaging" target on a system which has >>>> checkpkg activated showing what should be the checkpkg stanza; and this >>>> is not a luxury but a necessity as we have seen. >>> >>> Some GAR code refactoring will be required around line 1015 of >>> gar.pkg.mk, so that you can either run or display the checkpkg >>> command, and you still keep all how-to-run-checkpkg information in one place. >>> >>> Dago, is it doable? >> >> The question is what the workflow would be and what should be done. A good thing would IMHO be >> >> - mgar package >> - (Edit some stuff) >> - mgar repackage-CSWjustone >> >> After the individual repackage all packages would be checked together. Checking just one >> package would IMHO be too dangerous. Additionally, I would remove the target >> package-CSWfoo >> as it indicates it could be explicitly called. Building just one package without the others >> first is also a usecase I would like to avoid. >> >> Peter, would this be acceptable? > > In principle yes. However, for cas-* packages the work-flow is: > > - package one cas > - upload the resulting cas which is usually architecture neutral I have created a ticket so I don't forget the issue when I next work on the code: https://sourceforge.net/apps/trac/gar/ticket/76 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 1 14:28:28 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 1 Mar 2013 14:28:28 +0100 Subject: [csw-maintainers] incoherent checkpkg result related to libXaw In-Reply-To: <46cf037ced9c64b4b9a82708326b2ea3@opencsw.org> References: <46cf037ced9c64b4b9a82708326b2ea3@opencsw.org> Message-ID: <2F957C16-A4F7-4CA4-8995-00E6184CEE88@opencsw.org> Hi Peter, Am 01.03.2013 um 14:03 schrieb pfelecan : >> Am 01.03.2013 um 13:26 schrieb pfelecan : >>> I packaged TeXLive on February 25th and there were no errors during the checkpkg phase. >>> >>> Trying to upload the packages I get an error about a shared library not existing: >>> >>> * libXaw.so.5 could not be resolved for opt/csw/bin/xdvi-xaw, with rpath >>> ('/opt/csw/lib/$ISALIST', '/opt/csw/lib', '/opt/csw/lib', >>> '/usr/openwin/lib', '/opt/csw/lib', '/usr/lib/$ISALIST', '/usr/lib', >>> '/lib/$ISALIST', '/lib'), expanded to ['/opt/csw/lib', >>> '/opt/csw/lib/amd64', '/opt/csw/lib/pentium+mmx', '/opt/csw/lib/pentium', >>> '/opt/csw/lib/i486', '/opt/csw/lib/i386', '/opt/csw/lib/pentium_pro', >>> '/opt/csw/lib/i86', '/opt/csw/lib/pentium_pro+mmx', '/opt/csw/lib', >>> '/opt/csw/lib', '/usr/openwin/lib', '/opt/csw/lib', '/usr/lib', >>> '/usr/lib/amd64', '/usr/lib/pentium+mmx', '/usr/lib/pentium', >>> '/usr/lib/i486', '/usr/lib/i386', '/usr/lib/pentium_pro', '/usr/lib/i86', >>> '/usr/lib/pentium_pro+mmx', '/usr/lib', '/lib', '/lib/amd64', >>> '/lib/pentium+mmx', '/lib/pentium', '/lib/i486', '/lib/i386', >>> '/lib/pentium_pro', '/lib/i86', '/lib/pentium_pro+mmx', '/lib'], while the >>> file was not present on the filesystem, nor in the packages under >>> examination. >>> >>> for the texlive-binaries package. >>> >>> However, the library libXaw.so.5 exits in /usr/openwin/lib on a Solaris 10 installation. >>> >>> At the end of the upload output there is the usual phrase saying that: >>> >>> To see errors, run: >>> /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.11 --architecture i386 ... >>> >>> This makes me think that this can be specific to Solaris 11 but it's just a supposition. >> >> This is indeed the case. libXaw.so.5 is part of pkg:/x11/library/toolkit/libxaw5 which is >> specifically an addon: "This package provides a libXaw.so.5 binary for backwards compatibility >> with programs compiled on older releases of Solaris.". >> >>> In conclusion, as I wrote in the subject line, there is an incoherency somewhere and not only about the incriminated library. >>> >>> Can a knowledgeable person have a look and suggest a corrective path? > >> As we can't specify dependencies to such IPS packages yet I suggest that I reregister >> the packages from unstable11* now the package is installed. This should lead to checkpkg >> to pass. > > Thank you Dag. When the re-registering is done let me know so as I can try to upload again. I reregistered the unstable11* packages as documented in http://wiki.opencsw.org/checkpkg Please try again, hopefully your issue is fixed now. 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 1 15:19:40 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 1 Mar 2013 14:19:40 +0000 Subject: [csw-maintainers] incoherent checkpkg result related to libXaw In-Reply-To: References: Message-ID: 2013/3/1 pfelecan : > /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.11 > --architecture i386 Hm, this invocation should fail, there is no --architecture option any more, replaced by catalog-architecture, as you requested. Did you not update? From pfelecan at opencsw.org Fri Mar 1 19:31:07 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 01 Mar 2013 19:31:07 +0100 Subject: [csw-maintainers] incoherent checkpkg result related to libXaw In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Fri, 1 Mar 2013 14:19:40 +0000") References:

Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/3/1 pfelecan : >> /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.11 >> --architecture i386 > > Hm, this invocation should fail, there is no --architecture option any > more, replaced by catalog-architecture, as you requested. Did you not > update? I cannot update "login", is a build-farm component... What I cited is what checkpkg gave me as the command to use for seeing the errors. Note the "/opt/csw/bin/checkpkg" in the suggested incantation. -- Peter From maciej at opencsw.org Fri Mar 1 19:57:25 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 1 Mar 2013 18:57:25 +0000 Subject: [csw-maintainers] incoherent checkpkg result related to libXaw In-Reply-To: References:

Message-ID: 2013/3/1 Peter FELECAN : > "Maciej (Matchek) Blizi?ski" writes: > >> 2013/3/1 pfelecan : >>> /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.11 >>> --architecture i386 >> >> Hm, this invocation should fail, there is no --architecture option any >> more, replaced by catalog-architecture, as you requested. Did you not >> update? > > I cannot update "login", is a build-farm component... What I cited is > what checkpkg gave me as the command to use for seeing the errors. Note > the "/opt/csw/bin/checkpkg" in the suggested incantation. Right you are. The updated checkpkg should be now on login. From pfelecan at opencsw.org Sat Mar 2 10:16:55 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 02 Mar 2013 10:16:55 +0100 Subject: [csw-maintainers] incoherent checkpkg result related to libXaw In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Fri, 1 Mar 2013 18:57:25 +0000") References:

Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/3/1 Peter FELECAN : >> "Maciej (Matchek) Blizi?ski" writes: >> >>> 2013/3/1 pfelecan : >>>> /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.11 >>>> --architecture i386 >>> >>> Hm, this invocation should fail, there is no --architecture option any >>> more, replaced by catalog-architecture, as you requested. Did you not >>> update? >> >> I cannot update "login", is a build-farm component... What I cited is >> what checkpkg gave me as the command to use for seeing the errors. Note >> the "/opt/csw/bin/checkpkg" in the suggested incantation. > > Right you are. The updated checkpkg should be now on login. Thank you. Have tried again, to no avail: nohup csw-upload-pkg staging/build-25.Feb.2013/* < /dev/null >> ~/logs/texlive-upload.2 2>&1 & Traceback (most recent call last): File "/opt/csw/bin/checkpkg", line 197, in File "/opt/csw/bin/checkpkg", line 158, in main File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 828, in Run File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 236, in Run File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 785, in GetAllTags File "/opt/csw/lib/python/csw/package_checks.py", line 705, in CheckDisallowedPaths File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 419, in GetCommonPaths File "/opt/csw/lib/python/csw/checkpkg_lib.py", line 404, in _GetPathsForArch checkpkg_lib.DataError: Could not find the commondirs-i386 file. Processing 104 file(s). Please wait. Checking 95 package(s) against catalog unstable sparc SunOS5.10 Checking 95 package(s) against catalog unstable i386 SunOS5.10 Checking 95 package(s) against catalog unstable sparc SunOS5.11 Checking 95 package(s) against catalog unstable i386 SunOS5.11 Checks failed for catalogs: - i386 SunOS5.11 libkpathsea6-20120701,REV=2013.02.26-SunOS5.10-i386-CSW.pkg.gz . . . To see errors, run: /opt/csw/bin/checkpkg --catalog-release unstable --os-release SunOS5.11 --architecture i386 ... Note the "traceback" and the proposed command to run. -- Peter From maciej at opencsw.org Sat Mar 2 19:04:33 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 2 Mar 2013 18:04:33 +0000 Subject: [csw-maintainers] incoherent checkpkg result related to libXaw In-Reply-To: References:

Message-ID: 2013/3/2 Peter FELECAN : > checkpkg_lib.DataError: Could not find the commondirs-i386 file. Could it be a race condition where the package was being upgraded while checkpkg was running? There would be a brief amount of time when the file is missing (between pkgrm and pkgadd). I ran the same command myself and it seems to work. I also see that --catalog-architecture is not there. I'm not sure why. I did this: (1) submit the code, (2) contact Ben and ask to reroll cswutils. I'm not sure what happened there, maybe I only thought I submitted the code? Or maybe the cswutils package build did not pick up the new code? I'll try to find out. From maciej at opencsw.org Sat Mar 2 21:55:03 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 2 Mar 2013 20:55:03 +0000 Subject: [csw-maintainers] incoherent checkpkg result related to libXaw In-Reply-To: References:

Message-ID: 2013/3/2 Maciej (Matchek) Blizi?ski > I ran the same command myself and it seems to work. Looks like it worked, the packages are now in the Solaris 11 catalog. From pfelecan at opencsw.org Sun Mar 3 17:47:20 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 03 Mar 2013 17:47:20 +0100 Subject: [csw-maintainers] incoherent checkpkg result related to libXaw In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sat, 2 Mar 2013 18:04:33 +0000") References:

Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/3/2 Peter FELECAN : >> checkpkg_lib.DataError: Could not find the commondirs-i386 file. > > Could it be a race condition where the package was being upgraded > while checkpkg was running? There would be a brief amount of time when > the file is missing (between pkgrm and pkgadd). It's not the case. > I ran the same command myself and it seems to work. Inded, I just received the notification. > I also see that --catalog-architecture is not there. I'm not sure why. > I did this: (1) submit the code, (2) contact Ben and ask to reroll > cswutils. I'm not sure what happened there, maybe I only thought I > submitted the code? Or maybe the cswutils package build did not pick > up the new code? I'll try to find out. Please verify. Thank you. -- Peter From maciej at opencsw.org Sun Mar 3 18:30:36 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 3 Mar 2013 17:30:36 +0000 Subject: [csw-maintainers] incoherent checkpkg result related to libXaw In-Reply-To: References:

Message-ID: 2013/3/3 Peter FELECAN : >> Could it be a race condition where the package was being upgraded >> while checkpkg was running? There would be a brief amount of time when >> the file is missing (between pkgrm and pkgadd). > > It's not the case. Are you sure? Why are you sure? >> I ran the same command myself and it seems to work. > > Inded, I just received the notification. Why did it work then? I didn't do anything except running the command. From pfelecan at opencsw.org Sun Mar 3 18:48:19 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 03 Mar 2013 18:48:19 +0100 Subject: [csw-maintainers] incoherent checkpkg result related to libXaw In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sun, 3 Mar 2013 17:30:36 +0000") References:

Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/3/3 Peter FELECAN : >>> Could it be a race condition where the package was being upgraded >>> while checkpkg was running? There would be a brief amount of time when >>> the file is missing (between pkgrm and pkgadd). >> >> It's not the case. > > Are you sure? Why are you sure? Because I didn't upgraded the packages while uploading. >>> I ran the same command myself and it seems to work. >> >> Inded, I just received the notification. > > Why did it work then? I didn't do anything except running the command. A mistery which should be solved. -- Peter From dam at opencsw.org Mon Mar 4 14:27:36 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 4 Mar 2013 14:27:36 +0100 Subject: [csw-maintainers] Nwe pigz with zopfli support Message-ID: <41E23B83-1491-47AB-99AE-9C92AEF11084@opencsw.org> Hi folks, I just made a new version of pigz allowing parallel compression on all cores now with Zopfli support: http://code.google.com/p/zopfli/ Please give it a try and let me know if you encounter anything suspicous: http://buildfarm.opencsw.org/experimental.html#pigz 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 4 21:57:24 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 4 Mar 2013 21:57:24 +0100 Subject: [csw-maintainers] Wanted: Co-Admin of Sourceforge Message-ID: <011BDC4E-C64D-4617-BA94-1574FD0EA750@opencsw.org> Fellow maintainers, Sebastian mailed me some time ago that he would like to step back as co-admin of the sourceforge part of OpenCSW. As I think it is beneficiary to have more than one admin of the project I hereby call the position as vacant :-) So if you think this job is for you just drop me a note. The tasks mainly involve adding users to the project among some minor housekeeping. Best regards -- Dago From dam at opencsw.org Mon Mar 4 22:04:04 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 4 Mar 2013 22:04:04 +0100 Subject: [csw-maintainers] Upgrade of SourceForge projects Message-ID: <82005EB5-B1CD-4E1D-90D7-DCEA1224B307@opencsw.org> Hi folks, I just upgraded the SourceForge project for "opencsw" to the new Allura platform. This is a requirement of SF as the old platform will be turned off sometime in the future. This requires a fresh checkout before committing again. The URL changed from https://opencsw.svn.sourceforge.net/svnroot/opencsw to https://svn.code.sf.net/p/opencsw/code As the repository is not cloned, but regenerated you unfortunately cannot "svn switch" but must do a new checkout. We must do a similar thing some time in the future for "gar" too, but as this also requires moving our trac instance it is some time in the future, though. Sorry for the inconvenience -- Dago From pfelecan at opencsw.org Tue Mar 5 09:39:38 2013 From: pfelecan at opencsw.org (pfelecan) Date: Tue, 05 Mar 2013 09:39:38 +0100 Subject: [csw-maintainers] new TeXLive package not in Mantis Message-ID: After the epic submission of TeXLive packages the Mantis data base doesn't contain the corresponding entries. The old teTeX is still referenced. Is this related to the issues encountered in uploading the packages? From maciej at opencsw.org Tue Mar 5 09:48:39 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 5 Mar 2013 08:48:39 +0000 Subject: [csw-maintainers] new TeXLive package not in Mantis In-Reply-To: References: Message-ID: 2013/3/5 pfelecan > > After the epic submission of TeXLive packages the Mantis data base doesn't contain the corresponding entries. The old teTeX is still referenced. Is this related to the issues encountered in uploading the packages? Probably not related to the issues during uploading, but the processing later on. I'm guessing Ben would have the best idea what's up. There should be some logs from the integration cron job. Maciej From bwalton at opencsw.org Tue Mar 5 16:27:14 2013 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 5 Mar 2013 07:27:14 -0800 Subject: [csw-maintainers] new TeXLive package not in Mantis In-Reply-To: References:

Message-ID: Hi Peter, I forwarded you a message about one of the packages. There is an invalid name transition: "Updating tex_pdftricks_stub/CSWtex-pdftricks but old catalog name for CSWtex-pdftricks was tex_pdftricks. Silent catalog name change." I believe this occurs when the stub package doesn't define the correct dependency to the newly named package. This is forcing the remaining updates to fail. I should be able to override this, but it's really better if the naming is fixed instead. Thanks -Ben On Tue, Mar 5, 2013 at 12:48 AM, Maciej (Matchek) Blizi?ski wrote: > 2013/3/5 pfelecan >> >> After the epic submission of TeXLive packages the Mantis data base doesn't contain the corresponding entries. The old teTeX is still referenced. Is this related to the issues encountered in uploading the packages? > > Probably not related to the issues during uploading, but the > processing later on. > > I'm guessing Ben would have the best idea what's up. There should be > some logs from the integration cron job. > > Maciej From rupert at opencsw.org Wed Mar 6 00:14:38 2013 From: rupert at opencsw.org (rupert THURNER) Date: Wed, 6 Mar 2013 00:14:38 +0100 Subject: [csw-maintainers] libserf-1.2.0, how? In-Reply-To: References: Message-ID: hi, could somebody mgar knowledgable help to make a correct new version of libserf or point me to a good / simple example of another library which changed the version? rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfelecan at opencsw.org Wed Mar 6 20:05:01 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 06 Mar 2013 20:05:01 +0100 Subject: [csw-maintainers] new TeXLive package not in Mantis In-Reply-To: (Ben Walton's message of "Tue, 5 Mar 2013 07:27:14 -0800") References:

Message-ID: Ben Walton writes: > I forwarded you a message about one of the packages. There is an > invalid name transition: > > "Updating tex_pdftricks_stub/CSWtex-pdftricks but old catalog name for > CSWtex-pdftricks was tex_pdftricks. Silent catalog name change." > > I believe this occurs when the stub package doesn't define the correct > dependency to the newly named package. > > This is forcing the remaining updates to fail. I should be able to > override this, but it's really better if the naming is fixed instead. I will fix the recipe but in the mean time can you override this please? -- Peter From maciej at opencsw.org Wed Mar 6 22:37:38 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 6 Mar 2013 21:37:38 +0000 Subject: [csw-maintainers] libserf-1.2.0, how? In-Reply-To: References: Message-ID: 2013/3/5 rupert THURNER : > could somebody mgar knowledgable help to make a correct new version of > libserf or point me to a good / simple example of another library which > changed the version? The short answer is that you just build the new library, and if they changed the soname, you adjust the package name accordingly. Did you try that and ran into a problem? Maciej From rupert at opencsw.org Thu Mar 7 19:35:23 2013 From: rupert at opencsw.org (rupert THURNER) Date: Thu, 7 Mar 2013 19:35:23 +0100 Subject: [csw-maintainers] libserf-1.2.0, how? In-Reply-To: References:

Message-ID: If you could quickly change the makefile including a retiring of the old version should it be appropriate i d appreciate it. I got an error months ago while doing this and just left the version in place because of it. But that is not your intention afaiu. Rupert Am 06.03.2013 22:38 schrieb "Maciej (Matchek) Blizi?ski" : > 2013/3/5 rupert THURNER : > > could somebody mgar knowledgable help to make a correct new version of > > libserf or point me to a good / simple example of another library which > > changed the version? > > The short answer is that you just build the new library, and if they > changed the soname, you adjust the package name accordingly. Did you > try that and ran into a problem? > > Maciej > _______________________________________________ > 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 7 19:57:11 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 7 Mar 2013 19:57:11 +0100 Subject: [csw-maintainers] libserf-1.2.0, how? In-Reply-To: References:

<29EF90D5-EDEA-4A00-B2CA-82A015D7C59B@opencsw.org> Message-ID: Hi, Use "ldd -Ur" and you should have the errors displayed by ldd. What bug is caused by using "-z ignore" ? Yann 2013/3/7 Dagobert Michelsen > Hi, > > Am 07.03.2013 um 19:35 schrieb rupert THURNER: > > If you could quickly change the makefile including a retiring of the old > version should it be appropriate i d appreciate it. I got an error months > ago while doing this and just left the version in place because of it. But > that is not your intention afaiu. > > > > Rupert > > > > Am 06.03.2013 22:38 schrieb "Maciej (Matchek) Blizi?ski" < > maciej at opencsw.org>: > > > > > 2013/3/5 rupert THURNER : > > > > could somebody mgar knowledgable help to make a correct new version > of > > > > libserf or point me to a good / simple example of another library > which > > > > changed the version? > > > > > > The short answer is that you just build the new library, and if they > > > changed the soname, you adjust the package name accordingly. Did you > > > try that and ran into a problem? > > There are a couple of issues with -z ignore as all libraries are not > pulled in any more. > After adding > LINKER_IGNORE = > I get several warnings again: > > CHECKPKG_OVERRIDES_CSWlibserf1-0 += > soname-unused|libsendfile.so.1|is|needed|by|/opt/csw/lib/libserf-1.so.0.0.0|but|never|used > CHECKPKG_OVERRIDES_CSWlibserf1-0 += > soname-unused|libuuid.so.1|is|needed|by|/opt/csw/lib/libserf-1.so.0.0.0|but|never|used > CHECKPKG_OVERRIDES_CSWlibserf1-0 += > soname-unused|libiconv.so.2|is|needed|by|/opt/csw/lib/libserf-1.so.0.0.0|but|never|used > CHECKPKG_OVERRIDES_CSWlibserf1-0 += > soname-unused|libexpat.so.1|is|needed|by|/opt/csw/lib/libserf-1.so.0.0.0|but|never|used > CHECKPKG_OVERRIDES_CSWlibserf1-0 += soname-unused|libdb-4.8.so > |is|needed|by|/opt/csw/lib/libserf-1.so.0.0.0|but|never|used > CHECKPKG_OVERRIDES_CSWlibserf1-0 += > soname-unused|liblber-2.4.so.2|is|needed|by|/opt/csw/lib/libserf-1.so.0.0.0|but|never|used > CHECKPKG_OVERRIDES_CSWlibserf1-0 += > soname-unused|libldap-2.4.so.2|is|needed|by|/opt/csw/lib/libserf-1.so.0.0.0|but|never|used > > This is pretty strange, as at least some of them should be used, however > ldd -r > works fine. Any idea how this can happen? > > > Best regards > > -- Dago > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Thu Mar 7 20:09:23 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 7 Mar 2013 20:09:23 +0100 Subject: [csw-maintainers] libserf-1.2.0, how? In-Reply-To: References:

<29EF90D5-EDEA-4A00-B2CA-82A015D7C59B@opencsw.org> Message-ID: Hi Yann, Am 07.03.2013 um 20:01 schrieb Yann Rouillard: > Use "ldd -Ur" and you should have the errors displayed by ldd. Yes, a lot of unreferences objects > What bug is caused by using "-z ignore" ? I haven't tried the resulting library yet, may I should just see what happens. Best regards -- Dago > > Yann > > > > 2013/3/7 Dagobert Michelsen > Hi, > > Am 07.03.2013 um 19:35 schrieb rupert THURNER: > > If you could quickly change the makefile including a retiring of the old version should it be appropriate i d appreciate it. I got an error months ago while doing this and just left the version in place because of it. But that is not your intention afaiu. > > > > Rupert > > > > Am 06.03.2013 22:38 schrieb "Maciej (Matchek) Blizi?ski" : > > > > > 2013/3/5 rupert THURNER : > > > > could somebody mgar knowledgable help to make a correct new version of > > > > libserf or point me to a good / simple example of another library which > > > > changed the version? > > > > > > The short answer is that you just build the new library, and if they > > > changed the soname, you adjust the package name accordingly. Did you > > > try that and ran into a problem? > > There are a couple of issues with -z ignore as all libraries are not pulled in any more. > After adding > LINKER_IGNORE = > I get several warnings again: > > CHECKPKG_OVERRIDES_CSWlibserf1-0 += soname-unused|libsendfile.so.1|is|needed|by|/opt/csw/lib/libserf-1.so.0.0.0|but|never|used > CHECKPKG_OVERRIDES_CSWlibserf1-0 += soname-unused|libuuid.so.1|is|needed|by|/opt/csw/lib/libserf-1.so.0.0.0|but|never|used > CHECKPKG_OVERRIDES_CSWlibserf1-0 += soname-unused|libiconv.so.2|is|needed|by|/opt/csw/lib/libserf-1.so.0.0.0|but|never|used > CHECKPKG_OVERRIDES_CSWlibserf1-0 += soname-unused|libexpat.so.1|is|needed|by|/opt/csw/lib/libserf-1.so.0.0.0|but|never|used > CHECKPKG_OVERRIDES_CSWlibserf1-0 += soname-unused|libdb-4.8.so|is|needed|by|/opt/csw/lib/libserf-1.so.0.0.0|but|never|used > CHECKPKG_OVERRIDES_CSWlibserf1-0 += soname-unused|liblber-2.4.so.2|is|needed|by|/opt/csw/lib/libserf-1.so.0.0.0|but|never|used > CHECKPKG_OVERRIDES_CSWlibserf1-0 += soname-unused|libldap-2.4.so.2|is|needed|by|/opt/csw/lib/libserf-1.so.0.0.0|but|never|used > > This is pretty strange, as at least some of them should be used, however ldd -r > works fine. Any idea how this can happen? > > > Best regards > > -- Dago > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > > _______________________________________________ > 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 ihsan at opencsw.org Mon Mar 11 11:23:43 2013 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuIERvxJ9hbg==?=) Date: Mon, 11 Mar 2013 11:23:43 +0100 Subject: [csw-maintainers] dnssec and unbound In-Reply-To: References:

Message-ID: <513DB0AF.1080209@opencsw.org> Hi, On 10/29/2012 05:20 PM, Ben Walton wrote: >>> configure: WARNING: >>> *** >>> *** The DNSSEC root key file in /etc/unbound/root.key was not found. >>> *** This file is needed for the verification of DNSSEC responses. >>> *** Use the command: unbound-anchor -a "/etc/unbound/root.key" >>> *** to generate or update it. >>> *** >> >> Any advice on how we should handle this? Add the key to libunbound2? >> Ihsan? > > My initial reaction to this was that including the "config" file in > the library package wasn't the right thing to do, but after reading > about it and thinking some more, I think your suggestion is ok. > Originally I thought a -data package to deliver this (and similar > files from unbound if they exist) might be a better option but that > seems to heavy and counter-productive. > > The recipe for unbound could automate creating root.key at every > re-spin using the procedure described here: > http://www.unbound.net/documentation/howto_anchor.html When I started to package Unbound in 2009, DNSSEC was still experimental and there was no root key yet. I will include the key in the future build. Thanks for pointing on this. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From jh at opencsw.org Mon Mar 18 12:51:32 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Mon, 18 Mar 2013 12:51:32 +0100 Subject: [csw-maintainers] CSWlibssl1-0-0 missing 64bit lib In-Reply-To: References:

<29EF90D5-EDEA-4A00-B2CA-82A015D7C59B@opencsw.org> Message-ID: <5146FFC4.6030308@opencsw.org> Hi, libssl1_0_0-1.0.1e,REV=2013.03.12-SunOS5.10-i386-CSW.pkg seems to miss the 64bit lib. Greetings Jan From jh at opencsw.org Tue Mar 19 13:34:54 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Tue, 19 Mar 2013 13:34:54 +0100 Subject: [csw-maintainers] Fixing/rebuild subversion for Solaris9 In-Reply-To: <5146FFC4.6030308@opencsw.org> References:

<29EF90D5-EDEA-4A00-B2CA-82A015D7C59B@opencsw.org> <5146FFC4.6030308@opencsw.org> Message-ID: <51485B6E.2000908@opencsw.org> Hi, I need to reactivate a build for subversion for Solaris9. reason is that the apache module does not work as the old one in Solaris9 is not build against newest apache release. Solaris 9 package will not have a gnome-keychain anymore. Since we only have old glib. I don't think anyway uses it anyway. I have that stuff done and would like to push it. (See attached patch) @Rupert I see you are the last maintainer for the package. If you don't have any objections I will go forward. Greetings Jan Index: Makefile =================================================================== --- Makefile (revision 20348) +++ Makefile (working copy) @@ -36,8 +36,8 @@ LICENSE = LICENSE -# solaris9 does not have the newest glib2 any more -PACKAGING_PLATFORMS += solaris10-sparc solaris10-i386 +# solaris9 does not have the newest glib2 any more so no gnome-keychain on Solaris9 +PACKAGING_PLATFORMS = solaris9-sparc solaris9-i386 solaris10-sparc solaris10-i386 BUILD_DEP_PKGS += CSWlibexpat-dev BUILD_DEP_PKGS += CSWlibserf-dev @@ -57,16 +57,23 @@ RUNTIME_DEP_PKGS_CSWsvn += CSWlibapr1-0 RUNTIME_DEP_PKGS_CSWsvn += CSWlibaprutil1-0 RUNTIME_DEP_PKGS_CSWsvn += CSWlibneon27 -RUNTIME_DEP_PKGS_CSWsvn += CSWlibgnome-keyring0 -RUNTIME_DEP_PKGS_CSWsvn += CSWlibdbus1-3 -RUNTIME_DEP_PKGS_CSWsvn += CSWlibglib2-0-0 +RUNTIME_DEP_PKGS_CSWsvn_5.10 += CSWlibdbus1-3 +RUNTIME_DEP_PKGS_CSWsvn_5.10 += CSWlibgnome-keyring0 +RUNTIME_DEP_PKGS_CSWsvn_5.10 += CSWlibglib2-0-0 CHECKPKG_OVERRIDES_CSWsvn += surplus-dependency|CSWlibdbus1-3 +RUNTIME_DEP_PKGS_CSWsvn += $(RUNTIME_DEP_PKGS_CSWsvn_$(GAROSREL)) + + PACKAGES += CSWsvn-dev SPKG_DESC_CSWsvn-dev = Subversion Development Support PKGFILES_CSWsvn-dev = $(PKGFILES_DEVEL) PKGFILES_CSWsvn-dev += $(docdir)/$(CATALOGNAME_CSWsvn-dev)/changelog.CSW +#Needed for Solaris9 again: +OBSOLETED_BY_CSWsvn-dev_5.9 = CSWsvn-devel +OBSOLETED_BY_CSWsvn-dev += $(OBSOLETED_BY_CSWsvn-dev_$(GAROSREL)) + PACKAGES += CSWap2svn SPKG_DESC_CSWap2svn = Subversion Modules for Apache 2.2 CATALOGNAME_CSWap2svn = ap2_subversion @@ -182,18 +189,21 @@ NODIRPATHS = --libdir --libexecdir CONFIGURE_ARGS = $(DIRPATHS) --libdir=$(SVNLIB) --libexecdir=$(SVNLIB) CONFIGURE_ARGS += --disable-mod-activation -CONFIGURE_ARGS += --with-jdk=/usr/jdk/j2sdk1.4.2_02/j2se +CONFIGURE_ARGS_5.9 += --with-jdk=/usr/jdk1.6.0_20 CONFIGURE_ARGS += --enable-javahl CONFIGURE_ARGS += --with-apr=$(bindir)/apr-1-config CONFIGURE_ARGS += --with-apr-util=$(bindir)/apu-1-config CONFIGURE_ARGS += --with-apxs=$(prefix)/apache2/sbin/apxs -CONFIGURE_ARGS += --with-gnome-keyring=$(prefix) -CONFIGURE_ARGS += --with-jdk=$(JAVA_HOME) +CONFIGURE_ARGS_5.10 += --with-jdk=$(JAVA_HOME) CONFIGURE_ARGS += --with-sasl=$(prefix) CONFIGURE_ARGS += --with-serf=$(prefix) CONFIGURE_ARGS += --with-ssl=$(prefix) CONFIGURE_ARGS += --with-zlib=$(prefix) +#No Keyring on Solaris9 +CONFIGURE_ARGS_5.10 += --with-gnome-keyring=$(prefix) +CONFIGURE_ARGS += $(CONFIGURE_ARGS_$(GAROSREL)) + # Once you have verified that a new upstream release passes the tests, you can use # "SKIPTEST=1 gmake " to skip the tests for simple repackaging tasks. # From rupert at opencsw.org Tue Mar 19 19:24:48 2013 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 19 Mar 2013 19:24:48 +0100 Subject: [csw-maintainers] Fixing/rebuild subversion for Solaris9 In-Reply-To: <51485B6E.2000908@opencsw.org> References:

<29EF90D5-EDEA-4A00-B2CA-82A015D7C59B@opencsw.org> <5146FFC4.6030308@opencsw.org> <51485B6E.2000908@opencsw.org> Message-ID: Go ahead, any help is welcome ... Am 19.03.2013 13:35 schrieb "Jan Holzhueter" : > Hi, > I need to reactivate a build for subversion for Solaris9. > reason is that the apache module does not work as the old one in > Solaris9 is not build against newest apache release. > Solaris 9 package will not have a gnome-keychain anymore. Since we only > have old glib. I don't think anyway uses it anyway. > > I have that stuff done and would like to push it. (See attached patch) > > @Rupert I see you are the last maintainer for the package. > If you don't have any objections I will go forward. > > Greetings > Jan > > > Index: Makefile > =================================================================== > --- Makefile (revision 20348) > +++ Makefile (working copy) > @@ -36,8 +36,8 @@ > > LICENSE = LICENSE > > -# solaris9 does not have the newest glib2 any more > -PACKAGING_PLATFORMS += solaris10-sparc solaris10-i386 > +# solaris9 does not have the newest glib2 any more so no gnome-keychain > on Solaris9 > +PACKAGING_PLATFORMS = solaris9-sparc solaris9-i386 solaris10-sparc > solaris10-i386 > > BUILD_DEP_PKGS += CSWlibexpat-dev > BUILD_DEP_PKGS += CSWlibserf-dev > @@ -57,16 +57,23 @@ > RUNTIME_DEP_PKGS_CSWsvn += CSWlibapr1-0 > RUNTIME_DEP_PKGS_CSWsvn += CSWlibaprutil1-0 > RUNTIME_DEP_PKGS_CSWsvn += CSWlibneon27 > -RUNTIME_DEP_PKGS_CSWsvn += CSWlibgnome-keyring0 > -RUNTIME_DEP_PKGS_CSWsvn += CSWlibdbus1-3 > -RUNTIME_DEP_PKGS_CSWsvn += CSWlibglib2-0-0 > +RUNTIME_DEP_PKGS_CSWsvn_5.10 += CSWlibdbus1-3 > +RUNTIME_DEP_PKGS_CSWsvn_5.10 += CSWlibgnome-keyring0 > +RUNTIME_DEP_PKGS_CSWsvn_5.10 += CSWlibglib2-0-0 > CHECKPKG_OVERRIDES_CSWsvn += surplus-dependency|CSWlibdbus1-3 > > +RUNTIME_DEP_PKGS_CSWsvn += $(RUNTIME_DEP_PKGS_CSWsvn_$(GAROSREL)) > + > + > PACKAGES += CSWsvn-dev > SPKG_DESC_CSWsvn-dev = Subversion Development Support > PKGFILES_CSWsvn-dev = $(PKGFILES_DEVEL) > PKGFILES_CSWsvn-dev += > $(docdir)/$(CATALOGNAME_CSWsvn-dev)/changelog.CSW > +#Needed for Solaris9 again: > +OBSOLETED_BY_CSWsvn-dev_5.9 = CSWsvn-devel > +OBSOLETED_BY_CSWsvn-dev += $(OBSOLETED_BY_CSWsvn-dev_$(GAROSREL)) > > + > PACKAGES += CSWap2svn > SPKG_DESC_CSWap2svn = Subversion Modules for Apache 2.2 > CATALOGNAME_CSWap2svn = ap2_subversion > @@ -182,18 +189,21 @@ > NODIRPATHS = --libdir --libexecdir > CONFIGURE_ARGS = $(DIRPATHS) --libdir=$(SVNLIB) --libexecdir=$(SVNLIB) > CONFIGURE_ARGS += --disable-mod-activation > -CONFIGURE_ARGS += --with-jdk=/usr/jdk/j2sdk1.4.2_02/j2se > +CONFIGURE_ARGS_5.9 += --with-jdk=/usr/jdk1.6.0_20 > CONFIGURE_ARGS += --enable-javahl > CONFIGURE_ARGS += --with-apr=$(bindir)/apr-1-config > CONFIGURE_ARGS += --with-apr-util=$(bindir)/apu-1-config > CONFIGURE_ARGS += --with-apxs=$(prefix)/apache2/sbin/apxs > -CONFIGURE_ARGS += --with-gnome-keyring=$(prefix) > -CONFIGURE_ARGS += --with-jdk=$(JAVA_HOME) > +CONFIGURE_ARGS_5.10 += --with-jdk=$(JAVA_HOME) > CONFIGURE_ARGS += --with-sasl=$(prefix) > CONFIGURE_ARGS += --with-serf=$(prefix) > CONFIGURE_ARGS += --with-ssl=$(prefix) > CONFIGURE_ARGS += --with-zlib=$(prefix) > > +#No Keyring on Solaris9 > +CONFIGURE_ARGS_5.10 += --with-gnome-keyring=$(prefix) > +CONFIGURE_ARGS += $(CONFIGURE_ARGS_$(GAROSREL)) > + > # Once you have verified that a new upstream release passes the tests, > you can use > # "SKIPTEST=1 gmake " to skip the tests for simple repackaging > tasks. > # > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bonivart at opencsw.org Wed Mar 20 11:07:51 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 20 Mar 2013 11:07:51 +0100 Subject: [csw-maintainers] How to remove dialog_minimal from unstable? Message-ID: I got a request to rebuild dialog with a separate lib so this developer could link his software to it. So I split the package and also updated to a new upstream version. Doing this was rather complicated due to dialog using alternatives so Phil could have his minimalist dialog not depending on ncurses. I decided to skip this so now I need to get rid of dialog_minimal from the catalogs. I assume I should take care of that before uploading the new set but how? /peter From dam at opencsw.org Wed Mar 20 11:15:57 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 20 Mar 2013 11:15:57 +0100 Subject: [csw-maintainers] How to remove dialog_minimal from unstable? In-Reply-To: References: Message-ID: <0E295F01-742B-4691-9067-E5F86BED1755@opencsw.org> Hi Peter, Am 20.03.2013 um 11:07 schrieb Peter Bonivart : > I got a request to rebuild dialog with a separate lib so this > developer could link his software to it. > > So I split the package and also updated to a new upstream version. > Doing this was rather complicated due to dialog using alternatives so > Phil could have his minimalist dialog not depending on ncurses. > > I decided to skip this so now I need to get rid of dialog_minimal from > the catalogs. I assume I should take care of that before uploading the > new set but how? This depends on the step you want to take. Do you just want to drop dialog_minimal or make an obsoletion by the normal dialog? In the first case I guess you need to pkgdb removepkg `gmd5sum ` or pkgdb del-from-cat

`gmd5sum ` Maciej: right? 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 20 11:16:17 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 20 Mar 2013 10:16:17 +0000 Subject: [csw-maintainers] How to remove dialog_minimal from unstable? In-Reply-To: References: Message-ID: 2013/3/20 Peter Bonivart > I decided to skip this so now I need to get rid of dialog_minimal from > the catalogs. I assume I should take care of that before uploading the > new set but how? Try lib/python/safe_remove_package.py from gar sources. Maciej From maciej at opencsw.org Wed Mar 20 11:19:53 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 20 Mar 2013 10:19:53 +0000 Subject: [csw-maintainers] How to remove dialog_minimal from unstable? In-Reply-To: <0E295F01-742B-4691-9067-E5F86BED1755@opencsw.org> References: <0E295F01-742B-4691-9067-E5F86BED1755@opencsw.org> Message-ID: 2013/3/20 Dagobert Michelsen : > This depends on the step you want to take. Do you just want to drop > dialog_minimal or make an obsoletion by the normal dialog? > > In the first case I guess you need to > pkgdb removepkg `gmd5sum ` This command refers to the package stats. If you remove a package that way, you remove it from the database altogether. You cannot refer to it any more from any catalogs for instance. In this case, Peter only wants to break a bond between a particular svr4 file and a few catalogs. > or > pkgdb del-from-cat

`gmd5sum ` > > Maciej: right? Possibly, although this low level operation doesn't prevent you from breaking catalogs. The safe_remove_package.py script is a better approach, because it does sanity checks and bails out if the operation would break the catalog. Maciej From dam at opencsw.org Wed Mar 20 11:22:30 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 20 Mar 2013 11:22:30 +0100 Subject: [csw-maintainers] How to remove dialog_minimal from unstable? In-Reply-To: References: <0E295F01-742B-4691-9067-E5F86BED1755@opencsw.org> Message-ID: <5B1A6846-C9C0-4A41-A5D9-C8481A70ADF6@opencsw.org> Hi Maciej, Am 20.03.2013 um 11:19 schrieb Maciej (Matchek) Blizi?ski : > 2013/3/20 Dagobert Michelsen : >> This depends on the step you want to take. Do you just want to drop >> dialog_minimal or make an obsoletion by the normal dialog? >> >> In the first case I guess you need to >> pkgdb removepkg `gmd5sum ` > > This command refers to the package stats. If you remove a package that > way, you remove it from the database altogether. You cannot refer to > it any more from any catalogs for instance. In this case, Peter only > wants to break a bond between a particular svr4 file and a few > catalogs. > >> or >> pkgdb del-from-cat

`gmd5sum ` >> >> Maciej: right? > > Possibly, although this low level operation doesn't prevent you from > breaking catalogs. The safe_remove_package.py script is a better > approach, because it does sanity checks and bails out if the operation > would break the catalog. What do think about a high-level command that bundles all commands a user should do under normal operations, like upload a package or remove a package in a simple way without the need to use multiple commands? 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 20 11:40:46 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 20 Mar 2013 10:40:46 +0000 Subject: [csw-maintainers] How to remove dialog_minimal from unstable? In-Reply-To: <5B1A6846-C9C0-4A41-A5D9-C8481A70ADF6@opencsw.org> References: <0E295F01-742B-4691-9067-E5F86BED1755@opencsw.org> <5B1A6846-C9C0-4A41-A5D9-C8481A70ADF6@opencsw.org> Message-ID: 2013/3/20 Dagobert Michelsen : > What do think about a high-level command that bundles all commands a user > should do under normal operations, like upload a package or remove a package > in a simple way without the need to use multiple commands? If you think about maintaining our code, smaller tools are easier to modify and refactor. I'm already getting flak from people because our tools are complicated. It's also easier to define a sane set of command line flags if one tool does one thing. Imagine trying to get --help from a tool that does everything. Every possible option that any subcommand might take would appear in this nonsensical soup of unrelatedness. The pkgdb tool already shows signs of this problem. I'm guessing your intention is to make it easier for humans to know what tools are available and which one to use. Maybe there's a better way of improving findability. For example, a tool naming convention or a common location. Maciej From bonivart at opencsw.org Wed Mar 20 13:12:12 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 20 Mar 2013 13:12:12 +0100 Subject: [csw-maintainers] How to remove dialog_minimal from unstable? In-Reply-To: References:

Message-ID: On Wed, Mar 20, 2013 at 11:16 AM, Maciej (Matchek) Blizi?ski wrote: > 2013/3/20 Peter Bonivart >> I decided to skip this so now I need to get rid of dialog_minimal from >> the catalogs. I assume I should take care of that before uploading the >> new set but how? > > Try lib/python/safe_remove_package.py from gar sources. It just hangs: bonivart at login[opencsw]$ .buildsys/v2/lib/python/safe_remove_package.py --os-releases=SunOS5.10,SunOS5.11 -c dialog_minimal ? /peter From maciej at opencsw.org Wed Mar 20 13:43:24 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 20 Mar 2013 12:43:24 +0000 Subject: [csw-maintainers] How to remove dialog_minimal from unstable? In-Reply-To: References:

Message-ID: 2013/3/20 Peter Bonivart : > It just hangs No, it works fine. It downloads package metadata, which takes a long time. If you want it to be chatty, run it with --debug. From bonivart at opencsw.org Wed Mar 20 14:05:00 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 20 Mar 2013 14:05:00 +0100 Subject: [csw-maintainers] How to remove dialog_minimal from unstable? In-Reply-To: References:

Message-ID: On Wed, Mar 20, 2013 at 1:43 PM, Maciej (Matchek) Blizi?ski wrote: > 2013/3/20 Peter Bonivart : >> It just hangs > > No, it works fine. It downloads package metadata, which takes a long > time. If you want it to be chatty, run it with --debug. 2,5 hours now...really? /peter From maciej at opencsw.org Wed Mar 20 14:08:34 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 20 Mar 2013 13:08:34 +0000 Subject: [csw-maintainers] How to remove dialog_minimal from unstable? In-Reply-To: References:

Message-ID: 2013/3/20 Peter Bonivart : > 2,5 hours now...really? Welcome to the world of tracking all the symbols information! From bonivart at opencsw.org Wed Mar 20 17:14:25 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 20 Mar 2013 17:14:25 +0100 Subject: [csw-maintainers] How to remove dialog_minimal from unstable? In-Reply-To: References:

Message-ID: On Wed, Mar 20, 2013 at 2:08 PM, Maciej (Matchek) Blizi?ski wrote: > 2013/3/20 Peter Bonivart : >> 2,5 hours now...really? > > Welcome to the world of tracking all the symbols information! Victory! You were right, it finished after some five hours or so: bonivart at login[opencsw]$ .buildsys/v2/lib/python/safe_remove_package.py --os-releases=SunOS5.10,SunOS5.11 -c dialog_minimal # [dialog_minimal] unstable sparc SunOS5.10 9516dbdd6e24a1a0457c29edec3fc523 # [dialog_minimal] unstable i386 SunOS5.10 292f1a67c489c59655e86fe9eff2373b # [dialog_minimal] unstable sparc SunOS5.11 9516dbdd6e24a1a0457c29edec3fc523 # [dialog_minimal] unstable i386 SunOS5.11 292f1a67c489c59655e86fe9eff2373b bonivart at login[opencsw]$ cd bonivart at login[~]$ cd staging/build.2013-03-20/ bonivart at login[build.2013-03-20]$ csw-upload-pkg * Processing 6 file(s). Please wait. Uploading 'dialog-1.2r20121230,REV=2013.03.20-SunOS5.10-i386-CSW.pkg.gz' Uploading 'dialog-1.2r20121230,REV=2013.03.20-SunOS5.10-sparc-CSW.pkg.gz' Uploading 'dialog_dev-1.2r20121230,REV=2013.03.20-SunOS5.10-i386-CSW.pkg.gz' Uploading 'dialog_dev-1.2r20121230,REV=2013.03.20-SunOS5.10-sparc-CSW.pkg.gz' Uploading 'libdialog11-1.2r20121230,REV=2013.03.20-SunOS5.10-i386-CSW.pkg.gz' Uploading 'libdialog11-1.2r20121230,REV=2013.03.20-SunOS5.10-sparc-CSW.pkg.gz' Checking 3 package(s) against catalog unstable i386 SunOS5.10 Checking 3 package(s) against catalog unstable sparc SunOS5.10 Checking 3 package(s) against catalog unstable i386 SunOS5.11 Checking 3 package(s) against catalog unstable sparc SunOS5.11 All checks successful. Proceeding. Inserting dialog (i386 SunOS5.10) into catalog unstable i386 SunOS5.10 Inserting dialog_dev (i386 SunOS5.10) into catalog unstable i386 SunOS5.10 Inserting libdialog11 (i386 SunOS5.10) into catalog unstable i386 SunOS5.10 Inserting dialog (i386 SunOS5.10) into catalog unstable i386 SunOS5.11 Inserting dialog_dev (i386 SunOS5.10) into catalog unstable i386 SunOS5.11 Inserting libdialog11 (i386 SunOS5.10) into catalog unstable i386 SunOS5.11 Inserting dialog (sparc SunOS5.10) into catalog unstable sparc SunOS5.10 Inserting dialog_dev (sparc SunOS5.10) into catalog unstable sparc SunOS5.10 Inserting libdialog11 (sparc SunOS5.10) into catalog unstable sparc SunOS5.10 Inserting dialog (sparc SunOS5.10) into catalog unstable sparc SunOS5.11 Inserting dialog_dev (sparc SunOS5.10) into catalog unstable sparc SunOS5.11 Inserting libdialog11 (sparc SunOS5.10) into catalog unstable sparc SunOS5.11 bonivart at login[build.2013-03-20]$ I still don't understand why remove is so slow when inserts are just as fast as before..? It uploaded, checked and inserted the package set all in one minute. /peter From maciej at opencsw.org Wed Mar 20 19:14:59 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 20 Mar 2013 18:14:59 +0000 Subject: [csw-maintainers] How to remove dialog_minimal from unstable? In-Reply-To: References:

Message-ID: 2013/3/20 Peter Bonivart : > I still don't understand why remove is so slow when inserts are just > as fast as before..? It uploaded, checked and inserted the package set > all in one minute. The operation that takes the most time is fetching package metadata. They are cached locally on disk, so subsequent runs of the script are way faster, in the order of minutes, bottlenecking on catalog fetches. Inserting packages does not need fetching all of package metadata. The problem is figuring out package's reverse dependencies. If you want to check what depends on package X, you have to query every single package in the catalog. Therefore a single run of safe_remove_package.py requires fetching everything. I didn't want to complicate the code, even though I realized that some operations are hilariously slow. I know it can be annoying, but I didn't want to complicate the code, database and/or infrastructure any further. You can call me lazy or far-sighted, I'll take both. :-) Maciej From bonivart at opencsw.org Wed Mar 20 20:06:44 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Wed, 20 Mar 2013 20:06:44 +0100 Subject: [csw-maintainers] How to remove dialog_minimal from unstable? In-Reply-To: References:

Message-ID: On Wed, Mar 20, 2013 at 7:14 PM, Maciej (Matchek) Blizi?ski wrote: > 2013/3/20 Peter Bonivart : >> I still don't understand why remove is so slow when inserts are just >> as fast as before..? It uploaded, checked and inserted the package set >> all in one minute. > > The operation that takes the most time is fetching package metadata. > They are cached locally on disk, so subsequent runs of the script are > way faster, in the order of minutes, bottlenecking on catalog fetches. > Inserting packages does not need fetching all of package metadata. > > The problem is figuring out package's reverse dependencies. If you > want to check what depends on package X, you have to query every > single package in the catalog. Therefore a single run of > safe_remove_package.py requires fetching everything. > > I didn't want to complicate the code, even though I realized that some > operations are hilariously slow. I know it can be annoying, but I > didn't want to complicate the code, database and/or infrastructure any > further. You can call me lazy or far-sighted, I'll take both. :-) Thanks for explaining, it's not a common enough op to justify optimizing I guess. Maybe just output something like "this may take a while" because with no output for over three hours I think most would have given up. Maybe there's a nice place somewhere in the code to output a dot for progress. :) From dam at opencsw.org Thu Mar 21 20:58:24 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 21 Mar 2013 20:58:24 +0100 Subject: [csw-maintainers] CSWlibssl1-0-0 missing 64bit lib In-Reply-To: References:

<29EF90D5-EDEA-4A00-B2CA-82A015D7C59B@opencsw.org> <5146FFC4.6030308@opencsw.org> Message-ID: <1CC1A1F1-8914-45FF-BD8F-714FCBB8D3D8@opencsw.org> Hi Yann, Am 18.03.2013 um 22:17 schrieb Yann Rouillard : > I don't understand why the 64 libs are not included anymore. > Can you help me on this ? The problem is that on amd64 the libraries are installed in /opt/csw/lib instead of /opt/csw/lib/64 and therefore the merge does not pick them up. It turns out that --libdir is not passed to configure and the library directory is "just right" by default on sparcv9. Some experimenting showed that --libdir=lib/64 for 64 bit solves the issue, but the question remained why it works for sparcv9 and didn't work for amd64 in the first place. Now look in the profiles used in configure: "solaris64-x86_64-cc-sunw","cc:-xO3 -m64 -xstrconst -Xa -DL_ENDIAN::-D_REENTRANT::-lsocket -lnsl -lc:SIXTY_FOUR_BIT_LONG RC4_CHUNK BF_PTR DES_PTR DES_INT DES_UNROLL:${x86_64_asm}:elf:dlfcn:solaris-shared:-KPIC:-m64 -G -dy -z text -zdefs -Bdirect -zignore -M/usr/lib/ld/map.pagealign -M/usr/lib/ld/map.noexdata:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", ... "solaris64-sparcv9-cc-sunw","cc:-xtarget=ultra -m64 -Qoption cg -xregs=no%appl -xO5 -xstrconst -xdepend -xspace -Xa -DB_ENDIAN::-D_REENTRANT:ULTRASPARC:-lsocket -lnsl -lc:BN_LLONG RC4_CHUNK DES_INT DES_PTR DES_RISC1 DES_UNROLL BF_PTR:${sparcv9_asm}:dlfcn:solaris-shared:-KPIC:-m64 -G -dy -z text -zdefs -Bdirect -zignore -M/usr/lib/ld/map.pagealign:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):/usr/ccs/bin/ar rs::/64", There we have it: the further is lacking ::/64 at the end leading to the libraries being installed in wrong directories. I didn't feel like patching configure (feel free to do so and report upstream) but added --libdir as needed to the Makefile in addition to some minor tweaks: http://sourceforge.net/apps/trac/gar/changeset/20494 I suggest adding tests to the testsuite to see if there are actually files in /opt/csw/(bin|sbin|lib|libexec)/sparcv9 if OPENCSW_MODE64 in pkginfo contains 64. Best regards -- Dago > > Yann > > ---------- Forwarded message ---------- > From: Jan Holzhueter > Date: 2013/3/18 > Subject: CSWlibssl1-0-0 missing 64bit lib > To: List for OpenCSW maintainers , Yann Rouillard > > > Hi, > libssl1_0_0-1.0.1e,REV=2013.03.12-SunOS5.10-i386-CSW.pkg seems to miss > the 64bit lib. > > Greetings > Jan > > -- "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 pfelecan at opencsw.org Fri Mar 22 09:57:53 2013 From: pfelecan at opencsw.org (pfelecan) Date: Fri, 22 Mar 2013 09:57:53 +0100 Subject: [csw-maintainers] ctags alternate proposition Message-ID: CSWctags supplies the "Exuberant ctags" which is compatible with the etags/ctags provided also by CSWemacs-bin-common. Currently, both packages override the collision on the /opt/csw/bin/ctags component. I think that the time to use alternatives has come. Thus, I implemented the needed mechanism for the one provided by the package under my maintenanceship and kindly invite the maintainer of CSWctags to implement his part. In addition to this, I propose that the component provided by CSWctags be named /opt/csw/bin/ctags-exuberant (see how Debian manages this) such as there is no more collision between the 2 packages. Idem for the manual page. From jh at opencsw.org Fri Mar 22 10:02:45 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Fri, 22 Mar 2013 10:02:45 +0100 Subject: [csw-maintainers] ctags alternate proposition In-Reply-To: References: Message-ID: <514C1E35.10607@opencsw.org> Hi, Am 22.03.13 09:57, schrieb pfelecan: > CSWctags supplies the "Exuberant ctags" which is compatible with > the etags/ctags provided also by CSWemacs-bin-common. > > Currently, both packages override the collision on the > /opt/csw/bin/ctags component. > > I think that the time to use alternatives has come. Thus, I > implemented the needed mechanism for the one provided by the > package under my maintenanceship and kindly invite the maintainer > of CSWctags to implement his part. We have a dopple package here. Since we also do have CSWectags. Which looks like the same package. I would recommand to just remove the CSWctags package. Greetings Jan From pfelecan at opencsw.org Fri Mar 22 10:10:20 2013 From: pfelecan at opencsw.org (pfelecan) Date: Fri, 22 Mar 2013 10:10:20 +0100 Subject: [csw-maintainers] CSWemacscommon vs. CSWemacs-common as a run-time dependency Message-ID: Since Emacs packaging is under mgar aegis, the CSWemacscommon package was obsoleted by CSWemacs-common. However, for reasons that I do not understand, the old name is still proposed as a required run-time dependency instead of the new one. The more embarrassing instance being this: * Dependency issues of CSWemacs-common: * CSWemacscommon is needed by CSWemacs-common, because: * - found file(s) matching .*\.elc?$, e.g. u'/opt/csw/share/emacs/24.3/etc /edt-user.el' * RUNTIME_DEP_PKGS_CSWemacs-common += CSWemacscommon Please explore this issue and eventually provide a solution. TIA From grzemba at contac-dt.de Fri Mar 22 13:04:49 2013 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Fri, 22 Mar 2013 13:04:49 +0100 Subject: [csw-maintainers] ctags alternate proposition In-Reply-To: <514C1E35.10607@opencsw.org> References: <514C1E35.10607@opencsw.org> Message-ID: Ok, when ectags is ctags, why it is called ectags? ;-) Please remove CSWctags. Am 22.03.13 schrieb Jan Holzhueter : > Hi, > > Am 22.03.13 09:57, schrieb pfelecan: > > CSWctags supplies the "Exuberant ctags" which is compatible with > > the etags/ctags provided also by CSWemacs-bin-common. > > > > Currently, both packages override the collision on the > > /opt/csw/bin/ctags component. > > > > I think that the time to use alternatives has come. Thus, I > > implemented the needed mechanism for the one provided by the > > package under my maintenanceship and kindly invite the maintainer > > of CSWctags to implement his part. > > We have a dopple package here. Since we also do have CSWectags. > Which looks like the same package. > I would recommand to just remove the CSWctags package. > > Greetings > Jan > > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Fri Mar 22 15:38:14 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 22 Mar 2013 14:38:14 +0000 Subject: [csw-maintainers] CSWemacscommon vs. CSWemacs-common as a run-time dependency In-Reply-To: References: Message-ID: 2013/3/22 pfelecan : > Please explore this issue and eventually provide a solution. Sounds like checkpkg finds a .el file and has an idea that a package containing these files should depend on CSWemacscommon. If you grep lib/python for CSWemacscommon, it should become clear what's happening and how to fix it. When the code is updated, Ben can roll a new cswutils package and install it on login. Maciej From Joerg.Schilling at fokus.fraunhofer.de Fri Mar 22 17:10:02 2013 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Fri, 22 Mar 2013 17:10:02 +0100 Subject: [csw-maintainers] ctags alternate proposition In-Reply-To: <514C1E35.10607@opencsw.org> References: <514C1E35.10607@opencsw.org> Message-ID: <514c825a.TiRH8WaDjQQzlI08%Joerg.Schilling@fokus.fraunhofer.de> Jan Holzhueter wrote: > Am 22.03.13 09:57, schrieb pfelecan: > > CSWctags supplies the "Exuberant ctags" which is compatible with > > the etags/ctags provided also by CSWemacs-bin-common. > > > > Currently, both packages override the collision on the > > /opt/csw/bin/ctags component. > > > > I think that the time to use alternatives has come. Thus, I > > implemented the needed mechanism for the one provided by the > > package under my maintenanceship and kindly invite the maintainer > > of CSWctags to implement his part. > > We have a dopple package here. Since we also do have CSWectags. > Which looks like the same package. > I would recommand to just remove the CSWctags package. ctags is a program that belongs to the "vi" source - not to the emacs source if that matters.... 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 pfelecan at opencsw.org Fri Mar 22 20:07:36 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 22 Mar 2013 20:07:36 +0100 Subject: [csw-maintainers] ctags alternate proposition In-Reply-To: <514C1E35.10607@opencsw.org> (Jan Holzhueter's message of "Fri, 22 Mar 2013 10:02:45 +0100") References: <514C1E35.10607@opencsw.org> Message-ID: Jan Holzhueter writes: > Hi, > > Am 22.03.13 09:57, schrieb pfelecan: >> CSWctags supplies the "Exuberant ctags" which is compatible with >> the etags/ctags provided also by CSWemacs-bin-common. >> >> Currently, both packages override the collision on the >> /opt/csw/bin/ctags component. >> >> I think that the time to use alternatives has come. Thus, I >> implemented the needed mechanism for the one provided by the >> package under my maintenanceship and kindly invite the maintainer >> of CSWctags to implement his part. > > We have a dopple package here. Since we also do have CSWectags. > Which looks like the same package. > I would recommand to just remove the CSWctags package. Well, I didn't ssaw it. However, I think that the removal should be done by its maintainer, if active. Isn't it? -- Peter From pfelecan at opencsw.org Fri Mar 22 20:11:51 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 22 Mar 2013 20:11:51 +0100 Subject: [csw-maintainers] ctags alternate proposition In-Reply-To: <514c825a.TiRH8WaDjQQzlI08%Joerg.Schilling@fokus.fraunhofer.de> (Joerg Schilling's message of "Fri, 22 Mar 2013 17:10:02 +0100") References: <514C1E35.10607@opencsw.org> <514c825a.TiRH8WaDjQQzlI08%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: Joerg Schilling writes: > Jan Holzhueter wrote: > >> Am 22.03.13 09:57, schrieb pfelecan: >> > CSWctags supplies the "Exuberant ctags" which is compatible with >> > the etags/ctags provided also by CSWemacs-bin-common. >> > >> > Currently, both packages override the collision on the >> > /opt/csw/bin/ctags component. >> > >> > I think that the time to use alternatives has come. Thus, I >> > implemented the needed mechanism for the one provided by the >> > package under my maintenanceship and kindly invite the maintainer >> > of CSWctags to implement his part. >> >> We have a dopple package here. Since we also do have CSWectags. >> Which looks like the same package. >> I would recommand to just remove the CSWctags package. > > ctags is a program that belongs to the "vi" source - not to the emacs source if > that matters.... Sure, the Emacs delivered ctags is based on its "etags" and it's compatible with the ol' vi's ctags. "ectags" is a advanced, multi-lingual tag extractor. Anyhow, this is why I provided an alternative for Emacs's ctags. If we have vim, the same should apply. -- Peter From pfelecan at opencsw.org Fri Mar 22 20:13:07 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 22 Mar 2013 20:13:07 +0100 Subject: [csw-maintainers] CSWemacscommon vs. CSWemacs-common as a run-time dependency In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Fri, 22 Mar 2013 14:38:14 +0000") References:

Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/3/22 pfelecan : >> Please explore this issue and eventually provide a solution. > > Sounds like checkpkg finds a .el file and has an idea that a package > containing these files should depend on CSWemacscommon. If you grep > lib/python for CSWemacscommon, it should become clear what's happening > and how to fix it. > > When the code is updated, Ben can roll a new cswutils package and > install it on login. Thank you for the diagnostic. If I correctly understood, Ben is doing the modification &c? -- Peter From maciej at opencsw.org Fri Mar 22 21:53:18 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 22 Mar 2013 20:53:18 +0000 Subject: [csw-maintainers] CSWemacscommon vs. CSWemacs-common as a run-time dependency In-Reply-To: References:

Message-ID: 2013/3/22 Peter FELECAN : > "Maciej (Matchek) Blizi?ski" writes: > >> 2013/3/22 pfelecan : >>> Please explore this issue and eventually provide a solution. >> >> Sounds like checkpkg finds a .el file and has an idea that a package >> containing these files should depend on CSWemacscommon. If you grep >> lib/python for CSWemacscommon, it should become clear what's happening >> and how to fix it. >> >> When the code is updated, Ben can roll a new cswutils package and >> install it on login. > > Thank you for the diagnostic. If I correctly understood, Ben is doing > the modification &c? It'll be simpler if you do the modification and test that it actually does what you want it to, then submit the change and hand over to Ben. Maciej From maciej at opencsw.org Sat Mar 23 12:59:08 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 23 Mar 2013 11:59:08 +0000 Subject: [csw-maintainers] How to remove dialog_minimal from unstable? In-Reply-To: References:

Message-ID: 2013/3/20 Peter Bonivart : > Thanks for explaining, it's not a common enough op to justify > optimizing I guess. Maybe just output something like "this may take a > while" because with no output for over three hours I think most would > have given up. Maybe there's a nice place somewhere in the code to > output a dot for progress. :) Agreed. The patch is in your inbox for testing. One problem with the script is that you need to manually clean the revdep json files, otherwise the reverse dependency data will be stale and you might get wrong results. Maciej From pfelecan at opencsw.org Sat Mar 23 15:28:55 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 23 Mar 2013 15:28:55 +0100 Subject: [csw-maintainers] CSWemacscommon vs. CSWemacs-common as a run-time dependency In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Fri, 22 Mar 2013 20:53:18 +0000") References:

Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/3/22 Peter FELECAN : >> "Maciej (Matchek) Blizi?ski" writes: >> >>> 2013/3/22 pfelecan : >>>> Please explore this issue and eventually provide a solution. >>> >>> Sounds like checkpkg finds a .el file and has an idea that a package >>> containing these files should depend on CSWemacscommon. If you grep >>> lib/python for CSWemacscommon, it should become clear what's happening >>> and how to fix it. >>> >>> When the code is updated, Ben can roll a new cswutils package and >>> install it on login. >> >> Thank you for the diagnostic. If I correctly understood, Ben is doing >> the modification &c? > > It'll be simpler if you do the modification and test that it actually > does what you want it to, then submit the change and hand over to Ben. Well, I committed the modifications that I think are needed to have something nearer to the current Emacs packages names. I must confess that I didn't understood everything, consequently, a verification by a knowledgeable person is required. -- Peter From maciej at opencsw.org Sat Mar 23 15:40:27 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 23 Mar 2013 14:40:27 +0000 Subject: [csw-maintainers] CSWemacscommon vs. CSWemacs-common as a run-time dependency In-Reply-To: References:

Message-ID: 2013/3/23 Peter FELECAN : > Well, I committed the modifications that I think are needed to have > something nearer to the current Emacs packages names. I must confess > that I didn't understood everything, consequently, a verification by a > knowledgeable person is required. Your change looks good. Ben, could you reroll cswutils with the new code? Maciej From dam at opencsw.org Sun Mar 24 14:52:43 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 24 Mar 2013 14:52:43 +0100 Subject: [csw-maintainers] GSOC 2013 Message-ID: <3EE63779-255C-4F8D-B974-3F127922C6BC@opencsw.org> Fellow maintainers, I have just finished writing the application of OpenCSW to the Google Summer of Code (GSOC) 2013. For the students to pick I have made a wiki page with all open projects: http://wiki.opencsw.org/gsoc-2013 Please feel free to add project ideas and explanations why this is a good thing not only for OpenCSW, but the whole opensource community. Best regards -- Dago From maciej at opencsw.org Sun Mar 24 18:26:23 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 24 Mar 2013 17:26:23 +0000 Subject: [csw-maintainers] GSOC 2013 In-Reply-To: <3EE63779-255C-4F8D-B974-3F127922C6BC@opencsw.org> References: <3EE63779-255C-4F8D-B974-3F127922C6BC@opencsw.org> Message-ID: 2013/3/24 Dagobert Michelsen : > Please feel free to add project ideas and explanations why this is a > good thing not only for OpenCSW, but the whole opensource community. |woody| suggested the project to bootstrap and build into a different prefix ? I added it to the wiki. I also added more information to the IPS project, including some references to posts of people asking about IPS. The idea is to show that there is interest in this feature. Maciej From maciej at opencsw.org Mon Mar 25 01:11:34 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 25 Mar 2013 00:11:34 +0000 Subject: [csw-maintainers] The catalog is broken Message-ID: ERROR! Dependency CSWsvn-dev of package CSWsvn-devel is missing. I don't have the state of who did what with Subversion recently. In any case, please fix! Maciej From jh at opencsw.org Mon Mar 25 08:10:44 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Mon, 25 Mar 2013 08:10:44 +0100 Subject: [csw-maintainers] Buildfarm crashed Message-ID: <514FF874.8000800@opencsw.org> Hi, sorry for the downtime. Looks like the power was lost this morning. Don't know why yet. But we are up and running again. Greetings Jan From jh at opencsw.org Mon Mar 25 08:36:29 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Mon, 25 Mar 2013 08:36:29 +0100 Subject: [csw-maintainers] Buildfarm crashed In-Reply-To: <514FF874.8000800@opencsw.org> References: <514FF874.8000800@opencsw.org> Message-ID: <514FFE7D.9070803@opencsw.org> Hi, someone please enable the cataloge sign service again :) Thank you Am 25.03.13 08:10, schrieb Jan Holzhueter: > Hi, > sorry for the downtime. Looks like the power was lost this morning. > Don't know why yet. But we are up and running again. > > Greetings > Jan > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From yann at pleiades.fr.eu.org Mon Mar 25 23:00:41 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Mon, 25 Mar 2013 23:00:41 +0100 Subject: [csw-maintainers] CSWlibssl1-0-0 missing 64bit lib In-Reply-To: <1CC1A1F1-8914-45FF-BD8F-714FCBB8D3D8@opencsw.org> References:

<29EF90D5-EDEA-4A00-B2CA-82A015D7C59B@opencsw.org> <5146FFC4.6030308@opencsw.org> <1CC1A1F1-8914-45FF-BD8F-714FCBB8D3D8@opencsw.org> Message-ID: HI Dago, 2013/3/21 Dagobert Michelsen > "solaris64-sparcv9-cc-sunw","cc:-xtarget=ultra -m64 -Qoption cg > -xregs=no%appl -xO5 -xstrconst -xdepend -xspace -Xa > -DB_ENDIAN::-D_REENTRANT:ULTRASPARC:-lsocket -lnsl -lc:BN_LLONG RC4_CHUNK > DES_INT DES_PTR DES_RISC1 > DES_UNROLL=BF_PTR:${sparcv9_asm}:dlfcn:solaris-shared:-KPIC:-m64 -G -dy -z > text -zdefs -Bdirect -zignore > -M/usr/lib/ld/map.pagealign:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):/usr/ccs/bin/ar > rs::/64", > > There we have it: the further is lacking ::/64 at the end leading to the > libraries being > installed in wrong directories. I didn't feel like patching configure > (feel free to do so > and report upstream) but added --libdir as needed to the Makefile in > addition to some > minor tweaks: > http://sourceforge.net/apps/trac/gar/changeset/20494 > Thanks a lot for the help ! That works a like a charm. > > I suggest adding tests to the testsuite to see if there are actually files > in /opt/csw/(bin|sbin|lib|libHi Yann, > Yes that's a good idea. I added the test in gar: http://sourceforge.net/apps/trac/gar/changeset/20521 There is a problem when several packages are built from one recipe: BUILD64 can be enabled to produce the 64 bits libraries, but one of the package could contains only 32 bits executables by choice. I found for example the a52dec package which has this problem. For now, the test only checks missing executables if isaexec is enabled, but it can be improved if I can know if BUILD64 or BUILD64_LIBS_ONLY has been used in the recipe. Is this possible to add this information in OPENCSW_MODE64 ? Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Tue Mar 26 12:03:20 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 26 Mar 2013 12:03:20 +0100 Subject: [csw-maintainers] CSWlibssl1-0-0 missing 64bit lib In-Reply-To: References:

<29EF90D5-EDEA-4A00-B2CA-82A015D7C59B@opencsw.org> <5146FFC4.6030308@opencsw.org> <1CC1A1F1-8914-45FF-BD8F-714FCBB8D3D8@opencsw.org> Message-ID: <7CDFDBDF-7EC7-41F3-A24C-D6E5B41DF6D1@opencsw.org> Hallo Yann, Am 25.03.2013 um 23:00 schrieb Yann Rouillard: > 2013/3/21 Dagobert Michelsen >> "solaris64-sparcv9-cc-sunw","cc:-xtarget=ultra -m64 -Qoption cg -xregs=no%appl -xO5 -xstrconst -xdepend -xspace -Xa -DB_ENDIAN::-D_REENTRANT:ULTRASPARC:-lsocket -lnsl -lc:BN_LLONG RC4_CHUNK DES_INT DES_PTR DES_RISC1 DES_UNROLL=BF_PTR:${sparcv9_asm}:dlfcn:solaris-shared:-KPIC:-m64 -G -dy -z text -zdefs -Bdirect -zignore -M/usr/lib/ld/map.pagealign:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):/usr/ccs/bin/ar rs::/64", >> >> There we have it: the further is lacking ::/64 at the end leading to the libraries being >> installed in wrong directories. I didn't feel like patching configure (feel free to do so >> and report upstream) but added --libdir as needed to the Makefile in addition to some >> minor tweaks: >> http://sourceforge.net/apps/trac/gar/changeset/20494 > > Thanks a lot for the help ! > That works a like a charm. > > >> I suggest adding tests to the testsuite to see if there are actually files in /opt/csw/(bin|sbin|lib|libHi Yann, > > Yes that's a good idea. > I added the test in gar: http://sourceforge.net/apps/trac/gar/changeset/20521 > > There is a problem when several packages are built from one recipe: BUILD64 can be enabled to produce the 64 bits libraries, but one of the package could contains only 32 bits executables by choice. > I found for example the a52dec package which has this problem. > > For now, the test only checks missing executables if isaexec is enabled, but it can be improved if I can know if BUILD64 or BUILD64_LIBS_ONLY has been used in the recipe. > Is this possible to add this information in OPENCSW_MODE64 ? Maybe it would be more useful if that case would be explicitly overriden? By now I would consider missing 64 bit binaries a bug as amd64 as the dominant platform is much better than 32 bit x86. Best regards -- Dago From grzemba at contac-dt.de Tue Mar 26 14:19:54 2013 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Tue, 26 Mar 2013 14:19:54 +0100 Subject: [csw-maintainers] ctags alternate proposition In-Reply-To: References: <514C1E35.10607@opencsw.org> Message-ID: I have removed the package CSWctags. Am 22.03.13 schrieb Peter FELECAN : > Jan Holzhueter writes: > > > Hi, > > > > Am 22.03.13 09:57, schrieb pfelecan: > >> CSWctags supplies the "Exuberant ctags" which is compatible with > >> the etags/ctags provided also by CSWemacs-bin-common. > >> > >> Currently, both packages override the collision on the > >> /opt/csw/bin/ctags component. > >> > >> I think that the time to use alternatives has come. Thus, I > >> implemented the needed mechanism for the one provided by the > >> package under my maintenanceship and kindly invite the maintainer > >> of CSWctags to implement his part. > > > > We have a dopple package here. Since we also do have CSWectags. > > Which looks like the same package. > > I would recommand to just remove the CSWctags package. > > Well, I didn't ssaw it. However, I think that the removal should be done > by its maintainer, if active. Isn't it? > -- > Peter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jh at opencsw.org Wed Mar 27 20:01:25 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Wed, 27 Mar 2013 20:01:25 +0100 Subject: [csw-maintainers] Farm died again sorry. Message-ID: <51534205.1040803@opencsw.org> Hi, the farm crashed again. I'm sorry for that. We probably hit the zfs send bug again. Even though oracle told us it will not happen :) It takes some time until the memory is dumped. I hope to have it back up asap. Greetings Jan From dam at opencsw.org Wed Mar 27 22:00:38 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 27 Mar 2013 22:00:38 +0100 Subject: [csw-maintainers] Farm died again sorry. In-Reply-To: <51534205.1040803@opencsw.org> References: <51534205.1040803@opencsw.org> Message-ID: <9E538F4C-0A63-451F-9684-0A85DB6343AD@opencsw.org> Hi folks, Am 27.03.2013 um 20:01 schrieb Jan Holzhueter: > the farm crashed again. I'm sorry for that. We probably hit the zfs send > bug again. Even though oracle told us it will not happen :) > It takes some time until the memory is dumped. I hope to have it back up > asap. The farm is up again. Maciej, Ben: Could any of you gentlemen please restart the signing? Best regards -- Dago From jgoerzen at opencsw.org Thu Mar 28 00:15:03 2013 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Wed, 27 Mar 2013 16:15:03 -0700 Subject: [csw-maintainers] Catalog genration broken? Message-ID: <51537D77.9080503@opencsw.org> Hello, I recently csw-upload-pkg'ed a number of packages but I have had no email "catalog update report" sent yet. Nor has the updated packages shown up in the unstable catalog yet. I usually get these email's within a few hours. I see there was an issue recently with the buildfarm perhaps a service didn't get restarted yet? /Jake From maciej at opencsw.org Thu Mar 28 00:58:50 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 27 Mar 2013 23:58:50 +0000 Subject: [csw-maintainers] Catalog genration broken? In-Reply-To: <51537D77.9080503@opencsw.org> References: <51537D77.9080503@opencsw.org> Message-ID: 2013/3/27 Jake Goerzen