Re: Emacs on AMD64
Ah, there is a new release of emacs now: "http://developers.slashdot.org/developers/07/06/04/2113201.shtml";. Maybe it will resolve this issue? On Thu, 2007-05-31 at 15:31 -0700, David M. Fetter wrote: > Well, I went to look at the cvs for emacs and I found the following link > with the notable excerpt: > > http://cvs.savannah.gnu.org/viewvc/emacs/emacs/etc/MACHINES?revision=1.24&view=markup > > ---BEGIN--- > X86_64 GNU/Linux > > No special procedures should be needed to build a 64-bit Emacs. To > build a 32-bit Emacs, first ensure that the necessary 32-bit system > libraries and include files are installed. Then use: > > env CC="gcc -m32" ./configure --build=i386-linux-gnu \ > --x-libraries=/usr/X11R6/lib > > (using the location of the 32-bit X libraries on your system). > ---END--- > > It seems to me that this would just build a 32-bit version of emacs on a > 64-bit system, which is probably fine. If this is the case then it > could just be a slight modification of the spec file based on a platform > case statement. If somebody else doesn't get to trying this out before > me, then I'll likely test this out in the near future. > > On Thu, 2007-05-31 at 14:54 -0700, Doug Summers wrote: > > David M. Fetter wrote: > > > Is there any word on this problem? I just tried to build emacs again > > > from current on the RHEL4 64-bit but it still wasn't recognizing the > > > architecture. > > > > > > + ./configure --cache-file=./config.cache --prefix=/usr/local --with-x > > > --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib64 > > > --without-toolkit-scroll-bars --with-jpeg --with-png --with-tiff > > > --with-gif --with-x-toolkit=athena > > > loading cache ./config.cache > > > checking host system type... x86_64-unknown-linux-gnu > > > configure: error: Emacs hasn't been ported to `x86_64-unknown-linux-gnu' > > > systems. > > > Check `etc/MACHINES' for recognized configuration names. > > > > > > > > > On Wed, 2007-03-21 at 11:19 -0700, David M. Fetter wrote: > > >> It seems that this is still a problem, at least it is for us on RHEL4 > > >> 64-bit. We have partially looked into this and found that it might be > > >> able to be fixed with the newer release or maybe by doing some hacking > > >> with shtool or whatnot to add in the new architectures to it's > > >> detection. I would think that just MFC'ing the newer version into the > > >> 2-Stable would be easiest though. Could this be done? > > >> > > >> On Tue, 2006-07-18 at 13:33 -0700, Doug Summers wrote: > > >>> Bill Campbell wrote: > > >>>> On Tue, Jul 18, 2006, Ralf S. Engelschall wrote: > > >>>>> On Tue, Jul 18, 2006, Doug Summers wrote: > > >>>>> > > >>>>>> I can't build emacs from any version available. It keeps complaining > > >>>>>> about the host type not being supported. I noticed that the code is > > >>>>>> fairly old - is there a newer version available? > > >>>>> Which particular Emacs version on which AMD64-based OS have you tried? > > >>>> I just tried this on SuSE Linux Enterprise 9 with an Athlon 64, > > >>>> building emacs-21.4a-2.5.0.src.rpm. > > >>>> > > >>>> The problem appears that the configure script at line 1643 recognizes > > >>>> amd64*-*-*, and at line 1635 recognizes ia64*-*-* while the host system > > >>>> type comes up with x86_64-unknown-linux-gnu. > > >>>> > > >>>> It appears that some hacking is necessary on the configure file > > >>>> to get the right combination. > > >>>> > > >>>> I'm up to my a$$ in alligators now so don't have time to hack on > > >>>> this (and I'm a vi bigot not emacs :-). > > >>>> > > >>>> Bill > > >>>> -- > > >>>> INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC > > >>>> URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way > > >>>> FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) > > >>>> 236-1676 > > >>>> > > >>>> The Constitution is a written instrument. As such, its meaning > > >>>> does not alter. That which it meant when it wa
Re: samba dependencies
On Sat, 2007-06-02 at 08:54 +0200, Ralf S. Engelschall wrote: > On Fri, Jun 01, 2007, David Fetter wrote: > > > On Fri, 2007-06-01 at 22:39 +0200, Ralf S. Engelschall wrote: > > > On Thu, May 31, 2007, David M. Fetter wrote: > > > > > > > As I was building the latest samba rpm for the security issue, I noticed > > > > that there were a couple of incorrect dependencies... > > > > > > > > The first is that it required "openpkg >= 20060823", which is not true. > > > > It doesn't seem to have any specific relation to which version of > > > > openpkg that is being used. > > > > [...] > > > > > > IMHO the dependency is logically correct as rc.samba contains > > > "[EMAIL PROTECTED]@/bin/openpkg rc" which uses the "openpkg" frontend > > > (instead > > > of calling "rc" directly) and this went into SetUID mode on 20060823 > > > accrording to the HISTORY file of the "openpkg" package. So, you're > > > right: technically still still might work, but at least logically > > > packages using "openpkg rc" really do this because of the SetUID > > > functionality is now in effect. > > > > Ah, well then that makes sense. It isn't clear why it had this > > dependency when it did work under older version of openpkg. > > > > > > > > > [...] > > > > The second is that this new samba does require the latest kerberos-1.6 > > > > version, but this isn't listed as a requirement at all. It took me a > > > > little bit to determine that I should rebuild the latest kerberos from > > > > current prior to rebuilding the latest samba, which then in turn made > > > > samba build successfully. Including requirements such as this would be > > > > highly useful because it would eliminate time spent to troubleshoot why > > > > it isn't building when it's simply a BuildPreReq. > > > > > > Do you mean "samba" required "kerberos" if you have _NOT_ used > > > "kerberos::with_ads=yes"? If this is the case, then not the dependency > > > is missing but Samba accidental uses Kerberos now. Then we have not > > > to add the depdendency. Then we have to fix Samba. If it is just > > > under "with_ads=yes" everything is fine. > > > > Well, kerberos doesn't seem to have an option of > > "kerberos::with_ads=yes". It has the following option for the old 1.4 > > rpm: > > Err. sorry, I means samba::with_adns, of course. > > > > kerberos::with_fsl = yes > > > > and these options in the new 1.6 rpm: > > > > kerberos::with_fsl = yes > > kerberos::with_server = yes > > > > The options I built with samba are: > > > > samba::with_pam = yes > > samba::with_swat = yes > > samba::with_acl = yes > > samba::with_ldap = yes > > samba::with_ads = yes > > > > Without building the latest 1.6 version of kerberos, samba would not > > build. After building kerberos-1.6 and installing it, samba built, > > installed and worked fine. > > Ah, ok. So you really have with_ads=yes. Ok, this explains why Kerberos > is required. But your point is that really Kerberos __1.6__ is required, > right? And older 1.5 version doesn't work, right? So we have to make the > dependency stronger? Correct. And this is also a bigger problem within the RPM realm essentially. By that, I mean that it goes beyond OpenPKG, but OpenPKG could take this dependency issue and address it thus making OpenPKG stronger in yet another facet. > >Ralf S. Engelschall >[EMAIL PROTECTED] >www.engelschall.com > > __ > OpenPKG http://openpkg.org > User Communication List openpkg-users@openpkg.org > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: Emacs on AMD64
Well, I went to look at the cvs for emacs and I found the following link with the notable excerpt: http://cvs.savannah.gnu.org/viewvc/emacs/emacs/etc/MACHINES?revision=1.24&view=markup ---BEGIN--- X86_64 GNU/Linux No special procedures should be needed to build a 64-bit Emacs. To build a 32-bit Emacs, first ensure that the necessary 32-bit system libraries and include files are installed. Then use: env CC="gcc -m32" ./configure --build=i386-linux-gnu \ --x-libraries=/usr/X11R6/lib (using the location of the 32-bit X libraries on your system). ---END--- It seems to me that this would just build a 32-bit version of emacs on a 64-bit system, which is probably fine. If this is the case then it could just be a slight modification of the spec file based on a platform case statement. If somebody else doesn't get to trying this out before me, then I'll likely test this out in the near future. On Thu, 2007-05-31 at 14:54 -0700, Doug Summers wrote: > David M. Fetter wrote: > > Is there any word on this problem? I just tried to build emacs again > > from current on the RHEL4 64-bit but it still wasn't recognizing the > > architecture. > > > > + ./configure --cache-file=./config.cache --prefix=/usr/local --with-x > > --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib64 > > --without-toolkit-scroll-bars --with-jpeg --with-png --with-tiff > > --with-gif --with-x-toolkit=athena > > loading cache ./config.cache > > checking host system type... x86_64-unknown-linux-gnu > > configure: error: Emacs hasn't been ported to `x86_64-unknown-linux-gnu' > > systems. > > Check `etc/MACHINES' for recognized configuration names. > > > > > > On Wed, 2007-03-21 at 11:19 -0700, David M. Fetter wrote: > >> It seems that this is still a problem, at least it is for us on RHEL4 > >> 64-bit. We have partially looked into this and found that it might be > >> able to be fixed with the newer release or maybe by doing some hacking > >> with shtool or whatnot to add in the new architectures to it's > >> detection. I would think that just MFC'ing the newer version into the > >> 2-Stable would be easiest though. Could this be done? > >> > >> On Tue, 2006-07-18 at 13:33 -0700, Doug Summers wrote: > >>> Bill Campbell wrote: > >>>> On Tue, Jul 18, 2006, Ralf S. Engelschall wrote: > >>>>> On Tue, Jul 18, 2006, Doug Summers wrote: > >>>>> > >>>>>> I can't build emacs from any version available. It keeps complaining > >>>>>> about the host type not being supported. I noticed that the code is > >>>>>> fairly old - is there a newer version available? > >>>>> Which particular Emacs version on which AMD64-based OS have you tried? > >>>> I just tried this on SuSE Linux Enterprise 9 with an Athlon 64, > >>>> building emacs-21.4a-2.5.0.src.rpm. > >>>> > >>>> The problem appears that the configure script at line 1643 recognizes > >>>> amd64*-*-*, and at line 1635 recognizes ia64*-*-* while the host system > >>>> type comes up with x86_64-unknown-linux-gnu. > >>>> > >>>> It appears that some hacking is necessary on the configure file > >>>> to get the right combination. > >>>> > >>>> I'm up to my a$$ in alligators now so don't have time to hack on > >>>> this (and I'm a vi bigot not emacs :-). > >>>> > >>>> Bill > >>>> -- > >>>> INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC > >>>> URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way > >>>> FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) > >>>> 236-1676 > >>>> > >>>> The Constitution is a written instrument. As such, its meaning > >>>> does not alter. That which it meant when it was adopted, it > >>>> means now. > >>>> -- SOUTH CAROLINA v. US, 199 U.S. 437, 448 (1905) > >>>> __ > >>>> The OpenPKG Project www.openpkg.org > >>>> User Communication List openpkg-users@openpkg.org > >>> Supposedly the more recent CVS versions of Emacs fix this problem, but I > >>> haven't tested it yet. > >>> > >>> Ralph - I'll give this a try later on tonight and let you know if it > >>> works and what version. > >>> > >>> Doug > >>> __ > If I can get the source RPM that RedHat uses I can look at the .spec and > see how they define 64-bit machines. > __ > OpenPKG http://openpkg.org > User Communication List openpkg-users@openpkg.org > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: Emacs on AMD64
Is there any word on this problem? I just tried to build emacs again from current on the RHEL4 64-bit but it still wasn't recognizing the architecture. + ./configure --cache-file=./config.cache --prefix=/usr/local --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib64 --without-toolkit-scroll-bars --with-jpeg --with-png --with-tiff --with-gif --with-x-toolkit=athena loading cache ./config.cache checking host system type... x86_64-unknown-linux-gnu configure: error: Emacs hasn't been ported to `x86_64-unknown-linux-gnu' systems. Check `etc/MACHINES' for recognized configuration names. On Wed, 2007-03-21 at 11:19 -0700, David M. Fetter wrote: > It seems that this is still a problem, at least it is for us on RHEL4 > 64-bit. We have partially looked into this and found that it might be > able to be fixed with the newer release or maybe by doing some hacking > with shtool or whatnot to add in the new architectures to it's > detection. I would think that just MFC'ing the newer version into the > 2-Stable would be easiest though. Could this be done? > > On Tue, 2006-07-18 at 13:33 -0700, Doug Summers wrote: > > Bill Campbell wrote: > > > On Tue, Jul 18, 2006, Ralf S. Engelschall wrote: > > >> On Tue, Jul 18, 2006, Doug Summers wrote: > > >> > > >>> I can't build emacs from any version available. It keeps complaining > > >>> about the host type not being supported. I noticed that the code is > > >>> fairly old - is there a newer version available? > > >> Which particular Emacs version on which AMD64-based OS have you tried? > > > > > > I just tried this on SuSE Linux Enterprise 9 with an Athlon 64, > > > building emacs-21.4a-2.5.0.src.rpm. > > > > > > The problem appears that the configure script at line 1643 recognizes > > > amd64*-*-*, and at line 1635 recognizes ia64*-*-* while the host system > > > type comes up with x86_64-unknown-linux-gnu. > > > > > > It appears that some hacking is necessary on the configure file > > > to get the right combination. > > > > > > I'm up to my a$$ in alligators now so don't have time to hack on > > > this (and I'm a vi bigot not emacs :-). > > > > > > Bill > > > -- > > > INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC > > > URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way > > > FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) > > > 236-1676 > > > > > > The Constitution is a written instrument. As such, its meaning > > > does not alter. That which it meant when it was adopted, it > > > means now. > > > -- SOUTH CAROLINA v. US, 199 U.S. 437, 448 (1905) > > > __ > > > The OpenPKG Projectwww.openpkg.org > > > User Communication List openpkg-users@openpkg.org > > > > Supposedly the more recent CVS versions of Emacs fix this problem, but I > > haven't tested it yet. > > > > Ralph - I'll give this a try later on tonight and let you know if it > > works and what version. > > > > Doug > > __ > > The OpenPKG Projectwww.openpkg.org > > User Communication List openpkg-users@openpkg.org > > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
r fails to build on RHEL4 64-bit
I'm trying to build the r package on RHEL4 64-bit platform but it fails with this: /usr/local/bin/cc -std=gnu99 -I. -I../../../src/include -I../../../src/include -I/usr/local/include -DHAVE_CONFIG_H -fpic -fPIC -c Lapack.c -o Lapack.o /usr/local/bin/cc -std=gnu99 -shared -L/usr/local/lib -o lapack.so Lapack.o -L../../../lib -lRlapack -L../../../lib -lRblas -lgfortran -lm /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/libgfortranbegin.a /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/libgfortran.a /usr/local/bin/ld: skipping incompatible /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/libgfortran.a when searching for -lgfortran /usr/local/bin/ld: /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../lib64/libgfortran.a(pow_i4_i4.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../lib64/libgfortran.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[4]: *** [lapack.so] Error 1 make[3]: *** [R] Error 2 make[2]: *** [R] Error 1 make[1]: *** [R] Error 1 make: *** [R] Error 1 Has anybody come across this? -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
samba dependencies
As I was building the latest samba rpm for the security issue, I noticed that there were a couple of incorrect dependencies... The first is that it required "openpkg >= 20060823", which is not true. It doesn't seem to have any specific relation to which version of openpkg that is being used. Specifically, I had to modify the spec file so that it would build for our 2.3 openpkg systems. We are working on replacing these with a newer version of openpkg but we're still at least 6-9 months away from replacing all of our servers. In any case, changing the openpkg version requirement had no ill effect and worked with no issue. Putting a specific version requirement in place such as this seems to artificially create a dependency that really isn't true and in turn could cause some grief in the long run, though perhaps not significant grief. The second is that this new samba does require the latest kerberos-1.6 version, but this isn't listed as a requirement at all. It took me a little bit to determine that I should rebuild the latest kerberos from current prior to rebuilding the latest samba, which then in turn made samba build successfully. Including requirements such as this would be highly useful because it would eliminate time spent to troubleshoot why it isn't building when it's simply a BuildPreReq. In any case, I just wanted to point this out. It isn't really totally specific to samba, nor is it an openpkg specific dilemma. I do realize that this is more of a global rpm dilemma, however, since openpkg is essentially improving rpm I thought it's worth bringing up. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: Samba 3.0.25 Issues
Did you try running testparm against the conf file to see if perhaps there was some configuration change in the new version? On Tue, 2007-05-22 at 10:13 -0700, Doug Summers wrote: > Been using samba-3.0.24-20070211 for months with no problems. I tried > upgrading to samba-3.0.25-20070519 and I can't connect, using the same > smb.conf file. Here are the particulars: > > # global parameters > [global] > workgroup= xxx > netbios name = xxx > server string= xxx.xxx.xxx (Samba %v) > smb passwd file = /openpkg/etc/samba/smb.passwd > pid directory= /openpkg/var/samba/run > lock directory = /openpkg/var/samba/run/locks > log level= 3 > log file = /openpkg/var/samba/logs/log.%m > max log size = 1000 > > security = server > password server = xxx.yyy.com, zzz.yyy.com > encrypt passwords= yes > share modes = no > printing = bsd > printcap name= /etc/printcap > load printers= no > invalid users= root > map to guest = Bad User > guest account= nobody > null passwords = no > > socket options = TCP_NODELAY > case sensitive = no > default case = lower > preserve case= yes > short preserve case = yes > dead time= 0 > debug level = 0 > getwd cache = yes > wide links = yes > log level= 1 > os level = 64 > preferred master = yes > domain master= yes > domain logons= no > local master = yes > time server = no > wins support = no > > [homes] > comment = Home Directory > read only = No > browseable = No > > [INFOTECH] > comment = IGS Tools & Utilities > path = /tmp_mnt/infotech > read only = No > __________ > OpenPKG http://openpkg.org > User Communication List openpkg-users@openpkg.org > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: Samba Security fixes
On Thu, 2007-05-17 at 14:45 +0200, Ralf S. Engelschall wrote: > On Wed, May 16, 2007, David M. Fetter wrote: > > > On Tue, 2007-05-15 at 21:22 +0200, Ralf S. Engelschall wrote: > > > On Tue, May 15, 2007, David M. Fetter wrote: > > > > > > > Are you guys aware of this: > > > > "http://isc.sans.org/diary.html?storyid=2804";? > > > > > > Thanks for the hint. > > > > Well, I was going to update this rpm and upload it to current but the > > patch fails when I try right off. :-( > > That's exactly the reason why I was not able to immediately upgrade the > package during my bi-daily upgrade round. But I'm already working on > this issue (first for OpenPKG Enterprise 1)... Yes...we quickly realized this must be the case. :-) The patch isn't commented very well or we would've looked into it further. It makes it kind of difficult to sort through without comments to say what the various patch bits are doing or are for. > >Ralf S. Engelschall >[EMAIL PROTECTED] >www.engelschall.com > > __ > OpenPKG http://openpkg.org > User Communication List openpkg-users@openpkg.org > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
cpio bug
It seems that there is a bug in the 2.7 version of cpio which one of my co-workers found. This is what he writes: Version 2.7 (the newest released) has the bug. It is fixed in cvs but no minor rev has been shipped. The patch I found is really small to fix the bug I encountered but there are a bunch of other changes in cvs since the 2.7 release and I don't know how important any of those are for us. The bug causes symlinks to point to incorrect locations on copyout. This is a serious issue for openpkg since rpms are cpio archives and everything we are building can be affected. http://www.mail-archive.com/[EMAIL PROTECTED]/index.html search for symlink on that page. You can see more info in debian bug #412799 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412799 http://savannah.gnu.org/bugs/index.php?18094 http://savannah.gnu.org/file/cvs-diff.log?file_id=11044 diff -p -u -r1.19 copyout.c --- src/copyout.c 27 Sep 2006 09:28:50 - 1.19 +++ src/copyout.c 24 Oct 2006 10:47:38 - @@ -806,6 +806,7 @@ process_copy_out () free (link_name); continue; } + link_name[link_size] = 0; cpio_safer_name_suffix (link_name, false, !no_abs_paths_flag, true); link_size = strlen (link_name); FYI. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: build file usage?
On Wed, 2007-05-16 at 21:13 +0200, Ralf S. Engelschall wrote: > On Tue, May 15, 2007, David M. Fetter wrote: > > > -Dperl-dbi::with_dbd_mysql = yes > > -Dperl-dbi::with_dbd_pgsql = yes > > -Dperl-dbi::with_dbd_sqlite = no > > Leave out the blanks: > > -Dperl-dbi::with_dbd_mysql=yes > -Dperl-dbi::with_dbd_pgsql=yes > -Dperl-dbi::with_dbd_sqlite=no Ugh! Evil spaces!!! Thanks again. > >Ralf S. Engelschall >[EMAIL PROTECTED] >www.engelschall.com > > __ > OpenPKG http://openpkg.org > User Communication List openpkg-users@openpkg.org > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: Samba Security fixes
On Tue, 2007-05-15 at 21:22 +0200, Ralf S. Engelschall wrote: > On Tue, May 15, 2007, David M. Fetter wrote: > > > Are you guys aware of this: > > "http://isc.sans.org/diary.html?storyid=2804";? > > Thanks for the hint. Well, I was going to update this rpm and upload it to current but the patch fails when I try right off. :-( I'm going to continue working on getting it to work though because we need to fix this asap. It won't take long for one of the many students to decide it's a good idea to attack one of these vulnerabilities. We have to patch this tonight. If you happen to get it updated please let me/us know. Otherwise, you might see an update from me soon, if I can get the issues figured out. Thanks. >Ralf S. Engelschall >[EMAIL PROTECTED] >www.engelschall.com > > __ > OpenPKG http://openpkg.org > User Communication List openpkg-users@openpkg.org > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: Man Page Formatting Failure
On Wed, 2007-05-16 at 21:21 +0200, Ralf S. Engelschall wrote: > On Tue, May 15, 2007, David M. Fetter wrote: > > > All of the man pages throughout all of our openpkg rpms all are filled > > with ESC characters, so it looks like the following excerpt: > > > > --- BEGIN CUT --- > > BUILD(1)OpenPKG > > BUILD(1) > > > > > > > > ESC[1mNAMEESC[0m > >ESC[1mopenpkg build ESC[22m??? ESC[1mOpenPKG ESC[22mMaintenance > > Tool > > > > ESC[1mSYNOPSISESC[0m > >ESC[1mopenpkg build ESC[22m[ESC[1m???R ESC[4mESC[22mrpmESC[24m] > > [ESC[1m???r > > ESC[4mESC[22mrepositoryESC[24m] [ESC[1m???f ESC[4mESC[22mindex.rdfESC[24m] > > [ESC[1m???uESC[22m] [ESC[1m???UESC[22m] [ESC[1m???zESC[22m] > >[ESC[1m???ZESC[22m] [ESC[1m???iESC[22m] [ESC[1m???qESC[22m] [ESC[1m > > ???sESC[22m] [ESC[1m???SESC[22m] [ESC[1m???MESC[22m] [ESC[1m???LESC[22m] > > [ESC[1m > > ???WESC[22m] [ESC[1m???XESC[22m] [ESC[1m???KESC[22m] [ESC[1m???eESC[22m] > > [ESC[1m > > ???bESC[22m] [ESC[1m???BESC[22m] [ESC[1m???GESC[22m] > >[ESC[1m???P ESC[4mESC[22mpriv???cmdESC[24m] [ESC[1m???N > > ESC[4mESC[22mnon???priv???cmdESC[24m] [ESC[1m???p > > ESC[4mESC[22mplatformESC[24m] [ESC[1m???D > > ESC[4mESC[22mvarESC[24m=ESC[4mvalESC[24m ...] [ESC[1m???EESC[0m > >ESC[4mnameESC[24m ...] [ESC[1m???H ESC[4mESC[22mnameESC[24m ...] > > ([ESC[1m???aESC[22m] [ESC[1m???AESC[22m] ??? ESC[4mpatternESC[24m ...) > > > > ESC[1mDESCRIPTIONESC[0m > >The ESC[1mopenpkg build ESC[22mtool provides automated recursive > > from???scr > > --- END CUT --- > > > > Can anyone help me fix this issue? This makes reading man pages a bit > > difficult. > > This is just the usual amount of escape fun pod2man+groff produce. > Usually you should not see this except if your PAGER doesn't support > this. Try for instance... > > $ export PAGER="less -E -r" > > ...and the problem should be gone as "openpkg man" uses the standard > $PAGER variable. Well, that does work, but it's not really a great fix for us. It pretty much assumes and/or forces everyone to use less as their PAGER but we most likely have some folks who want to use something different. We lack any real authority because we're told to please everyone which is definitely difficult if not impossible. Anyhow, thanks. > >Ralf S. Engelschall >[EMAIL PROTECTED] >www.engelschall.com > > __ > OpenPKG http://openpkg.org > User Communication List openpkg-users@openpkg.org > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: Man Page Formatting Failure
P.S. This is the same on RHEL4 and Solaris 10. It's also true on our older rollout on both RHEL3 and Solaris 9. Basically, it's something that broke a while ago which has been low priority for us to fix. Now it's on the radar again. On Tue, 2007-05-15 at 15:56 -0700, David M. Fetter wrote: > All of the man pages throughout all of our openpkg rpms all are filled > with ESC characters, so it looks like the following excerpt: > > --- BEGIN CUT --- > BUILD(1)OpenPKG > BUILD(1) > > > > ESC[1mNAMEESC[0m >ESC[1mopenpkg build ESC[22m− ESC[1mOpenPKG ESC[22mMaintenance > Tool > > ESC[1mSYNOPSISESC[0m >ESC[1mopenpkg build ESC[22m[ESC[1m−R ESC[4mESC[22mrpmESC[24m] > [ESC[1m−r > ESC[4mESC[22mrepositoryESC[24m] [ESC[1m−f ESC[4mESC[22mindex.rdfESC[24m] > [ESC[1m−uESC[22m] [ESC[1m−UESC[22m] [ESC[1m−zESC[22m] >[ESC[1m−ZESC[22m] [ESC[1m−iESC[22m] [ESC[1m−qESC[22m] [ESC[1m > −sESC[22m] [ESC[1m−SESC[22m] [ESC[1m−MESC[22m] [ESC[1m−LESC[22m] [ESC[1m > −WESC[22m] [ESC[1m−XESC[22m] [ESC[1m−KESC[22m] [ESC[1m−eESC[22m] [ESC[1m > −bESC[22m] [ESC[1m−BESC[22m] [ESC[1m−GESC[22m] >[ESC[1m−P ESC[4mESC[22mpriv‐cmdESC[24m] [ESC[1m−N > ESC[4mESC[22mnon‐priv‐cmdESC[24m] [ESC[1m−p > ESC[4mESC[22mplatformESC[24m] [ESC[1m−D > ESC[4mESC[22mvarESC[24m=ESC[4mvalESC[24m ...] [ESC[1m−EESC[0m >ESC[4mnameESC[24m ...] [ESC[1m−H ESC[4mESC[22mnameESC[24m ...] > ([ESC[1m−aESC[22m] [ESC[1m−AESC[22m] ⎪ ESC[4mpatternESC[24m ...) > > ESC[1mDESCRIPTIONESC[0m >The ESC[1mopenpkg build ESC[22mtool provides automated recursive > from‐scr > --- END CUT --- > > Can anyone help me fix this issue? This makes reading man pages a bit > difficult. > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Man Page Formatting Failure
All of the man pages throughout all of our openpkg rpms all are filled with ESC characters, so it looks like the following excerpt: --- BEGIN CUT --- BUILD(1)OpenPKG BUILD(1) ESC[1mNAMEESC[0m ESC[1mopenpkg build ESC[22m− ESC[1mOpenPKG ESC[22mMaintenance Tool ESC[1mSYNOPSISESC[0m ESC[1mopenpkg build ESC[22m[ESC[1m−R ESC[4mESC[22mrpmESC[24m] [ESC[1m−r ESC[4mESC[22mrepositoryESC[24m] [ESC[1m−f ESC[4mESC[22mindex.rdfESC[24m] [ESC[1m−uESC[22m] [ESC[1m−UESC[22m] [ESC[1m−zESC[22m] [ESC[1m−ZESC[22m] [ESC[1m−iESC[22m] [ESC[1m−qESC[22m] [ESC[1m −sESC[22m] [ESC[1m−SESC[22m] [ESC[1m−MESC[22m] [ESC[1m−LESC[22m] [ESC[1m −WESC[22m] [ESC[1m−XESC[22m] [ESC[1m−KESC[22m] [ESC[1m−eESC[22m] [ESC[1m −bESC[22m] [ESC[1m−BESC[22m] [ESC[1m−GESC[22m] [ESC[1m−P ESC[4mESC[22mpriv‐cmdESC[24m] [ESC[1m−N ESC[4mESC[22mnon‐priv‐cmdESC[24m] [ESC[1m−p ESC[4mESC[22mplatformESC[24m] [ESC[1m−D ESC[4mESC[22mvarESC[24m=ESC[4mvalESC[24m ...] [ESC[1m−EESC[0m ESC[4mnameESC[24m ...] [ESC[1m−H ESC[4mESC[22mnameESC[24m ...] ([ESC[1m−aESC[22m] [ESC[1m−AESC[22m] ⎪ ESC[4mpatternESC[24m ...) ESC[1mDESCRIPTIONESC[0m The ESC[1mopenpkg build ESC[22mtool provides automated recursive from‐scr --- END CUT --- Can anyone help me fix this issue? This makes reading man pages a bit difficult. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: build file usage?
Here is the specific problem, I'm having because the build file isn't seemingly being utilized. Basically, perl-dbi is failing to build and giving this error: openpkg:build:FATAL: errors occured while building: perl-dbi-5.8.8-2.20061018: perl-dbi searches a frood called 'sqlite' I'm using this command to generate the rebuild script after which it is executed giving the aforementioned error: openpkg build -r /usr/local/RPM/OPKG/TMP/2-STABLE-20061018/SRC -f /usr/local/RPM/OPKG/TMP/2-STABLE-20061018/SRC/updates_index.rdf -A -U The build file that resides at /usr/local/.openpkg/build (the generic opkg user account) contains the following lines which pertain to perl-dbi options: -Dperl-dbi::with_dbd_mysql = yes -Dperl-dbi::with_dbd_pgsql = yes -Dperl-dbi::with_dbd_sqlite = no Note here that I am disabling sqlite because we do not want it installed on our systems, so we don't build it. Thus, if perl-dbi were to build with default options, it would require sqlite which is what it is doing and why it looks like the build file is not being recognized/used. Also, perl-dbi is not the only package that is not building with the options we specified within the build file. This is actually a fairly serious issue for us because we change a lot of the default options in packages when we do our rebuild. Also, just to rule it out, I linked ~root/.openpkg to /usr/local/.openpkg and I even copied the same build file into my own ~/.openpkg and tried letting it build with each of these changes with no difference in outcome. :-( Anybody have any ideas why suddenly the build options in the build file would just stop being recognized? On Mon, 2007-05-14 at 14:34 -0700, David M. Fetter wrote: > Well, we run the openpkg build command on our build servers as the opkg > user account and I have the build file (which contains rpm build options > only) located under /usr/local/.openpkg/build which would be the opkg > user's home directory. Should this setup recognize the build file or do > I need to also have it reside in root's home directory? I would expect > the way I set it up to work but it's not because openpkg build is > generating a build script that does not have the options I specified in > the build file. > > On Sun, 2007-05-13 at 04:03 +0200, Torsten Homeyer wrote: > > Ralf S. Engelschall wrote: > > > On Fri, May 11, 2007, David M. Fetter wrote: > > > > > >> Is the ~/.openpkg/build file still being acknowledged by openpkg-tools? > > >> It seems that it is no longer being adhered too when doing the build to > > >> create the build script. I just want to make sure this method wasn't > > >> obsoleted somewhere along the lines. > > > > > > "openpkg build" honors it and it works just fine for me. Here is an > > > example ~rse/.openpkg/build from one of my private boxes: > > > > > > > > > [/usr/opkg] > > > -r /v/openpkg/SRC/CURRENT > > > -P sudo > > > -N sudo > > > -E j2se > > > > > > [/v/p2p/sw] > > > -r /v/openpkg/SRC/CURRENT > > > -P sudo > > > -N sudo > > > > It's behavior chnaged some time ago due to the fact that certain actions > > within the openpkg command run under the different user IDs of the > > OpenPKG hirarchy. Linking my ~/.openpkg/build file to all the > > /PREFIX/.openpkg directories did the trick for me. > > > > Regards, > > Torsten > > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Samba Security fixes
Are you guys aware of this: "http://isc.sans.org/diary.html?storyid=2804";? -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: build file usage?
Well, we run the openpkg build command on our build servers as the opkg user account and I have the build file (which contains rpm build options only) located under /usr/local/.openpkg/build which would be the opkg user's home directory. Should this setup recognize the build file or do I need to also have it reside in root's home directory? I would expect the way I set it up to work but it's not because openpkg build is generating a build script that does not have the options I specified in the build file. On Sun, 2007-05-13 at 04:03 +0200, Torsten Homeyer wrote: > Ralf S. Engelschall wrote: > > On Fri, May 11, 2007, David M. Fetter wrote: > > > >> Is the ~/.openpkg/build file still being acknowledged by openpkg-tools? > >> It seems that it is no longer being adhered too when doing the build to > >> create the build script. I just want to make sure this method wasn't > >> obsoleted somewhere along the lines. > > > > "openpkg build" honors it and it works just fine for me. Here is an > > example ~rse/.openpkg/build from one of my private boxes: > > > > > > [/usr/opkg] > > -r /v/openpkg/SRC/CURRENT > > -P sudo > > -N sudo > > -E j2se > > > > [/v/p2p/sw] > > -r /v/openpkg/SRC/CURRENT > > -P sudo > > -N sudo > > It's behavior chnaged some time ago due to the fact that certain actions > within the openpkg command run under the different user IDs of the > OpenPKG hirarchy. Linking my ~/.openpkg/build file to all the > /PREFIX/.openpkg directories did the trick for me. > > Regards, > Torsten > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
build file usage?
Is the ~/.openpkg/build file still being acknowledged by openpkg-tools? It seems that it is no longer being adhered too when doing the build to create the build script. I just want to make sure this method wasn't obsoleted somewhere along the lines. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: Man Pages
I don't mean for all packages. I just mean the openpkg specific packages. The software/tools that have been developed in-house for use in the openpkg world. That should only be 4 or 5 man pages total. It would be a nice addition to list under the "Documentation" area. On Tue, 2007-05-08 at 19:51 +0200, Ralf S. Engelschall wrote: > On Tue, May 08, 2007, David M. Fetter wrote: > > > Are the man pages for the specific openpkg software online somewhere on > > the web site? It would be nice if they were. When we build our > > software currently the man pages all fail to properly build for some > > reason. It's a low priority for us to resolve but it would be nice if > > the man pages for openpkg, openpkg-tools and the other packages that are > > specific to openpkg were online. I can't seem to find them on the site > > if they are. > > We currently don't have the manpages online. > > In case someone wants to investigate on this: In order to display all > manpages of all packages, we would either need an OpenPKG instance with > all packages installed (which is not possible anyway) or at least have > all packages staying around in unpacked format (which we currently do > not have, too). Additionally one needs a man to html formatter and a > small wrapper CGI. I think there is rman which we use at FreeBSD.org... > >Ralf S. Engelschall >[EMAIL PROTECTED] >www.engelschall.com > > __ > OpenPKG http://openpkg.org > User Communication List openpkg-users@openpkg.org > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Man Pages
Are the man pages for the specific openpkg software online somewhere on the web site? It would be nice if they were. When we build our software currently the man pages all fail to properly build for some reason. It's a low priority for us to resolve but it would be nice if the man pages for openpkg, openpkg-tools and the other packages that are specific to openpkg were online. I can't seem to find them on the site if they are. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: Old Versions
I have to agree. I was going to grab the 2-Stable from Feb but I found that it was gone. :-( Oh well. We're adapting the best we can. On Sun, 2007-04-29 at 11:19 -0700, Doug Summers wrote: > Now that OpenPKG-STABLE has been removed and only OpenPKG-CURRENT is > available how can we access older versions when the new ones won't work? > I'm stuck with openssh & perl-util not working on RHEL4-AMD64 and I have > no way to go back. > __ > OpenPKG http://openpkg.org > User Communication List openpkg-users@openpkg.org > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: gnupg conflicts with libtasn1 in 2-stable-20061018
Ouch. We just barely started rolling out new servers with 2-Stable-20061018. H. This doesn't bode well for us. On Mon, 2007-04-16 at 21:07 +0200, Ralf S. Engelschall wrote: > On Mon, Apr 16, 2007, David M. Fetter wrote: > > > I get this message if I try to install both gnupg and libtasn1: > > > > file /usr/local/share/info/dir from install of libtasn1-0.3.6-2.20061018 > > conflicts with file from package gnupg-1.4.6-2.20061207 > > > > The libtasn1 package is needed for gnutls. Can this be fixed and > > updated please? Also, how much longer do we have before > > 2-Stable-20061018 is not supported in this fashion (if any)? > > Well, 2-STABLE-20061018 actually already went end of live with the > February 2007 snapshot. But just take gnupg-1.4.7-2.20070319 and > libtasn1-0.3.9-2.20070319 from 2-STABLE. There I already don't see this > problem any longer. But especially because of those support pains with > 2-STABLE we've already prepared a replacement offering based on the > E1.0-SOLID branch. Expect an announcement soon. > >Ralf S. Engelschall >[EMAIL PROTECTED] >www.engelschall.com > > __ > OpenPKG http://openpkg.org > User Communication List openpkg-users@openpkg.org > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
gnupg conflicts with libtasn1 in 2-stable-20061018
I get this message if I try to install both gnupg and libtasn1: file /usr/local/share/info/dir from install of libtasn1-0.3.6-2.20061018 conflicts with file from package gnupg-1.4.6-2.20061207 The libtasn1 package is needed for gnutls. Can this be fixed and updated please? Also, how much longer do we have before 2-Stable-20061018 is not supported in this fashion (if any)? -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: coreutils doesn't make link for uname
Ah, ok. That makes sense. On Wed, 2007-04-04 at 14:37 -0700, Bill Campbell wrote: > On Wed, Apr 04, 2007, David M. Fetter wrote: > >We have set 'coreutils::with_legacy = yes', however, it isn't making a > >symlink from uname to guname like the others. Can this be fixed and put > >into the 2.20061018 as an update please? > > This is intentional. Having an OpenPKG version called uname (and > hostname) breaks too many things as many configure files depend > on the underlying system's uname and hostname commands. > > Bill > -- > INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC > URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way > FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 > > Progress (n.): The process through which Usenet has evolved from >smart people in front of dumb terminals to dumb people in front of >smart terminals. -- [EMAIL PROTECTED] (obscurity) > __ > OpenPKG http://openpkg.org > User Communication List openpkg-users@openpkg.org > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: SMF on Solaris 10
This is what we're using. (see attachment)
On Tue, 2007-04-03 at 08:04 +0200, Enrico John wrote:
> Hi
>
> We need help with openpkg on solaris 10.
>
> When we shutdown the system, openpkg takes a long time to stop.
> Sometimes we get the message that openpkg changed to state maintenance.
>
> "/opt/local/opkg/etc/rc all stop" works well.
>
> [EMAIL PROTECTED]:/home/zue/users/joe$ uname -a
> SunOS zuetam02 5.10 Generic_118833-36 sun4u sparc SUNW,A70
>
> [EMAIL PROTECTED]:/home/zue/users/joe$ openpkg rpm -qa openpkg
> openpkg-2.5.4-2.5.4
>
> [EMAIL PROTECTED]:/home/zue/users/joe$
> [EMAIL PROTECTED]:/root# /bin/svcs -d openpkg/optlocalopkg
> STATE STIMEFMRI
> online 7:50:51 svc:/milestone/name-services:default
> online 7:50:59 svc:/milestone/network:default
> online 7:51:00 svc:/system/filesystem/local:default
> online 7:51:21 svc:/milestone/multi-user-server:default
>
> [EMAIL PROTECTED]:/home/zue/users/joe$ svcs -v openpkg/optlocalopkg
> STATE NSTATESTIMECTID FMRI
> online - 7:51:27 79
> svc:/openpkg/optlocalopkg:default
> [EMAIL PROTECTED]:/home/zue/users/joe$
>
>
>
> [EMAIL PROTECTED]:/home/zue/users/joe$ tail -20
> /var/svc/log/openpkg-optlocalopkg:default.log
> [ Apr 2 18:04:50 Method "stop" exited with status 0 ]
> [ Apr 2 18:07:25 Executing start method ("/opt/local/opkg/etc/rc all
> start") ]
> [ Apr 2 18:07:32 Method "start" exited with status 0 ]
> [ Apr 2 18:21:58 Stopping because service disabled. ]
> [ Apr 2 18:21:58 Executing stop method ("/opt/local/opkg/etc/rc all
> stop") ]
> [ Apr 2 18:22:03 Method "stop" exited with status 0 ]
> [ Apr 3 07:23:47 Executing start method ("/opt/local/opkg/etc/rc all
> start") ]
> [ Apr 3 07:23:52 Method "start" exited with status 0 ]
> [ Apr 3 07:39:32 Stopping because service disabled. ]
> [ Apr 3 07:39:32 Executing stop method ("/opt/local/opkg/etc/rc all
> stop") ]
> [ Apr 3 07:39:36 Method "stop" exited with status 0 ]
> [ Apr 3 07:42:33 Method or service exit timed out. Killing contract 78 ]
> [ Apr 3 07:44:51 Executing start method ("/opt/local/opkg/etc/rc all
> start") ]
> [ Apr 3 07:44:56 Method "start" exited with status 0 ]
> [ Apr 3 07:45:57 Stopping because service disabled. ]
> [ Apr 3 07:45:58 Executing stop method ("/opt/local/opkg/etc/rc all
> stop") ]
> [ Apr 3 07:46:02 Method "stop" exited with status 0 ]
> [ Apr 3 07:48:59 Method or service exit timed out. Killing contract 76 ]
> [ Apr 3 07:51:21 Executing start method ("/opt/local/opkg/etc/rc all
> start") ]
> [ Apr 3 07:51:27 Method "start" exited with status 0 ]
> [EMAIL PROTECTED]:/home/zue/users/joe$
>
> thank you for your help.
>
> regards,
> enrico
>
> We use openpkg successfully since four years now. All internal developed
> software is packaged and deployed with openpkg. www.meteoswiss.ch
> __
> OpenPKG http://openpkg.org
> User Communication List openpkg-users@openpkg.org
>
--
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
openpkg-startall.xml
Description: application/xml
signature.asc
Description: This is a digitally signed message part
coreutils doesn't make link for uname
We have set 'coreutils::with_legacy = yes', however, it isn't making a symlink from uname to guname like the others. Can this be fixed and put into the 2.20061018 as an update please? -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: [2.20061018 stable] gcc with_fortran fails to build
On Wed, 2007-03-21 at 13:40 -0700, Bill Campbell wrote:
> On Wed, Mar 21, 2007, David M. Fetter wrote:
> >On Wed, 2007-03-21 at 13:25 -0700, Bill Campbell wrote:
> >> On Wed, Mar 21, 2007, David M. Fetter wrote:
> >> >It seems that for some reason gcc is not acknowledging
> >> >our /usr/local/include directory in it's includes when building. In
> >> >fact, there is this specific bit in the spec file:
> >> >
> >> >%{l_shtool} subst -v -s \
> >> >-e 's;PREFIX_INCLUDE_DIR;PREFIX_INCLUDE_DIR_DISABLED;g' \
> >> >gcc/configure
> >> >
> >> >We happen to use /usr/local as our openpkg prefix since this is an
> >> >unused location for us across all of our systems and it is a common
> >> >place where software like this is typically found so it makes it easy
> >> >for the end users to find. In any case, we're still looking into this
> >> >but it seems that by removing this bit from the spec file, it causes
> >> >another series of dilemmas. One such dilemma is that multilib is being
> >> >enabled on RHEL4 64-bit when apparently that's not a good thing on that
> >> >particular platform. Any help with this would be great. Thanks. :-)
> >>
> >> A symlink from a ``normal'' OpenPKG instance to /usr/local?
> >>
> >> I often make symlinks such as %{l_prefix}/bin/perl to /usr/local/bin/perl
> >> to deal with software that may have this hard coded.
> >
> >That's not really a viable option for us now. We have been
> >using /usr/local as the prefix for openpkg since it has been setup here.
> >However, even so, should there really be prefix locations that are
> >essentially "off limits" for openpkg installations? It seems like the
> >option to set the prefix to /usr/local is there so it should be a usable
> >option. I'm thinking the problem should be fixed within gcc.
>
> I would avoid /usr/local as a prefix, particularly since FreeBSD systems
> use that extensively for anything not in the core distribution (as $DEITY
> intended :-). We also have several ISP customers who, after long training
> and browbeating, have learned to put their site-specific scripts under
> /usr/local, not in /usr/bin or simlar travesties.
I totally understand. However, environments can be and typically are
very different from one another. We don't use FreeBSD, we only use
Solaris and RHEL. We don't have people putting things in /usr/local
either. In fact, since we have now been using /usr/local for our core
software for the past couple years now, our end-users have become
accustomed to that location as to where they can find what they need.
We have also wrapped cfengine around openpkg in a very intricate manner.
Changing the /usr/local prefix for us would mean a major project for
restructuring our environment. In the end, it seems that only gcc
itself is having some oddity and that if said oddity is fixed then it no
longer becomes an issue. Ultimately, we just want to get gcc fixed and
working how we need without having to restructure our entire
environment. ;-)
>
> Bill
> --
> INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC
> URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
> FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
>
> ``It is better to die on your feet than to live on your knees!''
> -- Emiliano Zapata.
> __
> OpenPKG http://openpkg.org
> User Communication List openpkg-users@openpkg.org
>
--
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
signature.asc
Description: This is a digitally signed message part
Re: [2.20061018 stable] gcc with_fortran fails to build
On Wed, 2007-03-21 at 13:25 -0700, Bill Campbell wrote:
> On Wed, Mar 21, 2007, David M. Fetter wrote:
> >It seems that for some reason gcc is not acknowledging
> >our /usr/local/include directory in it's includes when building. In
> >fact, there is this specific bit in the spec file:
> >
> >%{l_shtool} subst -v -s \
> >-e 's;PREFIX_INCLUDE_DIR;PREFIX_INCLUDE_DIR_DISABLED;g' \
> >gcc/configure
> >
> >We happen to use /usr/local as our openpkg prefix since this is an
> >unused location for us across all of our systems and it is a common
> >place where software like this is typically found so it makes it easy
> >for the end users to find. In any case, we're still looking into this
> >but it seems that by removing this bit from the spec file, it causes
> >another series of dilemmas. One such dilemma is that multilib is being
> >enabled on RHEL4 64-bit when apparently that's not a good thing on that
> >particular platform. Any help with this would be great. Thanks. :-)
>
> A symlink from a ``normal'' OpenPKG instance to /usr/local?
>
> I often make symlinks such as %{l_prefix}/bin/perl to /usr/local/bin/perl
> to deal with software that may have this hard coded.
That's not really a viable option for us now. We have been
using /usr/local as the prefix for openpkg since it has been setup here.
However, even so, should there really be prefix locations that are
essentially "off limits" for openpkg installations? It seems like the
option to set the prefix to /usr/local is there so it should be a usable
option. I'm thinking the problem should be fixed within gcc.
>
> Bill
> --
> INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC
> URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
> FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
>
> The difference between science and the fuzzy subjects is that science
> requires reasoning while those other subjects merely require scholarship.
> -- Robert Heinlein
> __________
> OpenPKG http://openpkg.org
> User Communication List openpkg-users@openpkg.org
>
--
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
signature.asc
Description: This is a digitally signed message part
Re: [2.20061018 stable] gcc with_fortran fails to build
It seems that for some reason gcc is not acknowledging
our /usr/local/include directory in it's includes when building. In
fact, there is this specific bit in the spec file:
%{l_shtool} subst -v -s \
-e 's;PREFIX_INCLUDE_DIR;PREFIX_INCLUDE_DIR_DISABLED;g' \
gcc/configure
We happen to use /usr/local as our openpkg prefix since this is an
unused location for us across all of our systems and it is a common
place where software like this is typically found so it makes it easy
for the end users to find. In any case, we're still looking into this
but it seems that by removing this bit from the spec file, it causes
another series of dilemmas. One such dilemma is that multilib is being
enabled on RHEL4 64-bit when apparently that's not a good thing on that
particular platform. Any help with this would be great. Thanks. :-)
On Wed, 2007-02-21 at 10:19 -0800, David M. Fetter wrote:
> Ya, we did just that already. We need gcc to exist in general, but a
> specific group of folks want gcc with_fortran, so we need to have that
> as well. Believe me, I wouldn't be spending time on it if somebody
> didn't specifically request it. ;-)
>
> On Wed, 2007-02-21 at 11:51 -0500, Doug Henry wrote:
> > gcc with fortran from current (4.1.2) builds for me under
> > debian/ubuntu. If you haven't already, I would build gcc without
> > fortran, and then rebuild it with fortran so it builds using the same
> > version of openpkg gcc and not the system compiler. I have seen cases
> > with several packages where the build works with the openpkg gcc and
> > not the system gcc. If you are already doing this, it would have to
> > be some sort of system header weirdness.
> >
> > -good luck
> >
> > On 2/20/07, David M. Fetter <[EMAIL PROTECTED]> wrote:
> > Thanks. I'll try that out.
> >
> > On Tue, 2007-02-20 at 16:18 -0800, Bill Campbell wrote:
> > > On Tue, Feb 20, 2007, David M. Fetter wrote:
> > > >Ya, I did that already. It has the same failure.
> > >
> > > It looks like some structure is missing members.
> > >
> > > Look at line 2440 in this file to see what structure is
> > referenced with the
> > > term gfc_expr:
> > >
> > > /usr/local/RPM/USER/TMP/gcc-4.1.1/obj/../gcc/fortran/arith.c
> > >
> > > Then try to figure out which header file contains the
> > structure and whether
> > > you can see gfc_expr anyplace.
> > >
> > > I frequently use the attached perl script to create a
> > pre-processed tmp.c
> > > file so I can see exactly what's going on. Capture the
> > output of the build
> > > so you have the compile line that failed, then replace the
> > first ``gcc'' or
> > > ``cc'' part with this script redirecting the output to a
> > file for analysis
> > > (watch out for -o options as the preprocessed output will
> > end up there if
> > > it's present).
> > >
> > > The line with do.*csspath can be removed, and the spitshell
> > stuff at the
> > > top fixed to fit your system.
> > >
> > > ...
> > >
> > > Bill
> > > --
> > > INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial
> > Software LLC
> > > URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer
> > Way
> > > FAX:(206) 232-9186 Mercer Island, WA
> > 98040-0820; (206) 236-1676
> > >
> > > ``One of the common failings among honorable people is a
> > failure to
> > > appreciate how thoroughly dishonorable some other people can
> > be, and how
> > > dangerous it is to trust them.''
> > > - Thomas Sowell
> > --
> > David M. Fetter - Portland State University - UNIX Systems
> > Administrator
> > "Reality is merely an illusion, albeit a very persistent one."
> > ~Einstein
> >
> >
--
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
signature.asc
Description: This is a digitally signed message part
Re: a2ps fails to build on RHEL4 64-bit
On Wed, 2007-03-21 at 20:18 +0100, Ralf S. Engelschall wrote: > On Wed, Mar 21, 2007, David M. Fetter wrote: > > > It seems that we have found yet another package that has issues on RHEL4 > > 64-bit. Has anybody run into this and might know how this could be > > fixed? Just curious before we start wasting time on looking into it > > ourselves. :-) Anything to save time, you know. > > > > /usr/local/bin/cc -fPIC -o a2ps main.o read.o sshread.o ssheet.o > > select.o generate.o delegate.o regex.o buffer.o versions.o ffaces.o > > version-etc.o long-options.o parsessh.o lexssh.o lexps.o > > sheets-map.o ../lib/.libs/liba2ps.a -lfl -lm > > main.o: In function `spy_user': > > main.c:(.text+0xda4): warning: the use of `tempnam' is dangerous, better > > use `mkstemp' > > ssheet.o: In function `free_rule': > > ssheet.c:(.text+0x619): undefined reference to `faced_string_free' > > ../lib/.libs/liba2ps.a(encoding.o): In function `font_table_free': > > encoding.c:(.text+0x4a6): undefined reference to `font_entry_free' > > collect2: ld returned 1 exit status > > make[2]: *** [a2ps] Error 1 > > make[1]: *** [all-recursive] Error 1 > > make: *** [all-recursive-am] Error 2 > > Give CURRENT's a2ps-4.13b-20070321 a try. > I've tried to circumvent the problem... Sweet! That fixed it. Can this be MFC'ed into the 2.20061018 release please? > >Ralf S. Engelschall >[EMAIL PROTECTED] >www.engelschall.com > > __________ > OpenPKG http://openpkg.org > User Communication List openpkg-users@openpkg.org > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: Emacs on AMD64
It seems that this is still a problem, at least it is for us on RHEL4 64-bit. We have partially looked into this and found that it might be able to be fixed with the newer release or maybe by doing some hacking with shtool or whatnot to add in the new architectures to it's detection. I would think that just MFC'ing the newer version into the 2-Stable would be easiest though. Could this be done? On Tue, 2006-07-18 at 13:33 -0700, Doug Summers wrote: > Bill Campbell wrote: > > On Tue, Jul 18, 2006, Ralf S. Engelschall wrote: > >> On Tue, Jul 18, 2006, Doug Summers wrote: > >> > >>> I can't build emacs from any version available. It keeps complaining > >>> about the host type not being supported. I noticed that the code is > >>> fairly old - is there a newer version available? > >> Which particular Emacs version on which AMD64-based OS have you tried? > > > > I just tried this on SuSE Linux Enterprise 9 with an Athlon 64, > > building emacs-21.4a-2.5.0.src.rpm. > > > > The problem appears that the configure script at line 1643 recognizes > > amd64*-*-*, and at line 1635 recognizes ia64*-*-* while the host system > > type comes up with x86_64-unknown-linux-gnu. > > > > It appears that some hacking is necessary on the configure file > > to get the right combination. > > > > I'm up to my a$$ in alligators now so don't have time to hack on > > this (and I'm a vi bigot not emacs :-). > > > > Bill > > -- > > INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC > > URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way > > FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 > > > > The Constitution is a written instrument. As such, its meaning > > does not alter. That which it meant when it was adopted, it > > means now. > > -- SOUTH CAROLINA v. US, 199 U.S. 437, 448 (1905) > > __ > > The OpenPKG Projectwww.openpkg.org > > User Communication List openpkg-users@openpkg.org > > Supposedly the more recent CVS versions of Emacs fix this problem, but I > haven't tested it yet. > > Ralph - I'll give this a try later on tonight and let you know if it > works and what version. > > Doug > __ > The OpenPKG Projectwww.openpkg.org > User Communication List openpkg-users@openpkg.org > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
a2ps fails to build on RHEL4 64-bit
It seems that we have found yet another package that has issues on RHEL4 64-bit. Has anybody run into this and might know how this could be fixed? Just curious before we start wasting time on looking into it ourselves. :-) Anything to save time, you know. /usr/local/bin/cc -fPIC -o a2ps main.o read.o sshread.o ssheet.o select.o generate.o delegate.o regex.o buffer.o versions.o ffaces.o version-etc.o long-options.o parsessh.o lexssh.o lexps.o sheets-map.o ../lib/.libs/liba2ps.a -lfl -lm main.o: In function `spy_user': main.c:(.text+0xda4): warning: the use of `tempnam' is dangerous, better use `mkstemp' ssheet.o: In function `free_rule': ssheet.c:(.text+0x619): undefined reference to `faced_string_free' ../lib/.libs/liba2ps.a(encoding.o): In function `font_table_free': encoding.c:(.text+0x4a6): undefined reference to `font_entry_free' collect2: ld returned 1 exit status make[2]: *** [a2ps] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive-am] Error 2 -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: [2.20061018 stable] gcc with_fortran fails to build
Ya, we did just that already. We need gcc to exist in general, but a specific group of folks want gcc with_fortran, so we need to have that as well. Believe me, I wouldn't be spending time on it if somebody didn't specifically request it. ;-) On Wed, 2007-02-21 at 11:51 -0500, Doug Henry wrote: > gcc with fortran from current (4.1.2) builds for me under > debian/ubuntu. If you haven't already, I would build gcc without > fortran, and then rebuild it with fortran so it builds using the same > version of openpkg gcc and not the system compiler. I have seen cases > with several packages where the build works with the openpkg gcc and > not the system gcc. If you are already doing this, it would have to > be some sort of system header weirdness. > > -good luck > > On 2/20/07, David M. Fetter <[EMAIL PROTECTED]> wrote: > Thanks. I'll try that out. > > On Tue, 2007-02-20 at 16:18 -0800, Bill Campbell wrote: > > On Tue, Feb 20, 2007, David M. Fetter wrote: > > >Ya, I did that already. It has the same failure. > > > > It looks like some structure is missing members. > > > > Look at line 2440 in this file to see what structure is > referenced with the > > term gfc_expr: > > > > /usr/local/RPM/USER/TMP/gcc-4.1.1/obj/../gcc/fortran/arith.c > > > > Then try to figure out which header file contains the > structure and whether > > you can see gfc_expr anyplace. > > > > I frequently use the attached perl script to create a > pre-processed tmp.c > > file so I can see exactly what's going on. Capture the > output of the build > > so you have the compile line that failed, then replace the > first ``gcc'' or > > ``cc'' part with this script redirecting the output to a > file for analysis > > (watch out for -o options as the preprocessed output will > end up there if > > it's present). > > > > The line with do.*csspath can be removed, and the spitshell > stuff at the > > top fixed to fit your system. > > > > ... > > > > Bill > > -- > > INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial > Software LLC > > URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer > Way > > FAX:(206) 232-9186 Mercer Island, WA > 98040-0820; (206) 236-1676 > > > > ``One of the common failings among honorable people is a > failure to > > appreciate how thoroughly dishonorable some other people can > be, and how > > dangerous it is to trust them.'' > > - Thomas Sowell > -- > David M. Fetter - Portland State University - UNIX Systems > Administrator > "Reality is merely an illusion, albeit a very persistent one." > ~Einstein > > -- David M. Fetter - Portland State University - UNIX Systems Administrator "Reality is merely an illusion, albeit a very persistent one." ~Einstein signature.asc Description: This is a digitally signed message part
Re: [2.20061018 stable] gcc with_fortran fails to build
Thanks. I'll try that out. On Tue, 2007-02-20 at 16:18 -0800, Bill Campbell wrote: > On Tue, Feb 20, 2007, David M. Fetter wrote: > >Ya, I did that already. It has the same failure. > > It looks like some structure is missing members. > > Look at line 2440 in this file to see what structure is referenced with the > term gfc_expr: > > /usr/local/RPM/USER/TMP/gcc-4.1.1/obj/../gcc/fortran/arith.c > > Then try to figure out which header file contains the structure and whether > you can see gfc_expr anyplace. > > I frequently use the attached perl script to create a pre-processed tmp.c > file so I can see exactly what's going on. Capture the output of the build > so you have the compile line that failed, then replace the first ``gcc'' or > ``cc'' part with this script redirecting the output to a file for analysis > (watch out for -o options as the preprocessed output will end up there if > it's present). > > The line with do.*csspath can be removed, and the spitshell stuff at the > top fixed to fit your system. > > ... > > Bill > -- > INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC > URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way > FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 > > ``One of the common failings among honorable people is a failure to > appreciate how thoroughly dishonorable some other people can be, and how > dangerous it is to trust them.'' > - Thomas Sowell -- David M. Fetter - Portland State University - UNIX Systems Administrator "Reality is merely an illusion, albeit a very persistent one." ~Einstein signature.asc Description: This is a digitally signed message part
Re: [2.20061018 stable] gcc with_fortran fails to build
Ya, I did that already. It has the same failure. On Tue, 2007-02-20 at 22:27 +0100, Ralf S. Engelschall wrote: > On Tue, Feb 20, 2007, David M. Fetter wrote: > > > In the 2.20061018 stable release gcc fails to build on RHEL4 (either > > 32-bit or 64-bit arch) when enabling the with_fortran option. It builds > > fine on Solaris 10 sparc, however. The errors I'm getting are below. > > > > /usr/local/RPM/USER/TMP/gcc-4.1.1/obj/../gcc/fortran/arith.c:2440: > > error: 'gfc_expr' has no member named 'where' > > /usr/local/RPM/USER/TMP/gcc-4.1.1/obj/../gcc/fortran/arith.c:2442: > > error: 'gfc_expr' has no member named 'value' > > /usr/local/RPM/USER/TMP/gcc-4.1.1/obj/../gcc/fortran/arith.c:2453: > > error: 'gfc_expr' has no member named 'value' > > make[2]: *** [fortran/arith.o] Error 1 > > make[1]: *** [stage2_build] Error 2 > > make: *** [bootstrap-lean] Error 2 > > > > Any ideas why this is failing? Can it be fixed as an update to > > 2.20061018? > > I've no clue, but give the GCC 4.1.2 a try we have in CURRENT. > Perhaps it has this problem solved... > >Ralf S. Engelschall >[EMAIL PROTECTED] >www.engelschall.com > > __________ > OpenPKG http://openpkg.org > User Communication List openpkg-users@openpkg.org > -- David M. Fetter - Portland State University - UNIX Systems Administrator "Reality is merely an illusion, albeit a very persistent one." ~Einstein signature.asc Description: This is a digitally signed message part
[2.20061018 stable] gcc with_fortran fails to build
In the 2.20061018 stable release gcc fails to build on RHEL4 (either 32-bit or 64-bit arch) when enabling the with_fortran option. It builds fine on Solaris 10 sparc, however. The errors I'm getting are below. /usr/local/RPM/USER/TMP/gcc-4.1.1/obj/../gcc/fortran/arith.c:2440: error: 'gfc_expr' has no member named 'where' /usr/local/RPM/USER/TMP/gcc-4.1.1/obj/../gcc/fortran/arith.c:2442: error: 'gfc_expr' has no member named 'value' /usr/local/RPM/USER/TMP/gcc-4.1.1/obj/../gcc/fortran/arith.c:2453: error: 'gfc_expr' has no member named 'value' make[2]: *** [fortran/arith.o] Error 1 make[1]: *** [stage2_build] Error 2 make: *** [bootstrap-lean] Error 2 Any ideas why this is failing? Can it be fixed as an update to 2.20061018? -- David M. Fetter - Portland State University - UNIX Systems Administrator "Only those who attempt the absurd can achieve the impossible." signature.asc Description: This is a digitally signed message part
Re: Off-Topic, Yet inadvertently related.
P.S. http://shelleytherepublican.com/meaning-and-purpose.html ;-) On Wed, 2006-05-03 at 12:50 -0700, David M. Fetter wrote: > This is completely crazy! > > http://shelleytherepublican.com/2006/04/linux-european-threat-to-our-computers.html > > -- David M. Fetter - Portland State University - UNIX Systems Administrator "Reality is merely an illusion, albeit a very persistent one." ~Einstein signature.asc Description: This is a digitally signed message part
Off-Topic, Yet inadvertently related.
This is completely crazy! http://shelleytherepublican.com/2006/04/linux-european-threat-to-our-computers.html -- David M. Fetter - Portland State University - UNIX Systems Administrator "Reality is merely an illusion, albeit a very persistent one." ~Einstein signature.asc Description: This is a digitally signed message part
Re: NFS question
Hmmm, well, it sounds like it must be an irix nfs client thing. I would start reviewing the nfs client options on irix. Is the nfs share auto mounted or is it a manual or *fstab entry? The mount has it's own defined options and defaults which might be different than the other servers. That's where I would start looking. On Fri, 2006-02-24 at 14:40 -0500, Doug Henry wrote: > Tried it with gnu chmod and I get the same error message. > > > On 2/24/06, David M. Fetter <[EMAIL PROTECTED]> wrote: > Are you using the IRIX chmod or the gnu chmod from within > OpenPKG? > > On Fri, 2006-02-24 at 10:16 -0500, Doug Henry wrote: > > I have an NFS issue that I wanted to see if anyone has seen > before. > > My basic setup is a linux server, and mixed client > machines. On the > > linux server there is a large raid which is a giant > playground of data > > and has the following share defined: > > > > /raid/data*(sync,rw,all_squash,anonuid=1,anongid=1) > > > > I do this because ownership and permissions are meaningless > on this > > data share, and it keeps all data files usable by all...all > of the > > time. > > It works perfectly under linux, solaris, and through samba > to my > > windows clients. On my IRIX machine (stay with me...it may > not be an > > irix issue) I can create and delete files properly, but if I > do a > > chmod, I get an operation denied message. Strangely, irix > seems to > > check if I am the owner of the file before performing the > chmod and > > fails, but all other basic file operations work as > expected. > > > > Any and all suggestions welcome. > > > > -thanks > > > -- > David M. Fetter - UNIX System Administrator > "Change is inevitable. Growth is optional." ~unknown > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.2 (GNU/Linux) > > iD8DBQBD/zI > +/aYAl/wcnokRAjbjAJ0dxH7TREjkAnNCP7cgUllKaMl5DACgkF/o > lUZA8sJfjtdoab47m2ynJi4= > =/iX0 > -END PGP SIGNATURE- > > > -- David M. Fetter - UNIX System Administrator "Change is inevitable. Growth is optional." ~unknown signature.asc Description: This is a digitally signed message part
Re: NFS question
Try the OpenPKG one. If that works, then switch to using that version as a standard across all your servers. That way the results are always the same since it's the same utility. That's one of the nice benefits of using OpenPKG across multiple *nixes. ;-) On Fri, 2006-02-24 at 13:33 -0500, Doug Henry wrote: > The system chmod. I can't remember if I have tried the openpkg > (coreutils) one. > > > On 2/24/06, David M. Fetter <[EMAIL PROTECTED]> wrote: > Are you using the IRIX chmod or the gnu chmod from within > OpenPKG? > > On Fri, 2006-02-24 at 10:16 -0500, Doug Henry wrote: > > I have an NFS issue that I wanted to see if anyone has seen > before. > > My basic setup is a linux server, and mixed client > machines. On the > > linux server there is a large raid which is a giant > playground of data > > and has the following share defined: > > > > /raid/data*(sync,rw,all_squash,anonuid=1,anongid=1) > > > > I do this because ownership and permissions are meaningless > on this > > data share, and it keeps all data files usable by all...all > of the > > time. > > It works perfectly under linux, solaris, and through samba > to my > > windows clients. On my IRIX machine (stay with me...it may > not be an > > irix issue) I can create and delete files properly, but if I > do a > > chmod, I get an operation denied message. Strangely, irix > seems to > > check if I am the owner of the file before performing the > chmod and > > fails, but all other basic file operations work as > expected. > > > > Any and all suggestions welcome. > > > > -thanks > > > -- > David M. Fetter - UNIX System Administrator > "Change is inevitable. Growth is optional." ~unknown > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.2 (GNU/Linux) > > iD8DBQBD/zI > +/aYAl/wcnokRAjbjAJ0dxH7TREjkAnNCP7cgUllKaMl5DACgkF/o > lUZA8sJfjtdoab47m2ynJi4= > =/iX0 > -END PGP SIGNATURE- > > > -- David M. Fetter - UNIX System Administrator "Change is inevitable. Growth is optional." ~unknown signature.asc Description: This is a digitally signed message part
Re: NFS question
Are you using the IRIX chmod or the gnu chmod from within OpenPKG? On Fri, 2006-02-24 at 10:16 -0500, Doug Henry wrote: > I have an NFS issue that I wanted to see if anyone has seen before. > My basic setup is a linux server, and mixed client machines. On the > linux server there is a large raid which is a giant playground of data > and has the following share defined: > > /raid/data*(sync,rw,all_squash,anonuid=1,anongid=1) > > I do this because ownership and permissions are meaningless on this > data share, and it keeps all data files usable by all...all of the > time. > It works perfectly under linux, solaris, and through samba to my > windows clients. On my IRIX machine (stay with me...it may not be an > irix issue) I can create and delete files properly, but if I do a > chmod, I get an operation denied message. Strangely, irix seems to > check if I am the owner of the file before performing the chmod and > fails, but all other basic file operations work as expected. > > Any and all suggestions welcome. > > -thanks > -- David M. Fetter - UNIX System Administrator "Change is inevitable. Growth is optional." ~unknown signature.asc Description: This is a digitally signed message part
Re: openssh with_wrap fails on solaris (FIXED)
Ok, so, I figured out a couple ways to fix this, which I thought I would
share. The first method would be to add the following into the spec
file itself.
case "%{l_platform -t}" in
*-sunos* ) ldflags="$ldflags -lrt" ;;
esac
This method resolves the necessary "-lrt" on Solaris systems, however it
requires modifying the spec file. This other method, simply involves
editing the local users' ".rpmmacros" file to include the following line
on Solaris systems.
%l_ldflags -lrt
By doing this second method, it should solve all of the problematic
"-lrt" issues on Solaris systems without having to modify spec files at
all. This is theory, as I haven't fully tested it yet. It is also a
method used on OpenPKG 2.3 and may not be applicable or even necessary
in newer versions. I mainly just wanted to let those who are still
using the older version know.
Oh, and as a side note, openssh will fail to build even with "-lrt" if
you have enabled the with_private_namespace option within tcpwrappers.
You will get an error as such if it is enabled:
: undefined reference to `sock_host'
collect2: ld returned 1 exit status
make: *** [sshd] Error 1
make: *** Waiting for unfinished jobs
FYI.
On Tue, 2006-02-21 at 14:56 -0800, David M. Fetter wrote:
> So, Mark over here figured out that it is another "-lrt" thing in
> solaris. Is this something that is fixed in newer OpenPKG versions? We
> are probably going to be upgrading in the near future, but I was just
> curious if it has been addressed.
>
> See Mark's comments here:
>
> If you look at the config.log in
> the /usr/local/RPM/USER/TMP/openssh-3.9p1.
> Here is why it failed:
>
> configure:9555: /usr/local/bin/gcc -o conftest -O2 -pipe
> -I/usr/local/include -I/usr/include -DWITH_LDAP_PUBKEY -Wall
> -Wpointer-arith -Wno-uninitialized -I/usr/local/include
> -I/usr/local/include -L/usr/local/lib -R/usr/local/lib
> -L/usr/local/lib
> -R/usr/local/lib -L/usr/local/lib -L/usr/local/lib -L/lib -lldap
> -llber
> -lcrypto -lssl conftest.c -lwrap -lz -lfsl -lsocket -lnsl >&5
> /usr/local/lib/libwrap.so(misc.o)(.text+0x1b4): In function
> `tcpd_safe_sleep':
> : undefined reference to `nanosleep'
> collect2: ld returned 1 exit status
> configure:9561: $? = 1
> configure: failed program was:
>
> The " undefined reference to `nanosleep'" is the problem. If you do a
> "man
> nanosleep" on Solaris it shows that you need to use "-lrt" to link an
> executable with nanosleep.
>
> I think this is the same problem that berkely db has.
>
>
> On Tue, 2006-02-21 at 12:40 -0800, David M. Fetter wrote:
> > Ok, so I'm pretty sure that this has been brought up and even fixed a
> > while back, but I'm having some issue with this working. Now we're
> > still using OpenPKG 2.3 and that might be part of the issue. It builds
> > fine on RHEL3 but not on Solaris 9. I get the infamous error of
> > "checking for libwrap... configure: error: *** libwrap missing". The
> > only reference I found on this however in the mailing list archives was
> > related to a patch but it seemed to be quite old and supposedly was
> > adopted right away. Can anybody help me out here?
> >
--
David M. Fetter - UNIX System Administrator
"Change is inevitable. Growth is optional." ~unknown
signature.asc
Description: This is a digitally signed message part
Re: openssh with_wrap fails on solaris
So, Mark over here figured out that it is another "-lrt" thing in solaris. Is this something that is fixed in newer OpenPKG versions? We are probably going to be upgrading in the near future, but I was just curious if it has been addressed. See Mark's comments here: If you look at the config.log in the /usr/local/RPM/USER/TMP/openssh-3.9p1. Here is why it failed: configure:9555: /usr/local/bin/gcc -o conftest -O2 -pipe -I/usr/local/include -I/usr/include -DWITH_LDAP_PUBKEY -Wall -Wpointer-arith -Wno-uninitialized -I/usr/local/include -I/usr/local/include -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib -L/usr/local/lib -L/lib -lldap -llber -lcrypto -lssl conftest.c -lwrap -lz -lfsl -lsocket -lnsl >&5 /usr/local/lib/libwrap.so(misc.o)(.text+0x1b4): In function `tcpd_safe_sleep': : undefined reference to `nanosleep' collect2: ld returned 1 exit status configure:9561: $? = 1 configure: failed program was: The " undefined reference to `nanosleep'" is the problem. If you do a "man nanosleep" on Solaris it shows that you need to use "-lrt" to link an executable with nanosleep. I think this is the same problem that berkely db has. On Tue, 2006-02-21 at 12:40 -0800, David M. Fetter wrote: > Ok, so I'm pretty sure that this has been brought up and even fixed a > while back, but I'm having some issue with this working. Now we're > still using OpenPKG 2.3 and that might be part of the issue. It builds > fine on RHEL3 but not on Solaris 9. I get the infamous error of > "checking for libwrap... configure: error: *** libwrap missing". The > only reference I found on this however in the mailing list archives was > related to a patch but it seemed to be quite old and supposedly was > adopted right away. Can anybody help me out here? > -- David M. Fetter - UNIX System Administrator "Change is inevitable. Growth is optional." ~unknown signature.asc Description: This is a digitally signed message part
openssh with_wrap fails on solaris
Ok, so I'm pretty sure that this has been brought up and even fixed a while back, but I'm having some issue with this working. Now we're still using OpenPKG 2.3 and that might be part of the issue. It builds fine on RHEL3 but not on Solaris 9. I get the infamous error of "checking for libwrap... configure: error: *** libwrap missing". The only reference I found on this however in the mailing list archives was related to a patch but it seemed to be quite old and supposedly was adopted right away. Can anybody help me out here? -- David M. Fetter - UNIX System Administrator "Change is inevitable. Growth is optional." ~unknown signature.asc Description: This is a digitally signed message part
[Fwd: [Fwd: lesspipe warning bug & patch]]
This user here, Larry Lansing, contacted me on the community irc channel because he said he was having issues subscribing to the mailing list. He said that he gets the subscribe email and the successful confirmation that he subscribed but he can't post anything. He does get the emails though. Not sure why he can't post. In any case, this is the email he has been trying to post. Forwarded Message From: Larry Lansing <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: [Fwd: lesspipe warning bug & patch] Date: Tue, 31 Jan 2006 11:38:50 -0500 email message attachment (lesspipe warning bug & patch) Forwarded Message From: Larry Lansing <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: lesspipe warning bug & patch Date: Tue, 24 Jan 2006 17:46:13 -0500 -- "Most people do not really want freedom, because freedom involves responsibility, and most people are frightened of responsibility." -Sigmund Freud Sorry for sending this to you directly, but petidomo seems to hate me. Despite receiving success messages from the approval system, my messages to the devel list never seem to go through. If you could remedy this, I will to my best to bombard you with patches and new spec files. :) -- I've run into a small snag with 'less' in OpenPKG 2.5.0. Every time I invoke 'lesspipe' directly via the shell, or indirectly via 'less', I get the following warning messages from expr: [EMAIL PROTECTED]:~] lesspipe expr: warning: unportable BRE: `^.*\.\([^.]*\)$': using `^' as the first character of the basic regular expression is not portable; it is being ignored expr: warning: unportable BRE: `^\(.*\)\.[^.]*$': using `^' as the first character of the basic regular expression is not portable; it is being ignored cat: : No such file or directory [EMAIL PROTECTED]:~] less log.txt expr: warning: unportable BRE: `^.*\.\([^.]*\)$': using `^' as the first character of the basic regular expression is not portable; it is being ignored expr: warning: unportable BRE: `^\(.*\)\.[^.]*$': using `^' as the first character of the basic regular expression is not portable; it is being ignored For what it's worth, I'm using OpenPKG's 'expr'. A quick look at the 'lesspipe' shell script confirms that it does perform regular expression matches via 'expr', with a leading carrot in the match strings: ext=`expr "$base" : '^.*\.\([^.]*\)$'` base=`expr "$base" : '^\(.*\)\.[^.]*$'` A quick look at the expr info page confirms that the leading carrot is unnecessary: `STRING : REGEX' Perform pattern matching. The arguments are converted to strings and the second is considered to be a (basic, a la GNU `grep') regular expression, with a `^' implicitly prepended. The first argument is then matched against this regular expression. Here is a simple patch for lesspipe that removes the leading carrots and does not seem to hamper functionality: --- lesspipe.orig 2006-01-24 11:52:04.0 -0500 +++ lesspipe2006-01-24 11:52:12.0 -0500 @@ -8,8 +8,8 @@ base="$file" filter="" while [ 1 ]; do -ext=`expr "$base" : '^.*\.\([^.]*\)$'` -base=`expr "$base" : '^\(.*\)\.[^.]*$'` +ext=`expr "$base" : '.*\.\([^.]*\)$'` +base=`expr "$base" : '\(.*\)\.[^.]*$'` case $ext in gz|z|Z ) filter="$filter | gzip -d -c" Kudos for providing such a great system. It's made my day job _much_ easier. Let me know where to send the beer. :) -- Larry Lansing signature.asc Description: This is a digitally signed message part
Re: Samba w/ADS
Yes, I have seen this problem. I even mentioned the problem and possible solution in a previous "Samba w/ADS" thread. It seems that the order samba finds the libraries breaks it because it find ldap before it finds kerberos, but when I explicitly declare kerberos, then ldap, then the other necessary support libraries it builds properly. Now, I must note, that this is an example under openpkg 2.3 but using samba from current and I have tested it in a few months as other things became more important to look into. On Sun, 2006-01-15 at 11:30 -0800, Doug Summers wrote: > Using samba-3.0.21a-20051230 on RHEL 3.0... > > I was able to successfully get Samba w/ADS support built, but had to add > this to the command line: > > --define="with_ads yes" --define="l_ldflags -L$prefix/lib" > --define="l_cppflags -I$prefix/include" > > For some reason, without explicitly adding the LDFLAGS & CPPFLAGS > settings, Samba can't find the OpenLDAP libraries. Has anyone else > experienced this? > > Doug > __ > The OpenPKG Projectwww.openpkg.org > User Communication List openpkg-users@openpkg.org > -- David M. Fetter - UNIX Systems Administrator Portland State University "There are 10 types of people in the world, those that understand binary and those that don't." signature.asc Description: This is a digitally signed message part
Re: news
I say we burn the spammers alive! ;-) Oh and this is not the opinion of my employer or whatever...blah, blah, blah. LOL. On Sun, 2005-12-25 at 09:21 -0800, Bill Campbell wrote: > On Sun, Dec 25, 2005, Ralf S. Engelschall wrote: > >On Sat, Dec 24, 2005, Jan Goldsmith wrote: > > > >> [...] > > > >Sorry, someone tricked Petidomo via some special subscriptions and hence > >was able to let those postings be passed through. I've now fixed the > >Petidomo configuration. Hopefully this doesn't happen again... > > I don't care how good your filters and procedures are, some spam > will inevitably get through to the list (I've been known to > fumble-finger an approval on a message once or twice :-). > > Bill > -- > INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC > UUCP: camco!bill PO Box 820; 6641 E. Mercer Way > FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 > URL: http://www.celestial.com/ > > When you have an efficient government, you have a dictatorship. > -- Harry Truman > __ > The OpenPKG Project www.openpkg.org > User Communication List openpkg-users@openpkg.org > -- David M. Fetter - UNIX Systems Administrator Portland State University "There are 10 types of people in the world, those that understand binary and those that don't." signature.asc Description: This is a digitally signed message part
Re: OpenPKG Registry launched
On Tue, 2005-12-13 at 19:42 +0100, Bernhard Reiter wrote: > Am Donnerstag, 8. Dezember 2005 19:08 schrieb Bernhard Reiter: > > Hi Ralf, Hi Thomas, > > Ping? > Does anybody read me? We read. Not much to say when all there is are complaints, some of which you admit are potentially your own doing. The moral of the story here is that everybody who's part of OpenPKG is trying to do the best they can. In order to try to do something better, the information is needed. If the information isn't provided then OpenPKG may die and then there won't be anything to complain about because it just won't exist. Perhaps you would do better to offer up some solutions to what you complain about? > > > I think there are many other potential reasons why users do not give > > feeback. To me personally I have made several bad experiences with > > contacting OpenPKG, even with important questions. > > I probably have used the wrong channels, and had a mailinglist access setup > > problem for a while, but still the experience was bad. > > __ > The OpenPKG Projectwww.openpkg.org > User Communication List openpkg-users@openpkg.org > -- David M. Fetter - UNIX Systems Administrator Portland State University "There are 10 types of people in the world, those that understand binary and those that don't." signature.asc Description: This is a digitally signed message part
Re: OpenPKG Registry launched
What does it mean when a system doesn't have a heartbeat? I have three systems that seem to be now set as Departure because they don't have a heartbeat, but they aren't departed. Are the rest of the servers I registered today going to show up as departed tomorrow? -- David M. Fetter - UNIX Systems Administrator Portland State University "There are 10 types of people in the world, those that understand binary and those that don't." signature.asc Description: This is a digitally signed message part
Re: OpenPKG Registry launched
Oh, and, you probably hear this about is often as we all do here...good job on the openpkg product. There's always things to fix, but ultimately the core product is excellent. ;-) On Tue, 2005-11-29 at 15:53 -0800, David M. Fetter wrote: > Yeah, I can understand it all from yours and Thomas' perspective. I > suppose if I were in your shoes and it was all my own time and money on > the line (which ultimately means your families' livelihood), I would > most likely do something similar to get quick results. So, for that > part, no worries. It's all good in the end. > > While I try to keep up on all the news and such here, I still miss a few > things here and there. However, I think that perhaps a few things may > not have been discussed like the specifics of what things and when > exactly they would be going offline for anonymous access. The problem > with rsync, of course, is that I was using the --delete option which > means everything was wiped out. However, I anticipate such problems in > my coding so I had a rather simple recover and I just stopped the rsync > mirror script for now. If/When you find time to get the rsync bit back > up, I would be more than happy to help you test it. > > As far as the registry bits, I just built them on our build servers and > registered them. They show up in my online registry page, so I'm > promoting the package to our production binary repository which means > this Friday night all of our openpkg servers will have it installed. I > can then run a quick script to do the registration and you will have the > stats from us. > -- David M. Fetter - UNIX Systems Administrator Portland State University "There are 10 types of people in the world, those that understand binary and those that don't." signature.asc Description: This is a digitally signed message part
Re: OpenPKG Registry launched
Yeah, I can understand it all from yours and Thomas' perspective. I suppose if I were in your shoes and it was all my own time and money on the line (which ultimately means your families' livelihood), I would most likely do something similar to get quick results. So, for that part, no worries. It's all good in the end. While I try to keep up on all the news and such here, I still miss a few things here and there. However, I think that perhaps a few things may not have been discussed like the specifics of what things and when exactly they would be going offline for anonymous access. The problem with rsync, of course, is that I was using the --delete option which means everything was wiped out. However, I anticipate such problems in my coding so I had a rather simple recover and I just stopped the rsync mirror script for now. If/When you find time to get the rsync bit back up, I would be more than happy to help you test it. As far as the registry bits, I just built them on our build servers and registered them. They show up in my online registry page, so I'm promoting the package to our production binary repository which means this Friday night all of our openpkg servers will have it installed. I can then run a quick script to do the registration and you will have the stats from us. On Tue, 2005-11-29 at 23:58 +0100, Ralf S. Engelschall wrote: > On Tue, Nov 29, 2005, David M. Fetter wrote: > > > I may have missed something at some point, but if it's information of > > how many servers we have openpkg installed on, why can't we just fill > > out an online form? I would be more than happy to do that. > > Yes, David, I know that you and some others would be happy to do that > and you used the OpenPKG Community Feedback in the past for this. > Unfortunately after even 5 years we just received about 30 feedbacks in > total although we asked multiple times to give feedback and tell if one > is an OpenPKG user. Before and after every release we explicitly involve > our users and ask for their feedback. The results you know: mostly no > feedback. > > As I said and without kidding, even after five years we have not the > smallest clue how many users we have at all. It could be that we have > lots of users who care but just don't say anything at all because > OpenPKG "just works" for them (which would be cool, of course). > > But fully serious: it could be also that we have just 100 users and > our current efforts for establishing additional OpenPKG services are > just a major waste of time and money. Well, it would be even ok if our > community is very small -- as long as we know it _before_ we burn the > additional time and cash (please understand that at this point in time > I cannot give more details here in public about the current ongoing > service establishment projects, but at least OpenPKG Foundation members > know what I'm speaking about). > > > For that > > matter, the registry bit could be quite a bit less intrusive by just > > having it send the information you desire. My main point is, why not > > try to see how many of us setup the registry first, then if folks don't > > respond to that, pull the plug on rsync and other anonymous access? It > > would be better than pulling the plug and having mirrors that a bunch of > > us have get wiped out overnight. I, for one, can easily send you output > > from my automatic update process which would tell you the packages we > > have installed as well as the all of the options used on the number of > > servers that exist. I guess I didn't realize that all of this was going > > to be breaking in an overnight swoop and now it's caused a bunch of > > recovery work in our processes. > > Yes, I'm very sorry that we broke at least the RSYNC part. This was > certainly our fault because we entirely focused on FTP. There we even > made sure that the "openpkg build" tool still runs seamlessly despite > the required login. It was not our intention to easily break existing > things. We really tried to minimize the impact. > > As you know, the registration was even pre-announced inside the > OpenPKG Foundation about 2 weeks ago for testing purposes and just two > Foundation members responded at all (one of them were you AFAIK ;-). > Nobody else really cared very much. > > So we had to finally activate it for the public to really get the > feedback about it. Without the current complains we still wouldn't even > know the existing problems. I dislike myself the "Heave ho!" approach > we had to choose. But experience with the Community Feedback form and > the various questions on the mailing lists to give feedback definitely > showed that the
Re: OpenPKG Registry launched
On Mon, 2005-11-28 at 23:56 +0100, OpenPKG wrote: > FOR IMMEDIATE RELEASE - 2005-11-28 > > OpenPKG Registry finally launched! > > http://www.openpkg.org/ -- Munich, DE -- 2005-11-28 -- > As a consequence of the changed environmental conditions of OpenPKG > during the year 2005, the OpenPKG project needs to finally shift its > focus from the requirements of a single predominant sponsor towards > the needs of a highly distributed and diverse community. > > To meet this target it is vital to the OpenPKG project to know its > community. Unfortunately, experience showed that optional community > feedback gains just little attention. As a result, the OpenPKG project > still has not sufficiently explored its community in both size and > scope. To throw in a gear and build a much stronger relationship with > its community the OpenPKG project is forced to now pull essential > information from its community through mandatory methods. I may have missed something at some point, but if it's information of how many servers we have openpkg installed on, why can't we just fill out an online form? I would be more than happy to do that. For that matter, the registry bit could be quite a bit less intrusive by just having it send the information you desire. My main point is, why not try to see how many of us setup the registry first, then if folks don't respond to that, pull the plug on rsync and other anonymous access? It would be better than pulling the plug and having mirrors that a bunch of us have get wiped out overnight. I, for one, can easily send you output from my automatic update process which would tell you the packages we have installed as well as the all of the options used on the number of servers that exist. I guess I didn't realize that all of this was going to be breaking in an overnight swoop and now it's caused a bunch of recovery work in our processes. > > Everything available from the OpenPKG project is a free and open > offering and remains this way, of course. Additionally, since years it > was also possible to grab all of the OpenPKG offerings anonymously. In > order to receive information about the community this anonymous access > now is no longer provided for accessing the full range of OpenPKG > offerings. From now on only the latest OpenPKG-RELEASE (without > updates) is accessible anonymously. > > A registration is now required to access all other download resources. > Access is granted upon a free of charge registration as an OpenPKG > fellow user, registration of at least one installed OpenPKG instance > and a configured relationship between these two entities. > > Please note that everything available from the OpenPKG project remains > available free of charge and as open source software. Only anonymous > access to our offerings is now restricted in order to better assess > the OpenPKG installation base and start to understand the demands of > the OpenPKG community. > > Please actively support the OpenPKG project with your registration! > More details can be found under http://registry.openpkg.org/help > > MORE INFORMATION > > The OpenPKG ProjectOpenPKG Foundation e.V. > http://www.openpkg.org/http://www.openpkg.net/ > [EMAIL PROTECTED] [EMAIL PROTECTED] > +49-172-8986801 (CET) +49-172-8986801 (CET) > > __________ > The OpenPKG Projectwww.openpkg.org > Project Announcement List openpkg-announce@openpkg.org > -- David M. Fetter - UNIX Systems Administrator Portland State University "There are 10 types of people in the world, those that understand binary and those that don't." signature.asc Description: This is a digitally signed message part
Re: OpenPKG Registry launched
On Tue, 2005-11-29 at 09:11 -0800, Bill Campbell wrote: > On Tue, Nov 29, 2005, Ralf S. Engelschall wrote: > >On Mon, Nov 28, 2005, OpenPKG wrote: > > > >> OpenPKG Registry finally launched! > >> [...] > > > >The first questions pop up around the OpenPKG Registry. > > > >We will try hard to answer all of them to you. Let me just share a few > >personal points with you: > > What has happened to rsync access? My nightly mirror run > succeeded in deleting everything from our mirrors here. Indeed, this is the result I found this morning as well. Losing rsync functionality causes significant breakage in our automated deployment system. In addition, I have a question about how the registry bit works. Does this require that each of our servers be downloading directly from you or are we still able to have an intermediary place for doing a mirror so we can maintain our own binary repository as we currently do? As long as the registry is only sending you information on what is installed with what options and it works with 2.3 (since we're still on that and won't be moving to the latest release still for another few months), then we can proceed. Otherwise, I'm afraid that the registry will break how we are maintaining our binary repository and I will now have to go back and do significant re-working. That wouldn't be too good. Please advise. Thanks. > > Bill > -- > INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC > UUCP: camco!bill PO Box 820; 6641 E. Mercer Way > FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 > URL: http://www.celestial.com/ > > When a place gets crowded enough to require ID's, social collapse is > not far away. It is time to go elsewhere. The best thing about space > travel is that it made it possible to go elsewhere. > -- Robert Heinlein > __ > The OpenPKG Project www.openpkg.org > User Communication List openpkg-users@openpkg.org > -- David M. Fetter - UNIX Systems Administrator Portland State University "There are 10 types of people in the world, those that understand binary and those that don't." signature.asc Description: This is a digitally signed message part
jboss cpio error
I'm getting a cpio error when the jboss rpm we built is trying to unpack and install itself: http://updates.oit.pdx.edu/openpkg/2.3/prod-i686-pc-linux-gnu/CUR/jboss-3.2.7-20050129.ix86-rhel3-ulo.rpm Preparing... ## jboss warning: /usr/local/etc/jboss/jboss-minimal.xml saved as /usr/local/etc/jboss/jboss-minimal.xml.rpmorig warning: /usr/local/etc/jboss/jboss-service.xml saved as /usr/local/etc/jboss/jboss-service.xml.rpmorig warning: /usr/local/etc/jboss/jboss.sh saved as /usr/local/etc/jboss/jboss.sh.rpmorig warning: /usr/local/etc/jboss/jndi.properties saved as /usr/local/etc/jboss/jndi.properties.rpmorig warning: /usr/local/etc/jboss/log4j.xml saved as /usr/local/etc/jboss/log4j.xml.rpmorig warning: /usr/local/etc/jboss/login-config.xml saved as /usr/local/etc/jboss/login-config.xml.rpmorig warning: /usr/local/etc/jboss/server.policy saved as /usr/local/etc/jboss/server.policy.rpmorig warning: /usr/local/etc/jboss/standardjaws.xml saved as /usr/local/etc/jboss/standardjaws.xml.rpmorig warning: /usr/local/etc/jboss/standardjboss.xml saved as /usr/local/etc/jboss/standardjboss.xml.rpmorig warning: /usr/local/etc/jboss/standardjbosscmp-jdbc.xml saved as /usr/local/etc/jboss/standardjbosscmp-jdbc.xml.rpmorig warning: /usr/local/etc/jboss/xmdesc/AttributePersistenceService-xmbean.xml saved as /usr/local/etc/jboss/xmdesc/AttributePersistenceService-xmbean.xml.rpmorig warning: /usr/local/etc/jboss/xmdesc/ClientUserTransaction-xmbean.xml saved as /usr/local/etc/jboss/xmdesc/ClientUserTransaction-xmbean.xml.rpmorig warning: /usr/local/etc/jboss/xmdesc/JNDIView-xmbean.xml saved as /usr/local/etc/jboss/xmdesc/JNDIView-xmbean.xml.rpmorig warning: /usr/local/etc/jboss/xmdesc/NamingService-xmbean.xml saved as /usr/local/etc/jboss/xmdesc/NamingService-xmbean.xml.rpmorig warning: /usr/local/etc/jboss/xmdesc/TransactionManagerService-xmbean.xml saved as /usr/local/etc/jboss/xmdesc/TransactionManagerService-xmbean.xml.rpmorig ## error: unpacking of archive failed on file /usr/local/var/jboss/server/conf: cpio: rename failed - Invalid argument Has anybody else seen this? I haven't looked at the spec file thoroughly yet. I figured I'd try to send an email to see if there is a quick answer out there. -- David M. Fetter - UNIX Systems Administrator Portland State University "There are 10 types of people in the world, those that understand binary and those that don't." signature.asc Description: This is a digitally signed message part
Re: Solaris build environment
On Wed, 2005-08-24 at 11:41 -0400, Dan wrote: > On 8/22/05, David M. Fetter <[EMAIL PROTECTED]> wrote: > > Try this out: > > http://www.cns.pdx.edu/documentation/openpkg/psu_unofficial_openpkg_howto.html. > > > > > > On Mon, 2005-08-22 at 17:24 -0400, Dan wrote: > > > I'm trying to create a build environment under Solaris 9 (completely > > > stock) in which to build the PLUS tree as well as rebuild the CORE > > > packages, as encouraged by the tutorial. So far I haven't found > > > documentation or example configs anywhere online, other than how to > > > specify settings using ~/.rpmmacros and a few env vars. > > > > > > Could a developer share their configs or point me towards documentation? > > > > That's outstanding, David, thanks. Are you interested in updates to > that document? Yes and actually, I plan on doing my own updating and adding to the document in the near future. I have done quite a few fixes and corrections to make things work more smoothly as far as deployment and auto-updating. There are a few more to do, but the document needs to be updated with what I have done so far and just to reflect newer revisions of OpenPKG. > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: Solaris build environment
Try this out: http://www.cns.pdx.edu/documentation/openpkg/psu_unofficial_openpkg_howto.html. On Mon, 2005-08-22 at 17:24 -0400, Dan wrote: > I'm trying to create a build environment under Solaris 9 (completely > stock) in which to build the PLUS tree as well as rebuild the CORE > packages, as encouraged by the tutorial. So far I haven't found > documentation or example configs anywhere online, other than how to > specify settings using ~/.rpmmacros and a few env vars. > > Could a developer share their configs or point me towards documentation? > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: cvs and nls
On Thu, 2005-05-26 at 22:25 +0200, Ralf S. Engelschall wrote: > On Fri, May 20, 2005, Thomas Moschny wrote: > > > in order to rebuild cvs-1.12.9-2.3.1 for rhel3/ia64, I had to add the switch > > --disable-nls to the configure section, otherwise I get an error in the > > final > > linking step: > > > > /openpkg/bin/cc -O2 -pipe -fpic -DRSE_PATCHES -L/openpkg/lib > > -L/openpkg/lib > > -o cvs [...] ../diff/libdiff.a ../lib/libcvs.a -lrt -lcrypt -lnsl > > -lfsl > > -lnsl -lz > > ../lib/libcvs.a(xmalloc.o)(.text+0x42): In function `xalloc_die': > > : undefined reference to `libintl_gettext' > > ../lib/libcvs.a(xmalloc.o)(.text+0xd2): In function `xalloc_die': > > : undefined reference to `libintl_gettext' > > collect2: ld returned 1 exit status > > make[2]: *** [cvs] Error 1 > > make[1]: *** [all-recursive] Error 1 > > make: *** [all] Error 2 > > error: Bad exit status from /openpkg/RPM/TMP/rpm-tmp.50067 (%build) > > > > Is there something wrong with my libintl/gettext/... or is this "expected > > behavior" ? > > No, the --disable-nls is reasonable. Taken over into OpenPKG-CURRENT now: > http://cvs.openpkg.org/chngview?cn=23559 > Thanks. It seems to me that these sorts of fixes should go into the UPD for releases as well. At least after a certain time period that it has been in current and it seems to function properly. >Ralf S. Engelschall >[EMAIL PROTECTED] >www.engelschall.com > > __________ > The OpenPKG Projectwww.openpkg.org > User Communication List openpkg-users@openpkg.org > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: Q: Pointers to OpenPKG-HOWTOs ?
On Fri, 2005-07-01 at 13:13 -0700, Bill Campbell wrote: > On Fri, Jul 01, 2005, Matthias Kurz wrote: > > > >Hi. > > > >I've seen some pointers in the past, but i cannot find them again. Are > >there some public documents/HOWTOs, where people describe how they > >configure and maintain OpenPKG ? > > I have an overview on one of our sites that I wrote a couple of > years ago (and need to update). It's also referenced at the > bottom of the OpenPKG documentation page. > > http://www.libertysoft.org/openpkg/overview/ > > David Fetter, also has written quite a bit, certainly more detailled than > mine. This is also referenced on the OpenPKG documentation page. > > http://www.cns.pdx.edu/documentation/openpkg/psu_unofficial_openpkg_howto.html I will be updating this document within the next few months as well to reflect either things that haven't been documented yet but need to be or changes just for better or more efficient methods I have found in testing. > > Bill > -- > INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC > UUCP: camco!bill PO Box 820; 6641 E. Mercer Way > FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 > URL: http://www.celestial.com/ > > Many companies that have made themselves dependent on [the equipment of a > certain major manufacturer] (and in doing so have sold their soul to the > devil) will collapse under the sheer weight of the unmastered complexity of > their data processing systems. > -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5 > __ > The OpenPKG Project www.openpkg.org > User Communication List openpkg-users@openpkg.org > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: New Dependency Problem
That fixed it. Thanks. On Fri, 2005-04-29 at 07:49 +0200, Michael van Elst wrote: > On Thu, Apr 28, 2005 at 03:26:56PM -0700, David M. Fetter wrote: > > > Ya, I noticed that when I looked at the log. It seems that the build > > file might be getting parsed incorrectly or something. I attached the > > build file that is being used for the options. The openpkg build > > options I'm using are just '-A -U'. > > That explains it :) > > > -Dopenpkg-import::with_mta = no > > > > This adds the string 'openpkg-import::with_mta = no' to the option 'D'. > Later is split into 3 words: > > 'openpkg-import::with_mta' > -> has no '=' sign and gets the default value of 'yes'. > > '=' > -> isn't recognized as an option because there is no name before the '=' >and is ignored. > > 'no' > -> has no '=' sign and gets the default value of 'yes'. > > Please remove all the whitespace around '='. > > > Greetings, -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: New Dependency Problem
Ya, I noticed that when I looked at the log. It seems that the build file might be getting parsed incorrectly or something. I attached the build file that is being used for the options. The openpkg build options I'm using are just '-A -U'. On Fri, 2005-04-29 at 00:18 +0200, Michael van Elst wrote: > On Thu, Apr 28, 2005 at 03:05:05PM -0700, David M. Fetter wrote: > > > Here's the full output file. > > # ATTENTION: ne ignores option 'yes' > # ATTENTION: ne ignores option 'opkg-n' > # ATTENTION: ne ignores option 'www' > # ATTENTION: ne ignores option 'sys' > # ATTENTION: ne ignores option 'normal' > # ATTENTION: ne ignores option 'sendmail' > . > > This looks like there are some weird options passed to the script. > > # source for openpkg-import::with_mta is openpkg-import-0-2.3.0 > > This tells me that you do set the with_mta option. > > # recursing over dependencies for samba-3.0.11-2.3.1 > # rebuilding samba (parameter mismatch) > > You also ask for different options to be set for the samba > package. > > Could you please check the script parameters and the > content of .openpkg/build ? > > Greetings, -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu build.gz Description: GNU Zip compressed data signature.asc Description: This is a digitally signed message part
Re: New Dependency Problem
On Thu, 2005-04-28 at 07:48 +0200, Michael van Elst wrote: > On Wed, Apr 27, 2005 at 03:57:20PM -0700, David M. Fetter wrote: > > > Ok, so the installed postgresql7 does show this: > > Hmmm, well, we didn't build it 'with_mta=yes'. The installed instance > > of openpkg-import shows: > > What does the index show ? > openpkg-import::with_mta openpkg-import::with_mta_path openpkg-import > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: New Dependency Problem
On Thu, 2005-04-28 at 00:21 +0200, Michael van Elst wrote: > On Wed, Apr 27, 2005 at 03:08:26PM -0700, David M. Fetter wrote: > > > FATAL: errors occured while building: > > bind-9.3.0-2.3.0: bind searches a frood called 'postgresql' > > jabberd-2.0s6-2.3.1: jabberd searches a frood called 'postgresql' > > This means it requires 'postgresql' which doesn't exist. Now, > the postgresql7 package should also provide 'postgresql'. I don't > know why it isn't found. Ok, so the installed postgresql7 does show this: Provides: postgresql7::with_server = yes postgresql7::with_cxx = no postgresql7::with_perl = yes postgresql7::with_odbc = yes postgresql7::with_compat = no postgresql7::with_tcl = yes postgresql7::with_slony1 = no postgresql7::with_pgpool = no postgresql postgresql7 postgresql7 = 7.4.7-20050407 So, yes, it should be detecting that, but it's not. > > > openpkg-import-0-2.3.0: openpkg-import conflicts with > > sendmail-8.13.3-2.3.0 > > openpkg-import-0-2.3.0: openpkg-import conflicts with > > sendmail-8.13.3-2.3.0 > > openpkg-import-0-2.3.0: openpkg-import conflicts with > > sendmail-8.13.3-2.3.0 > > When openpkg-import is built with 'with_mta=yes' then it makes > available the MTA of the operating system to the OpenPKG instance. > This conflicts with the packages exim, postfix, sendmail, ssmtp. > There can be only one MTA. Hmmm, well, we didn't build it 'with_mta=yes'. The installed instance of openpkg-import shows: Provides: openpkg-import::with_mta = no openpkg-import::with_mta_path = sendmail openpkg-import = 0-2.3.0 > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
New Dependency Problem
In OpenPKG 2.3, we have the choice of either using postgresql (which is postgresql v8) or postgresql7. We chose to stay with postgresql7 for now as more significant testing needs to be done to do the upgrade for us. Now when I try to do a rebuild I get the following: FATAL: errors occured while building: bind-9.3.0-2.3.0: bind searches a frood called 'postgresql' jabberd-2.0s6-2.3.1: jabberd searches a frood called 'postgresql' openpkg-import-0-2.3.0: openpkg-import conflicts with sendmail-8.13.3-2.3.0 openpkg-import-0-2.3.0: openpkg-import conflicts with sendmail-8.13.3-2.3.0 openpkg-import-0-2.3.0: openpkg-import conflicts with sendmail-8.13.3-2.3.0 Now, it does seem that bind and jabberd could be built to use postgresql, however we didn't build it with enabling that option. It seems like an issue is present where bind and jabberd is requiring postgresql, when in fact it should only be required of the options that build them with postgresql support are enabled. As far as the openpkg-import and sendmail conflict goes. I'm not sure as of yet what that conflict might be, but it seems to be reporting such. Also, something of note is that this dilemma seems to only occur on our Solaris build server but not on our Linux build server. Anybody have any ideas about this or can it be fixed as a UPD? -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: RPM Upgrade Conflicts
The noreplace rpmmacros addition works perfectly for us. It solves all of our problems that we were having with auto-updating and working configs being overwritten. However, the .rpmmacros existence causes another side effect on linux systems because it is seen by the OS rpm as well as openpkg rpm. It would better better to move the openpkg .rpmmacros file under the ~/.openpkg/ directory along with the build file I think. On Sun, 2005-04-10 at 10:35 +0200, Ralf S. Engelschall wrote: > On Sat, Apr 09, 2005, Shawn Walker wrote: > > > # ~/.rpmmacros: > > %config config(noreplace) > > > > This way all "%config" tags in the OpenPKG .spec files are on-the-fly > > replaced with "%config(noreplace)" and as a result you get the .rpmnew > > instead of .rpmsave files. Voila! > > > > Wonderful! Then I have no complaint. Though it would be nice if that were > > documented in the FAQ :) > > I've added it to the Wiki now: > http://wiki.openpkg.org/?HintGeneralConfigNoReplace > >Ralf S. Engelschall >[EMAIL PROTECTED] >www.engelschall.com > > __ > The OpenPKG Project www.openpkg.org > User Communication List openpkg-users@openpkg.org > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: Samba w/ADS Support
I looked into this and from what I can tell there is a patch that has to be applied which has the ADS support. It currently isn't in the openpkg samba spec file. It would need to be added and rebuilt as part of current. I have this on my plate at my work, but it is rather low priority right now. On Thu, 2005-04-21 at 11:43 -0700, Doug Summers wrote: > I'm looking through the samba.spec files for the latest releases and > none of them have options for Active Directory support. Is this doable > from these sources or do I need to compile my own from Samba? > > Doug > __ > The OpenPKG Projectwww.openpkg.org > User Communication List openpkg-users@openpkg.org > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: RPM Upgrade Conflicts
On Fri, 2005-04-08 at 20:59 +0200, Michael van Elst wrote: > On Fri, Apr 08, 2005 at 11:39:33AM -0700, David M. Fetter wrote: > > > It seems that when most of the rpms that have config files are upgraded, > > the working config is moved to some *.rpmsave file and the new one is > > put into place. What this basically means is that any services on a > > server where we might upgrade an rpm on will temporarily break. > > This assumes that the new software is able to work correctly > with the old config files. This might be even true for most > popular packages most of the time but for a real production > environment you want some proper configuration management. Right. We actually have cfengine too for all of our configs. The dilemma is that when an rpm is updated it moves the config aside then restarts and bam we have downtime upon update. Cfengine comes along every 10 or 15 minutes and puts the proper config back into place, but we don't use cfengine to restart most of the services due to some issues we have had with trying to do it that way. So, the problem I'm trying to point out is that moving aside the running configs could cause unnecessary downtime even if it is for 10 or 15 minutes. Any down time is generally not good. Now I can understand that the some software won't work at all with an old config and I think at that juncture it is suitable for the running config to be moved aside to an *.rpmsave. It makes it so that it is blatantly obvious that the admin has to review it right away. However, most of the time, the running config works with slightly newer revisions of software and at that point it makes more sense to copy the new config to *.rpmnew so that when the admin has time they can go review the differences. It isn't really a matter of neglect on the admins' side of things, but in general most unix shops are understaffed and/or shorthanded due to the number of outstanding projects, so they may not have time to review every new config for every package and if it's not immediately necessary then why should they be forced to do that? In our shop, it is a goal to cut down the maintenance cost of maintaining software in general. Part of this project ended up using the fine OpenPKG product to assist with a good portion of the software management. We still have about 20-30 pieces of software that we have to manually maintain and keep current, but for the other 500+ pieces we are trying to incorporate it into an auto-update procedure. If it is the philosophy of OpenPKG to always move aside running configs to *.rpmsave regardless of whether it is necessary or not, then I suppose we will just need to manually update those pieces of software as well and pull them out of the automated update process. Unfortunately, this takes away from lowering the overall maintenance cost. All I'm trying to do is to see if I can bring up the discussion and maybe ultimately change the way the configs are handled during an upgrade of a package so that the maintenance cost can stay as minimal as possible. I completely agree with what you're saying and in a perfect world every admin would have the time to properly review thoroughly each piece of software prior to upgrade as well as each individual patch for the underlying OS. This, however, is not a perfect world and so we admins must make do and do the best we can to maintain stability in our environments. It becomes even more difficult to manage config changes like this with the more servers you have. From this stand point, it seems logical that there are reasons for using *.rpmnew and *.rpmsave for configs. Most of the time, *.rpmnew is sufficient and that's good because it can keep the maintenance costs down. When a piece of software changes a config so radically that it won't function with an old config, then using *.rpmsave to move aside the running config makes more sense. That is basically how I see it from the administrative aspect. I hope this makes some sense. I'm not trying to ruffle feathers or anything, I'm just trying to state what I think is a valid point. Thanks. > > Greetings, -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
RPM Upgrade Conflicts
It seems that when most of the rpms that have config files are upgraded, the working config is moved to some *.rpmsave file and the new one is put into place. What this basically means is that any services on a server where we might upgrade an rpm on will temporarily break. Most other linux distributions will put the new config with an upgraded package as *.rpmnew instead of moving aside the working config. Then it would be up to the administrators to do a comparison to see if anything needs to be added or modified between the working config and the new config. This seems to be a better approach so that running services are not broken in the middle of upgrading a package. Why does OpenPKG move the working config aside instead? Can this be changed so the packages with configs will copy the new config as *.rpmnew so running services don't break? The problem that I'm trying to solve here is that we want to have a certain portion of rpms automatically updated on a weekly basis as needed in a more or less hands off fashion, but if the upgrade means that the services break because the running config is moved aside, then that's not possible. Any comments? -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: openpkg build -A -U problem
On Tue, 2005-03-22 at 22:35 +0100, Michael van Elst wrote: > On Tue, Mar 22, 2005 at 09:13:42AM -0800, David M. Fetter wrote: > > I'm working on building a new binary repository out of the latest 2.3 > > release, but I'm coming across an issue with openssl. When I do an > > 'openpkg build -A -U' initially I get: > > > > openssl-0.9.7e-2.3.0UPDATE openssl-0.9.7e-2.3.1 > > If you have 2.3.0 and 2.3.1 then you have the update packages in > your repository. In that case the first installation of openssl > should pick the update (i.e. 2.3.1). > > So what is 'initially' ? How did you install 2.3.0 ? Initially, is just the first time I run it. Then the second it returns the next results. > > > Then when I execute 'openpkg build -A -U' a second time to make sure > > everything is updated properly, it comes back with: > > > > openssl-0.9.7e-2.3.1UPDATE openssl-0.9.7e-2.3.0 > > This looks like 2.3.1 is no longer avaible in the repository. They are both there. > > Do you install directly from ftp.openpkg.org ? No, I rsync my own local copy of the src rpms, which then removes about 30 or so of them that we don't want available, then rebuild the src rpm index and run the build command. The local src rpm repository has the base SRC with PLUS and UPD as subdirectories. > > > Greetings, -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
openpkg build -A -U problem
I'm working on building a new binary repository out of the latest 2.3 release, but I'm coming across an issue with openssl. When I do an 'openpkg build -A -U' initially I get: openssl-0.9.7e-2.3.0UPDATE openssl-0.9.7e-2.3.1 Then when I execute 'openpkg build -A -U' a second time to make sure everything is updated properly, it comes back with: openssl-0.9.7e-2.3.1UPDATE openssl-0.9.7e-2.3.0 This problem causes many packages to want to be rebuilt due to the dependencies of dependencies, etc. I have seen something similar with the 2.1 release as well. Is anybody aware of this problem? Has anybody else seen this? It seems to be only on Solaris because we build under RHEL3 and I don't have the same problem there. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: problems building emacs-21.4a-2.3.0.src.rpm on Whitebox Linux
Ok, then I will fix it. ;-) We can't do without this package so it
must work. Oh, and I did find that there is something wrong when
enabling with_leim=yes. It fails, seemingly because the secondary
source directory wasn't given a separate name and so it doesn't know
where the original emacs source directory is. I might fix this too, but
I don't really care too much about this portion. I'll submit a fix when
I have it.
On Wed, 2005-03-09 at 19:59 +0100, Ralf S. Engelschall wrote:
> On Wed, Mar 09, 2005, David M. Fetter wrote:
>
> > Anybody find out any info on this? I'm having the same issue on a RHEL3
> > system.
>
> No, and unless you attach a debugger I think you cannot find anything.
> The only things you can do without are the usual attempts: try to
> replace "%{l_cflags -O}" with "%{l_cflags}" to turn off optimizations,
> etc.
>Ralf S. Engelschall
>[EMAIL PROTECTED]
>www.engelschall.com
>
> __
> The OpenPKG Project www.openpkg.org
> User Communication List openpkg-users@openpkg.org
>
--
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
signature.asc
Description: This is a digitally signed message part
Re: problems building emacs-21.4a-2.3.0.src.rpm on Whitebox Linux
Anybody find out any info on this? I'm having the same issue on a RHEL3 system. On Sat, 2005-03-05 at 08:55 +0100, Simon Mudd wrote: > Just to follow up my own post I have tried and failed to build the > following rpms on WBL: > > emacs-21.3-2.1.0.src.rpm.build.txt > emacs-21.3-2.2.0.src.rpm.build.txt > emacs-21.4a-2.3.0.src.rpm.build.txt > > The build output can be found at > http://nl.WL0.org/~sjmudd/emacs-21.3-2.1.0.src.rpm.build.txt > http://nl.WL0.org/~sjmudd/emacs-21.3-2.2.0.src.rpm.build.txt > http://nl.WL0.org/~sjmudd/emacs-21.4a-2.3.0.src.rpm.build.txt > > I'll try and investigate further to see why these builds are failing. > > Regards, > > Simon > __ > The OpenPKG Projectwww.openpkg.org > User Communication List openpkg-users@openpkg.org > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Expect Tcl Dependency Problem
Something seems wrong with how Expect and Tcl interacts in regards to
dependencies. The problem occurs if you have a prior version of Tcl and
Expect installed, then go to upgrade to any other version. What happens
is that the update fails when trying to upgrade Tcl using the build
tools. It seems to be because Expect has a specific version of Tcl
required in it's Requires section. Since Expect has Tcl as a
requirement then the build tool sees that Tcl should be upgraded before
Expect as per the order it derives based on what exists in the Require
section of all of the rpms. However, since Expect has a specific
version of Tcl required, the update of the newer Tcl fails because the
currently old Expect that is installed requires an older specific
version of Tcl. I'm thinking that line #61 of the expect.spec file
should be:
PreReq: OpenPKG, openpkg >= 2.3.0, tcl >= %{V_tcl}
Instead of:
PreReq: OpenPKG, openpkg >= 2.3.0, tcl = %{V_tcl}
Line #60, which is the BuildPreReq, has the same line. I'm not sure if
this should be changed though. I'm thinking that only the PreReq should
be changed while the BuildPreReq stays with the specific version as that
seems that it would logically function as is needed and not break
updating from an older version to newer as well. Does this logic seem
proper to you guys?
--
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
signature.asc
Description: This is a digitally signed message part
OpenPKG Upgrade Questions
I have a couple of quick questions: 1. What is the current status of the 2.3 release? Is it on schedule or a bit behind? 2. Will I be able to upgrade OpenPKG from 2.1 to 2.3 directly or will I need to update 2.1 to 2.2 then 2.2 to 2.3? Thanks. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: OpenPKG Dependency Loop?
Ok, that's what I was thinking as well. I just wanted to confirm my suspicions. Will this be fixed or is it just going to be ignored since the latest release is 2.2 and 2.3 is soon to be released? On Thu, 2005-02-10 at 07:15 +0100, Michael van Elst wrote: > On Wed, Feb 09, 2005 at 04:30:27PM -0800, David M. Fetter wrote: > > > openpkg-2.1.2-2.1.2,openpkg-20040825-20040825 > > This is supposed to be one package name with version and revision > information. > > I guess there is a typo in a requirement or provides where the > entries are not whitespace but comma separated. > > Greetings, -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
OpenPKG Dependency Loop?
I'm having a new issue with OpenPKG itself. When I use the openpkg build tools against a local source repository to rebuild packages into binary rpms there seems to be some sort of loop. I setup the local source repository so that it has PLUS and UPD under the top level SRC directory. Then I rebuild the index for SRC, which includes all subdirectories. After this, I use openpkg build to generate the upgrade script which seems to go through fine and do all the rebuilds. However, after doing this the first time, if I do it again to verify that nothing more needs to be rebuilt/upgraded I get the following list of things that it wants to upgrade: ghostscript-8.14-2.1.0 UPDATE ghostscript-8.14-2.1.2 gimp-2.0.2-2.1.0DEPEND gimp-2.0.2-2.1.0 gv-3.5.8-2.1.0 DEPEND gv-3.5.8-2.1.0 kerberos-1.3.4-2.1.0UPDATE kerberos-1.3.4-2.1.1 libwmf-0.2.8.3-2.1.0DEPEND libwmf-0.2.8.3-2.1.0 mgv-3.1.5-2.1.0 DEPEND mgv-3.1.5-2.1.0 mysql-4.0.20-2.1.0 UPDATE mysql-4.0.20-2.1.1 openpkg-2.1.2-2.1.2,openpkg-20040825-20040825 UPDATE openpkg-2.1.0-2.1.0 perl-dbi-5.8.4-2.1.0UPDATE perl-dbi-5.8.4-2.1.1 perl-dbix-5.8.4-2.1.0 DEPEND perl-dbix-5.8.4-2.1.0 pgautodoc-1.23-2.1.0DEPEND pgautodoc-1.23-2.1.0 postgresql-7.4.3-2.1.1 UPDATE postgresql-7.4.3-2.1.0 pstoedit-3.33-2.1.0 DEPEND pstoedit-3.33-2.1.0 rsync-2.6.2-2.1.0 UPDATE rsync-2.6.2-2.1.1 sasl-2.1.18-2.1.0 UPDATE sasl-2.1.18-2.1.1 sudo-1.6.7p5-2.1.0 UPDATE sudo-1.6.7p5-2.1.2 vim-6.3.11-2.1.0UPDATE vim-6.3.11-2.1.1 Note that it seems to want to "update" openpkg-2.1.2 to openpkg-2.1.0, which of course is a downgrade. It also has some extra provides that includes a date, like it is from current, but it isn't. If I go ahead with this "upgrade" then check what it wants to do again, it returns the following list: ghostscript-8.14-2.1.2 UPDATE ghostscript-8.14-2.1.0 gimp-2.0.2-2.1.0DEPEND gimp-2.0.2-2.1.0 gv-3.5.8-2.1.0 DEPEND gv-3.5.8-2.1.0 kerberos-1.3.4-2.1.1UPDATE kerberos-1.3.4-2.1.0 libwmf-0.2.8.3-2.1.0DEPEND libwmf-0.2.8.3-2.1.0 mgv-3.1.5-2.1.0 DEPEND mgv-3.1.5-2.1.0 mysql-4.0.20-2.1.1 UPDATE mysql-4.0.20-2.1.0 openpkg-2.1.0-2.1.0,openpkg-20040712-20040712 UPDATE openpkg-2.1.2-2.1.2 perl-dbi-5.8.4-2.1.1DEPEND perl-dbi-5.8.4-2.1.0 perl-dbix-5.8.4-2.1.0 DEPEND perl-dbix-5.8.4-2.1.0 pgautodoc-1.23-2.1.0DEPEND pgautodoc-1.23-2.1.0 postgresql-7.4.3-2.1.0 UPDATE postgresql-7.4.3-2.1.1 pstoedit-3.33-2.1.0 DEPEND pstoedit-3.33-2.1.0 rsync-2.6.2-2.1.1 UPDATE rsync-2.6.2-2.1.0 sasl-2.1.18-2.1.1 UPDATE sasl-2.1.18-2.1.0 sudo-1.6.7p5-2.1.2 UPDATE sudo-1.6.7p5-2.1.0 vim-6.3.11-2.1.1UPDATE vim-6.3.11-2.1.0 Why would it be doing this? It seems that I'm stuck in an infinite loop. This doesn't seem to be a problem if I don't include the UPD directory, but we need to include it so that we have the security updates and other bug fixes that are applied to the source rpms under UPD. Can anybody assist me with this dilemma or point me in the right direction please? Thanks. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: Standardize %{l_prefix}/var/*/log* directories?
I don't know...I mean consistency? You may be asking for a lot
there. ;-)
Seriously though, I'd have to agree.
On Thu, 2005-01-27 at 15:13 -0800, Bill Campbell wrote:
> I would like to propose standardizing the log directories for openpkg
> packages. Some packages put the logs directly under their var/package
> directory, others under a subdirectory, generally named either log or logs.
>
> %{l_prefix}/var/apache/log
> %{l_prefix}/var/mailman/logs
> %{l_prefix}/var/postfix/log
> %{l_prefix}/var/squid/logs
> %{l_prefix}/var/zope/log
>
> I think it would nice if these were consistent.
>
> Bill
> --
> INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC
> UUCP: camco!bill PO Box 820; 6641 E. Mercer Way
> FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
> URL: http://www.celestial.com/
>
> Bagdikian's Observation:
> Trying to be a first-rate reporter on the average American
> newspaper is like trying to play Bach's "St. Matthew Passion"
> on a ukelele.
> __
> The OpenPKG Project www.openpkg.org
> User Communication List openpkg-users@openpkg.org
>
--
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
signature.asc
Description: This is a digitally signed message part
Re: Reset Ownership of Files
Cool. Yeah, the setugids options seems to do the trick. How nice of them. ;-) Thanks for pointing that out. Saved me some time. On Thu, 2005-01-20 at 00:38 +0100, Matthias Kurz wrote: > On Wed, Jan 19, 2005, David M. Fetter wrote: > > > On Thu, 2005-01-20 at 00:09 +0100, Matthias Kurz wrote: > [...] > > > Check "openpkg man rpm" for the options "--verify" (shows problems) and > > > --setugids (corrects problems). Maybe this helps. > > > > Ah, groovy. Yeah, I'm just slammed right now, so I was being lazy on > > this one. Thanks. > > I looked in a script, i wrote some time ago. I'm not sure, whether the > option "--all" (all installed packages) works with --verify and i do not > want to try it, currently :). In the script i used >openpkg rpm --setugids `rpm -qa` > >(mk) > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: Reset Ownership of Files
On Thu, 2005-01-20 at 00:09 +0100, Matthias Kurz wrote: > On Wed, Jan 19, 2005, David M. Fetter wrote: > > > So, we have a problem on of our newly built systems. It was jumpstarted > > and OpenPKG installed as part of that, but the openpkg user accounts > > (opkg, opkg-r & opkg-n) were not detected. Now all of the files are > > improperly chowned. What would the best way be to reset all of the > > permissions back to the default? I'm thinking some sort of openpkg rpm > > query that lists all of the files installed in every rpm package then > > piping that to some xargs command that chowns them right. I'm not sure > > what options from rpm would provide me the owner and group of each file > > it lists though. Anybody have any ideas? > > Hi. > > I'm not sure, whether i understand the problem. I would expect that > new accounts are created, when existing ones were not detected. Then this > would be a mapping problem > (find /prefix -user/group |xargs chown/chgrp ). > .. anyways, it's late... > Check "openpkg man rpm" for the options "--verify" (shows problems) and > --setugids (corrects problems). Maybe this helps. Ah, groovy. Yeah, I'm just slammed right now, so I was being lazy on this one. Thanks. > > >(mk) > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Reset Ownership of Files
So, we have a problem on of our newly built systems. It was jumpstarted and OpenPKG installed as part of that, but the openpkg user accounts (opkg, opkg-r & opkg-n) were not detected. Now all of the files are improperly chowned. What would the best way be to reset all of the permissions back to the default? I'm thinking some sort of openpkg rpm query that lists all of the files installed in every rpm package then piping that to some xargs command that chowns them right. I'm not sure what options from rpm would provide me the owner and group of each file it lists though. Anybody have any ideas? -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
User shell identification
There seems to be an issue where openpkg build does some automagickal identification of a users' shell, which makes sense because it then outputs the proper shell script to use to actually do the rebuilds and/or updates to software. We have come across a problem however where the identification fails to see the real shell the user is using. For instance, if a user logs into the build server as themselves and their default shell us tcsh, but they sudo exec bash, then the openpkg build tool seems to identify the user shell as tcsh. However, the actual shell in use by root is in fact bash so the output scripts are all improperly done in csh when they should be in sh. There is a work around, which of course is to do something like sudo exec tcsh, in which case the shell openpkg build detects is correct. However, I think this qualifies as a potential bug. Perhaps another way to detect the user shell is in order? Anyway, I just wanted to let you all know about this one. Not a huge issue but still a bit of a nuisance at times. Anyway, thanks for your help. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: openpkg build vs. openpkg rpm -Uhv *.rpm
On Sat, 2005-01-08 at 01:14 +0100, Michael van Elst wrote: > On Fri, Jan 07, 2005 at 03:47:10PM -0800, David M. Fetter wrote: > > > openpkg build -r http://repourl/openpkg/2.1/prod-sparc-sun-solaris2.9 -p > > sparc64 -f > > http://repourl/openpkg/2.1/prod-sparc-sun-solaris2.9/index-all.rdf -A -i > > -Dtcl::with_x11 -Dpostgresql::with_tcl tcl postgresql | bash > > Please retry without the -A option. -A selects all packages in the > repository and ignores any packages listed on the command line > (it really should exit with an error if you specify extra packages, > but it doesn't :-/). Ah. Silly me. I should've caught that one. Yes, the -D options did work by themselves. Speaking of -D not working with -A, though. I have been having another problem where the -E doesn't seem to be working with -A. We have a specific package that we always want to install last...nothing else depends on it. This package is a custom tripwire package. The idea is that we install all other binary rpms but exclude the tripwire package, then the next piece installs only the tripwire package which includes a post install that builds the initial database. This is all part of a jumpstart/kickstart process. So, I guess the question here is, should the -E option work in conjunction with the -A options? It seems to me that it should, but it doesn't seem to. Thanks for your help. > > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
openpkg rc conflicts
There seems to be an issue within openpkg somewhere within it's own rc bits. We originally found that when we would execute openpkg rc eval, we would get strange errors. We discovered through tracing the process out originally on our solaris systems and found that the openpkg rc got confused somehow and was calling the rpm package rc, which is the Plan9 shell. We resolved this problem on our own by removing and no longer installing the rc rpm. We now have found that we are having a similar confusion problem coming from openpkg rc eval on our RHEL3 linux systems. It is specifically related to linux now since we don't install the rc rpm, however RHEL3 linux using the /etc/rc system to do it's own initialization. Somehow openpkg rc is confusing it's own rc call with the /etc/rc under RHEL3 and we are having errors spawn do to this. A specific effect of this problem is that none of the services we run respond to an openpkg rc restart. To work around this problem we have been doing a stop, then a start manually. We're not quite sure how openpkg rc is getting confused with the other rc's, but perhaps openpkg rc should have some sort of hard set full path to the openpkg rc bit itself? Thus it wouldn't get confused like this? Anyway, we wanted to let you know about this one as well. Thanks. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: openpkg build vs. openpkg rpm -Uhv *.rpm
On Fri, 2005-01-07 at 22:49 +0100, Michael van Elst wrote: > On Fri, Jan 07, 2005 at 10:29:21AM -0800, David M. Fetter wrote: > > > Ok, so what you're saying basically concurs with my theory of what is > > going on. The problem though, is that we need to automate the updates, > > it would be entirely too encumbersome to manually update servers > > everytime such a conflict occurs. I'm sure you understand the dilemmas. > > Thus the -D...-D options aren't really optimal for such automation. How > > do you suggest this be resolved? > > For one thing: can you please test wether the update with manually > specified options works ? This is what I executed, except with proper urls of course... openpkg build -r http://repourl/openpkg/2.1/prod-sparc-sun-solaris2.9 -p sparc64 -f http://repourl/openpkg/2.1/prod-sparc-sun-solaris2.9/index-all.rdf -A -i -Dtcl::with_x11 -Dpostgresql::with_tcl tcl postgresql | bash This didn't work. It still resulted in the same error. Perhaps I'm trying the wrong command? > > For the other: Ralf should add the source change to -current so > that we have more people using the change. If all goes well it > can be pulled up to the release branch. > > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: openpkg build vs. openpkg rpm -Uhv *.rpm
On Fri, 2005-01-07 at 08:43 +0100, Michael van Elst wrote:
> On Thu, Jan 06, 2005 at 05:08:24PM -0800, David M. Fetter wrote:
>
> > FATAL: errors occured while building:
> > postgresql-7.4.3-2.1.0: postgresql has conflicting requirement
>
> That is a message from the build tool.
>
> > After tracing this error out, I found that it is because openpkg build
> > seems to find that tcl is installed, however it doesn't seem to realize
> > that the installed tcl isn't built with the with_x11 option
>
> It does find out but doesn't know how to proceed. There should be
> a line in the generated output like
>
> # ... has conflicting requirement option = value != new-value
>
> most likely pointing to the tcl package.
>
> The logic in depend_option() checks a dependency against an already
> installed package. If you want "tcl::with_x11=yes" and have installed
> "tcl::with_x11=no" then it is seen as a conflict.
>
> I don't know remember exactly why this is tested this way. The
> test is performed only for dependent packages and not for anything
> you ask to be built on the command line.
>
> Changing line 1599ff from
>
> $relmap = $env->{built}->{$pro->{prefix}} ||
> $env->{installed}->{$pro->{prefix}};
>
> to
>
> $relmap = $env->{built}->{$pro->{prefix}};
>
> in depend_option() restricts the test to packages in the build list
> (which is definitely necessary). But I don't see yet the implications
> of this change.
>
> You should also be able to overcome the conflict by asking for an
> upgrade of '-Dtcl::with_x11 -Dpostgresql::with_tcl tcl postgresql'.
>
> This way the update to 'tcl' is performed first, therefore it
> appears in the build list with the new option and the test against
> the requirements of postgresql succeeds.
Ok, so what you're saying basically concurs with my theory of what is
going on. The problem though, is that we need to automate the updates,
it would be entirely too encumbersome to manually update servers
everytime such a conflict occurs. I'm sure you understand the dilemmas.
Thus the -D...-D options aren't really optimal for such automation. How
do you suggest this be resolved?
>
>
> Greetings,
--
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
signature.asc
Description: This is a digitally signed message part
Re: openpkg build vs. openpkg rpm -Uhv *.rpm
On Fri, 2005-01-07 at 01:05 +0100, Michael van Elst wrote: > On Thu, Jan 06, 2005 at 03:45:49PM -0800, David M. Fetter wrote: > > > The problem we are seeing is that when we are installing or updating > > openpkg rpms on our servers, which pulls from rebuild binary rpms that > > we have in a custom repository, they often have conflicts that prevent > > them from being installed at all. > > There shouldn't be any conflicts. Can you give an example ? > Sure. A somewhat recent example of a conflict came about when we were asked by our research department to enable the with_tcl option in postgresql. Enabling this options spawned the requirement from tcl to add the with_x11 option (not sure why, but ok). We added both options and rebuilt the rpms on our build servers, then promoted the resulting binary rpms into our repository. When I go to one of our servers to update these using openpkg build, I get the following error: FATAL: errors occured while building: postgresql-7.4.3-2.1.0: postgresql has conflicting requirement After tracing this error out, I found that it is because openpkg build seems to find that tcl is installed, however it doesn't seem to realize that the installed tcl isn't built with the with_x11 option, so it doesn't update tcl before it attempts to update postgresql. If I use the -S switch option with openpkg build however, it does note that it thinks tcl and postgresql both need to be updated. > -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
openpkg build vs. openpkg rpm -Uhv *.rpm
Hello there. So, we have been doing a lot with OpenPKG and almost our entire environment is now converted to using OpenPKG as our core software. While doing this we have come across several issues or bumps in the road as it were. One of these has to do with openpkg build functionality. I was curious why openpkg build seems to be doing an 'rpm -Uhv --force' on each individual rpm, instead of all of the rpm such as if you installed them doing 'openpkg rpm -Uhv *.rpm'? The problem we are seeing is that when we are installing or updating openpkg rpms on our servers, which pulls from rebuild binary rpms that we have in a custom repository, they often have conflicts that prevent them from being installed at all. If instead the openpkg build were to do one openpkg rpm -Uhv on all of the rpms that it identifies it needs to update then these conflicts wouldn't happen. This is because rpm sees the dependencies exist on the same rpm -Uhv line and recognizes this, thus it doesn't error. Whereas when it does a --force for each individual rpm, it doesn't take note that the dependencies are actually satisfied and therefore it fails. This could be solved one of two ways as I can currently determine (I'm sure there are many other ways to solve it as well though). The openpkg build could have a --nodeps in addition to the --force for each individual rpm -Uhv command it executes. The other thing I was thinking is after the openpkg build does it's checking on build options and such to verify diffs between installed and newly indexed binaries, it could just do one openpkg rpm -Uhv --force *.rpm for all the rpms it sees that needs to be updated. Anyway, I hope this makes sense. If not let me know and I will try to show some more examples of scripts and work we have done to set everything up. Thanks. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: Package Request(s)
We made a logrotate spec file that you can use for that. I attached it.
We also attempted to include the TightVNC server portion but as Ralf had
stated it is a big pain to get it to work without all the X bits.
On Thu, 2004-12-23 at 13:59 -0800, Doug Summers wrote:
> I would like to see the following open-source packages added to OpenPKG
> (if possible, of course):
>
> OpenAFS (especially one that works with 2.6 Linux kernels)
> Logrotate (unless something similar already exists)
> TightVNC (add server version)
>
> After the holidays I'm going to be hitting up my company to dedicate
> some resources to this project. Hopefully I can convince them of
> OpenPKG's worth.
>
> Doug
> __
> The OpenPKG Projectwww.openpkg.org
> User Communication List openpkg-users@openpkg.org
>
--
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
##
## logrotate.spec -- OpenPKG RPM Specification
## Copyright (c) 2000-2004 The OpenPKG Project <http://www.openpkg.org/>
## Copyright (c) 2000-2004 Ralf S. Engelschall <[EMAIL PROTECTED]>
## Copyright (c) 2000-2004 Cable & Wireless <http://www.cw.com/>
##
## Permission to use, copy, modify, and distribute this software for
## any purpose with or without fee is hereby granted, provided that
## the above copyright notice and this permission notice appear in all
## copies.
##
## THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
## WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
## MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
## IN NO EVENT SHALL THE AUTHORS AND COPYRIGHT HOLDERS AND THEIR
## CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
## SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
## LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
## USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
## ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
## OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
## OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
## SUCH DAMAGE.
##
# package version
%define V_dist 3.7
%define V_opkg 3.7
# package information
Name: logrotate
Summary: Rotates, compresses, removes and mails system log files.
URL: http://download.fedora.redhat.com
Vendor: Redhat
Packager: Portland State
Distribution: OpenPKG
Class:EVAL
Group:System
License: GPL
Version: %{V_opkg}
Release: 20040804
# list of sources
Source:
http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPMS/logrotate-%{V_dist}.tar.gz
# build information
Prefix: %{l_prefix}
BuildRoot:%{l_buildroot}
BuildPreReq: OpenPKG, openpkg >= 2.1.0
PreReq: OpenPKG, openpkg >= 2.1.0
BuildPreReq: popt >= 1.7
AutoReq: no
AutoReqProv: no
%description
The logrotate utility is designed to simplify the administration of
log files on a system which generates a lot of log files. Logrotate
allows for the automatic rotation compression, removal and mailing of
log files. Logrotate can be set to handle a log file daily, weekly,
monthly or when the log file gets to a certain size. Normally,
logrotate runs as a daily cron job.
Install the logrotate package if you need a utility to deal with the
log files on your system.
%track
prog top = {
version = %{V_dist}
url =
http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPMS
regex = logrotate-(__VER__)\.tar\.gz
}
%prep
%setup -q -n logrotate-%{V_dist}
# Set the include and library flags to use l_prefix
%{l_shtool} subst \
-e 's;\(^CFLAGS.*\);\1 -I%{l_prefix}/include;' \
-e 's;\(^LOADLIBES =\)\(.*-lpopt.*\);\1 -L%{l_prefix}/lib \2;' \
Makefile
# Put the logrotate status file in the l_prefix var directory
%{l_shtool} subst \
-e 's;\(.*#define STATEFILE\).*;\1
"%{l_prefix}/var/logrotate/logrotate.status";' \
config.h
%build
# build program
%{l_make} %{l_mflags}
%install
rm -rf $RPM_BUILD_ROOT
# install program
%{l_shtool} mkdir -f -p -m 755 \
$RPM_BUILD_ROOT%{l_prefix}/sbin \
$RPM_BUILD_ROOT%{l_prefix}/man/man8 \
$RPM_BUILD_ROOT%{l_prefix}/var/logrotate \
$RPM_BUILD_ROOT%{l_prefix}/etc/logrotate
%{l_shtool} install -c -s -m 755 \
logrotate $RPM_BUILD_ROOT%{l_prefix}/sbin/
%{l_shtool} install -c -m 644 \
logrotate.8 $RPM_BUILD_ROOT%{l_prefix}/man/man8/
%{l_shtool} install -c -m 644 \
examples/logrotate-default
$RPM_BUILD_ROOT%{l_prefix}/etc/logrota
Ircd doesn't seem to run as non-root user
I'm trying to ircd to run as a non-root user but it doesn't seem to run
and there aren't any debugging or other error messages. I modified the
rc.ircd file to look like so:
#!/usr/local/lib/openpkg/bash /usr/local/etc/rc
##
## rc.ircd -- Run-Commands
##
%config
ircd_enable="$openpkg_rc_def"
ircd_log_prolog="true"
ircd_log_epilog="true"
ircd_log_numfiles="10"
ircd_log_minsize="1M"
ircd_log_complevel="9"
%common
ircd_pidfile="/usr/local/var/ircd/ircd.pid"
ircd_signal () {
[ -f $ircd_pidfile ] && kill -$1 `cat $ircd_pidfile`
}
%status -u daemon -o
ircd_usable="unknown"
ircd_active="no"
rcService ircd enable yes && \
ircd_signal 0 && ircd_active="yes"
echo "ircd_enable=\"$ircd_enable\""
echo "ircd_usable=\"$ircd_usable\""
echo "ircd_active=\"$ircd_active\""
%start -u daemon
rcService ircd enable yes || exit 0
rcService ircd active yes && exit 0
/usr/local/sbin/ircd -c
%stop -u daemon
rcService ircd enable yes || exit 0
rcService ircd active no && exit 0
ircd_signal TERM
sleep 2
rm -f $ircd_pidfile 2>/dev/null || true
%restart -u daemon
rcService ircd enable yes || exit 0
rcService ircd active no && exit 0
rc ircd stop start
%reload -u daemon
rcService ircd enable yes || exit 0
rcService ircd active no && exit 0
ircd_signal HUP
%daily -u daemon
rcService ircd enable yes || exit 0
# rotate logfile
shtool rotate -f \
-n ${ircd_log_numfiles} -s ${ircd_log_minsize} -d \
-z ${ircd_log_complevel} -m 644 -o daemon -g daemon \
-P "${ircd_log_prolog}" \
-E "${ircd_log_epilog} && rc ircd restart" \
/usr/local/var/ircd/ircd.log
After I execute 'openpkg rc ircd start' it states that it is starting
but it doesn't. The only thing it does is create an empty file located
at /usr/local/var/ircd/auth. Does anybody have any ideas why this might
be happening?
--
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
signature.asc
Description: This is a digitally signed message part
OpenPKG Tool Update Problem Persists
Ok, so I have a problem that seems to be able to be replicated where the update doesn't work for binary rpms on client systems. Perhaps this will help you help me out with this issue. Here it is... 1. Rebuild and install all release src rpms with only the default options on a separate build server. For the sake of consistency and the feel of a clean room type setup, do this test as root where the environment is identical on both servers. 2. Copy all of the created binary rpms into some sort of repository for client systems after which build a new index file for them. 3. On a client system of like hardware architecture and OS, install only the binary rpms created on the build server using a command like: `openpkg build -r /the/repos/path/ -p $arch -f /the/repos/path/index.rdf -A -i | sh` 4. Create a build file under root's home dir at ~/.openpkg/build which should exist on all systems with the following options: -Dtcl::with_x11=yes -Dpostgresql::with_server=yes -Dpostgresql::with_odbc=yes -Dpostgresql::with_tcl=yes -Dpostgresql::with_perl=yes The focus rpms in this example are tcl and postgresql. The tcl package requires with_x11 when you enable with_tcl for postgresql. 5. Now go back to the build server and rebuild the tcl and postgresql packages. Some problem here caused me to have to manually rebuild tcl and force install the resulting binary rpm. I received this error message when initially trying: "FATAL: errors occured while building: postgresql-7.4.3-2.1.0: postgresql has conflicting requirement" Afterward, the openpkg tools found that postgresql needed to be rebuilt with new options and did so. 6. Copy the newly rebuilt binary rpms into the repository you created previously and regenerate a new index file. 7. Go to the client system and attempt to update the system using a similar command to the one in step 3. I initially received the same error I showed in step 5 but after I force installed tcl, then it caught that postgresql had an option update and installed properly. This seems to be a consistent problem and should be able to be reproduced. The problem here is that the client update fails even though the build file does exist on all systems. I have had a similar problem with OpenSSH and GCC, though not with some other packages. It seems to only affect some rpms and not all. Can anybody help me resolve this issue because currently it is a major stopping block as the client systems aren't getting their updates automagically as they should due to this error? Thank you. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu signature.asc Description: This is a digitally signed message part
Re: Sudo + pam asking for password twice
Those pam components are OS specific, so it is outside of OpenPKG. By default, Linux generally denies while Solaris allows. What I did is install the take the sudo pam file from the native sudo command on linux and put that into place. That resolved all of the issues. On Wed, 2004-11-10 at 13:01 -0600, Aaron Bostick wrote: > Ok, I have answered my own question. > > On solaris which uses pam.conf instead of pam.d/, there was this entry: > > sudo auth required /usr/lib/security/$ISA/pam_unix.so > try_first_pass > > On linux, in pam.d, the sudo file had this: > > auth required pam_unix_auth.so shadow nodelay > > I merely appended the try_first_pass command to the end of the above > line, and the second password prompt went away. > > My next question is, since both of these entries are pam entries from > OpenPKG, why do we get try_first_pass for Solaris but not for Linux? > > Is this something that should be added to the sudo spec file or > something? > > Thanks, > Aaron > > On Wed, 2004-11-10 at 10:41, Aaron Bostick wrote: > > I thought for sure I read something about this on the list before but > > cannot seem to find it in the archives. > > > > Anyone know what the fix is to make sudo ask you for your password > > only > > once? I am assuming that sudo is asking once and then pam is asking > > again? > > > > Either way, if I type my password twice it completes successfully. > > > > I have only seen this on linux openpkg rollouts, not on solaris, but I > > have seen it on both gentoo and mandrake at this point. > > > > Thanks, > > Aaron > > __ > > The OpenPKG Projectwww.openpkg.org > > User Communication List [EMAIL PROTECTED] > > > __________ > The OpenPKG Projectwww.openpkg.org > User Communication List [EMAIL PROTECTED] > -- David M. Fetter <[EMAIL PROTECTED]> PSU signature.asc Description: This is a digitally signed message part
Re: Can openpkg realy help me
On Thu, 2004-10-28 at 07:45, Michael Schloh wrote: > > a minor reason for using openpkg is, that although our > > development-servers are completely linux-based, the production-servers > > are sometimes sun-solaris machines. > > > With only two platforms to cover, OpenPKG only has a marginal advantage > over other packaging utilities. Well, I don't know about that. It depends on how many servers you have as well. We only have Linux and Solaris in our environment but we have close to 100 servers and OpenPKG is extremely useful for us. It has cut down our maintenance cost by magnitudes already and we still haven't got it all fully automated in the fashion we want. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu "Only those who attempt the absurd can achieve the impossible." signature.asc Description: This is a digitally signed message part
Re: can openpkg realy help me
k > space is cheap, that's no critical problem, but for easy administration > of often used packages, it would help prevent some boring work. > > i'm not shure, whether i did just miss the right way to use openpkg. but > i didn't find one. > > so, what is your opinion? is it worth for me, to dig deeper into > openpkg, because there's a light at the end of the tunnel. or do i > expect things, that openpkg can't deliver (now)? There is a light at the end of the tunnel, however if you're needs are to simply have different environments for the same sort of application configuration, perhaps it would be better for you to use something like UML. Even Solaris 10 will have a UML functionality builtin. > > don't get me wrong. openpkg has an impressing concept, and i'm sure, > there are many environments, where it really solves problems. but i'm > not sure, if does it for me. > > of course i know, that openpkg is open source and lives from > get-and-give. and i would be glad to support the project on my way > getting more experienced. but if i would have to get an openpkg-pro > first, before being able to solve my basic tasks (like installing > apache2-tomcat4-mod_jk), i prefer fiddling with my old problems instead > of getting additional new ones. > > or maybe, the expected "average openpkg user" is higher qualified than > me -- i'm no experienced rpm-administrator, building easily .spec-files > and produce patches. till now it was sufficient for my job to get the > necessary packages and find the right ./configure options. > > i'm looking forward reading your replies. thanks in advance, > andi > > __ > The OpenPKG Projectwww.openpkg.org > User Communication List [EMAIL PROTECTED] -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu "Only those who attempt the absurd can achieve the impossible." signature.asc Description: This is a digitally signed message part
Re: OpenPKG Tools and Binary RPMs
On Tue, 2004-10-26 at 12:49, David M. Fetter wrote: > On Thu, 2004-10-21 at 08:45, David M. Fetter wrote: > > On Tue, 2004-10-19 at 15:44, Michael van Elst wrote: > > > On Tue, Oct 19, 2004 at 02:29:41PM -0700, David M. Fetter wrote: > > > > > > > Well, in our last example problem, the installed instance of gcc was > > > > simply a vanilla version with no additional options other than the > > > > default. However we needed the f77 option so we rebuilt the package on > > > > our build server, then placed the binary in our repository. When we > > > > went out to the client servers, the build tools didn't see that the new > > > > gcc version was compiled with this additional option or at least it > > > > didn't upgrade anything or show that it needed to be upgraded. So > > > > seemingly the build tools aren't acknowledging the changes. > > > > > > Did you tell the build tool on the client servers to use the f77 option ? > > > > Oh. I didn't realize you had to do that with the binaries. Silly me. > > Thanks. That will most likely fix my problem. > > Ok, so I added our custom ~/.openpkg/build file to all of our systems > under root's account. There is a cron job in place to go out and fetch > all updates via our local repository. However, it seems that when > executing the updates via cron, openpkg still doesn't pick up the build > options specified in the build file. We have an option change for > openssh which isn't detecting due to this. Now, if I execute this > update script manually as root it all works properly. Anybody have any > ideas as to why this might be? BTW, my script is essentially doing an openpkg build with -Ai options (along with the other mandatory ones) piping it to sh. It pulls from an url that contains local binary rpms. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu "Only those who attempt the absurd can achieve the impossible." signature.asc Description: This is a digitally signed message part
rpmmacros file
Where is the .rpmmacros file officially supposed be placed for openpkg? Or perhaps I should ask if there are more than one location for this file to be placed? I currently have a .rpmmacros file under root's account. What I just noticed is that if the system has rpm as it's native OS software management, then that rpm also picks up this .rpmmacros file and tries to use it. However, it doesn't understand some of the variables and therefore could fail. Should this .rpmmacros file go under ~/.openpkg/ instead? Can it go there now? -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu "Only those who attempt the absurd can achieve the impossible." signature.asc Description: This is a digitally signed message part
Re: OpenPKG Tools and Binary RPMs
On Thu, 2004-10-21 at 08:45, David M. Fetter wrote: > On Tue, 2004-10-19 at 15:44, Michael van Elst wrote: > > On Tue, Oct 19, 2004 at 02:29:41PM -0700, David M. Fetter wrote: > > > > > Well, in our last example problem, the installed instance of gcc was > > > simply a vanilla version with no additional options other than the > > > default. However we needed the f77 option so we rebuilt the package on > > > our build server, then placed the binary in our repository. When we > > > went out to the client servers, the build tools didn't see that the new > > > gcc version was compiled with this additional option or at least it > > > didn't upgrade anything or show that it needed to be upgraded. So > > > seemingly the build tools aren't acknowledging the changes. > > > > Did you tell the build tool on the client servers to use the f77 option ? > > Oh. I didn't realize you had to do that with the binaries. Silly me. > Thanks. That will most likely fix my problem. Ok, so I added our custom ~/.openpkg/build file to all of our systems under root's account. There is a cron job in place to go out and fetch all updates via our local repository. However, it seems that when executing the updates via cron, openpkg still doesn't pick up the build options specified in the build file. We have an option change for openssh which isn't detecting due to this. Now, if I execute this update script manually as root it all works properly. Anybody have any ideas as to why this might be? -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu "Only those who attempt the absurd can achieve the impossible." signature.asc Description: This is a digitally signed message part
Re: local binary repository
From what I've seen so far if you want to install binaries then the build options would simply be "-A" or "-A -i". On Thu, 2004-10-21 at 09:47, Aaron Bostick wrote: > Hey guys, > > I currently rsync SRC and UPD from release directories but not the BIN > directory. My plan is to put my own files in BIN. So I recently > upgraded a server and copied his binary rpms from his RPM/PKG directory > to the BIN/sparc64-solaris8/ directory on the ftp/rsync host. > > I've tried openpkg build -BuUa, -uUa, -Bu, -u, etc... but always the > output tries to rebuild from source. The best I can get is something > like this: > > if test ! -f /opkg/RPM/PKG/binutils-2.14-2.2.0.sparc64-solaris8-opk.rpm > ; then /opkg/bin/openpkg rpm --rebuild > ftp://auspmn04/release/2.2/SRC/binutils-2.14-2.2.0.src.rpm ; fi || exit > $? > > which is looking for the binary rpm local first before rebuilding. That > is fine but I thought build would curl the binary rpm down to the local > machine first and then run the above command. This I do not see > happening. > > I have tried with indexes and without with same results. I also tried > build -r -f and -r and -f by themselves. > > Also, in my 00INDEX.rdf file, the BIN rdf entry is last because my > experience is the later entries take precedence??? > > Any ideas? > > Thanks, > Aaron > __ > The OpenPKG Project www.openpkg.org > User Communication List [EMAIL PROTECTED] -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu "Only those who attempt the absurd can achieve the impossible." signature.asc Description: This is a digitally signed message part
Re: OpenPKG Tools and Binary RPMs
On Tue, 2004-10-19 at 15:44, Michael van Elst wrote: > On Tue, Oct 19, 2004 at 02:29:41PM -0700, David M. Fetter wrote: > > > Well, in our last example problem, the installed instance of gcc was > > simply a vanilla version with no additional options other than the > > default. However we needed the f77 option so we rebuilt the package on > > our build server, then placed the binary in our repository. When we > > went out to the client servers, the build tools didn't see that the new > > gcc version was compiled with this additional option or at least it > > didn't upgrade anything or show that it needed to be upgraded. So > > seemingly the build tools aren't acknowledging the changes. > > Did you tell the build tool on the client servers to use the f77 option ? Oh. I didn't realize you had to do that with the binaries. Silly me. Thanks. That will most likely fix my problem. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu "Only those who attempt the absurd can achieve the impossible." signature.asc Description: This is a digitally signed message part
Re: OpenPKG Tools and Binary RPMs
On Tue, 2004-10-19 at 13:59, Michael van Elst wrote: > On Tue, Oct 19, 2004 at 10:20:35AM -0700, David M. Fetter wrote: > > > rebuilt. However, once we deploy the newly built binary rpms into our > > repository to be pushed out to client systems the openpkg build doesn't > > acknowledge such changes. > > What do you mean with "doesn't acknowledge such changes" ? Well, in our last example problem, the installed instance of gcc was simply a vanilla version with no additional options other than the default. However we needed the f77 option so we rebuilt the package on our build server, then placed the binary in our repository. When we went out to the client servers, the build tools didn't see that the new gcc version was compiled with this additional option or at least it didn't upgrade anything or show that it needed to be upgraded. So seemingly the build tools aren't acknowledging the changes. > > If you tell the build tool to install a package that has a different > set of options than the one that is currently installed then it should > do exactly that. > > However, if the installed package satisfies the required options > then it won't be replaced unless you have a newer _version_ of it > in the repository. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu "Only those who attempt the absurd can achieve the impossible." signature.asc Description: This is a digitally signed message part
OpenPKG Tools and Binary RPMs
It seems that openpkg build doesn't recognize or handle properly rpms that have been updated only with a new option. If I'm doing a full rebuild from a source rpm then the specified options in the build file are recongized and the various package along with dependencies are rebuilt. However, once we deploy the newly built binary rpms into our repository to be pushed out to client systems the openpkg build doesn't acknowledge such changes. Is this a known bug? Does this make sense or do you need more explanation? -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu "Only those who attempt the absurd can achieve the impossible." signature.asc Description: This is a digitally signed message part
Re: DOCDIR
On Wed, 2004-10-06 at 13:03, Ralf S. Engelschall wrote:
> On Wed, Oct 06, 2004, David M. Fetter wrote:
>
> > I noticed that docs for openpkg rpms are being put under
> > "%{l_prefix}/share/%{name}". If I add a %doc section under %files it
> > puts the docs I specify under "%{l_prefix}/doc/%{name}-%{version}" as
> > would normally be done with standard rpm. Is there another way I should
> > be specifying doc files so that it puts them under the share directory
> > like everything else?
>
> Put it into %{l_prefix}/share/%{name} and then mark these files in
> %files section with a %doc prefix. That should work fine. There are a
> few OpenPKG packages which already do this successfully, although the
> %doc feature is still not really deployed in a larger scope within
> OpenPKG.
Ok. I was just defining DOCDIR to be %{l_prefix}/share up toward the
top. I mainly wanted to know if there was a cleaner solution that is
used. Sounds like this is good. Thanks.
--
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
"Only those who attempt the absurd can achieve the impossible."
signature.asc
Description: This is a digitally signed message part
