Any wxMSW users out there?
Hi, a while back I did a clean-up of wxWidgets ports, including wxGTK, but I didn't touch wxMSW. The question is: does anyone really need wxMSW or may we delete it? The port is outdated (the version 2.8.4 is from May 2007, it hasn't even been upgraded to version 2.8.5 from September 2007) and fails already during configure (it is possible that the problem is at least somewhat related to MinGW, but I don't really know). And yet there is no single bug report requesting an upgrade or a fix to allow building the port. My assumption is that nobody has been using this port for a long time. I would suggest to delete it unless there are any objections or needs to keep it around. Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
tarball mismatch ...
Hi all,
I have a problem with matching checksums and realise that the same tarball
(by name) is actually different depending on the download sites. This is from
my Apache libcloud port:
master_siteswww.apache.org/dist/libcloud/ \
https://pypi.python.org/packages/source/${_n}/${_name}/
The published checksums correspond for each source, but do not match, so the
tarball is effectively different. I filed a ticket for this, but how would you
deal with such an situation in general or if there is no reply.
Thanks!
~petr
smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: tarball mismatch ...
Choose to get rid of one of the master sites. Peter Danecek wrote: The published checksums correspond for each source, but do not match, so the tarball is effectively different. I filed a ticket for this, but how would you deal with such an situation in general or if there is no reply. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: tarball mismatch ...
But which one would you consider correct than? Apache because it is upstream, or PyPI because it is probably the one more frequently installed. On Dec 12, 2013, at 15:27 , Jeremy Lavergne jer...@lavergne.gotdns.org wrote: Choose to get rid of one of the master sites. Peter Danecek wrote: The published checksums correspond for each source, but do not match, so the tarball is effectively different. I filed a ticket for this, but how would you deal with such an situation in general or if there is no reply. smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: tarball mismatch ...
It's entirely up to you, as there's already a split on which one to use. I'd personally go upstream since its the official host of the software. Peter Danecek wrote: But which one would you consider correct than? Apache because it is upstream, or PyPI because it is probably the one more frequently installed. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: tarball mismatch ...
you may also want to download both and diff them yourself to see if there are any 'real' differences. On Dec 12, 2013, at 9:38 AM, Jeremy Lavergne jer...@lavergne.gotdns.org wrote: It's entirely up to you, as there's already a split on which one to use. I'd personally go upstream since its the official host of the software. Peter Danecek wrote: But which one would you consider correct than? Apache because it is upstream, or PyPI because it is probably the one more frequently installed. -- Daniel J. Luke dl...@us.ntt.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: tarball mismatch ...
I just got a reply from the developers, reportedly there are no real difference and they will try to take care of this, so the problem might be gone soon. For the moment, I workaround the problem by using the bzip2 tarball which is not effected. ~petr On Dec 12, 2013, at 15:45 , Daniel J. Luke dl...@geeklair.net wrote: you may also want to download both and diff them yourself to see if there are any 'real' differences. On Dec 12, 2013, at 9:38 AM, Jeremy Lavergne jer...@lavergne.gotdns.org wrote: It's entirely up to you, as there's already a split on which one to use. I'd personally go upstream since its the official host of the software. Peter Danecek wrote: But which one would you consider correct than? Apache because it is upstream, or PyPI because it is probably the one more frequently installed. -- Daniel J. Luke dl...@us.ntt.net smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
livechecking ...
Hi all,
I have some questions concerning livecheck.
(1) livecheck default behaviour
I started introducing the livecheck part only recently (after having found in
other ports) and am now going back to older ports and realise that if you did
not care before, it most like would leave the port with broken livechecking.
From the Guide I understand that the fallback default is `freecode`. Is this
what works for most ports out of the box? Or have all these ports now an
explicit livecheck section?
I now started using something like the following and so far it works in most
cases. The assumption here is, that newer versions will go into a similar
download directory (page) as where the current version comes from.
{{{
livecheck.type regex
livecheck.url [lindex ${master_sites} 0]
livecheck.regex ${_name}-(\\d+(\\.\\d+)+)\\${extract.suffix}
}}}
Wouldn't it make sense to something similar into the default `livecheck`
sequence?
However, implementing it exactly this way has one problem. When mirrors
(predefined site lists) are used in `master_sites` code above will fail. It
would be necessary to expand to the list provided by mirror_sites.tcl first.
(2) livecheck only for main port
Recently, a committer added the following code block to one of my ports.
if {${name} ne ${subport}} {
[...]
livecheck.type none
} else {
livecheck.type regex
livecheck.url https://pypi.python.org/pypi/${real_name}
livecheck.regex ${real_name}-(\[0-9.\]+)${extract.suffix}
}
This disables livechecking for subports and enables it only for the main port.
I am wondering why this is useful. I usually just added livechecking at the
end, observed no problems so far.
(3) For the globus ports it would be very useful to have the possibility to
check a set of URLs (actually 2) extract the pattern according to the regex,
concat the results and evaluate for the version in the in the usual way. I am
thinking of a specification of this kind (in analogy to licences):
{{{
livecheck.type regex
livecheck.url { http://www.globus.org/ftppub/gt5/5.2/5.2.5/packages/src/ \
http://www.globus.org/ftppub/gt5/5.2/5.2.5/updates/src/ }
livecheck.regex ${_name}-(\\d+(\\.\\d+)+)\\${extract.suffix}
Would something like this be TOO difficult to implement?
Where should I go and look to get some better idea?
Thanks a lot!
~petr
smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: livechecking ...
Peter Danecek wrote:
From the Guide I understand that the fallback default is `freecode`. Is this
what works for most ports out of the box? Or have all these ports now an explicit
livecheck section?
I now started using something like the following and so far it works in most
cases. The assumption here is, that newer versions will go into a similar
download directory (page) as where the current version comes from.
{{{
livecheck.type regex
livecheck.url [lindex ${master_sites} 0]
livecheck.regex ${_name}-(\\d+(\\.\\d+)+)\\${extract.suffix}
}}}
Wouldn't it make sense to something similar into the default `livecheck`
sequence?
However, implementing it exactly this way has one problem. When mirrors (predefined site
lists) are used in `master_sites` code above will fail. It would be necessary to expand
to the list provided by mirror_sites.tcl first.
The default is basically for sites which never have an explicit
livecheck. Maintainers should ensure their livechecks are correct, be it
default or otherwise. You're probably correct in assuming this
necessitates an explicit livecheck for new Portfiles.
(2) livecheck only for main port
This disables livechecking for subports and enables it only for the main port.
I am wondering why this is useful. I usually just added livechecking at the
end, observed no problems so far.
Most maintainers only need to know that the package was updated, not
that every instance defined in the Portfile was updated. For example,
reports based on `port livecheck maintainer:petr` would be littered with
duplicate messages unless you disable livechecks in the extraneous subports.
This does assume your subports are simply the same software, rather than
separate packages. ZendFramework uses subports that are distinct packages:
http://trac.macports.org/browser/trunk/dports/www/ZendFramework/Portfile?rev=113073
(3) For the globus ports it would be very useful to have the possibility to
check a set of URLs (actually 2) extract the pattern according to the regex,
concat the results and evaluate for the version in the in the usual way. I am
thinking of a specification of this kind (in analogy to licences):
{{{
livecheck.type regex
livecheck.url { http://www.globus.org/ftppub/gt5/5.2/5.2.5/packages/src/ \
http://www.globus.org/ftppub/gt5/5.2/5.2.5/updates/src/
}
livecheck.regex ${_name}-(\\d+(\\.\\d+)+)\\${extract.suffix}
Would something like this be TOO difficult to implement?
Where should I go and look to get some better idea?
This doesn't sound like a common use case... that being said, there
probably is no harm in implementing livecheck.url as a list. You'll want
to look in the trunk/base/src code for the livecheck code and the
trunk/dports/_resources for some other uses of livecheck.
I'd also recommend parsing the version (to get 5.2 from 5.2.5) so you
don't need to update the livecheck everytime there's a new version.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: livechecking ...
On Dec 12, 2013, at 19:17 , Jeremy Lavergne jer...@lavergne.gotdns.org wrote:
Peter Danecek wrote:
From the Guide I understand that the fallback default is `freecode`. Is
this what works for most ports out of the box? Or have all these ports now
an explicit livecheck section?
I now started using something like the following and so far it works in most
cases. The assumption here is, that newer versions will go into a similar
download directory (page) as where the current version comes from.
{{{
livecheck.type regex
livecheck.url [lindex ${master_sites} 0]
livecheck.regex ${_name}-(\\d+(\\.\\d+)+)\\${extract.suffix}
}}}
Wouldn't it make sense to something similar into the default `livecheck`
sequence?
However, implementing it exactly this way has one problem. When mirrors
(predefined site lists) are used in `master_sites` code above will fail. It
would be necessary to expand to the list provided by mirror_sites.tcl
first.
The default is basically for sites which never have an explicit livecheck.
Maintainers should ensure their livechecks are correct, be it default or
otherwise. You're probably correct in assuming this necessitates an explicit
livecheck for new Portfiles.
Okay, but then a `livecheck.type none` default might be the cleaner default,
at least it would not produce all these errors. Anyway, I will update my ports
ASAP.
(2) livecheck only for main port
This disables livechecking for subports and enables it only for the main
port. I am wondering why this is useful. I usually just added livechecking
at the end, observed no problems so far.
Most maintainers only need to know that the package was updated, not that
every instance defined in the Portfile was updated. For example, reports
based on `port livecheck maintainer:petr` would be littered with duplicate
messages unless you disable livechecks in the extraneous subports.
This does assume your subports are simply the same software, rather than
separate packages. ZendFramework uses subports that are distinct packages:
http://trac.macports.org/browser/trunk/dports/www/ZendFramework/Portfile?rev=113073
I see the point with multiple messages from subports. On the other hand,
something like: `port livecheck installed` would not necessary produce the
expected result, at least for all the python subports, right? But, maybe this
is not the desired use case.
(3) For the globus ports it would be very useful to have the possibility to
check a set of URLs (actually 2) extract the pattern according to the regex,
concat the results and evaluate for the version in the in the usual way. I
am thinking of a specification of this kind (in analogy to licences):
{{{
livecheck.type regex
livecheck.url {
http://www.globus.org/ftppub/gt5/5.2/5.2.5/packages/src/ \
http://www.globus.org/ftppub/gt5/5.2/5.2.5/updates/src/
}
livecheck.regex ${_name}-(\\d+(\\.\\d+)+)\\${extract.suffix}
Would something like this be TOO difficult to implement?
Where should I go and look to get some better idea?
This doesn't sound like a common use case... that being said, there probably
is no harm in implementing livecheck.url as a list. You'll want to look in
the trunk/base/src code for the livecheck code and the
trunk/dports/_resources for some other uses of livecheck.
I agree, that this is probably not the most common situation. But I **really**
would like to have livechecking for all the single components of the Globus
Toolkit in place. It would make tracking updates a lot easier easiest and that
is what livecheck is for, and I do not see another way to implement
livechecking here.
Well, maybe there is another one:
Only checking http://www.globus.org/ftppub/gt5/5.2/5.2.5/updates/src/. But then
again, I would need to be able to influence how the fact that an update is NOT
found is interpreted.
The desired behaviour would be then:
search pattern
if pattern found: compare to the current version
if ${largest_pattern} ${version}: is outdated
if ${largest_pattern} == ${version}: is up-to-date
if ${largest_pattern} ${version}: unexpected situation (maybe error)
if pattern not found: is up-to-date
But it is not possible to implement this kind of behaviour neither, right?
Which alternative is better, easier to implement?
I'd also recommend parsing the version (to get 5.2 from 5.2.5) so you don't
need to update the livecheck everytime there's a new version.
Agreed!
These are determined automatically (it is partly implemented), but I would like
to introduce a portgroup for this. Not sure on the details, I will follow up on
this as well ;-)
Here, I just copied the whole URL, just in case someone would be interested to
look it up.
~petr
smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
Re: livechecking ...
On Dec 12, 2013, at 13:23, Peter Danecek peter.dane...@bo.ingv.it wrote:
On Dec 12, 2013, at 19:17 , Jeremy Lavergne jer...@lavergne.gotdns.org
wrote:
Peter Danecek wrote:
From the Guide I understand that the fallback default is `freecode`. Is
this what works for most ports out of the box? Or have all these ports now
an explicit livecheck section?
I now started using something like the following and so far it works in
most cases. The assumption here is, that newer versions will go into a
similar download directory (page) as where the current version comes from.
{{{
livecheck.type regex
livecheck.url [lindex ${master_sites} 0]
livecheck.regex ${_name}-(\\d+(\\.\\d+)+)\\${extract.suffix}
}}}
Wouldn't it make sense to something similar into the default `livecheck`
sequence?
However, implementing it exactly this way has one problem. When mirrors
(predefined site lists) are used in `master_sites` code above will fail. It
would be necessary to expand to the list provided by mirror_sites.tcl
first.
The default is basically for sites which never have an explicit livecheck.
Maintainers should ensure their livechecks are correct, be it default or
otherwise. You're probably correct in assuming this necessitates an explicit
livecheck for new Portfiles.
Okay, but then a `livecheck.type none` default might be the cleaner
default, at least it would not produce all these errors. Anyway, I will
update my ports ASAP.
I guess it was thought that a default livecheck that sometimes tells you an
update is available and sometimes tells you something went wrong is better than
a default livecheck that never tells you anything.
(2) livecheck only for main port
This disables livechecking for subports and enables it only for the main
port. I am wondering why this is useful. I usually just added livechecking
at the end, observed no problems so far.
Most maintainers only need to know that the package was updated, not that
every instance defined in the Portfile was updated. For example, reports
based on `port livecheck maintainer:petr` would be littered with duplicate
messages unless you disable livechecks in the extraneous subports.
This does assume your subports are simply the same software, rather than
separate packages. ZendFramework uses subports that are distinct packages:
http://trac.macports.org/browser/trunk/dports/www/ZendFramework/Portfile?rev=113073
I see the point with multiple messages from subports. On the other hand,
something like: `port livecheck installed` would not necessary produce the
expected result, at least for all the python subports, right? But, maybe this
is not the desired use case.
Correct, that’s not the intended use case. livecheck is for port maintainers to
discover if new versions of the ports they maintain are available.
(3) For the globus ports it would be very useful to have the possibility to
check a set of URLs (actually 2) extract the pattern according to the
regex, concat the results and evaluate for the version in the in the usual
way. I am thinking of a specification of this kind (in analogy to licences):
{{{
livecheck.type regex
livecheck.url {
http://www.globus.org/ftppub/gt5/5.2/5.2.5/packages/src/ \
http://www.globus.org/ftppub/gt5/5.2/5.2.5/updates/src/
}
livecheck.regex ${_name}-(\\d+(\\.\\d+)+)\\${extract.suffix}
Would something like this be TOO difficult to implement?
Where should I go and look to get some better idea?
This doesn't sound like a common use case... that being said, there probably
is no harm in implementing livecheck.url as a list. You'll want to look in
the trunk/base/src code for the livecheck code and the
trunk/dports/_resources for some other uses of livecheck.
I agree, that this is probably not the most common situation. But I
**really** would like to have livechecking for all the single components of
the Globus Toolkit in place. It would make tracking updates a lot easier
easiest and that is what livecheck is for, and I do not see another way to
implement livechecking here.
livecheck was implemented with the expectation that for any piece of software,
there will be a single stable url that will list the latest version number. So
far this has generally worked out ok. If this software you’re talking about
does not have such a page, you should ask its developers to create one; it’s in
every user’s best interest to be able to go to a predictable url to find out if
their software is outdated or not.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: build.macports.org failures
On Dec 12, 2013, at 00:28, Joshua Root j...@macports.org wrote: On 2013-12-11 16:47 , Joshua Root wrote: On 2013-12-11 14:29 , Clemens Lang wrote: I've been monitoring the current attempt at building the remaining ports and it seems the buildbot is currently hanging at the valgrind-devel port. It *should* be running a post-fetch phase from the Portfile that uses the svn protocol to check out some sources, but I don't see any progress in the log anymore[1]. Could you maybe just kill the port process (or the svn process, if that's still running) on the Mavericks slave? It doesn't matter if the valgrind-devel build fails in this case, because valgrind-devel will not build on Mavericks anyway. [1] The log is currently at about 2.1 GiB. Seems unlikely it would start to cause problems at this size. It didn't bring down the system, just made the build step fail due to timeout as expected. That isn't great of course, and valgrind-devel should be fixed to not hang, but gathering archives is currently underway despite the failure, as designed. I'll do a build with the last few hundred ports once it finishes up. It seems textmate2 and yap-devel also hung. Both of these fetch with git. textmate2 is unusual. In addition to fetching git submodules in a post-fetch block, the build system also fetches additional software during the build phase. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: livechecking ...
On Dec 12, 2013, at 20:06 , Jeremy Lavergne jer...@lavergne.gotdns.org wrote:
Peter Danecek wrote:
I see the point with multiple messages from subports. On the other hand,
something like: `port livecheck installed` would not necessary produce the
expected result, at least for all the python subports, right? But, maybe
this is not the desired use case.
To me, an end user certainly would not have a need to use livecheck.
A maintainer would need to use livecheck, but on their ports regardless of
currently installed. This is why my example used `maintainer:petr` versus
`installed`.
Sounds reasonable. Will update my ports for this as well.
(3) For the globus ports it would be very useful to have the possibility
to check a set of URLs (actually 2) extract the pattern according to the
regex, concat the results and evaluate for the version in the in the usual
way. I am thinking of a specification of this kind (in analogy to
licences):
{{{
livecheck.type regex
livecheck.url {
http://www.globus.org/ftppub/gt5/5.2/5.2.5/packages/src/ \
http://www.globus.org/ftppub/gt5/5.2/5.2.5/updates/src/ }
livecheck.regex ${_name}-(\\d+(\\.\\d+)+)\\${extract.suffix}
Would something like this be TOO difficult to implement?
Where should I go and look to get some better idea?
This doesn't sound like a common use case... that being said, there
probably is no harm in implementing livecheck.url as a list. You'll want to
look in the trunk/base/src code for the livecheck code and the
trunk/dports/_resources for some other uses of livecheck.
I agree, that this is probably not the most common situation. But I
**really** would like to have livechecking for all the single components of
the Globus Toolkit in place. It would make tracking updates a lot easier
easiest and that is what livecheck is for, and I do not see another way to
implement livechecking here.
Well, maybe there is another one:
Only checking http://www.globus.org/ftppub/gt5/5.2/5.2.5/updates/src/. But
then again, I would need to be able to influence how the fact that an update
is NOT found is interpreted.
The desired behaviour would be then:
search pattern
if pattern found: compare to the current version
if ${largest_pattern} ${version}: is outdated
if ${largest_pattern} == ${version}: is up-to-date
if ${largest_pattern} ${version}: unexpected situation (maybe error)
if pattern not found: is up-to-date
But it is not possible to implement this kind of behaviour neither, right?
Which alternative is better, easier to implement?
This is effectively the existing livecheck procedure.
Not exactly!
But, effectively, the behaviour was changes, since I tested the last time. I
discussed it already on the list, which probably let to this changes.
It is the last part which is different.
If pattern not found it now gives me:
Error: cannot check if globus-common was updated (regex didn't match)
This is for sure reasonable. But in this special case: if no update was
provided, the port is fine and up to date. But of cause if I would mess up the
regex, this be remain undetected, so the procedure above is probably not ideal.
It sounds like the components for globus are updated independently yet stored
in the same location. Is this correct?
Correct, components live their own live, but at certain intervals are released
as a whole toolkit packages. Package managers (for example on Linux) install
the independent components, and so will Macports (hopefully). We (Dennis
provided most of these ports, I CC him) also provide only a subset of all
available components, basically the client part.
Here the list to get you an idea:
{{{
[radegast-wifi:globus-macports/ports/globus-common] petr% port search globus
globus-callout @2.2_1 (net)
Globus Toolkit - Globus Callout Library
globus-clients @2.0_1 (net)
Globus Toolkit - client collection
globus-common @14.9 (net)
Globus Toolkit - Common Library
globus-core @8.9_1 (devel)
Globus Toolkit - Globus Core
globus-ftp-client @7.4_1 (net)
Globus Toolkit - GridFTP Client Library
globus-ftp-control @4.5 (net)
Globus Toolkit - GridFTP Control Library
globus-gass-copy @8.6_1 (net)
Globus Toolkit - Globus Gass Copy
globus-gass-server-ez @4.3_1 (net)
Globus Toolkit - Simple File Server Implementation using GASS Server API
globus-gass-transfer @7.2_1 (net)
Globus Toolkit - Globus Gass Transfer
globus-gram-client @12.4_1 (net)
Globus Toolkit - GRAM Client Library
globus-gram-client-tools @10.4_1 (net)
Globus Toolkit - Job Management Tools (globusrun)
globus-gram-protocol @11.3_1 (net)
Globus Toolkit - GRAM Protocol Library
globus-gsi-callback @4.4_1 (net)
Globus Toolkit - Globus GSI Callback Library
globus-gsi-cert-utils @8.3_1 (net)
Globus Toolkit - Globus GSI Cert Utils Library
globus-gsi-credential @5.3_1 (net)
Globus Toolkit -
Re: livechecking ...
On Dec 12, 2013, at 21:17 , Ryan Schmidt ryandes...@macports.org wrote:
(3) For the globus ports it would be very useful to have the possibility
to check a set of URLs (actually 2) extract the pattern according to the
regex, concat the results and evaluate for the version in the in the usual
way. I am thinking of a specification of this kind (in analogy to
licences):
{{{
livecheck.type regex
livecheck.url {
http://www.globus.org/ftppub/gt5/5.2/5.2.5/packages/src/ \
http://www.globus.org/ftppub/gt5/5.2/5.2.5/updates/src/
}
livecheck.regex ${_name}-(\\d+(\\.\\d+)+)\\${extract.suffix}
Would something like this be TOO difficult to implement?
Where should I go and look to get some better idea?
This doesn't sound like a common use case... that being said, there
probably is no harm in implementing livecheck.url as a list. You'll want to
look in the trunk/base/src code for the livecheck code and the
trunk/dports/_resources for some other uses of livecheck.
I agree, that this is probably not the most common situation. But I
**really** would like to have livechecking for all the single components of
the Globus Toolkit in place. It would make tracking updates a lot easier
easiest and that is what livecheck is for, and I do not see another way to
implement livechecking here.
livecheck was implemented with the expectation that for any piece of
software, there will be a single stable url that will list the latest version
number. So far this has generally worked out ok. If this software you’re
talking about does not have such a page, you should ask its developers to
create one; it’s in every user’s best interest to be able to go to a
predictable url to find out if their software is outdated or not.
I provided more details in my last reply to Jeremy, so you might want to read
that as well.
I agree, the the choice to separate software it two separate directories is not
very fortunate (at least for us here). But it is not that you cannot find out
if there are recent updates. Maybe the developers would even argue, it is
easier to find out about updates if they keep them separately and their scheme
allows to easily find out which components (versions) a toolkit release is
composed of.
But I will try to contact the developers and see what they propose.
~petr
smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: livechecking ...
I'd probably ask why they need to be different from everyone else. RSS or an HTML table generated from their internal directory structure would suffice without forcing everyone to guess and check a bunch of directories. Peter Danecek wrote: I agree, the the choice to separate software it two separate directories is not very fortunate (at least for us here). But it is not that you cannot find out if there are recent updates. Maybe the developers would even argue, it is easier to find out about updates if they keep them separately and their scheme allows to easily find out which components (versions) a toolkit release is composed of. But I will try to contact the developers and see what they propose. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Any wxMSW users out there?
I think I tried installing it once but was never able to do so successfully: Local-Admins-MacBook-Pro:~ root# port installed wxmsw None of the specified ports are installed. I forget what the exact build failure was... Anyway I would like to keep it around and get it to work because there was some project that uses wxWidgets successfully on Windows that I was trying to port to OS X, so it might be helpful to use in the porting process... On Thu, Dec 12, 2013 at 9:23 AM, Mojca Miklavec mo...@macports.org wrote: Hi, a while back I did a clean-up of wxWidgets ports, including wxGTK, but I didn't touch wxMSW. The question is: does anyone really need wxMSW or may we delete it? The port is outdated (the version 2.8.4 is from May 2007, it hasn't even been upgraded to version 2.8.5 from September 2007) and fails already during configure (it is possible that the problem is at least somewhat related to MinGW, but I don't really know). And yet there is no single bug report requesting an upgrade or a fix to allow building the port. My assumption is that nobody has been using this port for a long time. I would suggest to delete it unless there are any objections or needs to keep it around. Mojca ___ 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
