Re: cyrus-sasl

2012-12-11 Thread Franci Nabalanci
Thank you...looks like that I am a genie pig :).

It stopped again because gobject-introspection looks for python 2.7 but I
use 2.5 all the time and didn't complain...

Don't worry...

On Mon, Dec 10, 2012 at 11:49 PM, Hajimu UMEMOTO u...@freebsd.org wrote:

 Hi,

  On Mon, 10 Dec 2012 16:04:56 -0600
  Franci Nabalanci lum...@gmail.com said:

 lumiwa === gconf2-2.32.0_3 cannot install: unknown OpenLDAP version:
 Shared
 lumiwa object libsasl2.so.2 not found, required by ldapwhoami.
 lumiwa *** [all] Error code 1

 It seems we cannot remove old lib (libsasl2.so.2) during upgrade.
 I've just committed to change UPDATING to recommend to use -w option
 of portmaster.

 Sincerely,

 --
 Hajimu UMEMOTO
 u...@mahoroba.org  ume@{,jp.}FreeBSD.org
 http://www.mahoroba.org/~ume/

___
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: cyrus-sasl

2012-12-11 Thread Franci Nabalanci
I reinstall Python 2.7

I red that kdepimlibs doesn't build too...

On Tue, Dec 11, 2012 at 5:28 AM, Franci Nabalanci lum...@gmail.com wrote:

 Thank you...looks like that I am a genie pig :).

 It stopped again because gobject-introspection looks for python 2.7 but I
 use 2.5 all the time and didn't complain...

 Don't worry...

 On Mon, Dec 10, 2012 at 11:49 PM, Hajimu UMEMOTO u...@freebsd.org wrote:

 Hi,

  On Mon, 10 Dec 2012 16:04:56 -0600
  Franci Nabalanci lum...@gmail.com said:

 lumiwa === gconf2-2.32.0_3 cannot install: unknown OpenLDAP version:
 Shared
 lumiwa object libsasl2.so.2 not found, required by ldapwhoami.
 lumiwa *** [all] Error code 1

 It seems we cannot remove old lib (libsasl2.so.2) during upgrade.
 I've just committed to change UPDATING to recommend to use -w option
 of portmaster.

 Sincerely,

 --
 Hajimu UMEMOTO
 u...@mahoroba.org  ume@{,jp.}FreeBSD.org
 http://www.mahoroba.org/~ume/



___
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: ports/174366: [new port] sysutils/i7z: A better i7 (and now i3, i5) reporting tool for Linux

2012-12-11 Thread zont
Synopsis: [new port] sysutils/i7z: A better i7 (and now i3, i5) reporting tool 
for Linux

Responsible-Changed-From-To: zont-freebsd-ports
Responsible-Changed-By: zont
Responsible-Changed-When: Tue Dec 11 12:14:02 UTC 2012
Responsible-Changed-Why: 
I'm not a port committer.

http://www.freebsd.org/cgi/query-pr.cgi?pr=174366
___
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: ports/174366: [new port] sysutils/i7z: A better i7 (and now i3, i5) reporting tool for Linux

2012-12-11 Thread zont
Synopsis: [new port] sysutils/i7z: A better i7 (and now i3, i5) reporting tool 
for Linux

Responsible-Changed-From-To: freebsd-ports-freebsd-ports-bugs
Responsible-Changed-By: zont
Responsible-Changed-When: Tue Dec 11 12:24:21 UTC 2012
Responsible-Changed-Why: 
Fix responsible.

http://www.freebsd.org/cgi/query-pr.cgi?pr=174366
___
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: cyrus-sasl

2012-12-11 Thread Hajimu UMEMOTO
Hi,

 On Tue, 11 Dec 2012 05:36:48 -0600
 Franci Nabalanci lum...@gmail.com said:

lumiwa I red that kdepimlibs doesn't build too...

I've committed the fix to this issue.  Please try the latest one.

Sincerely,

--
Hajimu UMEMOTO
u...@mahoroba.org  ume@{,jp.}FreeBSD.org
http://www.mahoroba.org/~ume/
___
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


pkgng: sqlite: database is locked

2012-12-11 Thread Mathias Picker
I'm getting sqlite: database is locked errors with pkg. For deinstalls
(portmaster updates) and fresh port installs with make install. The
latest is

===   Registering installation for MuSE-0.9.2_14
Installing MuSE-0.9.2_14... done
pkg: sqlite: database is locked

which results in muse not being registered in the pkg database...

How can I investigate this further? This persists between reboots, and
for fresh pkg runs. 

I'm hesitating to upgrade all the changes after the ports freeze has
been lifted...

I'm using a FreeBSD-stable and have changed to pkgng maybe two weeks
ago. At the first portmaster -a after the upgrade, I think everything
went smooth, and then more and more of these errors popped up.
Everything is build using gcc.

mp# uname -a
FreeBSD mp.virtual-earth.de 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #28
r243882: Wed Dec  5 18:28:39 CET 2012
mathi...@mp.virtual-earth.de:/usr/obj/usr/src/sys/GENERIC  amd64

mp# pkg -v
1.0.3

Any help apreciated,

Mathias


___
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


recent port upgrades causing missing libraries

2012-12-11 Thread Adam McDougall
I used poudriere to build pkgng packages from the latest round
of port updates since the freeze.  I know in the commit message
for xcb-util it bumped some other ports, but it seems like not
enough to make poudriere reinstall enough packages to make things
work.  The pcre upgrade also caused some problems.  I'm sorry that
I don't have time to make an extensive report of ports vs. libraries
or a PR but I can add some brief details.  Using pkg install -fR 
on xcb-util and pcre cured the issues for now, but that doesn't mean
I've caught them all.  pkg_libchk doesn't work with pkgng.  I could
have told pkg to reinstall all packages but that is a big hammer.

Reinstalling libiconv-1.14
Upgrading pcre: 8.31_1 - 8.32
Upgrading png: 1.5.12 - 1.5.13
Upgrading jpeg: 8_3 - 8_4
Upgrading xcb-util: 0.3.8,1 - 0.3.9_1,1
Upgrading glib: 2.28.8_4 - 2.28.8_5
Upgrading tiff: 4.0.2_1 - 4.0.3
Upgrading gobject-introspection: 0.10.8_2 - 0.10.8_3
Upgrading cairo: 1.10.2_4,2 - 1.10.2_5,2
Reinstalling ghostscript9-nox11-9.06_1
Upgrading pciids: 20120906 - 20121208
Upgrading startup-notification: 0.12 - 0.12_1
Upgrading openldap-client: 2.4.33 - 2.4.33_1
Upgrading cups-client: 1.5.2_2 - 1.5.4
Upgrading postfix: 2.9.4,1 - 2.9.4_2,1
Upgrading binutils: 2.22_3 - 2.23.1
Upgrading javavmwrapper: 2.4_2 - 2.4_3
Upgrading xterm: 287 - 287_1
Upgrading Thunar: 1.4.0_2 - 1.4.0_3
Upgrading goffice: 0.8.17_2 - 0.8.17_3
Upgrading ImageMagick: 6.7.9.4 - 6.8.0.7
Upgrading wireshark: 1.8.3 - 1.8.3_1

Upgrading Thunar from 1.4.0_2 to 1.4.0_3...Shared object libpcre.so.1 not 
found, required by update-desktop-database
Shared object libpcre.so.1 not found, required by update-desktop-database
 done

# pkg which `which update-desktop-database`
/usr/local/bin/update-desktop-database was installed by package 
desktop-file-utils-0.18

Terminal:
libpcre.so.1 = not found (0)

exo-desktop-item-edit:
libxcb-util.so.0 = not found (0)
libpcre.so.1 = not found (0)
libpcre.so.3 = /usr/local/lib/libpcre.so.3 (0x807942000)

mousepad:
libxcb-util.so.0 = not found (0)
libxcb-util.so.1 = /usr/local/lib/libxcb-util.so.1 (0x807749000)
libpcre.so.1 = not found (0)
libpcre.so.3 = /usr/local/lib/libpcre.so.3 (0x80794e000)

I think either more port version bumps are needed, or an entry in UPDATING.
The UPDATING entry for perl is still wrong, I discussed on a list that it
should not contain -x in the pkg command but it still does.  The -x will make
it install unwanted things.
___
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: recent port upgrades causing missing libraries

2012-12-11 Thread Bryan Drewery
On 12/11/2012 9:03 AM, Adam McDougall wrote:
 I used poudriere to build pkgng packages from the latest round
 of port updates since the freeze.  I know in the commit message
 for xcb-util it bumped some other ports, but it seems like not
 enough to make poudriere reinstall enough packages to make things
 work.  


Poudriere does the right thing here, it recompiles all affected ports.

The pcre upgrade also caused some problems.  I'm sorry that
 I don't have time to make an extensive report of ports vs. libraries
 or a PR but I can add some brief details.  Using pkg install -fR 
 on xcb-util and pcre cured the issues for now, but that doesn't mean
 I've caught them all.  pkg_libchk doesn't work with pkgng.  I could
 have told pkg to reinstall all packages but that is a big hammer.

The problem then comes here, pkgng doesn't automatically know that ports
have been rebuilt (without PORTREVISION bumps) or that their checksums
do not match, unless you use pkg install -fR on the proper packages.

I've written a script that does the same as `portmaster -w`, which will
preserve old libraries when running `pkg upgrade`, which will at least
prevent a broken system while you use pkg_libchk to force reinstall
affected packages:

https://gist.github.com/3099160


 
 Reinstalling libiconv-1.14
 Upgrading pcre: 8.31_1 - 8.32
 Upgrading png: 1.5.12 - 1.5.13
 Upgrading jpeg: 8_3 - 8_4
 Upgrading xcb-util: 0.3.8,1 - 0.3.9_1,1
 Upgrading glib: 2.28.8_4 - 2.28.8_5
 Upgrading tiff: 4.0.2_1 - 4.0.3
 Upgrading gobject-introspection: 0.10.8_2 - 0.10.8_3
 Upgrading cairo: 1.10.2_4,2 - 1.10.2_5,2
 Reinstalling ghostscript9-nox11-9.06_1
 Upgrading pciids: 20120906 - 20121208
 Upgrading startup-notification: 0.12 - 0.12_1
 Upgrading openldap-client: 2.4.33 - 2.4.33_1
 Upgrading cups-client: 1.5.2_2 - 1.5.4
 Upgrading postfix: 2.9.4,1 - 2.9.4_2,1
 Upgrading binutils: 2.22_3 - 2.23.1
 Upgrading javavmwrapper: 2.4_2 - 2.4_3
 Upgrading xterm: 287 - 287_1
 Upgrading Thunar: 1.4.0_2 - 1.4.0_3
 Upgrading goffice: 0.8.17_2 - 0.8.17_3
 Upgrading ImageMagick: 6.7.9.4 - 6.8.0.7
 Upgrading wireshark: 1.8.3 - 1.8.3_1
 
 Upgrading Thunar from 1.4.0_2 to 1.4.0_3...Shared object libpcre.so.1 not 
 found, required by update-desktop-database
 Shared object libpcre.so.1 not found, required by update-desktop-database
  done
 
 # pkg which `which update-desktop-database`
 /usr/local/bin/update-desktop-database was installed by package 
 desktop-file-utils-0.18
 
 Terminal:
 libpcre.so.1 = not found (0)
 
 exo-desktop-item-edit:
 libxcb-util.so.0 = not found (0)
 libpcre.so.1 = not found (0)
 libpcre.so.3 = /usr/local/lib/libpcre.so.3 (0x807942000)
 
 mousepad:
 libxcb-util.so.0 = not found (0)
 libxcb-util.so.1 = /usr/local/lib/libxcb-util.so.1 (0x807749000)
 libpcre.so.1 = not found (0)
 libpcre.so.3 = /usr/local/lib/libpcre.so.3 (0x80794e000)
 
 I think either more port version bumps are needed, or an entry in UPDATING.
 The UPDATING entry for perl is still wrong, I discussed on a list that it
 should not contain -x in the pkg command but it still does.  The -x will make
 it install unwanted things.

 ___
 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
 

___
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


[RFC/HEADSUP] portmaster default -w (preserve shared libraries)

2012-12-11 Thread Bryan Drewery
(As maintainer) I'm proposing to make -w the default for portmaster.
This will preserve old shared libraries when upgrading. This helps 2 things:

1. Prevents a broken system during upgrades
2. Prevents a broken system after upgrading for ports that did not get a
PORTREVISION bump from a shared library update.

You have certainly ran into this problem with large library updates such
as png, pcre, openssl, etc.

Portupgrade has always done this as default, and I have never seen any
problems arise from it. It also cleans up prevents duplicated library
versions. If portmaster is not already doing this, I will ensure it does.

You could then use pkg_libchk to rebuild any lingering ports if you
wanted to ensure your system was using the latest. Then cleanout the
preserved shared library.

Of course there will be a way to stick to the old default of not
preserving the libraries.

Someone may consider this a POLA violation, but I consider that a broken
system from missing libraries and PORTREVISION bumps is more of a POLA
violation.


The other option to ensuring that all ports work correctly after a
shared library update is to just rebuild any port which recursively is
affected by another port being updated. I think this is fine in
scenarios such as tinderbox/poudriere, but with end-user compiling ports
on their system, this may quickly become too much of a burden.


Regards,
Bryan Drewery




signature.asc
Description: OpenPGP digital signature


Re: [RFC/HEADSUP] portmaster default -w (preserve shared libraries)

2012-12-11 Thread Kimmo Paasiala
On Tue, Dec 11, 2012 at 5:55 PM, Bryan Drewery bdrew...@freebsd.org wrote:
 (As maintainer) I'm proposing to make -w the default for portmaster.
 This will preserve old shared libraries when upgrading. This helps 2 things:

 1. Prevents a broken system during upgrades
 2. Prevents a broken system after upgrading for ports that did not get a
 PORTREVISION bump from a shared library update.

 You have certainly ran into this problem with large library updates such
 as png, pcre, openssl, etc.

 Portupgrade has always done this as default, and I have never seen any
 problems arise from it. It also cleans up prevents duplicated library
 versions. If portmaster is not already doing this, I will ensure it does.

 You could then use pkg_libchk to rebuild any lingering ports if you
 wanted to ensure your system was using the latest. Then cleanout the
 preserved shared library.

 Of course there will be a way to stick to the old default of not
 preserving the libraries.

 Someone may consider this a POLA violation, but I consider that a broken
 system from missing libraries and PORTREVISION bumps is more of a POLA
 violation.


 The other option to ensuring that all ports work correctly after a
 shared library update is to just rebuild any port which recursively is
 affected by another port being updated. I think this is fine in
 scenarios such as tinderbox/poudriere, but with end-user compiling ports
 on their system, this may quickly become too much of a burden.


 Regards,
 Bryan Drewery



Absolutely yes from me. The -w option is real lifesaver and should be
on by default.

-Kimmo
___
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: recent port upgrades causing missing libraries

2012-12-11 Thread Jeremy Messenger
On Tue, Dec 11, 2012 at 9:45 AM, Bryan Drewery bryan-li...@shatow.net wrote:
 On 12/11/2012 9:03 AM, Adam McDougall wrote:
 I used poudriere to build pkgng packages from the latest round
 of port updates since the freeze.  I know in the commit message
 for xcb-util it bumped some other ports, but it seems like not
 enough to make poudriere reinstall enough packages to make things
 work.


 Poudriere does the right thing here, it recompiles all affected ports.

 The pcre upgrade also caused some problems.  I'm sorry that
 I don't have time to make an extensive report of ports vs. libraries
 or a PR but I can add some brief details.  Using pkg install -fR
 on xcb-util and pcre cured the issues for now, but that doesn't mean
 I've caught them all.  pkg_libchk doesn't work with pkgng.  I could
 have told pkg to reinstall all packages but that is a big hammer.

 The problem then comes here, pkgng doesn't automatically know that ports
 have been rebuilt (without PORTREVISION bumps) or that their checksums
 do not match, unless you use pkg install -fR on the proper packages.

 I've written a script that does the same as `portmaster -w`, which will
 preserve old libraries when running `pkg upgrade`, which will at least
 prevent a broken system while you use pkg_libchk to force reinstall
 affected packages:

 https://gist.github.com/3099160

I don't think the 'portmaster -w' will help with his issue. His issue
is pretty mess up, because his binaries below have been compiled with
old and new library at the same time. For some reason, it doesn't
uninstall (or move when use 'portmaster -w') old libraries first
before build with new libraries.

 Reinstalling libiconv-1.14
 Upgrading pcre: 8.31_1 - 8.32
 Upgrading png: 1.5.12 - 1.5.13
 Upgrading jpeg: 8_3 - 8_4
 Upgrading xcb-util: 0.3.8,1 - 0.3.9_1,1
 Upgrading glib: 2.28.8_4 - 2.28.8_5
 Upgrading tiff: 4.0.2_1 - 4.0.3
 Upgrading gobject-introspection: 0.10.8_2 - 0.10.8_3
 Upgrading cairo: 1.10.2_4,2 - 1.10.2_5,2
 Reinstalling ghostscript9-nox11-9.06_1
 Upgrading pciids: 20120906 - 20121208
 Upgrading startup-notification: 0.12 - 0.12_1
 Upgrading openldap-client: 2.4.33 - 2.4.33_1
 Upgrading cups-client: 1.5.2_2 - 1.5.4
 Upgrading postfix: 2.9.4,1 - 2.9.4_2,1
 Upgrading binutils: 2.22_3 - 2.23.1
 Upgrading javavmwrapper: 2.4_2 - 2.4_3
 Upgrading xterm: 287 - 287_1
 Upgrading Thunar: 1.4.0_2 - 1.4.0_3
 Upgrading goffice: 0.8.17_2 - 0.8.17_3
 Upgrading ImageMagick: 6.7.9.4 - 6.8.0.7
 Upgrading wireshark: 1.8.3 - 1.8.3_1

 Upgrading Thunar from 1.4.0_2 to 1.4.0_3...Shared object libpcre.so.1 not 
 found, required by update-desktop-database
 Shared object libpcre.so.1 not found, required by update-desktop-database
  done

 # pkg which `which update-desktop-database`
 /usr/local/bin/update-desktop-database was installed by package 
 desktop-file-utils-0.18

 Terminal:
 libpcre.so.1 = not found (0)

 exo-desktop-item-edit:
 libxcb-util.so.0 = not found (0)
 libpcre.so.1 = not found (0)
 libpcre.so.3 = /usr/local/lib/libpcre.so.3 (0x807942000)

 mousepad:
 libxcb-util.so.0 = not found (0)
 libxcb-util.so.1 = /usr/local/lib/libxcb-util.so.1 (0x807749000)
 libpcre.so.1 = not found (0)
 libpcre.so.3 = /usr/local/lib/libpcre.so.3 (0x80794e000)

 I think either more port version bumps are needed, or an entry in UPDATING.
 The UPDATING entry for perl is still wrong, I discussed on a list that it
 should not contain -x in the pkg command but it still does.  The -x will make
 it install unwanted things.

 ___
 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


 ___
 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



-- 
mezz.free...@gmail.com - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@freebsd.org
___
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: [RFC/HEADSUP] portmaster default -w (preserve shared libraries)

2012-12-11 Thread Chris Rees
On 11 Dec 2012 15:55, Bryan Drewery bdrew...@freebsd.org wrote:

 (As maintainer) I'm proposing to make -w the default for portmaster.
 This will preserve old shared libraries when upgrading. This helps 2
things:

 1. Prevents a broken system during upgrades
 2. Prevents a broken system after upgrading for ports that did not get a
 PORTREVISION bump from a shared library update.

 You have certainly ran into this problem with large library updates such
 as png, pcre, openssl, etc.

 Portupgrade has always done this as default, and I have never seen any
 problems arise from it. It also cleans up prevents duplicated library
 versions. If portmaster is not already doing this, I will ensure it does.

 You could then use pkg_libchk to rebuild any lingering ports if you
 wanted to ensure your system was using the latest. Then cleanout the
 preserved shared library.

 Of course there will be a way to stick to the old default of not
 preserving the libraries.

Yes, this is a great idea.

Chris
___
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: recent port upgrades causing missing libraries

2012-12-11 Thread Bryan Drewery
On 12/11/2012 10:21 AM, Jeremy Messenger wrote:
 On Tue, Dec 11, 2012 at 9:45 AM, Bryan Drewery bryan-li...@shatow.net wrote:
 On 12/11/2012 9:03 AM, Adam McDougall wrote:
 I used poudriere to build pkgng packages from the latest round
 of port updates since the freeze.  I know in the commit message
 for xcb-util it bumped some other ports, but it seems like not
 enough to make poudriere reinstall enough packages to make things
 work.


 Poudriere does the right thing here, it recompiles all affected ports.

 The pcre upgrade also caused some problems.  I'm sorry that
 I don't have time to make an extensive report of ports vs. libraries
 or a PR but I can add some brief details.  Using pkg install -fR
 on xcb-util and pcre cured the issues for now, but that doesn't mean
 I've caught them all.  pkg_libchk doesn't work with pkgng.  I could
 have told pkg to reinstall all packages but that is a big hammer.

 The problem then comes here, pkgng doesn't automatically know that ports
 have been rebuilt (without PORTREVISION bumps) or that their checksums
 do not match, unless you use pkg install -fR on the proper packages.

 I've written a script that does the same as `portmaster -w`, which will
 preserve old libraries when running `pkg upgrade`, which will at least
 prevent a broken system while you use pkg_libchk to force reinstall
 affected packages:

 https://gist.github.com/3099160
 
 I don't think the 'portmaster -w' will help with his issue. His issue
 is pretty mess up, because his binaries below have been compiled with
 old and new library at the same time. For some reason, it doesn't
 uninstall (or move when use 'portmaster -w') old libraries first
 before build with new libraries.

There's no portmaster involved here. I only mention it as an example.
This is purely pkgng using binary packages.

 
 Reinstalling libiconv-1.14
 Upgrading pcre: 8.31_1 - 8.32
 Upgrading png: 1.5.12 - 1.5.13
 Upgrading jpeg: 8_3 - 8_4
 Upgrading xcb-util: 0.3.8,1 - 0.3.9_1,1
 Upgrading glib: 2.28.8_4 - 2.28.8_5
 Upgrading tiff: 4.0.2_1 - 4.0.3
 Upgrading gobject-introspection: 0.10.8_2 - 0.10.8_3
 Upgrading cairo: 1.10.2_4,2 - 1.10.2_5,2
 Reinstalling ghostscript9-nox11-9.06_1
 Upgrading pciids: 20120906 - 20121208
 Upgrading startup-notification: 0.12 - 0.12_1
 Upgrading openldap-client: 2.4.33 - 2.4.33_1
 Upgrading cups-client: 1.5.2_2 - 1.5.4
 Upgrading postfix: 2.9.4,1 - 2.9.4_2,1
 Upgrading binutils: 2.22_3 - 2.23.1
 Upgrading javavmwrapper: 2.4_2 - 2.4_3
 Upgrading xterm: 287 - 287_1
 Upgrading Thunar: 1.4.0_2 - 1.4.0_3
 Upgrading goffice: 0.8.17_2 - 0.8.17_3
 Upgrading ImageMagick: 6.7.9.4 - 6.8.0.7
 Upgrading wireshark: 1.8.3 - 1.8.3_1

 Upgrading Thunar from 1.4.0_2 to 1.4.0_3...Shared object libpcre.so.1 not 
 found, required by update-desktop-database
 Shared object libpcre.so.1 not found, required by 
 update-desktop-database
  done

 # pkg which `which update-desktop-database`
 /usr/local/bin/update-desktop-database was installed by package 
 desktop-file-utils-0.18

 Terminal:
 libpcre.so.1 = not found (0)

 exo-desktop-item-edit:
 libxcb-util.so.0 = not found (0)
 libpcre.so.1 = not found (0)
 libpcre.so.3 = /usr/local/lib/libpcre.so.3 (0x807942000)

 mousepad:
 libxcb-util.so.0 = not found (0)
 libxcb-util.so.1 = /usr/local/lib/libxcb-util.so.1 (0x807749000)
 libpcre.so.1 = not found (0)
 libpcre.so.3 = /usr/local/lib/libpcre.so.3 (0x80794e000)

 I think either more port version bumps are needed, or an entry in UPDATING.
 The UPDATING entry for perl is still wrong, I discussed on a list that it
 should not contain -x in the pkg command but it still does.  The -x will 
 make
 it install unwanted things.

 ___
 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


 ___
 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
 
 
 

___
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: [RFC/HEADSUP] portmaster default -w (preserve shared libraries)

2012-12-11 Thread Hajimu UMEMOTO
Hi,

 On Tue, 11 Dec 2012 16:21:31 +
 Chris Rees utis...@gmail.com said:

utisoft On 11 Dec 2012 15:55, Bryan Drewery bdrew...@freebsd.org wrote:

 (As maintainer) I'm proposing to make -w the default for portmaster.
 This will preserve old shared libraries when upgrading. This helps 2
utisoft things:

 1. Prevents a broken system during upgrades
 2. Prevents a broken system after upgrading for ports that did not get a
 PORTREVISION bump from a shared library update.

 You have certainly ran into this problem with large library updates such
 as png, pcre, openssl, etc.

 Portupgrade has always done this as default, and I have never seen any
 problems arise from it. It also cleans up prevents duplicated library
 versions. If portmaster is not already doing this, I will ensure it does.

 You could then use pkg_libchk to rebuild any lingering ports if you
 wanted to ensure your system was using the latest. Then cleanout the
 preserved shared library.

 Of course there will be a way to stick to the old default of not
 preserving the libraries.

utisoft Yes, this is a great idea.

+1

Sincerely,

--
Hajimu UMEMOTO
u...@mahoroba.org  ume@{,jp.}FreeBSD.org
http://www.mahoroba.org/~ume/
___
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: [RFC/HEADSUP] portmaster default -w (preserve shared libraries)

2012-12-11 Thread Jeremy Messenger
On Tue, Dec 11, 2012 at 10:16 AM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Tue, Dec 11, 2012 at 5:55 PM, Bryan Drewery bdrew...@freebsd.org wrote:
 (As maintainer) I'm proposing to make -w the default for portmaster.
 This will preserve old shared libraries when upgrading. This helps 2 things:

 1. Prevents a broken system during upgrades
 2. Prevents a broken system after upgrading for ports that did not get a
 PORTREVISION bump from a shared library update.

 You have certainly ran into this problem with large library updates such
 as png, pcre, openssl, etc.

 Portupgrade has always done this as default, and I have never seen any
 problems arise from it. It also cleans up prevents duplicated library
 versions. If portmaster is not already doing this, I will ensure it does.

 You could then use pkg_libchk to rebuild any lingering ports if you
 wanted to ensure your system was using the latest. Then cleanout the
 preserved shared library.

 Of course there will be a way to stick to the old default of not
 preserving the libraries.

 Someone may consider this a POLA violation, but I consider that a broken
 system from missing libraries and PORTREVISION bumps is more of a POLA
 violation.


 The other option to ensuring that all ports work correctly after a
 shared library update is to just rebuild any port which recursively is
 affected by another port being updated. I think this is fine in
 scenarios such as tinderbox/poudriere, but with end-user compiling ports
 on their system, this may quickly become too much of a burden.


 Regards,
 Bryan Drewery



 Absolutely yes from me. The -w option is real lifesaver and should be
 on by default.

I disagree. The -w is a temp fix and not a correct solution, so it
shouldn't be default.

 -Kimmo


-- 
mezz.free...@gmail.com - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@freebsd.org
___
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: [RFC/HEADSUP] portmaster default -w (preserve shared libraries)

2012-12-11 Thread Alex Dupre
Jeremy Messenger ha scritto:

 Absolutely yes from me. The -w option is real lifesaver and should be
 on by default.
 
 I disagree. The -w is a temp fix and not a correct solution, so it
 shouldn't be default.

I agree with your disagreement :-)

-- 
Alex Dupre
___
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: recent port upgrades causing missing libraries

2012-12-11 Thread Jeremy Messenger
On Tue, Dec 11, 2012 at 10:25 AM, Bryan Drewery bryan-li...@shatow.net wrote:
 On 12/11/2012 10:21 AM, Jeremy Messenger wrote:
 On Tue, Dec 11, 2012 at 9:45 AM, Bryan Drewery bryan-li...@shatow.net 
 wrote:
 On 12/11/2012 9:03 AM, Adam McDougall wrote:
 I used poudriere to build pkgng packages from the latest round
 of port updates since the freeze.  I know in the commit message
 for xcb-util it bumped some other ports, but it seems like not
 enough to make poudriere reinstall enough packages to make things
 work.


 Poudriere does the right thing here, it recompiles all affected ports.

 The pcre upgrade also caused some problems.  I'm sorry that
 I don't have time to make an extensive report of ports vs. libraries
 or a PR but I can add some brief details.  Using pkg install -fR
 on xcb-util and pcre cured the issues for now, but that doesn't mean
 I've caught them all.  pkg_libchk doesn't work with pkgng.  I could
 have told pkg to reinstall all packages but that is a big hammer.

 The problem then comes here, pkgng doesn't automatically know that ports
 have been rebuilt (without PORTREVISION bumps) or that their checksums
 do not match, unless you use pkg install -fR on the proper packages.

 I've written a script that does the same as `portmaster -w`, which will
 preserve old libraries when running `pkg upgrade`, which will at least
 prevent a broken system while you use pkg_libchk to force reinstall
 affected packages:

 https://gist.github.com/3099160

 I don't think the 'portmaster -w' will help with his issue. His issue
 is pretty mess up, because his binaries below have been compiled with
 old and new library at the same time. For some reason, it doesn't
 uninstall (or move when use 'portmaster -w') old libraries first
 before build with new libraries.

 There's no portmaster involved here. I only mention it as an example.
 This is purely pkgng using binary packages.

He built his own package by using poudriere. The question is that why
did it allows linked with old and new libraries at the same time? It
should be uninstall old libraries first before compile/link with new
libraries.

 Reinstalling libiconv-1.14
 Upgrading pcre: 8.31_1 - 8.32
 Upgrading png: 1.5.12 - 1.5.13
 Upgrading jpeg: 8_3 - 8_4
 Upgrading xcb-util: 0.3.8,1 - 0.3.9_1,1
 Upgrading glib: 2.28.8_4 - 2.28.8_5
 Upgrading tiff: 4.0.2_1 - 4.0.3
 Upgrading gobject-introspection: 0.10.8_2 - 0.10.8_3
 Upgrading cairo: 1.10.2_4,2 - 1.10.2_5,2
 Reinstalling ghostscript9-nox11-9.06_1
 Upgrading pciids: 20120906 - 20121208
 Upgrading startup-notification: 0.12 - 0.12_1
 Upgrading openldap-client: 2.4.33 - 2.4.33_1
 Upgrading cups-client: 1.5.2_2 - 1.5.4
 Upgrading postfix: 2.9.4,1 - 2.9.4_2,1
 Upgrading binutils: 2.22_3 - 2.23.1
 Upgrading javavmwrapper: 2.4_2 - 2.4_3
 Upgrading xterm: 287 - 287_1
 Upgrading Thunar: 1.4.0_2 - 1.4.0_3
 Upgrading goffice: 0.8.17_2 - 0.8.17_3
 Upgrading ImageMagick: 6.7.9.4 - 6.8.0.7
 Upgrading wireshark: 1.8.3 - 1.8.3_1

 Upgrading Thunar from 1.4.0_2 to 1.4.0_3...Shared object libpcre.so.1 
 not found, required by update-desktop-database
 Shared object libpcre.so.1 not found, required by 
 update-desktop-database
  done

 # pkg which `which update-desktop-database`
 /usr/local/bin/update-desktop-database was installed by package 
 desktop-file-utils-0.18

 Terminal:
 libpcre.so.1 = not found (0)

 exo-desktop-item-edit:
 libxcb-util.so.0 = not found (0)
 libpcre.so.1 = not found (0)
 libpcre.so.3 = /usr/local/lib/libpcre.so.3 (0x807942000)

 mousepad:
 libxcb-util.so.0 = not found (0)
 libxcb-util.so.1 = /usr/local/lib/libxcb-util.so.1 (0x807749000)
 libpcre.so.1 = not found (0)
 libpcre.so.3 = /usr/local/lib/libpcre.so.3 (0x80794e000)

 I think either more port version bumps are needed, or an entry in UPDATING.
 The UPDATING entry for perl is still wrong, I discussed on a list that it
 should not contain -x in the pkg command but it still does.  The -x will 
 make
 it install unwanted things.

 ___
 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


 ___
 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







-- 
mezz.free...@gmail.com - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@freebsd.org
___
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: [RFC/HEADSUP] portmaster default -w (preserve shared libraries)

2012-12-11 Thread Chris Rees
On 11 Dec 2012 16:44, Alex Dupre a...@freebsd.org wrote:

 Jeremy Messenger ha scritto:

  Absolutely yes from me. The -w option is real lifesaver and should be
  on by default.
 
  I disagree. The -w is a temp fix and not a correct solution, so it
  shouldn't be default.

 I agree with your disagreement :-)


I get what you're saying, but please consider which is easier to reverse-
deleting an accidentally saved library, or restoring an accidentally
deleted library?

Defaults should be safe.  I was bitten by this with pcre- sometimes we
can't update all our ports at one time.

How isn't it correct?  We still keep src libraries around until we make
delete-old-libs.  Why should ports be different?

Chris
___
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: [RFC/HEADSUP] portmaster default -w (preserve shared libraries)

2012-12-11 Thread Ronald Klop

On Tue, 11 Dec 2012 18:04:33 +0100, Chris Rees utis...@gmail.com wrote:


On 11 Dec 2012 16:44, Alex Dupre a...@freebsd.org wrote:


Jeremy Messenger ha scritto:

 Absolutely yes from me. The -w option is real lifesaver and should be
 on by default.

 I disagree. The -w is a temp fix and not a correct solution, so it
 shouldn't be default.

I agree with your disagreement :-)



I get what you're saying, but please consider which is easier to reverse-
deleting an accidentally saved library, or restoring an accidentally
deleted library?

Defaults should be safe.  I was bitten by this with pcre- sometimes we
can't update all our ports at one time.

How isn't it correct?  We still keep src libraries around until we make
delete-old-libs.  Why should ports be different?

Chris


Doesn't the ports framework itself also keep the old libraries around in  
/usr/local/lib/compat/pkg or something like that?


Ronald.
___
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: [RFC/HEADSUP] portmaster default -w (preserve shared libraries)

2012-12-11 Thread Mathias Picker
Am Dienstag, den 11.12.2012, 18:16 +0200 schrieb Kimmo Paasiala:
 On Tue, Dec 11, 2012 at 5:55 PM, Bryan Drewery bdrew...@freebsd.org wrote:
  (As maintainer) I'm proposing to make -w the default for portmaster.
  This will preserve old shared libraries when upgrading. This helps 2 things:
 
  1. Prevents a broken system during upgrades
  2. Prevents a broken system after upgrading for ports that did not get a
  PORTREVISION bump from a shared library update.
 
  You have certainly ran into this problem with large library updates such
  as png, pcre, openssl, etc.
 
  Portupgrade has always done this as default, and I have never seen any
  problems arise from it. It also cleans up prevents duplicated library
  versions. If portmaster is not already doing this, I will ensure it does.
 
  You could then use pkg_libchk to rebuild any lingering ports if you
  wanted to ensure your system was using the latest. Then cleanout the
  preserved shared library.
 
  Of course there will be a way to stick to the old default of not
  preserving the libraries.
 
  Someone may consider this a POLA violation, but I consider that a broken
  system from missing libraries and PORTREVISION bumps is more of a POLA
  violation.
 
 
  The other option to ensuring that all ports work correctly after a
  shared library update is to just rebuild any port which recursively is
  affected by another port being updated. I think this is fine in
  scenarios such as tinderbox/poudriere, but with end-user compiling ports
  on their system, this may quickly become too much of a burden.
 
 
  Regards,
  Bryan Drewery
 
 
 
 Absolutely yes from me. The -w option is real lifesaver and should be
 on by default.

+1

Cheers, Mathias

 
 -Kimmo
 ___
 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


___
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: cyrus-sasl

2012-12-11 Thread Franci Nabalanci
It is long way to kdepimlibs...it stopped in avahi-app related with
pcrelibs.so.1 as my wife told me by phone. I am not at home yet.


On Tue, Dec 11, 2012 at 7:28 AM, Hajimu UMEMOTO u...@freebsd.org wrote:

 Hi,

  On Tue, 11 Dec 2012 05:36:48 -0600
  Franci Nabalanci lum...@gmail.com said:

 lumiwa I red that kdepimlibs doesn't build too...

 I've committed the fix to this issue.  Please try the latest one.

 Sincerely,

 --
 Hajimu UMEMOTO
 u...@mahoroba.org  ume@{,jp.}FreeBSD.org
 http://www.mahoroba.org/~ume/

___
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: recent port upgrades causing missing libraries

2012-12-11 Thread Kimmo Paasiala
On Tue, Dec 11, 2012 at 6:57 PM, Jeremy Messenger
mezz.free...@gmail.com wrote:
 On Tue, Dec 11, 2012 at 10:25 AM, Bryan Drewery bryan-li...@shatow.net 
 wrote:
 On 12/11/2012 10:21 AM, Jeremy Messenger wrote:
 On Tue, Dec 11, 2012 at 9:45 AM, Bryan Drewery bryan-li...@shatow.net 
 wrote:
 On 12/11/2012 9:03 AM, Adam McDougall wrote:
 I used poudriere to build pkgng packages from the latest round
 of port updates since the freeze.  I know in the commit message
 for xcb-util it bumped some other ports, but it seems like not
 enough to make poudriere reinstall enough packages to make things
 work.


 Poudriere does the right thing here, it recompiles all affected ports.

 The pcre upgrade also caused some problems.  I'm sorry that
 I don't have time to make an extensive report of ports vs. libraries
 or a PR but I can add some brief details.  Using pkg install -fR
 on xcb-util and pcre cured the issues for now, but that doesn't mean
 I've caught them all.  pkg_libchk doesn't work with pkgng.  I could
 have told pkg to reinstall all packages but that is a big hammer.

 The problem then comes here, pkgng doesn't automatically know that ports
 have been rebuilt (without PORTREVISION bumps) or that their checksums
 do not match, unless you use pkg install -fR on the proper packages.

 I've written a script that does the same as `portmaster -w`, which will
 preserve old libraries when running `pkg upgrade`, which will at least
 prevent a broken system while you use pkg_libchk to force reinstall
 affected packages:

 https://gist.github.com/3099160

 I don't think the 'portmaster -w' will help with his issue. His issue
 is pretty mess up, because his binaries below have been compiled with
 old and new library at the same time. For some reason, it doesn't
 uninstall (or move when use 'portmaster -w') old libraries first
 before build with new libraries.

 There's no portmaster involved here. I only mention it as an example.
 This is purely pkgng using binary packages.

 He built his own package by using poudriere. The question is that why
 did it allows linked with old and new libraries at the same time? It
 should be uninstall old libraries first before compile/link with new
 libraries.


Poudriere is not the problem here because it builds everything
everytime in a clean jail. The problem is the way pkg-install(8)
detects if a package needs to re-installed, if there's no portrevision
bump it won't re-install the package even if the package has been
linked against new shared libraries.

-Kimmo
___
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: pkgng: sqlite: database is locked

2012-12-11 Thread Olli Hauer
On 2012-12-11 15:13, Mathias Picker wrote:
 I'm getting sqlite: database is locked errors with pkg. For deinstalls
 (portmaster updates) and fresh port installs with make install. The
 latest is
 
 ===   Registering installation for MuSE-0.9.2_14
 Installing MuSE-0.9.2_14... done
 pkg: sqlite: database is locked
 
 which results in muse not being registered in the pkg database...
 
 How can I investigate this further? This persists between reboots, and
 for fresh pkg runs. 
 
 I'm hesitating to upgrade all the changes after the ports freeze has
 been lifted...
 
 I'm using a FreeBSD-stable and have changed to pkgng maybe two weeks
 ago. At the first portmaster -a after the upgrade, I think everything
 went smooth, and then more and more of these errors popped up.
 Everything is build using gcc.
 
 mp# uname -a
 FreeBSD mp.virtual-earth.de 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #28
 r243882: Wed Dec  5 18:28:39 CET 2012
 mathi...@mp.virtual-earth.de:/usr/obj/usr/src/sys/GENERIC  amd64
 
 mp# pkg -v
 1.0.3
 
 Any help apreciated,
 
 Mathias
 

Hi Mathias,

maybe you could find with one of the commands the process which
locks the database.

# fstat /var/db/pkg/pkgdb.db /var/db/pkg/local.sqlite
# sockstat | grep -e local.sqlite -e pkgdb.db

--
Regards,
olli
___
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: recent port upgrades causing missing libraries

2012-12-11 Thread Sergey V. Dyatko
On Tue, 11 Dec 2012 09:45:33 -0600
Bryan Drewery bryan-li...@shatow.net wrote:

 On 12/11/2012 9:03 AM, Adam McDougall wrote:
  I used poudriere to build pkgng packages from the latest round
  of port updates since the freeze.  I know in the commit message
  for xcb-util it bumped some other ports, but it seems like not
  enough to make poudriere reinstall enough packages to make things
  work.  
 
 
 Poudriere does the right thing here, it recompiles all affected ports.
 
 The pcre upgrade also caused some problems.  I'm sorry that
  I don't have time to make an extensive report of ports vs. libraries
  or a PR but I can add some brief details.  Using pkg install -fR 
  on xcb-util and pcre cured the issues for now, but that doesn't mean
  I've caught them all.  pkg_libchk doesn't work with pkgng.  I could
  have told pkg to reinstall all packages but that is a big hammer.
 
 The problem then comes here, pkgng doesn't automatically know that
 ports have been rebuilt (without PORTREVISION bumps) or that their
 checksums do not match, unless you use pkg install -fR on the proper
 packages.
 
 I've written a script that does the same as `portmaster -w`, which
 will preserve old libraries when running `pkg upgrade`, which will at
 least prevent a broken system while you use pkg_libchk to force
 reinstall affected packages:

pkg_libchk doesn't work with pkgng. Dirty patch I used today:
http://svn.freebsd.by/files/patch-pkg_libchk-pkgng

btw, ports/174361

 
 https://gist.github.com/3099160
 
 
  
  Reinstalling libiconv-1.14
  Upgrading pcre: 8.31_1 - 8.32
  Upgrading png: 1.5.12 - 1.5.13
  Upgrading jpeg: 8_3 - 8_4
  Upgrading xcb-util: 0.3.8,1 - 0.3.9_1,1
  Upgrading glib: 2.28.8_4 - 2.28.8_5
  Upgrading tiff: 4.0.2_1 - 4.0.3
  Upgrading gobject-introspection: 0.10.8_2 - 0.10.8_3
  Upgrading cairo: 1.10.2_4,2 - 1.10.2_5,2
  Reinstalling ghostscript9-nox11-9.06_1
  Upgrading pciids: 20120906 - 20121208
  Upgrading startup-notification: 0.12 - 0.12_1
  Upgrading openldap-client: 2.4.33 - 2.4.33_1
  Upgrading cups-client: 1.5.2_2 - 1.5.4
  Upgrading postfix: 2.9.4,1 - 2.9.4_2,1
  Upgrading binutils: 2.22_3 - 2.23.1
  Upgrading javavmwrapper: 2.4_2 - 2.4_3
  Upgrading xterm: 287 - 287_1
  Upgrading Thunar: 1.4.0_2 - 1.4.0_3
  Upgrading goffice: 0.8.17_2 - 0.8.17_3
  Upgrading ImageMagick: 6.7.9.4 - 6.8.0.7
  Upgrading wireshark: 1.8.3 - 1.8.3_1
  
  Upgrading Thunar from 1.4.0_2 to 1.4.0_3...Shared object
  libpcre.so.1 not found, required by update-desktop-database
  Shared object libpcre.so.1 not found, required by
  update-desktop-database done
  
  # pkg which `which update-desktop-database`
  /usr/local/bin/update-desktop-database was installed by package
  desktop-file-utils-0.18
  
  Terminal:
  libpcre.so.1 = not found (0)
  
  exo-desktop-item-edit:
  libxcb-util.so.0 = not found (0)
  libpcre.so.1 = not found (0)
  libpcre.so.3 = /usr/local/lib/libpcre.so.3 (0x807942000)
  
  mousepad:
  libxcb-util.so.0 = not found (0)
  libxcb-util.so.1 = /usr/local/lib/libxcb-util.so.1
  (0x807749000) libpcre.so.1 = not found (0)
  libpcre.so.3 = /usr/local/lib/libpcre.so.3 (0x80794e000)
  
  I think either more port version bumps are needed, or an entry in
  UPDATING. The UPDATING entry for perl is still wrong, I discussed
  on a list that it should not contain -x in the pkg command but it
  still does.  The -x will make it install unwanted things.
 



-- 
wbr, tiger
___
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: [RFC/HEADSUP] portmaster default -w (preserve shared libraries)

2012-12-11 Thread Scot Hetzel
On Tue, Dec 11, 2012 at 11:08 AM, Ronald Klop
ronald-freeb...@klop.yi.org wrote:
 On Tue, 11 Dec 2012 18:04:33 +0100, Chris Rees utis...@gmail.com wrote:

 On 11 Dec 2012 16:44, Alex Dupre a...@freebsd.org wrote:


 Jeremy Messenger ha scritto:

  Absolutely yes from me. The -w option is real lifesaver and should be
  on by default.
 
  I disagree. The -w is a temp fix and not a correct solution, so it
  shouldn't be default.

 I agree with your disagreement :-)


 I get what you're saying, but please consider which is easier to reverse-
 deleting an accidentally saved library, or restoring an accidentally
 deleted library?

 Defaults should be safe.  I was bitten by this with pcre- sometimes we
 can't update all our ports at one time.

 How isn't it correct?  We still keep src libraries around until we make
 delete-old-libs.  Why should ports be different?

 Chris


 Doesn't the ports framework itself also keep the old libraries around in
 /usr/local/lib/compat/pkg or something like that?

The ports framework doesn't keep old libraries.  Tools such as
portupgrade and portmaster may be configured to keep old libraries
when upgrading the port.

-- 
DISCLAIMER:

No electrons were mamed while sending this message. Only slightly bruised.
___
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: pkgng: sqlite: database is locked

2012-12-11 Thread Mathias Picker
Am Dienstag, den 11.12.2012, 19:02 +0100 schrieb Olli Hauer:
 On 2012-12-11 15:13, Mathias Picker wrote:
  I'm getting sqlite: database is locked errors with pkg. For deinstalls
  (portmaster updates) and fresh port installs with make install. The
  latest is
  
  ===   Registering installation for MuSE-0.9.2_14
  Installing MuSE-0.9.2_14... done
  pkg: sqlite: database is locked
  
  which results in muse not being registered in the pkg database...
  
  How can I investigate this further? This persists between reboots, and
  for fresh pkg runs. 
  
  I'm hesitating to upgrade all the changes after the ports freeze has
  been lifted...
  
  I'm using a FreeBSD-stable and have changed to pkgng maybe two weeks
  ago. At the first portmaster -a after the upgrade, I think everything
  went smooth, and then more and more of these errors popped up.
  Everything is build using gcc.
  
  mp# uname -a
  FreeBSD mp.virtual-earth.de 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #28
  r243882: Wed Dec  5 18:28:39 CET 2012
  mathi...@mp.virtual-earth.de:/usr/obj/usr/src/sys/GENERIC  amd64
  
  mp# pkg -v
  1.0.3
  
  Any help apreciated,
  
  Mathias
  
 
 Hi Mathias,
 
 maybe you could find with one of the commands the process which
 locks the database.
 
 # fstat /var/db/pkg/pkgdb.db /var/db/pkg/local.sqlite
 # sockstat | grep -e local.sqlite -e pkgdb.db

OK:
mp# fstat /var/db/pkg/pkgdb.db /var/db/pkg/local.sqlite
USER CMD  PID   FD MOUNT  INUM MODE SZ|DV R/W
NAME
mp# sockstat | grep -e local.sqlite -e pkgdb.db
mp# 

I retried the muse install which gave me an error before, now it works
fine?? Maybe it's only after portmaster runs?

Maybe a pkg invocation which does not release the lock? I will look into
this again.

Thanks, Mathias

 
 --
 Regards,
 olli
 ___
 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


___
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: pkgng: sqlite: database is locked

2012-12-11 Thread Baptiste Daroussin
On Tue, Dec 11, 2012 at 07:32:03PM +0100, Mathias Picker wrote:
 Am Dienstag, den 11.12.2012, 19:02 +0100 schrieb Olli Hauer:
  On 2012-12-11 15:13, Mathias Picker wrote:
   I'm getting sqlite: database is locked errors with pkg. For deinstalls
   (portmaster updates) and fresh port installs with make install. The
   latest is
   
   ===   Registering installation for MuSE-0.9.2_14
   Installing MuSE-0.9.2_14... done
   pkg: sqlite: database is locked
   
   which results in muse not being registered in the pkg database...
   
   How can I investigate this further? This persists between reboots, and
   for fresh pkg runs. 
   
   I'm hesitating to upgrade all the changes after the ports freeze has
   been lifted...
   
   I'm using a FreeBSD-stable and have changed to pkgng maybe two weeks
   ago. At the first portmaster -a after the upgrade, I think everything
   went smooth, and then more and more of these errors popped up.
   Everything is build using gcc.
   
   mp# uname -a
   FreeBSD mp.virtual-earth.de 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #28
   r243882: Wed Dec  5 18:28:39 CET 2012
   mathi...@mp.virtual-earth.de:/usr/obj/usr/src/sys/GENERIC  amd64
   
   mp# pkg -v
   1.0.3
   
   Any help apreciated,
   
   Mathias
   
  
  Hi Mathias,
  
  maybe you could find with one of the commands the process which
  locks the database.
  
  # fstat /var/db/pkg/pkgdb.db /var/db/pkg/local.sqlite
  # sockstat | grep -e local.sqlite -e pkgdb.db
 
 OK:
 mp# fstat /var/db/pkg/pkgdb.db /var/db/pkg/local.sqlite
 USER CMD  PID   FD MOUNT  INUM MODE SZ|DV R/W
 NAME
 mp# sockstat | grep -e local.sqlite -e pkgdb.db
 mp# 
 
 I retried the muse install which gave me an error before, now it works
 fine?? Maybe it's only after portmaster runs?
 
 Maybe a pkg invocation which does not release the lock? I will look into
 this again.
 

The lock is always release at the end of the pkg invocation, the only way to get
there is multiple pkg running at the same time and even there the lock should
stay for long.

If you manage to reproduce I'd be very intersted in the way how to reproduce
and/or the debug information :)

regards,
Bapt


pgpC67c0CvqYP.pgp
Description: PGP signature


Re: [RFC/HEADSUP] portmaster default -w (preserve shared libraries)

2012-12-11 Thread Alex Dupre

Chris Rees ha scritto:

I get what you're saying, but please consider which is easier to reverse-
deleting an accidentally saved library, or restoring an accidentally
deleted library?


Unluckily it's not so simple...


Defaults should be safe.  I was bitten by this with pcre- sometimes we
can't update all our ports at one time.

How isn't it correct?


For simple ports it may works correctly, but for others it could happen 
that finally both revisions are linked into a library or executable 
(because one !recompiled dependency depends on the old version and 
another recompiled dependency depends on the new version) and this is 
not good. So the correct thing is to always recompile ports to get the 
new version, the 'keep old libs' flags should be used with caution (this 
is why I prefer it to be opt-in and not opt-out).



We still keep src libraries around until we make
delete-old-libs.  Why should ports be different?


Also for src the policy is: don't recompile any ports after an upgrade, 
or recompile them all, exactly for this reason.


--
Alex Dupre
___
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: [RFC/HEADSUP] portmaster default -w (preserve shared libraries)

2012-12-11 Thread Jeremy Messenger
On Tue, Dec 11, 2012 at 11:04 AM, Chris Rees utis...@gmail.com wrote:

 On 11 Dec 2012 16:44, Alex Dupre a...@freebsd.org wrote:

 Jeremy Messenger ha scritto:

  Absolutely yes from me. The -w option is real lifesaver and should be
  on by default.
 
  I disagree. The -w is a temp fix and not a correct solution, so it
  shouldn't be default.

 I agree with your disagreement :-)


 I get what you're saying, but please consider which is easier to reverse-
 deleting an accidentally saved library, or restoring an accidentally deleted
 library?

I don't see how you can accident delete library. If you accident
deleted it. It won't be in another place because you already deleted
it as our ports only install a library without backup. :-) When ports
uninstall that deleted a library isn't an accident or it will be a
bug.

 Defaults should be safe.  I was bitten by this with pcre- sometimes we can't
 update all our ports at one time.

If can't update all ports then please wait until when you can. I never
have any problem to update all ports at a time by ran it over night
time. Or even better, use packages if you can't afford the ports
system.

 How isn't it correct?

-When a main app that linked with main library. The main library
linked with foo libray that has linked old library and bar library
that linked with new library. Then the main app try to run it and
cause some weird problem. It was hard to debug it until I asked user
to ran ldconfig. Don't know if my english is clear, but drawing a
picture below.

main app
  |
  main library
   /\
 foo libbar lib
/ \
   old lib  new lib

-I have seen it before when somehow ports compiled with old library
from lib/compat/pkg with new library by accident because of user's
custom tweak.

-Security issue. Users forgot (or don't know about it if
lib/compat/pkg is default) to complete the upgrade.

-We should never hide a real problem by default. Repeat, never hide problem.

When you decide to upgrade library and you need to have everything
that depend on it to be recompiled. Move old library in the different
place are supposed to be only for temp until you have compiled all
ports with the updated library. So that way you can have your
apps/desktop running while you are compiling/updating.

GNOME have tons and tons of libraries with complicate dependencies.
Turn it on by default worry me, because it is hard to debug this issue
than have app dead with error to tell you that you have missing
library.

  We still keep src libraries around until we make
 delete-old-libs.  Why should ports be different?

See Alex's replied and add here:

Have you seen bug reports because they didn't ran delete-old* before?
Well, I have from some users.  Without run delete-old* even effected
on ports (ie: I remember libcrypt and libusb issue).

IMO the delete-old* shouldn't be default because this option is not
only for upgrade. It's also for if you want to delete extra stuff. If
the delete-old* split function by one for only delete old stuff for
upgrade then this one should be default. Another function should be
disable by default until users want to delete extra stuff.

 Chris


-- 
mezz.free...@gmail.com - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@freebsd.org
___
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: recent port upgrades causing missing libraries

2012-12-11 Thread Jeremy Messenger
On Tue, Dec 11, 2012 at 11:58 AM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Tue, Dec 11, 2012 at 6:57 PM, Jeremy Messenger
 mezz.free...@gmail.com wrote:
 On Tue, Dec 11, 2012 at 10:25 AM, Bryan Drewery bryan-li...@shatow.net 
 wrote:
 On 12/11/2012 10:21 AM, Jeremy Messenger wrote:
 On Tue, Dec 11, 2012 at 9:45 AM, Bryan Drewery bryan-li...@shatow.net 
 wrote:
 On 12/11/2012 9:03 AM, Adam McDougall wrote:
 I used poudriere to build pkgng packages from the latest round
 of port updates since the freeze.  I know in the commit message
 for xcb-util it bumped some other ports, but it seems like not
 enough to make poudriere reinstall enough packages to make things
 work.


 Poudriere does the right thing here, it recompiles all affected ports.

 The pcre upgrade also caused some problems.  I'm sorry that
 I don't have time to make an extensive report of ports vs. libraries
 or a PR but I can add some brief details.  Using pkg install -fR
 on xcb-util and pcre cured the issues for now, but that doesn't mean
 I've caught them all.  pkg_libchk doesn't work with pkgng.  I could
 have told pkg to reinstall all packages but that is a big hammer.

 The problem then comes here, pkgng doesn't automatically know that ports
 have been rebuilt (without PORTREVISION bumps) or that their checksums
 do not match, unless you use pkg install -fR on the proper packages.

 I've written a script that does the same as `portmaster -w`, which will
 preserve old libraries when running `pkg upgrade`, which will at least
 prevent a broken system while you use pkg_libchk to force reinstall
 affected packages:

 https://gist.github.com/3099160

 I don't think the 'portmaster -w' will help with his issue. His issue
 is pretty mess up, because his binaries below have been compiled with
 old and new library at the same time. For some reason, it doesn't
 uninstall (or move when use 'portmaster -w') old libraries first
 before build with new libraries.

 There's no portmaster involved here. I only mention it as an example.
 This is purely pkgng using binary packages.

 He built his own package by using poudriere. The question is that why
 did it allows linked with old and new libraries at the same time? It
 should be uninstall old libraries first before compile/link with new
 libraries.


 Poudriere is not the problem here because it builds everything
 everytime in a clean jail. The problem is the way pkg-install(8)
 detects if a package needs to re-installed, if there's no portrevision
 bump it won't re-install the package even if the package has been
 linked against new shared libraries.

Okay, don't really know much about poudriere so let's drop on this.

If the PORTREVISION wasn't bump then how did his moused got rebuilt?
If you look at the mousepad (orignal email's log that you have snipped
out) and you will see that it got linked with old and new two
libraries at the same time because the tool didn't uninstall old
library first before rebuild other ports. That kind of bug needs to be
figured out if it's tool fault.

 -Kimmo



-- 
mezz.free...@gmail.com - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@freebsd.org
___
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


downloading source code from github

2012-12-11 Thread Radim Kolar
its good practice to download source code using git from github if it is 
not available for download, just tagged in repo?

___
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: Compiz problem - Undefined symbol animGetI

2012-12-11 Thread Dimitry Andric

On 2012-12-08 20:32, AN wrote:
...

I believe this is related to the switch to clang because the same hardware
was configured the same way previously, the only difference is that the
system where Compiz was working was compiled with GCC 4.2.

When I run the following on the command line:

compiz --replace --sm-disable --ignore-desktop-hints ccp 
gtk-window-decorator --replace 

I get:

/usr/local/lib/compiz/libanimation.so Undefined symbol animGetI


Please try applying the attached patch (easiest is to use svn patch from
the root of your ports tree).  This fixes a number of problems with
inline functions in compiz-plugins-main.
Index: x11-wm/compiz-plugins-main/files/patch-include__compiz-animation.h
===
--- x11-wm/compiz-plugins-main/files/patch-include__compiz-animation.h	(revision 0)
+++ x11-wm/compiz-plugins-main/files/patch-include__compiz-animation.h	(working copy)
@@ -0,0 +1,81 @@
+--- include/compiz-animation.h.orig	2009-10-14 03:01:42.0 +0200
 include/compiz-animation.h	2012-12-10 00:51:30.0 +0100
+@@ -215,7 +215,7 @@ typedef struct _AnimBaseFunctions {
+ 
+ #define OPTION_GETTERS(extensionBaseFunctions,\
+ 		   extensionPluginInfo, firstEffectOption)		\
+-static inline CompOptionValue *		\
++extern inline CompOptionValue *		\
+ animGetOptVal (CompWindow *w,		\
+ 	   int optionId)		\
+ {	\
+@@ -223,35 +223,35 @@ animGetOptVal (CompWindow *w,		\
+ 	(w, (extensionPluginInfo), optionId - (firstEffectOption));	\
+ }		\
+ 		\
+-inline Bool	\
++extern inline Bool\
+ animGetB (CompWindow *w,			\
+ 	  int optionId)\
+ {		\
+ return animGetOptVal (w, optionId)-b;	\
+ }		\
+ 		\
+-inline int	\
++extern inline int\
+ animGetI (CompWindow *w,			\
+ 	  int optionId)\
+ {		\
+ return animGetOptVal (w, optionId)-i;	\
+ }		\
+ 		\
+-inline float	\
++extern inline float\
+ animGetF (CompWindow *w,			\
+ 	  int optionId)\
+ {		\
+ return animGetOptVal (w, optionId)-f;	\
+ }		\
+ 		\
+-inline char *	\
++extern inline char *\
+ animGetS (CompWindow *w,			\
+ 	  int optionId)\
+ {		\
+ return animGetOptVal (w, optionId)-s;	\
+ }		\
+ 		\
+-inline unsigned short *\
++extern inline unsigned short *			\
+ animGetC (CompWindow *w,			\
+ 	  int optionId)\
+ {		\
+@@ -260,23 +260,23 @@ animGetC (CompWindow *w,			\
+ 
+ #define OPTION_GETTERS_HDR			\
+ 		\
+-inline Bool	\
++extern inline Bool\
+ animGetB (CompWindow *w,			\
+ 	  int optionId);			\
+ 		\
+-inline int	\
++extern inline int\
+ animGetI (CompWindow *w,			\
+ 	  int optionId);			\
+ 		\
+-inline float	\
++extern inline float\
+ animGetF (CompWindow *w,			\
+ 	  int optionId);			\
+ 		\
+-inline char *	\
++extern inline char *\
+ animGetS (CompWindow *w,			\
+ 	  int optionId);			\
+ 		\
+-inline unsigned short *\
++extern inline unsigned short *			\
+ animGetC (CompWindow *w,			\
+ 	  int optionId);
+ 
Index: x11-wm/compiz-plugins-main/files/patch-src__animation__animation-internal.h
===
--- x11-wm/compiz-plugins-main/files/patch-src__animation__animation-internal.h	(revision 0)
+++ x11-wm/compiz-plugins-main/files/patch-src__animation__animation-internal.h	(working copy)
@@ -0,0 +1,20 @@
+--- src/animation/animation-internal.h.orig	2009-10-14 03:01:42.0 +0200
 src/animation/animation-internal.h	2012-12-10 00:55:13.0 +0100
+@@ -429,7 +429,7 @@ applyPerspectiveSkew (CompOutput *output
+ 		  CompTransform *transform,
+ 		  Point *center);
+ 
+-inline void
++extern inline void
+ applyTransform (CompTransform *wTransform,
+ 		CompTransform *transform);
+ 
+@@ -616,7 +616,7 @@ fxZoomInit (CompWindow * w);
+ void
+ applyZoomTransform (CompWindow * w);
+ 
+-void
++extern inline void
+ getZoomCenterScale (CompWindow *w,
+ 		Point *pCurCenter, Point *pCurScale);
+ 
Index: x11-wm/compiz-plugins-main/files/patch-src__animation__animation.c
===
--- x11-wm/compiz-plugins-main/files/patch-src__animation__animation.c	(revision 0)
+++ x11-wm/compiz-plugins-main/files/patch-src__animation__animation.c	(working copy)
@@ -0,0 +1,11 @@
+--- src/animation/animation.c.orig	2009-10-14 03:01:42.0 +0200
 src/animation/animation.c	2012-12-10 00:46:15.0 +0100
+@@ -742,7 +742,7 @@ defaultUpdateWindowTransform (CompWindow
+ }
+ 
+ // Apply transform to wTransform
+-inline void
++extern inline void
+ applyTransform (CompTransform *wTransform,
+ 		CompTransform *transform)
+ {
Index: x11-wm/compiz-plugins-main/files/patch-src__animation__zoomside.c
===
--- x11-wm/compiz-plugins-main/files/patch-src__animation__zoomside.c	(revision 0)
+++ 

Re: downloading source code from github

2012-12-11 Thread Steven Kreuzer
The documentation for doing this is in Mk/bsd.sites.mk (cut and pasted
below)
Also, You can take a look at devel/py-kazoo as an example

#
# In order to use GitHub your port must define USE_GITHUB and the following
# variables:
#
# GH_ACCOUNT- account name of the GitHub user hosting the project
# default: not set, mandatory
#
# GH_PROJECT- name of the project on GitHub
# default: ${PORTNAME}
#
# GH_TAGNAME- name of the tag to download (master, 2.0.1, ...)
# default: ${DISTVERSION}
#
# GH_COMMIT - first 7 digits of the commit that generated GH_TAGNAME
# (man git-describe(1))
# default: not set, mandatory
#


On Tue, Dec 11, 2012 at 6:40 AM, Radim Kolar h...@filez.com wrote:

 its good practice to download source code using git from github if it is
 not available for download, just tagged in repo?
 __**_
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/**mailman/listinfo/freebsd-portshttp://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to 
 freebsd-ports-unsubscribe@**freebsd.orgfreebsd-ports-unsubscr...@freebsd.org
 

___
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: recent port upgrades causing missing libraries

2012-12-11 Thread Bryan Drewery
On 12/11/2012 9:03 AM, Adam McDougall wrote:
 I used poudriere to build pkgng packages from the latest round
 of port updates since the freeze.  I know in the commit message
 for xcb-util it bumped some other ports, but it seems like not
 enough to make poudriere reinstall enough packages to make things
 work.  The pcre upgrade also caused some problems.  I'm sorry that
 I don't have time to make an extensive report of ports vs. libraries
 or a PR but I can add some brief details.  Using pkg install -fR 
 on xcb-util and pcre cured the issues for now,


pkg install -fR devel/pcre should be enough. Is it what results in the
errors below?

Have you modified your local libraries at all, symlinks, etc?

 but that doesn't mean
 I've caught them all.  pkg_libchk doesn't work with pkgng.  I could
 have told pkg to reinstall all packages but that is a big hammer.
 
 Reinstalling libiconv-1.14
 Upgrading pcre: 8.31_1 - 8.32
 Upgrading png: 1.5.12 - 1.5.13
 Upgrading jpeg: 8_3 - 8_4
 Upgrading xcb-util: 0.3.8,1 - 0.3.9_1,1
 Upgrading glib: 2.28.8_4 - 2.28.8_5
 Upgrading tiff: 4.0.2_1 - 4.0.3
 Upgrading gobject-introspection: 0.10.8_2 - 0.10.8_3
 Upgrading cairo: 1.10.2_4,2 - 1.10.2_5,2
 Reinstalling ghostscript9-nox11-9.06_1
 Upgrading pciids: 20120906 - 20121208
 Upgrading startup-notification: 0.12 - 0.12_1
 Upgrading openldap-client: 2.4.33 - 2.4.33_1
 Upgrading cups-client: 1.5.2_2 - 1.5.4
 Upgrading postfix: 2.9.4,1 - 2.9.4_2,1
 Upgrading binutils: 2.22_3 - 2.23.1
 Upgrading javavmwrapper: 2.4_2 - 2.4_3
 Upgrading xterm: 287 - 287_1
 Upgrading Thunar: 1.4.0_2 - 1.4.0_3
 Upgrading goffice: 0.8.17_2 - 0.8.17_3
 Upgrading ImageMagick: 6.7.9.4 - 6.8.0.7
 Upgrading wireshark: 1.8.3 - 1.8.3_1
 
 Upgrading Thunar from 1.4.0_2 to 1.4.0_3...Shared object libpcre.so.1 not 
 found, required by update-desktop-database
 Shared object libpcre.so.1 not found, required by update-desktop-database
  done
 
 # pkg which `which update-desktop-database`
 /usr/local/bin/update-desktop-database was installed by package 
 desktop-file-utils-0.18
 
 Terminal:
 libpcre.so.1 = not found (0)
 
 exo-desktop-item-edit:
 libxcb-util.so.0 = not found (0)
 libpcre.so.1 = not found (0)
 libpcre.so.3 = /usr/local/lib/libpcre.so.3 (0x807942000)
 
 mousepad:
 libxcb-util.so.0 = not found (0)
 libxcb-util.so.1 = /usr/local/lib/libxcb-util.so.1 (0x807749000)
 libpcre.so.1 = not found (0)
 libpcre.so.3 = /usr/local/lib/libpcre.so.3 (0x80794e000)
 
 I think either more port version bumps are needed, or an entry in UPDATING.
 The UPDATING entry for perl is still wrong, I discussed on a list that it
 should not contain -x in the pkg command but it still does.  The -x will make
 it install unwanted things.

I've added an UPDATING entry for pcre, and fixed the perl entry.


Bryan Drewery
___
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: [RFC/HEADSUP] portmaster default -w (preserve shared libraries)

2012-12-11 Thread RW
On Tue, 11 Dec 2012 20:18:51 +0100
Alex Dupre wrote:


 For simple ports it may works correctly, but for others it could
 happen that finally both revisions are linked into a library or
 executable (because one !recompiled dependency depends on the old
 version and another recompiled dependency depends on the new version)
 and this is not good. So the correct thing is to always recompile
 ports to get the new version, the 'keep old libs' flags should be
 used with caution (this is why I prefer it to be opt-in and not
 opt-out).

The main reason for keeping the libraries is that it reduces the
number of breakages during the upgrade process, which can be a very
serious inconvenience, particularly if the forced update fails to
complete. In my experience the problem you describe is much less
significant.
___
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


mouse problem after recent port upgrade

2012-12-11 Thread AN
FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #5 r244122: Tue Dec 11 
15:24:02 EST 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL  amd64


# dmesg |grep ums
ums0: Logitech USB Receiver, class 0/0, rev 2.00/12.01, addr 2 on usbus1
ums1: Logitech USB Receiver, class 0/0, rev 2.00/22.00, addr 3 on usbus3
ums1: 16 buttons and [XYZT] coordinates ID=0
ums0: 16 buttons and [XYZT] coordinates ID=2

The output above is for a Logitech M305 wireless usb mouse.  Previously 
the default behavior for the mouse was that a double click with the left mouse 
button, followed by a single middle button click would have performed a 
cut and paste operation.  Now when I double click the left button the text 
is highlighted, but the single click middle button does not paste.  What 
could have caused this?  What ports could affect this?  Any help would be 
appreciated, thanks in advance.


___
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: recent port upgrades causing missing libraries

2012-12-11 Thread Adam McDougall
On Tue, Dec 11, 2012 at 02:57:14PM -0600, Bryan Drewery wrote:

  On 12/11/2012 9:03 AM, Adam McDougall wrote:
   I used poudriere to build pkgng packages from the latest round
   of port updates since the freeze.  I know in the commit message
   for xcb-util it bumped some other ports, but it seems like not
   enough to make poudriere reinstall enough packages to make things
   work.  The pcre upgrade also caused some problems.  I'm sorry that
   I don't have time to make an extensive report of ports vs. libraries
   or a PR but I can add some brief details.  Using pkg install -fR 
   on xcb-util and pcre cured the issues for now,
  
  
  pkg install -fR devel/pcre should be enough. Is it what results in the
  errors below?

I believe you are right about pcre being enough. I reverted /usr/local 
and /var/db/pkg to a backup so I could do some before and after ldd * 
in /usr/local/bin and -fR on xcb-util didn't make a difference after 
pcre.  The reason I did xcb-util first was because it was the first 
library error I noticed during startx after the initial pkg upgrade.  
During pkg install -fR xcb-util I saw lots of library errors regarding 
pcre, so I followed with -fR on pcre.  At this point everything looked 
fine.  Thanks for your updates to UPDATING today.
  
  Have you modified your local libraries at all, symlinks, etc?

No, this is all output from two desktops that are using only packages 
from my poudriere environment.  I haven't symlinked libraries or 
anything like that.  I try to take an all or nothing upgrade approach 
when it comes to libraries because I know mixing can cause difficult 
problems and having well built packages takes the pain out of updating 
(as long as the right stuff actually gets replaced).  The output below 
is all from the second system where I took more notes because I was 
expecting it to happen.  I'm not sure in this scenario why ldd would 
show linking against multiple library versions unless it is adding in 
library links recursively from a mix of old and new libraries.
I think this would all have been fine if pkg or I had known about the
additional steps needed.  So much less painful than (re-re-re)compiling
large portions of ports for library bumps.

Is there a way to make pkg reinstall any package where the checksum at 
time of install no longer matches what the repo has?  *somehow* I suspect
it is possible for pkg to automatically know because I've seen it offer
to reinstall some packages when I've changed compile options.
I understand poudriere is super conservative about recompiling packages;
I would like to apply that same rigor to pkg upgrade even if it takes
an additional command, but reinstalling all packages each time would be
overkill.
  
  I've added an UPDATING entry for pcre, and fixed the perl entry.

  Bryan Drewery

Thanks!
___
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


Notes on upgrades after libpcre update

2012-12-11 Thread Kevin Oberman
As many of you noticed, the update of devel/pcre bumped hte version of
libpcre.so which is a dependency of LOTS of things. Here are some
incomplete notes on what might bite you: Note that I refer to
pkg_libchk. It is part of sysutils/bsddminscripts. If you run pkgng,
you will need to edit it an change pkg_info to pkg info. There may
be a couple of other changes needed, but I have not switched to pkgng
due to tools that use the old /var/db/pkg structure.

1. portmaster/portupgrade -r devel/pcre will want to re-install most
everything on the system. Use pkg_libcheck:
% pkg_libchk -o | grep libpcre | cut -f1 -d: | sort | uniq  rebuild.pcre
2. pkg_delete -f avahi-app
3. portmaster -D `cat rebuild.pcre`

This will result in re-building only those ports that really need
re-building. If avahi-app is not deleted, it will fail to re-build. If
you hit that, just delete the package and re-start the rebuild job.

If I find other issues, I will follow up on this thread. Since my
system is a laptop running Gnome, others may hit issues I won't. This
would be better done on the wiki, but I don't have write access to it.
-- 
R. Kevin Oberman, Network Engineer
E-mail: kob6...@gmail.com
___
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: Notes on upgrades after libpcre update

2012-12-11 Thread Eitan Adler
On 11 December 2012 18:18, Kevin Oberman kob6...@gmail.com wrote:
 As many of you noticed, the update of devel/pcre bumped hte version of
 libpcre.so which is a dependency of LOTS of things. Here are some
 incomplete notes on what might bite you: Note that I refer to
 pkg_libchk. It is part of sysutils/bsddminscripts. If you run pkgng,
 you will need to edit it an change pkg_info to pkg info. There may
 be a couple of other changes needed, but I have not switched to pkgng
 due to tools that use the old /var/db/pkg structure.

 1. portmaster/portupgrade -r devel/pcre will want to re-install most
 everything on the system. Use pkg_libcheck:
 % pkg_libchk -o | grep libpcre | cut -f1 -d: | sort | uniq  rebuild.pcre
 2. pkg_delete -f avahi-app
 3. portmaster -D `cat rebuild.pcre`

 This will result in re-building only those ports that really need
 re-building. If avahi-app is not deleted, it will fail to re-build. If
 you hit that, just delete the package and re-start the rebuild job.

 If I find other issues, I will follow up on this thread. Since my
 system is a laptop running Gnome, others may hit issues I won't. This
 would be better done on the wiki, but I don't have write access to it.

make a user, tell me the username, I'll get it for you.
-- 
Eitan Adler
___
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: [RFC/HEADSUP] portmaster default -w (preserve shared libraries)

2012-12-11 Thread Kevin Oberman
On Tue, Dec 11, 2012 at 1:04 PM, RW rwmailli...@googlemail.com wrote:
 On Tue, 11 Dec 2012 20:18:51 +0100
 Alex Dupre wrote:


 For simple ports it may works correctly, but for others it could
 happen that finally both revisions are linked into a library or
 executable (because one !recompiled dependency depends on the old
 version and another recompiled dependency depends on the new version)
 and this is not good. So the correct thing is to always recompile
 ports to get the new version, the 'keep old libs' flags should be
 used with caution (this is why I prefer it to be opt-in and not
 opt-out).

 The main reason for keeping the libraries is that it reduces the
 number of breakages during the upgrade process, which can be a very
 serious inconvenience, particularly if the forced update fails to
 complete. In my experience the problem you describe is much less
 significant.

It does eliminate the instant breakage of lots and lots of stuff, but
it can lead to hard to track down issues later.

The problem is that, as ports are updated, you end up with
applications that link to libraries that, in turn link to the library
that had the version bump. If one of those libraries is updated, the
application fails as the loader (rtld) will refuse to load two
different versions of the same library (for good reason). So saving
the old lib is fine, but you really, really need to update all ports
that link to that library fairly immediately.
-- 
R. Kevin Oberman, Network Engineer
E-mail: kob6...@gmail.com
___
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


mouse problem after recent port upgrade (fwd)

2012-12-11 Thread AN

Follow up to message below.

-- Forwarded message --
Date: Tue, 11 Dec 2012 16:53:50 -0500 (EST)
From: AN a...@neu.net
To: freebsd-ports@freebsd.org
Subject: mouse problem after recent port upgrade

FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #5 r244122: Tue Dec 11 
15:24:02 EST 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL  amd64


# dmesg |grep ums
ums0: Logitech USB Receiver, class 0/0, rev 2.00/12.01, addr 2 on usbus1
ums1: Logitech USB Receiver, class 0/0, rev 2.00/22.00, addr 3 on usbus3
ums1: 16 buttons and [XYZT] coordinates ID=0
ums0: 16 buttons and [XYZT] coordinates ID=2

The output above is for a Logitech M305 wireless usb mouse.  Previously the 
default behavior for the mouse was that a double click with the left mouse 
button, followed by a single middle button click would have performed a cut and 
paste operation.  Now when I double click the left button the text is 
highlighted, but the single click middle button does not paste.  What could 
have caused this?  What ports could affect this?  Any help would be 
appreciated, thanks in advance.




Running portupgrade -fr devel/pcre fixes the problem.
___
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: [RFC/HEADSUP] portmaster default -w (preserve shared libraries)

2012-12-11 Thread Warren Block

On Tue, 11 Dec 2012, Bryan Drewery wrote:


(As maintainer) I'm proposing to make -w the default for portmaster.
This will preserve old shared libraries when upgrading. This helps 2 things:

1. Prevents a broken system during upgrades
2. Prevents a broken system after upgrading for ports that did not get a
PORTREVISION bump from a shared library update.

You have certainly ran into this problem with large library updates such
as png, pcre, openssl, etc.

Portupgrade has always done this as default, and I have never seen any
problems arise from it. It also cleans up prevents duplicated library
versions. If portmaster is not already doing this, I will ensure it does.

You could then use pkg_libchk to rebuild any lingering ports if you
wanted to ensure your system was using the latest. Then cleanout the
preserved shared library.

Of course there will be a way to stick to the old default of not
preserving the libraries.

Someone may consider this a POLA violation, but I consider that a broken
system from missing libraries and PORTREVISION bumps is more of a POLA
violation.


The -w behavior by default seems reasonable.  When implemented, it 
should be mentioned in UPDATING.  pkg_libchk should also be mentioned as 
a way of finding installed applications that are depending on old 
libraries in /usr/local/lib/compat/pkg.

___
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


need help with pkg - failed portupgrade

2012-12-11 Thread AN
FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #5 r244122: Tue Dec 11 
15:24:02 EST 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL  amd64


While running portupgrade due to (The pcre library has been updated to 
version 8.32.  Please rebuild all ports that depend on it.) I had the 
following failure:


The command I ran was :portupgrade -vfr devel/pcre

and it failed with:
===  Cleaning for gnome-screensaver-2.30.2_3
---  Removing temporary files and directories
---  Removing old package'
---  Installation of x11/gnome-screensaver ended at: Tue, 11 Dec 2012 
23:01:06 -0500 (consumed 00:00:15)

---  Cleaning out obsolete shared libraries
[Updating the pkgdb format:bdb_btree in /var/db/pkg ... USING PKGNG
- 798 packages found (-0 +1) . done]
---  Reinstallation of x11/gnome-screensaver ended at: Tue, 11 Dec 2012 
23:01:08 -0500 (consumed 00:01:40)

---  ** Upgrade tasks 278: 200 done, 0 ignored, 7 skipped and 2 failed
** No origin recorded: libreoffice-3.5.7
** Specify one with -o option, or run 'pkgdb -F' to interactively fix it.
---  Session ended at: Tue, 11 Dec 2012 23:01:08 -0500 (consumed 
04:51:07)
/usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:964:in 
`initialize': ArgumentError (ArgumentError)

from /usr/local/sbin/portupgrade:1060:in `new'
from /usr/local/sbin/portupgrade:1060:in `do_upgrade'
from /usr/local/sbin/portupgrade:855:in `main'
from /usr/local/sbin/portupgrade:850:in `each'
from /usr/local/sbin/portupgrade:850:in `main'
from /usr/local/lib/ruby/1.8/optparse.rb:791:in `initialize'
from /usr/local/sbin/portupgrade:237:in `new'
from /usr/local/sbin/portupgrade:237:in `main'
from /usr/local/sbin/portupgrade:2371


I deleted Libreoffice with:
pkg -d delete libreoffice-3.5.7

# pkgdb -vF
USING PKGNG
pkgdb -F not supported with PKGNG yet. Use 'pkg check' directly.
[root@FBSD10 ~]# pkg check
usage: pkg check [-Bdsr] [-vy] [-a | -gxX pattern]

For more information see 'pkg help check'.

Not sure how to proceed now, any help is appreciated.

Once I get this fixed, how can I restart portupgrade from where it ended 
and not recompile the ports that were already updated?


Thanks in advance.

___
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: [RFC/HEADSUP] portmaster default -w (preserve shared libraries)

2012-12-11 Thread Matthieu Volat
On Tue, 11 Dec 2012 09:55:24 -0600
Bryan Drewery bdrew...@freebsd.org wrote:

 (As maintainer) I'm proposing to make -w the default for portmaster.
 This will preserve old shared libraries when upgrading. This helps 2 things:
 
 [...]

I have a few question about what happens if you always use this flag: 
* Do you keep every version of the shlibs you ever built on your system?
* Are there any method to clean the unused ones?
* What do we do about libraries versions that have security issues and that we 
need to get out asap?

Regards,

-- 
Matthieu Volat ma...@alkumuna.eu
___
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: Some ports options is broken

2012-12-11 Thread Kurt Jaeger
Hi!

 After ports unfreeze there was commit (
 http://svnweb.freebsd.org/ports?view=revisionrevision=308598 I think) that
 introduces new mechanism for selecting ports options. And it has broken
 many ports options.
 
 Example 1. databases/freetds-devel.
 Now you can't select any option. In ANY case you gets this:
  You must select one and only one option from the ODBC single
  You must select one and only one option from the SSL single
 Config is invalid. Re-edit? [Y/N]
 
 And databases/freetds-devel lost one option - MSDBLIB (MS SQL Server
 compatibility). Where has it gone?

The patch at

  http://www.freebsd.org/cgi/query-pr.cgi?pr=174377

should fix that.

-- 
p...@opsec.eu+49 171 3101372 8 years to go !
___
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: Some ports options is broken

2012-12-11 Thread Baptiste Daroussin
On Wed, Dec 12, 2012 at 08:26:52AM +0100, Kurt Jaeger wrote:
 Hi!
 
  After ports unfreeze there was commit (
  http://svnweb.freebsd.org/ports?view=revisionrevision=308598 I think) that
  introduces new mechanism for selecting ports options. And it has broken
  many ports options.
  
  Example 1. databases/freetds-devel.
  Now you can't select any option. In ANY case you gets this:
   You must select one and only one option from the ODBC single
   You must select one and only one option from the SSL single
  Config is invalid. Re-edit? [Y/N]
  
  And databases/freetds-devel lost one option - MSDBLIB (MS SQL Server
  compatibility). Where has it gone?
 
 The patch at
 
   http://www.freebsd.org/cgi/query-pr.cgi?pr=174377
 
 should fix that.
 

I have done a fast fix already, your patch is wrong is the way that OPTIONS_SET
is a end user thing to put in make.conf where OPTIONS_DEFAULT is the one to be
used inside a port

Do you want the PR to remain open because you will add some modification on top
of my fast fix or not?

Concerning the openldap problem, I have spotted why it does that, which is the
long known problem of UNIQUENAME changing all the time, it might take more time
to fix in the particular case because it is not easy to. it worked before
because the option framework was buggily read 3 times.

regards,
Bapt


pgpJ9tWL1mmLg.pgp
Description: PGP signature


Re: [RFC/HEADSUP] portmaster default -w (preserve shared libraries)

2012-12-11 Thread Matthias Andree
Am 11.12.2012 20:34, schrieb Jeremy Messenger:

 If can't update all ports then please wait until when you can. I never
 have any problem to update all ports at a time by ran it over night
 time. Or even better, use packages if you can't afford the ports
 system.

This is ridiculous. We know that there have been extended (months!)
periods where we were stuck because all useful versions of some
important library had security vulnerabilities.  The last pain I
recollect was libxul.  Old version vulnerable, no new version, and then
when the new version was around, some dependencies did not work with
libxul-10*.  This would in effect have meant no update for months.


Bryan, practially, I propose that portmaster should

- list stored libraries on each and every run, and ask that the user
updates those ports that use the old, saved, libraries, pointing to
bsdadminutils and pkg_libchk.

- we may need to save more than just the .so files, namely, the origin
and portname of a saved library so that portmaster can run portaudit
against those names to complain about security issues in saved libraries.


___
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