Re: [Fink-devel] Gettext stable-unstable switching on 10.4 tree

2006-02-27 Thread David R. Morrison


On Feb 25, 2006, at 2:16 PM, Dave Vasilevsky wrote:



On Feb 25, 2006, at 4:07 PM, David R. Morrison wrote:
So its only because we don't have a deb for (old) gettext-tools?   
If I built the old gettext-tools first it would be OK?


Gah, I've been getting things wrong. Lemme see if I can get this  
straight. We have these packages in stable:


gettext (-bin -dev -tools) 0.10.40-19

And in unstable:

gettext (-dev) 0.10.40-24
libgettext3-shlibs (-dev gettext-bin gettext-doc) 0.14.5-1
gettext-tools (libgettextpo2-dev libgettextpo2-shlibs) 0.14.5-3

The problem occurs on the upgrade from gettext 0.10.x in stable to  
gettext 0.10.x in unstable, right? I was getting this mixed up  
before, so you can neglect my last mail.


Correct.




What we need then is to ensure that the old gettext-bin/tools are  
no longer installed at the time when the new gettext is installed.  
Either the gettext-bin/tools packages could be completely  
uninstalled, or they could be upgraded to the new gettext-bin/ 
tools--both situations would work.


It's still possible that adding to the new gettext Conflicts:  
gettext-bin ( 0.14.5-1), gettext-tools ( 0.14.5-1) would  
satisfy, I'm not sure how the dep engine would treat that.


This basically works (with BuildConflicts rather than Conflicts), but  
uncovers another bug in the dep engine, also reported recently on the  
mailing list.  Namely, fink uninstalls gettext-bin and gettext-tools  
at the beginning of the process, but then (apparently) tries to  
reinstall them after just installing a single package from the update  
list.


Or, we could be hacky and add 'fink build gettext-bin gettext- 
tools' to the new gettext's CompileScript, like we used to do in  
some other weird case.




This doesn't work, but it does work to add 'fink remove gettext-bin  
gettext-tools' to the new gettext's CompileScript.


However, I'm having trouble getting fink to bootstrap with the new  
gettext in place (in the 10.4 directory within the bootstrap  
directory) as well as libgettext3.  Will keep trying for a while;  
don't want to move libgettext3 and the new gettext to stable until we  
can also bootstrap with them.


  -- Dave




---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: [Fink-devel] Some observations on Gnome on Intel Macs

2006-02-27 Thread Daniel Macks
On Sun, Feb 26, 2006 at 11:39:45AM -0500, Daniel Johnson wrote:
 
 The issue is that gnome-vfs2 2.10.x is too new for control-center2  
 and gnome-panel which are both 2.6.x. The methods they rely on no  
 longer exist.

Now that we have KDE3.5.1, gnome-menus, a dependency for modern
version of the gnome stuff that is still in the GNOME2.6 era, can be
added. There's a -submissions for it that needs work, and a version in
my exp that I think is usable.

dan

-- 
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: [Fink-devel] How to deal with gconf files?

2006-02-27 Thread Daniel Macks
On Sun, Feb 26, 2006 at 07:16:39PM -0500, Sebastien Maret wrote:
 I am updating the gnucash package in fink, but I don't know how to
 deal with gconf files. There are two types of files. The first ones
 are .schema files, that get installed in %i/sw/etc/gconf/schemas. For
 what i saw in other packages, I think that one must past the
 --disable-schemas-install option to the configure script, declare
 these files as ConfFiles, and make a PostInstScript:
 
 if [ configure = $1 ]; then
   export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
   gconftool-2 --makefile-install-rule %p/etc/gconf/schemas/foo.schemas 
 /dev/null
   gconftool-2 --makefile-install-rule %p/etc/gconf/schemas/bar.schemas 
 /dev/null
 endif

Right. I'm not convinced this is correct, but it's the current
standard for fink packages.

 The second type of files are .xml files that get installed in
 %i/etc/gconf/gconf.xml.defaults/schemas/apps/gnucash. What should I do
 with those?

I think those are created on-the-fly by the gconftool-2
--makefile-install-rule call. If you pass --disable-schemas-install,
are they still present?

dan

-- 
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: [Fink-devel] Gettext stable-unstable switching on 10.4 tree

2006-02-27 Thread Daniel Macks
On Sat, Feb 25, 2006 at 06:48:21AM -0800, David R. Morrison wrote:
 
 There is a deeper issue here which perhaps we need to resolve: when  
 is it appropriate for a dependency to say (= %v-%r) and when should  
 it say (= %v-%r)?
 
 My first take on this is that among splitoffs of a given package, the  
 -dev should often have (= %v-%r) on the -shlibs.  However, perhaps  
 the -bin (and anything else) should have (= %v-%r).

I concur.

Fink's shlibs policy and modern libtool implementation is that for
install_name libfoo.1.dylib:

  foo-dev:libfoo.dylib - libfoo.1.1.0.dylib
  foo-shlibs: libfoo.1.dylib - libfoo.1.1.0.dylib
  foo-shlibs: libfoo.1.1.0.dylib (actual file)

The dependency must be = in order to have foo-dev work reliably.
Different versions of foo-shlibs, higher or lower, might have
different libfoo.1.x.y.dylib.

The only way = would not be needed is for:

  foo-dev:libfoo.dylib - libfoo.1.dylib
  foo-shlibs: libfoo.1.dylib - libfoo.1.1.0.dylib
  foo-shlibs: libfoo.1.1.0.dylib (actual file)

By definition, all versions of foo-shlibs contain libfoo.1.dylib, so
any version of foo-dev will have valid symlinks. A = dependency would
still be important for sanity, for example, to assure that foo.h in
foo-dev doesn't declare things that aren't in an older
compatibility_version of the lib.

For a -bin splitoff of a package that also contains a -shlibs
component all in the same .info, = is really only needed as a side
effect of compatibility_version.

dan

-- 
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel


[Fink-devel] Proposal: New percent-expansion for full version (Was: HEAD buildlocks (and maybe others?) don't handle epoch)

2006-02-27 Thread Dave Vasilevsky

On Feb 27, 2006, at 10:11 AM, Daniel Macks wrote:

So either there's a bug in get_depends (either its implementation or
how it is being called in this code snippet) or there's a bug in your
.info file (missing %e in the Depends line).


It's a bug in the .info file. The SplitOffs had Depends: %N (= %v-% 
r). But now that there's an epoch, that should be Depends: %N (= %e: 
%v-%r).



I propose that we add a %V expansion for full version, so we can just  
write (= %V) and forget about whether or not an epoch is needed. Any  
objections?


Dave




PGP.sig
Description: This is a digitally signed message part


Re: [Fink-devel] ESP Ghostscript

2006-02-27 Thread Tomoaki Okayama
At Sun, 26 Feb 2006 14:42:15 -0500,
Daniel Johnson wrote:
 
 At the very least, this needs to backup any existing files and  
 restore them at package removal. A better solution is to include a  
 script with the package which does the actual installation into /usr  
 and handles restoration at removal. This way the user must explicitly  
 choose to do this rather than being surprised by simply installing a  
 package. The package's PreRm should also call this script to ensure  
 that the package will clean up after itself. The postfix package does  
 something like this with its mta-switch script.

I see. Such a script is now included and I let the script be not called
automatically when installing. Thanks for your advice!

-- 
Tomoaki Okayama / Todai Fink Team


---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: [Fink-devel] ghemical, freeglut, 10.4

2006-02-27 Thread Alexander K. Hansen
On 2/27/06, William Scott [EMAIL PROTECTED] wrote:
   Hi Folks:

 I just changed ghemical's dependency (not to be confused with
 chemical dependency) from glut to freeglut on my machine and verified
 that this works.

 There is currently no maintainer for ghemical.  Does anyone mind if I
 update it?  Unless someone is chomping at the bit, I could try to
 maintain it and possibly augment it (it currently lacks the
 functionality provided by external code, if I am reading the web page
 right).

 Which then brings up the ever-popular glut/freeglut issue:  Should we
 try to change over in the 10.4 tree?

 These packages currently depend on glut:

 graphics/glui.info
 graphics/lablgl.info
 graphics/lightlab.info
 kde/kdegraphics3.info
 libs/gle3.info
 libs/libsmoke.info
 sci/fung-calc.info
 sci/gdis.info
 sci/gopenmol.info
 x11/xplanet.info

 and these on freeglut:

 sci/coot.info
 (sci/ghemical.info)
 sci/molmol.info
 sci/nightfall.info
 sci/pymol-py.info
 sci/xmakemol.info
 x11/freeglut.info


 Bill






I believe that the Standard Operating Procedure in these cases is that
anybody with commits access can make changes to unmaintained packages.

(And suffer the wrath of everybody else if they do something that
causes the list to get flooded with complaints) :-)

--
Alexander K. Hansen
Fink Documenter
[Day Job] Levitated Dipole Experiment
http://psfcwww2.psfc.mit.edu/ldx/


---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: [Fink-devel] Proposal: New percent-expansion for full version (Was: HEAD buildlocks (and maybe others?) don't handle epoch)

2006-02-27 Thread Daniel Macks
On Mon, Feb 27, 2006 at 01:58:19PM -0500, Chris Zubrzycki wrote:
 On Feb 27, 2006, at 1:22 PM, Dave Vasilevsky wrote:
 
 It's a bug in the .info file. The SplitOffs had Depends: %N (= %v-% 
 r). But now that there's an epoch, that should be Depends: %N (= % 
 e:%v-%r).
 
 I propose that we add a %V expansion for full version, so we can  
 just write (= %V) and forget about whether or not an epoch is  
 needed. Any objections?

Yamean 

  if (defined $epoch) {%V=%e:%v-%r} else {%V=%v-%r}

I like it! Very useful. No side effects, not gonna break anything.

dan

-- 
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: [Fink-devel] Re: mixed blt-dev dependencies on pythons

2006-02-27 Thread Daniel Macks
On Sat, Feb 25, 2006 at 09:20:24PM -0500, Jack Howarth wrote:
 I believe the BuildConflicts on blt-dev was added to python24
 by Daniel Macks to avoid it accidentally being linked into python24.
 The note at...
 
 http://cvs.sourceforge.net/viewcvs.py/fink/dists/10.4-transitional/unstable/main/finkinfo/languages/python24.info?rev=1.8view=markup
 
 ...indicates Daniel was unclear if he should do the same for python23.

The issue is that python autodetects blt-dev and links against blt if
it is present, but blt-dev was not a dependency nor were any flags
used to force it to be unused if present. That's a fundamental
packaging bug: either it must always be used (and hence a dependency)
or never be used (autodetection must fail).

blt has a lot of dependencies, its upstream looked pretty inactive,
and I couldn't find a reason to have it included, so I leaned towards
never using it. Email to python* maintainer went unanswered and
un-acted-upon, so I added blt-dev as a BuildConflicts to avoid having
it autodetected.

I did this to both python23 and python24. It's clear that maintainer
knew I was monkeying with python/blt at that point because I screwed
up the python23 fix and he repaired it.

So if we need python24 with blt, let's just add it (and rev-up
obviously) and check to see if we need to add it as a dependency of
things that link to python24.

dan

-- 
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel


[Fink-devel] Re: Fink-devel digest, Vol 1 #2227 - 14 msgs

2006-02-27 Thread William Scott
 If gle3 switches to using freeglut, does that break things that link
 against gle3 and were compiled when gle3 was using glut?

 dan


I just grepped through the 10.4 info files and couldn't find anything that 
depends on gle3...  I was going to test this to see.

Bill



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel


[Fink-devel] KDE builds on Intel! (mostly)

2006-02-27 Thread Daniel Johnson
Just to let everyone know, I've built all of bundle-kde on Intel,  
except for kdeaccessibility3 and koffice. Along the way I've fixed  
Intel building of some dependecies and emailed maintainers about some  
others.


The blocker for kdeaccessibility3 is gstreamer (at least) which uses  
assembly language files for it's x86 build. Unfortunately, Apple's  
assembler appears to use a different syntax than the Gnu assembler  
and dies horribly when trying to parse the files. It's possible to  
use the generic C code instead, but it won't be simple to decouple  
the assembly code from the rest of the x86isms. This could turn out  
to be a problem with other assembly-using packages.


--
Daniel Johnson
[EMAIL PROTECTED]
PGP public key: http://homepage.mac.com/danielj7/publickey.txt



PGP.sig
Description: This is a digitally signed message part


[Fink-devel] Q: Trees search order or precedence?

2006-02-27 Thread Adrian Mugnolo
Hi,

I have the following setting in my fink.conf file:

Trees: local/main stable/main stable/crypto
unstable/main

I am working on a package project that I keep updating
to the local tree.  Two other packages with the same
name exist under both stable and unstable trees.

Which is the proper way to tell fink(8) which tree it
should work on?  Or which is the search order for
directories listed under the Trees configuration
directive?

All documentation examples show work on new
packages.  It would be great to include at least one
case where the package already exists in the public
trees.

Thanks in advance.

Regards

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: [Fink-devel] KDE builds on Intel! (mostly)

2006-02-27 Thread Dave Vasilevsky


On Feb 27, 2006, at 9:57 PM, Daniel Johnson wrote:
The blocker for kdeaccessibility3 is gstreamer (at least) which  
uses assembly language files for it's x86 build. Unfortunately,  
Apple's assembler appears to use a different syntax than the Gnu  
assembler and dies horribly when trying to parse the files. It's  
possible to use the generic C code instead, but it won't be simple  
to decouple the assembly code from the rest of the x86isms. This  
could turn out to be a problem with other assembly-using packages.


Which version of gstreamer fails, and what's the error? I think the  
gstreamer folks removed most of their assembly code lately.


Dave


PGP.sig
Description: This is a digitally signed message part


Re: [Fink-devel] ghemical, freeglut, 10.4

2006-02-27 Thread Mark Tracy
William Scott wrote:  Hi Folks:  I just changed ghemical's dependency (not to be confused with   chemical dependency) from glut to freeglut on my machine and verified   that this works.  There is currently no maintainer for ghemical.  Does anyone mind if I   update it?  Unless someone is chomping at the bit, I could try to   maintain it and possibly augment it (it currently lacks the   functionality provided by external code, if I am reading the web page   right).  The current version of ghemical in fink (1.0.x) has babel and mini-mopac support built in. The newer 1.9x series uses externals for those. One of those external functionalities is MPQC-- the Massively-Parallel Quantum Chemistry package. I have gotten it to build in uniprocessor mode, but I don't really want to maintain a fink package since I lack the massively-parallel hardware to test it the way it was meant to be used. If anyone is interested, you need a few things: mpqc-2.3.0.tar.bz2  (the latest version from mpqc.sourceforge.net. Anything earlier won't work)gcc 4  (gcc 3.3 failed miserably)fortran (g77-3.4.3-13 worked for me)the following flags for configure:  --disable-parallel --with-libdirs=-L/sw/lib -framework vecLib --with-flibs=-lg2cThe funny business with putting -framework vecLib in libdirs is because configure ignores certain popular environment variables like LDFLAGS.and this patch for configure:--- configure.original  2006-02-27 21:23:51.0 -0800+++ configure   2006-01-14 11:03:42.0 -0800@@ -4312,7 +4312,7 @@           ;;           # Ignore these flags.-        -lang* | -lcrt[01].o | -lcrtbegin.o | -lc | -lgcc | -libmil | -LANG:=*)+        -lang* | -lcrt[012].o | -lcrtbegin.o | -lc | -lgcc | -libmil | -LANG:=*)           ;;         -lkernel32)           test x"$CYGWIN" != xyes  ac_cv_f77_libs="$ac_cv_f77_libs $ac_arg"The result passes make check0 in 20 minutes and make check1 in 31 hours, with no errors on my 700MHz G4 iMac. I'm afraid to try make check2.Cheers,Mark Tracy