Re: [Fink-devel] package hijacking
On May 29, 2004, at 5:01 AM, [EMAIL PROTECTED] wrote: isn't there a policy on taking over another's package? i just noticed that my rzip package was updated and maintainership was changed without so much as an email or posting to fink-devel. This make me much less inclined to create any new packages... Yes, we aren't supposed to unmaintain you unless we're certain your email is dead. It looks to me like RR just packaged it independently and didn't notice it was already there. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Patch and PatchScript ignored
Building my 1st fink packages and I cannot for the life of me get Patch or PatchScript entries to be observed. Is there any mechanism to debug this situation? If I prevent the builddir from being removed, I can apply the patch successfully, by hand. Doesn't help too much. The output of `sudo fink -v rebuild libapache-mod-midgard` does not mention any patchfiles -- it seems to be ignoring the entries in the info file completely. The .info and .patch files look like: $ cat libapache-mod-midgard.info Package: libapache-mod-midgard Version: 1.5.0 Revision: 1 Maintainer: Martin Langhoff [EMAIL PROTECTED] Conflicts: libapache-mod-midgard ( 1.5.0) Replaces: libapache-mod-midgard ( 1.5.0) Provides: libapache-mod-midgard BuildDepends: midgard-lib, libiconv-dev Depends: midgard-lib, libiconv Source:http://midgard-project.org/midcom-serveattachmentguid-80246bc255da12ebec9cde450276d20e/mod_midgard-%v.tar.bz2 Source-MD5: 5f67a4d2320cf54eaefa6b7c00fe3e69 ConfigureParams: --with-apxs=/usr/sbin/apxs --with-midgard-config=/sw/bin/midgard-config InstallScript: make install DESTDIR=%d Patch: %n.patch ##PatchScript: sed -e 's,@FINKPREFIX@,%p,g' %a/%n.patch | patch -p0 Description: Modmidgard! Homepage: http://www.midgard-project.org/ License: LGPL $ cat libapache-mod-midgard.patch diff -urN mod_midgard-1.5.0.orig/Makefile.in mod_midgard-1.5.0/Makefile.in --- mod_midgard-1.5.0.orig/Makefile.in Mon Jun 23 12:04:32 2003 +++ mod_midgard-1.5.0/Makefile.in Sun May 30 02:50:44 2004 @@ -27,9 +27,11 @@ # install the shared object file into Apache install: all - $(APXS) -i -a -n 'midgard' mod_midgard.so - $(INSTALL) -m 644 midgard-root.php3 `$(APXS) -q LIBEXECDIR` - $(INSTALL) -m 644 midgard-root.php `$(APXS) -q LIBEXECDIR` + # will be done after install # $(APXS) -i -a -n 'midgard' mod_midgard.so + echo Installing! + $(INSTALL) -m 755 mod_midgard.so$(DESTDIR)/lib + $(INSTALL) -m 644 midgard-root.php3 $(DESTDIR)`$(APXS) -q LIBEXECDIR` + $(INSTALL) -m 644 midgard-root.php $(DESTDIR)`$(APXS) -q LIBEXECDIR` # set up the httpd.conf file for Midgard use conf: thank you! martin -- -- Martin Langhoff http://nzl.com.ar/ --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Patch and PatchScript ignored
On May 29, 2004, at 11:43 PM, Martin Langhoff (NZL) wrote: Building my 1st fink packages and I cannot for the life of me get Patch or PatchScript entries to be observed. Is there any mechanism to debug this situation? If I prevent the builddir from being removed, I can apply the patch successfully, by hand. Doesn't help too much. Works fine here, with those info files. (the patch fails, though) Perhaps you have an old version of your info file there somewhere. If all else fails try putting the revision on 2 and see if 'fink update' updates it to 2. -Ben --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Busted /etc due to a fink bug?
On May 29, 2004, at 6:04 PM, Martin Langhoff (NZL) wrote: And that was the last time /etc was seen alive. After a moment of panic, I fixed it mounting the iBook as a FW device -- connected to another mac. Recreated the symlink, easy enough. However, I find distressing that I was able to do this so... effortlessly. This is not a fink bug... it is an apt/dpkg feature. However, i have in the past considered patching dpkg+apt so it will refuse to remove that symlink since it is so easy to screw yourself this way. Just haven't gotten around to it, feel free.. :) -Ben --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: dists/10.3/unstable/main/finkinfo/utils rzip.patch,NONE,1.1 rzip.info,1.1,1.2
Revert this
-Ben
On May 27, 2004, at 6:33 PM, Benjamin Reed wrote:
Update of /cvsroot/fink/dists/10.3/unstable/main/finkinfo/utils
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv2740
Modified Files:
rzip.info
Added Files:
rzip.patch
Log Message:
rzip compression program
Index: rzip.info
===
RCS file:
/cvsroot/fink/dists/10.3/unstable/main/finkinfo/utils/rzip.info,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- rzip.info 9 May 2004 17:02:11 - 1.1
+++ rzip.info 28 May 2004 01:33:47 - 1.2
@@ -1,24 +1,19 @@
Package: rzip
Version: 2.0
Revision: 1
-Description: Compression utility for large files
-License: GPL
-Maintainer: rayg [EMAIL PROTECTED]
-
-Depends: bzip2-shlibs, publib
-BuildDepends: bzip2-dev, publib
-
-Source: http://rzip.samba.org/ftp/rzip/rzip-%v.tar.gz
+Depends: bzip2-shlibs
+BuildDepends: bzip2-dev
+Source: http://%n.samba.org/ftp/%n/%n-%v.tar.gz
Source-MD5: 8a88b445afba919b122a3899d6d26b2a
-
-SetLIBS: -L%p/lib -lpub
-
-InstallScript:
- install -d -m 755 %i/bin %i/share/man/man1
- install -m 755 rzip %i/bin/
- install -m 644 rzip.1 %i/share/man/man1/
+Patch: %n.patch
+InstallScript: make install DESTDIR=%d
+Description: An extremely efficient compression program.
+DescDetail:
+rzip is a compression program, similar in functionality to gzip or
+bzip2, but able to take advantage long distance redundencies in
+files, which can sometimes allow rzip to produce much better
+compression ratios than other programs.
-
-DocFiles: COPYING
-
+License: GPL
+Maintainer: Benjamin Reed [EMAIL PROTECTED]
Homepage: http://rzip.samba.org/
--- NEW FILE: rzip.patch ---
--- rzip-2.0/main.c Wed Feb 11 19:01:08 2004
+++ rzip-2.0-new/main.c Thu May 27 21:24:39 2004
@@ -118,7 +118,24 @@
fchown(fd_out, st.st_uid, st.st_gid);
}
-
+static void*
+strndup (const char *src, size_t n)
+{
+ size_t i;
+ char *dst;
+
+ if (src == NULL)
+ return NULL;
+
+ dst = (char*) malloc (n + 1);
+ if (dst != NULL) {
+ for (i = 0; i n src[i]; i++)
+ dst[i] = src[i];
+ dst[i] = '\0';
+ }
+
+ return dst;
+}
/*
decompress one file from the command line
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle
10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click
___
Fink-commits mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-commits
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: [Fink-users] Upgrading to 10.3.4 and emacs21
On May 28, 2004, at 7:52 AM, David R. Morrison wrote: but this principle has always been more a pious wish than reality. Could you explain in more detail what you mean? I think it's a pretty accurate comment. It has been stated goal of fink to make sure that fink packages always compile the same everywhere, but we've never had adequate QA tools to make sure this was happening. We should have something soon which allows users to submit their builds of a package so we can compare them... see my exp dir and http://www.opendarwin.org/~benh57/fink/pdb/package.php/apt as the demo site. It does not have a UI for comparing and showing multiple builds of package contents, but it that is planned. -Ben --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: Checking MacOSX version number
On May 28, 2004, at 5:23 AM, Charles Lepple wrote: Sébastien Maret wrote: I'm working on a package that compiles and runs only on MacOSX10.3.4, because of a libm bug in previous versions. How can I check in my package the version of MacOSX before compiling ? actually, I guess you would need both Depends and BuildDepends to make sure that people don't install a pre-build binary on older versions. Just Depends.. Depends implies BuildDepends (currently) -Ben --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149alloc_id66op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Checking MacOSX version number
Le 30 mai 04, à 10:56, Ben Hines a écrit : On May 28, 2004, at 1:40 AM, Sébastien Maret wrote: I'm working on a package that compiles and runs only on MacOSX10.3.4, because of a libm bug in previous versions. There is no such thing as libm on any OS X. libm is just a symlink to libSystem, the standard system library. What bug are you referring to? From the REAME file of Yorick, the package I'm working on: Apple shipped MacOS X 10.3 (Panther) with a bug in the system math library libm (part of /usr/lib/LibSystem.dylib) which can cause the functions sqrt, sinh, tanh, asinh, acosh, and atanh to malfunction, when floating point exceptions are unmasked. Yorick is one of the few (perhaps the only) code which unmasks SIGFPE, so that the CPU will actually generate SIGFPE signals. Yorick does not use asinh, acosh, or atanh. For tanh, the buggy system library causes SIGFPE for any argument, e.g.- tanh(2). For sqrt, the situation is more complicated: The system library calls the hardware fsqrt instruction for CPUs which have it, which gives correct results, but for CPUs which do not have the fsqrt instruction, the system library calls a buggy software sqrt, which causes SIGFPE for any argument, e.g.- sqrt(2). Thus, yorick's sqrt works on G5 machines, but fails on G4 machines and earlier architectures. (In fact, yorick will not even start on a G4 under MacOS 10.3, since there are a couple of sqrt calls in the startup code.) Apple introduced the bug with 10.3.0, and it is present in 10.3.1 and 10.3.2, and likely will be present in 10.3.3. Darwin developers know of this problem, and agree that it is a bug in Libm-47. There is a chance it will be corrected by 10.3.4. It seems to be corrected in 10.3.4. Sébastien -- Sébastien Maret Laboratoire d'Astrophysique de Grenoble BP 53 38041 Grenoble cedex 9 France Tel: +33 (0) 4 76 63 55 19 Fax: +33 (0) 4 76 44 88 21 [EMAIL PROTECTED] --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149alloc_id66op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] validating BuildDependsOnly
Dear Fink developers,
For some time, I've wanted to have a way to validate that packages are
using the BuildDependsOnly field correctly. The test I want to employ
is this: if the package installs anything into /sw/include, it should
be declaring BuildDependsOnly to be true. (This doesn't guarantee that
the dylib symlinks have been put into the correct place, but it does
guard against someone overlooking the need to declare BuildDependsOnly
in a -dev splitoff.)
Now this is a bit tricky: we need to do the validation on the .deb file
in order to see if anything was installed into /sw/include, but the
BuildDependsOnly declaration is in the .info file. And there is no way
to track which .info file was used to create a .deb file.
One thing we might do is to gzip the .info file and put it into the .deb.
That seems like overkill for the moment, so I propose a different strategy.
For each package, at build time I'll touch one of the following two files
(after creating the appropriate directory):
/sw/share/BuildDependsOnly/true/%n
or
/sw/share/BuildDependsOnly/false/%n
It's then pretty easy to do the validation just by examining the contents
of the .deb.
There is a drawback: when we implement this, any .deb's built after the
change will be different than .deb's built before the change. On the
other hand, I've written the validation code so that it won't complain
about older .deb's, so this shouldn't really be a problem.
Any comments? Is this too quick-and-dirty? (The alternative would be
to do something like store %n.info.gz in the .deb file, accessible via
ar, but as I said above, that strikes me as overkill at the moment.)
-- Dave
P.S. Here's a possible implementation:
--- PkgVersion.pm.orig Sat May 8 13:40:32 2004
+++ PkgVersion.pm Sun May 30 10:34:30 2004
@@ -1843,6 +1843,16 @@
}
}
+ # generate commands to record the BuildDependsOnly status
+ $install_script .= \n/usr/bin/install -d -m 755 %i/share/BuildDependsOnly;
+ if ($self-param_boolean(BuildDependsOnly)) {
+ $install_script .= \n/usr/bin/install -d -m 755
%i/share/BuildDependsOnly/true;
+ $install_script .= \n/usr/bin/touch
%i/share/BuildDependsOnly/true/%n;
+ } else {
+ $install_script .= \n/usr/bin/install -d -m 755
%i/share/BuildDependsOnly/false;
+ $install_script .= \n/usr/bin/touch
%i/share/BuildDependsOnly/false/%n;
+ }
+
$install_script .= \n/bin/rm -f %i/info/dir %i/info/dir.old %i/share/info/dir
%i/share/info/dir.old;
### install
--- Validation.pm.orig Tue Apr 27 17:51:56 2004
+++ Validation.pm Sun May 30 11:15:07 2004
@@ -696,6 +696,8 @@
# - installation of .elc files
# - (it's now OK to install files directly into
#/sw/share/emacs/site-lisp, so we no longer check for this)
+# - BuildDependsOnly: if package stores files in /sw/include, it should
+# declare BuildDependsOnly true
# - ideas?
#
sub validate_dpkg_file {
@@ -708,6 +710,8 @@
my ($pid, $bad_dir);
my $filename;
my $looks_good = 1;
+ my $BDO_false = 0;
+ my $installed_headers = 0;
print Validating .deb file $dpkg_filename...\n;
@@ -734,6 +738,10 @@
($dpkg_filename =~ /xemacs/ {
$looks_good = 0;
print Warning: Compiled .elc file installed. Package
should install .el files, and provide a
/sw/lib/emacsen-common/packages/install/package script that byte compiles them for
each installed Emacs flavour.\n Offending file: $1\n;
+ } elsif ( $filename =~/^$basepath\/include/ ) {
+ $installed_headers = 1;
+ } elsif ( $filename
=~/^$basepath\/share\/BuildDependsOnly\/false/ ) {
+ $BDO_false = 1;
} else {
foreach $bad_dir (@bad_dirs) {
# Directory from this list are not allowed to
exist in the .deb.
@@ -750,6 +758,10 @@
}
close(DPKG_CONTENTS) or die Error on close: $!\n;
+ if ($installed_headers and $BDO_false) {
+ print Warning: Headers installed in $basepath/include but package
does not declare BuildDependsOnly to be true\n;
+ }
+
if ($looks_good and Fink::Config::verbosity_level() == 3) {
print Package looks good!\n;
}
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] validating BuildDependsOnly
Actually, I like the idea of including the .info in the .deb. It seems
more future-proof than a one-time hack like making a BuildDependsOnly
dir. Having the .info would make it possibly to do a lot more
validation on the .deb than before (e.g. did all of the Files: entries
make it into the splitoff .deb). It would also make it straightforward
to be able to rebuild a .deb later even if the original .info file has
gone missing.
Chris
On Sunday, May 30, 2004, at 10:33 AM, David R. Morrison wrote:
Dear Fink developers,
For some time, I've wanted to have a way to validate that packages are
using the BuildDependsOnly field correctly. The test I want to employ
is this: if the package installs anything into /sw/include, it should
be declaring BuildDependsOnly to be true. (This doesn't guarantee that
the dylib symlinks have been put into the correct place, but it does
guard against someone overlooking the need to declare BuildDependsOnly
in a -dev splitoff.)
Now this is a bit tricky: we need to do the validation on the .deb file
in order to see if anything was installed into /sw/include, but the
BuildDependsOnly declaration is in the .info file. And there is no way
to track which .info file was used to create a .deb file.
One thing we might do is to gzip the .info file and put it into the
.deb.
That seems like overkill for the moment, so I propose a different
strategy.
For each package, at build time I'll touch one of the following two
files
(after creating the appropriate directory):
/sw/share/BuildDependsOnly/true/%n
or
/sw/share/BuildDependsOnly/false/%n
It's then pretty easy to do the validation just by examining the
contents
of the .deb.
There is a drawback: when we implement this, any .deb's built after the
change will be different than .deb's built before the change. On the
other hand, I've written the validation code so that it won't complain
about older .deb's, so this shouldn't really be a problem.
Any comments? Is this too quick-and-dirty? (The alternative would be
to do something like store %n.info.gz in the .deb file, accessible via
ar, but as I said above, that strikes me as overkill at the moment.)
-- Dave
P.S. Here's a possible implementation:
--- PkgVersion.pm.orig Sat May 8 13:40:32 2004
+++ PkgVersion.pm Sun May 30 10:34:30 2004
@@ -1843,6 +1843,16 @@
}
}
+ # generate commands to record the BuildDependsOnly status
+ $install_script .= \n/usr/bin/install -d -m 755
%i/share/BuildDependsOnly;
+ if ($self-param_boolean(BuildDependsOnly)) {
+ $install_script .= \n/usr/bin/install -d -m 755
%i/share/BuildDependsOnly/true;
+ $install_script .= \n/usr/bin/touch
%i/share/BuildDependsOnly/true/%n;
+ } else {
+ $install_script .= \n/usr/bin/install -d -m 755
%i/share/BuildDependsOnly/false;
+ $install_script .= \n/usr/bin/touch
%i/share/BuildDependsOnly/false/%n;
+ }
+
$install_script .= \n/bin/rm -f %i/info/dir %i/info/dir.old
%i/share/info/dir %i/share/info/dir.old;
### install
--- Validation.pm.orig Tue Apr 27 17:51:56 2004
+++ Validation.pm Sun May 30 11:15:07 2004
@@ -696,6 +696,8 @@
# - installation of .elc files
# - (it's now OK to install files directly into
#/sw/share/emacs/site-lisp, so we no longer check for this)
+# - BuildDependsOnly: if package stores files in /sw/include, it
should
+# declare BuildDependsOnly true
# - ideas?
#
sub validate_dpkg_file {
@@ -708,6 +710,8 @@
my ($pid, $bad_dir);
my $filename;
my $looks_good = 1;
+ my $BDO_false = 0;
+ my $installed_headers = 0;
print Validating .deb file $dpkg_filename...\n;
@@ -734,6 +738,10 @@
($dpkg_filename =~ /xemacs/ {
$looks_good = 0;
print Warning: Compiled .elc file installed. Package should
install .el files, and provide a
/sw/lib/emacsen-common/packages/install/package script that byte
compiles them for each installed Emacs flavour.\n Offending file:
$1\n;
+ } elsif ( $filename =~/^$basepath\/include/ ) {
+$installed_headers = 1;
+ } elsif ( $filename =~/^$basepath\/share\/BuildDependsOnly\/false/
) {
+$BDO_false = 1;
} else {
foreach $bad_dir (@bad_dirs) {
# Directory from this list are not allowed to exist in the .deb.
@@ -750,6 +758,10 @@
}
close(DPKG_CONTENTS) or die Error on close: $!\n;
+ if ($installed_headers and $BDO_false) {
+ print Warning: Headers installed in $basepath/include but package
does not declare BuildDependsOnly to be true\n;
+ }
+
if ($looks_good and Fink::Config::verbosity_level() == 3) {
print Package looks good!\n;
}
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle
10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click
___
Fink-devel mailing list
[EMAIL PROTECTED]
[Fink-devel] BuildDependsOnly is a bad idea?
I guess BuildDependsOnly flag is intended to improve scalability, but I think it is a bad idea. The problem is library-to-library dependency. For example, every applications depending on gtk+2 must also depend on atk1, glib2-dev, pango1-xft2-dev, gettext-dev and libiconv-dev. This is major source of error. When Todai Fink Team runned a script like this in April: for pkg in all-nonvirtual-packages; do if $pkg is not built; then fink remove all-of-non-essential-packages fink -y build $pkg fi done we found many many packages (for example Apache2) could not be built because something (for example libiconv-dev) is missing in BuildDepends. Such a error would not have happened if gtk+2-dev had depended on pango1-xft and glib2-dev, glib2-dev had depended on gettext-dev, and gettext-dev had depended on libiconv-dev. Moreover, if library A started using another library B, everything depending on A would need to start BuildDepending on B-dev. This is very annoying. I suggest to get rid of BuildDependsOnly and let A-dev depend on B-dev. Or am I overlokking some negative side effect? --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] BuildDependsOnly is a bad idea?
The reason for the BuildDependsOnly flag is to make it possible to upgrade a library in the future, if the upgrade is not binary-backwards-compatible. An example is the neon package. Currently we are using neon24, but in the recent past we used neon23 (and many earlier ones). If you have neon24 installed and link with -lneon, you will be linked to the v. 24 of the neon lib because of a symlink from libneon.dylib to libneon.24.dylib. On the other hand, if you have neon23 installed and link with -lneon you get v. 23 because of a symlink in that package from libneon.dylib to libneon.23.dylib. For this reason, you have to be able to remove neon24 and replace it with neon23, or vice versa. BUT, if other things are allowed to depend on this package, then the removal will not be possible: you can only remove something using fink (or dpkg) if nothing else depends on it. However, I agree that the problem you raise is a serious one. I have another proposal which will help to address it: a new field called InheritedBuildDepends. If you put something in InheritedBuildDepends for package foo, then whenever something BuildDepends on foo, fink will make sure that all of the other InheritedBuildDepends packages are installed at build-time, also. Once this is implemented, it should make it much easier to maintain all of the builddepends fields. -- Dave --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] validating BuildDependsOnly
It would also make it straightforward to be able to rebuild a .deb later even if the original .info file has gone missing. Well, almost. The problem is, you also need the correct version of the .patch file to rebuild the .deb. And .patch files can get very large, so I'm pretty sure we *don't* want to store those in the .deb (even in compressed form). -- Dave --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Checking MacOSX version number
On May 30, 2004, at 2:08 AM, Sébastien Maret wrote: Le 30 mai 04, à 10:56, Ben Hines a écrit : On May 28, 2004, at 1:40 AM, Sébastien Maret wrote: I'm working on a package that compiles and runs only on MacOSX10.3.4, because of a libm bug in previous versions. There is no such thing as libm on any OS X. libm is just a symlink to libSystem, the standard system library. What bug are you referring to? From the REAME file of Yorick, the package I'm working on: yorick already has a fink maintainer, david munro.. it wasn't moved to the 10.3 tree since it didn't work. Since it does now, it can just be updated. See: http://fink.sourceforge.net/pdb/package.php/yorick -Ben --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149alloc_id66op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Checking MacOSX version number
yorick already has a fink maintainer, david munro.. it wasn't moved to the 10.3 tree since it didn't work. Since it does now, it can just be updated. See: http://fink.sourceforge.net/pdb/package.php/yorick David Munroe stopped to maintain this package for some time. I submitted one month ago a new version for 10.3, which is still under validation. See: http://sourceforge.net/tracker/index.php? func=detailaid=943986group_id=17203atid=414256 Sébastien --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149alloc_id66op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Checking MacOSX version number
From http://sourceforge.net/tracker/index.php?func=detailaid=943986group_id=172 03atid=414256 I added darwin (= 7.4.0) in the Build field. On 5/28/04 1:40 AM, Sébastien Maret [EMAIL PROTECTED] wrote: I'm working on a package that compiles and runs only on MacOSX10.3.4, because of a libm bug in previous versions. How can I check in my package the version of MacOSX before compiling ? Sébastien --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149alloc_id66op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149alloc_id66op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] librep-0.16.2-11
gcc -c -DHAVE_CONFIG_H -I. -I../src -I.. -no-cpp-precomp -I/sw/include -g -O0 unix_dl.c -fno-common -DPIC -o unix_dl.lo unix_dl.c: In function `rep_open_dl_library': unix_dl.c:328: warning: assignment discards qualifiers from pointer target type unix_dl.c: In function `rep_find_c_symbol': unix_dl.c:466: error: `Dl_info' undeclared (first use in this function) unix_dl.c:466: error: (Each undeclared identifier is reported only once unix_dl.c:466: error: for each function it appears in.) unix_dl.c:466: error: parse error before info unix_dl.c:467: error: `info' undeclared (first use in this function) make[1]: *** [unix_dl.lo] Error 1 make: *** [all] Error 1 ### execution of make failed, exit code 2 Failed: compiling librep-0.16.2-11 failed -- Package manager version: 0.19.2 Distribution version: 0.7.0 Mac OS X version: 10.3.4 December 2001 Developer Tools gcc version: 3.3 make version: 3.79 Feedback Courtesy of FinkCommander
[Fink-devel] librep-0.14-28
Hey, I got the following error when trying to install gnome bundle, so I tried librep by itself and still no such luck. The same error comes up each time: unix_dl.c: In function `rep_open_dl_library': unix_dl.c:328: warning: assignment discards qualifiers from pointer target type unix_dl.c: In function `rep_find_c_symbol': unix_dl.c:466: error: `Dl_info' undeclared (first use in this function) unix_dl.c:466: error: (Each undeclared identifier is reported only once unix_dl.c:466: error: for each function it appears in.) unix_dl.c:466: error: parse error before info unix_dl.c:467: error: `info' undeclared (first use in this function) make[1]: *** [unix_dl.lo] Error 1 make: *** [all] Error 1 ### execution of failed, exit code 2 Failed: compiling librep-0.14-28 failed Thanks, Michael -- Package manager version: 0.18.4 Distribution version: 0.7.0 Mac OS X version: 10.3.4 December 2001 Developer Tools gcc version: 3.3 make version: 3.79 Feedback Courtesy of FinkCommander
Re: [Fink-devel] librep-0.14-28
FAQ 6.16 http://fink.sourceforge.net/faq/comp-general.php?phpLang=en#dlfcn-from-oo Peter Michael wrote: Hey, I got the following error when trying to install gnome bundle, so I tried librep by itself and still no such luck. The same error comes up each time: unix_dl.c: In function `rep_open_dl_library': unix_dl.c:328: warning: assignment discards qualifiers from pointer target type unix_dl.c: In function `rep_find_c_symbol': unix_dl.c:466: error: `Dl_info' undeclared (first use in this function) unix_dl.c:466: error: (Each undeclared identifier is reported only once unix_dl.c:466: error: for each function it appears in.) unix_dl.c:466: error: parse error before info unix_dl.c:467: error: `info' undeclared (first use in this function) make[1]: *** [unix_dl.lo] Error 1 make: *** [all] Error 1 ### execution of failed, exit code 2 Failed: compiling librep-0.14-28 failed Thanks, Michael -- Package manager version: 0.18.4 Distribution version: 0.7.0 Mac OS X version: 10.3.4 December 2001 Developer Tools gcc version: 3.3 make version: 3.79 Feedback Courtesy of FinkCommander -- Peter O'Gorman - http://www.pogma.com --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] librep-0.16.2-11
Amgine wrote: unix_dl.c:466: error: `Dl_info' undeclared (first use in this function) FAQ#6.16 I get build errors involving `Dl_info'. http://fink.sourceforge.net/faq/comp-general.php?#dlfcn-from-oo -- Martin --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
