Re: RPM macro substitutions by openpkg index
On Wed, Aug 06, 2008 at 04:38:47PM -0400, steve muskiewicz wrote:
Hi,
> Question concerning the "openpkg index" command. I have a local OpenPKG
> repository that includes a couple of my own internally developed RPM
> packages. In those packages spec files, I generally make use of an RPM
> macro in the Release: tag since I am building these packages for
> different projects or OSes, ie. something like:
>
> Release: 2%{rpmdist}.20080716
The index tool just parses information from specfiles, it doesn't
know much about the inner workings of RPM and IMHO it shouldn't
recognize such implicit user options because that links the build
process tightly to the index process. There would also be the
question on how complex your .rpmmacros may become.
On the other hand, explicit options don't give such problems.
It should be easy to teach the index tool to understand an
option like -Drpmdist=.rhel for a macro definition that is
predefined for all spec-files.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
OpenPKG http://openpkg.org
User Communication List openpkg-users@openpkg.org
Re: Installing Bootstrap on AIX
On Thu, Jun 07, 2007 at 09:10:26PM +0200, Ralf S. Engelschall wrote: > On Thu, Jun 07, 2007, Doug Summers wrote: > > > Besides the "error: failed to open /etc/mtab" messages (which are no big > > deal) AIX doesn't have /etc/init.d. Can you add symlinking /etc/rc.d/init.d > > to /etc/init.d? > > So, you mean there is no /etc/init.d but a /etc/rc.d/init.d? > Ok, then we should not symlink /etc/rc.d/init.d to /etc/init.d, > but instead place _our_ stuff into just /etc/rc.d/init.d. > But where is the rc2.d dir under AIX? Can you provide me > with the output of the following command, please: > > $ ls -l /etc/init.d /etc/rc.d/init.d > $ ls -l /etc/rc?.d /etc/rc.d/rc?.d /etc/init.d/rc?.d > > I have to make sure that we correctly symlink from > the init.d dir to the rc2.d dir. In AIX you have /etc/rc.d/init.d/ /etc/rc.d/rc2.d/ /etc/rc.d/rc3.d/ /etc/rc.d/rc4.d/ /etc/rc.d/rc5.d/ /etc/rc.d/rc6.d/ /etc/rc.d/rc7.d/ /etc/rc.d/rc8.d/ /etc/rc.d/rc9.d/ all empty on a standard system. The script /etc/rc.d/rc is called by init for the specific run level and executes the S* or K* scripts in the appropriate directory for the run level. You may place your start/stop-Scripts in /etc/rc.d/init.d and place links in /etc/rc.d/rc?.d/. Greetings, -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
Re: openpkg:build:FATAL: an I/O error occured
On Thu, May 31, 2007 at 02:16:16PM +0200, Olivier Kaloudoff wrote:
> Hello list !
>
> I'm facing this error message sometimes, and don't know
> how to fix it.
The I/O error just indicates an I/O error and is independent
of the parser. It means that the build tool cannot retrieve
the index file(s) from the OpenPKG repository.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
OpenPKG http://openpkg.org
User Communication List openpkg-users@openpkg.org
Re: build file usage?
On Tue, May 15, 2007 at 03:52:15PM -0700, David M. Fetter wrote:
> -Dperl-dbi::with_dbd_mysql = yes
> -Dperl-dbi::with_dbd_pgsql = yes
> -Dperl-dbi::with_dbd_sqlite = no
I'm not sure if something was changed, but when I wrote the
build tool, there was no '=' separator needed. Please try:
-Dperl-dbi::with_dbd_mysql yes
-Dperl-dbi::with_dbd_pgsql yes
-Dperl-dbi::with_dbd_sqlite no
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
OpenPKG http://openpkg.org
User Communication List openpkg-users@openpkg.org
Re: Problem bootstrapping on Solaris 10 SPARC
On Tue, Apr 24, 2007 at 09:54:11PM +0200, Ralf S. Engelschall wrote:
> find ELF" error. Between the build and the install mainly just is
> the "strip" step, so this has to be the problem.
See
http://www.brandonhutchinson.com/cannot_find_ELF_when_installing_OpenSSH.html
for a hint that GNU strip is broken.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
OpenPKG http://openpkg.org
User Communication List openpkg-users@openpkg.org
Re: Upgrading to Latest OpenPKG-STABLE
On Fri, Oct 27, 2006 at 09:43:55PM +0200, Ralf S. Engelschall wrote: > On Fri, Oct 27, 2006, Doug Summers wrote: > > > Should I worry about this warning? > > # ATTENTION: perl-openpkg-5.8.8-2.20061018 is in LIMBO > > H sorry, I've no clue about this output from "openpkg build". > Anybody else an idea? Perhaps Michael van Elst is listening and could > tell us in more detail what this means. AFAIK from inspecting the source > of "openpkg build" this marks the current inspected package "as a target > before reverse dependencies trigger it again" during the internal > recursion. Sorry, I do not really understand whether this is a problem > or not. But to me it doesn't seem to be a problem, just a little bit > obscure processing hint. This means that the target was seen a second time while recursing through the dependency tree, so there must be a dependency cycle. The cycle could be in the index, it could also exist because of the currently installed packages that bring their own dependencies. Assuming that the cycle does not exist in the index you can remove all your packages and reinstall everything from scratch to make sure that all dependencies are followed correctly. If the cycle is in the index, this obviously won't work. Greetings, -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: Upgrade Procedure OpenPKG 2.5 to OpenPKG 2.20060622 failed
On Sun, Jul 02, 2006 at 03:33:33PM +0200, Simon J Mudd wrote:
> > Upgraded postfix to openpkg-import. Thanks.
>
> This breaks 'openpkg build -Ua' as shown below:
openpkg-import defaults to an empty package that does not
provide anything. Please try:
openpkg build -Dwith_mta=yes openpkg-import
This will provide 'MTA' and satisfy the requirement of your
other packages.
N.B. so far that is the only functionality of openpkg-import.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: Upgrade Procedure OpenPKG 2.5 to OpenPKG 2.20060622 failed
On Sun, Jul 02, 2006 at 09:26:59AM +0200, Simon J Mudd wrote:
> Regarding the MTA issue it might be nice if there were a system-mta
> package which does nothing more than provide symbolic links from
> $prefix/sbin/sendmail to the system equivalent.
AFAIK that is provided by the 'openpkg-import' package.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: Upgrade Procedure OpenPKG 2.5 to OpenPKG 2.20060622 failed
On Sat, Jul 01, 2006 at 06:54:38PM +0200, Simon J Mudd wrote:
> # now upgrade the whole OpenPKG instance, in correct
> # dependency order and by keeping all chosen build-time options.
> # $prefix/bin/openpkg build -ZaKB | sh
> FATAL: errors occured while building:
> pine-4.64L-2.20060622: pine searches a frood called 'MTA'
The man page reads:
-Z openpkg build ignores all installed packages, the script will
rebuild all selected packages from scratch. Note that this doesn't
work together with the -a option.
I guess that's -zaKB then.
The build tool doesn't guess what your preferred MTA is because
the -z option tells it to forget about installed packages and
there are multiple choices.
You have to give it a hint with -Hpostfix.
N.B. sendmail-8.13.5-2.5.1.src.rpm got lost from the UPD directory.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: LSOF on AIX 5.x
On Fri, Dec 30, 2005 at 02:10:31PM -0800, Doug Summers wrote:
> Definitely the AIX one - /usr/bin/strip is the only one on the system.
> Another note - the above problems only occur on 64-bit AIX 5.1 systems;
> 32-bit systems build just fine with xlc.
The AIX binary tools need to be told wether to work on 32bit or 64bit
binaries. The default is to work on 32bit binaries.
strip -X 32work on 32bit binaries, ignore 64bit binaries
strip -X 64work on 64bit binaries, ignore 32bit binaries
strip -X 32_64 work on either 32bit binaries or 64bit binaries
The same can be done by setting the environment variable OBJECT_MODE.
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: Install not in Distro list
On Sun, Sep 04, 2005 at 09:47:48AM +0200, Simon J Mudd wrote:
> 1. Install openpkg
> 2. install openpkg-tools dependencies (make, gcc, perl)
> 3. install openpkg-tools
One interesting part of the first openpkg-tool (which only consisted of
the build and index scripts) was that it would search for a perl
installation. Since many platforms already provide some version of perl,
this simplified bootstrapping.
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: Install not in Distro list
On Fri, Sep 02, 2005 at 10:49:10AM +0200, Herbert Schmid wrote:
> Hi Ralf,
>
> hast Du ne Ahnung, was der slapd macht, wenn die replog-angabe drin ist?
> Der schreibt nur absoluten Käsen in das replogfile und das wird
> irgendwann gigantisch groß.
Er schreibt sein Replikations-Log und der slurpd uebertraegt das
regelmaessig an weitere slapds und kuemmert sich auch ums aufraeumen.
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: syslog config (a bit off topic)
On Tue, Aug 30, 2005 at 02:51:01PM -0400, Doug Henry wrote:
> I guess I'm basically trying to figure out
> what auditing capabilities I have, and if I need more, where (if) I can get
> them. Thanks for any input.
You may look for LAus (Linux Audit-Subsystem). It comes with the
Enterprise Versions of RedHat and SuSE but is also available
for other distributions.
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: problems setting up sasl/ldap in an openpkg environment
On Sun, Aug 28, 2005 at 09:25:22PM +0200, [EMAIL PROTECTED] wrote: > Hi, > > does anybody have a hint for me concerning the setup of sasl/ldap in a > openpkg environment? Testing authentication using testsaslauthd like > auth1# /v/authback/sw/sbin/testsaslauthd -u test -p test > just returns the following line: > > 0: NO "authentication failed" > I don't see any binding request to ldap, > ldap_auth_method: bind Is saslauthd started with '-a ldap'? sasl.spec does not put it into rc.sasl. Do you really want 'ldap_auth_method: bind' ? Does your SASL application allow to use plain passwords in the mech_list ? -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: Shells Problems - FYI
On Thu, Aug 18, 2005 at 03:40:09PM -0700, Doug Summers wrote:
> FYI - none of the AIX systems I have (4.3.3 through 5.3) have libtermlib
> and I have no idea where (if even possible) to get it.
AIX knows termcap from libtermcap (but which lacks 'xterm' in
the standard distribution).
It also knows terminfo from libcurses. There is no separate
library to use terminfo.
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: openpkg build command-line question
On Sat, Aug 13, 2005 at 09:50:58AM +0200, Matthias Kurz wrote:
> On Fri, Aug 12, 2005, Doug Summers wrote:
>
> > Is it possible to pass --define switches besides with_something=yes/no?
> > I have some packages on AIX that I want to use IBM's compiler but I
> > don't know how to pass it to openpkg build. For example, I'd like to do
> > this:
> >
> > openpkg build --define="l_cc /usr/vacpp/bin/xlc_r" --define="l_cxx
> > /usr/vacpp/bin/xlC_r" gtk
>
> Not that i know. I guess you know about $HOME/.openpkg/rpmmacros and
> want to override the settings only for one package (gtk) ?
openpkg build -Duse_cc=/usr/vacpp/bin/xlc_r -Duse_cxx=/usr/vacpp/bin/xlC_r gtk
should do the trick. The use_XXX Macros are used in %{l_tool_locate xxx}
to locate several standard binaries.
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: issue building samba-3.0.14a
On Mon, Jul 25, 2005 at 07:38:11PM -0400, Lois Bennett wrote:
> The spec file for samba assumes that the default for using LDAP in
> building samba is 'no' but the samba configure has 'yes' or 'auto' as
> the default.
I always prefer an explicit setting for all cases and a comparison
against "yes". The option could have any value, so treating anything
not equal to "yes" as "no" is a bit more predictable.
%if "%{with_ldap}" == "yes"
--with-ldap=yes
%else
--with-ldap=no
%endif
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: Segmentation Fault
On Tue, May 03, 2005 at 08:33:52AM +0900, Jaewoo Lee wrote:
> $ openpkg rpm -bb apache2.buildonly.spec
You cannot just take an arbitrary spec file and expect it to build or
even build nicely.
For OpenPKG rpm you need OpenPKG-specific spec files just like you need
RedHat-specific spec files when using the RedHat rpm. You also need
the program sources and possibly some help files (default configuration,
startup scripts and the like). This is all packed together in a
source package.
The source packages for OpenPKG can be found on ftp.openpkg.org.
Packages also have dependencies, e.g. the apache2 package requires
that you have expat, libiconv and db installed. And with OpenPKG
this means: the appropriate packages from the OpenPKG collection.
Please have a look at http://www.openpkg.org/doc/handbook/openpkg.html
for the gory details of OpenPKG.
> Processing files: apache2-2.0.54-10
> Segmentation fault (core dumped)
Now that might be interesting from an academic point of view as
it looks like rpm crashed on the junk spec file you fed it (no
program should crash, ever).
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: New Dependency Problem
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, -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: New Dependency Problem
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, -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: New Dependency Problem
On Thu, Apr 28, 2005 at 09:24:43AM -0700, David M. Fetter wrote:
> > What does the index show ?
>
> openpkg-import::with_mta
> openpkg-import::with_mta_path
> openpkg-import
I still don't understand it.
Please send me the output of 'openpkg build'.
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: New Dependency Problem
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 ?
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: New Dependency Problem
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. > 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. -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: Compile Problems - OpenLDAP & Solaris 2.6
On Fri, Apr 22, 2005 at 01:20:21PM -0700, Doug Summers wrote:
> Using OpenPKG did
> give me an isolated environment that got past the problems I had in the
> past of compiling anything.
This is how it should be. The problem is that many vendor sources
contain configure scripts and Makefiles that try to "guess" what
should be built and how.
It takes quite some effort for the packagers to stop this guessing
and I am sure that many OpenPKG packages still fall short when
trying to fix the problem.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: build recommendations
On Fri, Apr 22, 2005 at 08:45:23AM +0200, Matthias Kurz wrote:
> On Thu, Apr 21, 2005, Michael van Elst wrote:
>
> > On Thu, Apr 21, 2005 at 12:13:38PM +0200, Matthias Kurz wrote:
> [...]
> > Packages in RPM/PKG are only relevant when you do not upgrade
> > but reinstall the version (with the same options or a superset of
> > the options) that was once installed.
>
> Maybe it was not with upgrade (-U) but with some other option(s). I
> observed, that packages that _should_ have been recompiled - because
> one or more prerequisites were recompiled - were not recompiled. Instead
> the binary package from RPM/PKG was reinstalled. This happened for
> installed packages where no new source packages existed. From then on
> i always used the "-u" option.
If a package is a requirement and you don't specify -U, it might be
installed from an already existing binary package in RPM/PKG. That's
what it is supposed to do as it can safely assume that you do not
tamper with the packages in RPM/PKG.
If it is a reverse requirement, i.e you install some package that
the former depends on, then it must be recompiled and anything
in RPM/PKG must be ignored.
If not then it is a bug :)
> > > But. To solve the problem of duplicate packages in the "build" part
> > > probably adds too much complexity in the wrong place. I think it would
> > > be better (easier ?) to put this functionality in the "index" part. E.g.
> > > an option -d for "delete older versions of a package".
> >
> > I do not really understand your setup. Do you compute the index
> > directly from RPM/PKG on the build host ?
>
> I have one build host for every platform/release. There the packages
> are compiled from sources, leading to binary packages under RPM/PKG. In
> this RPM/PKG i run "openpkg index" and it is mounted inside a hierarchy
> that is accessible over anonymous ftp. From there the "slave" machines
> get their binary packages.
I wouldn't do that but copy or move away the generated binary
packages.
> Whenever a new package is compiled from sources, that means, when a new
> binary package is created, the previous version of the binary package
> _remains_ in RPM/PKG. So the different versions of a binary package add
> up.
Yes. That's what rpm does :-/
> When i delete RPM/PKG completely, there is nothing left to install
> the slave hosts. When i _move_ everything from RPM/PKG to another place,
> then i just have the same problem (many versions of the binary packages)
> in this other place.
Maybe this helps:
#!/bin/sh
bin="$1"
dst="$2"
copy="$dst/"`basename "$bin"`
cp "$bin" "$copy"
name=`openpkg rpm -q --qf '%{name}' -p "$bin"`
for b in $dst/$name-*; do
if [ "$b" = "$copy" ]; then
:
else
n=`openpkg rpm -q --qf '%{name}' -p "$b"`
if [ "$n" = "$name" ]; then
rm "$b"
fi
fi
done
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: Compile Problems - OpenLDAP & Solaris 2.6
On Fri, Apr 22, 2005 at 10:27:58AM -0700, Doug Summers wrote:
> checking whether the C compiler (/openpkg/bin/cc -O2 -pipe
> -I/openpkg/include/pth -I/openpkg/include -I/openpkg/include/pth
> -L/openpkg/lib -L/openpkg/lib/pth -L/openpkg/lib) works... no
> configure: error: installation or configuration problem: C compiler
> cannot create executables.
> error: Bad exit status from /openpkg/RPM/TMP/rpm-tmp.15510 (%build)
>
> I tried switching back to the gcc I installed from sunfreeware.com but
> it did the same thing. Obviously my gcc can compile executables as none
> of the other source packages complained.
This error usually means that the configure script tries to _link_
with libraries that aren't found or that do not exists at all. You
should find a config.log file in the build directory that contains
more information.
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: build recommendations
On Thu, Apr 21, 2005 at 12:13:38PM +0200, Matthias Kurz wrote: > All packages with the same %name are the same package. All packages > except the one with the newest build date are old packages. > Removing everything from RPM/PKG is not very practical, because one > needs all (binary) packages e.g. when a new machine is installed or > when machines with older software than the build machine are upgraded. > And rebuilding everything all the time is not very elegant and quite > time-consuming. Any update (-U) will rebuild all packages involved and ignore whatever is in RPM/PKG. If the repository contains source packages this means: recompilation. If the repository contains binary packages this means: download. If a machine is newly installed there is nothing in RPM/PKG. If a machine is upgraded then it doesn't matter what is in RPM/PKG. Different versions are ignored anyway. Packages in RPM/PKG are only relevant when you do not upgrade but reinstall the version (with the same options or a superset of the options) that was once installed. > But. To solve the problem of duplicate packages in the "build" part > probably adds too much complexity in the wrong place. I think it would > be better (easier ?) to put this functionality in the "index" part. E.g. > an option -d for "delete older versions of a package". I do not really understand your setup. Do you compute the index directly from RPM/PKG on the build host ? Greetings, -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: build recommendations
On Wed, Apr 20, 2005 at 01:40:22PM +0200, Matthias Kurz wrote:
> I also recommend to use -Uua or to remove everything from $prefix/RPM/PKG
> before running "openpkg build".
-U always includes -u, the build script cannot easily check wether
a binary package in RPM/PKG was created from current sources and
thus must ignore it if an update is requested.
> It would be nice to have an option that removes all old versions of a
> package from $prefix/RPM/PKG, when a new build succeeded.
Maybe, but what is 'an old version of a package' ? I would consider
to simply delete everything from RPM/PKG.
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: Remote fetching not working properly on my system - Solaris 9 - Sparc
On Tue, Apr 19, 2005 at 08:55:07PM -0400, Etienne-Hugues Fortin wrote:
> I'm always getting this famous "cannot open ...". However, if I do a wget
> --passive-ftp or curl , everything is working fine which seems
> to eliminate any problem that could be related to firewall.
Do you use a proxy by having set the ftp_proxy environment variable?
wget and curl will honor that setting, rpm will not.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: RPM Upgrade Conflicts
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.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: openpkg build -A -U problem
On Tue, Mar 22, 2005 at 02:04:48PM -0800, David M. Fetter wrote: > > > openssl-0.9.7e-2.3.0UPDATE openssl-0.9.7e-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. The output (which is from build -s) says you already have 2.3.0 installed and the index contains the version 2.3.1. as an update. So how did you install openssl-0.9.7e-2.3.0 ? The first time a 'build -s' would return something like: openssl ADD openssl-0.9.7e-2.3.1 and a simple 'build openssl' returns something like: echo ftp://ftp.openpkg.org/release/2.3/UPD/openssl-0.9.7e-2.3.1.src.rpm /usr/local/openpkg/bin/openpkg rpm --rebuild ftp://ftp.openpkg.org/release/2.3/UPD/openssl-0.9.7e-2.3.1.src.rpm || exit $? /usr/local/openpkg/bin/openpkg rpm -Uvh /usr/local/openpkg/RPM/PKG/openssl-0.9.7e-2.3.1.ix86-netbsd2.0-ulo.rpm || exit $? echo ftp://ftp.openpkg.org/release/2.3/UPD/openssl-0.9.7e-2.3.1.src.rpm = $? > > Do you install directly from ftp.openpkg.org ? > > No, I rsync my own local copy of the src rpms This at least rules out intermittent problem with the index. BTW, what perl is used when you run the build tool ? -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: openpkg build -A -U problem
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 ? > 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. Do you install directly from ftp.openpkg.org ? Greetings, -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: OpenPKG Dependency Loop?
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,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: openpkg build vs. openpkg rpm -Uhv *.rpm
>{repository}};
}
@@ -2720,8 +2721,9 @@
=item B<-E> I
Ignore a package with the specified I. This can be used to avoid
-upgrading to a broken package in the repository. There can be multiple
-B<-E> options.
+upgrading to a broken package in the repository. If you use a
+wildcard pattern or the B<-a> or B<-A> options then I will not
+be selected. There can be multiple B<-E> options.
=item B<-H> I
@@ -2730,13 +2732,13 @@
=item B<-a>
-Select all installed packages. Do not specify a pattern list together
+Select all installed packages. You cannot specify a pattern list together
with the B<-a> option.
=item B<-A>
-Select all packages in the repository. Do not specify a pattern list together
-with the B<-A> option.
+Select all packages in the repository. You cannot specify a pattern list
+together with the B<-A> option.
=back
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: openpkg build vs. openpkg rpm -Uhv *.rpm
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 :-/).
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: openpkg build vs. openpkg rpm -Uhv *.rpm
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 ?
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.
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: openpkg build vs. openpkg rpm -Uhv *.rpm
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.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: openpkg build vs. openpkg rpm -Uhv *.rpm
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 ?
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: mysqld_safe and ulimit
On Wed, Jan 05, 2005 at 02:03:58PM +0100, Dimitri Aivaliotis wrote:
> * hardnofiles 1
> What am I missing here?
The attribute is 'nofile' without the s :)
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: mysqld_safe and ulimit
On Wed, Jan 05, 2005 at 12:25:30PM +0100, Dimitri Aivaliotis wrote: > Warning: setrlimit couldn't increase number of open files to more than > 1024 (request: 5010) MySQL can only set a 'soft limit' for the number of open files that must not be above the 'hard limit'. The 'hard limits' can be displayed with 'ulimit -Ha' and can be changed only by root with e.g. 'ulimit -H -n 1'. To get larger 'hard limits' for ordinary users you may configure these in /etc/security/limits.conf and tell PAM to use the pam_limits.so module in /etc/pam.d/. There is another system wide limit for open files. You can query it with 'cat /proc/sys/fs/file-max' and also change it with something like 'echo 12345 >/proc/sys/fs/file-max'. This must be larger than the 'hard limit' you want to set :) Greetings, -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: OPENPKG BUILD stops working
On Fri, Dec 24, 2004 at 10:15:44AM -0300, [EMAIL PROTECTED] wrote:
> I check the output from openpkg build -Ua. There it stops with:
>
> # curling index ftp://ftp.openpkg.org/release/2.2/UPD/00UPLOAD/00INDEX.rdf
> # using XML parser
>
> So I checked manual access to that last file that was DENIED.
Looks like the index is broken, it shouldn't include a 00UPLOAD
directory.
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: OPENPKG BUILD stops working
On Thu, Dec 23, 2004 at 01:25:04PM -0800, Bill Campbell wrote:
> On Thu, Dec 23, 2004, [EMAIL PROTECTED] wrote:
> >no element found at line 1, column 0, byte 0 at
> >/opkg/lib/perl/vendor_perl/5.8.5/i686-linux/XML/Parser.pm line 187
> When I see this type of thing building off our local mirrors which is on
> our anonymous ftp site, the first thing I check is to see if manual
> anonymous ftp to the site works. Most often, the user limit has been
> exceeded so the request is being refused.
The message comes from the XML parser seeing an empty input. This
happens when curl fails to download an index or, very unlikely,
if the index file has length 0.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List openpkg-users@openpkg.org
Re: Ircd doesn't seem to run as non-root user
On Fri, Dec 10, 2004 at 08:44:48AM +0100, Ralf S. Engelschall wrote: > On Thu, Dec 09, 2004, David M. Fetter wrote: > > > 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: > > [...] > > Well, AFAIK IRC uses TCP port 194 and hence the daemon > has to be started as root in order to listen to the port... IRC has an assigned port number of 194, but nobody uses it to avoid running the irc server as root. Instead almost all IRC servers use port 6667. -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: OpenPKG Tool Update Problem Persists
On Thu, Nov 18, 2004 at 02:13:48PM -0800, David M. Fetter wrote:
> 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"
There is another message in the output that tells you what
requirement did conflict.
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: can openpkg realy help me
Hi, > be possible to get source-rpm for older versions from the cvs, but is > there a guarantee, that a source-rpm of openpkg 1.2 will run in an > openpkg 2.2 instance? no. It will definitely fail, the openpkg bootstrap releases are not compatible. > second: java-web application-environments doesn't seem to be a major > focus of the openpkg-community. trying to build a really basic and > common configuration with apache2, tomcat4 and mod_jk-connector with the > current release didn't succeed. i wouldn't expect this, if more people > out there were using openpkg for this kind of stuff. Lets say, apache2 isn't the major focus :) The goal should therefore be to package the tomcat adapter for apache2. For apache1 you just install the tomcat4-adapter (which is mod_webapp and optionally mod_jk). > third: this is just a minor issue, but it seems, that the concept of > proxy-packages isn't used very much too. Indeed. Usually it creates more problems than it solves. > otherwise, maybe, since disk > space is cheap, that's no critical problem, but for easy administration > of often used packages, it would help prevent some boring work. Where do you see the boring work ? You need time to build the packages, but that's CPU time and not your time. Greetings, -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Upgrade questions
On Wed, Oct 27, 2004 at 07:09:21PM -0300, Alexander Belck wrote: > 1st) I do not understand the meaning of the word LIMBO, don't know if its > important Quote: Limbo (Late Lat. limbus) a word of Teutonic derivation, meaning literally "hem" or "border," as of a garment, or anything joined on (cf. Italian lembo or English limb). In theological usage the name is applied to (a) the temporary place or state of the souls of the just who, although purified from sin, were excluded from the beatific vision until Christ's triumphant ascension into Heaven (the "limbus patrum"); or (b) to the permanent place or state of those unbaptized children and others who, dying without grievous personal sin, are excluded from the beatific vision on account of original sin alone (the "limbus infantium" or "puerorum"). In literary usage the name is sometimes applied in a wider and more general sense to any place or state of restraint, confinement, or exclusion, and is practically equivalent to "prison" (see, e.g., Milton, "Paradise Lost," III, 495; Butler, "Hudibras," part II, canto i, and other English classics). End Quote :) > 2nd) How could I have a circular dependency ? I don't know. It is possible that neither your installed package base nor the packages in the repository have circular dependencies but the combination of both has. This can happen when the dependency structure changes. > 3) I take the risk and rebuild all packages to rel-2.2 in chroot copy >exept for some problems compiling (other issues from prev mail) >I have no ATTENTION when runing openpkg build -Ua Rebuilding from scratch is a way to avoid the scenario I described above. Greetings, -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Upgrade questions
On Wed, Oct 27, 2004 at 04:35:28PM -0300, Alexander Belck wrote: > looking to new.sh I found some ATTENCION I don't understand > > # ATTENTION: mysql-4.0.20-2.1.0 is in LIMBO > # ATTENTION: openldap-2.2.14-2.1.0 is in LIMBO > # ATTENTION: openssl-0.9.7d-2.1.0 is in LIMBO > # ATTENTION: perl-5.8.4-2.1.0 is in LIMBO > # ATTENTION: perl-ldap-5.8.4-2.1.0 is in LIMBO > # ATTENTION: perl-mail-5.8.4-2.1.0 is in LIMBO > # ATTENTION: perl-sys-5.8.4-2.1.0 is in LIMBO > # ATTENTION: perl-time-5.8.4-2.1.0 is in LIMBO > # ATTENTION: postgresql-7.4.3-2.1.0 is in LIMBO > > What does this LIMBO means ? While the build tool computes dependencies for a target it marks the target as "in LIMBO" because any reference to it is undefined until the target has been installed or updated. If you see that message then you have a circular dependency. > Should I worry about ? Maybe. Circular dependencies should be avoided because there is no deterministic path for resolving them. The result might be broken too if you link with an old library that gets updated later. Greetings, -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Openpkg build question
On Thu, Oct 21, 2004 at 07:46:33PM +0300, Georgy Goshin wrote:
> Hi,
>
> Also one question regarding usage of build command. Is there any arguments
> that will install new package with all dependences, but will not reinstall
> and rebuild any packages already installed?
A simple openpkg buildwill do that.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: OpenPKG Tools and Binary RPMs
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 ?
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: OpenPKG Tools and Binary RPMs
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" ?
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.
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: perl error in openpkg build -Ua
On Fri, Oct 15, 2004 at 02:18:17AM -0500, F. Even wrote:
> [EMAIL PROTECTED] openpkg build -Ua > update.sh
>
> no element found at line 1, column 0, byte 0 at
> /cw/lib/perl/vendor_perl/5.8.4/i386-freebsd/XML/Parser.pm line 187
The XML parser cannot decode the index, probably because you cannot
fetch it correctly (firewalls? NAT?) or because the index is defective.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: Sendmail's configuration, AMAVIS.
On Thu, Oct 14, 2004 at 08:28:31AM +0300, Georgy Goshin wrote:
> But I still need information about what is Dual MTA in sendmail's case and
> how to configure AMAVIS to work with sendmail in OpenPKG.
Dual MTA probably refers to the modern sendmail configuration where
you have two sendmail processes. One talking to the rest of the
world and one dealing with mail originating from the mailserver.
This is also the setup that OpenPKG uses.
amavisd is a "milter" for sendmail. "milter" is sendmail's "mail filter"
API.
You define a "milter" process for amavisd with the INPUT_MAIL_FILTER macro
in the sendmail.m4 file like:
INPUT_MAIL_FILTER(`milter-amavis',
`S=local:@l_prefix@/var/amavisd/amavisd.sock, F=T, T=S:10m;R:10m;E:10m')
define(`confMILTER_MACROS_ENVFROM',
confMILTER_MACROS_ENVFROM``, {b}'')dnl # supply macro {b} to helper
with a proper replacement for @l_prefix@ and then build sendmail.cf
from this.
I haven't tried it myself :-)
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: Sendmail's configuration, AMAVIS.
On Wed, Oct 13, 2004 at 09:24:41PM +0300, Georgy Goshin wrote:
> Michael,
>
> Thanks for an answer, I did it, but now it stops listening on lo, only on
> eth0's address. How to bind OpenPKG's sendmail to all interfaces?
Bind it to 0.0.0.0. This is a wildcard for all interfaces.
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: Why Mismatch?
On Mon, Sep 27, 2004 at 12:10:51PM -0700, David M. Fetter wrote: > > MISMATCH says that a package would be updated because it doesn't > > provide requested options. > > That's odd though, because when I query the package that I have > installed it does have the requested options and that package is > installed. Somewhere there must be a difference. You may check the build script (i.e. don't use -S) for what options the build tool requests for the new build. You also see in the comment section (the lines starting with #) where the build tool decides to rebuild the package because of 'parameter mismatch'. Greetings, -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Why Mismatch?
On Mon, Sep 27, 2004 at 10:22:32AM -0700, David M. Fetter wrote: > I get a "mismatch" reported on snmp but I'm not sure why. This is the > line: > > snmp-5.1.1-2.1.0MISMATCH snmp-5.1.1-2.1.0 > > For what reason would I be getting a mismatch like this? The installed > package is the one that was built, so I'm confused here. Anybody know? > Thanks. MISMATCH says that a package would be updated because it doesn't provide requested options. -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: SRC or UPD?
On Thu, Sep 23, 2004 at 03:26:03PM -0700, David M. Fetter wrote: > Is it "-e" or "-E"? Different options. -e tells the build tool even to downgrade dependent packages when that's in the repository. -E excludes packages from the calculations. > name. Therefore, if I didn't ever want to install ksh or zsh and I > prefer sendmail as my mailer daemon, I would use something like "-E ksh > -E zsh -H sendmail", right? Yes. Apparently the -E option is broken because the getopts string is broken in build.pl. It should read: my $getopts = 'R:r:f:uUaAzZP:N:E:H:iD:p:qsSXMLWKebBg'; The colon after the E was missing. -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: SRC or UPD?
On Thu, Sep 23, 2004 at 12:55:59PM -0700, David M. Fetter wrote: > > For the build tool to upgrade is to replace the installed version > > of a package with a version from the repository. > > It first determines the 'newest' version in the repository and then > > tries to install it, independent on what version you have installed. > > Well, that makes sense now. I don't understand why we would want to do > that though. A reverse dependency might require a package to be rebuilt or reinstalled, and that can only work if all packages are in the repository. In that case you don't get the downgrade problem either. Another reason is that the index is seen as the nominal set of packages for an installation (or a superset). Converging on that set makes sense if you want equal installations on multiple machines. So, the final authority is not the individual version number, but the index. :-) The only method to override this, for now, is to exclude a package from the upgrade process completely. All what I said so far is only valid for packages that you pass to the build tool as an argument. In case of dependent packages the version of the installed package should be honored unless you use the -e option. Greetings, -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: SRC or UPD?
On Thu, Sep 23, 2004 at 12:04:25PM -0700, David M. Fetter wrote:
> ...why would the openpkg build tool want to downgrade
> a piece of software from a X.Y.{1,2,...} version to a X.Y.0 version? It
> seems to me that if there is a X.Y.{1,2,...} installed then that would
> be the newest version of the package therefore it wouldn't do anything
> with it.
For the build tool to upgrade is to replace the installed version
of a package with a version from the repository.
It first determines the 'newest' version in the repository and then
tries to install it, independent on what version you have installed.
So the question is, what index do you use and what is in there ?
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: Rebuild script
On Thu, Sep 02, 2004 at 08:31:15PM -0300, Alexander Belck wrote:
> Can openpkg tool genaret a script that would rebuild all packages with same
> options on an other platform.
openpkg build -zawill do this.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: FreeRadius
On Wed, Sep 01, 2004 at 03:48:44PM -0300, Alexander Belck wrote:
> But shouldn't openpkg use libs/headers from openpkg version ?
Definitely. It should.
> Why does it seams to be mixing the underlaying OS-stuff with the OPKG ones ?
Because that's what the vendor configure scripts usually do.
One task of the OpenPKG maintainers is to hammer the configure scripts
enough that they stop doing that.
Obviously this package warrants a bigger hammer :-/
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: FreeRadius
On Wed, Sep 01, 2004 at 02:59:22PM -0300, Alexander Belck wrote:
> Could it be that building freeradius it uses the wrong ver of des.h ?
It is either using the wrong des.h or the wrong crypto library.
The names of the crypto API changed between openssl 0.9.6 and 0.9.7.
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: OpenPKG bind in chroot ?
On Thu, Aug 05, 2004 at 06:22:40PM -0300, Alexander Belck wrote:
> 3rd) What does option with_dlz enables ?
It adds the "dynamic loadable zones" patch.
See http://bind-dlz.sourceforge.net/ for details.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: help using openpkg [newbie question]
Hi everyone, On Mon, Jul 26, 2004 at 02:20:57PM -0500, Aaron Bostick wrote: > This works in 2.0. 2.1 may be a little different. You have to install > these in this order on all machines to get the 'build' tool working: > > openpkg > make > binutils > gcc > perl > openpkg-tools yes and no. The build tool uses perl, but it is not necessary to build perl manually for using the tool. It will try to use any perl it finds. With a native perl from the OS (on all Linux machines, even on Solaris nowadays) I run the bootstrap, then as the 'opkg' user I run something like: openpkg rpm -i ftp://ftp.openpkg.org/release/2.1/SRC/openpkg-tool\* openpkg rpmbuild RPM/SRC/openpkg-tools/openpkg-tools.spec openpkg rpm -U RPM/PKG/openpkg-tools* openpkg build -Ua | sh to install openpkg-tools and pull in any updates. The nice thing about this procedure is that I don't have to care about what version is available and can put those commands in a small script. The basic rpm commands like -i can use wildcards. The --rebuild command (which combines -i of the source rpm and the rpmbuild run) can't. Finally I make a ~opkg/.openpkg/build containing something like: -P /usr/pkg/bin/sudo with a reasonable configured sudo on the system :-) or else: -P -su root -c so that I can run builds as the opkg user. > If you have custom packages and need to rebuild your index then you can > cron this as well: > > 0 4 * * * /opkg/bin/openpkg index -c -r OpenPKG-2.0/Source/ -o > /mirror/release/2.0/SRC/00INDEX.rdf.bz2 -i /mirror/release/2.0/SRC/ With many source packages (such as a full release repository) you really do want to use caching using -C (and you need to have the perl DB_File module installed). > After you have your mirror setup, the build command above changes to: > > /opkg/bin/openpkg build -f ftp:// name>/release/2.0/00INDEX.rdf ntp | /bin/sh - If you regularly build from a mirror you may want to put the -f option (and/or -r option) into $HOME/.openpkg/build Greetings, -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: Ever rebuilding openpkg-2.1.0
On Sun, Jul 25, 2004 at 12:03:09AM +0200, Ralf S. Engelschall wrote: > On Sat, Jul 24, 2004, Michael van Elst wrote: > > > [..] > > One could special case the openpkg package, but I'd like to avoid this > > if possible. > > > > The following patch therefore will simply select the database entry with > > the smallest version number, i.e. OpenPKG-2.1.0-2.1.0 when deciding on > > wether it needs an update. > > [...] > > I've tested this patch. Now it works as expected for a RELEASE based > OpenPKG instances, but on a CURRENT based OpenPKG instance (really all > packages from CURRENT, no mix), it now tries there to always rebuild and > upgrade an already up-to-date "openpkg" CURRENT package. I think we have > to afford a special case here, haven't we? Thanks to your last change it doesn't happen anymore :) | revision 1.349 | date: 2004-07-24 22:10:41 +; author: rse; state: Exp; lines: +1 -2 | remove useless "Provides" for the corresponding RELEASE version Greetings, -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: ../openpkg build samba is giving an I/O error [FreeBSD 4.STABLE]
On Sat, Jul 24, 2004 at 06:31:22PM +0200, Simon J Mudd wrote:
> Hello,
>
> I'm having trouble using openpkg build on FreeBSD and am consistently
> getting an I/O error. I am not sure how to identify the problem further.
I/O error means that the build tool gets an error when reading an
index from a file or pipe.
In your case it tries to read:
ftp://ftp.openpkg.org/release/2.1/BIN/00INDEX.rdf
by issuing the command
/openpkg/lib/openpkg/curl -q -s -o -
"ftp://ftp.openpkg.org/release/2.1/BIN/00INDEX.rdf";
This works fine for me. I guess you experience some network error,
possibly related to a firewall or NAT router.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: Ever rebuilding openpkg-2.1.0
On Sat, Jul 24, 2004 at 08:00:23PM +0200, Ralf S. Engelschall wrote:
> Oh, now I understand the problem! Unfortunately the Provides for the
> CURRENT version is very important for mixing RELEASE and CURRENT and
> hence cannot be removed. So, we should tell "openpkg build" about this
> special case, I think. Do you have a quick patch at hand, Michael?
One could special case the openpkg package, but I'd like to avoid this
if possible.
The following patch therefore will simply select the database entry with
the smallest version number, i.e. OpenPKG-2.1.0-2.1.0 when deciding on
wether it needs an update.
--- build.pl.dist Sat Jul 24 21:21:50 2004
+++ build.plSat Jul 24 21:49:56 2004
@@ -1318,15 +1318,15 @@
#
# find target in map
#
-sub find_target ($$) {
-my($name, $map) = @_;
+sub find_target ($$$) {
+my($name, $map, $pos) = @_;
my($vmap) = $map->{$name};
my(@vs);
return unless $vmap;
@vs = sort { vcmp($b,$a) } keys %$vmap;
-return $vmap->{$vs[0]}->[-1];
+return $vmap->{$vs[$pos]}->[-1];
}
#
@@ -1413,7 +1413,7 @@
$conflicts = target_conflicts($target, $env);
foreach (@$conflicts) {
-my($t) = find_target($_, $map);
+my($t) = find_target($_, $map, 0);
return $t if $t;
}
return;
@@ -1741,7 +1741,7 @@
#
# see if a target is already installed and requires a rebuild
#
-if ($t = find_target($target->{name}, $env->{installed})) {
+if ($t = find_target($target->{name}, $env->{installed}, -1)) {
if (exists $env->{exclude}->{$target->{name}}) {
print "# excluding $target->{name} (no upgrade allowed)\n";
return;
@@ -2312,7 +2312,7 @@
next if $n =~ /::/;
next if exists $map{$n};
next unless grep { $_ ne '' } keys %{$repository->{$n}};
-$t = find_target($n, $repository);
+$t = find_target($n, $repository, 0);
$map{$n}->{'status'} = 'NEW';
$map{$n}->{'rel'}= vs($t);
push @names,$n;
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: Ever rebuilding openpkg-2.1.0
On Sat, Jul 24, 2004 at 08:59:01AM +0200, Ralf S. Engelschall wrote:
> That's a known bug in the "openpkg build" command (see
> http://cvs.openpkg.org/getfile/openpkg-tools/TODO for a
> list of known issues). It works fine for CURRENT, but when
> updating a RELEASE it always thinks that the "openpkg"
> package has to be recompiled.
This is caused by the openpkg package that provides an additional
current version. After installing openpkg-2.1 and the tools I get:
[EMAIL PROTECTED] openpkg rpm --provides -qa
OpenPKG
openpkg = 20040712-20040712
openpkg = 2.1.0-2.1.0
gpg(OpenPKG <[EMAIL PROTECTED]>) = 4:807593e063c4cb9f-3c591eda
gpg(63c4cb9f) = 4:807593e063c4cb9f-3c591eda
openpkg-tools = 0.8.15-2.1.0
The build tool then tries to update openpkg-20040712-20040712 to the
one described in the index.
Either the bogus version information has to be removed from
database or the build tool needs to have some idea how to
detect and handle packages that appear more than once in
the database. Note that there is no real package behind
that entry in the database, it is just a Provides: value.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: openpkg build -Ua question
On Fri, Jul 23, 2004 at 07:25:15PM -0300, Alexander Belck wrote:
> I allready needed to reenter twice the openpkg build -Ua > upgrad.sh after
> execution exited with error from previos upgrad.sh version.
>
> Each time I generate a new upgrad.sh script, the sequence is altered.
>
> Could it be that openpkg is unable to decide the apropriate order to upgrade all
> packages from an instalation ?
It is surely possible that it can't decide on the appropriate order.
- there could be a bug in the build tool.
- the dependencies might change and are invalid for the installed packages.
- there is no unique order, the result may then be somewhat random
as more than one ordering is correct.
If you run the build tool several times in a row without actually
running the script (or changing the installed packages or the index)
the result should of course be the same.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: openpkg build -Ua question
On Fri, Jul 23, 2004 at 05:55:22PM -0300, Alexander Belck wrote:
> Is this constant use of --force normal ?
The build tool will always use --force if it updates a package. This
asks rpm to do two things:
- to ignore if the package or a more recent version is already installed,
the build tool already takes care of this issue and may make
different decisisions.
- to overwrite files that may belong to different packages. Here it is
the OpenPKG developers who need to be careful that this is safe,
usually by ensuring that there are no such file conflicts between
packages.
> My poor expirience with rpm got to unstable rpm instalations when using --force.
The second point can lead to instabilities if the packages aren't
created carefully, but avoiding --force doesn't solve the problem
of broken packages :)
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: Compiling against OpenLDAP in OpenPKG - static linking problem
On Tue, Jul 20, 2004 at 01:23:24PM +0200, Stephan Buys wrote: > l/ conftest.c -lresolv -lcrypto -llber -lldap 1>&5 > /kolab/lib//libldap.a(open.o)(.text+0x198): In function `ldap_create': > : undefined reference to `ber_memcalloc_x' > /kolab/lib//libldap.a(open.o)(.text+0x1f4): In function `ldap_create': > : undefined reference to `ber_sockbuf_alloc' > /kolab/lib//libldap.a(open.o)(.text+0x228): In function `ldap_create': > : undefined reference to `ber_memfree_x' > I think the issue here is with how configure is trying to compile agains statically > linked libraries. Static libraries require a correct link order while references to dynamic libraries are sorted at run time. In this case you need to link with libldap first, i.e. -lldap -llber. Greetings, -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: using 'openpkg build' to install binary rpms
On Thu, Jul 08, 2004 at 01:40:00PM -0700, David M. Fetter wrote:
> appropriate packages are to be ADDed and some to be UPDATEd. I just
> looked at the generated install script and what I see is that everything
> is pointing to the repository except for where it wants to do the 'rpm
> -Uhv' of the package. There it's giving the path of
> /usr/local/RPM/USERS/BIN. I'm not sure why it would be doing this.
If there is a suitable binary package in ${rpmdir} it will be used
unless you use the -a,-u or -U option.
With one of these options or if there is no suitable binary package
in ${rpmdir} it will be "rebuilt".
Rebuilding the package from a source package in the repository
means to compile it with rpm --rebuild.
Rebuilding the package from a binary package in the repository
means to copy it using curl.
In either case the ready binary package (which either already
existed or has been rebuilt or has been copied) is installed
or updated from ${rpmdir}.
Use -u and you should see commands to curl the files from the
repository to ${rpmdir} and to rpm -Uvh from there.
N.B. it is unclear to me why -a triggers the same behaviour. Probably
some misguided optimization that should be removed from the build
tool.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: using 'openpkg build' to install binary rpms
On Thu, Jul 08, 2004 at 09:56:15AM -0700, David M. Fetter wrote:
> What I'm doing is generating index.rdf files under each of these
> subdirectories and one on the top level which should be picking up the
> index files in the subdirectories as I understand it.
The indexes are human readable XML. Please have a look that the index
files have been build correctly.
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: static apache + mem question
On Fri, Jun 25, 2004 at 04:34:21PM -0300, Alexander Belck wrote:
> >From my running httpd using top I got:
>
> PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
> 9169 nobody14 0 14504 9,9M 7936 S 1,7 8,2 0:14 httpd
> 8773 nobody 9 0 14164 9976 6004 S 0,0 8,1 0:11 httpd
> 9155 nobody 9 0 13992 9828 9220 S 0,0 7,9 0:10 httpd
>
> What does this means ?
> Is the size in Kb, so that my biggest httpd process is using 14Mb ?
> What means RSS (it seams confusing to me since the first says 9,9M and the
> second only 9976 about 1000 times smaler)
SIZE is the amount of virtual memory used.
RSS is the resident set size, which is some kind of average of
the real memory used.
Since both values include shared memory (i.e. the shared code and
also shared system libraries) you cannot just add up the values of
several processes to get a total. The SHARE value gives some hints
about what part is shared, but it is still not enough information.
You also see that the processes do not use the same amount of memory,
not even the same virtual memory because each did handle different
requests (and one is probably the master process).
Finally you don't see how much memory the system uses to support
these processes. In particular, the amount of memory used up
for caching files accessed by the httpd processes.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: static apache + mem question
On Fri, Jun 25, 2004 at 10:59:42AM -0300, Alexander Belck wrote:
> Do I need a hole new OpenPkg instalation with a diferent opkg_root to have
> distingt apache builds (one with_mod_php, one without) and processes ?
You need a new OpenPKG instance to get different apache builds. You
could run several Apache instances from a single OpenPKG instance if
you provide your own startup scripts and configurations, but using
multiple OpenPKG instances is easier to maintain, especially once you
want to migrate a server to a different machine.
> How many client connections can a single apache process handle (simultaneos
> browsing of one site) ?
A single process can handle only a single connection at a time. However,
most connections are very short (in particular those serving static content)
and multiple users won't notice the latency.
Note that the OS itself (the kernel) queues incoming connections, so that
a part of the client connection is already served in parallel. For static
content that effect is significant.
> I thoght that multiple apache processes could be activated if the number of
> request require it and shuted down if to many are idle.
Yes, that is done automatically. Apache starts one "master" process that
controls any number of child processes. Each child handles a single
connection.
For small servers some 4-10 processes are enough.
For big servers you may want maybe up to a few hundred processes.
A good approach for a high end server is also to split it into
various parts that serve static pages, dynamic content and large
files. Each type wants a specific apache configuration for best
performance.
> About security problems with php, are they just there for acessing sites where
> php is enabled, or only to the persons with write publishing access to the
> sites tree directory (that will mean that the ISP client has bad intensions to
> exploit the php security flaus, not any unknown guy at the web) ?
The person who can write php scripts of course has direct control over
any exploit. But often even visitors can use the same exploits because
most PHP scripts are buggy.
The point is that all customers on that server become victims, not just
the one that hosts the exploit. A single bad customer can compromise
all your customers.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: static apache + mem question
On Fri, Jun 25, 2004 at 08:51:45AM -0300, Alexander Belck wrote: Hi, > How can I avaliate the amount of memory efectivly used ? > I think that frequenly apache processes are just waiting for a connection and > will hope that in this situation the data reserved for all modules are relativly > small. They should only grow when some module is realy being used by an > webapplication and released again when the site/page is leaved. The memory is allocated once it is used and stays there until the apache process ends. You can configure the number of queries a single apache process should answer before it terminates. By default that is a few ten thousand requests. > > If your modular apache is about 300K then it doesn't load or use > > all the modules. So why build them into the static binary ? > > I just looked at the size of /usr/sbin/httpd, I do not know how to check the > efective memmory used when running, where the necessary modules will be loaded > and obviosly much more ram will be used from the system. This however is the important number. Check with 'ps' or 'top'. > Most modules are enabled, and also most time they are not used, but they are > avaible if someone whants to use them. As an ISP I could not say that I support > PHP, but do not offer lots of functions availble thru PHP. As an ISP you should not run a single Apache with mod_php for more than one customer. PHP safe mode is a myth :-) Greetings, -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: static apache + mem question
On Thu, Jun 24, 2004 at 07:29:30PM -0300, Alexander Belck wrote:
> There is realy a huge difference in size. The modular apche is about 300K, while
> the one I build in OpenPkg is about 6M. Normaly I see several instances of
> apache running (about 10 as setup in httpd.conf).
> I was wundering if using OpenPkg static version of apache will consume about 60M
> of my ram, or will it be smart enouth to share the common code and consume
> juste a bit more than 1 copy of apache ?
It will share the common code but it won't share the data which
also grows with the number of modules.
> I'm afraid that OpenPkg static aproch isn't a good aproach for an (eaven small)
> ISP, where several instances of apache with lots of possible modules will be
> needed.
Two observations:
If your modular apache is about 300K then it doesn't load or use
all the modules. So why build them into the static binary ?
Building apache with all modules is a bad idea anyway. Most things
served will be static pages, but the process serving static
pages has to carry the weight of all the modules. You should think
about a more flexible approach and use several apache instances
together, each tailored for a specific purpose. With OpenPKG you
can do this easily by creating several OpenPKG instances.
N.B. Yes, this approach wastes disk space, but it helps a lot
maintaining such an installation which is more important even
for a small ISP.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: openldap, sasl, apache chicken and egg problem (Was: Re: More problems with apache)
On Thu, Jun 24, 2004 at 08:40:47AM -0300, [EMAIL PROTECTED] wrote:
> But when I try to build apache with php_ldap (where I presume this module will
> allow php to access ldap records), it requires that OpenLDAP should be build
> with_sasl (as if necessarily to access openldap thru php it needs to
> authenticate the access using sasl) ??
Building OpenLDAP with SASL is rarely required. It creates
a hen-and-egg problem with the usage of SASL with an LDAP
backend.
openpkg build -Dwith_mod_php -Dwith_mod_php_openldap apache
should do the right thing regarding apache, php and ldap.
In particular it should require openldap without SASL support.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: Howto build with_option
On Tue, Jun 22, 2004 at 06:26:56PM -0300, Alexander Belck wrote:
> What is the sintax for `openpkg build foo` and have it use something like:
> -define "with_zlib yes" or if possible a short way like -D with_zlib
just as you say:
-Dwith_zlib
builds with
--define "with_zlib yes"
If you have options with a different value then write
-Dwith_option=value
> Is it possible to get the same options used when upgrading a package ? How ?
This is done automatically. The build tool will fetch the option
values from the installed package and build the upgrade with the
same options unless you override these on the command line.
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: src rpm rebuild options & openpkg tool
On Tue, May 11, 2004 at 09:59:53AM -0700, David M. Fetter wrote:
> We have the need to use many of the options when rebuilding the source
> rpms. I'm trying to work on getting this process mostly automated if
> not all of it. My question here is, is it possible to pass multiple
> rebuild options for multiple packages when using the openpkg index/build
> tools? If so, how? Thanks.
You can define options with
-Dpackage::option or
-Dpackage::option=value
to pass specific options to each package. You can use as many -D
options as fit on the command line.
You may also create a $HOME/.openpkg/build file with these command line
options (one per line) for convenience and to avoid the command line
length limit.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: OpenPKG build help
On Tue, May 04, 2004 at 09:20:00PM +0200, Steffen Weinreich wrote: > >>We use > >> openpkg build -r http://whatever.local.is/openpkg/release/2.0/ -p > >>ix86-debian3.0-oi > > > >Is it possible to use an anonymous ftp server or is web sever the only > >remote option? There are three kinds of remote operations: fetching an index, fetching a binary package and building from a source package. The first two operations are done by running curl, the latter is done with internal rpm functions. Currently this means you can use anonymous ftp, http and of course files on a mounted filesystem. > FTP works also, but we are not using ftp anywhere for security reasons :-) Anonymous FTP isn't more security relevant than HTTP. -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: FATAL I/O error in openpkg build
On Thu, Apr 22, 2004 at 10:37:11AM -0500, Aaron Bostick wrote:
> Any other reasons why I would get a FATAL I/O error? Am I doing something
> wrong? Should I just stick with the rpm --rebuild / -Uvh cause that is
> working for me but doesn't do the nice dep checking.
You probably have a firewall that blocks extended passive ftp transfers
(EPSV command).
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: Rebuild Apache with options
On Thu, Mar 18, 2004 at 10:06:06AM -0600, Mike's List wrote:
> Where do I get the "openpkg build" --supposedly in the tools? but I
> don't see it at ftp.openpkg.org or do I need to get it someplace else?
As others pointed out, it is a PLUS package.
openpkg build is a perl script that evaluates package dependencies
and produces a shell script of rpm commands to install or update
packages.
It probably makes your life easier with OpenPKG, but it won't fix
the %files problem you see.
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: Rebuild Apache with options
On Wed, Mar 17, 2004 at 01:05:02PM +0100, Matthias Kurz wrote:
> And it would probably better to use "openpkg build", wouldn't it ?
>
> openpkg build -Dapache::with_mod_php=yes -Dapache::with_mod_php_mysql=yes apache | sh
Sure :)
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: Rebuild Apache with options
On Wed, Mar 17, 2004 at 07:18:38AM +0100, Michael van Elst wrote:
> rpm --rebuild --define 'with_php yes' --define 'with_php_mysql yes' apache
That should have been: 'with_mod_php yes' and 'with_mod_php_mysql yes'.
To find out what options you have for a package you may query it, e.g.:
rpm -qip ftp://ftp.openpkg.org/current/SRC/apache-1.3.29-20040311.src.rpm
Name:apache Source RPM: (none)
Version: 1.3.29 Packager: The OpenPKG Project
Release: 20040311Build Host: dv1.dev.de.cw.net
Group: Web Build System: ix86-freebsd4.9
Distrib: OpenPKG Build Time: Thu Mar 11 13:27:51 2004
License: ASF Relocations: (not relocateable)
Vendor: Apache Software Foundation Install Size: 9515594 bytes
URL: http://httpd.apache.org/Install Time: (not installed)
Summary: Apache HTTP Server
Description:
The Apache Project is a collaborative software development effort
aimed at creating a robust, commercial-grade, featureful, and
freely-available source code implementation of an HTTP (Web) server.
The project is jointly managed by a group of volunteers located
around the world, using the Internet and the Web to communicate,
plan, and develop the server and its related documentation. These
volunteers are known as the Apache Group. In addition, hundreds
of users have contributed ideas, code, and documentation to the
project.
Provides:
apache::with_suexec = yes
apache::with_suexec_caller = openpkg-dev-n
apache::with_suexec_userdir = public_html
apache::with_suphp = no
apache::with_suphp_caller = openpkg-dev-n
apache::with_suphp_phpcgi = /openpkg-dev/cgi/php
apache::with_mod_ssl = no
apache::with_mod_perl = no
apache::with_mod_php = no
apache::with_mod_dav = no
apache::with_mod_layout = no
apache::with_mod_macro = no
apache::with_mod_auth_ldap = no
apache::with_mod_auth_mysql = no
apache::with_mod_auth_pam = no
apache::with_mod_gzip = no
apache::with_mod_fastcgi = no
apache::with_mod_throttle = no
apache::with_mod_access_referer = no
apache::with_mod_roaming = no
apache::with_mod_relocate = no
apache::with_mod_security = no
apache::with_mod_dosevasive = no
apache::with_mod_php_calendar = no
apache::with_mod_php_mysql = no
apache::with_mod_php_pgsql = no
apache::with_mod_php_gd = no
apache::with_mod_php_bdb = no
apache::with_mod_php_debug = no
apache::with_mod_php_pdflib = no
apache::with_mod_php_zlib = no
apache::with_mod_php_bzip2 = no
apache::with_mod_php_ssl = no
apache::with_mod_php_openldap = no
apache::with_mod_php_openldapsasl = no
apache::with_mod_php_mm = no
apache::with_mod_php_pcre = no
apache::with_mod_php_ftp = no
apache::with_mod_php_java = no
apache::with_mod_php_oci7 = no
apache::with_mod_php_oci8 = no
apache::with_mod_php_freetype = no
apache::with_mod_php_gettext = no
apache::with_mod_php_imap = no
apache::with_mod_php_xml = no
apache::with_mod_php_dom = no
apache::with_mod_php_bc = no
apache::with_mod_php_transsid = no
apache::with_mod_php_curl = no
apache::with_mod_php_mhash = no
apache::with_mod_php_wddx = no
apache::with_mod_php_gdbm = no
apache::with_mod_php_versioning = no
apache::with_mod_php_snmp = no
apache::with_mod_php_odbc = no
apache::with_mod_php_mbregex = no
apache::with_mod_php_mbstring = no
apache::with_mod_php_pear = no
apache::with_mod_php_exif = no
apache::with_mod_php_iconv = no
apache::with_mod_php_sendmail = no
apache::with_gdbm_ndbm = yes
apache::with_shared_core = no
apache::with_shared_chain = no
apache::with_debug = no
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: Rebuild Apache with options
On Tue, Mar 16, 2004 at 07:35:12PM -0800, David M. Fetter wrote:
> Do this:
>
> 1. openpkg rpm -ivh apache*src.rpm
> 2. vi %prefix/RPM/SRC/apache/apache.spec
> 3. make appropriate configure changes/additions
> 4. openpkg rpm -ba %prefix/RPM/SRC/apache/apache.spec
> 5. openpkg rpm -ivh $prefix/RPM/PKG/apache*.rpm
Not with OpenPKG.
The OpenPKG spec files have conditional support for many additions
that are activated by defining a macro. E.g.
rpm --rebuild --define 'with_php yes' --define 'with_php_mysql yes' apache
will build the apache package with both options included.
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: What is or for?
On Thu, Mar 11, 2004 at 05:57:39PM +0100, Matthias Kurz wrote: > On Thu, Mar 11, 2004, David M. Fetter wrote: > > > I looked through the online documentation but can't seem to find any > > reference as to what the or identifies. What does it mean? > > I noticed when I bootstrapped it on Solaris 8 the was , but > > then when I'm now building it on Solaris 9 the changed to . > > Why is that? Can this tag be changed or manipulated for custom rebuilt > > packages? That would be useful. Then we can keep essentially the same > > naming convention with our own modified packages but have a different > > to identify us. > The tag identifies different OpenPKG instances on the same machine and is by default computed from the prefix. E.g.: /usr/local/opkg -> ulo -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: 2.0: apache needs flex?
On Sun, Feb 29, 2004 at 12:25:50PM +0100, Birger Kraegelin wrote:
> I had similar errors on building perl-xxx packages, which silently depend on
> perl-openpkg at runtime, not at build time. So the build command doesn't
> respect the dependencies.
All the perl-xxx packages depend on perl-openpkg at runtime and at build
time.
In any case, the build tool doesn't know much about this difference. It
treats all dependencies as build dependencies (because it doesn't
matter if a package is built too early). At the end it deletes all
newly installed packages that were added to the list only because
of build dependecies.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: kerberos and OpenPKG
On Wed, Feb 18, 2004 at 10:00:22PM +0200, Stephan Buys wrote:
> But wouldn't the fact that OpenPKG uses only static linking mean that you could
> happily uninstall the Kerberos package, and sasl would still continue to work, just
> with
> some extra features enabled...
There are usually other items, like config files, that would be missing.
You would also miss updates because OpenPKG wouldn't know about Kerberos
anymore after you deinstall the package but leave a possibly working
library linked to some other package behind.
If there is a dependency then it must be made explicit (i.e. using an
option).
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: kerberos and OpenPKG
On Wed, Feb 18, 2004 at 07:26:55AM +0200, Stephan Buys wrote:
> Also, the .spec file disables Kerberos support, even though the sasl, etc. packages
> will "automatically" detect Kerberos and use it (which is usefull for sites who need
> to deploy kerberos).
Automatic detection of Kerberos would create an 'implicit' dependency
that is not reflected in the package database. That's why it is disabled.
If I remember correctly there were also some build problems that I
didn't try to solve because of lack of a working Kerberos system.
Of course you may try and have success :)
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: LDAP and SASL (chicken and egg)
On Mon, Dec 08, 2003 at 06:17:27PM -0300, [EMAIL PROTECTED] wrote: > Mainly I whant postix to be able to auth clients agains LDAP, so sasl > --with_ldap seams to be necessary. > In respect to OpenLDAP authentication, I'm not shure where it will be necessary. > To allow querys/changes to the LDAP database I use client_host_addr for querys > and self ACL for changes, so I guess I could leave OpenLDAP without_sasl That's a kind of mutual dependencies that cannot easily be resolved. opensasl --with_ldap -> use LDAP as backend for verifyfing credentials openldap --with_sasl -> authenticate with SASL for accessing LDAP If you'd specifify both, then a SASL client could request data from LDAP but before it could do so it needs to authenticate with SASL, if that's again using the LDAP method you create and infinite loop. Obviously you could think about configurations that avoid the loop, however both packages also have such a dependency at build time because each package requires libraries from the other package. However, for normal setups you don't need that. You use OpenLDAP without with_sasl but use a simpler authentication method, e.g. a shared secret, possibly with TLS when the communication between postfix and LDAP is routed over an insecure network. postfix then offers SASL to the mail clients and uses the "simpler authentication method" to communicate with LDAP. Greetings, -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: How to know about with-options ?
On Fri, Dec 05, 2003 at 10:05:15AM -0800, Bill Campbell wrote: > >And if I build a package whith a desired option (--with-ldap) when OpenPKG > >release an update would the openpkg tool be smart enouth to rebuild the new > >package with the same option ? > > Only if it's in your ~/.openpkg/build file where one can specify > everything needed by the ``openpkg'' program. 'openpkg build' will update packages with the same options that were used when installing the packages unless you explicitely override them on the command line (or in the .openpkg/build file). It is still useful to have the options saved somewhere if you need to remove a package and then install it from scratch. Greetings, -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: OpenPkg on RedHat 7.3
On Tue, Dec 02, 2003 at 06:07:15PM -0300, [EMAIL PROTECTED] wrote:
> That was my typo, but still no openpkg-tool on the ftp.
>
> All I found starting with 'o' is:
It is in the PLUS directory.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: Warning using openpkg-tool
On Thu, Oct 23, 2003 at 08:50:09PM +0200, Thomas Lotterer wrote:
> Re Michael!
> The reason for using the double inverse logic is that %{with_mta} is
> not a choice between yes/no but yes/sendmailpath/no.
Hi Thomas,
that's worse. The Parser, the Index format and the build tool
all treat conditionals as boolean.
If options are queried (and to be interpreted by the build tool)
then these options MUST be boolean and use the values 'yes' and 'no'.
I suggest to split "with_mta" into two options. One that is boolean
and that is used as a conditional in the specfile, and one that
specifies an explicit path.
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: Warning using openpkg-tool
On Thu, Oct 23, 2003 at 10:12:38AM -0400, Dennis McRitchie wrote:
Dennis,
>
> WARNING: unknown token '"%{with_mta}"':
> < #if "%{with_mta}" != "no"
> > #if "%{with_mta}" != "no"
> WARNING: unknown token '!=':
> < #if "%{with_mta}" != "no"
> > #if "%{with_mta}" != "no"
> WARNING: unknown token '"no"':
> < #if "%{with_mta}" != "no"
> > #if "%{with_mta}" != "no"
>
The specfile parser doesn't know comparisons with the != operator, in
particular that operator wasn't part of the set of allowed operators
listed in the RPM documentation when I had a look.
The parser only complains about this single case (there is another one
in the install section) because it doesn't read beyond the first section
macro, i.e. the %description section.
Since rpm supports the != operator one should fix the parser. In the
meantime you can replace this test with a query for == "yes". Testing
for a positive condition with a non-negating operator is better style
anyway, IMHO of course :)
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: Subject: [OpenPKG-SA-2003.044] OpenPKG Security Advisory (openssl)
ays that you do not want to use binary RPMs, unfortunately that also rules out binary RPMs from the index. You can call that a bug. > "rm $opkg_root/RPM/PKG/*; openpkg build ..." This should be a sufficient workaround. > (*2*) Well, "unconditionally" here means: force a rebuild of only the named > packages and also force a rebuild of all packages that depend on one > or more of the rebuilt packages. That's called 'reverse dependencies' and is handled automatically unless you turn it off with -q. You may want to turn it off if you upgrade a build tool like gcc or make. It is implicitely turned off for the openpkg bootstrap package itself, otherwise an upgrade to the bootstrap would rebuild every installed package :-) Greetings, -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: openpkg-tool -- option to build packages?
On Fri, Sep 19, 2003 at 03:18:32PM -0700, Bill Campbell wrote: > I would like to see an option to openpkg that would extract the options for > a package from the ~/.openpkg/build file, then generate the appropriate > commands to build from the SRC/package directory. I think this would be > very useful when doing modification. Now I create a build.sh file in the > SRC directory to make it easier to build, but it would be less error-prone > to do this with something like: > > openpkg build -ba packagename | sh -ba ? > > It would probably be necessary to be able do specify options such as > --nodeps as well since it's entirely possible that some requirements might > not be met yet (e.g. MTA building sudo). I wouldn't use '--nodeps' and 'less error-prone' in a single sentence :) If you think about package options (like with_mod_perl for apache) you can specifiy this now. You may also specify 'preferences' for virtual packages like MTA with -H. Greetings, -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
Re: openpkg-tool-1.2.6-1.2.6: Solaris 8 vs 9 and curl syntax
On Fri, Sep 19, 2003 at 02:54:23PM -0500, Vinod Kutty wrote:
>
> Hi,
Vinod,
> I was testing updating an openpkg 1.2 instance on Solaris 9. The RPMs were
> built on Solaris 8.
> 1. Notice that the echo statements use "solaris2.8" but the curl renames
> the output using the string 'solaris2.9'. It shouldn't break anything in
> this case, but is that intentional?
Echo and the first argument to curl specify the name of the package,
i.e. the filename/url as denoted in the index. Since the files
were built on Solaris 8 they carry solaris2.8 in their name.
The second argument to curl specifies the destination path to a local
binary RPM. This is the same path that would be used when building
the package locally from the source. Since the local RPM is configured
for solaris2.9 that's also what the filename includes.
The logic should be correct.
> 2. The curl fails. Removing "-s" reveals a "malformed " error, which
> I resolved by prepending "file://" to the pathname in the saved output
> from openpkg build. The openpkg man page says "-r" can take a directory
> path for the repository, so I'm assuming this is a bug. Is this fixed in a
> newer release ?
It's a bug and prepending file:// is the correct thing to do.
Here is an (untested) patch...
--- openpkg-build.pl.dist Fri Sep 19 23:30:11 2003
+++ openpkg-build.plFri Sep 19 23:38:20 2003
@@ -2165,7 +2165,7 @@
#
sub print_list1 ($$$) {
my($list,$c,$uncond,$with,$ignore,$usebin,$allbin) = @_;
-my($spkg,$bpkg,$ppkg);
+my($spkg,$bpkg,$ppkg,$cpkg);
my($mywith, $opt);
my($cmd1, $cmd2, $mark);
@@ -2215,7 +2215,9 @@
npriv("$RPM$opt --makeproxy $ppkg").
" )";
} elsif (defined $_->{prefix}) {
-$cmd1 = npriv("$CURL -q -s -o $bpkg $spkg");
+$cpkg = $spkg;
+$cpkg = 'file://'.$cpkg unless $cpkg =~ /^\w+:/;
+$cmd1 = npriv("$CURL -q -s -o $bpkg $cpkg");
} else {
$cmd1 = npriv("$RPM$opt --rebuild $spkg");
}
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: perl-dbi and Oracle
On Thu, Sep 11, 2003 at 01:11:14PM +0200, Steffen Weinreich wrote:
>
> Thinking this over and over again, I got the idea to include the complete
> client in an openpkg package. I'm not sure if this is a good idea but OTOS
> our colleagues haven't to thru the install process on every machine over
> and over again. Ary comments on this?
I don't know how you could embed the Oracle installation procedure
into an RPM.
Of course it is possible to tar and feather all relevenant files from
an Oracle installation and create an package from it. The critical
point is what constitutes "all relevant files" for an arbitrary
Oracle release/patchlevel.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: perl-dbi and Oracle
On Wed, Sep 10, 2003 at 11:06:38PM +0200, Steffen Weinreich wrote:
Steffen,
> build the oracle package from the cvs. But this fails since there is no
> "product" directory in the Oracle Base directory of our Oracle 9.2 Client
> directory.
here the oracle client installs under /product/920/.
The oracle meta package should detect an oracle installation correctly
if you set the ORACLE_HOME environment variable.
Greetings,
--
Michael van Elst
Internet: [EMAIL PROTECTED]
"A potential Snark may lurk in every tree."
__
The OpenPKG Projectwww.openpkg.org
User Communication List [EMAIL PROTECTED]
Re: openpkg build -U and $HOME/.openpkg/build
On Thu, Sep 04, 2003 at 12:58:03AM +0200, Matthias Kurz wrote: > > So, shouldn't "openpkg build" have assumed the -U option in any case, > given in the command line or not ? There is no difference between a -U on the command line and a -U in the .openpkg/build file. A can only guess that you already had a current version of pkg1 installed, so the first build did nothing to pkg1 and thus did not pull up any of the dependencies. When you deleted pkg1 it had to be built from scratch and this triggered checks to all dependencies including the bootstrap package. You can see the decision-making process in the output of 'openpkg build'. E.g. a # source for openpkg is openpkg-20030903-20030903 Somewhere the target 'openpkg' is touched, the heuristic decides that this refers to 'openpkg-20030903-20030903'. # make installs openpkg-20030903-20030903 for openpkg The target 'make' requires installation of the target 'openpkg' and uses the specific 'openpkg-20030903-20030903' package. # rebuilding openpkg (update) Installing target 'openpkg' requires a _rebuild_ (i.e. there is already an openpkg package installed) and the prime reason for this is that this is an update to a higher (or different) version. # adding openpkg-20030903-20030903 to list The rpm commands to build and install the openpkg-20030903-20030903 package are added to the generated script. Greetings, -- Michael van Elst Internet: [EMAIL PROTECTED] "A potential Snark may lurk in every tree." __ The OpenPKG Projectwww.openpkg.org User Communication List [EMAIL PROTECTED]
