Re: gdb75 dumps core on startup

[Hans Ottevanger]

On 08/27/12 17:06, Luca Pizzamiglio wrote:

Hi,
Hans : have you tried the patch included here ports/171109?


With that patch gdb75 comes back to life again on amd64, and stops 
spewing weird messages while starting up on both amd64 and i386. If I 
stumble over more issues I will let you know. Thanks for your reply.


Kind regards,

Hans


Andriy: thanks for the report, I create a patch for that as soon as I can!

Regards,
Luca

On Mon, Aug 27, 2012 at 4:59 PM, Hans Ottevanger  wrote:

On 08/27/12 16:03, Andriy Gapon wrote:


Program terminated with signal 11, Segmentation fault
...
#0  0x004777e2 in i386_use_watchpoints ()
#1  0x00476bbd in _initialize_amd64fbsd_nat ()
#2  0x0060deea in initialize_all_files ()
#3  0x005e710f in gdb_init ()
#4  0x00549086 in relocate_gdb_directory ()
#5  0x00547aa4 in catch_errors ()
#6  0x00548bb4 in gdb_main ()
#7  0x00457ea9 in main ()

This is on amd64 head.



I can confirm that this happens on my not so recent 10-CURRENT (r239353),
also amd64.

I see a similar issue on 8.3-STABLE (r239646) on amd64:

$ gdb75 ./a.out
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
Segmentation fault: 11 (core dumped)

while on i386 gcc75 works OK, but I see:

$ gdb75 ./a.out
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
GNU gdb (GDB) 7.5 [GDB v7.5 for FreeBSD]
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-portbld-freebsd8.3".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/hans/a.out...done.
(gdb)

I do not know if the message about the undefined symbol is related to the
issue at hand. The previous version (gcc741) did not show this message and
functioned perfectly, also on amd64.

Kind regards,

Hans




___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: gdb75 dumps core on startup

[Hans Ottevanger]

On 08/27/12 16:03, Andriy Gapon wrote:

Program terminated with signal 11, Segmentation fault
...
#0  0x004777e2 in i386_use_watchpoints ()
#1  0x00476bbd in _initialize_amd64fbsd_nat ()
#2  0x0060deea in initialize_all_files ()
#3  0x005e710f in gdb_init ()
#4  0x00549086 in relocate_gdb_directory ()
#5  0x00547aa4 in catch_errors ()
#6  0x00548bb4 in gdb_main ()
#7  0x00457ea9 in main ()

This is on amd64 head.



I can confirm that this happens on my not so recent 10-CURRENT 
(r239353), also amd64.


I see a similar issue on 8.3-STABLE (r239646) on amd64:

$ gdb75 ./a.out
[GDB will not be able to debug user-mode threads: 
/usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]

Segmentation fault: 11 (core dumped)

while on i386 gcc75 works OK, but I see:

$ gdb75 ./a.out
[GDB will not be able to debug user-mode threads: 
/usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]

GNU gdb (GDB) 7.5 [GDB v7.5 for FreeBSD]
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-portbld-freebsd8.3".
For bug reporting instructions, please see:
...
Reading symbols from /home/hans/a.out...done.
(gdb)

I do not know if the message about the undefined symbol is related to 
the issue at hand. The previous version (gcc741) did not show this 
message and functioned perfectly, also on amd64.


Kind regards,

Hans
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD unmaintained ports which are currently marked broken

[Hans Ottevanger]

On 03/07/12 15:45, Hans Ottevanger wrote:

On 03/07/12 09:28, lini...@freebsd.org wrote:

As part of an ongoing effort to reduce the number of problems in

[...]


portname: x11/kdelibs3
broken because: does not compile
build errors: none.
overview:
http://portsmon.FreeBSD.org/portoverview.py?category=x11&portname=kdelibs3





I have tried to rebuild kdelibs3 (using "make TRYBROKEN=yes") on
8.3-PRERELEASE r232394 (both amd64 and i386 userland in a jail) and on
10.0-CURRENT r232656 (amd64 only) on a recently portsnapped /usr/ports
and I cannot reproduce the build error mentioned in

http://lists.freebsd.org/pipermail/cvs-ports/2012-March/237903.html

All my builds finish without errors.

Am I the only one seeing this?

If kdelibs3 is actually broken, how could I reproduce the build error in
the commit message?



I see now that the brokenness has (silently) been limited to 7.x earlier 
today.


Thanks. This saves some extra attention while rebuilding ports.

Kind regards,

Hans
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD unmaintained ports which are currently marked broken

[Hans Ottevanger]

On 03/07/12 09:28, lini...@freebsd.org wrote:

As part of an ongoing effort to reduce the number of problems in

[...]


portname:   x11/kdelibs3
broken because: does not compile
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=x11&portname=kdelibs3




I have tried to rebuild kdelibs3 (using "make TRYBROKEN=yes") on 
8.3-PRERELEASE r232394 (both amd64 and i386 userland in a jail) and on 
10.0-CURRENT r232656 (amd64 only) on a recently portsnapped /usr/ports 
and I cannot reproduce the build error mentioned in


http://lists.freebsd.org/pipermail/cvs-ports/2012-March/237903.html

All my builds finish without errors.

Am I the only one seeing this?

If kdelibs3 is actually broken, how could I reproduce the build error in 
the commit message?


Kind regards,

Hans Ottevanger

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: why is audio/akode marked as BROKEN: Unfetchable?

[Hans Ottevanger]

On Sun, Jul 10, 2011 at 12:32:13PM +0200, Heino Tiedemann wrote:
> Hey,
> 
> 
> why is audio/akode marked as BROKEN: Unfetchable?
> 
> 
> It IS fetchable, e.g. here:
> 
> 
> http://www.kde-apps.org/CONTENT/content-files/30375-akode-2.0.2.tar.bz2
> 
> 
> Or here:
> 
> http://pkgs.fedoraproject.org/repo/pkgs/akode/30375-akode-2.0.2.tar.bz2/659ced0c9c735cb3e55b9138ff02342c/30375-akode-2.0.2.tar.bz2
> 
> or here:
> http://findpro.net/en/index.php?action=download&id=63297
> 
> 

or here:

ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/30375-akode-2.0.2.tar.bz2

or here:

fetch 
ftp://ftp.nl.freebsd.org/pub/FreeBSD/ports/distfiles/30375-akode-2.0.2.tar.bz2

Kind regards,

Hans Ottevanger
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Superfluous dependencies

[Hans Ottevanger]

On Sun, Mar 13, 2011 at 4:27 PM, Hans Ottevanger
 wrote:
> On Sat, Mar 12, 2011 at 10:53 PM, Mark Linimon  wrote:
>> On Thu, Mar 10, 2011 at 10:28:40AM +0100, Hans Ottevanger wrote:
>>> If anybody is interested I could consolidate my results and post a few 
>>> patches.
>>
>> I would like to see them.
>>
>> This is the kind of really-dull-but-necessary work that we need to have
>> people work on to fight the creeping dependencies :-)
>>
>> mcl
>>
>
> Real life intervened the last few days, so excuses for the delay.
>
> Since the test system I used last week became a mess in the process, I
> restarted the effort this morning on my 9.0-CURRENT system (amd64,
> r219593). I have cvsupped the ports tree at about 10:45 UTC. Limiting
> the discussion to Xorg alone for now, I made the following changes to
> just three makefiles:
>
> Index: devel/glib20/Makefile
> ===
> RCS file: /home/ncvs/ports/devel/glib20/Makefile,v
> retrieving revision 1.174
> diff -r1.174 Makefile
> 42,43c42,43
> < USE_PYTHON=   yes
> < USE_PERL5=    yes
> ---
>> USE_PYTHON_BUILD=yes
>> USE_PERL5_BUILD=yes
> Index: sysutils/hal/Makefile
> ===
> RCS file: /home/ncvs/ports/sysutils/hal/Makefile,v
> retrieving revision 1.69
> diff -r1.69 Makefile
> 29c29
> < USE_PYTHON=   yes
> ---
>> USE_PYTHON_BUILD=yes
> Index: sysutils/polkit/Makefile
> ===
> RCS file: /home/ncvs/ports/sysutils/polkit/Makefile,v
> retrieving revision 1.9
> diff -r1.9 Makefile
> 20c20
> < RUN_DEPENDS=
> ${LOCALBASE}/share/gir-1.0/GLib-2.0.gir:${PORTSDIR}/devel/gobject-introspection
> ---
>> #RUN_DEPENDS= 
>> ${LOCALBASE}/share/gir-1.0/GLib-2.0.gir:${PORTSDIR}/devel/gobject-introspection
>
> The first two are quite trivial, the third could be a bit tricky, but
> I cannot find (and imagine) a situation where gobject-introspection is
> needed on run-time for a "normal" end-user.
>
> After building and installing xorg-7.5.1 I can deinstall the following
> packages (and probably quite a few others that are only needed at
> build-time):
>
> autoconf-2.68
> automake-1.11.1
> bison-2.4.3,1
> gobject-introspection-0.9.12_1
> help2man-1.39.2
> intltool-0.41.1
> m4-1.4.15,1
> p5-Locale-gettext-1.05_3
> p5-XML-Parser-2.40
> perl-5.10.1_3
> python27-2.7.1_1
> xcb-proto-1.6
>
> As far as I can see now, X functions OK, though I still have to compile KDE.
>
>
> Kind regards
>
> Hans Ottevanger
>

As suggested by Chris Rees, also as unified diffs:

--- devel/glib20/Makefile.orig  2011-03-13 17:26:30.0 +0100
+++ devel/glib20/Makefile   2011-03-13 17:26:47.0 +0100
@@ -39,8 +39,8 @@
 USE_GNOME= gnomehack pkgconfig ltverhack
 USE_GMAKE= yes
 MAKE_JOBS_SAFE=yes
-USE_PYTHON=yes
-USE_PERL5= yes
+USE_PYTHON_BUILD=yes
+USE_PERL5_BUILD=yes
 CONFIGURE_ARGS=--enable-static --with-libiconv=gnu \
--disable-gtk-doc --with-html-dir=${PREFIX}/share/doc \
--disable-man --without-xml-catalog \
--- sysutils/hal/Makefile.orig  2011-03-13 17:05:01.0 +0100
+++ sysutils/hal/Makefile   2011-03-13 17:27:58.0 +0100
@@ -26,7 +26,7 @@
 USE_GNOME= gnomehack intlhack ltverhack
 USE_AUTOTOOLS= libtool
 USE_LDCONFIG=  yes
-USE_PYTHON=yes
+USE_PYTHON_BUILD=yes
 CONFIGURE_ARGS=--disable-gtk-doc \
--with-backend=freebsd \
--disable-docbook-docs \
--- sysutils/polkit/Makefile.orig   2011-03-13 17:05:11.0 +0100
+++ sysutils/polkit/Makefile2011-03-13 17:28:54.0 +0100
@@ -17,7 +17,7 @@
 BUILD_DEPENDS=
${LOCALBASE}/share/gir-1.0/GLib-2.0.gir:${PORTSDIR}/devel/gobject-introspection
 LIB_DEPENDS=   eggdbus-1.0:${PORTSDIR}/devel/eggdbus \
    expat.6:${PORTSDIR}/textproc/expat2
-RUN_DEPENDS=
${LOCALBASE}/share/gir-1.0/GLib-2.0.gir:${PORTSDIR}/devel/gobject-introspection
+#RUN_DEPENDS=
${LOCALBASE}/share/gir-1.0/GLib-2.0.gir:${PORTSDIR}/devel/gobject-introspection

 USE_GNOME= gnomehack glib20 intlhack
 USE_GMAKE= yes


Kind regards,

Hans Ottevanger
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Superfluous dependencies

[Hans Ottevanger]

On Sat, Mar 12, 2011 at 10:53 PM, Mark Linimon  wrote:
> On Thu, Mar 10, 2011 at 10:28:40AM +0100, Hans Ottevanger wrote:
>> If anybody is interested I could consolidate my results and post a few 
>> patches.
>
> I would like to see them.
>
> This is the kind of really-dull-but-necessary work that we need to have
> people work on to fight the creeping dependencies :-)
>
> mcl
>

Real life intervened the last few days, so excuses for the delay.

Since the test system I used last week became a mess in the process, I
restarted the effort this morning on my 9.0-CURRENT system (amd64,
r219593). I have cvsupped the ports tree at about 10:45 UTC. Limiting
the discussion to Xorg alone for now, I made the following changes to
just three makefiles:

Index: devel/glib20/Makefile
===
RCS file: /home/ncvs/ports/devel/glib20/Makefile,v
retrieving revision 1.174
diff -r1.174 Makefile
42,43c42,43
< USE_PYTHON=   yes
< USE_PERL5=yes
---
> USE_PYTHON_BUILD=yes
> USE_PERL5_BUILD=yes
Index: sysutils/hal/Makefile
===
RCS file: /home/ncvs/ports/sysutils/hal/Makefile,v
retrieving revision 1.69
diff -r1.69 Makefile
29c29
< USE_PYTHON=   yes
---
> USE_PYTHON_BUILD=yes
Index: sysutils/polkit/Makefile
===
RCS file: /home/ncvs/ports/sysutils/polkit/Makefile,v
retrieving revision 1.9
diff -r1.9 Makefile
20c20
< RUN_DEPENDS=
${LOCALBASE}/share/gir-1.0/GLib-2.0.gir:${PORTSDIR}/devel/gobject-introspection
---
> #RUN_DEPENDS= 
> ${LOCALBASE}/share/gir-1.0/GLib-2.0.gir:${PORTSDIR}/devel/gobject-introspection

The first two are quite trivial, the third could be a bit tricky, but
I cannot find (and imagine) a situation where gobject-introspection is
needed on run-time for a "normal" end-user.

After building and installing xorg-7.5.1 I can deinstall the following
packages (and probably quite a few others that are only needed at
build-time):

autoconf-2.68
automake-1.11.1
bison-2.4.3,1
gobject-introspection-0.9.12_1
help2man-1.39.2
intltool-0.41.1
m4-1.4.15,1
p5-Locale-gettext-1.05_3
p5-XML-Parser-2.40
perl-5.10.1_3
python27-2.7.1_1
xcb-proto-1.6

As far as I can see now, X functions OK, though I still have to compile KDE.


Kind regards

Hans Ottevanger
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Superfluous dependencies

[Hans Ottevanger]

On Tue, Mar 8, 2011 at 3:51 PM, Michael Scheidell
 wrote:
>
>
> On 3/8/11 4:42 AM, Hans Ottevanger wrote:
>>
>> One of them that I already hunted down is bison-2.4.3,1 that gets
>> dragged in via gobject-introspection-0.9.12_1 when installing
>> xorg-7,5.1 (even as a package). This is caused by bison specified as a
>> dependency of type "both" in the port Makefile of
>> gobject-introspection where it should be specified as "build". I don't
>> think that Bison is used on run-time here and most likely not even on
>> build- time.
>
> appears one of our 'short cuts' causes this.  and I found it on a port I
> took over maint of.
>
> happens all the time if you do a 'RUN_DEPENDS += BUILD_DEPENDS'
>
> pulls in all kind of cruft.
>

Indeed I see this 'shortcut' being used all over the place. But in the
cases I have looked into the last few days, i.e. the xorg-7.5.1 and
kde-lite-3.5.10_8 ports, the problem is just a trivial, but slightly
different. It appears that in many occasions USE_PYTHON and USE_PERL
are specified in situations where I think USE_PYTHON_BUILD and
USE_PERL_BUILD, respectively, would suffice.

By making a few trivial changes i can make xorg-7.5.1 fully
independent on run-time of Python, Perl and Bison. The same can be
done for kde-lite-3.5.10_8 when I also disable the Perl support in
net-snmp, which is a dependency of kdeutils-3.5.10_8.

If anybody is interested I could consolidate my results and post a few patches.

Kind regards,

Hans Ottevanger


]...]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Superfluous dependencies

[Hans Ottevanger]

Porters,

I have been working on some fresh FreeBSD 8.2 installations recently
and I was surprised about the amount of extra ports that get installed
as dependencies. Once I finish an installation of Xorg and KDE 3 (yes,
still using it, like many FreeBSD users and developers), I end up with
a handful of scripting languages and development tools I did not ask
for.

One of them that I already hunted down is bison-2.4.3,1 that gets
dragged in via gobject-introspection-0.9.12_1 when installing
xorg-7,5.1 (even as a package). This is caused by bison specified as a
dependency of type "both" in the port Makefile of
gobject-introspection where it should be specified as "build". I don't
think that Bison is used on run-time here and most likely not even on
build- time. I also doubt the need for Python in this case, i.e. as a
dependency for an Xorg installation, but it may be needed in a more
general use case of gobject-introspection.

I have changed the dependency in my Makefile and rebuilt everything. I
now do not have bison as a dependency anymore and can safely delete
it, just like all other build dependencies.

I am sure there are more of  these superfluous dependencies and I will
probably hunt down a few more. Does anyone have an idea how to do this
systematically?

Kind regards,

Hans Ottevanger
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"