Re: pango1-xft2-ft2191.24.5-7 fails with gtk-doc-1.18-1

On Wed, 18 Jan 2012 22:02:52 -0500, Hanspeter Niederstrasser 
<hanspeter <at> snaggledworks.com> wrote:
On 10.6 (32 or 64), pango1-xft2-ft219-1.24.5-7 fails tests when building
> with the newer gtk-doc-1.18-1:

Confirmed. I flagged the test as expected-fail, so it won't block the 
build. I can't quite figure out what specifically to do to fix them 
all, and pango has completely overhauled (in a way that can't be simply 
backported) at least some of these underlying functions and their 
documentation. New version is blocked from fink by glib and perhaps 
also intrinsic bugginess. 

dan

  --
Daniel Macks
dmacks <at> netspace.org

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
fink-gnome-core mailing list
fink-gnome-core <at> lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.gnome
Subscription management:

pango1-xft2-ft2191.24.5-7 fails with gtk-doc-1.18-1

On 10.6 (32 or 64), pango1-xft2-ft219-1.24.5-7 fails tests when building 
with the newer gtk-doc-1.18-1:

....
gtk-doc: Building HTML
rm -rf ./html
mkdir ./html
mkhtml_options=""; \
	gtkdoc-mkhtml 2>&1 --help | grep  >/dev/null "\-\-path"; \
	if test "sgml.stamp pango-docs.sgml pango_markup.sgml version.xml 
pango-querymodules.xml" = "0"; then \
	  mkhtml_options=--path="."; \
	fi
cd ./html && gtkdoc-mkhtml   pango ../pango-docs.sgml
Computing chunks...

           In gtk-doc.xsl: For acronym (element-type) no value found!

           In gtk-doc.xsl: For acronym (element-type) no value found!

           In gtk-doc.xsl: For acronym (element-type) no value found!

           In gtk-doc.xsl: For acronym (out) no value found!

test "xlayout.gif rotated-text.png" = "x" || ( cd . && cp layout.gif 
rotated-text.png html )
gtk-doc: Fixing cross-references
....
into make check
....

Gnome-panel and lablgtk2 on Fink 10.7

Hello Corey and gnome-core,

I have a Fink package for coqide that depends on (among other things) gnome-panel and lablgtk2, but these
packages are not available in the 10.7 tree.
Do you think you could move them there?
I've been able to build gnome-panel 2.28.0-3 and lablgtk2 2.14.2-2 on 10.7 with their existing package
descriptions without any modifications.

Best regards,
Bruno De Fraine

------------------------------------------------------------------------------
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
_______________________________________________
fink-gnome-core mailing list
fink-gnome-core <at> lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.gnome
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-gnome-core

[patch] glib2 on x86_64 can't collate/sort (eg in file dialogs)

GTK+ file open dialogs don't sort alphabetically on x86_64 because 
apparently glib is using Carbon for collation.  The following patch 
fixes file dialog sorting when I tested it on firefox8 on 10.7.  In 
theory it should be applied to all x86_64 platforms.  Dunno if including 
it for i386 or powerpc would be detrimental.

diff -Nurd -x'*~' glib-2.22.4.orig/tests/child-test.c 
glib-2.22.4/tests/child-test.c
--- glib-2.22.4.orig/glib/gunicollate.c.orig 2009-03-31 
18:04:20.000000000 -0500
+++ glib-2.22.4/glib/gunicollate.c 2010-03-06 17:59:08.000000000 -0600
@@ -26,6 +26,9 @@
  #include <wchar.h>
  #endif

+/* Carbon is not available on 64-bit */
+#undef HAVE_CARBON
+
  #ifdef HAVE_CARBON
  #include <CoreServices/CoreServices.h>
  #endif

Source:
https://trac.macports.org/ticket/23959

Hanspeter

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to

eel2-1:2.6.2-1010

Hallo,

I'm sorry.

There is the instruction to get  (pmw-py23 and pil-py23) but no item  
Found?

Thanks for an answer,  cheers, Erwin

Feedback: not good

--
Package manager version: 0.27.13
Distribution version: 0.9.0 i386
Mac OS X version: 10.5.8
Developer Tools not installed
Feedback Courtesy of FinkCommander

Gruss von dem Erwin
an der Nördlichen Ostsee

gtkmm2.4 is obsolete: documentation for this, and 10.7 ?

Hi there,

today I was trying to build a package using gtkmm2.4 (specifically, the package "surfer"), and since I was
using "-m --build-as-nobody" as is my habit, Fink error out like this:

WARNING: The package surfer has a preferred BuildDepends on gtkmm2.4-dev,
	 but gtkmm2.4-dev is an obsolete package.

I was confused at first, because there is no outward sign that gtkmm2.4-dev is obsolete. Indeed, "fink info
gtkmm2.4-dev" says nothing about this! Only when I looked at the .info file, did I discover that gtkmm2.4
and gtkmm2.4-dev are obsolete; apparently these days you ought to use gtkmm2.4-gtk-dev and
gtkmm2.4-shlibs only.

But several packages to this day depend on gtkmm2.4-dev, and I am not surprised. If this is meant to
eventually change, then it should be made crystal clear for packagers that they are doing something
wrong, and how to do it right.

Hence, could at the very least the "Description:" fields for gtkmm2.4 and gtkmm2.4-dev be changed to
contain "OBSOLETE" and a hint as to what the migration plan is ?

Secondly, a problem that troubles many other packages is the fact that building a package with just one
obsolete splitoff will cause fink to install fink-obsolete-package during build time. This is quite
annoying; e.g. me personally, I always balk by default when I see that building a package will install
fink-obsolete-packages. 

One way to fix this is to not make migration packages a splitoff, but rather have them in a separate .info
file. I realize that using splitoffs for migration packages sometimes is important, but in this case, I
wonder if it really is... ? At least for 10.7, we have a chance to start with a clean slate. So, can we at least
for 10.7 (re)move the obsolete parts into a separate .info file, so that the genuine non-obsolete parts
can be built without involving fink-obsolete-package ? Same for glibmm2.4, by the way.

These packages work in 10.7, and I really need them ...

The following all work on 10.7, and are dependencies for one or more packages I maintain.  Any chance they
might be added?

Many thanks in advance.

fftw
gsl
gtk2-engines
gtkglarea2
pygobject2-py
pygtk2-gtk-py

I've Bcc-ed maintainers for those packages that have them.

-- Bill

William G. Scott
Professor
Department of Chemistry and Biochemistry
and The Center for the Molecular Biology of RNA
228 Sinsheimer Laboratories
University of California at Santa Cruz
Santa Cruz, California 95064
USA

------------------------------------------------------------------------------
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey

gnome-desktop-2.14.0-2

Feedback: works for me

--
Package manager version: 0.27.13
Distribution version: 0.9.0 powerpc
Mac OS X version: 10.5.8
Developer Tools not installed
Feedback Courtesy of FinkCommander

------------------------------------------------------------------------------
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
_______________________________________________
fink-gnome-core mailing list
fink-gnome-core <at> lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.gnome
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-gnome-core

libgnomeprint2.2 clang fix

  The current libgnomeprint2.2 packaging fails to build under Lion with
clang unless the following patchlet is added to the libgnomeprint2.2.patch...

--- libgnomeprint-2.18.6/libgnomeprint/modules/cups/gnome-print-cups-transport.c.orig  
2011-07-09 14:57:38.000000000 -0400
+++ libgnomeprint-2.18.6/libgnomeprint/modules/cups/gnome-print-cups-transport.c        2011-07-09
14:58:14.000000000 -0400
@@ -36,6 +36,7 @@
 #include <fcntl.h>
 #include <unistd.h>
 #include <locale.h>
+#include <stdio.h>

 #include <cups/cups.h>
 #include <libgnomeprint/gnome-print.h>

so that the FILE type is available when it is used in a declaration. FYI.
           Jack

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
fink-gnome-core mailing list
fink-gnome-core <at> lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.gnome

glib2-shlibs.info clang fix

  The current glib2-shlibs.info in unstable fails to build under clang
due to errors of the form...

/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..  -I.. 
-DG_LOG_DOMAIN=\"GLib\" -DG_DISABLE_CAST_CHECKS -DG_DISABLE_DEPRECATED -DGLIB_COMPILATION
-DPCRE_STATIC -I/sw/include -DG_DISABLE_SINGLE_INCLUDES   -Os -Wall -c -o garray.lo garray.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DG_LOG_DOMAIN=\"GLib\"
-DG_DISABLE_CAST_CHECKS -DG_DISABLE_DEPRECATED -DGLIB_COMPILATION -DPCRE_STATIC -I/sw/include
-DG_DISABLE_SINGLE_INCLUDES -Os -Wall -c garray.c  -fno-common -DPIC -o .libs/garray.o
In file included from garray.c:944:
./galiasdef.c:18:72: error: only weak aliases are supported on darwin
extern __typeof (g_array_append_vals) g_array_append_vals
__attribute((alias("IA__g_array_append_vals"), visibility("default")));
                                                                       ^
./galiasdef.c:21:58: error: only weak aliases are supported on darwin
extern __typeof (g_array_free) g_array_free __attribute((alias("IA__g_array_free"), visibility("default")));
                                                         ^
./galiasdef.c:24:72: error: only weak aliases are supported on darwin
extern __typeof (g_array_insert_vals) g_array_insert_vals
__attribute((alias("IA__g_array_insert_vals"), visibility("default")));

Only two solutions are possible. The first, patching glib/makegalias.pl and friends to emit
"weak, alias" rather than "alias" seems difficult to implement. The far simplier fix is to just
append --disable-visibility to ConfigureParams. Note that configure in glib reports...

  --disable-visibility    don't use ELF visibility attributes

The Mach-O object format doesn't support true alias in the object files ala ELF and 
the weak import that Geoff Keatting created is considered a partially functional hack.
So in the absence of any failures in glib, the --disable-visibility option seems wiser.

Fink evolution-2.28.3.1-4 failures

1) fails to finish building the docs w/out docbook-dtd installed

2)
Validating .deb dir /sw/buildworld.build/root-evolution-2.28.3.1-4...
Error: File installed into deprecated directory /sw/sbin/.*/
	Offending file: /sw/sbin/evolution/
	Offending file: /sw/sbin/evolution/2.28/
	Offending file: /sw/sbin/evolution/2.28/csv2vcard
	Offending file: /sw/sbin/evolution/2.28/evolution-addressbook-clean
	Offending file: /sw/sbin/evolution/2.28/evolution-addressbook-export
	Offending file: /sw/sbin/evolution/2.28/evolution-alarm-notify
	Offending file: /sw/sbin/evolution/2.28/killev
Removing runtime build-lock...

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
fink-gnome-core mailing list
fink-gnome-core <at> lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.gnome
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-gnome-core