From pfelecan at opencsw.org Fri Dec 2 19:43:56 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 02 Dec 2011 19:43:56 +0100 Subject: [csw-maintainers] GCC 4.6.2 C++ front issue In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Tue, 29 Nov 2011 09:04:03 +0000") References: Message-ID: The minimal program: int main() {} compiles, links (g++ -o c c.cc) but doesn't run; the following error message is reported: ld.so.1: c: fatal: libstdc++.so.6: open failed: No such file or directory and ldd reports: libstdc++.so.6 => (file not found) libm.so.2 => /lib/libm.so.2 libgcc_s.so.1 => (file not found) libc.so.1 => /lib/libc.so.1 If reporting this in Mantis or in private is preferred, I'll do it. type g++ : g++ is /opt/csw/bin/g++ g++ --version : g++ (GCC) 4.6.2 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Peter From maciej at opencsw.org Fri Dec 2 21:21:54 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 2 Dec 2011 20:21:54 +0000 Subject: [csw-maintainers] GCC 4.6.2 C++ front issue In-Reply-To: References: Message-ID: 2011/12/2 Peter FELECAN : > The minimal program: > > int main() {} > > compiles, links (g++ -o c c.cc) but doesn't run; the following error > message is reported: > > ? ? ? ?ld.so.1: c: fatal: libstdc++.so.6: open failed: No such file or > ? ? ? ?directory > > and ldd reports: > ? ? ? ?libstdc++.so.6 => ? ? ? ?(file not found) > ? ? ? ?libm.so.2 => ? ? /lib/libm.so.2 > ? ? ? ?libgcc_s.so.1 => ? ? ? ? (file not found) > ? ? ? ?libc.so.1 => ? ? /lib/libc.so.1 > > If reporting this in Mantis or in private is preferred, I'll do it. Yes, please do. It's good for tracking progress. This behavior is known, it has always been like this. Before I relocated the shared libraries, it was more obvious what to do, because libstdc++ was in a nonstandard location (outside /opt/csw/lib), and you had to add -R/opt/csw/gcc4/lib. Right now, the library is in a standard location (/opt/csw/lib), but gcc won't add it to the runpath by default. I'm not sure whether it's a good or a bad thing. There's a way to make gcc always add /opt/csw/lib to the runpath. One thing to do would be making sure that we can add a path that precedes /opt/csw/lib, otherwise it would be impossible to get out of problems such as the one with libnet. This was discussed some time ago on gcc-help. It's very easy to do it wrong. For example, if you compile with -m64, then you need to add -R/opt/csw/lib/64, and not -R/opt/csw/lib, and it has to be somehow expressed in the patch for the gcc sources. References: FAQ item: http://gcc.gnu.org/faq.html#rpath gcc-help thread: http://permalink.gmane.org/gmane.comp.gcc.help/39282 SFW thread: http://goo.gl/YUuyn Maciej From pfelecan at opencsw.org Sat Dec 3 09:23:52 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 03 Dec 2011 09:23:52 +0100 Subject: [csw-maintainers] GCC 4.6.2 C++ front issue In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Fri, 2 Dec 2011 20:21:54 +0000") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2011/12/2 Peter FELECAN : >> The minimal program: >> >> int main() {} >> >> compiles, links (g++ -o c c.cc) but doesn't run; the following error >> message is reported: >> >> ? ? ? ?ld.so.1: c: fatal: libstdc++.so.6: open failed: No such file or >> ? ? ? ?directory >> >> and ldd reports: >> ? ? ? ?libstdc++.so.6 => ? ? ? ?(file not found) >> ? ? ? ?libm.so.2 => ? ? /lib/libm.so.2 >> ? ? ? ?libgcc_s.so.1 => ? ? ? ? (file not found) >> ? ? ? ?libc.so.1 => ? ? /lib/libc.so.1 >> >> If reporting this in Mantis or in private is preferred, I'll do it. > > Yes, please do. It's good for tracking progress. I'll do. > This behavior is known, it has always been like this. Before I > relocated the shared libraries, it was more obvious what to do, > because libstdc++ was in a nonstandard location (outside > /opt/csw/lib), and you had to add -R/opt/csw/gcc4/lib. Right now, the > library is in a standard location (/opt/csw/lib), but gcc won't add it > to the runpath by default. This was never an issue with gcc3 or gcc4 before. > I'm not sure whether it's a good or a bad thing. > > There's a way to make gcc always add /opt/csw/lib to the runpath. > > One thing to do would be making sure that we can add a path that > precedes /opt/csw/lib, otherwise it would be impossible to get out of > problems such as the one with libnet. > > This was discussed some time ago on gcc-help. It's very easy to do it > wrong. For example, if you compile with -m64, then you need to add > -R/opt/csw/lib/64, and not -R/opt/csw/lib, and it has to be somehow > expressed in the patch for the gcc sources. This is managed by the specification file which support conditionals. -- Peter From maciej at opencsw.org Sat Dec 3 11:29:52 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 3 Dec 2011 10:29:52 +0000 Subject: [csw-maintainers] GCC 4.6.2 C++ front issue In-Reply-To: References: Message-ID: 2011/12/3 Peter FELECAN : > "Maciej (Matchek) Blizi?ski" writes: > >> 2011/12/2 Peter FELECAN : >>> The minimal program: >>> >>> int main() {} >>> >>> compiles, links (g++ -o c c.cc) but doesn't run; the following error >>> message is reported: >>> >>> ? ? ? ?ld.so.1: c: fatal: libstdc++.so.6: open failed: No such file or >>> ? ? ? ?directory >>> >>> and ldd reports: >>> ? ? ? ?libstdc++.so.6 => ? ? ? ?(file not found) >>> ? ? ? ?libm.so.2 => ? ? /lib/libm.so.2 >>> ? ? ? ?libgcc_s.so.1 => ? ? ? ? (file not found) >>> ? ? ? ?libc.so.1 => ? ? /lib/libc.so.1 >>> >>> If reporting this in Mantis or in private is preferred, I'll do it. >> >> Yes, please do. ?It's good for tracking progress. > > I'll do. > >> This behavior is known, it has always been like this. ?Before I >> relocated the shared libraries, it was more obvious what to do, >> because libstdc++ was in a nonstandard location (outside >> /opt/csw/lib), and you had to add -R/opt/csw/gcc4/lib. ?Right now, the >> library is in a standard location (/opt/csw/lib), but gcc won't add it >> to the runpath by default. > > This was never an issue with gcc3 or gcc4 before. It doesn't look like a regression to me. Not from gcc-4.3.3, anyway. Please test with gcc-4.3.3 on the current* hosts. maciej at current10x [current10x]:~/src/tmp $ echo "int main() {}" > test.cc maciej at current10x [current10x]:~/src/tmp $ /opt/csw/gcc4/bin/g++ test.cc -o test maciej at current10x [current10x]:~/src/tmp $ ./test ld.so.1: test: fatal: libstdc++.so.6: open failed: No such file or directory Killed maciej at current10x [current10x]:~/src/tmp $ ldd test libstdc++.so.6 => (file not found) libm.so.2 => /lib/libm.so.2 libgcc_s.so.1 => (file not found) libc.so.1 => /lib/libc.so.1 maciej at current10x [current10x]:~/src/tmp $ /opt/csw/gcc4/bin/g++ -v Using built-in specs. Target: i386-pc-solaris2.10 Configured with: ../gcc-4.3.3/configure --prefix=/opt/csw/gcc4 --exec-prefix=/opt/csw/gcc4 --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-nls --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x --with-mpfr=/opt/csw --with-gmp=/opt/csw --enable-java-awt=xlib --enable-libada --enable-libssp --enable-objc-gc --enable-threads=posix --enable-stage1-languages=c --enable-languages=ada,c,c++,fortran,java,objc Thread model: posix gcc version 4.3.3 (GCC) maciej at current10x [current10x]:~/src/tmp $ /usr/sbin/pkgchk -l -p /opt/csw/gcc4/bin/g++ NOTE: Couldn't lock the package database. Pathname: /opt/csw/gcc4/bin/g++ Type: linked file Source of link: /opt/csw/bin/isaexec Referenced by the following packages: CSWgcc4g++ Current status: installed maciej at current10x [current10x]:~/src/tmp $ pkginfo -l CSWgcc4g++ PKGINST: CSWgcc4g++ NAME: gcc4g++ - GNU C++ Compiler CATEGORY: application ARCH: i386 VERSION: 4.3.3,REV=2009.05.07 BASEDIR: / VENDOR: http://mirrors.kernel.org/gnu/gcc//gcc-4.3.3/ packaged for CSW by Mike Watters PSTAMP: mwatters at build8x-20090507210353 INSTDATE: Dec 08 2009 15:00 HOTLINE: http://www.opencsw.org/bugtrack/ EMAIL: mwatters at opencsw.org STATUS: completely installed FILES: 755 installed pathnames 14 shared pathnames 2 linked files 61 directories 14 executables 220021 blocks used (approx) You are right that gcc3 uses custom specs and adds the runpath by default. maciej at current10x [current10x]:~/src/tmp $ rm test maciej at current10x [current10x]:~/src/tmp $ /opt/csw/gcc3/bin/g++ -o test test.cc maciej at current10x [current10x]:~/src/tmp $ /usr/ccs/bin/dump -Lv test | grep RPATH [7] RPATH /opt/csw/lib maciej at current10x [current10x]:~/src/tmp $ /opt/csw/gcc3/bin/g++ -v Reading specs from /opt/csw/gcc3/lib/gcc/i386-pc-solaris2.8/3.4.6/specs Configured with: ../sources/gcc-3.4.6/configure --prefix=/opt/csw/gcc3 --with-local-prefix=/opt/csw --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix --enable-shared --enable-multilib --enable-nls --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x --enable-java-awt=xlib --enable-languages=all Thread model: posix gcc version 3.4.6 Do we have the build recipe for gcc-3.4.6? >> I'm not sure whether it's a good or a bad thing. >> >> There's a way to make gcc always add /opt/csw/lib to the runpath. >> >> One thing to do would be making sure that we can add a path that >> precedes /opt/csw/lib, otherwise it would be impossible to get out of >> problems such as the one with libnet. >> >> This was discussed some time ago on gcc-help. It's very easy to do it >> wrong. For example, if you compile with -m64, then you need to add >> -R/opt/csw/lib/64, and not -R/opt/csw/lib, and it has to be somehow >> expressed in the patch for the gcc sources. > > This is managed by the specification file which support conditionals. Are you already familiar with this file? For example, do you know the syntax? Maciej From pfelecan at opencsw.org Sat Dec 3 13:43:53 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 03 Dec 2011 13:43:53 +0100 Subject: [csw-maintainers] GCC 4.6.2 C++ front issue In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sat, 3 Dec 2011 10:29:52 +0000") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2011/12/3 Peter FELECAN : >> "Maciej (Matchek) Blizi?ski" writes: >> >>> This behavior is known, it has always been like this. ?Before I >>> relocated the shared libraries, it was more obvious what to do, >>> because libstdc++ was in a nonstandard location (outside >>> /opt/csw/lib), and you had to add -R/opt/csw/gcc4/lib. ?Right now, the >>> library is in a standard location (/opt/csw/lib), but gcc won't add it >>> to the runpath by default. >> >> This was never an issue with gcc3 or gcc4 before. > > It doesn't look like a regression to me. Not from gcc-4.3.3, anyway. > Please test with gcc-4.3.3 on the current* hosts. > [...] > maciej at current10x [current10x]:~/src/tmp $ /opt/csw/gcc3/bin/g++ -v > Reading specs from /opt/csw/gcc3/lib/gcc/i386-pc-solaris2.8/3.4.6/specs > Configured with: ../sources/gcc-3.4.6/configure --prefix=/opt/csw/gcc3 > --with-local-prefix=/opt/csw --with-gnu-as --with-as=/opt/csw/bin/gas > --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix > --enable-shared --enable-multilib --enable-nls --with-included-gettext > --with-libiconv-prefix=/opt/csw --with-x --enable-java-awt=xlib > --enable-languages=all > Thread model: posix > gcc version 3.4.6 > > Do we have the build recipe for gcc-3.4.6? Of course we have the build recipe. Not as GAR but using my build system. If you look at ~pefelecan/CSW/patches/gcc3* you have every applied patch. The ~pfelecan/CSW/customs/gcc3-3.4.6-specs.awk files contains the "magic" for patching the spec file. As I remember, gcc4 doesn't provide an explicit specification file (it can be generated and used) but in the first 4th branch I provided one because it allowed the specifications patching. >>> This was discussed some time ago on gcc-help. It's very easy to do it >>> wrong. For example, if you compile with -m64, then you need to add >>> -R/opt/csw/lib/64, and not -R/opt/csw/lib, and it has to be somehow >>> expressed in the patch for the gcc sources. >> >> This is managed by the specification file which support conditionals. > > Are you already familiar with this file? For example, do you know the syntax? Yes. It's quite easy to use it. Have a look and the syntax and meaning will become evident after a while. If you need help let me know. In my gcc3 packaging I've patched the supplied file. BTW, the file is generated using the content of specific macros documented in gccint-*.*.info file, section "17.2 Controlling the Compilation Driver, `gcc'"; the info file contain almost everything needed to port, build and package. Unfortunately is not the way that I choose in my packaging but I strongly recommend it. HTH -- Peter From rupert at opencsw.org Sat Dec 3 19:39:03 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 3 Dec 2011 19:39:03 +0100 Subject: [csw-maintainers] why mgar prefers 9s to 10s? Message-ID: hi, do i expect something what it should not do by expecting it should prefer 10s now? rupert @ unstable10s : ~/mgar-sav/pkg/subversion/trunk $ mgar package /home/rupert/mgar-sav/pkg/.buildsys/v2/gar//gar.pkg.mk:886: *** You are building this package on a non-requested platform host 'unstable10s'. The following platforms were requested: /home/rupert/mgar-sav/pkg/.buildsys/v2/gar//gar.pkg.mk:886: *** - solaris9-sparc to be build on host 'unstable9s' /home/rupert/mgar-sav/pkg/.buildsys/v2/gar//gar.pkg.mk:886: *** - solaris9-i386 to be build on host 'unstable9x' /home/rupert/mgar-sav/pkg/.buildsys/v2/gar//gar.pkg.mk:886: *** You can execute 'gmake platforms' to automatically build on all necessary platforms.. Stop. rupert From maciej at opencsw.org Sat Dec 3 20:08:57 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 3 Dec 2011 19:08:57 +0000 Subject: [csw-maintainers] why mgar prefers 9s to 10s? In-Reply-To: References: Message-ID: 2011/12/3 rupert THURNER : > rupert @ unstable10s : ~/mgar-sav/pkg/subversion/trunk > $ mgar package > /home/rupert/mgar-sav/pkg/.buildsys/v2/gar//gar.pkg.mk:886: *** You > are building this package on a non-requested platform host Look up: PACKAGING_PLATFORMS At: http://sourceforge.net/apps/trac/gar/wiki/Platforms Also: /etc/opt/csw/garrc From rupert at opencsw.org Sat Dec 3 21:15:16 2011 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 3 Dec 2011 21:15:16 +0100 Subject: [csw-maintainers] why mgar prefers 9s to 10s? In-Reply-To: References: Message-ID: didn't we decide to drop solaris9 compile for new releases a couple of weeks ago? 2011/12/3 Maciej (Matchek) Blizi?ski : > 2011/12/3 rupert THURNER : >> rupert @ unstable10s : ~/mgar-sav/pkg/subversion/trunk >> $ mgar package >> /home/rupert/mgar-sav/pkg/.buildsys/v2/gar//gar.pkg.mk:886: *** You >> are building this package on a non-requested platform host > > Look up: PACKAGING_PLATFORMS > > At: http://sourceforge.net/apps/trac/gar/wiki/Platforms > > Also: /etc/opt/csw/garrc > _______________________________________________ > 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 Sat Dec 3 21:19:55 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 3 Dec 2011 20:19:55 +0000 Subject: [csw-maintainers] why mgar prefers 9s to 10s? In-Reply-To: References: Message-ID: 2011/12/3 rupert THURNER : > didn't we decide to drop solaris9 compile for new releases a couple of > weeks ago? We changed Solaris 9 support into best effort, it doesn't mean that we don't compile for Solaris 9 any more. Maciej From pfelecan at opencsw.org Sun Dec 4 12:16:46 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 04 Dec 2011 12:16:46 +0100 Subject: [csw-maintainers] why mgar prefers 9s to 10s? In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sat, 3 Dec 2011 20:19:55 +0000") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2011/12/3 rupert THURNER : >> didn't we decide to drop solaris9 compile for new releases a couple of >> weeks ago? > > We changed Solaris 9 support into best effort, it doesn't mean that we > don't compile for Solaris 9 any more. >From my point of view, best effort attitude make it optional to deliver a Solaris 9 package if the packager's best effort is to deliver a Solaris 10 one. As an adept of Hamilton, I'm all for this minimal effort. -- Peter From pfelecan at opencsw.org Sun Dec 4 12:28:11 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 04 Dec 2011 12:28:11 +0100 Subject: [csw-maintainers] the role and content of snapshots directory in the mirror Message-ID: What's the role of the snapshots directory in the mirror? there are a bunch of stuff there... Everything else is explained in the README file but not this. -- Peter From maciej at opencsw.org Sun Dec 4 12:45:05 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 4 Dec 2011 11:45:05 +0000 Subject: [csw-maintainers] the role and content of snapshots directory in the mirror In-Reply-To: References: Message-ID: 2011/12/4 Peter FELECAN : > What's the role of the snapshots directory in the mirror? there are a > bunch of stuff there... Everything else is explained in the README file > but not this. I don't see the snapshots directory here: http://mirror.opencsw.org/opencsw/ The idea of snapshots has been replaced with named releases, I killed the snapshots directory. Where do you see it? Maciej From maciej at opencsw.org Sun Dec 4 12:48:42 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 4 Dec 2011 11:48:42 +0000 Subject: [csw-maintainers] why mgar prefers 9s to 10s? In-Reply-To: References: Message-ID: 2011/12/4 Peter FELECAN : > From my point of view, best effort attitude make it optional to deliver > a Solaris 9 package if the packager's best effort is to deliver a > Solaris 10 one. As an adept of Hamilton, I'm all for this minimal > effort. William Rowan Hamilton, known for the Hamiltonian path in graph theory? Maciej From pfelecan at opencsw.org Sun Dec 4 13:55:45 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 04 Dec 2011 13:55:45 +0100 Subject: [csw-maintainers] why mgar prefers 9s to 10s? In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sun, 4 Dec 2011 11:48:42 +0000") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2011/12/4 Peter FELECAN : >> From my point of view, best effort attitude make it optional to deliver >> a Solaris 9 package if the packager's best effort is to deliver a >> Solaris 10 one. As an adept of Hamilton, I'm all for this minimal >> effort. > > William Rowan Hamilton, known for the Hamiltonian path in graph theory? Yes. -- Peter From pfelecan at opencsw.org Sun Dec 4 14:00:05 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 04 Dec 2011 14:00:05 +0100 Subject: [csw-maintainers] the role and content of snapshots directory in the mirror In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sun, 4 Dec 2011 11:45:05 +0000") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2011/12/4 Peter FELECAN : >> What's the role of the snapshots directory in the mirror? there are a >> bunch of stuff there... Everything else is explained in the README file >> but not this. > > I don't see the snapshots directory here: > > http://mirror.opencsw.org/opencsw/ > > The idea of snapshots has been replaced with named releases, I killed > the snapshots directory. Where do you see it? ftp://ftp.sunet.se/pub/vendor/sun/OpenCSW/snapshots/ but not on other mirrors that I checked. I think that there is something rotten in sunet.se mirror feed. -- Peter From pfelecan at opencsw.org Sun Dec 4 17:21:29 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 04 Dec 2011 17:21:29 +0100 Subject: [csw-maintainers] GCC 4.6.2 C++ front issue In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sat, 3 Dec 2011 10:29:52 +0000") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: >> This is managed by the specification file which support conditionals. > > Are you already familiar with this file? For example, do you know the syntax? gcc.info : "3.15 Specifying subprocesses and the switches to pass to them" explains the syntax of specs files -- Peter From dam at opencsw.org Mon Dec 5 14:08:12 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 5 Dec 2011 14:08:12 +0100 Subject: [csw-maintainers] [csw-buildfarm] ssh key forward not working on buildfarm? In-Reply-To: References: Message-ID: Hi Rupert, [fwd'ing maintainers@] Am 04.12.2011 um 19:30 schrieb rupert THURNER: > while the direct connection "my pc - github" works, i cannot connect > any more via the buildfarm: > rupert @ login : ~/mgar/gar > $ git push origin master > Permission denied (publickey). > fatal: The remote end hung up unexpectedly > > on my local machine i configured that my key is forwarded: > > $ cat .ssh/config > Host * > ForwardAgent yes > > as i am not regulary using github out of the csw buildfarm, i am not > sure when what changed. can it be that the buildfarm is responsible > for this behaviour? This should work. How about increasing verbosity or tracing the agent to see if it is actually used? Best regards -- Dago From maciej at opencsw.org Mon Dec 5 21:01:40 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 5 Dec 2011 20:01:40 +0000 Subject: [csw-maintainers] GCC 4.6 progress In-Reply-To: References: Message-ID: http://buildfarm.opencsw.org/experimental.html#gcc-4.6 Somebody pinch me. From bwalton at opencsw.org Tue Dec 6 14:18:47 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 06 Dec 2011 08:18:47 -0500 Subject: [csw-maintainers] buildfarm update Message-ID: <1323177480-sup-6119@pinkfloyd.chass.utoronto.ca> Hi All, I'm doing pkgutil -Uu on unstable* right now. For the most part, this will only affect gcc packages, but a few other items are being pulled in too. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From pfelecan at opencsw.org Tue Dec 6 14:42:35 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 06 Dec 2011 14:42:35 +0100 Subject: [csw-maintainers] GCC 4.6 progress In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Mon, 5 Dec 2011 20:01:40 +0000") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > http://buildfarm.opencsw.org/experimental.html#gcc-4.6 > > Somebody pinch me. Why? -- Peter From maciej at opencsw.org Tue Dec 6 16:56:31 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 6 Dec 2011 15:56:31 +0000 Subject: [csw-maintainers] GCC 4.6 progress In-Reply-To: References: Message-ID: 2011/12/6 Peter FELECAN : >> http://buildfarm.opencsw.org/experimental.html#gcc-4.6 >> >> Somebody pinch me. > > Why? I see the i386 Solaris 10 gcc4ada package. I close my eyes, open them again, and it doesn't disappear! By the way, I mailed the ada/gnat mailing lists with a request for testing, but the list seems inactive. http://lists.ada.cx/archives/dragonlace/20111206/000034.html I'll also ask on #ada on Freenode. Maciej From maciej at opencsw.org Tue Dec 6 18:16:46 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 6 Dec 2011 17:16:46 +0000 Subject: [csw-maintainers] Integrating from unstable to dublin Message-ID: Assuming that the gcc-4.6 tests (including GNAT) work fine, we'll be ready to integrate package from unstable to dublin. We haven't done any unstable?dublin integrations for a while now, mainly due to package dependencies. My general idea is to take everything from unstable and promote it to dublin. Of course, we'll review the changes before they're applied. On the summercamp, we decided that we need a couple more libraries updated and repackaged, and we can close off the dublin catalog. If anyone knows about any reason not to integrate any packages from unstable to dublin, please speak now! Maciej From jgoerzen at opencsw.org Tue Dec 6 20:05:15 2011 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Tue, 06 Dec 2011 11:05:15 -0800 Subject: [csw-maintainers] dovecot, conf.d directories, and SAMPLECONF In-Reply-To: <4ED42408.2080609@opencsw.org> References: <4ECA9515.4040503@opencsw.org> <4ECA96F9.4080307@opencsw.org> <4ED41D78.2040506@opencsw.org> <4ED42408.2080609@opencsw.org> Message-ID: <4EDE676B.7050601@opencsw.org> On 11/28/11 16:15, Geoff Davis wrote: > On 11/28/11 3:47 PM, Jake Goerzen wrote: >> (bits of original message snipped) >> I wanted to ask, do you know anything about the "conf.d" directory in >> example-config? In the dovecot 2.0 documentation "quick >> configuration" it says to copy dovecot.conf and conf.d from the >> example-config directory. Should I handle this conf.d directory as a >> SAMPLECONF? or just the single dovecot.conf file as previously done? >> > If you understand Dovecot's configuration file format well enough, my > advice would be to throw together a very minimal sample configuration > file that is self-contained in a single file and that doesn't use conf.d. > Thanks for the advice Geoff, I ended up creating a minimal config and it works well. Thanks, Jake From raos at opencsw.org Tue Dec 6 20:25:46 2011 From: raos at opencsw.org (Rafael Ostertag) Date: Tue, 6 Dec 2011 20:25:46 +0100 Subject: [csw-maintainers] Integrating from unstable to dublin In-Reply-To: References: Message-ID: <20111206192546.GH18805@bender.opencsw.org> Hi Maciej On Tue, Dec 06, 2011 at 05:16:46PM +0000, Maciej (Matchek) Blizi??ski wrote: > If anyone knows about any reason not to integrate any packages from > unstable to dublin, please speak now! Not sure if this is OT, but I still have the latest SASL package in the pipeline, which AFAIK should also go into dublin. So, if you would integrate everything now, the latest SASL wouldn't make it into dublin, right? Or could the latest version be released into dublin later on? rafi From jgoerzen at opencsw.org Tue Dec 6 21:23:47 2011 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Tue, 06 Dec 2011 12:23:47 -0800 Subject: [csw-maintainers] Integrating from unstable to dublin In-Reply-To: References: Message-ID: <4EDE79D3.5040902@opencsw.org> On 12/06/11 09:16, Maciej (Matchek) Blizi?ski wrote: > Assuming that the gcc-4.6 tests (including GNAT) work fine, we'll be > ready to integrate package from unstable to dublin. We haven't done > any unstable?dublin integrations for a while now, mainly due to > package dependencies. My general idea is to take everything from > unstable and promote it to dublin. Of course, we'll review the changes > before they're applied. > > On the summercamp, we decided that we need a couple more libraries > updated and repackaged, and we can close off the dublin catalog. > > If anyone knows about any reason not to integrate any packages from > unstable to dublin, please speak now! > Please don't use the CSWdovecot packages in unstable for going into dublin, instead use the previously release packages of rev: dovecot-1.2.17,REV=2011.06.10 These are better tested. Or give me 1 more day to release an updated package that fixes the bug filed against the unstable package. Thanks Jake From maciej at opencsw.org Tue Dec 6 23:30:41 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 6 Dec 2011 22:30:41 +0000 Subject: [csw-maintainers] Integrating from unstable to dublin In-Reply-To: <4EDE79D3.5040902@opencsw.org> References: <4EDE79D3.5040902@opencsw.org> Message-ID: 2011/12/6 Jake Goerzen : > On 12/06/11 09:16, Maciej (Matchek) Blizi?ski wrote: >> If anyone knows about any reason not to integrate any packages from >> unstable to dublin, please speak now! >> > > Please don't use the CSWdovecot packages in unstable for going into dublin, > instead use the previously release packages of rev: > ?dovecot-1.2.17,REV=2011.06.10 ?These are better tested. ? Or give me 1 more > day to release an updated package that fixes the bug filed against the > unstable package. Thanks for the feedback, this is the kind of thing I wanted to coordinate. One day is not a problem. Get the package sorted out, and let us know; then we'll proceed with the integrate. If you will have any subsequent updates you would like to get into dublin, it's possible too. Maciej From pfelecan at opencsw.org Wed Dec 7 09:11:11 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 07 Dec 2011 09:11:11 +0100 Subject: [csw-maintainers] GCC 4.6 progress In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Tue, 6 Dec 2011 15:56:31 +0000") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2011/12/6 Peter FELECAN : >>> http://buildfarm.opencsw.org/experimental.html#gcc-4.6 >>> >>> Somebody pinch me. >> >> Why? > > I see the i386 Solaris 10 gcc4ada package. I close my eyes, open them > again, and it doesn't disappear! > > By the way, I mailed the ada/gnat mailing lists with a request for > testing, but the list seems inactive. > > http://lists.ada.cx/archives/dragonlace/20111206/000034.html > > I'll also ask on #ada on Freenode. Have you run the test suite? Maybe you can publish the results in the package wiki. -- Peter From maciej at opencsw.org Wed Dec 7 10:23:10 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 7 Dec 2011 09:23:10 +0000 Subject: [csw-maintainers] GCC 4.6 progress In-Reply-To: References: Message-ID: 2011/12/7 Peter FELECAN : > Have you run the test suite? Maybe you can publish the results in the > package wiki. No, but it's a good idea, I'll do it once the next round of compilation (this time self-sufficient, no longer dependent on my home directory) finishes. Which package wiki do you have in mind? Maciej From pfelecan at opencsw.org Wed Dec 7 11:09:49 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 07 Dec 2011 11:09:49 +0100 Subject: [csw-maintainers] GCC 4.6 progress In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Wed, 7 Dec 2011 09:23:10 +0000") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2011/12/7 Peter FELECAN : >> Have you run the test suite? Maybe you can publish the results in the >> package wiki. > > No, but it's a good idea, I'll do it once the next round of > compilation (this time self-sufficient, no longer dependent on my home > directory) finishes. > > Which package wiki do you have in mind? This one: http://wiki.opencsw.org/project-gcc-4.6 BTW, when I'm looking to http://www.opencsw.org/get-it/packages/ there is no gcc-4.6 package. What's the source of the list? > > Maciej > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > > -- Peter From maciej at opencsw.org Wed Dec 7 11:21:34 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 7 Dec 2011 10:21:34 +0000 Subject: [csw-maintainers] GCC 4.6 progress In-Reply-To: References: Message-ID: 2011/12/7 Peter FELECAN : > BTW, when I'm looking to http://www.opencsw.org/get-it/packages/ there > is no gcc-4.6 package. What's the source of the list? gcc4core and others are indeed missing. There is a periodic integration job, reading from the buildfarm database and writing into the website database. Maybe Ben can look at it? Maciej From bwalton at opencsw.org Wed Dec 7 14:13:43 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 07 Dec 2011 08:13:43 -0500 Subject: [csw-maintainers] GCC 4.6 progress In-Reply-To: References: Message-ID: <1323263497-sup-7479@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Wed Dec 07 05:21:34 -0500 2011: > gcc4core and others are indeed missing. > > There is a periodic integration job, reading from the buildfarm > database and writing into the website database. Maybe Ben can look at > it? I need Rafael's name added to the pkgdb...and I need to better handle the missing name situation in the integration tools: DEBUG: INSERT INTO packages (software,pkgname,description,version,vendorurl,maintname,maintemail,maintlogin, repositoryurl) VALUES (?,?,?,?,?,?,?,?,?) ./../lib/csw/db/web.rb:137:in `execute': Column 'maintname' cannot be null (Mysql::Error) from ./../lib/csw/db/web.rb:137:in `run_ins_query' from ./../lib/csw/db/web.rb:32:in `register_prj' from ./update_web:166 from ./update_web:164:in `each' from ./update_web:164 This was happening after we cleaned out old versions and then started registering new and updated packages. Will gcc4java4rt and gcc4objcrt be obsoleted? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Wed Dec 7 16:35:46 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 7 Dec 2011 15:35:46 +0000 Subject: [csw-maintainers] GCC 4.6 progress In-Reply-To: <1323263497-sup-7479@pinkfloyd.chass.utoronto.ca> References: <1323263497-sup-7479@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/12/7 Ben Walton : > Excerpts from Maciej (Matchek) Blizi?ski's message of Wed Dec 07 05:21:34 -0500 2011: > >> gcc4core and others are indeed missing. >> >> There is a periodic integration job, reading from the buildfarm >> database and writing into the website database. Maybe Ben can look at >> it? > > I need Rafael's name added to the pkgdb...and I need to better handle > the missing name situation in the integration tools: Rafael Ostertag > DEBUG: INSERT INTO packages > (software,pkgname,description,version,vendorurl,maintname,maintemail,maintlogin, > repositoryurl) VALUES (?,?,?,?,?,?,?,?,?) > ./../lib/csw/db/web.rb:137:in `execute': Column 'maintname' cannot be > null > (Mysql::Error) > ? ?from ./../lib/csw/db/web.rb:137:in `run_ins_query' > ? ?from ./../lib/csw/db/web.rb:32:in `register_prj' > ? ?from ./update_web:166 > ? ?from ./update_web:164:in `each' > ? ?from ./update_web:164 > > This was happening after we cleaned out old versions and then started > registering new and updated packages. > > Will gcc4java4rt and gcc4objcrt be obsoleted? Yes. From jgoerzen at opencsw.org Wed Dec 7 18:40:42 2011 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Wed, 07 Dec 2011 09:40:42 -0800 Subject: [csw-maintainers] Integrating from unstable to dublin In-Reply-To: References: <4EDE79D3.5040902@opencsw.org> Message-ID: <4EDFA51A.8050301@opencsw.org> On 12/06/11 14:30, Maciej (Matchek) Blizi?ski wrote: > 2011/12/6 Jake Goerzen: >> On 12/06/11 09:16, Maciej (Matchek) Blizi?ski wrote: >>> If anyone knows about any reason not to integrate any packages from >>> unstable to dublin, please speak now! >>> >> Please don't use the CSWdovecot packages in unstable for going into dublin, >> instead use the previously release packages of rev: >> dovecot-1.2.17,REV=2011.06.10 These are better tested. Or give me 1 more >> day to release an updated package that fixes the bug filed against the >> unstable package. > Thanks for the feedback, this is the kind of thing I wanted to coordinate. Your welcome. :) Glad to help keep the high quality of packages. > > One day is not a problem. Get the package sorted out, and let us > know; then we'll proceed with the integrate. > > If you will have any subsequent updates you would like to get into > dublin, it's possible too. > Okay, I've uploaded new packages into the catalog with rev: dovecot-2.0.16,REV=2011.12.07-SunOS5.9 These should be alright to integrate into dublin. Thanks, Jake From bwalton at opencsw.org Wed Dec 7 18:42:07 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 07 Dec 2011 12:42:07 -0500 Subject: [csw-maintainers] GCC 4.6 progress In-Reply-To: References: <1323263497-sup-7479@pinkfloyd.chass.utoronto.ca> Message-ID: <1323279547-sup-6784@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Wed Dec 07 10:35:46 -0500 2011: > > I need Rafael's name added to the pkgdb...and I need to better handle > > the missing name situation in the integration tools: > > Rafael Ostertag Yup, I knew the name...I just need it added to the db. Can you poke it in for me? We should implement some mechanism to detect this missing data and auto-populate it based on /etc/passwd from login, me thinks. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Thu Dec 8 18:05:50 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 8 Dec 2011 17:05:50 +0000 Subject: [csw-maintainers] GCC 4.6 progress In-Reply-To: <1323279547-sup-6784@pinkfloyd.chass.utoronto.ca> References: <1323263497-sup-7479@pinkfloyd.chass.utoronto.ca> <1323279547-sup-6784@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/12/7 Ben Walton : > Excerpts from Maciej (Matchek) Blizi?ski's message of Wed Dec 07 10:35:46 -0500 2011: > >> > I need Rafael's name added to the pkgdb...and I need to better handle >> > the missing name situation in the integration tools: >> >> Rafael Ostertag > > Yup, I knew the name...I just need it added to the db. ?Can you poke > it in for me? Done. > ?We should implement some mechanism to detect this > missing data and auto-populate it based on /etc/passwd from login, me > thinks. The database is populated when a package with a new maintainer email is encountered. We could parse the description field and extract names from there. From bwalton at opencsw.org Thu Dec 8 20:55:18 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 08 Dec 2011 14:55:18 -0500 Subject: [csw-maintainers] GCC 4.6 progress In-Reply-To: References: <1323263497-sup-7479@pinkfloyd.chass.utoronto.ca> <1323279547-sup-6784@pinkfloyd.chass.utoronto.ca> Message-ID: <1323374003-sup-5418@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Thu Dec 08 12:05:50 -0500 2011: > > Yup, I knew the name...I just need it added to the db. ?Can you poke > > it in for me? > > Done. Cool, it'll be picked up at the next run. I'm going to catch the exceptions that were generated here and die with a useful error message, but I don't see a sane way to continue here as I'd be required to pick a fake name (The Unknown Maintainer?)... > The database is populated when a package with a new maintainer email > is encountered. We could parse the description field and extract > names from there. Cool, that would work. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From daniel at opencsw.org Fri Dec 9 17:06:03 2011 From: daniel at opencsw.org (Daniel Pocock) Date: Sat, 10 Dec 2011 00:06:03 +0800 Subject: [csw-maintainers] Ganglia (k)stats: per-CPU and per-disk IO Message-ID: <4EE231EB.6020902@opencsw.org> I've put together some modules that use kstat to obtain the following: - per-core CPU metrics (based on the existing libmetrics/solaris code) - per-disk IO statistics, including average service time, wait time, IOps, etc I'd appreciate any feedback from people who try them. Code is here: https://sourceforge.net/p/gmod-solaris/home/ and binaries/packages are already available on OpenCSW: http://buildfarm.opencsw.org/experimental.html#ganglia-modules-solaris This code is largely inspired by code I've seen in other parts of Ganglia. Also, I would like to try and find someone else with an interest in Solaris to be a joint admin on the Sourceforge page. From daniel at opencsw.org Sat Dec 10 11:29:30 2011 From: daniel at opencsw.org (Daniel Pocock) Date: Sat, 10 Dec 2011 18:29:30 +0800 Subject: [csw-maintainers] fontconfig => rrdtool slowness under Apache Message-ID: <4EE3348A.2060603@opencsw.org> There are many discussions around the web about rrdtool running slowly in various situations In my case, I found "rrdtool graph" runs slowly (4-5 seconds per graph, even on a very powerful machine) when generating the graphs for Ganglia web pages. This is on a fresh install of the CSW packages of Apache2, PHP5, rrdtool and fontconfig. In my case, I found that chown nobody /var/opt/csw/cache/fontconfig chown nobody /var/opt/csw/cache/fontconfig/* immediately resolved the issue. On the machine in question: Apache process runs as nobody nobody has shell /usr/bin/false nobody's home = / Can anyone suggest where the blame lies? Is there any other information from my environment that may be helpful in fixing this? Versions: CSWfconfig 2.6.0,REV=2009.04.24 CSWrrdtool 1.4.5,REV=2011.03.21 CSWapache2 2.2.21,REV=2011.10.05 Platform: Solaris 10 x86 Sun x4150, 16 core, 32GB From raos at opencsw.org Sun Dec 11 10:23:29 2011 From: raos at opencsw.org (Rafael Ostertag) Date: Sun, 11 Dec 2011 10:23:29 +0100 Subject: [csw-maintainers] Including -R in pkg-config files Message-ID: <20111211092328.GD404@bender.opencsw.org> Hi Guys I got a bug report (http://www.opencsw.org/bugtrack/view.php?id=4437) where there is a complain that 'pkg-config --libs' does not include the '-R' flag in the output. Now, I would like to know the policy on this, i.e. do we adjust the .pc files to include the -R flag or is it the user's (user as in somebody thirdparty linking against our libs) responsibility to add it to the compiler flags? For us, since we are using gar, this does not pose a problem, I guess. Any pointers on this greatly appreciated. Cheers rafi From maciej at opencsw.org Sun Dec 11 14:15:52 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 11 Dec 2011 13:15:52 +0000 Subject: [csw-maintainers] Including -R in pkg-config files In-Reply-To: <20111211092328.GD404@bender.opencsw.org> References: <20111211092328.GD404@bender.opencsw.org> Message-ID: 2011/12/11 Rafael Ostertag : > I got a bug report (http://www.opencsw.org/bugtrack/view.php?id=4437) where > there is a complain that 'pkg-config --libs' does not include the '-R' flag in > the output. > > Now, I would like to know the policy on this, i.e. do we adjust the .pc files > to include the -R flag or is it the user's (user as in somebody thirdparty > linking against our libs) responsibility to add it to the compiler flags? For > us, since we are using gar, this does not pose a problem, I guess. > > Any pointers on this greatly appreciated. There's no policy on this that I know of. My gut feeling is that it makes sense to add the -R flag there. I see no obvious downsides, and it makes things works for downstream developers. In our case, we keep all libs in /opt/csw/lib, so the -R/opt/csw/lib flag is there in all GAR builds anyway; but for a different reason. If you think of a downstream user, the lack of -R/opt/csw/lib means that any built binaries will be unable to find their libraries. Maciej From bwalton at opencsw.org Sun Dec 11 14:50:37 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 11 Dec 2011 08:50:37 -0500 Subject: [csw-maintainers] Including -R in pkg-config files In-Reply-To: References: <20111211092328.GD404@bender.opencsw.org> Message-ID: <1323611359-sup-6036@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Sun Dec 11 08:15:52 -0500 2011: > There's no policy on this that I know of. My gut feeling is that it > makes sense to add the -R flag there. I see no obvious downsides, > and it makes things works for downstream developers. I agree with this. I think that adding it makes a lot of sense as it will improve the user experience downstream of our packages. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From raos at opencsw.org Sun Dec 11 14:51:42 2011 From: raos at opencsw.org (Rafael Ostertag) Date: Sun, 11 Dec 2011 14:51:42 +0100 Subject: [csw-maintainers] Including -R in pkg-config files In-Reply-To: References: <20111211092328.GD404@bender.opencsw.org> Message-ID: <20111211135142.GE404@bender.opencsw.org> Hi Maciej On Sun, Dec 11, 2011 at 01:15:52PM +0000, Maciej (Matchek) Blizi??ski wrote: > 2011/12/11 Rafael Ostertag : > > I got a bug report (http://www.opencsw.org/bugtrack/view.php?id=4437) where > > there is a complain that 'pkg-config --libs' does not include the '-R' flag in > > the output. > > > > Now, I would like to know the policy on this, i.e. do we adjust the .pc files > > to include the -R flag or is it the user's (user as in somebody thirdparty > > linking against our libs) responsibility to add it to the compiler flags? For > > us, since we are using gar, this does not pose a problem, I guess. > > > > Any pointers on this greatly appreciated. > > There's no policy on this that I know of. My gut feeling is that it > makes sense to add the -R flag there. I see no obvious downsides, and > it makes things works for downstream developers. > > In our case, we keep all libs in /opt/csw/lib, so the -R/opt/csw/lib > flag is there in all GAR builds anyway; but for a different reason. If > you think of a downstream user, the lack of -R/opt/csw/lib means that > any built binaries will be unable to find their libraries. > I see your point there. But a grep on /opt/csw/lib/pkgconfig revelead that only a few packages are employing the -R flag. So, wouldn't it be a good idea to establish a policy on this ('we feature the -R flag by default'), and create a checkpkg test, which softly enforces that policy? Have a nice weekend --rafi From maciej at opencsw.org Sun Dec 11 19:08:54 2011 From: maciej at opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?=) Date: Sun, 11 Dec 2011 18:08:54 +0000 Subject: [csw-maintainers] Including -R in pkg-config files In-Reply-To: <20111211135142.GE404@bender.opencsw.org> References: <20111211092328.GD404@bender.opencsw.org> <20111211135142.GE404@bender.opencsw.org> Message-ID: <20111211180853.GB20389@quince.home.blizinski.pl> Rafael Ostertag wrote: > Hi Maciej > > On Sun, Dec 11, 2011 at 01:15:52PM +0000, Maciej (Matchek) Blizi??ski wrote: > > In our case, we keep all libs in /opt/csw/lib, so the -R/opt/csw/lib > > flag is there in all GAR builds anyway; but for a different reason. If > > you think of a downstream user, the lack of -R/opt/csw/lib means that > > any built binaries will be unable to find their libraries. > > > > I see your point there. But a grep on /opt/csw/lib/pkgconfig revelead that only > a few packages are employing the -R flag. Yes, it's not uncommon to discover a problem in one package, and then realize that it applies to 78%-94% of the whole catalog. > So, wouldn't it be a good idea to establish a policy on this ('we feature the > -R flag by default'), and create a checkpkg test, which softly enforces that > policy? Yes, this is what we do in such situation! The modification to checkpkg will require the addition of parsing of pkginfo files, adding the extracted information to the main data structure, and then reading it during the package check phase. Is it something you would be interested in doing as a programming exercise? I can offer guidance and code / patch reviews. Maciej From bwalton at opencsw.org Mon Dec 12 03:56:08 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 11 Dec 2011 21:56:08 -0500 Subject: [csw-maintainers] Including -R in pkg-config files In-Reply-To: <20111211135142.GE404@bender.opencsw.org> References: <20111211092328.GD404@bender.opencsw.org> <20111211135142.GE404@bender.opencsw.org> Message-ID: <1323658561-sup-6343@pinkfloyd.chass.utoronto.ca> Excerpts from Rafael Ostertag's message of Sun Dec 11 08:51:42 -0500 2011: > So, wouldn't it be a good idea to establish a policy on this ('we > feature the -R flag by default'), and create a checkpkg test, which > softly enforces that policy? +1. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From raos at opencsw.org Mon Dec 12 07:56:03 2011 From: raos at opencsw.org (Rafael Ostertag) Date: Mon, 12 Dec 2011 07:56:03 +0100 Subject: [csw-maintainers] Including -R in pkg-config files In-Reply-To: <20111211180853.GB20389@quince.home.blizinski.pl> References: <20111211092328.GD404@bender.opencsw.org> <20111211135142.GE404@bender.opencsw.org> <20111211180853.GB20389@quince.home.blizinski.pl> Message-ID: <20111212065603.GG404@bender.opencsw.org> Hi Maciej On Sun, Dec 11, 2011 at 06:08:54PM +0000, Maciej Blizi??ski wrote: > Yes, this is what we do in such situation! The modification to checkpkg > will require the addition of parsing of pkginfo files, adding the > extracted information to the main data structure, and then reading it > during the package check phase. > > Is it something you would be interested in doing as a programming > exercise? I can offer guidance and code / patch reviews. Ok, I'm in on this. Cheers rafi From dam at opencsw.org Tue Dec 13 11:13:27 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 13 Dec 2011 11:13:27 +0100 Subject: [csw-maintainers] Need help on C++ linker issue Message-ID: Hi folks, in my effort to build imagemagick 64 bit I encountered a problem with the latest libfpx, where I get unresolved symbols. When look at the methods I see a function with a different mangled name, which has however the same unmangled signature. It would be cool if someone with more expertise on C++ could lend me a hand in this, everything is checked in GAR in pkg/libfpx/trunk: unstable9s% ldd -r work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so /usr/lib/secure/s9_preload.so.1 libCrun.so.1 => /usr/lib/libCrun.so.1 libm.so.1 => /usr/lib/libm.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 /usr/platform/SUNW,SPARC-Enterprise-T5220/lib/libc_psr.so.1 symbol not found: __1cPCExposedDocFileNRenameElement6Mpkcp1_i_ (work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so) symbol not found: __1cPCExposedDocFileNRenameElement6Mpkcp1_i_ (work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so) symbol not found: __1cPOLEHeaderStreamESeek6MklkL_C_ (work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so) symbol not found: __1cDstdNbasic_ostream4Ccn0ALchar_traits4Cc___Fwrite6Mpkcl_r1_ (work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so) symbol not found: __1cDstdNbasic_ostream4Ccn0ALchar_traits4Cc___Dput6Mc_r1_ (work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so) unstable9s% ldd -r work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so | c++filt /usr/lib/secure/s9_preload.so.1 libCrun.so.1 => /usr/lib/libCrun.so.1 libm.so.1 => /usr/lib/libm.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 /usr/platform/SUNW,SPARC-Enterprise-T5220/lib/libc_psr.so.1 symbol not found: int CExposedDocFile::RenameElement(const char*,const char*) (work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so) symbol not found: int CExposedDocFile::RenameElement(const char*,const char*) (work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so) symbol not found: unsigned char OLEHeaderStream::Seek(const long,const unsigned long) (work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so) symbol not found: std::ostream &std::ostream::write(const char*,long) (work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so) symbol not found: std::ostream &std::ostream::put(char) (work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so) unstable9s% nm -A work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so | grep RenameElement work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so: [1234] | 460404| 104|FUNC |GLOB |0 |8 |__1cKOLEStorageNRenameElement6Mpkc2_C_ work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so: [2120] | 601812| 176|FUNC |GLOB |0 |8 |__1cPCExposedDocFileNRenameElement6MpkHp1_i_ work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so: [1317] | 581748| 96|FUNC |GLOB |0 |8 |__1cPCExposedDocFileNRenameElement6Mpkc2_i_ work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so: [2392] | 0| 0|NOTY |GLOB |0 |UNDEF |__1cPCExposedDocFileNRenameElement6Mpkcp1_i_ unstable9s% nm -A work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so | grep RenameElement | c++filt work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so: [1234] | 460404| 104|FUNC |GLOB |0 |8 |unsigned char OLEStorage::RenameElement(const char*,const char*) work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so: [2120] | 601812| 176|FUNC |GLOB |0 |8 |int CExposedDocFile::RenameElement(const unsigned short*,const unsigned short*) work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so: [1317] | 581748| 96|FUNC |GLOB |0 |8 |int CExposedDocFile::RenameElement(const char*,const char*) work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so: [2392] | 0| 0|NOTY |GLOB |0 |UNDEF |int CExposedDocFile::RenameElement(const char*,const char*) 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 Tue Dec 13 13:21:43 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 13 Dec 2011 13:21:43 +0100 Subject: [csw-maintainers] About *-dev packages Message-ID: <58C6E250-1EE0-4D79-9AD0-A0DCAFB6A65C@opencsw.org> Hi folks, I just got a nice idea: derived develpment packages named after bundles. In GAR it is quite common at the moment to make mistakes in the definition of BUILD_DEP_PKGS as most are already installed. Additionally, there is no canonical name for the development packages apart from the *-dev suffix, but the stem is not easily gettable. To solve this I have the following idea: 1. Make the name of the development package CSW-dev This was it can be easily associated with the other packages from the bundle 2. *If* there is a development package for a bundle make an entry "i develpkg" in the pkgmap so the file gets into /var/sadm/pkg//develpkg to make it even more easy to get the name of the development package. pkgutil could aid it in this with a "always install devel packages on this machine" if any new packages are requested by looking this info up. Or "purge all development packages". Thoughts welcome! 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 Tue Dec 13 14:20:55 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 13 Dec 2011 14:20:55 +0100 Subject: [csw-maintainers] OpenCSW distribution specific pre-processor macro Message-ID: In many cases I'm interested in supplying a package which have build dependencies on the presence or absence of OpenCSW packages on a Solaris system. This is easy to provide for the GCC suite by adding to the predefined macros one such as __opencsw__. An example: I need to provide a default value for the SHELL environment variable and for a OpenCSW enabled system I prefer /opt/csw/bin/bash instead of /usr/bin/bash (I know that this can be solved by running /usr/bin/env bash); consequently, when building on such a system I can provide a sensible value by depending on the specific macro existence. I think that for other languages and tools (specifically autotools), there are situations where such a discrimination can be useful. Comments, observations, criticisms, &c -- Peter From Joerg.Schilling at fokus.fraunhofer.de Tue Dec 13 17:41:15 2011 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 13 Dec 2011 17:41:15 +0100 Subject: [csw-maintainers] OpenCSW distribution specific pre-processor macro In-Reply-To: References: Message-ID: <4ee7802b.eX+lkF548VA7Q4aR%Joerg.Schilling@fokus.fraunhofer.de> Peter FELECAN wrote: > In many cases I'm interested in supplying a package which have build > dependencies on the presence or absence of OpenCSW packages on a Solaris > system. > > This is easy to provide for the GCC suite by adding to the predefined > macros one such as __opencsw__. Why do you like to do this? The Schily makefile system auto-adds -DSCHILY_BUILD and it could be configured to add more specific things for specific projects. Could this approach work for you? 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 Tue Dec 13 18:43:27 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 13 Dec 2011 18:43:27 +0100 Subject: [csw-maintainers] OpenCSW distribution specific pre-processor macro In-Reply-To: <4ee7802b.eX+lkF548VA7Q4aR%Joerg.Schilling@fokus.fraunhofer.de> (Joerg Schilling's message of "Tue, 13 Dec 2011 17:41:15 +0100") References: <4ee7802b.eX+lkF548VA7Q4aR%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) writes: > Peter FELECAN wrote: > >> In many cases I'm interested in supplying a package which have build >> dependencies on the presence or absence of OpenCSW packages on a Solaris >> system. >> >> This is easy to provide for the GCC suite by adding to the predefined >> macros one such as __opencsw__. > > > Why do you like to do this? > > The Schily makefile system auto-adds -DSCHILY_BUILD and it could be configured to > add more specific things for specific projects. Could this approach work for > you? In this case, I can write a makefile which takes advantage of using smake, which is a very good thing. It could also add -D__opencsw__ which satisfies my needs (knowing the build system vs. knowing the distribution environment on which I build). Delegating the definition of the __opencsw__ symbol to the pre-processor is even more generic that to have it in the build tool. This is exactly what I wish to extend for full auto-configuration, compile-time detection, &c. For example, I can determine if I'm on an Unix system and then know if I'm on a GNU/Linux or on a Solaris or AIX. But how can I determine in the aforementioned cases that I'm building in a OpenCSW environment? A concrete example, which I gave in the original post, is the compile time determination of the default values for a strategy to guess the shell used to spawn scripts. There are certainly other useful cases. -- Peter From raos at opencsw.org Tue Dec 13 22:42:58 2011 From: raos at opencsw.org (Rafael Ostertag) Date: Tue, 13 Dec 2011 22:42:58 +0100 Subject: [csw-maintainers] Need help on C++ linker issue In-Reply-To: References: Message-ID: <20111213214258.GH404@bender.opencsw.org> Hi Dago On Tue, Dec 13, 2011 at 11:13:27AM +0100, Dagobert Michelsen wrote: > Hi folks, > > in my effort to build imagemagick 64 bit I encountered a problem with the latest > libfpx, where I get unresolved symbols. When look at the methods I see a function > with a different mangled name, which has however the same unmangled signature. > It would be cool if someone with more expertise on C++ could lend me a hand in > this, everything is checked in GAR in pkg/libfpx/trunk: > > unstable9s% ldd -r work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so | c++filt > /usr/lib/secure/s9_preload.so.1 > libCrun.so.1 => /usr/lib/libCrun.so.1 > libm.so.1 => /usr/lib/libm.so.1 > libc.so.1 => /usr/lib/libc.so.1 > libdl.so.1 => /usr/lib/libdl.so.1 > /usr/platform/SUNW,SPARC-Enterprise-T5220/lib/libc_psr.so.1 > symbol not found: int CExposedDocFile::RenameElement(const char*,const char*) (work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so) > symbol not found: int CExposedDocFile::RenameElement(const char*,const char*) (work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so) > symbol not found: unsigned char OLEHeaderStream::Seek(const long,const unsigned long) (work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so) > symbol not found: std::ostream &std::ostream::write(const char*,long) (work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so) > symbol not found: std::ostream &std::ostream::put(char) (work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so) > I submitted two patches to libfpx which sould get rid of the ::RenameElement() and ::Seek() symbols not being found: unstable9s$ ldd -r work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so | c++filt /usr/lib/secure/s9_preload.so.1 libCrun.so.1 => /usr/lib/libCrun.so.1 libm.so.1 => /usr/lib/libm.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 /usr/platform/SUNW,SPARC-Enterprise-T5220/lib/libc_psr.so.1 symbol not found: std::ostream &std::ostream::write(const char*,long) (work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so) symbol not found: std::ostream &std::ostream::put(char) (work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so) However, the std::ostream:write() and ::put() symbols appear to be more serious. I guess they are caused by a combination of -D_RWSTD_NO_WSTR=1 and the way libfpx handles wchar. The file oless/h/owchar.h states following: // Note: These routines uses WCHAR which is unsigned short (2 bytes) // They are not compatible with some systems that uses 4 bytes / wide characters and it appears Solaris is using 4 bytes (sizeof(wchar_t)==4). This might explain why one has to use -D_RWSTD_NO_WSTR=1 in the first place. I might add, that I did not spend a great deal of time hunting down the ostream issue, so my conjecture might be off by miles. Hope this helps. Cheers rafi From dam at opencsw.org Wed Dec 14 00:27:46 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 14 Dec 2011 00:27:46 +0100 Subject: [csw-maintainers] Need help on C++ linker issue In-Reply-To: <20111213214258.GH404@bender.opencsw.org> References: <20111213214258.GH404@bender.opencsw.org> Message-ID: Hi Rafi, Am 13.12.2011 um 22:42 schrieb Rafael Ostertag: > On Tue, Dec 13, 2011 at 11:13:27AM +0100, Dagobert Michelsen wrote: >> Hi folks, >> >> in my effort to build imagemagick 64 bit I encountered a problem with the latest >> libfpx, where I get unresolved symbols. When look at the methods I see a function >> with a different mangled name, which has however the same unmangled signature. >> It would be cool if someone with more expertise on C++ could lend me a hand in >> this, everything is checked in GAR in pkg/libfpx/trunk: >> >> unstable9s% ldd -r work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so | c++filt >> /usr/lib/secure/s9_preload.so.1 >> libCrun.so.1 => /usr/lib/libCrun.so.1 >> libm.so.1 => /usr/lib/libm.so.1 >> libc.so.1 => /usr/lib/libc.so.1 >> libdl.so.1 => /usr/lib/libdl.so.1 >> /usr/platform/SUNW,SPARC-Enterprise-T5220/lib/libc_psr.so.1 >> symbol not found: int CExposedDocFile::RenameElement(const char*,const char*) (work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so) >> symbol not found: int CExposedDocFile::RenameElement(const char*,const char*) (work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so) >> symbol not found: unsigned char OLEHeaderStream::Seek(const long,const unsigned long) (work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so) >> symbol not found: std::ostream &std::ostream::write(const char*,long) (work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so) >> symbol not found: std::ostream &std::ostream::put(char) (work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so) > > I submitted two patches to libfpx which sould get rid of the ::RenameElement() > and ::Seek() symbols not being found: > > unstable9s$ ldd -r work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so | c++filt > /usr/lib/secure/s9_preload.so.1 > libCrun.so.1 => /usr/lib/libCrun.so.1 > libm.so.1 => /usr/lib/libm.so.1 > libc.so.1 => /usr/lib/libc.so.1 > libdl.so.1 => /usr/lib/libdl.so.1 > /usr/platform/SUNW,SPARC-Enterprise-T5220/lib/libc_psr.so.1 > symbol not found: std::ostream &std::ostream::write(const char*,long) (work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so) > symbol not found: std::ostream &std::ostream::put(char) (work/solaris9-sparc/pkgroot/opt/csw/lib/libfpx.so) > > However, the std::ostream:write() and ::put() symbols appear to be more > serious. I guess they are caused by a combination of -D_RWSTD_NO_WSTR=1 and the > way libfpx handles wchar. The file oless/h/owchar.h states following: > > // Note: These routines uses WCHAR which is unsigned short (2 bytes) > // They are not compatible with some systems that uses 4 bytes > / wide characters > > and it appears Solaris is using 4 bytes (sizeof(wchar_t)==4). This might explain why one > has to use -D_RWSTD_NO_WSTR=1 in the first place. I might add, that I did not > spend a great deal of time hunting down the ostream issue, so my conjecture > might be off by miles. > > Hope this helps. These were exactly the changes I needed. The std::ostream can easily be added by using -lCstd and I have now a fully working libfpx, the *last* thing missing to ImageMagick64 ! 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 Dec 14 02:04:14 2011 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 13 Dec 2011 20:04:14 -0500 Subject: [csw-maintainers] About *-dev packages In-Reply-To: <58C6E250-1EE0-4D79-9AD0-A0DCAFB6A65C@opencsw.org> References: <58C6E250-1EE0-4D79-9AD0-A0DCAFB6A65C@opencsw.org> Message-ID: <1323824542-sup-896@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Tue Dec 13 07:21:43 -0500 2011: Hi Dago, > 1. Make the name of the development package CSW-dev This was > it can be easily associated with the other packages from the > bundle I like this although it might trigger a bunch of renames. As those are easy to handle now, I don't see it as a big deal. > 2. *If* there is a development package for a bundle make an entry "i > develpkg" in the pkgmap so the file gets into > /var/sadm/pkg//develpkg to make it even more easy to get the > name of the development package. > > pkgutil could aid it in this with a "always install devel packages > on this machine" if any new packages are requested by looking this > info up. Or "purge all development packages". I definitely like this. It would be akin to aptitude build-depends foo! :) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From raos at opencsw.org Wed Dec 14 07:40:30 2011 From: raos at opencsw.org (Rafael Ostertag) Date: Wed, 14 Dec 2011 07:40:30 +0100 Subject: [csw-maintainers] Need help on C++ linker issue In-Reply-To: References: <20111213214258.GH404@bender.opencsw.org> Message-ID: <20111214064030.GI404@bender.opencsw.org> Hi Dago On Wed, Dec 14, 2011 at 12:27:46AM +0100, Dagobert Michelsen wrote: > These were exactly the changes I needed. The std::ostream can easily be added by using > -lCstd and I have now a fully working libfpx, the *last* thing missing to ImageMagick64 ! Kewl. Glad to be of any help :) Have a nice day. Cheers rafi From maciej at opencsw.org Wed Dec 14 11:51:28 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 14 Dec 2011 10:51:28 +0000 Subject: [csw-maintainers] A chain of updates Message-ID: This topic is related to package renames. Here's how we generally handle renames: Stage 1: The starting point CSWwrong-name / wrong_name Stage 2: Content moved, stub exists CSWwrong-name / wrong_name_stub CSWgood-name / good_name Stage 3: The stub is removed CSWrong-name is removed from the catalog CSWgood-name / good_name / incompatible with CSWwrong-name We have done a lot of transitions from Stage 1 to Stage 2, but very little transitions from Stage 2 to Stage 3. The main obstacle with 2?3 is that we currently can't assume that users update packages on a regular basis, and we want upgrades to work from any to any historical states of the catalog. This effectively blocks us from performing the 2?3 transitions. Here's where named releases can help. We could require sequential updates. For example, legacy?dublin would be a valid update path, and so would be dublin?kiel. However, legacy?kiel would not. If we tracked the renames, we could identify all packages that e.g. have gone 1?2 during the legacy?dublin transition, and have them go 2?3 during the dublin?kiel transition. Thoughts? Maciej P.S. By ?legacy? I mean http://mirror.opencsw.org/opencsw/legacy/ - it has been also known as ?stable?, but I want to move away of equating the words ?stable catalog? with the content from 2008. From pfelecan at opencsw.org Wed Dec 14 12:00:46 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 14 Dec 2011 12:00:46 +0100 Subject: [csw-maintainers] A chain of updates In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Wed, 14 Dec 2011 10:51:28 +0000") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > Here's where named releases can help. We could require sequential > updates. For example, legacy?dublin would be a valid update path, and > so would be dublin?kiel. However, legacy?kiel would not. > > If we tracked the renames, we could identify all packages that e.g. > have gone 1?2 during the legacy?dublin transition, and have them go > 2?3 during the dublin?kiel transition. > > Thoughts? Question: does this means that I can do dublin -> ++kiel ? Also, this means that you need to keep all the named releases or define an obsolescence time for a named release. -- Peter From maciej at opencsw.org Wed Dec 14 12:23:26 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 14 Dec 2011 11:23:26 +0000 Subject: [csw-maintainers] A chain of updates In-Reply-To: References: Message-ID: 2011/12/14 Peter FELECAN : > "Maciej (Matchek) Blizi?ski" writes: > >> Here's where named releases can help. ?We could require sequential >> updates. For example, legacy?dublin would be a valid update path, and >> so would be dublin?kiel. However, legacy?kiel would not. >> >> If we tracked the renames, we could identify all packages that e.g. >> have gone 1?2 during the legacy?dublin transition, and have them go >> 2?3 during the dublin?kiel transition. >> >> Thoughts? > > Question: does this means that I can do dublin -> ++kiel ? You can do dublin?kiel, but you cannot upgrade from dublin to a named release after kiel. In other words, you need to sequentially upgrade from one named release to another, with no skipping. A thought: pkgutil could somehow keep track of this, and stop or warn if someone attempted to do an invalid upgrade. > Also, this means that you need to keep all the named releases or define > an obsolescence time for a named release. Correct. We'd keep them for something like 3 years, which amounts to about 6 named releases at any given point in time. Maciej From dam at opencsw.org Wed Dec 14 13:26:36 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 14 Dec 2011 13:26:36 +0100 Subject: [csw-maintainers] A chain of updates In-Reply-To: References: Message-ID: Hi Maciej, Am 14.12.2011 um 12:23 schrieb Maciej (Matchek) Blizi?ski: > 2011/12/14 Peter FELECAN : >> "Maciej (Matchek) Blizi?ski" writes: >>> Here's where named releases can help. We could require sequential >>> updates. For example, legacy?dublin would be a valid update path, and >>> so would be dublin?kiel. However, legacy?kiel would not. >>> >>> If we tracked the renames, we could identify all packages that e.g. >>> have gone 1?2 during the legacy?dublin transition, and have them go >>> 2?3 during the dublin?kiel transition. >>> >>> Thoughts? >> >> Question: does this means that I can do dublin -> ++kiel ? > > You can do dublin?kiel, but you cannot upgrade from dublin to a named > release after kiel. ...and you cannot update from "legacy" (the old "stable") to "kiel", but must first update to "dublin". > In other words, you need to sequentially upgrade > from one named release to another, with no skipping. > > A thought: pkgutil could somehow keep track of this, and stop or warn > if someone attempted to do an invalid upgrade. +1. >> Also, this means that you need to keep all the named releases or define >> an obsolescence time for a named release. > > Correct. We'd keep them for something like 3 years, which amounts to > about 6 named releases at any given point in time. We could keep them on the primary mirror without expiration, but provide for the rsync downstream only that subset. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From pfelecan at opencsw.org Wed Dec 14 19:01:08 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 14 Dec 2011 19:01:08 +0100 Subject: [csw-maintainers] A chain of updates In-Reply-To: (Dagobert Michelsen's message of "Wed, 14 Dec 2011 13:26:36 +0100") References: Message-ID: Dagobert Michelsen writes: > Hi Maciej, > > Am 14.12.2011 um 12:23 schrieb Maciej (Matchek) Blizi?ski: >> 2011/12/14 Peter FELECAN : >>> "Maciej (Matchek) Blizi?ski" writes: >>>> Here's where named releases can help. We could require sequential >>>> updates. For example, legacy?dublin would be a valid update path, and >>>> so would be dublin?kiel. However, legacy?kiel would not. >>>> >>>> If we tracked the renames, we could identify all packages that e.g. >>>> have gone 1?2 during the legacy?dublin transition, and have them go >>>> 2?3 during the dublin?kiel transition. >>>> >>>> Thoughts? >>> >>> Question: does this means that I can do dublin -> ++kiel ? >> >> You can do dublin?kiel, but you cannot upgrade from dublin to a named >> release after kiel. > > ...and you cannot update from "legacy" (the old "stable") to "kiel", > but must first update to "dublin". This is clear now. >> In other words, you need to sequentially upgrade >> from one named release to another, with no skipping. >> >> A thought: pkgutil could somehow keep track of this, and stop or warn >> if someone attempted to do an invalid upgrade. > > +1. > >>> Also, this means that you need to keep all the named releases or define >>> an obsolescence time for a named release. >> >> Correct. We'd keep them for something like 3 years, which amounts to >> about 6 named releases at any given point in time. > > We could keep them on the primary mirror without expiration, but provide > for the rsync downstream only that subset. If you have enough place that would be the best, giving an long term archive capability. -- Peter From daniel at opencsw.org Fri Dec 16 08:11:50 2011 From: daniel at opencsw.org (Daniel Pocock) Date: Fri, 16 Dec 2011 15:11:50 +0800 Subject: [csw-maintainers] mirroring a subset of pkgs Message-ID: <4EEAEF36.9050409@opencsw.org> pkgutil has the ability to run in download-only mode and collect packages for installation later/on other machines However, it then becomes necessary to manually pkgadd each pkg.gz on the target machine - potentially a painful process I've written a script (see below) that should provide an all-in-one solution to this problem, I'd appreciate any feedback on this approach In particular, - can anyone comment on how I should handle packages that are not architecture specific? - should bldcat work on a Linux host? It chokes on the first line, #!/usr/bin/env perl -w and when that is fixed, it gives a bad file descriptor error #!/bin/bash # Mirrors a subset of CSW packages for pkgutil to install ### Configurable settings #################################################### PKG_SUBSET_MAIN="pkgutil wget rsync gangliaweb nagios netsnmp git gitk " \ "coreutils dtracetoolkit gtar openssl lsof netcat socat vim xtail" MIRROR_MAIN=http://mirror.opencsw.org/opencsw/unstable # If commented, won't try to fetch: #PKG_SUBSET_EXPERIMENTAL="sqsh" MIRROR_EXPERIMENTAL=http://buildfarm.opencsw.org/opencsw/experimental # Where to put the downloads: PKG_DEST=/tmp/pkgmirror # Which versions to fetch: PKG_VERSIONS=5.10 # Which bin dir contains pkgutil #PKGUTIL_BINDIR=/opt/csw/bin PKGUTIL_BINDIR=/home/daniel/ws/pkgutil-trunk # The binary names PKGUTIL="${PKGUTIL_BINDIR}/pkgutil" BLDCAT="${PKGUTIL_BINDIR}/bldcat" ### End of configurable settings ############################################# mkdir -p ${PKG_DEST} || exit 1 for PKG_ARCH in i386 sparc ; do for PKG_VERSION in ${PKG_VERSIONS} ; do # Identify the platform, create a directory: PKG_PLATFORM="${PKG_ARCH}:${PKG_VERSION}" PKG_PLATFORM_DEST="${PKG_DEST}/${PKG_ARCH}/${PKG_VERSION}" mkdir -p ${PKG_PLATFORM_DEST} || exit 1 # Get the main packages we want: ${PKGUTIL} -d -y -t ${MIRROR_MAIN} -T ${PKG_PLATFORM} \ -P ${PKG_PLATFORM_DEST} ${PKG_SUBSET_MAIN} || exit 1 # Get any experimental packages we want: if [ ! -z "${PKG_SUBSET_EXPERIMENTAL}" ]; then for PKG_NAME in ${PKG_SUBSET_EXPERIMENTAL} ; do # Notice the URL is different for each package in experimental: ${PKGUTIL} -d -y -t ${MIRROR_EXPERIMENTAL}/${PKG_NAME} \ -T ${PKG_PLATFORM} \ -P ${PKG_PLATFORM_DEST} ${PKG_NAME} || exit 1 done fi # Create the catalog file: ${BLDCAT} ${PKG_PLATFORM_DEST} || exit 1 done done From bonivart at opencsw.org Fri Dec 16 10:41:37 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 16 Dec 2011 10:41:37 +0100 Subject: [csw-maintainers] mirroring a subset of pkgs In-Reply-To: <4EEAEF36.9050409@opencsw.org> References: <4EEAEF36.9050409@opencsw.org> Message-ID: On Fri, Dec 16, 2011 at 8:11 AM, Daniel Pocock wrote: > > > pkgutil has the ability to run in download-only mode and collect > packages for installation later/on other machines > > However, it then becomes necessary to manually pkgadd each pkg.gz on the > target machine - potentially a painful process But it does output all the commands necessary to pkgadd the packages in the correct order. You shouldn't have to do more than copy'n'paste that. > - should bldcat work on a Linux host? ?It chokes on the first line, > #!/usr/bin/env perl -w and when that is fixed, it gives a bad file > descriptor error It's not meant to run on Linux. Some time back I heard of interest in running pkgutil in download mode on Linux and did a writeup of that here: http://pkgutil.wikidot.com/use-with-examples#toc8. In pkgutil 2.6 I will also look for wget in /usr/bin so the step with faking the symlink can be removed. But downloading just uses some logic and calls wget which is generic. You can't do anything that involves Solaris pkg tools and bldcat needs to do pkgtrans so I can't see that working. /peter From dam at opencsw.org Fri Dec 16 11:25:04 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 16 Dec 2011 11:25:04 +0100 Subject: [csw-maintainers] mirroring a subset of pkgs In-Reply-To: References: <4EEAEF36.9050409@opencsw.org> Message-ID: Hi Peter, Am 16.12.2011 um 10:41 schrieb Peter Bonivart: > On Fri, Dec 16, 2011 at 8:11 AM, Daniel Pocock wrote: >> pkgutil has the ability to run in download-only mode and collect >> packages for installation later/on other machines >> >> However, it then becomes necessary to manually pkgadd each pkg.gz on the >> target machine - potentially a painful process > > But it does output all the commands necessary to pkgadd the packages > in the correct order. You shouldn't have to do more than copy'n'paste > that. The resulting thing to be transfered could include a generated install script and an admin file together with the packages bundles up as tar or self-installing .sh or something to make things easier. Best regards -- Dago From maciej at opencsw.org Fri Dec 16 17:39:27 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 16 Dec 2011 16:39:27 +0000 Subject: [csw-maintainers] The Solaris subreddit Message-ID: If there are any Redditors here: there is a Solaris subreddit: http://www.reddit.com/r/solaris/ It's a low traffic reddit. There are currently 289 subscribers, and links are coming up at the rate of 1-3 a month. But still it's a good place to look at, and potentially post some links. I've spammed them with a link to the list of our packages. There were 11 upvotes and 4 downvotes. For people who don't have reddit accounts - consider joining reddit and posting Solaris-related links. For its size, the reddit community seems to be well behaved and self-regulated. Other subreddits that might be of interest: http://www.reddit.com/r/technology/ http://www.reddit.com/r/unix/ http://www.reddit.com/r/vim/ http://www.reddit.com/r/emacs/ More: http://www.reddit.com/reddits/ Maciej From daniel at opencsw.org Sat Dec 17 05:07:32 2011 From: daniel at opencsw.org (Daniel Pocock) Date: Sat, 17 Dec 2011 12:07:32 +0800 Subject: [csw-maintainers] mirroring a subset of pkgs In-Reply-To: References: <4EEAEF36.9050409@opencsw.org> Message-ID: <4EEC1584.7000302@opencsw.org> On 16/12/11 18:25, Dagobert Michelsen wrote: > Hi Peter, > > Am 16.12.2011 um 10:41 schrieb Peter Bonivart: > >> On Fri, Dec 16, 2011 at 8:11 AM, Daniel Pocock wrote: >> >>> pkgutil has the ability to run in download-only mode and collect >>> packages for installation later/on other machines >>> >>> However, it then becomes necessary to manually pkgadd each pkg.gz on the >>> target machine - potentially a painful process >>> >> But it does output all the commands necessary to pkgadd the packages >> in the correct order. You shouldn't have to do more than copy'n'paste >> that. >> > The resulting thing to be transfered could include a generated install > script and an admin file together with the packages bundles up as tar > or self-installing .sh or something to make things easier. > > > I ran pkgutil for coreutils in download only mode to test this The output (see below) appears to have the package list in the right order, but it doesn't give the commands to run Even so, the approach I have provided for building a mirror is still quite valid for a subset of the catalog, because after I have built my `mini-mirror', I may not want to install every downloaded package on every target machine - I may still want pkgutil to just pick some of the packages and their dependencies when I am on each target host. E.g. on some hosts, I want gangliaweb (which depends on rrdtool and gangliaagent and it's dependencies), but on other hosts I just want gangliaagent (and not rrdtool, apache, etc) daniel at lt2:~/csw/pkgutil-trunk$ ./pkgutil -d -y -t http://mirror.opencsw.org/opencsw/unstable -T i386:5.10 -P /tmp/pkgs coreutils You're not root and didn't set -W, using home dir. => Fetching new catalog and descriptions (http://mirror.opencsw.org/opencsw/unstable/i386/5.10) if available ... --2011-12-17 12:00:55-- http://mirror.opencsw.org/opencsw/unstable/i386/5.10/catalog Resolving mirror.opencsw.org... 131.188.40.82, 2001:638:a00:28::52 Connecting to mirror.opencsw.org|131.188.40.82|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 677820 (662K) [text/plain] Saving to: `/home/daniel/.pkgutil/catalog.mirror.opencsw.org_opencsw_unstable_i386_5.10.tmp' 100%[======================================>] 677,820 238K/s in 2.8s 2011-12-17 12:00:59 (238 KB/s) - `/home/daniel/.pkgutil/catalog.mirror.opencsw.org_opencsw_unstable_i386_5.10.tmp' saved [677820/677820] --2011-12-17 12:00:59-- http://mirror.opencsw.org/opencsw/unstable/i386/5.10/descriptions Resolving mirror.opencsw.org... 131.188.40.82, 2001:638:a00:28::52 Connecting to mirror.opencsw.org|131.188.40.82|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 198440 (194K) [text/plain] Saving to: `/home/daniel/.pkgutil/descriptions.mirror.opencsw.org_opencsw_unstable_i386_5.10.tmp' 100%[======================================>] 198,440 93.8K/s in 2.1s 2011-12-17 12:01:02 (93.8 KB/s) - `/home/daniel/.pkgutil/descriptions.mirror.opencsw.org_opencsw_unstable_i386_5.10.tmp' saved [198440/198440] ==> 3442 packages loaded from /home/daniel/.pkgutil/catalog.mirror.opencsw.org_opencsw_unstable_i386_5.10 => Fetching new catalog and descriptions (http://mirror.opencsw.org/opencsw/testing/i386/5.10) if available ... --2011-12-17 12:01:02-- http://mirror.opencsw.org/opencsw/testing/i386/5.10/catalog Resolving mirror.opencsw.org... 131.188.40.82, 2001:638:a00:28::52 Connecting to mirror.opencsw.org|131.188.40.82|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 627107 (612K) [text/plain] Saving to: `/home/daniel/.pkgutil/catalog.mirror.opencsw.org_opencsw_testing_i386_5.10.tmp' 100%[======================================>] 627,107 221K/s in 2.8s 2011-12-17 12:01:06 (221 KB/s) - `/home/daniel/.pkgutil/catalog.mirror.opencsw.org_opencsw_testing_i386_5.10.tmp' saved [627107/627107] --2011-12-17 12:01:06-- http://mirror.opencsw.org/opencsw/testing/i386/5.10/descriptions Resolving mirror.opencsw.org... 131.188.40.82, 2001:638:a00:28::52 Connecting to mirror.opencsw.org|131.188.40.82|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 180223 (176K) [text/plain] Saving to: `/home/daniel/.pkgutil/descriptions.mirror.opencsw.org_opencsw_testing_i386_5.10.tmp' 100%[======================================>] 180,223 102K/s in 1.7s 2011-12-17 12:01:08 (102 KB/s) - `/home/daniel/.pkgutil/descriptions.mirror.opencsw.org_opencsw_testing_i386_5.10.tmp' saved [180223/180223] ==> 3172 packages loaded from /home/daniel/.pkgutil/catalog.mirror.opencsw.org_opencsw_testing_i386_5.10 Solving needed dependencies ... Solving dependency order ... Package list: CSWcas-texinfo-1.42,REV=2010.11.26 (opencsw/unstable) CSWcommon-1.5,REV=2010.12.11 (opencsw/unstable) CSWcoreutils-8.13,REV=2011.09.10 (opencsw/unstable) CSWggettext-data-0.18.1.1,p,REV=2011.03.15 (opencsw/unstable) CSWiconv-1.14,REV=2011.08.08 (opencsw/unstable) CSWlibcharset1-1.14,REV=2011.08.07 (opencsw/unstable) CSWlibgcc-s1-4.6.2,REV=2011.12.05 (opencsw/unstable) CSWlibgmp10-5.0.2,REV=2011.09.24 (opencsw/unstable) CSWlibiconv2-1.14,REV=2011.08.07 (opencsw/unstable) CSWlibintl8-0.18.1.1,p,REV=2011.03.15 (opencsw/unstable) Total size: 10.1 MB => Fetching CSWcommon-1.5,REV=2010.12.11 (1/10) ... --2011-12-17 12:01:08-- http://mirror.opencsw.org/opencsw/unstable/i386/5.10/common-1.5,REV=2010.12.11-SunOS5.8-i386-CSW.pkg Resolving mirror.opencsw.org... 131.188.40.82, 2001:638:a00:28::52 Connecting to mirror.opencsw.org|131.188.40.82|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 22528 (22K) [application/octet-stream] Saving to: `/tmp/pkgs/common-1.5,REV=2010.12.11-SunOS5.8-i386-CSW.pkg.tmp' 100%[======================================>] 22,528 32.1K/s in 0.7s 2011-12-17 12:01:10 (32.1 KB/s) - `/tmp/pkgs/common-1.5,REV=2010.12.11-SunOS5.8-i386-CSW.pkg.tmp' saved [22528/22528] => Fetching CSWlibiconv2-1.14,REV=2011.08.07 (2/10) ... --2011-12-17 12:01:10-- http://mirror.opencsw.org/opencsw/unstable/i386/5.10/libiconv2-1.14,REV=2011.08.07-SunOS5.9-i386-CSW.pkg.gz Resolving mirror.opencsw.org... 131.188.40.82, 2001:638:a00:28::52 Connecting to mirror.opencsw.org|131.188.40.82|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1350101 (1.3M) [application/x-gzip] Saving to: `/tmp/pkgs/libiconv2-1.14,REV=2011.08.07-SunOS5.9-i386-CSW.pkg.gz.tmp' 100%[======================================>] 1,350,101 379K/s in 3.5s 2011-12-17 12:01:14 (379 KB/s) - `/tmp/pkgs/libiconv2-1.14,REV=2011.08.07-SunOS5.9-i386-CSW.pkg.gz.tmp' saved [1350101/1350101] => Fetching CSWlibcharset1-1.14,REV=2011.08.07 (3/10) ... --2011-12-17 12:01:14-- http://mirror.opencsw.org/opencsw/unstable/i386/5.10/libcharset1-1.14,REV=2011.08.07-SunOS5.9-i386-CSW.pkg.gz Resolving mirror.opencsw.org... 131.188.40.82, 2001:638:a00:28::52 Connecting to mirror.opencsw.org|131.188.40.82|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 21914 (21K) [application/x-gzip] Saving to: `/tmp/pkgs/libcharset1-1.14,REV=2011.08.07-SunOS5.9-i386-CSW.pkg.gz.tmp' 100%[======================================>] 21,914 31.2K/s in 0.7s 2011-12-17 12:01:15 (31.2 KB/s) - `/tmp/pkgs/libcharset1-1.14,REV=2011.08.07-SunOS5.9-i386-CSW.pkg.gz.tmp' saved [21914/21914] => Fetching CSWlibgcc-s1-4.6.2,REV=2011.12.05 (4/10) ... --2011-12-17 12:01:15-- http://mirror.opencsw.org/opencsw/unstable/i386/5.10/libgcc_s1-4.6.2,REV=2011.12.05-SunOS5.10-i386-CSW.pkg.gz Resolving mirror.opencsw.org... 131.188.40.82, 2001:638:a00:28::52 Connecting to mirror.opencsw.org|131.188.40.82|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 316023 (309K) [application/x-gzip] Saving to: `/tmp/pkgs/libgcc_s1-4.6.2,REV=2011.12.05-SunOS5.10-i386-CSW.pkg.gz.tmp' 100%[======================================>] 316,023 148K/s in 2.1s 2011-12-17 12:01:18 (148 KB/s) - `/tmp/pkgs/libgcc_s1-4.6.2,REV=2011.12.05-SunOS5.10-i386-CSW.pkg.gz.tmp' saved [316023/316023] => Fetching CSWggettext-data-0.18.1.1,p,REV=2011.03.15 (5/10) ... --2011-12-17 12:01:18-- http://mirror.opencsw.org/opencsw/unstable/i386/5.10/ggettext_data-0.18.1.1,p,REV=2011.03.15-SunOS5.9-all-CSW.pkg.gz Resolving mirror.opencsw.org... 131.188.40.82, 2001:638:a00:28::52 Connecting to mirror.opencsw.org|131.188.40.82|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 820540 (801K) [application/x-gzip] Saving to: `/tmp/pkgs/ggettext_data-0.18.1.1,p,REV=2011.03.15-SunOS5.9-all-CSW.pkg.gz.tmp' 100%[======================================>] 820,540 259K/s in 3.1s 2011-12-17 12:01:22 (259 KB/s) - `/tmp/pkgs/ggettext_data-0.18.1.1,p,REV=2011.03.15-SunOS5.9-all-CSW.pkg.gz.tmp' saved [820540/820540] => Fetching CSWiconv-1.14,REV=2011.08.08 (6/10) ... --2011-12-17 12:01:22-- http://mirror.opencsw.org/opencsw/unstable/i386/5.10/iconv_stub-1.14,REV=2011.08.08-SunOS5.9-all-CSW.pkg.gz Resolving mirror.opencsw.org... 131.188.40.82, 2001:638:a00:28::52 Connecting to mirror.opencsw.org|131.188.40.82|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 13221 (13K) [application/x-gzip] Saving to: `/tmp/pkgs/iconv_stub-1.14,REV=2011.08.08-SunOS5.9-all-CSW.pkg.gz.tmp' 100%[======================================>] 13,221 18.9K/s in 0.7s 2011-12-17 12:01:23 (18.9 KB/s) - `/tmp/pkgs/iconv_stub-1.14,REV=2011.08.08-SunOS5.9-all-CSW.pkg.gz.tmp' saved [13221/13221] => Fetching CSWlibgmp10-5.0.2,REV=2011.09.24 (7/10) ... --2011-12-17 12:01:23-- http://mirror.opencsw.org/opencsw/unstable/i386/5.10/libgmp10-5.0.2,REV=2011.09.24-SunOS5.9-i386-CSW.pkg.gz Resolving mirror.opencsw.org... 131.188.40.82, 2001:638:a00:28::52 Connecting to mirror.opencsw.org|131.188.40.82|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 480818 (470K) [application/x-gzip] Saving to: `/tmp/pkgs/libgmp10-5.0.2,REV=2011.09.24-SunOS5.9-i386-CSW.pkg.gz.tmp' 100%[======================================>] 480,818 171K/s in 2.7s 2011-12-17 12:01:27 (171 KB/s) - `/tmp/pkgs/libgmp10-5.0.2,REV=2011.09.24-SunOS5.9-i386-CSW.pkg.gz.tmp' saved [480818/480818] => Fetching CSWlibintl8-0.18.1.1,p,REV=2011.03.15 (8/10) ... --2011-12-17 12:01:27-- http://mirror.opencsw.org/opencsw/unstable/i386/5.10/libintl8-0.18.1.1,p,REV=2011.03.15-SunOS5.9-i386-CSW.pkg.gz Resolving mirror.opencsw.org... 131.188.40.82, 2001:638:a00:28::52 Connecting to mirror.opencsw.org|131.188.40.82|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 66222 (65K) [application/x-gzip] Saving to: `/tmp/pkgs/libintl8-0.18.1.1,p,REV=2011.03.15-SunOS5.9-i386-CSW.pkg.gz.tmp' 100%[======================================>] 66,222 47.3K/s in 1.4s 2011-12-17 12:01:29 (47.3 KB/s) - `/tmp/pkgs/libintl8-0.18.1.1,p,REV=2011.03.15-SunOS5.9-i386-CSW.pkg.gz.tmp' saved [66222/66222] => Fetching CSWcas-texinfo-1.42,REV=2010.11.26 (9/10) ... --2011-12-17 12:01:29-- http://mirror.opencsw.org/opencsw/unstable/i386/5.10/cas_texinfo-1.42,REV=2010.11.26-SunOS5.9-all-CSW.pkg.gz Resolving mirror.opencsw.org... 131.188.40.82, 2001:638:a00:28::52 Connecting to mirror.opencsw.org|131.188.40.82|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1562 (1.5K) [application/x-gzip] Saving to: `/tmp/pkgs/cas_texinfo-1.42,REV=2010.11.26-SunOS5.9-all-CSW.pkg.gz.tmp' 100%[======================================>] 1,562 --.-K/s in 0s 2011-12-17 12:01:29 (4.49 MB/s) - `/tmp/pkgs/cas_texinfo-1.42,REV=2010.11.26-SunOS5.9-all-CSW.pkg.gz.tmp' saved [1562/1562] => Fetching CSWcoreutils-8.13,REV=2011.09.10 (10/10) ... --2011-12-17 12:01:29-- http://mirror.opencsw.org/opencsw/unstable/i386/5.10/coreutils-8.13,REV=2011.09.10-SunOS5.9-i386-CSW.pkg.gz Resolving mirror.opencsw.org... 131.188.40.82, 2001:638:a00:28::52 Connecting to mirror.opencsw.org|131.188.40.82|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 7546399 (7.2M) [application/x-gzip] Saving to: `/tmp/pkgs/coreutils-8.13,REV=2011.09.10-SunOS5.9-i386-CSW.pkg.gz.tmp' 100%[======================================>] 7,546,399 1.82M/s in 5.9s 2011-12-17 12:01:36 (1.22 MB/s) - `/tmp/pkgs/coreutils-8.13,REV=2011.09.10-SunOS5.9-i386-CSW.pkg.gz.tmp' saved [7546399/7546399] Packages downloaded to /tmp/pkgs: common-1.5,REV=2010.12.11-SunOS5.8-i386-CSW.pkg (OK) libiconv2-1.14,REV=2011.08.07-SunOS5.9-i386-CSW.pkg.gz (OK) libcharset1-1.14,REV=2011.08.07-SunOS5.9-i386-CSW.pkg.gz (OK) libgcc_s1-4.6.2,REV=2011.12.05-SunOS5.10-i386-CSW.pkg.gz (OK) ggettext_data-0.18.1.1,p,REV=2011.03.15-SunOS5.9-all-CSW.pkg.gz (OK) iconv_stub-1.14,REV=2011.08.08-SunOS5.9-all-CSW.pkg.gz (OK) libgmp10-5.0.2,REV=2011.09.24-SunOS5.9-i386-CSW.pkg.gz (OK) libintl8-0.18.1.1,p,REV=2011.03.15-SunOS5.9-i386-CSW.pkg.gz (OK) cas_texinfo-1.42,REV=2010.11.26-SunOS5.9-all-CSW.pkg.gz (OK) coreutils-8.13,REV=2011.09.10-SunOS5.9-i386-CSW.pkg.gz (OK) From skayser at opencsw.org Sat Dec 17 10:32:57 2011 From: skayser at opencsw.org (Sebastian Kayser) Date: Sat, 17 Dec 2011 10:32:57 +0100 Subject: [csw-maintainers] mirroring a subset of pkgs In-Reply-To: <4EEC1584.7000302@opencsw.org> References: <4EEAEF36.9050409@opencsw.org> <4EEC1584.7000302@opencsw.org> Message-ID: <20111217093257.GG9345@sebastiankayser.de> * Daniel Pocock wrote: > On 16/12/11 18:25, Dagobert Michelsen wrote: > > > > Am 16.12.2011 um 10:41 schrieb Peter Bonivart: > > > >> On Fri, Dec 16, 2011 at 8:11 AM, Daniel Pocock wrote: > >> > >>> pkgutil has the ability to run in download-only mode and collect > >>> packages for installation later/on other machines > >>> > >>> However, it then becomes necessary to manually pkgadd each pkg.gz on the > >>> target machine - potentially a painful process > >>> > >> But it does output all the commands necessary to pkgadd the packages > >> in the correct order. You shouldn't have to do more than copy'n'paste > >> that. > >> > > The resulting thing to be transfered could include a generated install > > script and an admin file together with the packages bundles up as tar > > or self-installing .sh or something to make things easier. > > I ran pkgutil for coreutils in download only mode to test this > > The output (see below) appears to have the package list in the right > order, but it doesn't give the commands to run What Peter was talking about is the -s/--stream mode. It'll put all requested packages in one file and afterwards tell you the pkgadd commands necessary to install them on the target box. > Even so, the approach I have provided for building a mirror is still > quite valid for a subset of the catalog, because after I have built my > `mini-mirror', I may not want to install every downloaded package on > every target machine - I may still want pkgutil to just pick some of the > packages and their dependencies when I am on each target host. Yes, building an internal mirror based on a subset of packages is something that's likely a common use case. Do we have a tutorial, FAQ entry, or wiki page for how to do that? If not, we should get one. > E.g. on some hosts, I want gangliaweb (which depends on rrdtool and > gangliaagent and it's dependencies), but on other hosts I just want > gangliaagent (and not rrdtool, apache, etc) > > > daniel at lt2:~/csw/pkgutil-trunk$ ./pkgutil -d -y -t > http://mirror.opencsw.org/opencsw/unstable -T i386:5.10 -P /tmp/pkgs > coreutils > You're not root and didn't set -W, using home dir. > => Fetching new catalog and descriptions > (http://mirror.opencsw.org/opencsw/unstable/i386/5.10) if available ... > --2011-12-17 12:00:55-- > http://mirror.opencsw.org/opencsw/unstable/i386/5.10/catalog > Resolving mirror.opencsw.org... 131.188.40.82, 2001:638:a00:28::52 > Connecting to mirror.opencsw.org|131.188.40.82|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 677820 (662K) [text/plain] > Saving to: > `/home/daniel/.pkgutil/catalog.mirror.opencsw.org_opencsw_unstable_i386_5.10.tmp' > > 100%[======================================>] 677,820 238K/s in > 2.8s Not relevant to the thread, but for general pkgutil usage. Are you aware of the wgetopts=-q in pkgutil.conf? Makes for a much terser and IMHO nicer output. Sebastian From bwalton at opencsw.org Sun Dec 18 04:30:12 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sat, 17 Dec 2011 22:30:12 -0500 Subject: [csw-maintainers] Fwd: Output from "cron" command Message-ID: <1324178981-sup-8876@pinkfloyd.chass.utoronto.ca> Hi All, Shall I override this file conflict to let the registration proceed? Thanks -Ben --- Begin forwarded message from Ben Walton --- From: Ben Walton To: bwalton Date: Sat, 17 Dec 2011 22:07:23 -0500 Subject: Output from "cron" command Your "cron" job on ocswchbiesv01 /home/bwalton/bin/run_web_updates produced the following output: ERROR: /opt/csw/bin/gdk-pixbuf-csource: Conflict between CSWgdkpixbuf/gdk_pixbuf and CSWgtk2 --- End forwarded message --- -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From raos at opencsw.org Sun Dec 18 09:12:47 2011 From: raos at opencsw.org (Rafael Ostertag) Date: Sun, 18 Dec 2011 09:12:47 +0100 Subject: [csw-maintainers] Fwd: Output from "cron" command In-Reply-To: <1324178981-sup-8876@pinkfloyd.chass.utoronto.ca> References: <1324178981-sup-8876@pinkfloyd.chass.utoronto.ca> Message-ID: <20111218081247.GN404@bender.opencsw.org> Hi Ben On Sat, Dec 17, 2011 at 10:30:12PM -0500, Ben Walton wrote: > Hi All, > > Shall I override this file conflict to let the registration proceed? > > Thanks > -Ben Yes, please. This will be solved when the latest GTK2 (2.24) gets submitted, which I hope will be today. Sorry for the trouble. --rafi From maciej at opencsw.org Sun Dec 18 16:42:43 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 18 Dec 2011 15:42:43 +0000 Subject: [csw-maintainers] Integrating from unstable to dublin In-Reply-To: <4EDFA51A.8050301@opencsw.org> References: <4EDE79D3.5040902@opencsw.org> <4EDFA51A.8050301@opencsw.org> Message-ID: I've generated the current diff for integration from unstable to dublin: http://buildfarm.opencsw.org/~maciej/to_dublin.sh.txt (the .txt extension makes Apache use a browser-viewable mime type) Those who care can review the package change list. We won't integrate just yet. There currently are serious bugs in the MySQL package (startup script, quickstart script), which I need to fix before we integrate. Maciej From bonivart at opencsw.org Sun Dec 18 19:59:56 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 18 Dec 2011 19:59:56 +0100 Subject: [csw-maintainers] pkgutil 2.6 beta 1 Message-ID: Hi, I have packaged a first beta of pkgutil 2.6 for you to test. This is the change log: - Support site feature RELEASE. Cache names locally, if changed (testing starts to point to kiel instead of dublin e.g.) an alert is issued - Add --catinfo option, OpenCSW #4835 (Sebastian Kayser) - Warn about cswclassutils not in global zone when running in sparse zone (detect read-only /usr) - Change default mirror to http://mirror.opencsw.org/opencsw/testing - Add /usr/perl5/bin to PATH (Dago) - Default unlimited depth for --deptree (Sebastian) - Use -q as default for wget (Dago) - Document (on wiki) how to use pkgutil on Linux for downloading - Add /usr/bin path to locate wget to ease running on Linux - Fix typo in readme about rootpath option - bldcat: make --param very generic, every unrecognized foo:bar means it will be inserted into the catalog as a magic comment (# foo bar) - bldcat: add param option including timestamp and release name You can find it here: http://buildfarm.opencsw.org/experimental.html#pkgutil /peter From opk at opencsw.org Sun Dec 18 21:31:50 2011 From: opk at opencsw.org (Oliver Kiddle) Date: Sun, 18 Dec 2011 21:31:50 +0100 Subject: [csw-maintainers] preserving config files on upgrade Message-ID: <11476.1324240310@thecus.kiddle.eu> Is there any mechanism for handling configuration files. Basically, I'd like to know how best to handle bug 4624 on nmh. nmh 1.4 will likely be released shortly and I'd prefer if the new package doesn't overwrite existing mts.conf files. Thanks Oliver From bwalton at opencsw.org Sun Dec 18 21:38:58 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 18 Dec 2011 15:38:58 -0500 Subject: [csw-maintainers] preserving config files on upgrade In-Reply-To: <11476.1324240310@thecus.kiddle.eu> References: <11476.1324240310@thecus.kiddle.eu> Message-ID: <1324240409-sup-7916@pinkfloyd.chass.utoronto.ca> Excerpts from Oliver Kiddle's message of Sun Dec 18 15:31:50 -0500 2011: Hi Oliver, > Is there any mechanism for handling configuration files. Basically, > I'd like to know how best to handle bug 4624 on nmh. nmh 1.4 will > likely be released shortly and I'd prefer if the new package doesn't > overwrite existing mts.conf files. Is there anything in place in the current package for this file? If it will be left behind when the package is removed, you're in good shape. If it will be removed, then there isn't much you can do. In your pending package, simply designate the mts.conf file as the class action that is most appropriate[1] and it will be delivered as installed as a different file (different location or name, depending) and only installed if required. Thanks -Ben [1] http://wiki.opencsw.org/cswclassutils-package: cswcptemplates or cswpreserveconf are what you're after. -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Mon Dec 19 03:04:20 2011 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 18 Dec 2011 21:04:20 -0500 Subject: [csw-maintainers] the future of pkg-get... In-Reply-To: <1315362400-sup-2443@pinkfloyd.chass.utoronto.ca> References: <1315241773-sup-2057@pinkfloyd.chass.utoronto.ca> <1315253472-sup-9970@pinkfloyd.chass.utoronto.ca> <73328001-D783-4032-9FF9-FA81A41B4F9F@opencsw.org> <1315253759-sup-2517@pinkfloyd.chass.utoronto.ca> <1315362400-sup-2443@pinkfloyd.chass.utoronto.ca> Message-ID: <1324260076-sup-4890@pinkfloyd.chass.utoronto.ca> Excerpts from Ben Walton's message of Tue Sep 06 22:27:06 -0400 2011: > See: http://buildfarm.opencsw.org/experimental.html#pkgget Unless anyone objects, I'll start the ball rolling on this in the next few days. I'll precede the release by an announcement a few days prior. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Mon Dec 19 15:21:23 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 19 Dec 2011 14:21:23 +0000 Subject: [csw-maintainers] GCC 4.6.2 C++ front issue In-Reply-To: References: Message-ID: I'll probably not be able to work on it (or on anything bigger) in the nearest weeks. If anyone has any free cycles to work on it, and cares about it, please go ahead. If I start working on the -R issue again, I'll update this thread. If you're reading this, and this is the last message in the thread, it means I haven't made any progress on this issue. Here's the link to the recipe: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/gcc4/trunk/Makefile Maciej From daniel at opencsw.org Mon Dec 19 18:44:42 2011 From: daniel at opencsw.org (Daniel Pocock) Date: Mon, 19 Dec 2011 18:44:42 +0100 Subject: [csw-maintainers] mirroring a subset of pkgs In-Reply-To: <20111217093257.GG9345@sebastiankayser.de> References: <4EEAEF36.9050409@opencsw.org> <4EEC1584.7000302@opencsw.org> <20111217093257.GG9345@sebastiankayser.de> Message-ID: <4EEF780A.6080208@opencsw.org> On 17/12/11 10:32, Sebastian Kayser wrote: > * Daniel Pocock wrote: >> On 16/12/11 18:25, Dagobert Michelsen wrote: >>> >>> Am 16.12.2011 um 10:41 schrieb Peter Bonivart: >>> >>>> On Fri, Dec 16, 2011 at 8:11 AM, Daniel Pocock wrote: >>>> >>>>> pkgutil has the ability to run in download-only mode and collect >>>>> packages for installation later/on other machines >>>>> >>>>> However, it then becomes necessary to manually pkgadd each pkg.gz on the >>>>> target machine - potentially a painful process >>>>> >>>> But it does output all the commands necessary to pkgadd the packages >>>> in the correct order. You shouldn't have to do more than copy'n'paste >>>> that. >>>> >>> The resulting thing to be transfered could include a generated install >>> script and an admin file together with the packages bundles up as tar >>> or self-installing .sh or something to make things easier. >> >> I ran pkgutil for coreutils in download only mode to test this >> >> The output (see below) appears to have the package list in the right >> order, but it doesn't give the commands to run > > What Peter was talking about is the -s/--stream mode. It'll put all > requested packages in one file and afterwards tell you the pkgadd > commands necessary to install them on the target box. I wasn't aware of that - when reading the docs, I just zoomed in on the Linux downloading info: http://pkgutil.wikidot.com/use-with-examples#toc8 and the stuff about stream mode (which is just above the Linux stuff) didn't really stand out. Maybe it should be repeated in the Linux section (or an extra example) >> Even so, the approach I have provided for building a mirror is still >> quite valid for a subset of the catalog, because after I have built my >> `mini-mirror', I may not want to install every downloaded package on >> every target machine - I may still want pkgutil to just pick some of the >> packages and their dependencies when I am on each target host. > > Yes, building an internal mirror based on a subset of packages is > something that's likely a common use case. Do we have a tutorial, FAQ > entry, or wiki page for how to do that? If not, we should get one. I attach another copy of the script, slightly improved Before making a document, should this become part of the pkgutil SVN, or should I start another repo for it? For those wanting to have a quick go at it, just play with the settings at the beginning >> E.g. on some hosts, I want gangliaweb (which depends on rrdtool and >> gangliaagent and it's dependencies), but on other hosts I just want >> gangliaagent (and not rrdtool, apache, etc) >> >> >> daniel at lt2:~/csw/pkgutil-trunk$ ./pkgutil -d -y -t >> http://mirror.opencsw.org/opencsw/unstable -T i386:5.10 -P /tmp/pkgs >> coreutils >> You're not root and didn't set -W, using home dir. >> => Fetching new catalog and descriptions >> (http://mirror.opencsw.org/opencsw/unstable/i386/5.10) if available ... >> --2011-12-17 12:00:55-- >> http://mirror.opencsw.org/opencsw/unstable/i386/5.10/catalog >> Resolving mirror.opencsw.org... 131.188.40.82, 2001:638:a00:28::52 >> Connecting to mirror.opencsw.org|131.188.40.82|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 677820 (662K) [text/plain] >> Saving to: >> `/home/daniel/.pkgutil/catalog.mirror.opencsw.org_opencsw_unstable_i386_5.10.tmp' >> >> 100%[======================================>] 677,820 238K/s in >> 2.8s > > Not relevant to the thread, but for general pkgutil usage. Are you aware > of the wgetopts=-q in pkgutil.conf? Makes for a much terser and IMHO > nicer output. Thanks for that tip - in the example, I was just running pkgutil on a Linux box, with no pkgutil.conf present -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pkgutil-mkmirror URL: From opk at opencsw.org Tue Dec 20 18:05:45 2011 From: opk at opencsw.org (Oliver Kiddle) Date: Tue, 20 Dec 2011 18:05:45 +0100 Subject: [csw-maintainers] uWatch and QA page for zsh Message-ID: <21933.1324400745@thecus.kiddle.eu> Does anyone have any idea why the QA page is showing big numbers for the upstream release of zsh, see: http://www.opencsw.org/qa/package/zsh/ Running gmake get-upstream-latest-version correctly picks up 4.3.15 as the latest. Oliver From maciej at opencsw.org Wed Dec 21 09:56:33 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 21 Dec 2011 08:56:33 +0000 Subject: [csw-maintainers] uWatch and QA page for zsh In-Reply-To: <21933.1324400745@thecus.kiddle.eu> References: <21933.1324400745@thecus.kiddle.eu> Message-ID: 2011/12/20 Oliver Kiddle : > Does anyone have any idea why the QA page is showing big numbers for the > upstream release of zsh, see: > ?http://www.opencsw.org/qa/package/zsh/ > > Running gmake get-upstream-latest-version correctly picks up 4.3.15 as > the latest. The first thought is broken integration. From dam at opencsw.org Wed Dec 21 10:00:02 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 21 Dec 2011 10:00:02 +0100 Subject: [csw-maintainers] uWatch and QA page for zsh In-Reply-To: References: <21933.1324400745@thecus.kiddle.eu> Message-ID: <5BB440B8-6FD9-41D7-A682-E5C26C26197C@opencsw.org> Hi, Am 21.12.2011 um 09:56 schrieb Maciej (Matchek) Blizi?ski: > 2011/12/20 Oliver Kiddle : >> Does anyone have any idea why the QA page is showing big numbers for the >> upstream release of zsh, see: >> http://www.opencsw.org/qa/package/zsh/ >> >> Running gmake get-upstream-latest-version correctly picks up 4.3.15 as >> the latest. > > The first thought is broken integration. William spent a lot of effort in the QA system, unfortunately he is quite busy lately with his new job and there is probably a problem as Maciej mentioned. BTW, do we have some docs about the workings about the version detection in the database? 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 Dec 21 11:56:17 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 21 Dec 2011 11:56:17 +0100 Subject: [csw-maintainers] Drop koffice_gcc ? Message-ID: <011C3A3D-C2D4-47E9-81AE-55E55384AE6E@opencsw.org> Hi folks, I am redoing some of the baselibs for ImageMagick and would like to drop one old package (the only one requirung legacy ilmbase libs): koffice_gcc I don't see that this is going to be updated in the future as desktop Solaris is pretty much dead. Comments? 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 Dec 21 12:17:49 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 21 Dec 2011 11:17:49 +0000 Subject: [csw-maintainers] Drop koffice_gcc ? In-Reply-To: <011C3A3D-C2D4-47E9-81AE-55E55384AE6E@opencsw.org> References: <011C3A3D-C2D4-47E9-81AE-55E55384AE6E@opencsw.org> Message-ID: 2011/12/21 Dagobert Michelsen : > I am redoing some of the baselibs for ImageMagick and would like to drop one > old package (the only one requirung legacy ilmbase libs): > ?koffice_gcc > I don't see that this is going to be updated in the future as desktop Solaris is > pretty much dead. > > Comments? We seem to generally go into the direction of the server stuff. Of course, libraries such as GTK still play a major role (kudos to Rafi), but we don't seem to have much traction on the desktop environment side of things. I see it as a good thing, it's better to do less things and do them well. If at any point in time anybody comes along and contributes desktop related packages, they will be more than welcome. At the same time, we shouldn't let the desktop packages stand in our way to what we specialize in. Maciej From pfelecan at opencsw.org Wed Dec 21 13:04:55 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 21 Dec 2011 13:04:55 +0100 Subject: [csw-maintainers] Drop koffice_gcc ? In-Reply-To: <011C3A3D-C2D4-47E9-81AE-55E55384AE6E@opencsw.org> (Dagobert Michelsen's message of "Wed, 21 Dec 2011 11:56:17 +0100") References: <011C3A3D-C2D4-47E9-81AE-55E55384AE6E@opencsw.org> Message-ID: Dagobert Michelsen writes: > I am redoing some of the baselibs for ImageMagick and would like to drop one > old package (the only one requirung legacy ilmbase libs): > koffice_gcc > I don't see that this is going to be updated in the future as desktop Solaris is > pretty much dead. > > Comments? Nothing against dropping the package. However, I don't see what has this to do with the desktop environment. Maybe there is something to clarify in what you/we understand by "desktop environment". -- Peter From dam at opencsw.org Wed Dec 21 13:39:07 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 21 Dec 2011 13:39:07 +0100 Subject: [csw-maintainers] Drop koffice_gcc ? In-Reply-To: References: <011C3A3D-C2D4-47E9-81AE-55E55384AE6E@opencsw.org> Message-ID: <3052D2FB-C928-4E9A-A3F2-5CE964B12FA2@opencsw.org> Hi Peter, Am 21.12.2011 um 13:04 schrieb Peter FELECAN: > Dagobert Michelsen writes: >> I am redoing some of the baselibs for ImageMagick and would like to drop one >> old package (the only one requirung legacy ilmbase libs): >> koffice_gcc >> I don't see that this is going to be updated in the future as desktop Solaris is >> pretty much dead. >> >> Comments? > > Nothing against dropping the package. However, I don't see what has this > to do with the desktop environment. Maybe there is something to clarify > in what you/we understand by "desktop environment". I meant applications that are mainly useful if you are using Solaris for your desktop. An office application I would say is in this category, but e.g. not the gtk Wireshark GUI, which can be useful even on a server for debugging purposes. 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 Dec 21 13:39:51 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 21 Dec 2011 13:39:51 +0100 Subject: [csw-maintainers] Drop koffice_gcc ? In-Reply-To: References: <011C3A3D-C2D4-47E9-81AE-55E55384AE6E@opencsw.org> Message-ID: Hi Maciej, Am 21.12.2011 um 12:17 schrieb Maciej (Matchek) Blizi?ski: > 2011/12/21 Dagobert Michelsen : >> I am redoing some of the baselibs for ImageMagick and would like to drop one >> old package (the only one requirung legacy ilmbase libs): >> koffice_gcc >> I don't see that this is going to be updated in the future as desktop Solaris is >> pretty much dead. > > We seem to generally go into the direction of the server stuff. Of > course, libraries such as GTK still play a major role (kudos to Rafi), > but we don't seem to have much traction on the desktop environment > side of things. I see it as a good thing, it's better to do less > things and do them well. > > If at any point in time anybody comes along and contributes desktop > related packages, they will be more than welcome. At the same time, we > shouldn't let the desktop packages stand in our way to what we > specialize in. Ok, should I delete koffice_gcc with csw-upload-pkg then? 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 Dec 21 14:27:27 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 21 Dec 2011 08:27:27 -0500 Subject: [csw-maintainers] Drop koffice_gcc ? In-Reply-To: References: <011C3A3D-C2D4-47E9-81AE-55E55384AE6E@opencsw.org> Message-ID: <1324473975-sup-3530@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Dec 21 07:39:51 -0500 2011: > Ok, should I delete koffice_gcc with csw-upload-pkg then? +1. I agree with Maciej that things that we should focus on the strengths and not let fringe stuff hold back progress. If somebody becomes interested, it can be re-added at that time. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From dam at opencsw.org Wed Dec 21 14:32:43 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 21 Dec 2011 14:32:43 +0100 Subject: [csw-maintainers] Drop koffice_gcc ? In-Reply-To: <1324473975-sup-3530@pinkfloyd.chass.utoronto.ca> References: <011C3A3D-C2D4-47E9-81AE-55E55384AE6E@opencsw.org> <1324473975-sup-3530@pinkfloyd.chass.utoronto.ca> Message-ID: Hi Ben, Am 21.12.2011 um 14:27 schrieb Ben Walton: > Excerpts from Dagobert Michelsen's message of Wed Dec 21 07:39:51 -0500 2011: > >> Ok, should I delete koffice_gcc with csw-upload-pkg then? > > +1. I agree with Maciej that things that we should focus on the > strengths and not let fringe stuff hold back progress. If somebody > becomes interested, it can be re-added at that time. I can't delete that: > dam at login [login]:/export/mirror/opencsw-official/allpkgs > csw-upload-pkg --remove koffice_addons-1.3-SunOS5.8-all-CSW.pkg.gz koffice_gcc-1.6.3-SunOS5.8-i386-CSW.pkg.gz koffice_gcc-1.6.3-SunOS5.8-sparc-CSW.pkg.gz koffice_i18n-1.3.5-SunOS5.8-all-CSW.pkg.gz > Removing koffice_addons (all SunOS5.8) from catalog unstable i386 SunOS5.10 > Removing koffice_addons (all SunOS5.8) from catalog unstable i386 SunOS5.11 > Removing koffice_addons (all SunOS5.8) from catalog unstable i386 SunOS5.8 > Traceback (most recent call last): > File "/home/dam/bin/csw-upload-pkg", line 606, in > uploader.Remove() > File "/home/dam/bin/csw-upload-pkg", line 179, in Remove > self._RemoveFile(filename) > File "/home/dam/bin/csw-upload-pkg", line 192, in _RemoveFile > self._RemoveFromCatalog(filename, cat_arch, cat_osrel, file_metadata) > File "/home/dam/bin/csw-upload-pkg", line 235, in _RemoveFromCatalog > % (url, http_code, d.getvalue())) > __main__.RestCommunicationError: http://buildfarm.opencsw.org/releases/catalogs/unstable/i386/SunOS5.8/a20559ab50efba6edebf5d33191c58b0/ - HTTP code: 406, content: {"error_message": "package deletions from an obsolete OS release such as SunOS5.8 are not allowed"} > zsh: 6349 exit 1 csw-upload-pkg --remove koffice_addons-1.3-SunOS5.8-all-CSW.pkg.gz > dam at login [login]:/export/mirror/opencsw-official/allpkgs > Just deleting from Solaris 9+10 seems wrong to me. I propose to not integrate koffice_* into dublin and publish the updates for my lib only on the new release. 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 Dec 21 14:52:32 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 21 Dec 2011 13:52:32 +0000 Subject: [csw-maintainers] Drop koffice_gcc ? In-Reply-To: References: <011C3A3D-C2D4-47E9-81AE-55E55384AE6E@opencsw.org> <1324473975-sup-3530@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/12/21 Dagobert Michelsen : > Hi Ben, > > Am 21.12.2011 um 14:27 schrieb Ben Walton: >> Excerpts from Dagobert Michelsen's message of Wed Dec 21 07:39:51 -0500 2011: >> >>> Ok, should I delete koffice_gcc with csw-upload-pkg then? >> >> +1. ?I agree with Maciej that things that we should focus on the >> strengths and not let fringe stuff hold back progress. ?If somebody >> becomes interested, it can be re-added at that time. > > I can't delete that: > >> dam at login [login]:/export/mirror/opencsw-official/allpkgs > csw-upload-pkg --remove koffice_addons-1.3-SunOS5.8-all-CSW.pkg.gz koffice_gcc-1.6.3-SunOS5.8-i386-CSW.pkg.gz koffice_gcc-1.6.3-SunOS5.8-sparc-CSW.pkg.gz koffice_i18n-1.3.5-SunOS5.8-all-CSW.pkg.gz >> Removing koffice_addons (all SunOS5.8) from catalog unstable i386 SunOS5.10 >> Removing koffice_addons (all SunOS5.8) from catalog unstable i386 SunOS5.11 >> Removing koffice_addons (all SunOS5.8) from catalog unstable i386 SunOS5.8 >> Traceback (most recent call last): >> ? File "/home/dam/bin/csw-upload-pkg", line 606, in >> ? ? uploader.Remove() >> ? File "/home/dam/bin/csw-upload-pkg", line 179, in Remove >> ? ? self._RemoveFile(filename) >> ? File "/home/dam/bin/csw-upload-pkg", line 192, in _RemoveFile >> ? ? self._RemoveFromCatalog(filename, cat_arch, cat_osrel, file_metadata) >> ? File "/home/dam/bin/csw-upload-pkg", line 235, in _RemoveFromCatalog >> ? ? % (url, http_code, d.getvalue())) >> __main__.RestCommunicationError: http://buildfarm.opencsw.org/releases/catalogs/unstable/i386/SunOS5.8/a20559ab50efba6edebf5d33191c58b0/ - HTTP code: 406, content: {"error_message": "package deletions from an obsolete OS release such as SunOS5.8 are not allowed"} >> zsh: 6349 exit 1 ? ? csw-upload-pkg --remove koffice_addons-1.3-SunOS5.8-all-CSW.pkg.gz >> dam at login [login]:/export/mirror/opencsw-official/allpkgs > > > Just deleting from Solaris 9+10 seems wrong to me. I propose to not integrate koffice_* into > dublin and publish the updates for my lib only on the new release. Hah, so we did exercise both options: 1. "csw-upload-pkg --remove foo-*-SunOS5.8-*.pkg.gz" with the expectation that it will not get removed from the 5.8 catalog 2. "csw-upload-pkg --remove foo-*-SunOS5.8-*.pkg.gz" with the expectation that it will get removed from the 5.8 catalog Maciej From dam at opencsw.org Wed Dec 21 14:56:48 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 21 Dec 2011 14:56:48 +0100 Subject: [csw-maintainers] Drop koffice_gcc ? In-Reply-To: References: <011C3A3D-C2D4-47E9-81AE-55E55384AE6E@opencsw.org> <1324473975-sup-3530@pinkfloyd.chass.utoronto.ca> Message-ID: <27B0E771-DB4A-4A20-8D35-CF361C5CDAF3@opencsw.org> Hi Maciej, Am 21.12.2011 um 14:52 schrieb Maciej (Matchek) Blizi?ski: > 2011/12/21 Dagobert Michelsen : >> Am 21.12.2011 um 14:27 schrieb Ben Walton: >>> Excerpts from Dagobert Michelsen's message of Wed Dec 21 07:39:51 -0500 2011: >>> >>>> Ok, should I delete koffice_gcc with csw-upload-pkg then? >>> >>> +1. I agree with Maciej that things that we should focus on the >>> strengths and not let fringe stuff hold back progress. If somebody >>> becomes interested, it can be re-added at that time. >> >> I can't delete that: >> >>> dam at login [login]:/export/mirror/opencsw-official/allpkgs > csw-upload-pkg --remove koffice_addons-1.3-SunOS5.8-all-CSW.pkg.gz koffice_gcc-1.6.3-SunOS5.8-i386-CSW.pkg.gz koffice_gcc-1.6.3-SunOS5.8-sparc-CSW.pkg.gz koffice_i18n-1.3.5-SunOS5.8-all-CSW.pkg.gz >>> Removing koffice_addons (all SunOS5.8) from catalog unstable i386 SunOS5.10 >>> Removing koffice_addons (all SunOS5.8) from catalog unstable i386 SunOS5.11 >>> Removing koffice_addons (all SunOS5.8) from catalog unstable i386 SunOS5.8 >>> Traceback (most recent call last): >>> File "/home/dam/bin/csw-upload-pkg", line 606, in >>> uploader.Remove() >>> File "/home/dam/bin/csw-upload-pkg", line 179, in Remove >>> self._RemoveFile(filename) >>> File "/home/dam/bin/csw-upload-pkg", line 192, in _RemoveFile >>> self._RemoveFromCatalog(filename, cat_arch, cat_osrel, file_metadata) >>> File "/home/dam/bin/csw-upload-pkg", line 235, in _RemoveFromCatalog >>> % (url, http_code, d.getvalue())) >>> __main__.RestCommunicationError: http://buildfarm.opencsw.org/releases/catalogs/unstable/i386/SunOS5.8/a20559ab50efba6edebf5d33191c58b0/ - HTTP code: 406, content: {"error_message": "package deletions from an obsolete OS release such as SunOS5.8 are not allowed"} >>> zsh: 6349 exit 1 csw-upload-pkg --remove koffice_addons-1.3-SunOS5.8-all-CSW.pkg.gz >>> dam at login [login]:/export/mirror/opencsw-official/allpkgs > >> >> Just deleting from Solaris 9+10 seems wrong to me. I propose to not integrate koffice_* into >> dublin and publish the updates for my lib only on the new release. > > Hah, so we did exercise both options: > > 1. "csw-upload-pkg --remove foo-*-SunOS5.8-*.pkg.gz" with the > expectation that it will not get removed from the 5.8 catalog > 2. "csw-upload-pkg --remove foo-*-SunOS5.8-*.pkg.gz" with the > expectation that it will get removed from the 5.8 catalog :-) I guess the latter one is indeed wrong. So, I suggest to not integrate koffice_* into "dublin" and push the updated ilm libs only to "dublin". 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 Dec 21 15:00:23 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 21 Dec 2011 14:00:23 +0000 Subject: [csw-maintainers] Drop koffice_gcc ? In-Reply-To: <27B0E771-DB4A-4A20-8D35-CF361C5CDAF3@opencsw.org> References: <011C3A3D-C2D4-47E9-81AE-55E55384AE6E@opencsw.org> <1324473975-sup-3530@pinkfloyd.chass.utoronto.ca> <27B0E771-DB4A-4A20-8D35-CF361C5CDAF3@opencsw.org> Message-ID: 2011/12/21 Dagobert Michelsen : > So, I suggest to not integrate > koffice_* into "dublin" and push the updated ilm libs only to "dublin". It's already in dublin, isn't it? From grzemba at contac-dt.de Mon Dec 19 13:17:11 2011 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Mon, 19 Dec 2011 13:17:11 +0100 Subject: [csw-maintainers] Review for the 389directoryserver project Message-ID: <7490e2a06255.4eef3957@contac-dt.de> Hi, please review my first part of the 389directoryserver project: http://buildfarm.opencsw.org/experimental.html#389directoryserver finnaly the Mozilla LDAP Tools could be a own project (which need the NSPR and NSS). packages CSWlibsvrcore0 CSWlibsvrcore0-dev: pkgrepo: Changeset [16568]: svrcore/trunk: Mozilla Svrcore, first build (http://sourceforge.net/apps/trac/gar/changeset/16568%3E) -- 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 dam at opencsw.org Wed Dec 21 15:43:02 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 21 Dec 2011 15:43:02 +0100 Subject: [csw-maintainers] Review for the 389directoryserver project In-Reply-To: <7490e2a06255.4eef3957@contac-dt.de> References: <7490e2a06255.4eef3957@contac-dt.de> Message-ID: <4BEF8D3E-0EEC-4F8C-8632-F02972C0B051@opencsw.org> Hi Carsten, Am 19.12.2011 um 13:17 schrieb Carsten Grzemba: > please review my first part of the 389directoryserver project: > > http://buildfarm.opencsw.org/experimental.html#389directoryserver This should already be in $(PKGFILES_DEVEL): PKGFILES_CSWlibsvrcore0-dev += /opt/csw/lib/libsvrcore.so This is probably a relict: ARCHALL_CSWgnutlsdevel = 1 I suggest changing this CONFIGURE_ARGS_isa-sparcv9 = --enable-64bit CONFIGURE_ARGS_isa-amd64 = --enable-64bit CONFIGURE_ARGS += $(CONFIGURE_ARGS_$(MODULATION)) to CONFIGURE_ARGS-64 = --enable-64bit CONFIGURE_ARGS += $(CONFIGURE_ARGS-$(MEMORYMODEL)) This looks like CFLAGS is not passed properly: CONFIGURE_ARGS_OPT += --enable-optimize="-xO3" Maybe the contents should be $(CFLAGS) ? I suggest moving this up after PKGFILES_* RUNTIME_DEP_PKGS_CSWlibsvrcore0-dev += CSWlibsvrcore0 Looks pretty good otherwise :-) Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From pfelecan at opencsw.org Wed Dec 21 15:46:46 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 21 Dec 2011 15:46:46 +0100 Subject: [csw-maintainers] Drop koffice_gcc ? In-Reply-To: <3052D2FB-C928-4E9A-A3F2-5CE964B12FA2@opencsw.org> (Dagobert Michelsen's message of "Wed, 21 Dec 2011 13:39:07 +0100") References: <011C3A3D-C2D4-47E9-81AE-55E55384AE6E@opencsw.org> <3052D2FB-C928-4E9A-A3F2-5CE964B12FA2@opencsw.org> Message-ID: Dagobert Michelsen writes: > Hi Peter, > > Am 21.12.2011 um 13:04 schrieb Peter FELECAN: >> Dagobert Michelsen writes: >>> I am redoing some of the baselibs for ImageMagick and would like to drop one >>> old package (the only one requirung legacy ilmbase libs): >>> koffice_gcc >>> I don't see that this is going to be updated in the future as desktop Solaris is >>> pretty much dead. >>> >>> Comments? >> >> Nothing against dropping the package. However, I don't see what has this >> to do with the desktop environment. Maybe there is something to clarify >> in what you/we understand by "desktop environment". > > I meant applications that are mainly useful if you are using Solaris for your > desktop. An office application I would say is in this category, but e.g. not > the gtk Wireshark GUI, which can be useful even on a server for debugging > purposes. Thank you. That is more precise. However, I can use a GUI enabled application as kOffice in the same case as Wireshark isn't it. Anyhow, just drop the beast if there is no maintainer for it. -- Peter From dam at opencsw.org Wed Dec 21 21:10:48 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 21 Dec 2011 21:10:48 +0100 Subject: [csw-maintainers] Strange problem on postinstall Message-ID: Hi folks, I just got a strange problem on the buildfarm when I tried to update unstable9s: > => Removing old version of CSWdjvulibre (1/12) ... > pkgrm: ERROR: bad read of contents file > pkgrm: ERROR: pathname=/etc/opt/csw/odbc.ini.CSW > pkgrm: ERROR: problem=bad end of entry The problematic line in /var/sadm/install/contents looks like this: > /etc/opt/csw/odbc.ini.CSW f cswpreserveconf 0644 root bin 0 0 1324040699 CSWunixodbc:cswcpsampleconf *CSWlibodbc2 I have the impression this is a partial run of installf during cswcpsampleconf. Unfortunately I don't have the log from the earlier run which may have caused 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 dam at opencsw.org Wed Dec 21 21:59:42 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 21 Dec 2011 21:59:42 +0100 Subject: [csw-maintainers] Drop koffice_gcc ? In-Reply-To: References: <011C3A3D-C2D4-47E9-81AE-55E55384AE6E@opencsw.org> <3052D2FB-C928-4E9A-A3F2-5CE964B12FA2@opencsw.org> Message-ID: Hi folks, Am 21.12.2011 um 15:46 schrieb Peter FELECAN: > Dagobert Michelsen writes: >> Am 21.12.2011 um 13:04 schrieb Peter FELECAN: >>> Dagobert Michelsen writes: >>>> I am redoing some of the baselibs for ImageMagick and would like to drop one >>>> old package (the only one requirung legacy ilmbase libs): >>>> koffice_gcc >>>> I don't see that this is going to be updated in the future as desktop Solaris is >>>> pretty much dead. >>>> >>>> Comments? >>> >>> Nothing against dropping the package. However, I don't see what has this >>> to do with the desktop environment. Maybe there is something to clarify >>> in what you/we understand by "desktop environment". >> >> I meant applications that are mainly useful if you are using Solaris for your >> desktop. An office application I would say is in this category, but e.g. not >> the gtk Wireshark GUI, which can be useful even on a server for debugging >> purposes. > > Thank you. That is more precise. > > However, I can use a GUI enabled application as kOffice in the same case > as Wireshark isn't it. > > Anyhow, just drop the beast if there is no maintainer for it. Looks like it is going a bit bigger than I had anticipated: the large CSWkdegcc package depended on koffice_gcc, thus my removal broke a dependency. I would like to remove the other old KDE stuff also, but as there are quite some packages I would like to bring this to maintainers@ first. It is specifically about the package dependencies here: http://www.opencsw.org/packages/CSWkdegcc/ 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 Dec 22 11:37:28 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 22 Dec 2011 10:37:28 +0000 Subject: [csw-maintainers] Experimental directory cleanup Message-ID: I've made a list of the current experimental directory state. The experimental page is currently so big, that even though it's a static HTML file, it takes a long time to load. I've identified directories that could be cleaned up. There are three kinds of issues identified: - empty directories - files that are non-directories (e.g. "jgeorzen") - directories where the youngest files are year old I suggest we clean these directories up. If we don't want to delete the packages, we can move them elsewhere, so they don't bloat the main experimental page. alarmclock old-files, oldest: 2010-10-05 alternatives old-files, oldest: 2010-02-12 amaier old-files, oldest: 2010-02-01 ap2_mod_auth_kerb is empty apache2 is empty apache2-gcc4 is empty bchill old-files, oldest: 2010-02-01 bonivart old-files, oldest: 2010-02-01 bwalton is empty bwalton-submit is empty cfengine3 is empty cpan-B-C old-files, oldest: 2010-12-01 cpan-meta.yml old-files, oldest: 2010-12-16 cswclassutils is empty cswpki is empty cswutils is empty dam old-files, oldest: 2010-04-09 daniel old-files, oldest: 2010-02-01 dlaigle old-files, oldest: 2010-02-01 ellson is empty ffmpeg is empty freeradius old-files, oldest: 2010-12-14 gadavis is empty gamin is empty ganglia is empty gdk-pixbuf is empty git is empty gmarler is empty gnome old-files, oldest: 2010-03-17 gnome-ssh-askpass is empty gnupg is empty grass is empty hson old-files, oldest: 2010-03-28 ihsan is empty imagemagick64 old-files, oldest: 2010-03-30 ja old-files, oldest: 2010-02-01 james is empty jensd old-files, oldest: 2010-09-24 jgeorzen is not a directory jgoerzen is empty jh old-files, oldest: 2010-11-23 joerg old-files, oldest: 2010-06-24 jpeg is empty kerberos is empty kester is empty libconfuse is empty libffi is empty libmagic is empty lsw old-files, oldest: 2010-02-01 maciej old-files, oldest: 2010-06-12 markp is empty mcrypt is empty mike old-files, oldest: 2010-02-01 mwatters old-files, oldest: 2010-02-01 openssh+lpk old-files, oldest: 2010-11-25 opk old-files, oldest: 2010-10-15 perl old-files, oldest: 2010-11-10 perl-critic is empty phil old-files, oldest: 2010-02-01 php5_apc is empty postgresql-shallow old-files, oldest: 2010-09-22 prabatty old-files, oldest: 2010-02-01 pycurl is empty r is empty raos is empty remake is empty ruby-dublin is empty ruby19 old-files, oldest: 2010-10-06 rubygems old-files, oldest: 2010-07-29 rupert is empty schwindt old-files, oldest: 2010-02-01 sendmail is empty tmp old-files, oldest: 2010-09-01 trygvis old-files, oldest: 2010-02-01 unixodbc is empty wbonnet is empty xfce4.8 is empty From bonivart at opencsw.org Thu Dec 22 13:25:54 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 22 Dec 2011 13:25:54 +0100 Subject: [csw-maintainers] Experimental directory cleanup In-Reply-To: References: Message-ID: 2011/12/22 Maciej (Matchek) Blizi?ski : > I suggest we clean these directories up. If we don't want to delete > the packages, we can move them elsewhere, so they don't bloat the main > experimental page. I removed gnupg, perl-critic, r and cleaned up a little in bonivart. /peter From wilbury at opencsw.org Thu Dec 22 13:28:15 2011 From: wilbury at opencsw.org (Juraj Lutter) Date: Thu, 22 Dec 2011 13:28:15 +0100 Subject: [csw-maintainers] Experimental directory cleanup In-Reply-To: References: Message-ID: <4EF3225F.5020209@opencsw.org> On 12/22/2011 01:25 PM, Peter Bonivart wrote: > 2011/12/22 Maciej (Matchek) Blizi?ski : >> I suggest we clean these directories up. If we don't want to delete >> the packages, we can move them elsewhere, so they don't bloat the main >> experimental page. > > I removed gnupg, perl-critic, r and cleaned up a little in bonivart. I removed apache2-gcc4 -- Juraj Lutter From dam at opencsw.org Thu Dec 22 13:58:11 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 22 Dec 2011 13:58:11 +0100 Subject: [csw-maintainers] Experimental directory cleanup In-Reply-To: References: Message-ID: <53499880-C712-44F2-B7B7-338881BA8B7D@opencsw.org> Hi Maciej, Am 22.12.2011 um 11:37 schrieb Maciej (Matchek) Blizi?ski: > I've made a list of the current experimental directory state. The > experimental page is currently so big, that even though it's a static > HTML file, it takes a long time to load. I've identified directories > that could be cleaned up. There are three kinds of issues identified: > > - empty directories > - files that are non-directories (e.g. "jgeorzen") > - directories where the youngest files are year old I made some general cleanup of empty dirs and maintainers who haven't been active for some time. 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 Thu Dec 22 18:16:00 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 22 Dec 2011 12:16:00 -0500 Subject: [csw-maintainers] Experimental directory cleanup In-Reply-To: <53499880-C712-44F2-B7B7-338881BA8B7D@opencsw.org> References: <53499880-C712-44F2-B7B7-338881BA8B7D@opencsw.org> Message-ID: <1324574135-sup-9944@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Thu Dec 22 07:58:11 -0500 2011: > I made some general cleanup of empty dirs and maintainers who > haven't been active for some time. I just nuked a few things too. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Thu Dec 22 18:24:42 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 22 Dec 2011 12:24:42 -0500 Subject: [csw-maintainers] Drop koffice_gcc ? In-Reply-To: References: <011C3A3D-C2D4-47E9-81AE-55E55384AE6E@opencsw.org> <3052D2FB-C928-4E9A-A3F2-5CE964B12FA2@opencsw.org> Message-ID: <1324574494-sup-1617@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Dec 21 15:59:42 -0500 2011: > Looks like it is going a bit bigger than I had anticipated: the > large CSWkdegcc package depended on koffice_gcc, thus my removal > broke a dependency. I would like to remove the other old KDE stuff > also, but as there are quite some packages I would like to bring > this to maintainers@ first. It is specifically about the package > dependencies here: http://www.opencsw.org/packages/CSWkdegcc/ So you're wanting to remove kdegcc and everything that it depends on? Or will you just remove kdegcc? If the former, that will cascade into removing things like amorok, etc when the dependency chain is followed. I'm not opposed to this but it will be a big action. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Tue Dec 27 19:23:28 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 27 Dec 2011 18:23:28 +0000 Subject: [csw-maintainers] Catalog checks via REST Message-ID: Hello maintainers, This is a follow-up to the recent incident with a dependency loop in the package catalog. During the last camp, we've discussed writing own package checks in different languages than Python. To recap, interfacing with other languages is possible but requires additional work. As an intermediate step, I offered access to the package data via REST, so that people can write own checks in any languages they want. If/when there is enough traction for checks in other languages, we can go back to the idea of creating bindings to other languages. The same idea can be applied to catalog checks. I've written a proof-of-concept script in Perl, which pulls catalog information and pretty-prints it. To check a catalog, the script would do some kind of inspection of the data structure and draw some conclusions (e.g. there's a dependency loop). The script is available from our code repository: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/web/examples/catalog_data.pl One of the concerns were "I don't know REST". The answer is that there's nothing to learn. Here's the script body: use LWP::Simple; use JSON; use Data::Dumper; my $url = 'http://buildfarm.opencsw.org/pkgdb/rest/catalogs/unstable/sparc/SunOS5.9/'; my $json_string = get $url; die "Couldn't get $url" unless defined $json_string; my $catalog_data = decode_json $json_string; print Dumper($catalog_data); The current situation with the catalogs is that we don't have good diagnostics of catalogs. If something goes wrong, the new catalog is not pushed, but we have no feedback about what was wrong, until Dagobert pulls out a cron email from the depths of his email inbox. Would anybody be so kind and write a script which polls the catalogs and check them for problems? The script above can serve as a starting point (assuming you want to write in Perl, but you can do the same in any other language that has a JSON library). Maciej From maciej at opencsw.org Tue Dec 27 19:25:45 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 27 Dec 2011 18:25:45 +0000 Subject: [csw-maintainers] GCC 4.6.2 C++ front issue In-Reply-To: References: Message-ID: I sat down at it today and got a reasonable result. I'm now respinning the gcc packages, they should be ready to test some time tomorrow. From maciej at opencsw.org Wed Dec 28 17:51:00 2011 From: maciej at opencsw.org (Maciej (Matchek) Blizinski) Date: Wed, 28 Dec 2011 16:51:00 +0000 Subject: [csw-maintainers] Most shared directory entries Message-ID: It's an old thing one, but perhaps worth mentioning. These are the most popular shared directories, meaning that there are multiple packages that ship them. Given relatively large numbers of packages shipping these directories, perhaps we could move the ownership of these directories to CSWcommon and gradually remove them from the packages? /opt/csw/share/man/man1 563 /opt/csw/share 524 /opt/csw/share/man/man3 496 /opt/csw/lib 410 (there are more of them) Thoughts? From bwalton at opencsw.org Wed Dec 28 18:31:12 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 28 Dec 2011 12:31:12 -0500 Subject: [csw-maintainers] Most shared directory entries In-Reply-To: References: Message-ID: <1325093351-sup-4887@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Wed Dec 28 11:51:00 -0500 2011: > shipping these directories, perhaps we could move the ownership of > these directories to CSWcommon and gradually remove them from the > packages? +1. We should likely add all of the man/man* directories. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Wed Dec 28 18:44:00 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 28 Dec 2011 17:44:00 +0000 Subject: [csw-maintainers] GCC 4.6.2 C++ front issue In-Reply-To: References: Message-ID: The packages fixing http://bugs.opencsw.org/id/4875 are out for testing: http://buildfarm.opencsw.org/experimental.html#gcc-4.6 Please test! To the people who don't recall what's that all about: In these packages, GCC automatically adds /opt/csw/lib or /opt/csw/lib/64 to the RPATH of every produced binary. This may lead to good things or bad things, but the consensus seems to be that the good outweigh the bad. Maciej From bwalton at opencsw.org Wed Dec 28 19:50:43 2011 From: bwalton at opencsw.org (Ben Walton) Date: Wed, 28 Dec 2011 13:50:43 -0500 Subject: [csw-maintainers] Most shared directory entries In-Reply-To: References: Message-ID: <1325098136-sup-5911@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizinski's message of Wed Dec 28 11:51:00 -0500 2011: > Thoughts? Looking at CSWcommon, I see that we currently deliver an arch specific package. The differences (that I can see) are simply that {lib,bin}/ contain different set of directories for isaexec to leverage. Is there any harm in shipping an ARCH=all CSWcommon that provides the super set of directories? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Wed Dec 28 20:02:24 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 28 Dec 2011 19:02:24 +0000 Subject: [csw-maintainers] Most shared directory entries In-Reply-To: <1325098136-sup-5911@pinkfloyd.chass.utoronto.ca> References: <1325098136-sup-5911@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/12/28 Ben Walton : > Is there any harm in shipping an ARCH=all CSWcommon that provides the > super set of directories? It can cause confusion. If I logged on to a sparc server and saw an amd64 directory there, I would be worried. Maciej From dam at opencsw.org Wed Dec 28 22:41:13 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 28 Dec 2011 22:41:13 +0100 Subject: [csw-maintainers] Most shared directory entries In-Reply-To: References: <1325098136-sup-5911@pinkfloyd.chass.utoronto.ca> Message-ID: <6575BA6E-11AF-4EDF-A553-4848807D79BD@opencsw.org> Hi, Am 28.12.2011 um 20:02 schrieb Maciej (Matchek) Blizi?ski: > 2011/12/28 Ben Walton : >> Is there any harm in shipping an ARCH=all CSWcommon that provides the >> super set of directories? > > It can cause confusion. If I logged on to a sparc server and saw an > amd64 directory there, I would be worried. Two things: - We don't ship development files with ARCHALL=1 for the exact same reason as Maciej outlined. I am pretty much against putting amd64-anything on Sparc, be it names or contents. - The common dirs stripped in GAR are taken from the CSWcommon package from Phil. This is generally bad from a workflow perspective. I suggest changing this to having the directories coded in GAR and have a special build description to make a CSWcommon package out of that and feed the directory exclusion at the same time. 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 Dec 28 22:45:08 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 28 Dec 2011 22:45:08 +0100 Subject: [csw-maintainers] Most shared directory entries In-Reply-To: <1325093351-sup-4887@pinkfloyd.chass.utoronto.ca> References: <1325093351-sup-4887@pinkfloyd.chass.utoronto.ca> Message-ID: Hi Ben, Am 28.12.2011 um 18:31 schrieb Ben Walton: > Excerpts from Maciej (Matchek) Blizinski's message of Wed Dec 28 11:51:00 -0500 2011: >> shipping these directories, perhaps we could move the ownership of >> these directories to CSWcommon and gradually remove them from the >> packages? > > +1. We should likely add all of the man/man* directories. I have mixed feelings about directories in CSWcommon. Why do we have them at all? The only real reason I see for CSWcommon are the 64 -> (sparcv9|amd64) symlinks, and even those could be delivered in each package. Could you outline the real value of taking out directories? Additionally we should IMHO strip all locale subdirectories as this is a complete mess - we ship around 30% of the locale-specific subdirs and leave the others for inclusion in each package. If at all I suggest keeping only a minimum set. One more thing: The cause for the warning after bootstrapping CSWpkgutil and then futher installing packages is because pkgutil does not have directory entries for the dirs in CSWcommon making them default owner:group, on update these are "don't belong to anything"-rewritten, so CSWpkgutil is probably a special case to disable exclusion completely. 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 Thu Dec 29 14:49:48 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 29 Dec 2011 08:49:48 -0500 Subject: [csw-maintainers] Most shared directory entries In-Reply-To: References: <1325093351-sup-4887@pinkfloyd.chass.utoronto.ca> Message-ID: <1325165907-sup-825@pinkfloyd.chass.utoronto.ca> Excerpts from Dagobert Michelsen's message of Wed Dec 28 16:45:08 -0500 2011: Hi Dago, > I have mixed feelings about directories in CSWcommon. Why do we have > them at all? The only real reason I see for CSWcommon are the 64 -> > (sparcv9|amd64) symlinks, and even those could be delivered in each > package. Could you outline the real value of taking out directories? Other than inertia, I don't see a huge benefit to this package. I +1'd Maciej's post with the assumption that if we're delivering a CSWcommon, it should be as sane as possible. Aside from trimming the size of install/contents by some amount, I don't really see much benefit to the package at all. I delivers a single file (locale.alias) right now but if we drop the locale directories entirely, then that would go too. I think the only thing that I might deliver in this package if doing it from scratch would be csw.conf that is referenced by quite a few things (pkg-get, class action scripts, apache2 module installation, etc). We could locally encapsulate the cswpreserveconf logic inside the postinstall for CSWcommon to ensure that we don't overwrite csw.conf with csw.conf.CSW. This would let us provide a fairly current template of some sample options that can be set in the file. I think many people don't realize that they have control over enabling daemons, user id ranges, whether or not to enable apache modules, etc. Much like pkgutil.conf.CSW, it would be at least useful to showcase a set of capabilities with some documentation and other references. > Additionally we should IMHO strip all locale subdirectories as this > is a complete mess - we ship around 30% of the locale-specific > subdirs and leave the others for inclusion in each package. If at > all I suggest keeping only a minimum set. Yes, that makes sense. > One more thing: The cause for the warning after bootstrapping > CSWpkgutil and then futher installing packages is because pkgutil > does not have directory entries for the dirs in CSWcommon making > them default owner:group, on update these are "don't belong to > anything"-rewritten, so CSWpkgutil is probably a special case to > disable exclusion completely. That makes sense too, if we continue providing the skeleton directory package. Replying to your other message, if we do carry this package forward, I agree that having GAR be the authoritative source of the list is much better than the current method. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Thu Dec 29 15:58:57 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 29 Dec 2011 14:58:57 +0000 Subject: [csw-maintainers] [IRC] Coloring messages from bots Message-ID: This may be interesting to IRC users on our channel. ceeswi, our bot, posts quite a lot of messages lately. Each commit, wiki page update, or a package upload to the experimental catalog, result now in a message on the channel. At times, it's easy to miss a message from a human if it happpens to fall somewhere in between messages from ceeswi. Here's a tip for irssi users: these settings will match substrings and color whole lines. This way, it's visually obvious which posts are from humans, and which ones are not. /hilight -color %m experimentalpkgs: /hilight -color %m pkgrepo: /hilight -color %C ontwitter: /save This uses simple regex matching; seems to work reasonably well. Unfortunately, there's a bug in irssi which causes nick matching (the -mask option) to not work with full line highlight[1]. I talked to skayser that ceeswi could could itself color the messages. We might Until then, this should be a viable workaround. I don't have ready solutions for other IRC clients, but I suppose that it should be possible in most of the advanced ones. If you know how to do this in other clients, please post! Maciej [1] http://bugs.irssi.org/index.php?do=details&task_id=275 From bwalton at opencsw.org Thu Dec 29 16:05:54 2011 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 29 Dec 2011 10:05:54 -0500 Subject: [csw-maintainers] Catalog checks via REST In-Reply-To: References: Message-ID: <1325171009-sup-1257@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Tue Dec 27 13:23:28 -0500 2011: Hi Maciej, > The current situation with the catalogs is that we don't have good > diagnostics of catalogs. If something goes wrong, the new catalog is > not pushed, but we have no feedback about what was wrong, until > Dagobert pulls out a cron email from the depths of his email inbox. I've considered routing a few mails of this nature to devel@ or buildfarm@ so that they're seen by more people than me. Specifically, I'm considering the mantis and web db update scripts, but others such as catalog generation would be good candidates too. If this were done, we'd want to move the execution of the scripts to role accounts (this should be done anyway) so that multiple people can jump in to look at issues if required. Using the REST URLS, you'd need to rewrite the json -> catalog code (not huge, but still redundant). If we simply routed the email differently, we'd get a heads up and not duplicate code. If you're talking about new, deeper, checks on the catalog than what chkcat currently does then ignore the above paragraph. I still think getting this type of mail in front of multiple people is a good idea though. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From maciej at opencsw.org Thu Dec 29 16:09:24 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 29 Dec 2011 15:09:24 +0000 Subject: [csw-maintainers] [community-building] FLOSS Weekly 195: ZeroMQ Message-ID: Here's a podcast episode from FLOSS Weekly (which featured us in episode 163). I'd like to bring it to the attention of people who are interested in community building. It's not so much about the content, but about the form of the interview. The guest, Pieter Hintjens, handles the conversation exceptionally well. There are so many things he gets right: the way he talks (no noise such us uhms and hums), the straightforward answers he gives, the overall confidence, they are all excellent. Even the awkward questions from Randal at the end (vi vs emacs, favorite scripting language; Randal wants to get people to say 'emacs' and 'perl'), Pieter handles in a cool manner, and doesn't fall into any trap of a polarizing answer. This episode should be presented as a gold standard of how to speak about community. Episode URL: http://twit.tv/show/floss-weekly/195 Direct link: http://www.podtrac.com/pts/redirect.mp3/twit.cachefly.net/floss0195.mp3 Maciej From dam at opencsw.org Thu Dec 29 19:39:11 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 29 Dec 2011 19:39:11 +0100 Subject: [csw-maintainers] [csw-buildfarm] CSWglib2 to CSWlibglib2-0-0 on 9x/9s In-Reply-To: <20111229180545.GA13581@bender.opencsw.org> References: <1325179963-sup-140@pinkfloyd.chass.utoronto.ca> <20111229180545.GA13581@bender.opencsw.org> Message-ID: <97F57167-E72C-472F-B616-813B03344ACB@opencsw.org> Hi folks, Am 29.12.2011 um 19:05 schrieb Rafael Ostertag: > On Thu, Dec 29, 2011 at 12:34:22PM -0500, Ben Walton wrote: >> Excerpts from rupert THURNER's message of Thu Dec 29 10:22:12 -0500 2011: >>> could you please upgrade CSWglib2 to CSWlibglib2-0-0 on 9x/9s? >> >> Something is wonky with the catalog. I've CC'd Rafael here as these >> are his packages and he might know what's up. >> >> I see on 9x/9s: >> >> ==> 3393 packages loaded from /var/opt/csw/pkgutil/catalog.mirror.bo.opencsw.org-official_unstable_i386_5.9 >> Solving needed dependencies ... >> Package CSWlibglib2-dev not in catalog. Exiting. >> >> The same shows up for CSWlibglib2-0-0. >> >> Rafael: Were these released for 10 only? > > Yes, they were indeed. It was decided to go with 5.10 only, since glib2 has > become difficult to properly build even on 5.10... There are two solutions: 1. To just produce something you can depend on CSWlibglib2-0-0 and build for Solaris 10 only and be done with it as Solaris 9 is best effort. 2. If you want to do the best effort for Solaris 9 you must have a conditional dependency and separate packages for Solaris 9 and 10 like PACKAGING_PLATFORMS += solaris9-sparc solaris9-i386 solaris10-sparc solaris10-i386 RUNTIME_DEP_PKGS_CSWsvn-5.9 += CSWglib2 RUNTIME_DEP_PKGS_CSWsvn-5.10 += CSWlibglib2-0-0 RUNTIME_DEP_PKGS_CSWsvn += $(RUNTIME_DEP_PKGS_CSWsvn-$(GAROSREL)) Best regards -- Dago From dam at opencsw.org Thu Dec 29 20:52:00 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 29 Dec 2011 20:52:00 +0100 Subject: [csw-maintainers] Catalog checks via REST In-Reply-To: References: Message-ID: Hi Maciej, Am 27.12.2011 um 19:23 schrieb Maciej (Matchek) Blizi?ski: > This is a follow-up to the recent incident with a dependency loop in > the package catalog. > > During the last camp, we've discussed writing own package checks in > different languages than Python. To recap, interfacing with other > languages is possible but requires additional work. As an intermediate > step, I offered access to the package data via REST, so that people > can write own checks in any languages they want. If/when there is > enough traction for checks in other languages, we can go back to the > idea of creating bindings to other languages. > > The same idea can be applied to catalog checks. > > I've written a proof-of-concept script in Perl, which pulls catalog > information and pretty-prints it. To check a catalog, the script would > do some kind of inspection of the data structure and draw some > conclusions (e.g. there's a dependency loop). > > The script is available from our code repository: > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/web/examples/catalog_data.pl > > One of the concerns were "I don't know REST". The answer is that > there's nothing to learn. Here's the script body: I did some fiddling and get results like this for each entry: { 'catalogname' => 'py_mysql', 'version_string' => '1.2.3,REV=2011.03.13', 'vendor_url' => 'http://pypi.python.org/pypi/MySQL-python', 'md5_sum' => 'b8bd74a346662f8da1edd0f915c1d0ab', 'arch' => 'sparc', 'osrel' => 'SunOS5.9', 'size' => 43319, 'file_basename' => 'py_mysql-1.2.3,REV=2011.03.13-SunOS5.9-sparc-CSW.pkg.gz', 'maintainer_email' => 'maciej at opencsw.org', 'version' => '1.2.3,REV=2011.03.13', 'mtime' => '2011-03-13 07:48:49', 'pkgname' => 'CSWpy-mysql', 'repository_url' => 'https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/lang-python/mysql-python/trunk/Makefile', 'basename' => 'py_mysql-1.2.3,REV=2011.03.13-SunOS5.9-sparc-CSW.pkg.gz', 'maintainer_full_name' => 'Maciej Blizinski', 'filename_arch' => 'sparc', 'rev' => '2011.03.13' }, There is no information about the dependencies. I am really sorry, but I keep forgetting how to get this information. I suggest adding it to this page so it is easily usable next time: http://wiki.opencsw.org/restful-interface Best regards -- Dago From maciej at opencsw.org Thu Dec 29 20:53:50 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 29 Dec 2011 19:53:50 +0000 Subject: [csw-maintainers] Catalog checks via REST In-Reply-To: <1325171009-sup-1257@pinkfloyd.chass.utoronto.ca> References: <1325171009-sup-1257@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/12/29 Ben Walton : > Excerpts from Maciej (Matchek) Blizi?ski's message of Tue Dec 27 13:23:28 -0500 2011: > > Hi Maciej, > >> The current situation with the catalogs is that we don't have good >> diagnostics of catalogs. If something goes wrong, the new catalog is >> not pushed, but we have no feedback about what was wrong, until >> Dagobert pulls out a cron email from the depths of his email inbox. > > I've considered routing a few mails of this nature to devel@ or > buildfarm@ so that they're seen by more people than me. ?Specifically, > I'm considering the mantis and web db update scripts, but others such > as catalog generation would be good candidates too. Yes, this mailing list would be a good target, but in general, we have to be careful with targeting mailing lists with automated emails. We have the code commits currently, but code commits are human-generated. Emails from cron are different, they keep coming day in and day out whether they hold any interesting information or not. We need to keep the email traffic meaningful. > If this were > done, we'd want to move the execution of the scripts to role accounts > (this should be done anyway) so that multiple people can jump in to > look at issues if required. +1 > Using the REST URLS, you'd need to rewrite the json -> catalog code > (not huge, but still redundant). ?If we simply routed the email > differently, we'd get a heads up and not duplicate code. Don't we have duplicate code already? There is a Ruby and a Python implementation. I'm not sure if ckcat can generate emails when necessary while keeping silent when there's nothing interesting to say. > If you're talking about new, deeper, checks on the catalog than what > chkcat currently does then ignore the above paragraph. ?I still think > getting this type of mail in front of multiple people is a good idea > though. Part of the idea is to have asynchronous checks. You could detect problems even before the catalog is generated. Maciej From maciej at opencsw.org Thu Dec 29 20:59:41 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 29 Dec 2011 19:59:41 +0000 Subject: [csw-maintainers] Catalog checks via REST In-Reply-To: References: Message-ID: 2011/12/29 Dagobert Michelsen : > I did some fiddling and get results like this for each entry: > > ? ? ? ? ?{ > ? ? ? ? ? ?'catalogname' => 'py_mysql', > ? ? ? ? ? ?'version_string' => '1.2.3,REV=2011.03.13', > ? ? ? ? ? ?'vendor_url' => 'http://pypi.python.org/pypi/MySQL-python', > ? ? ? ? ? ?'md5_sum' => 'b8bd74a346662f8da1edd0f915c1d0ab', > ? ? ? ? ? ?'arch' => 'sparc', > ? ? ? ? ? ?'osrel' => 'SunOS5.9', > ? ? ? ? ? ?'size' => 43319, > ? ? ? ? ? ?'file_basename' => 'py_mysql-1.2.3,REV=2011.03.13-SunOS5.9-sparc-CSW.pkg.gz', > ? ? ? ? ? ?'maintainer_email' => 'maciej at ...', I expect more spam now. :-P > ? ? ? ? ? ?'version' => '1.2.3,REV=2011.03.13', > ? ? ? ? ? ?'mtime' => '2011-03-13 07:48:49', > ? ? ? ? ? ?'pkgname' => 'CSWpy-mysql', > ? ? ? ? ? ?'repository_url' => 'https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/lang-python/mysql-python/trunk/Makefile', > ? ? ? ? ? ?'basename' => 'py_mysql-1.2.3,REV=2011.03.13-SunOS5.9-sparc-CSW.pkg.gz', > ? ? ? ? ? ?'maintainer_full_name' => 'Maciej Blizinski', > ? ? ? ? ? ?'filename_arch' => 'sparc', > ? ? ? ? ? ?'rev' => '2011.03.13' > ? ? ? ? ?}, > > There is no information about the dependencies. Yes, there is no dependency information, because this particular data structure is retrieved directly from the fields in the MySQL tables. The dependency information is currently only present in the serialized data (a binary blob). To get the full information, you need to retrieve the full deserialized package stats. The URL fragment regex matcher is: /rest/srv4/([0-9a-f]{32})/pkg-stats/ > I am really sorry, but I keep forgetting how to > get this information. I suggest adding it to this page so it is easily usable next time: > ?http://wiki.opencsw.org/restful-interface I updated the wiki: the page to look at is http://buildfarm.opencsw.org/pkgdb/ It has a link to the URL definitions. Maciej From bonivart at opencsw.org Thu Dec 29 21:03:01 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 29 Dec 2011 21:03:01 +0100 Subject: [csw-maintainers] Catalog checks via REST In-Reply-To: References: <1325171009-sup-1257@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/12/29 Maciej (Matchek) Blizi?ski : > I'm not sure if ckcat can generate emails when necessary while keeping > silent when there's nothing interesting to say. Chkcat can be run with --erroronly which supresses all warnings or with --quiet which only returns an exit code of 0 for OK, 1 for warnings found or 2 for errors found. /peter From maciej at opencsw.org Thu Dec 29 21:17:06 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 29 Dec 2011 20:17:06 +0000 Subject: [csw-maintainers] Catalog checks via REST In-Reply-To: References: <1325171009-sup-1257@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/12/29 Peter Bonivart : > 2011/12/29 Maciej (Matchek) Blizi?ski : >> I'm not sure if ckcat can generate emails when necessary while keeping >> silent when there's nothing interesting to say. > > Chkcat can be run with --erroronly which supresses all warnings or > with --quiet which only returns an exit code of 0 for OK, 1 for > warnings found or 2 for errors found. What about sending emails? chkcat doesn't know anything about emails, so it needs either a wrapper, or an extension. You might also want to send only one email from a series from runs. For example, when you check the unstable catalog, you run it {sparc,x86}?{5.8,5.9,5.10,5.11} = 8 times. If there's a problem, the same problem will be present in most of the catalogs. In such case, you don't want to send 8 emails, but only 1 email (with a summary). Someone has to sit down and solve this before we can have meaningful reports on the mailing list. Maciej From bonivart at opencsw.org Thu Dec 29 21:49:51 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 29 Dec 2011 21:49:51 +0100 Subject: [csw-maintainers] Catalog checks via REST In-Reply-To: References: <1325171009-sup-1257@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/12/29 Maciej (Matchek) Blizi?ski : > What about sending emails? chkcat doesn't know anything about emails, > so it needs either a wrapper, or an extension. You might also want to > send only one email from a series from runs. For example, when you > check the unstable catalog, you run it {sparc,x86}?{5.8,5.9,5.10,5.11} > = 8 times. If there's a problem, the same problem will be present in > most of the catalogs. In such case, you don't want to send 8 emails, > but only 1 email (with a summary). Someone has to sit down and solve > this before we can have meaningful reports on the mailing list. To me, the unix way is to combine multiple simple tools to do the job you need at the moment. It would be easy to have a shell wrapper running chkcat against each catalog outputting the errors to a file and only mailing if the file/files actually contain something. /peter From dam at opencsw.org Thu Dec 29 23:04:20 2011 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 29 Dec 2011 23:04:20 +0100 Subject: [csw-maintainers] Catalog checks via REST In-Reply-To: References: Message-ID: <033689A1-FD32-4DCB-9CE3-6C68D3AF6B4B@opencsw.org> Hi Maciej, Am 29.12.2011 um 20:59 schrieb Maciej (Matchek) Blizi?ski: > 2011/12/29 Dagobert Michelsen : >> There is no information about the dependencies. > > Yes, there is no dependency information, because this particular data > structure is retrieved directly from the fields in the MySQL tables. > The dependency information is currently only present in the serialized > data (a binary blob). To get the full information, you need to > retrieve the full deserialized package stats. The URL fragment regex > matcher is: > > /rest/srv4/([0-9a-f]{32})/pkg-stats/ I adjusted my code to retrieve "depends" and "i_depends" for each package and I think this is not practical: getting all the data takes some hours whereas parsing the catalog file takes only a second. I really like the REST approach, but at the current performance the checks are just not feasible. >> I am really sorry, but I keep forgetting how to >> get this information. I suggest adding it to this page so it is easily usable next time: >> http://wiki.opencsw.org/restful-interface > > I updated the wiki: the page to look at is http://buildfarm.opencsw.org/pkgdb/ > > It has a link to the URL definitions. Cool, I found everything I needed in there :-) Best regards -- Dago From rupert at opencsw.org Thu Dec 29 23:06:35 2011 From: rupert at opencsw.org (rupert THURNER) Date: Thu, 29 Dec 2011 23:06:35 +0100 Subject: [csw-maintainers] subversion-1.7.2 now with gnome-keyring, where to put command line keyring tool? Message-ID: hi, subversion-1.7.2 is now compiled with gnome-keyring included. for headless installations, there is no possibility to maintain the keys. mark phippard from collabnet wrote a tool to do this command line based, which is now available as well: https://ctf.open.collab.net/sf/projects/keyring/. this should go into a dedicated package, or would it be good to just add it to gnome keyring? rupert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bonivart at opencsw.org Thu Dec 29 23:32:19 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Thu, 29 Dec 2011 23:32:19 +0100 Subject: [csw-maintainers] mirroring a subset of pkgs In-Reply-To: <4EEF780A.6080208@opencsw.org> References: <4EEAEF36.9050409@opencsw.org> <4EEC1584.7000302@opencsw.org> <20111217093257.GG9345@sebastiankayser.de> <4EEF780A.6080208@opencsw.org> Message-ID: On Mon, Dec 19, 2011 at 6:44 PM, Daniel Pocock wrote: >>> Even so, the approach I have provided for building a mirror is still >>> quite valid for a subset of the catalog, because after I have built my >>> `mini-mirror', I may not want to install every downloaded package on >>> every target machine - I may still want pkgutil to just pick some of the >>> packages and their dependencies when I am on each target host. >> >> Yes, building an internal mirror based on a subset of packages is >> something that's likely a common use case. Do we have a tutorial, FAQ >> entry, or wiki page for how to do that? If not, we should get one. > > I attach another copy of the script, slightly improved > > Before making a document, should this become part of the pkgutil SVN, or > should I start another repo for it? Have you looked at the pkgutilplus package? There's a script in it contributed by Dago that builds a mirror structure, it's used for our experimental repo (http://buildfarm.opencsw.org/experimental.html). If your script is substantially different than his I would gladly include it in the pkgutilplus package. /peter From maciej at opencsw.org Fri Dec 30 00:44:52 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 29 Dec 2011 23:44:52 +0000 Subject: [csw-maintainers] Catalog checks via REST In-Reply-To: <033689A1-FD32-4DCB-9CE3-6C68D3AF6B4B@opencsw.org> References: <033689A1-FD32-4DCB-9CE3-6C68D3AF6B4B@opencsw.org> Message-ID: 2011/12/29 Dagobert Michelsen : > I adjusted my code to retrieve "depends" and "i_depends" for each package and > I think this is not practical: getting all the data takes some hours > whereas parsing the catalog file takes only a second. I really like the > REST approach, but at the current performance the checks are just not > feasible. That's true. I've been planning to extend the mysql table structure to accommodate the dependency (and more) information. I kept on being distracted by things such as GCC and now MySQL and OpenSSL (dynamic prototypes). To get the schema change done, I'll have to pause the work on packages and get back to tool development. Meanwhile, did you do any measurements, how long would it take to retrieve a whole catalog? Is it a day, or a week, or a month? Another observation is that one query runs on one core only. The buildfarm has many cores, so you can gain performance by making multiple calls in parallel, which will be processed in parallel. This can probably shorten the required time five- to tenfold. Maciej From pfelecan at opencsw.org Fri Dec 30 11:28:39 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 30 Dec 2011 11:28:39 +0100 Subject: [csw-maintainers] Most shared directory entries In-Reply-To: <1325165907-sup-825@pinkfloyd.chass.utoronto.ca> (Ben Walton's message of "Thu, 29 Dec 2011 08:49:48 -0500") References: <1325093351-sup-4887@pinkfloyd.chass.utoronto.ca> <1325165907-sup-825@pinkfloyd.chass.utoronto.ca> Message-ID: Ben Walton writes: > Replying to your other message, if we do carry this package forward, I > agree that having GAR be the authoritative source of the list is much > better than the current method. This is so if everything is packaged through GAR, which is far from true, isn't it? -- Peter From maciej at opencsw.org Fri Dec 30 12:00:20 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 30 Dec 2011 11:00:20 +0000 Subject: [csw-maintainers] Most shared directory entries In-Reply-To: References: <1325093351-sup-4887@pinkfloyd.chass.utoronto.ca> <1325165907-sup-825@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/12/30 Peter FELECAN : >> Replying to your other message, if we do carry this package forward, I >> agree that having GAR be the authoritative source of the list is much >> better than the current method. > > This is so if everything is packaged through GAR, which is far from > true, isn't it? I think that Ben's point can be rephrased as: "having GAR code to be the authoritative source" Meaning, that there is a file in our code repository, which can be used as information source, by GAR just as well as any other tool. Maciej From pfelecan at opencsw.org Fri Dec 30 12:53:33 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 30 Dec 2011 12:53:33 +0100 Subject: [csw-maintainers] Most shared directory entries In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Fri, 30 Dec 2011 11:00:20 +0000") References: <1325093351-sup-4887@pinkfloyd.chass.utoronto.ca> <1325165907-sup-825@pinkfloyd.chass.utoronto.ca> Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2011/12/30 Peter FELECAN : >>> Replying to your other message, if we do carry this package forward, I >>> agree that having GAR be the authoritative source of the list is much >>> better than the current method. >> >> This is so if everything is packaged through GAR, which is far from >> true, isn't it? > > I think that Ben's point can be rephrased as: > > "having GAR code to be the authoritative source" > > Meaning, that there is a file in our code repository, which can be > used as information source, by GAR just as well as any other tool. Well, given the prohibitive time taken to extract and upgrade a working copy of GAR I'm not very warm for this as a generic solution. I know that I can extract the incriminated file but what I wish is to have a more granular GAR but this is another subject. -- Peter From maciej at opencsw.org Fri Dec 30 14:28:36 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 30 Dec 2011 13:28:36 +0000 Subject: [csw-maintainers] Most shared directory entries In-Reply-To: References: <1325093351-sup-4887@pinkfloyd.chass.utoronto.ca> <1325165907-sup-825@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/12/30 Peter FELECAN : > Well, given the prohibitive time taken to extract and upgrade a working > copy of GAR I'm not very warm for this as a generic solution. I know > that I can extract the incriminated file but what I wish is to have a > more granular GAR but this is another subject. Prohibitive? It takes sixteen seconds. $ time svn co -q http://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/v2 gar-from-svn real 0m16.914s user 0m0.210s sys 0m0.200s From pfelecan at opencsw.org Fri Dec 30 14:56:30 2011 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 30 Dec 2011 14:56:30 +0100 Subject: [csw-maintainers] Most shared directory entries In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Fri, 30 Dec 2011 13:28:36 +0000") References: <1325093351-sup-4887@pinkfloyd.chass.utoronto.ca> <1325165907-sup-825@pinkfloyd.chass.utoronto.ca> Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2011/12/30 Peter FELECAN : >> Well, given the prohibitive time taken to extract and upgrade a working >> copy of GAR I'm not very warm for this as a generic solution. I know >> that I can extract the incriminated file but what I wish is to have a >> more granular GAR but this is another subject. > > Prohibitive? It takes sixteen seconds. > > $ time svn co -q > http://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/v2 > gar-from-svn > > real 0m16.914s > user 0m0.210s > sys 0m0.200s I'm not talking about the extraction this repository, which BTW is: real 0m19.221s user 0m0.209s sys 0m0.365s on my system and which is alright. I'm thinking to the "recipes" (you know, I'm still wondering how to make a whole build server for my maintenance usage in my lab not somewhere far, &c). If the reference file that we mentioned in the original discussion is in the repository cited above, it can be alright. -- Peter From maciej at opencsw.org Fri Dec 30 17:09:22 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 30 Dec 2011 16:09:22 +0000 Subject: [csw-maintainers] Most shared directory entries In-Reply-To: References: <1325093351-sup-4887@pinkfloyd.chass.utoronto.ca> <1325165907-sup-825@pinkfloyd.chass.utoronto.ca> Message-ID: 2011/12/30 Peter FELECAN : > I'm thinking to the "recipes" (you know, I'm still wondering how to > make a whole build server for my maintenance usage in my lab not > somewhere far, &c). The full checkout is admittedly heavy. I had ideas how to make it lighter, but it's a general problem which ails all larger source controlled build repositories. Currently, our incremental updates take about 2-5 minutes, while an empty update takes about 40 seconds. But let's have that discussion in a separate thread. > If the reference file that we mentioned in the original discussion is in > the repository cited above, it can be alright. I believe the reference was to these two files: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/v2/etc/commondirs-i386 https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/v2/etc/commondirs-sparc They are already used by checkpkg. From maciej at opencsw.org Fri Dec 30 19:15:03 2011 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 30 Dec 2011 18:15:03 +0000 Subject: [csw-maintainers] Catalog checks via REST In-Reply-To: References: <033689A1-FD32-4DCB-9CE3-6C68D3AF6B4B@opencsw.org> Message-ID: I've pushed GCC to experimental, but haven't gotten a notification email. I think we might have a bad catalog, and we don't know why. From bwalton at opencsw.org Fri Dec 30 19:46:44 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 30 Dec 2011 13:46:44 -0500 Subject: [csw-maintainers] subversion-1.7.2 now with gnome-keyring, where to put command line keyring tool? In-Reply-To: References: Message-ID: <1325270723-sup-2477@pinkfloyd.chass.utoronto.ca> Excerpts from rupert THURNER's message of Thu Dec 29 17:06:35 -0500 2011: Hi Rupert, > subversion-1.7.2 is now compiled with gnome-keyring included. for Nice! > headless installations, there is no possibility to maintain the > keys. mark phippard from collabnet wrote a tool to do this command > line based, which is now available as well: > https://ctf.open.collab.net/sf/projects/keyring/. this should go > into a dedicated package, or would it be good to just add it to > gnome keyring? I'd go separate package here since it doesn't seem to be included in the contrib/ directory of the subversion package itself. You might reference it from README.CSW in CSWsvn though. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bonivart at opencsw.org Fri Dec 30 20:06:34 2011 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 30 Dec 2011 20:06:34 +0100 Subject: [csw-maintainers] Catalog checks via REST In-Reply-To: References: <033689A1-FD32-4DCB-9CE3-6C68D3AF6B4B@opencsw.org> Message-ID: 2011/12/30 Maciej (Matchek) Blizi?ski : > I've pushed GCC to experimental, but haven't gotten a notification > email. I think we might have a bad catalog, and we don't know why. Do you mean unstable? In what stage has the process stopped and what stopped it? You could upload it into the database after passing checkpkg tests so it's when the cron job tries to produce a catalog from the database it breaks, probably due to chkcat complaining, right? Couldn't the output of the chkcat run always be put on a fixed path browseable? So anyone knowing the url for a catalog could check it themselves. Also, Dago had some performance tips regarding chkcat so maybe it could be run when doing the uploading. /peter From bwalton at opencsw.org Fri Dec 30 20:13:59 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 30 Dec 2011 14:13:59 -0500 Subject: [csw-maintainers] Catalog checks via REST In-Reply-To: References: <1325171009-sup-1257@pinkfloyd.chass.utoronto.ca> Message-ID: <1325272370-sup-8583@pinkfloyd.chass.utoronto.ca> Excerpts from Maciej (Matchek) Blizi?ski's message of Thu Dec 29 15:17:06 -0500 2011: > > Chkcat can be run with --erroronly which supresses all warnings or > > with --quiet which only returns an exit code of 0 for OK, 1 for > > warnings found or 2 for errors found. > > What about sending emails? chkcat doesn't know anything about > emails, so it needs either a wrapper, or an extension. You might > also want to send only one email from a series from runs. For > example, when you check the unstable catalog, you run it > {sparc,x86}?{5.8,5.9,5.10,5.11} = 8 times. If there's a problem, the > same problem will be present in most of the catalogs. In such case, > you don't want to send 8 emails, but only 1 email (with a > summary). Someone has to sit down and solve this before we can have > meaningful reports on the mailing list. We currently have a single job that generates all of the catalogs and has them signed. This script could be wrapped to suppress mail unless there is an error[1] or have the scripts it drives run quietly and only spew cron mail on stderr or non-zero exit. That would be a better solution, imo. It takes care of being courteous to mailboxes and summarizing everything. This all assumes that the script is spamming Dago every time it runs, which is something I don't know. Thanks -Ben [1] I have a script that does this already (as I'm sure many of you do as well). If it's useful here, I'll share it. -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From bwalton at opencsw.org Fri Dec 30 20:20:02 2011 From: bwalton at opencsw.org (Ben Walton) Date: Fri, 30 Dec 2011 14:20:02 -0500 Subject: [csw-maintainers] Most shared directory entries In-Reply-To: References: <1325093351-sup-4887@pinkfloyd.chass.utoronto.ca> <1325165907-sup-825@pinkfloyd.chass.utoronto.ca> Message-ID: <1325272457-sup-6143@pinkfloyd.chass.utoronto.ca> Excerpts from Peter FELECAN's message of Fri Dec 30 05:28:39 -0500 2011: Hi Peter, > This is so if everything is packaged through GAR, which is far from > true, isn't it? I think the change that we're talking about would be transparent to non-GAR users. The current GAR workflow is: 1. New CSWcommon is released. 2. Somebody updates files in GAR to reflect changes. 3. New packages from GAR exclude 'base' directories as listed in the updated files. For non-GAR users, if packages are ignoring the directories at all, I'd presume that you're grabbing CSWcommon and building a list externally somewhere. I think this would (or could) remain unchanged. The GAR workflow would become: 1. Update list of directories/files to exclude from base package. 2. Run recipe to build new CSWcommon. 3. CSWcommon is built based on file list in GAR. 4. CSWcommon is published an others can use it as a basis for excludes. It seems that you're ok with extracting the pair of files required from SVN without grabbing the rest of GAR or the recipe tree though, so either the old non-GAR workflow or a slight modification to fetch these lists would be fine. (I'm pretty sure we're all on the same page now, so this is just a summary/clarification.) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 From juraj at lutter.sk Thu Dec 22 13:28:10 2011 From: juraj at lutter.sk (Juraj Lutter) Date: Thu, 22 Dec 2011 12:28:10 -0000 Subject: [csw-maintainers] Experimental directory cleanup In-Reply-To: References: Message-ID: <4EF3224D.2040907@lutter.sk> On 12/22/2011 01:25 PM, Peter Bonivart wrote: > > I removed gnupg, perl-critic, r and cleaned up a little in bonivart. I removed apache2-gcc4 -- Juraj Lutter | /\ ASCII Ribbon Campaign otis (at) wilbury (dot) sk | \/ - NO HTML/RTF in e-mail http://www.wilbury.sk/ | /\ - NO Word docs in e-mail JID: otis (at) jabber (dot) vx (dot) sk !07/11 PDP a ni deppart m'I !pleH