Re: Why oxygen-icons port requires qt4-mac phonon?
Hi Marko - Because it uses the kde4 1.1 PortGroup :) Seems like if the port is noarch and is KDE related, then maybe it does not need those dependencies? I don't use this port, nor the rest of KDE (at least at this time). - MLD On Tue, Jun 3, 2014, at 09:40 PM, Marko Käning wrote: Why do the oxygen-icons actually require ports qt4-mac and phonon installed? --- $ port deps oxygen-icons Full Name: oxygen-icons @4.12.5_0 Extract Dependencies: xz Build Dependencies: cmake, pkgconfig, automoc Library Dependencies: qt4-mac, phonon --- ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Why oxygen-icons port requires qt4-mac phonon?
Hello, If I remember correctly, oxygen-icons was also using some dependencies during configurations, but I am not fully sure, and it appears that it is not the case presently. One thing is that since oxygen-icons is used in practice by ports such as kde4-baseapps, these dependencies are pulled out anyway, and I wonder if some configurations within the kde4 portgroup are not necessary to install things correctly. The fact of removing kde4 may be more trouble than it is worth. Cheers, Nicolas On Jun4, 2014, at 14:02, Michael Dickens michae...@macports.org wrote: Hi Marko - Because it uses the kde4 1.1 PortGroup :) Seems like if the port is noarch and is KDE related, then maybe it does not need those dependencies? I don't use this port, nor the rest of KDE (at least at this time). - MLD On Tue, Jun 3, 2014, at 09:40 PM, Marko Käning wrote: Why do the oxygen-icons actually require ports qt4-mac and phonon installed? --- $ port deps oxygen-icons Full Name: oxygen-icons @4.12.5_0 Extract Dependencies: xz Build Dependencies: cmake, pkgconfig, automoc Library Dependencies: qt4-mac, phonon --- ___ 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: Permissions change with MacPorts 2.3?
Hi, Based on some searching (ie no hands-on experience!), it seems that it might be simpler to create a .metadata_never_index file [1] inside that folder to encourage Spotlight to leave it alone. Alternatively, we could add .noindex to the folder name to achieve the same effect. Wouldn't one of these be a better solution? None of those posts have any references to any official documentation by Apple and there's no source code available for Spotlight to check for myself. Just trying it on my system would have been an option, but that doesn't necessarily mean it will work on all platforms supported by MacPorts base. I found dome documentation on apple.com that suggests marking the folder hidden achieves Spotlight index exclusion, but I don't have the link at hand right now. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Boost.Python and g++
Wow, that looks a lot simpler than I thought that it would be... I was expecting something like this would have to be fixed upstream by gcc, because that is how they handle the GNU vs. NeXT Objective C runtime issues, but if all it takes in this case is this script, it seems like just using this script would be easier... the main thing I worry about would be how the version numbers are hardcoded, but that seems like it should be easy enough to fix. (cc-ing macports-dev because this seems like more of a development issue) On Mon, Jun 2, 2014 at 7:29 AM, Akim Demaille akim.demai...@gmail.com wrote: Hi all, A long long time ago I had started discussing (well, complaining might be more appropriate :-) about the fact that I could no longer use g++ to compile my project, because Boost.Python was compiled with clang++'s libc++. Well, since then I managed to wrap a dirty script, g++-libc++, which does the trick for me: it compiles with g++, but using libc++. It might be useful for some users. Actually, maybe it should be shipped with MacPorts' g++ (some distros provide similar scripts to GNU/Linux to use clang++ on top of libstdc++). Cheers. ___ macports-users mailing list macports-us...@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: certsync: Please test patches on systems 10.9
Like we do with the Portfiles in trunk, could you split the patch between the whitespace changes and the functionality changes? Right now with the two of them together, it is kind of harder to know which sections of the patch to focus on when reading it... On Mon, Jun 2, 2014 at 6:41 PM, Clemens Lang c...@macports.org wrote: Hi, […] test the attached patch […] Attached, sorry. -- Clemens Lang ___ 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: Why oxygen-icons port requires qt4-mac phonon?
Hi Nicolas Michael, ah, I see, the kde port group… That explains it. On 04 Jun 2014, at 14:20 , Nicolas Pavillon ni...@macports.org wrote: If I remember correctly, oxygen-icons was also using some dependencies during configurations, but I am not fully sure, and it appears that it is not the case presently. Hmm... ok… One thing is that since oxygen-icons is used in practice by ports such as kde4-baseapps, these dependencies are pulled out anyway, and I wonder if some configurations within the kde4 portgroup are not necessary to install things correctly. The fact of removing kde4 may be more trouble than it is worth. I see your point there! I wanted to abuse it for the KDE/CI system which I am trying to set up using MacPorts. (There I need just the icons without qt4-mac or anything else.) It would have been nice if the icons wouldn’t need any dependencies, as Harald Fernengel managed to use them as well on Homebrew without extra deps. But I won’t object if you are reluctant to change anything there. Greets, Marko ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [120476] trunk/dports/cross/avrdude/Portfile
Also, while we are commenting on this revision, is the entirety of texlive
really needed for the docs variant? If the description says that it
requires LaTeX, that seems to me like it would just indicate a dependency
on texlive-latex or maybe texlive-latex-extra, but not necessarily the
whole texlive distribution... but idk, I could be wrong, just wondering...
On Thu, May 29, 2014 at 5:01 PM, Ryan Schmidt ryandes...@macports.org
wrote:
On May 29, 2014, at 10:22 AM, g...@macports.org wrote:
Revision
120476
Author
g...@macports.org
Date
2014-05-29 08:22:23 -0700 (Thu, 29 May 2014)
Log Message
cross/avrdude:
docs require latex to be present, so adding texlive ad a build
dependency,
and making the variant optional
Modified Paths
• trunk/dports/cross/avrdude/Portfile
Diff
Modified: trunk/dports/cross/avrdude/Portfile (120475 = 120476)
--- trunk/dports/cross/avrdude/Portfile 2014-05-29 15:13:37 UTC
(rev 120475)
+++ trunk/dports/cross/avrdude/Portfile 2014-05-29 15:22:23 UTC
(rev 120476)
@@ -5,6 +5,7 @@
name avrdude
version 6.1
+revision 1
categoriescross devel
maintainers bdmicro.com:bsd
description an Atmel AVR MCU programmer
@@ -29,10 +30,8 @@
configure.args--mandir=${prefix}/share/man \
--disable-parport
-variant docs description {Build documentation} {
-depends_build-append port:texinfo
+variant docs description {Build documentation (requires LaTeX)} {
+depends_build-append port:texlive
configure.args-append --enable-doc
}
-
-default_variants +docs
There is no reason to revbump when removing default variants, because
MacPorts will not remove variants from an installed port unless the user
explicitly tells it to do so (e.g. by using sudo port upgrade
--enforce-variants avrdude -docs)
___
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: Permissions change with MacPorts 2.3?
According to Fink's documentation, adding a .build extension to the
folder name has the same effect as adding a .noindex extension to it,
which is what they do with their build folder:
http://www.finkproject.org/doc/users-guide/uguide.en.html#conf.optional
So that could be another option...
On Tue, Jun 3, 2014 at 9:16 PM, Craig Treleaven ctrelea...@cogeco.ca
wrote:
At 11:02 PM +0200 6/3/14, Clemens Lang wrote:
Hi,
I sometimes use EasyFind to search in portfiles. I noticed today
that the macports folder under ${prefix}/var is no longer visible. I
would guess this happened after I upgraded to MacPorts 2.3 but I
can't be certain. Using the command line, I see the following:
[Š]
Was it an intended change to hide this directory? Or a glitch on my
system?
That was intentional. In specific, it's this Changelog entry:
Disable Spotlight indexing on build directories, distfiles,
registry, log files, archives, base source and the default ports
tree. (cal in r113649)
You can avoid this by manually reverting the change and touching a file
named .nohide in the directory. See
http://trac.macports.org/changeset/113649
Thanks. I noticed that in the change log but didn't see how it was
implemented.
Based on some searching (ie no hands-on experience!), it seems that it
might be simpler to create a .metadata_never_index file [1] inside that
folder to encourage Spotlight to leave it alone. Alternatively, we could
add .noindex to the folder name to achieve the same effect.
Wouldn't one of these be a better solution?
Craig
[1] http://apple.stackexchange.com/questions/92784/
preventing-spotlight-from-indexing-files-folders
___
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
KDE3
Hello, This topic has been discussed some time ago on this mailing list without a real conclusion, but I am again considering the status of KDE3 on Macports. Considering that Qt5 is out and KDEF5 is soon to be released, it makes KDE3 more and more obsolete. Furthermore, it seems to not build presently on the later platforms (ticket #41136). I would therefore start considering making the whole KDE3 suite gradually obsolete unless there is some opposition after my mail. Considering the existing ports, it seems to me that there are first some dependents ports which could be dealt with (see list below), and then the KDE3 suite itself which could be made obsolete in a second stage. I tried to make below a list of the existing ports depending on kde3 that I hope to be exhaustive, along with my opinion about their status. Of course, any opinion is welcome about them. My idea would be that in case all the ports below can be handled, I would seriously consider to then make the whole kde3 suite obsolete too. Ports that can be replaced: - kmymoney: can be replaced with kmymoney4 - filelight: can be replaced with kde4-filelight - kcachegrind: can be replaced with kcachegrind4 - konversation11: can be replaced with konversation Ports without replacement: - kchmviewer: still depends on qt3, possesses a variant for kde which is said to be untested. The variant could be dropped in my opinion. - klibido: appears to be not developed anymore since 2006. After 8 years, the ports could be made obsolete. - ndmanager: there was a notice announcing the passage to qt4 in mid-2013, but no new development. Could be made obsolete. - qalculate-kde: there is a new version for kde4, but I could not get it to build. Even qalculate-gtk does not build presently on my platform. If the build is not fixed, it could be made obsolete anyway. - koffice: This is a big piece of kde3, along with a whole bunch of language ports. There is a koffice2-devel port, but it has not been maintained at all (nomaintainer). It still depends on the old kde4 1.0 portgroup, and fails at the configure stage. As it is a non-working *-devel port, I would tend to make it obsolete. There is also a new submission request for calligra (ticket #37579), which has not been submitted yet. I tested a little bit with the latest versions, and I can get something partly working, so that a port commit could be considered with what I have. For what I understand from a simplistic web search, calligra seems more promising than koffice2 as a stable release software. Koffice may then be set a replaced by calligra. From the list above, there could be some clean up which could be beneficial, along with some ports which are clearly obsolete. Then, in the case all of the above can be dealt with, it seems to me that kde3 could be set as obsolete and replaced by kde4. However, this simplistic way of expressing it does not consider the mess of ports in both architectures, so that a way of making the transition should be thought of. Cheers, Nicolas ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: KDE3
We can always revert your deletions, so I’d just go for it. If there are any issues, it should start with a discussion of relevancy. As you point out KDE3 is beyond hope in many measures, but if there’s some very good reason that’s hidden then source control will show its magic. On Jun 4, 2014, at 19:53, Nicolas Pavillon ni...@macports.org wrote: Furthermore, it seems to not build presently on the later platforms (ticket #41136). I would therefore start considering making the whole KDE3 suite gradually obsolete unless there is some opposition after my mail. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [120644] trunk/dports/games/moria/Portfile
On Jun 4, 2014, at 10:01 AM, m...@macports.org wrote:
Revision
120644
Author
m...@macports.org
Date
2014-06-04 08:01:51 -0700 (Wed, 04 Jun 2014)
Log Message
moria: Install files required by license.
Modified Paths
• trunk/dports/games/moria/Portfile
Diff
Modified: trunk/dports/games/moria/Portfile (120643 = 120644)
--- trunk/dports/games/moria/Portfile 2014-06-04 14:58:29 UTC (rev 120643)
+++ trunk/dports/games/moria/Portfile 2014-06-04 15:01:51 UTC (rev 120644)
@@ -70,6 +70,13 @@
xinstall -m 644 -c ${worksrcpath}/files/rwizcmds.hlp
${destroot}${prefix}/var/games/moria
xinstall -m 644 -c ${worksrcpath}/files/version.hlp
${destroot}${prefix}/var/games/moria
xinstall -m 644 -c ${worksrcpath}/files/welcome.hlp
${destroot}${prefix}/var/games/moria
+
+# Files required by license
+xinstall -m 644 -c ${worksrcpath}/util/mergemem/README
${destroot}${prefix}/var/games/moria
+xinstall -m 644 -c ${worksrcpath}/util/mergemem/moriadecode.c
${destroot}${prefix}/var/games/moria
+xinstall -m 644 -c ${worksrcpath}/util/mergemem/moriaencode.c
${destroot}${prefix}/var/games/moria
+xinstall -m 644 -c ${worksrcpath}/util/mergemem/moriamerge.c
${destroot}${prefix}/var/games/moria
+
}
If it changes the files that are installed, the revision should be increased.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [120646] trunk/dports/python/py-spyder-devel
On Jun 4, 2014, at 11:40 AM, ebori...@macports.org wrote:
Revision
120646
Author
ebori...@macports.org
Date
2014-06-04 09:40:10 -0700 (Wed, 04 Jun 2014)
Log Message
py-spyder-devel: Update to 2.3.0rc; Add noAntiAlias variant: turns off
antialiasing in editor.
Modified Paths
• trunk/dports/python/py-spyder-devel/Portfile
Added Paths
• trunk/dports/python/py-spyder-devel/files/no_AA.diff
Diff
Modified: trunk/dports/python/py-spyder-devel/Portfile (120645 = 120646)
+variant noAntiAlias description {Use non-anti-aliased fonts in editor.} {
+patchfiles-append no_AA.diff
+}
Note that variant names are treated case-sensitively, unlike port names. I
think this is a bug, which I filed as:
https://trac.macports.org/ticket/25970
But it is not fixed yet. And this is one of the reasons we usually use
lowercase letters for variant names, often with underscores separating words,
instead of using camelCase names.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: KDE3
Hi Nicolas, I haven’t done anything for KDE3 for a long time and if so it was just cleaning up stg which didn’t work anymore wrt kmymoney... So, I think it is fine to start disentangling KDE4 and KDE3 and getting rid of the latter bit by bit now. Greets, Marko ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
