Re: Snow Leopard buildbot out of disk space
On 2014-5-5 14:48 , Ryan Schmidt wrote: > Shree, > > Did you ever discover where all the disk space is disappearing to, or compare > all the buildslaves to see if their disk usage is similar? You previously > mentioned a lot of disk space being used in /opt/local/var/macports/software. > We decided that was normal, since the buildbot scripts don't uninstall ports > but only deactivate them, so that they can be easily reactivated later. Did > you check whether this directory perhaps contains all previous versions of a > port? If so, that would be an opportunity for cleanup. For example, check if > /opt/local/var/macports/software/graphviz-devel contains numerous archives, > or only the one for the current version 2.39.20140425.0445. On the other > hand, it could just be that as we add more and more new ports to our > collection, we’re going to need more and more disk space to store the > archives. Each new version of llvm/clang, for example, takes another 1GB of > disk space. You can watch the old versions being uninstalled in the cleanup step. I really doubt they're going to be there. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [119727] trunk/dports/math/OpenBLAS-devel/Portfile
On May 4, 2014, at 21:27, ni...@macports.org wrote: > Revision > 119727 > Author > ni...@macports.org > Date > 2014-05-04 19:27:10 -0700 (Sun, 04 May 2014) > Log Message > > OpenBLAS-devel: update to latest commit > Modified Paths > > • trunk/dports/math/OpenBLAS-devel/Portfile > Diff > > Modified: trunk/dports/math/OpenBLAS-devel/Portfile (119726 => 119727) > > --- trunk/dports/math/OpenBLAS-devel/Portfile 2014-05-05 02:26:17 UTC (rev > 119726) > +++ trunk/dports/math/OpenBLAS-devel/Portfile 2014-05-05 02:27:10 UTC (rev > 119727) > @@ -5,7 +5,8 @@ > PortGroup github 1.0 > PortGroup muniversal 1.0 > > -github.setupxianyi OpenBLAS 1140c489c902 > +github.setupxianyi OpenBLAS 020f36f97091 > +revision1 MacPorts users who had the previous version of this port installed will not be informed of this update via “port outdated” (or “sudo port upgrade outdated”) because: $ ~/macports/users/ryandesign/scripts/vercmp 1140c489c902 020f36f97091 MacPorts considers 1140c489c902 to be greater than 020f36f97091. Increasing the revision has no effect on this. Only increasing the epoch will fix this. And recall that the epoch can never be removed from a port nor decreased. You should pick a version number that in normal updates only increases. A commit hash from a distributed version control system like git is thus not a good choice for the version field. Instead, if the project does not assign version numbers, consider inventing a version number in the MMDD format. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Snow Leopard buildbot out of disk space
Shree, Did you ever discover where all the disk space is disappearing to, or compare all the buildslaves to see if their disk usage is similar? You previously mentioned a lot of disk space being used in /opt/local/var/macports/software. We decided that was normal, since the buildbot scripts don't uninstall ports but only deactivate them, so that they can be easily reactivated later. Did you check whether this directory perhaps contains all previous versions of a port? If so, that would be an opportunity for cleanup. For example, check if /opt/local/var/macports/software/graphviz-devel contains numerous archives, or only the one for the current version 2.39.20140425.0445. On the other hand, it could just be that as we add more and more new ports to our collection, we’re going to need more and more disk space to store the archives. Each new version of llvm/clang, for example, takes another 1GB of disk space. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: trac is currently having a problem: adding comments isn't possible
On May 2, 2014, at 14:20, mk-macpo...@techno.ms wrote: > >> On 02 May 2014, at 21:12 , Clemens Lang wrote: >> Maybe it depends on the comment content? Did you try adding a comment with >> a different text? > Ha, thanks, why didn’t I think of that now… > It worked. > So, I have to rewrite my message and see. > Check if anything you wrote matches anything in the BadContent wiki page. An entry there may be too broad and may need to be made more specific. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: compiler.blacklist
At 10:28 PM -0500 5/3/14, Ryan Schmidt wrote:
On May 3, 2014, at 07:28, Craig Treleaven wrote:
At 8:34 PM -0500 5/2/14, Ryan Schmidt wrote:
On May 2, 2014, at 20:20, Craig Treleaven wrote:
For my mythtv-core.xx ports, I want to blacklist clang prior to
XCode 5, so I added:
compiler.blacklist-append { clang <= 500.2.79 } \
>macports-clang*
That doesn't work when I build on Lion with XCode 4.3.3 (clang
318.0.61)--it tries to build with clang and falls over.
That sounds like you may not have included the
compiler_blacklist_versions 1.0 portgroup. If you do that, it
should do what you say: blacklist all MacPorts clangs, and Xcode
clangs less than 500. So on Macs with Xcode 4 or earlier, you'll
be building with llvm-gcc-4.2 or gcc-4.2. Is that really what you
want? If Xcode 5's clang is ok, presumably MacPorts clang 3.5
would work too, maybe even 3.4, and those would probably be
preferable to the old llvm-gcc or gcc.
You are indeed correct; the line to add the
compiler_blacklist_versions portgroup got dropped somewhere along
the way. And the buildbots were down when the change was committed.
Is this something that lint could be made to pick up? ie a
compiler version comparison used but required PortGroup missing?
Good idea. Done in r119714.
Ultimately the workings of the compiler_blacklist_versions portgroup
should be incorporated into base instead.
Pre-XCode 5, Myth builds and runs fine with gcc and llvm-gcc. The
the upstream project only recently put in some fixes that allow it
to build with later versions of clang.
Re MacPorts-supplied versions of clang, I simply haven't tried to
build with them. I cribbed that section from qt4-mac port since it
had the same issue with LIBRARY_PATH that I had. The
'macports-clang*' exclusion is probably extraneous but I wanted to
be sure to use know-working compilers, only.
There may be some small difference between MacPorts clang and Xcode
clang, but the primary difference is the version numbering.
According to our XcodeVersionInfo wiki page, Xcode 5.0 came with
"Apple LLVM version 5.0 (clang-500.2.75) (based on LLVM 3.3svn)".
"LLVM 3.3svn" means that this version corresponds to some version of
LLVM that is greater than 3.3 and less than 3.4. So if you already
know that Xcode 5's clang works, and earlier Xcodes' clangs don't
work, then you also know that MacPorts clang 3.3 and earlier won't
work either, and MacPorts clang 3.4 and later should work.
Thanks, I'll add this to the list of things to test. I'm a bit
gunshy about compilers. After XCode 4.4 came out, the port would
compile with certain compilers but threw runtime failures (seemingly
deep in libunwind). I never did find the cause of the problem, but
with help, we found certain combinations that worked and stuck with
them. Don't want to re-awaken the monsters! ;)
Craig
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
