[Fink-devel] buildconflicts, buildlock

[Martin Costabel]

I have 2 loosely related questions:
1. What is the status of the BuildConflicts mechanism? I seem to 
remember that some months ago this worked as intended, i.e. the 
buildonly packages in question were removed before building and 
reinstalled afterwards. There were problems when many packages were 
installed at once, but this is normal and acceptable.

Recently, I tried to use this mechanism to get rid of some of those 
freetype 1 vs 2 conflicts by putting

 BuildConflicts: freetype | freetype-hinting
into the info file. This never worked. Depending on the order of the two 
packages and on which one was installed, it either did nothing at all or 
gave me a circular dependency error.

Now, with the arrival of the buildlock mechanism, Buildconflicts seems 
to be half dead: It is transformed into an ordinary Conflicts for the 
buildlock package, but there is no automatic removal any more, only a 
crash. And no automatic eventual restoration either, of course. As a 
message on the users list indicates, the message produced by this crash 
is not useful for normal users.

2. Is there any documentation of the buildlock system, in particular an 
explanation of how it works and what was the problem this is supposed to 
solve? Not one of the problems I had, it seems to me. From reading the 
sources, I found that there is a no_buildlocks option, and I would 
prefer this to be the default. There are even traces of a 
"Buildlock_PkgVersion" parameter in Fink::Config which "fink configure" 
and the documentation know nothing about.

3. Another undocumented config parameter is ConfFileCompatVersion.
--
Martin

---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] /sw/lib/perl5/Fink/Package.pm line 360

[Robert T Wyatt]

I finally realized I had picked up my "typo" from Dave V's suggestion 
and simply replied to the wrong message.

When I tried Dave's suggestion (below), it failed with:
bash-2.05b$ fink selfupdate
syntax error at /sw/lib/perl5/Fink/Package.pm line 361, near "or"
Compilation failed in require at /sw/lib/perl5/Fink/Engine.pm line 34.
BEGIN failed--compilation aborted at /sw/lib/perl5/Fink/Engine.pm line 34.
Compilation failed in require at /sw/bin/fink line 167.
bash-2.05b$
This is with Package.pm lines 360, 361 (on 10.2):
open APTDUMP, "-|", "$basepath/bin/apt-cache dump";
or die "Can't run apt-cache dump: $!";
Perhaps this is where TS' comment comes in:
At 1:51 PM -0700 2/25/05, TheSin wrote:
can't have that first ;
Since the other solution (given by dmacks below) is working, I'm not 
going to go down the road of figuring out why Dave's isn't, but y'all 
probably already know why anyhow.


At 3:12 PM -0500 2/25/05, Dave Vasilevsky wrote:
On Feb 25, 2005, at 10:24 AM, Daniel Macks wrote:
 open APTDUMP, "$basepath/bin/apt-cache dump |"
Perl usually discourages this form, since if someone could convince 
$basepath to bstart with ">" it might do bad things.

Why not stick with this?
open APTDUMP, "-|", "$basepath/bin/apt-cache dump";
Still not super (since ugly basepaths with spaces can still fail), 
but a bit better and it works with both perls.

Dave

---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] buildconflicts, buildlock

[TheSin]

I will revive buildconflicts again, and I say again cause I wrote it 
the first time and I believe Max disabled it because of an other issue 
which also affected the shlibs stuff.  After over a year we found away 
around it for the shlibs stuff and I'm currently working on a system 
for fink to add and remove users and groups via info file that will 
embed into the deb files making the passwd package no longer needed.  
Once that is done I'll tackle buildconflicts again and try not to break 
other things this time :D so likely a few months away.
---
TS
http://southofheaven.org
Chaos is the beginning and end, try dealing with the rest.

On 26-Feb-05, at 4:07 AM, Martin Costabel wrote:
I have 2 loosely related questions:
1. What is the status of the BuildConflicts mechanism? I seem to 
remember that some months ago this worked as intended, i.e. the 
buildonly packages in question were removed before building and 
reinstalled afterwards. There were problems when many packages were 
installed at once, but this is normal and acceptable.

Recently, I tried to use this mechanism to get rid of some of those 
freetype 1 vs 2 conflicts by putting

 BuildConflicts: freetype | freetype-hinting
into the info file. This never worked. Depending on the order of the 
two packages and on which one was installed, it either did nothing at 
all or gave me a circular dependency error.

Now, with the arrival of the buildlock mechanism, Buildconflicts seems 
to be half dead: It is transformed into an ordinary Conflicts for the 
buildlock package, but there is no automatic removal any more, only a 
crash. And no automatic eventual restoration either, of course. As a 
message on the users list indicates, the message produced by this 
crash is not useful for normal users.

2. Is there any documentation of the buildlock system, in particular 
an explanation of how it works and what was the problem this is 
supposed to solve? Not one of the problems I had, it seems to me. From 
reading the sources, I found that there is a no_buildlocks option, and 
I would prefer this to be the default. There are even traces of a 
"Buildlock_PkgVersion" parameter in Fink::Config which "fink 
configure" and the documentation know nothing about.

3. Another undocumented config parameter is ConfFileCompatVersion.
--
Martin

---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real 
users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel


---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] /sw/lib/perl5/Fink/Package.pm line 360

[TheSin]

sorry i wasn't more clear, the ; in perl ends a statement but the or on 
the next line means it's still going.  perl is getting confused cause 
there is stop but there is still more.

if you remove the ; from the end of the first line of code to or will 
continue and end at the ; on the second line and will work as desired.  
the benefit to drm's version is that it has an error check, that is 
what the or is for.  ie: if it can't open apt-cache dump, it's run the 
or part of the statement and at least tell you something and stop 
trying to continue the rest of the script.
---
TS
http://southofheaven.org
Chaos is the beginning and end, try dealing with the rest.

On 26-Feb-05, at 9:13 AM, Robert T Wyatt wrote:
I finally realized I had picked up my "typo" from Dave V's suggestion 
and simply replied to the wrong message.

When I tried Dave's suggestion (below), it failed with:
bash-2.05b$ fink selfupdate
syntax error at /sw/lib/perl5/Fink/Package.pm line 361, near "or"
Compilation failed in require at /sw/lib/perl5/Fink/Engine.pm line 
34.
BEGIN failed--compilation aborted at /sw/lib/perl5/Fink/Engine.pm 
line 34.
Compilation failed in require at /sw/bin/fink line 167.
bash-2.05b$

This is with Package.pm lines 360, 361 (on 10.2):
open APTDUMP, "-|", "$basepath/bin/apt-cache dump";
or die "Can't run apt-cache dump: $!";
Perhaps this is where TS' comment comes in:
At 1:51 PM -0700 2/25/05, TheSin wrote:
can't have that first ;
Since the other solution (given by dmacks below) is working, I'm not 
going to go down the road of figuring out why Dave's isn't, but y'all 
probably already know why anyhow.


At 3:12 PM -0500 2/25/05, Dave Vasilevsky wrote:
On Feb 25, 2005, at 10:24 AM, Daniel Macks wrote:
 open APTDUMP, "$basepath/bin/apt-cache dump |"
Perl usually discourages this form, since if someone could convince 
$basepath to bstart with ">" it might do bad things.

Why not stick with this?
open APTDUMP, "-|", "$basepath/bin/apt-cache dump";
Still not super (since ugly basepaths with spaces can still fail), 
but a bit better and it works with both perls.

Dave

---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real 
users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel


---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] freetype2 update

[Benjamin Reed]

I've got a version of freetype2/freetype2-hinting 2.1.9 in my
experimental tree that, in theory, fixes issues of binary compatibility
and building by older packages.  It includes some patches from debian
for backwards-compat as well as removing the error about including
ft2build.h first.

I would appreciate feedback from people to see if this works for
everyone...  I tested running stuff built against freetype2 2.1.3 in
/sw/lib/freetype2, as well as building some stuff that links against it
(including my qt3/kde in experimental) and everything seemed to work.

If this works, I'll apply the patch to the x server packages as
necessary too.


---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] buildconflicts, buildlock

[David R. Morrison]

Actually, Justin, buildconflicts *had* been working recently.  But as Martin
points out, the buildlock system has now broken it.

  -- Dave


---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] buildconflicts, buildlock

[Dave Vasilevsky]

On Feb 26, 2005, at 6:07 AM, Martin Costabel wrote:
2. Is there any documentation of the buildlock system, in particular 
an explanation of how it works and what was the problem this is 
supposed to solve? Not one of the problems I had, it seems to me. From 
reading the sources, I found that there is a no_buildlocks option, and 
I would prefer this to be the default. There are even traces of a 
"Buildlock_PkgVersion" parameter in Fink::Config which "fink 
configure" and the documentation know nothing about.
Martin,
Buildlocks solves several problems.
Fink's dep engine isn't always smart. Suppose foo depends on bar, and 
bar conflicts/replaces with iggy. If you had bar installed and did 
'fink install foo iggy', Fink might build and install first iggy and 
then foo. Now foo is being built without bar installed, since it's 
replaced by iggy. If it tries to link to a dylib in both bar and iggy, 
it will now be linked to iggy but will say 'Depends: bar'. This is BAD.

Building with the wrong packages installed could also happen if the 
user removes a package while building something that depends on it. Or 
if the user is running multiple builds at once, one build could remove 
something needed by the other. The dep engine also gets confused in 
some other situations.

When these problems occur, usually it results in Fink failing to build 
a package that really has no bug, or in Fink building a package that's 
not quite right (like the badly linked library situation discussed 
above). This causes all kinds of relatively mysterious bugs, and a lot 
of failed builds that lead to bug reports. We developers don't see it 
so often because we usually have a lot of packages installed already, 
but big builds like 'fink install bundle-gnome' on a brand new fink are 
very likely to run into this problem.

All buildlocks does is while building a package, it installs a "fake" 
package which depends on everything the current build needs to build. 
Now, if somebody (a user or fink) tries to remove a package while 
building something that needs it, they'll get an error. And if a 
package is about to be built but something it needs is missing, rather 
than silently try to build and then breaking, the buildlock will fail 
to install. Then Fink will give the user a message that they should try 
again (which usually solves the problem), rather than a random build 
failure that results in an irate message to the mailing list :-)

I'd say that a fair fraction of the error messages that we get on the 
lists, and the complaints people have about Fink, come from the 
problems I mentioned above. So it's very important that these 
situations not happen. And it's not trivial to "just" fix all the 
little things in the dep engine that can go wrong. Even if the current 
problems do get fixed, buildlocks will make sure new ones don't come 
up.

I think it's very important for the sanity of our packagers that 
buildlocks remain on by default. Essentially the only reason to turn 
them off is if there's a bug in buildlocks.

Dave


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

Re: [Fink-devel] buildconflicts, buildlock

[Robert T Wyatt]

two cents from a beginner:
At 3:55 PM -0500 2/26/05, Dave Vasilevsky wrote:
Buildlocks solves several problems.
Fink's dep engine isn't always smart. [snip] 'fink install 
bundle-gnome' [is] very likely to run into this problem.
Good example! I've been installing a bunch of gnome thingies the last 
several hours and getting plenty of these:

dpkg: error processing fink-buildlock-gnome-apt-0.3.15-5 (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 fink-buildlock-gnome-apt-0.3.15-5
### execution of dpkg failed, exit code 1
Can't set build lock for gnome-apt (0.3.15-5)
If any of the above dpkg error messages mention problems with
dependencies, fink has probably gotten confused by trying to build
many packages at once. Try building just this current package. When
that has completed successfully, you could retry whatever you did that
led to the present error.
Regardless of the cause of the lock failure, don't worry: you have not
wasted compiling time! Packages that had been completely built before
this error occurred will not have to be recompiled.
dpkg -r fink-buildlock-gnome-apt-0.3.15-5
(Reading database ... 141051 files and directories currently installed.)
Removing fink-buildlock-gnome-apt-0.3.15-5 ...
Failed: buildlock failure
(for more details see: 
http://uts.cc.utexas.edu/~bentones/development/at-home/20050226a.txt
and search for "failed")

Most of these are packages wanting db3, at least one wants ncurses5, 
and then there are a couple of others..., but it's pretty easy to see 
where the problems are coming from now and mostly I just have to fink 
install whatever the problem package is, which will pick up the 
missing dependency, and then go up two levels in my bash command 
history and re-execute.

Now if we could just make the package manager do this for us, or 
never have any more mixed dependencies again, or 

Anyway, I think the buildlock helps me to help myself. --robert
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] buildconflicts, buildlock

[TheSin]

no problem, I couldn't remember how it broke though I thought it was 
when Max removed my Engine changes.  Either way those changes I made 
where wrong and I see the other side.  I'll fix buildconflicts 
regardless.
---
TS
http://southofheaven.org
Chaos is the beginning and end, try dealing with the rest.

On 26-Feb-05, at 1:21 PM, David R. Morrison wrote:
Actually, Justin, buildconflicts *had* been working recently.  But as 
Martin
points out, the buildlock system has now broken it.

  -- Dave

---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] buildconflicts, buildlock

[David R. Morrison]

Robert T Wyatt <[EMAIL PROTECTED]> wrote:

> two cents from a beginner:
> 
> At 3:55 PM -0500 2/26/05, Dave Vasilevsky wrote:
> >Buildlocks solves several problems.
> >
> >Fink's dep engine isn't always smart. [snip] 'fink install 
> >bundle-gnome' [is] very likely to run into this problem.
> 
> Good example! I've been installing a bunch of gnome thingies the last 
> several hours and getting plenty of these:
> 
> dpkg: error processing fink-buildlock-gnome-apt-0.3.15-5 (--install):
>   dependency problems - leaving unconfigured
> Errors were encountered while processing:
>   fink-buildlock-gnome-apt-0.3.15-5
> ### execution of dpkg failed, exit code 1
> Can't set build lock for gnome-apt (0.3.15-5)
> 

[snip]

> Most of these are packages wanting db3, at least one wants ncurses5, 

OK, in my opinion, this behavior as reported by Robert indicates that the
buildlock system is not yet working as it should.

Fink is "supposed" to be able to switch back and forth among db3 vs. db42,
or ncurses5 vs. libncurses5.  So shouldn't we be trying to restore the
dependencies of the buildlock package, instead of just refusing to install
it?  (For example, we could add each new deb to the scanpackages database
just after it's built, and then ask apt-get (rather than dpkg) to install
the buildlock... which would "put back" a .deb that just got removed,
presumably.)

  -- Dave


---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] buildconflicts, buildlock

[Dave Vasilevsky]

On Feb 26, 2005, at 6:08 PM, David R. Morrison wrote:
OK, in my opinion, this behavior as reported by Robert indicates that 
the
buildlock system is not yet working as it should.
It's working fine, it's catching a bug in Fink right away rather than 
later. :-)

Fink is "supposed" to be able to switch back and forth among db3 vs. 
db42,
or ncurses5 vs. libncurses5.  So shouldn't we be trying to restore the
dependencies of the buildlock package, instead of just refusing to 
install
it?
Fink never did this properly. In one invocation, it can accomplish 
precisely ONE switch between replaceable packages, and sometimes it 
even does that wrong. At least now we're not letting it pass when it 
could cause an error.

(For example, we could add each new deb to the scanpackages database
just after it's built, and then ask apt-get (rather than dpkg) to 
install
the buildlock... which would "put back" a .deb that just got removed,
presumably.)
That's one idea. I was under the impression that Justin's shlibs 
changes in post-0.24 would be re-calculating dependencies before and 
after each build, which is another way to solve this issue. Am I right 
or wrong about that?

Dave



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

Re: [Fink-devel] buildconflicts, buildlock

[Daniel Macks]

On Sat, Feb 26, 2005 at 12:07:57PM +0100, Martin Costabel wrote:
> I have 2 loosely related questions:
> 
> 1. What is the status of the BuildConflicts mechanism? I seem to 
> remember that some months ago this worked as intended, i.e. the 
> buildonly packages in question were removed before building and 
> reinstalled afterwards. There were problems when many packages were 
> installed at once, but this is normal and acceptable.
> 
> Recently, I tried to use this mechanism to get rid of some of those 
> freetype 1 vs 2 conflicts by putting
> 
>  BuildConflicts: freetype | freetype-hinting
> 
> into the info file. This never worked.

As well it shouldn't (at least not as you want), by rigorous logic of
the OR operator. Just like:
  Depends: foo | bar

means something like "Depends:foo | Depends:bar", your usage means
"BC:freetype | BC:freetype-hinting". If you want to BConflicts with
*both*, you'd need an AND list.

The "Conflicts" field documentation notes:
  This fields also supports versioned dependencies like the Depends
  field, but not alternatives (wouldn't make sense).
where the term "alternatives" is defined (in the "Depends" field docs)
as the use of "|".

> 2. Is there any documentation of the buildlock system, in particular an 
> explanation of how it works and what was the problem this is supposed to 
> solve? Not one of the problems I had, it seems to me. From reading the 
> sources, I found that there is a no_buildlocks option, and I would 
> prefer this to be the default. There are even traces of a 
> "Buildlock_PkgVersion" parameter in Fink::Config which "fink configure" 
> and the documentation know nothing about.

This is just one of many flags and options that are for internal use
by the fink code only. Saves having to rewrite whole chunks of code.

> 3. Another undocumented config parameter is ConfFileCompatVersion.

This probably *should* be documented, since it has some meaning for
end-users.

dan

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



---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] buildconflicts, buildlock

[Daniel Macks]

On Sat, Feb 26, 2005 at 03:21:30PM -0500, David R. Morrison wrote:
> Actually, Justin, buildconflicts *had* been working recently.  But as Martin
> points out, the buildlock system has now broken it.

That seems strange. In Engine.pm, the calls to *_buildlock are tightly
wrapped around the phase_* calls that build the package. All of this
is well *inside* the lines documented to:
# remove buildconfilcts before new builds reinstall after build
and
# Reinstall buildconficts after the build

dan

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



---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] buildconflicts, buildlock

[Martin Costabel]

Daniel Macks wrote:
[]
BuildConflicts: freetype | freetype-hinting
into the info file. This never worked.

As well it shouldn't (at least not as you want), by rigorous logic of
the OR operator. Just like:
  Depends: foo | bar
means something like "Depends:foo | Depends:bar", your usage means
"BC:freetype | BC:freetype-hinting". If you want to BConflicts with
*both*, you'd need an AND list.
You are right. This was actually a typo in my message, in the info file 
I had correctly

BuildConflicts: freetype, freetype-hinting
It was this version that did not work.
--
Martin

---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] freetype2-update

[jfm]

Hi Benjamin,
I still get with mozilla :
nsFreeType.cpp
g++-3.3 -I/sw/lib/freetype2/include 
-I/sw/lib/freetype2/include/freetype2 -o nsFreeType.o -c 
-DOSTYPE=\"Darwin7.8.0\" -DOSARCH=\"Darwin\" -I../.. 
-I../../../dist/include/xpcom -I../../../dist/include/string 
-I../../../dist/include/pref -I../../../dist/include/uconv 
-I../../../dist/include/unicharutil -I../../../dist/include/gfx 
-I../../../dist/include 
-I/sw/bld/mozilla-1.7.5-1/mozilla/dist/include/nspr  -I/sw/include 
-I/sw/include -I/sw/include -I/sw/lib/freetype2/include/freetype2 
-I/sw/lib/freetype2/include -I/usr/X11R6/include   -fPIC  
-I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion 
-Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth 
-Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long 
-no-cpp-precomp -fno-common -fshort-wchar -pipe  -DNDEBUG -DTRIMMED -O  
-I/usr/X11R6/include -DMOZILLA_CLIENT -include 
../../../mozilla-config.h -Wp,-MD,.deps/nsFreeType.pp nsFreeType.cpp
In file included from nsFreeType.h:39,
 from nsFreeType.cpp:48:
../../../dist/include/gfx/nsIFreeType2.h:53: error: `FTC_Image_Cache' 
was not
   declared in this scope
../../../dist/include/gfx/nsIFreeType2.h:53: error: `aImageCache' was 
not
   declared in this scope
../../../dist/include/gfx/nsIFreeType2.h:53: error: variable 
declaration is not
   allowed here
../../../dist/include/gfx/nsIFreeType2.h:92: error: `FTC_Image_Cache' 
was not
   declared in this scope
../../../dist/include/gfx/nsIFreeType2.h:92: error: parse error before 
`,'
   token
../../../dist/include/gfx/nsIFreeType2.h:104: error: type specifier 
omitted for
   parameter `FTC_Image_Cache'
../../../dist/include/gfx/nsIFreeType2.h:104: error: parse error before 
`*'
   token
In file included from nsFreeType.cpp:48:
nsFreeType.h:107: error: `FTC_Image_Cache' was not declared in this 
scope
nsFreeType.h:107: error: `FTC_Image_Desc' was not declared in this scope
nsFreeType.h:107: error: parse error before `,' token
... etc; followed by bailout


There is a more general issue here it seems : it may be difficult to 
satisfy with a single package
the requirements both of those who need a <= 2.1.7 pkg, and of those 
for whom apparently
even xorg's freetype is not sufficiently new ...
The original purpose is still stated in DescDetail as :
"The freetype2 packages now exist only for compatibility with older Fink
packages.  Developers should use the freetype that is part of XFree86
for new packages."

I`m using since long a 2.1.7 pkg _ plain adaptation of the 2.1.3 _ , 
w/o any problems.
Looking at the Changelogs, it already priovides substantial 
improvements/fixes over 2.1.3,
and I think 2.1.3 -> 2.1.4 is OK with any fink pkg
I'll put it in my exp dir so people can look at it.

Best,
JF
PS: The mozilla problem with >> 2.1.7 should be gone with the current 
v. 1.8 beta 1
(and probably also with the 1.8a6 version in exp/gnome/2.8); but do we 
want a
beta 1 mozilla in fink ??


---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] freetype2-update

[Jean-François Mertens]

On 27 Feb 2005, at 02:10, jfm wrote:
and I think 2.1.3 -> 2.1.4 is OK with any fink pkg
That was : 2.1.3 -> 2.1.7 ...
Jf

---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] buildconflicts, buildlock

[David R. Morrison]

Dave Vasilevsky <[EMAIL PROTECTED]> wrote:

> On Feb 26, 2005, at 6:08 PM, David R. Morrison wrote:
> > OK, in my opinion, this behavior as reported by Robert indicates that 
> > the
> > buildlock system is not yet working as it should.
> 
> It's working fine, it's catching a bug in Fink right away rather than 
> later. :-)
> 
> > Fink is "supposed" to be able to switch back and forth among db3 vs. 
> > db42,
> > or ncurses5 vs. libncurses5.  So shouldn't we be trying to restore the
> > dependencies of the buildlock package, instead of just refusing to 
> > install
> > it?
> 
> Fink never did this properly. In one invocation, it can accomplish 
> precisely ONE switch between replaceable packages, and sometimes it 
> even does that wrong. At least now we're not letting it pass when it 
> could cause an error.
> 
> > (For example, we could add each new deb to the scanpackages database
> > just after it's built, and then ask apt-get (rather than dpkg) to 
> > install
> > the buildlock... which would "put back" a .deb that just got removed,
> > presumably.)
> 
> That's one idea. I was under the impression that Justin's shlibs 
> changes in post-0.24 would be re-calculating dependencies before and 
> after each build, which is another way to solve this issue. Am I right 
> or wrong about that?
> 
> Dave
> 

That's not relevant, actually.  The issue is:  which -dev packages are 
present at buildtime.  Those aren't recalculated.

  -- Dave


---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] linc1-0.5.5-12 failed

[Robert T Wyatt]

Hi folks, I'm getting multiply defined warnings and errors on 10.2 
with linc1. I don't know how to deal with these. Thanks, Robert.

/bin/sh ../libtool --mode=link gcc  -O3 -funroll-loops 
-fstrict-aliasing -L/sw/lib -o liblinc.la -rpath /sw/lib -L/sw/lib 
-lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lintl -liconv 
-version-info 1:0:0 linc.lo linc-connection.lo linc-protocols.lo 
linc-server.lo linc-source.lo
rm -fr .libs/liblinc.la .libs/liblinc.* .libs/liblinc.*
gcc -dynamiclib -flat_namespace -undefined suppress -o 
.libs/liblinc.1.0.0.dylib  linc.lo linc-connection.lo 
linc-protocols.lo linc-server.lo linc-source.lo  -L/sw/lib 
-lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lintl -liconv -lc 
-install_name  /sw/lib/liblinc.1.dylib -compatibility_version 2 
-current_version 2.0
ld: warning -dylib_install_name /sw/lib/liblinc.1.dylib not found in 
segment address table LD_SEG_ADDR_TABLE 
/sw/var/lib/fink/prebound/seg_addr_table
ld: warning -undefined suppress disables -prebind
ld: warning multiple definitions of symbol _locale_charset
/sw/lib/libiconv.dylib(localcharset.o) definition of _locale_charset
/sw/lib/libintl.dylib(localcharset.lo) definition of _locale_charset
(cd .libs && rm -f liblinc.1.dylib && ln -s liblinc.1.0.0.dylib 
liblinc.1.dylib)
(cd .libs && rm -f liblinc.dylib && ln -s liblinc.1.0.0.dylib liblinc.dylib)
ar cru .libs/liblinc.a  linc.o linc-connection.o linc-protocols.o 
linc-server.o linc-source.o
ranlib .libs/liblinc.a
creating liblinc.la
(cd .libs && rm -f liblinc.la && ln -s ../liblinc.la liblinc.la)
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../include 
-I/sw/include/glib-2.0 -I/sw/lib/glib-2.0/include-Wall -Wunused 
-Wmissing-prototypes -Wmissing-declarations -DG_DISABLE_DEPRECATED 
-D_GNU_SOURCE  -no-cpp-precomp -I/sw/include  -O3 -funroll-loops 
-fstrict-aliasing -c cleanup.c
cleanup.c: In function `open_socket':
cleanup.c:104: warning: passing arg 2 of `connect' from incompatible 
pointer type
/bin/sh ../libtool --mode=link gcc  -O3 -funroll-loops 
-fstrict-aliasing -L/sw/lib -o linc-cleanup-sockets -L/sw/lib 
-lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lintl -liconv   cleanup.o
gcc -O3 -funroll-loops -fstrict-aliasing -o linc-cleanup-sockets 
cleanup.o  -L/sw/lib -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lintl 
-liconv
ld: warning prebinding disabled because dependent library: 
/sw/lib/libgobject-2.0.0.dylib is not prebound
ld: warning multiple definitions of symbol _locale_charset
/sw/lib/libiconv.dylib(localcharset.o) definition of _locale_charset
/sw/lib/libintl.dylib(localcharset.lo) definition of _locale_charset
ld: warning suggest use of -bind_at_load, as lazy binding may result 
in errors or different symbols being used
symbol _locale_charset used from dynamic library 
/sw/lib/libiconv.dylib(localcharset.o) not from earlier dynamic 
library /sw/lib/libintl.1.dylib(localcharset.lo)
Making all in docs
*** Scanning header files ***
if grep -l '^..*$' ./linc.types > /dev/null ; then \
CC="/bin/sh ../libtool --mode=compile gcc" LD="/bin/sh ../libtool 
--mode=link gcc" CFLAGS="" LDFLAGS="" gtkdoc-scanobj --module=linc 
--output-dir=. ; \
else \
cd . ; \
for i in linc.args linc.hierarchy linc.signals ; do \
   test -f $i || touch $i ; \
done \
fi
cd . && \
  gtkdoc-scan --module=linc --source-dir=.. 
--ignore-headers="config.h acconfig.h linc-private.h"
touch scan-build.stamp
*** Rebuilding template files ***
cd . && gtkdoc-mktmpl --module=linc
=
WARNING: 24 unused declarations.
  These can be found in linc-unused.txt.
  They should be added to linc-sections.txt in the appropriate place.
=
touch tmpl-build.stamp
*** Building SGML ***
cd . && \
gtkdoc-mkdb --module=linc --source-dir=.. --main-sgml-file=linc-docs.sgml
56% symbol docs coverage (15 symbols documented, 12 not documented)
See linc-undocumented.txt for a list of missing docs.
The doc coverage percentage doesn't include intro sections.
touch sgml-build.stamp
*** Building HTML ***
test -d ./html || mkdir ./html
cd ./html && gtkdoc-mkhtml linc ../linc-docs.sgml
/sw/bin/openjade:../sgml/linc-types.sgml:63:19:E: ID 
"LINCPROTOCOLINFO" already defined
/sw/bin/openjade:../sgml/linc-protocol.sgml:123:19: ID 
"LINCPROTOCOLINFO" first defined here
make[2]: *** [html-build.stamp] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive-am] Error 2
### execution of make failed, exit code 2
Removing build lock...
dpkg -r fink-buildlock-linc1-0.5.5-12
(Reading database ... 96808 files and directories currently installed.)
Removing fink-buildlock-linc1-0.5.5-12 ...
Failed: phase compiling: linc1-0.5.5-12 failed

Before reporting any errors, please run "fink selfupdate" and
try again.  If you continue to have issues, you can try e-mailing
the maintainer:
None 
---
SF email is sponsored by 

[Fink-devel] Packages mentioning /sw/ by name in unstable

[Alexander Strange]

There are currently four packages in unstable that mention /sw/ instead 
of %p where it might cause the build to error out:

* Jeremy Higgs
ettercap-ssl
* Blair Zajac
grass5.7
* Jeffrey Whitaker
scilab-atlas
scilab
Besides that, there are many more packages that use /sw/ specifically 
in their Desc* fields. There were too many to mention by name, though.

[newibook:~] astrange% grep -rl sw/ /sw/fink/dists/unstable/*/finkinfo 
| wc -l
 233


---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Packages mentioning /sw/ by name in unstable

[Benjamin Reed]

Alexander Strange wrote:
> There are currently four packages in unstable that mention /sw/ instead
> of %p where it might cause the build to error out:
> 
> * Jeremy Higgs
> ettercap-ssl
> * Blair Zajac
> grass5.7
> * Jeffrey Whitaker
> scilab-atlas
> scilab
> 
> Besides that, there are many more packages that use /sw/ specifically in
> their Desc* fields. There were too many to mention by name, though.

I think these are there because, historically, desc* didn't expand
percent (I think that got changed recently.)


---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Packages mentioning /sw/ by name in unstable

[Alexander Strange]

On Feb 27, 2005, at 12:48 AM, Alexander Strange wrote:
* Jeffrey Whitaker
scilab-atlas
scilab
Looking at these two again, they are actually correct (although not 
structured in the usual way).


---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Packages mentioning /sw/ by name in unstable

[Michèle Garoche]

Le 27 févr. 2005, à 7:06, Benjamin Reed a écrit :
Alexander Strange wrote:
There are currently four packages in unstable that mention /sw/ 
instead
of %p where it might cause the build to error out:

* Jeremy Higgs
ettercap-ssl
* Blair Zajac
grass5.7
* Jeffrey Whitaker
scilab-atlas
scilab
Besides that, there are many more packages that use /sw/ specifically 
in
their Desc* fields. There were too many to mention by name, though.
Thanks for pointing it out, oversight from my part.
I think these are there because, historically, desc* didn't expand
percent (I think that got changed recently.)
Does this expansion work on all trees/branches?
Michèle



PGP.sig
Description: =?ISO-8859-1?Q?Ceci_est_une_signature_=E9lectronique_PGP?=