Re: [125902] trunk/dports/science/arb/Portfile

2014-09-29 Thread Jeremy Huddleston Sequoia

 On Sep 28, 2014, at 22:19, Ryan Schmidt ryandes...@macports.org wrote:
 
 
 On Sep 28, 2014, at 10:32 PM, jerem...@macports.org wrote:
 
 Revision
 125902
 Author
 jerem...@macports.org
 Date
 2014-09-28 20:32:20 -0700 (Sun, 28 Sep 2014)
 Log Message
 
 arb: Take a stab at fixing the SL build on the builder
 Modified Paths
 
  • trunk/dports/science/arb/Portfile
 Diff
 
 Modified: trunk/dports/science/arb/Portfile (125901 = 125902)
 
 +platform darwin {
 +if {${os.major}  11} {
 +depends_build-append port:coreutils
 +
 +configure.env-append INSTALL=${prefix}/bin/ginstall
 +}
 +}
 
 The error I see on the buildbot is:
 
 
 install -s dvtditr dndfast7 dndblast sextet5 mafft-distance pairlocalalign 
 pair2hat3s multi2hat3s rnatest pairash addsingle splittbfast disttbfast 
 tbfast mafft-profile f2cl mccaskillwrap contrafoldwrap countlen seq2regtable 
 regtable2seq score getlag dndpre dndpre2 setcore replaceu restoreu 
 setdirection makedirectionlist version 
 /opt/local/var/macports/build/_opt_mports_dports_science_arb/arb/work/arbsrc_12565/lib/mafft
 strip: object: 
 /opt/local/var/macports/build/_opt_mports_dports_science_arb/arb/work/arbsrc_12565/lib/mafft/dvtditr
  malformed object (unknown load command 13)
 
 
 So it looks like it's strip, not install, that's having a problem with the 
 object's load command.

Yes, it is strip that has the issue with the object's load command, and my goal 
is to use the strip executable provided by the cctools port.

The problem is that 'install -s' is /usr/bin/install which runs 'xcrun strip' 
which executes the older version of strip from Xcode (which does not know about 
newer load commands).  I was trying to get the port to use ginstall -s which 
will run 'strip' which will pick up MacPorts' cctools strip instead.

--Jeremy

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


Re: imake

2014-09-29 Thread Mojca Miklavec
On Mon, Sep 29, 2014 at 5:58 AM, Joshua Root wrote:

 rasmol - Packaged version released in 2008, latest release was in 2009

 This is probably used by some of our scientist users. There does seem to
 be a 2.7.5.2 release from 2011, and more files added to their
 sourceforge site in 2013. So certainly not dead. (Probably just
 developed by academics in their spare time, like many such tools.)

I totally agree with the last few sentences.

I used rasmol lot in the past, but haven't used it for years now.
Tools like pymol have been developed in the meantime which are using
newer technologies and are slightly more user-friendly. Still, this
doesn't mean that authors shouldn't be asked about moving to a modern
build system. Or that MacPorts definitely needs to support the tool
(they seem to provide some apple-specific downloads).

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


Re: [MacPorts] #33179: xymon and xymon-server disagree about whether clientlaunch.cfg should be registered to the port or not

2014-09-29 Thread Francois Claire

Hi,


Why is the xymon port now a stub ?


Francois.



Le 29/09/14 16:50, MacPorts a écrit :

#33179: xymon and xymon-server disagree about whether clientlaunch.cfg should be
registered to the port or not
---+---
   Reporter:  ryandesign@…  |  Owner:  fclaire@…
   Type:  defect| Status:  closed
   Priority:  Normal|  Milestone:
  Component:  ports |Version:  2.0.3
Resolution:  wontfix   |   Keywords:
   Port:  xymon |
---+---
Changes (by mf2k@…):

  * status:  new = closed
  * resolution:   = wontfix


Comment:

  Closing this since the xymon port is now a stub.



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


Re: [MacPorts] #33179: xymon and xymon-server disagree about whether clientlaunch.cfg should be registered to the port or not

2014-09-29 Thread Frank Schima
Because according to port info, it was replaced by xymon-client. 

$ port info xymon
xymon @4.3.7_3 (net)
Replaced by:  xymon-client

Description:  Xymon is a system for monitoring of hosts and networks, 
inspired by the Big Brother system. This port is a stub and has been
  replaced by the xymon-client port.
Homepage: http://www.xymon.com/

Conflicts with:   xymon-server
Platforms:darwin
License:  unknown
Maintainers:  nomaintai...@macports.org


On Sep 29, 2014, at 8:54 AM, Francois Claire fcla...@free.fr wrote:

 Hi,
 
 
 Why is the xymon port now a stub ?
 
 
 Francois.
 
 
 
 Le 29/09/14 16:50, MacPorts a écrit :
 #33179: xymon and xymon-server disagree about whether clientlaunch.cfg 
 should be
 registered to the port or not
 ---+---
   Reporter:  ryandesign@…  |  Owner:  fclaire@…
   Type:  defect| Status:  closed
   Priority:  Normal|  Milestone:
  Component:  ports |Version:  2.0.3
 Resolution:  wontfix   |   Keywords:
   Port:  xymon |
 ---+---
 Changes (by mf2k@…):
 
  * status:  new = closed
  * resolution:   = wontfix
 
 
 Comment:
 
  Closing this since the xymon port is now a stub.
 
 
 ___
 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


Re: [MacPorts] #33179: xymon and xymon-server disagree about whether clientlaunch.cfg should be registered to the port or not

2014-09-29 Thread Francois Claire
Yes, sure. Sorry for the stupid question: I remembered why just after 
pushing the send button...



Cheers,
Francois.


Le 29/09/14 16:57, Frank Schima a écrit :

Because according to port info, it was replaced by xymon-client.

$ port info xymon
xymon @4.3.7_3 (net)
Replaced by:  xymon-client

Description:  Xymon is a system for monitoring of hosts and 
networks, inspired by the Big Brother system. This port is a stub and 
has been

  replaced by the xymon-client port.
Homepage: http://www.xymon.com/

Conflicts with:   xymon-server
Platforms:darwin
License:  unknown
Maintainers:  nomaintai...@macports.org


On Sep 29, 2014, at 8:54 AM, Francois Claire fcla...@free.fr 
mailto:fcla...@free.fr wrote:



Hi,


Why is the xymon port now a stub ?


Francois.



Le 29/09/14 16:50, MacPorts a écrit :
#33179: xymon and xymon-server disagree about whether 
clientlaunch.cfg should be

registered to the port or not
---+---
  Reporter:  ryandesign@…  |  Owner:  fclaire@…
  Type:  defect| Status:  closed
  Priority:  Normal|  Milestone:
 Component:  ports |Version:  2.0.3
Resolution:  wontfix   |   Keywords:
  Port:  xymon |
---+---
Changes (by mf2k@…):

 * status:  new = closed
 * resolution:   = wontfix


Comment:

 Closing this since the xymon port is now a stub.



___
macports-dev mailing list
macports-dev@lists.macosforge.org 
mailto: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


Releasing code as portgroup instead of in base/ (was Re: imake)

2014-09-29 Thread Daniel J. Luke
On Sep 28, 2014, at 2:55 AM, Ryan Schmidt ryandes...@macports.org wrote:
 
 Moving this code to a portgroup would make it possible for us to fix this 
 problem and any other problems that might come up later without having to 
 produce a new MacPorts release.

I think we really should move in the other direction:

-make releases easier
-less code in portgroups (move as much as possible to base/)

someone can say I did foo with macports version x.y.z, it's hard for an 
end-user to know I did foo with macports verison x.y.z and the revision of 
portgroup blah that I got in my last portsync which corresponds with rXX in 
your repo

--
Daniel J. Luke  
 
++  
  
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++  
  
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++



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


Re: imake

2014-09-29 Thread Ian Wadham

On 29/09/2014, at 3:25 PM, Nicolas Pavillon wrote:
 On 29/09/2014 13:03, Brandon Allbery wrote:
 On Sun, Sep 28, 2014 at 11:51 PM, Brandon Allbery allber...@gmail.com 
 wrote:
 If I understood other discussions correctly, KDE3 is already being removed.
 
 Sorry, not discussions; recent commit messages indicate that it's being 
 obsoleted and slated for removal starting from the leaves. See for example 
 r125868, r125871.
 
 I had mentioned the idea of making KDE3 obsolete quite some time ago (months) 
 on the list, but never got to do it. I indeed started (independently from the 
 imake discussion, just a coincidence) some days ago with the dependents 
 ports. I going slightly slowly on this part as I am trying to find 
 replacements for the few remaining kde3-based apps whenever possible.
 The idea would be to then remove the kde3 suite after all dependents have 
 been taken care of. 
 
 The biggest remaining issue is koffice. Ideally, it could be replaced by 
 calligra (requested in ticket #https://trac.macports.org/ticket/37579), but 
 it seems plagued with several problems at runtime making it only very partly 
 usable on OS X. 

As Ryan said, it is not really the duty of MacPorts developers to keep
ports alive if they are not supported upstream.  KDE 3 is long since
dead (unmaintained) and all KDE apps dependent on KDE 3 with it.
So, do not worry about KOffice… :-(

As a KDE developer, I do not like this aspect of KDE, but it is a fact of
life. If there is nobody available to port a KDE app to a new version of
KDE, then the app becomes unmaintained and is no longer released.

KDE 4 is heading that way right now, as the emphasis (in the KDE
project) shifts to Frameworks and KF5. Marko, René and I are working
to make the transition easier for MacPorts developers and users this
time around. When we have time, we should see what can be done to
make Calligra more workable in KDE 4 on Apple OS X.

ATM I do not see more than a trickle of KDE 4 apps that have been
ported to KF5. Maybe that will become a flood later.

Meanwhile, I do not know what other FOSS office suites might be a
goer on MacPorts. I use LibreOffice…

Cheers, Ian W.


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


Re: [125934] trunk/dports/mail

2014-09-29 Thread Ryan Schmidt

 On Sep 29, 2014, at 5:48 PM, pixi...@macports.org wrote:
 
 Revision
 125934
 Author
 pixi...@macports.org
 Date
 2014-09-29 15:48:32 -0700 (Mon, 29 Sep 2014)
 Log Message
 
 mail/postfinger:
 - New port for postfinger, a postfix configuration reporting tool.
 
 Added Paths
 
   • trunk/dports/mail/postfinger/
   • trunk/dports/mail/postfinger/Portfile
 Diff
 
 Added: trunk/dports/mail/postfinger/Portfile (0 = 125934)
 
 --- trunk/dports/mail/postfinger/Portfile (rev 0)
 +++ trunk/dports/mail/postfinger/Portfile 2014-09-29 22:48:32 UTC (rev 
 125934)
 
 @@ -0,0 +1,44 @@
 
 +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
 c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
 +# $Id$
 +
 +PortSystem  1.0
 +
 +namepostfinger
 +version 1.30
 +categories  mail
 +platforms   darwin
 +maintainers pixilla openmaintainer
 +license GPL-2+
 +
 +description Postfix Configuration Summary Reporter
 +long_description${description}
 +
 +homepage
 http://ftp.wl0.org/SOURCES/postfinger
 
 +master_sites
 ftp://ftp.wl0.org/ftp.wl0.org/postfinger/
 
 +
 +extract.suffix
 +
 +distfiles   ${name}-${version} \
 +README
 +checksums   ${name}-${version} \
 +rmd160  62f8e8ce2888bf3d9e615072e9f25284d3f4155e \
 +sha256  
 2c993b87ca3063eb4b81f7f652d6292a72d777be500bda214d54ce485aee2fd0 \
 +README \
 +rmd160  7f08ecd13c073d81ca11ef097370fbdd361adb3d \
 +sha256  
 1e842f569b1d7878adc6bb38a1f5e80d8d3d25de051b820527f7f9fb9a8a4d95
 +
 +extract.mkdir   yes
 +extract {
 +file copy ${distpath}/[lindex ${distfiles} 0] ${worksrcpath}/${name}
 +file copy ${distpath}/[lindex ${distfiles} 1] ${worksrcpath}/
 +}
 +use_configure   no
 +build   {}
 +destroot {
 +xinstall -m 755 ${worksrcpath}/${name} ${destroot}${prefix}/bin/
 +xinstall -d -m 0755 ${destroot}${prefix}/share/doc/${name}
 +xinstall -m 644 ${worksrcpath}/README 
 ${destroot}${prefix}/share/doc/${name}/
 +}
 +
 +livecheck.url   [lindex ${master_sites} 0]
 +livecheck.regex ${name}-(\[0-9.\]+)

I presume this is noarch?

Remember you'll have to use the unversioned distfile recipe eventually, if the 
README ever changes.


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