Re: samba4

2014-01-06 Thread Ryan Schmidt

On Jan 5, 2014, at 18:18, Chris Murphy wrote:

 When searching samba in available ports, I see a relatively current samba3, 
 but a six and a half  year old samba 4.0.0 tp5. Is this correct? Are there 
 any plans to bring samba4 more up to date?

https://trac.macports.org/ticket/38834


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev


Re: [115295] trunk/dports/math/parmetis/Portfile

2014-01-06 Thread Sean Farley

ryandes...@macports.org writes:

 On Dec 30, 2013, at 13:52, s...@macports.org wrote:

 Revision
 115295
 Author
 s...@macports.org
 Date
 2013-12-30 11:52:49 -0800 (Mon, 30 Dec 2013)
 Log Message
 
 parmetis: add correct flags for debug variant
 Modified Paths
 
  • trunk/dports/math/parmetis/Portfile
 Diff
 
 Modified: trunk/dports/math/parmetis/Portfile (115294 = 115295)
 
 --- trunk/dports/math/parmetis/Portfile  2013-12-30 19:52:44 UTC (rev 
 115294)
 +++ trunk/dports/math/parmetis/Portfile  2013-12-30 19:52:49 UTC (rev 
 115295)
 
 @@ -61,6 +61,16 @@
 
  default_variants +mpich
 
  }
 
  
 
 +if {[variant_isset debug]} {
 +configure.cflags-delete-O1 -O2 -O3 -Os -DNDEBUG
 +configure.cppflags-delete  -O1 -O2 -O3 -Os -DNDEBUG
 +configure.cxxflags-delete  -O1 -O2 -O3 -Os -DNDEBUG
 +
 +configure.cflags-append-g
 +configure.cppflags-append  -g
 +configure.cxxflags-append  -g
 +}

 Optimization flags don’t belong in (and aren’t in) the cppflags. And the way 
 that optimization flags get into the cflags and cxxflags is via optflags. So 
 if you want to change the optimization flags, changing configure.optflags is 
 best. -DNDEBUG isn’t in any of those flags, so attempting to remove it does 
 nothing. (The cmake portgroup does do something with -DNDEBUG; you may need 
 to look into that.) Here’s a simpler way to do what you’re doing:

 if {[variant_isset debug]} {
 configure.optflags -O0
 configure.cflags-append-g
 configure.cxxflags-append  -g
 }

 Note that this code would have to run *before* any other uses of 
 configure.cflags or configure.cxxflags, otherwise the default value of 
 configure.optflags would already have been appended to them.

Oops, yes, you're right. This is code copied from my debug portgroup
that I forgot to update. I'll fix it. Thanks for the heads up.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev


Port upgrade outdated sequence

2014-01-06 Thread Peter Brommer
Hi,

I ran into a problem running port upgrade outdated today. Among the packages to 
be upgraded were libLASi (from 1.1.1_0 to 1.1.1_1) and graphviz (from 
2.34.0_1+pangocairo+x11 to 2.34.0_4+pangocairo+x11). However, the port upgrade 
command chose to execute the upgrade in an unfortunate sequence: First it tried 
to upgrade graphviz, which failed due to the bug in ticket 
https://trac.macports.org/ticket/41567 - when the proper behaviour would have 
been to upgrade libLASi first. This required a manual intervention, which IMHO 
is not user friendly.

Does the port upgrade command have any logic in determining the order of 
upgrades? Or is this something that needs to be specified on the port file 
level? In this case, graphviz lib-depends on libLASi, so should port not try 
upgrading the deps before a package?
 
Cheers,

Peter



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev


Re: Port upgrade outdated sequence

2014-01-06 Thread Ryan Schmidt

On Jan 6, 2014, at 12:37, Peter Brommer p.brom...@warwick.ac.uk wrote:

 I ran into a problem running port upgrade outdated today. Among the packages 
 to be upgraded were libLASi (from 1.1.1_0 to 1.1.1_1) and graphviz (from 
 2.34.0_1+pangocairo+x11 to 2.34.0_4+pangocairo+x11). However, the port 
 upgrade command chose to execute the upgrade in an unfortunate sequence: 
 First it tried to upgrade graphviz, which failed due to the bug in ticket 
 https://trac.macports.org/ticket/41567 - 

That ticket is about libLASi, not graphviz, and was resolved 6 weeks ago.

 when the proper behaviour would have been to upgrade libLASi first. This 
 required a manual intervention, which IMHO is not user friendly.
 
 Does the port upgrade command have any logic in determining the order of 
 upgrades? Or is this something that needs to be specified on the port file 
 level? In this case, graphviz lib-depends on libLASi, so should port not try 
 upgrading the deps before a package?

It does.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev


Re: Port upgrade outdated sequence

2014-01-06 Thread Peter Brommer
Hi Ryan,

thank you for your reply.

On 6 Jan 2014, at 18:50, Ryan Schmidt ryandes...@macports.org wrote:

 
 On Jan 6, 2014, at 12:37, Peter Brommer p.brom...@warwick.ac.uk wrote:
 
 I ran into a problem running port upgrade outdated today. Among the packages 
 to be upgraded were libLASi (from 1.1.1_0 to 1.1.1_1) and graphviz (from 
 2.34.0_1+pangocairo+x11 to 2.34.0_4+pangocairo+x11). However, the port 
 upgrade command chose to execute the upgrade in an unfortunate sequence: 
 First it tried to upgrade graphviz, which failed due to the bug in ticket 
 https://trac.macports.org/ticket/41567 - 
 
 That ticket is about libLASi, not graphviz, and was resolved 6 weeks ago.

That was actually not my point.

 
 when the proper behaviour would have been to upgrade libLASi first. This 
 required a manual intervention, which IMHO is not user friendly.
 
 Does the port upgrade command have any logic in determining the order of 
 upgrades? Or is this something that needs to be specified on the port file 
 level? In this case, graphviz lib-depends on libLASi, so should port not try 
 upgrading the deps before a package?
 
 It does.

I just noticed that it was not port upgrade that did the out-of-order install, 
but rather a rebuild after database errors. My first port upgrade command ran 
into bug https://trac.macports.org/ticket/41737 (against webkit-gtk, which 
appears to be still open). The workaround requires running 
port -f deactivate webkit-gtk
port install webkit-gtk-2.0

The latter command resulted in the following output:
[..]
---  Cleaning webkit-gtk-2.0
---  Updating database of binaries: 100.0%
---  Scanning binaries for linking errors: 100.0%
---  Found 412 broken file(s), matching files to ports
---  Found 27 broken port(s), determining rebuild order
---  Rebuilding in order
 py27-matplotlib @1.3.1 +tkinter
 pymol @1.6.0 
 qt4-mac @4.8.5 
 wxPython-3.0 @2.9.5 
 wxWidgets-3.0 @3.0.0 
 ImageMagick @6.8.7-3 +x11
 gimp2 @2.8.8 +help_browser+python27
 GraphicsMagick @1.3.18 +q8
 gnuplot @4.6.4 +aquaterm+luaterm+pangocairo+wxwidgets+x11
 mplayer-devel @36449 
 openmotif @2.3.4 
 ddd @3.3.12 
 netpbm @10.64.04 
 graphviz @2.34.0 +pangocairo+x11
 transfig @3.2.5d 
 povray @3.7.0.0 
 xcursorgen @1.0.5 
 grace @5.1.23 
 libsdl_image @1.2.12 
 xorg-libXfont @1.4.6 
 gtkglext @1.2.0 
 gtkmm @2.24.4 +x11
 gtkimageview @1.6.4 
 ufraw @0.19.2 
 gtkspell2 @2.0.16 +x11
 inkscape @0.48.4 +python27+x11
 octave @3.2.4 +atlas+gcc47-gcc45
[snip..much later]
---  Computing dependencies for graphviz
---  Fetching archive for graphviz
---  Attempting to fetch 
graphviz-2.34.0_4+pangocairo+x11.darwin_12.x86_64.tbz2 from 
http://mse.uk.packages.macports.org/sites/packages.macports.org/graphviz
---  Attempting to fetch 
graphviz-2.34.0_4+pangocairo+x11.darwin_12.x86_64.tbz2 from 
http://lil.fr.packages.macports.org/graphviz
---  Attempting to fetch 
graphviz-2.34.0_4+pangocairo+x11.darwin_12.x86_64.tbz2 from 
http://packages.macports.org/graphviz
---  Fetching distfiles for graphviz
---  Verifying checksums for graphviz
---  Extracting graphviz
---  Configuring graphviz
---  Building graphviz
Error: org.macports.build for port graphviz returned: command execution failed

The repair job thus tried to rebuild graphviz, without upgrading libLASi 
beforehand, and thus failed.

I do apologise for my incorrect earlier e-mail; the problem was not with port 
upgrade, but with whatever it is that checks for broken ports. Please do let me 
know if this is a bug and I will file a ticket.

Peter

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev


Re: Port upgrade outdated sequence

2014-01-06 Thread Ryan Schmidt
On Jan 6, 2014, at 13:07, Peter Brommer wrote:

 I just noticed that it was not port upgrade that did the out-of-order 
 install, but rather a rebuild after database errors. My first port upgrade 
 command ran into bug https://trac.macports.org/ticket/41737 (against 
 webkit-gtk, which appears to be still open). The workaround requires running 
 port -f deactivate webkit-gtk
 port install webkit-gtk-2.0
 
 The latter command resulted in the following output:
 [..]
 ---  Cleaning webkit-gtk-2.0
 ---  Updating database of binaries: 100.0%
 ---  Scanning binaries for linking errors: 100.0%
 ---  Found 412 broken file(s), matching files to ports
 ---  Found 27 broken port(s), determining rebuild order
 ---  Rebuilding in order
 py27-matplotlib @1.3.1 +tkinter
 pymol @1.6.0 
 qt4-mac @4.8.5 
 wxPython-3.0 @2.9.5 
 wxWidgets-3.0 @3.0.0 
 ImageMagick @6.8.7-3 +x11
 gimp2 @2.8.8 +help_browser+python27
 GraphicsMagick @1.3.18 +q8
 gnuplot @4.6.4 +aquaterm+luaterm+pangocairo+wxwidgets+x11
 mplayer-devel @36449 
 openmotif @2.3.4 
 ddd @3.3.12 
 netpbm @10.64.04 
 graphviz @2.34.0 +pangocairo+x11
 transfig @3.2.5d 
 povray @3.7.0.0 
 xcursorgen @1.0.5 
 grace @5.1.23 
 libsdl_image @1.2.12 
 xorg-libXfont @1.4.6 
 gtkglext @1.2.0 
 gtkmm @2.24.4 +x11
 gtkimageview @1.6.4 
 ufraw @0.19.2 
 gtkspell2 @2.0.16 +x11
 inkscape @0.48.4 +python27+x11
 octave @3.2.4 +atlas+gcc47-gcc45
 [snip..much later]
 ---  Computing dependencies for graphviz
 ---  Fetching archive for graphviz
 ---  Attempting to fetch 
 graphviz-2.34.0_4+pangocairo+x11.darwin_12.x86_64.tbz2 from 
 http://mse.uk.packages.macports.org/sites/packages.macports.org/graphviz
 ---  Attempting to fetch 
 graphviz-2.34.0_4+pangocairo+x11.darwin_12.x86_64.tbz2 from 
 http://lil.fr.packages.macports.org/graphviz
 ---  Attempting to fetch 
 graphviz-2.34.0_4+pangocairo+x11.darwin_12.x86_64.tbz2 from 
 http://packages.macports.org/graphviz
 ---  Fetching distfiles for graphviz
 ---  Verifying checksums for graphviz
 ---  Extracting graphviz
 ---  Configuring graphviz
 ---  Building graphviz
 Error: org.macports.build for port graphviz returned: command execution failed
 
 The repair job thus tried to rebuild graphviz, without upgrading libLASi 
 beforehand, and thus failed.

Ah yes. That is a bug.

https://trac.macports.org/ticket/40150

It’s fixed in trunk, which will become MacPorts 2.3 eventually.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev


Using the github Portgroup

2014-01-06 Thread Frank Schima
Hi All,


Can someone with more knowledge of the github portgroup help me to set the 
proper github.setup for the the following URL?

https://github.com/sfepy/sfepy/tree/release_2013.4

I’ve tried the following with no success:

PortGroup   github 1.0
PortGroup   python 1.0

github.setupsfepy sfepy 2013.4 release_2013.4
namepy-sfepy

It seems to want to download from  
https://github.com/sfepy/sfepy/tarball/release_2013.42013.4. I’ve tried other 
variations with no success. 


Thank you!
Frank

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev


Re: Using the github Portgroup

2014-01-06 Thread Sean Farley

macsforever2...@macports.org writes:

 Hi All,


 Can someone with more knowledge of the github portgroup help me to set the 
 proper github.setup for the the following URL?

 https://github.com/sfepy/sfepy/tree/release_2013.4

 I’ve tried the following with no success:

 PortGroup   github 1.0
 PortGroup   python 1.0

 github.setupsfepy sfepy 2013.4 release_2013.4
 namepy-sfepy

 It seems to want to download from  
 https://github.com/sfepy/sfepy/tarball/release_2013.42013.4. I’ve tried other 
 variations with no success. 

Your setup line should be:

github.setupsfepy sfepy 2013.4 release_

The last argument is an optional prefix, not the whole tag name.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev


Re: Using the github Portgroup

2014-01-06 Thread Frank Schima

On Jan 6, 2014, at 2:57 PM, Sean Farley s...@macports.org wrote:

 
 macsforever2...@macports.org writes:
 
 Can someone with more knowledge of the github portgroup help me to set the 
 proper github.setup for the the following URL?
 
 https://github.com/sfepy/sfepy/tree/release_2013.4
 
 I’ve tried the following with no success:
 
 PortGroup   github 1.0
 PortGroup   python 1.0
 
 github.setupsfepy sfepy 2013.4 release_2013.4
 namepy-sfepy
 
 It seems to want to download from  
 https://github.com/sfepy/sfepy/tarball/release_2013.42013.4. I’ve tried 
 other variations with no success. 
 
 Your setup line should be:
 
 github.setupsfepy sfepy 2013.4 release_
 
 The last argument is an optional prefix, not the whole tag name.

That works. Thank you!!


-Frank

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev


Looking for a few good maintainers

2014-01-06 Thread David Evans
The current gnome-utils and gnome-games ports are unmaintained and
outdated.  In current GNOME3 distributions, they have been replaced by
individual
packages, none of which have been ported to MacPorts as yet.  If anyone
has a few spare cycles to port and maintain any of these ports, please
take a look
at the referenced tickets for details.  Thanks for your help.

[1] https://trac.macports.org/ticket/42035 (gnome-utils)
[2] https://trac.macports.org/ticket/42037 (gnome-games)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev


Re: Looking for a few good maintainers

2014-01-06 Thread Eric Gallager
I'd be willing to help, but unfortunately I think that the a few spare
cycles requirement is going to disqualify me, as my main hard drive
recently died and I'm still in the process of transferring to a new one...



On Mon, Jan 6, 2014 at 5:47 PM, David Evans dev...@macports.org wrote:

 The current gnome-utils and gnome-games ports are unmaintained and
 outdated.  In current GNOME3 distributions, they have been replaced by
 individual
 packages, none of which have been ported to MacPorts as yet.  If anyone
 has a few spare cycles to port and maintain any of these ports, please
 take a look
 at the referenced tickets for details.  Thanks for your help.

 [1] https://trac.macports.org/ticket/42035 (gnome-utils)
 [2] https://trac.macports.org/ticket/42037 (gnome-games)
 ___
 macports-dev mailing list
 macports-dev@lists.macosforge.org
 https://lists.macosforge.org/mailman/listinfo/macports-dev

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev