Ryan,
the new design is rad! But I wonder if it is appropriate to use floppy disk
icons to symbolize packages. I’m pretty sure the youngest over here do not even
know what it is about ;)
(Granted, that’s just nitpicking…)
Thanks for the wonderful work.
Vincent
On Apr 7, 2014, at 18:30, mo...@macports.org wrote:
> Revision
> 118680
> Author
> mo...@macports.org
> Date
> 2014-04-07 16:30:45 -0700 (Mon, 07 Apr 2014)
> Log Message
>
> mojca/root: add a simple 'port select' functionality, move bin and man pages,
> create a symlink root5/root6 in bin
> Mo
On 2014-4-8 04:03 , Bradley Giesbrecht wrote:
> On Apr 7, 2014, at 9:12 AM, David Strubbe wrote:
>> Hi all,
>>
>> I found two strange things in using 'port installed depends:'. The 'gcr'
>> port appears to depend on itself, and gconf and gtk3 appear to depend on
>> each other. Does this make sen
On 2014-4-8 02:26 , Arno Hautala wrote:
> On Mon, Apr 7, 2014 at 12:03 PM, Peter Danecek
> wrote:
>>
>> 2. Is there a way to "fetch" available binary packages, without installing
>> the right away? There is the possibility do fetch all sources relevant for
>> some port. Sometimes I would like t
On 2014-4-8 02:25 , James Berry wrote:
> Ryan,
>
> Congrats. I think it’s starting to look really good. A couple of quick
> comments:
>
> - I think I would swap-in “that” for “which” in the following sentence:
>
> MacPorts is a package management system for OS X which lets you easily
>
On 2014-4-8 02:03 , Peter Danecek wrote:
>
> Hi all,
>
> I have some questions regarding binary installs.
>
> 1. I would like to know if there is some way to understand if a port was
> installed from sources or from binaries. I'd assume this might be a
> information which would have to go int
On Apr 7, 2014, at 16:42, Clemens Lang wrote:
>> All good in theory.
>>
>> In practice the port uses the cmake PortGroup which defines
>> "pre-configure" step and it seems that it overwrites the one from
>> active_variants, so adding
>>require_active_variants portB "" +python33
>> doesn't ha
On Apr 7, 2014, at 18:09, Christopher Jones wrote:
> p.s. whats the most recent MacPorts clang compiler you can install on OSX10.7
> ?
clang 3.4 and earlier should build fine on 10.7.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
ht
On Apr 7, 2014, at 17:14, David Strubbe wrote:
> Ok, I think I see what is going on here: apparently "port installed
> depends:XXX" returns all ports depending on port XXX -- OR a port that
> contains the string XXX.
It’s a regular expression search. So if you want the ports that depend on gcr
p.s. whats the most recent MacPorts clang compiler you can install on OSX10.7 ?
On 8 Apr 2014, at 12:03am, Christopher Jones wrote:
> Hi,
>
> For me, I’m afraid, I think this means ROOT6 can only be properly supported
> on 10.8 or newer. As its only these OS versions that have c++11 support. I
Hi,
For me, I’m afraid, I think this means ROOT6 can only be properly supported on
10.8 or newer. As its only these OS versions that have c++11 support. If
upstream have decided ROOT from version 6 onwards requires c++11 support, I am
not going to second guess them.
I previously had variants i
Ok, I think I see what is going on here: apparently "port installed
depends:XXX" returns all ports depending on port XXX -- OR a port that
contains the string XXX. This seems like a bug, and gives very misleading
information.
* "gcr" appears to depend on itself because it depends on "libgcrypt".
*
Hi,
I would like to ask for advice about how to properly support building
ROOT 6 (which builds clang/cling 3.5 as part of the installation) on
Lion.
I'm aware of http://trac.macports.org/wiki/FAQ#libcpp. But it's not
clear to me if dependency on clang 3.5 means that one will be unable
to to run R
Indeed, evidently "depends:" does some strange things which "depof:" does
not.
Though "man port" does not define "depends:", it is recommended here:
https://guide.macports.org/#using.common-tasks.finddepending
By contrast, "depof:" does not seem to appear in the guide.
David
On Mon, Apr 7, 2014
Hi,
> All good in theory.
>
> In practice the port uses the cmake PortGroup which defines
> "pre-configure" step and it seems that it overwrites the one from
> active_variants, so adding
> require_active_variants portB "" +python33
> doesn't have any effect at all.
pre-configure blocks don't
Looks great. I suggest that in the info on the right-hand side for a given
port, you mention also the possibility of running "port test" when
available.
David
On Mon, Apr 7, 2014 at 4:13 PM, wrote:
> Hi Ryan,
>
> I do like your work very much! This looks really cool!!!
>
> A few remarks:
>
>
On Mon, Apr 7, 2014 at 3:52 PM, Mojca Miklavec wrote:
> On Mon, Apr 7, 2014 at 3:44 PM, Jeremy Lavergne wrote:
>> The active_variants PortGroup can be used this way:
>> active_variants $depspec $required $forbidden
>>
>> That forbidden section is likely what you’re after, inside a variant block.
A
Hi Ryan,
I do like your work very much! This looks really cool!!!
A few remarks:
1) Perhaps the icons at least could be blue to match the mandatory
good-old MacPorts icon, which definitely needs to appear here instead of the
new “macports”. :)
2) I think that the headline is p
Hi,
as I have currently no access to an Intel Mac and therefore stuck with
10.5, I'd like to give up maintainership of the ports below:
py-lightblue (open tickets: 36371, 38666)
linuxdoc-tools (42988)
AppKiDo (36865)
Thanks and regards
Michael
___
m
I was under the impression that the "depends:" pseudo-portname and the
"depof:" portname were two separate things...
On Mon, Apr 7, 2014 at 2:19 PM, David Strubbe wrote:
> Hm, I guess I got "depends:" from suggestions in messages on this list.
> Using "port installed depof:gcr" gcr is not list
On Mon, Apr 7, 2014 at 5:01 PM, Ryan Schmidt wrote:
> Dear fellow MacPorts developers and enthusiasts,
>
> I’ve been working on a new MacPorts web site for some time, and I would like
> to share with you my work so far:
Amazing!
> Further work to be done, in no particular order and not necessari
Hm, I guess I got "depends:" from suggestions in messages on this list.
Using "port installed depof:gcr" gcr is not listed, so that is more
reasonable. "depof:gtk3" does not list gconf, and "depof:gconf" does list
gtk3. So it seems that "depends:" is buggy. Maybe it should be removed if
it has been
On Apr 7, 2014, at 9:12 AM, David Strubbe wrote:
> Hi all,
>
> I found two strange things in using 'port installed depends:'. The 'gcr' port
> appears to depend on itself, and gconf and gtk3 appear to depend on each
> other. Does this make sense? Is it a bug in base or the Portfiles?
I don't k
On Apr 7, 2014, at 10:11 AM, Craig Treleaven wrote:
>
>> * Make the homepage simple and inviting
>
> Very nice!
> ...
> Personally, I think the recent port updates section should be more prominent.
> Shows that the project is active and gives a flavour for the software that
> MacPorts actuall
On Apr 7, 2014, at 8:01 AM, Ryan Schmidt wrote:
> About the look and feel:
>
> The new site’s styling is done using a CSS framework made by Twitter called
> Bootstrap.
This is refreshing, looks GREAT!
I like the direction and +1 for "Responsive Design".
Regards,
Bradley Giesbrecht (pixilla)
At 10:01 AM -0500 4/7/14, Ryan Schmidt wrote:
Dear fellow MacPorts developers and enthusiasts,
I've been working on a new MacPorts web site for some time, and I
would like to share with you my work so far:
url: http://macports.ryandesign.com:8080
username: mp
password: 333
It is not yet comp
On Mon, Apr 7, 2014 at 12:58 PM, Peter Danecek wrote:
>
> Thanks for this hint. This is not yet documented in the man page, right? Or I
> just missed it?
> ~petr
Yeah, I don't think it's documented anywhere. Maybe the man page? I
found out about it myself by asking on one of the mail lists a few
On Apr 7, 2014, at 7:20 AM, Mojca Miklavec wrote:
> Hi,
>
> I see that mysql55 for example installs man pages to
>$prefix/share/man/mysql55/man1/*.1.gz
> where they are not really functional.
>
> Is that a proper place for these files? / Is there any better place?
In the case of mysql55 an
On Mon, Apr 7, 2014 at 12:03 PM, Peter Danecek wrote:
>
> 2. Is there a way to "fetch" available binary packages, without installing
> the right away? There is the possibility do fetch all sources relevant for
> some port. Sometimes I would like to do something very similar with binary
> packag
Ryan,
Congrats. I think it’s starting to look really good. A couple of quick comments:
- I think I would swap-in “that” for “which” in the following sentence:
MacPorts is a package management system for OS X which lets you easily
install…
(see
http://www.quickanddirtytips.com/
Hi all,
I found two strange things in using 'port installed depends:'. The 'gcr'
port appears to depend on itself, and gconf and gtk3 appear to depend on
each other. Does this make sense? Is it a bug in base or the Portfiles?
David
$ port installed depends:gcr
The following ports are currently i
Hi all,
I have some questions regarding binary installs.
1. I would like to know if there is some way to understand if a port was
installed from sources or from binaries. I'd assume this might be a information
which would have to go into the DB on activation, but is not recorded (yet) ???
2.
I like it a lot, too. The design is very clean and the organization of the
different information is very clear. Perhaps a few CSS tweaks could make it a
little less vanilla Bootstrap and give the site a bit more of its own identity.
Even without that it’s a huge improvement over the existing sit
I like the new design!
Especially, the new and quite clear installation page is what really should be
helpful to get people start easily. I must admit that even I never know which
Xcode is the one to install on each OS version.
Only thing to consider when it comes to appearance: I would stic
On Mon, Apr 7, 2014 at 11:01 AM, Ryan Schmidt wrote:
>
> Dear fellow MacPorts developers and enthusiasts,
>
> I’ve been working on a new MacPorts web site for some time, and I would like
> to share with you my work so far:
I really like the direction you've got so far. I've only been able to
loo
On Apr 7, 2014, at 11:01 AM, Ryan Schmidt wrote:
>
> It is not yet complete but I hope it gives an idea of the direction I’m
> going, and I very much hope that you like it.
This looks good!
> Gentle feedback about what works and what doesn’t (both functionally and
> conceptually) and what els
On Mon, Apr 7, 2014 at 10:44 AM, Brandon Allbery wrote:
> On Mon, Apr 7, 2014 at 10:40 AM, Mojca Miklavec wrote:
>
>> It probably wouldn't be such a bad idea to create a script
>> $prefix/bin/-init.sh which would prepend
>> $prefix/libexec// to PATH. Or maybe simply create a
>> script like $prefix
Dear fellow MacPorts developers and enthusiasts,
I’ve been working on a new MacPorts web site for some time, and I would like to
share with you my work so far:
url: http://macports.ryandesign.com:8080
username: mp
password: 333
It is not yet complete but I hope it gives an idea of the direction
On Mon, Apr 7, 2014 at 10:40 AM, Mojca Miklavec wrote:
> On Mon, Apr 7, 2014 at 4:22 PM, Brandon Allbery wrote:
> > On Mon, Apr 7, 2014 at 10:20 AM, Mojca Miklavec wrote:
> >> I see that mysql55 for example installs man pages to
> >> $prefix/share/man/mysql55/man1/*.1.gz
> >> where they are n
On Mon, Apr 7, 2014 at 4:22 PM, Brandon Allbery wrote:
> On Mon, Apr 7, 2014 at 10:20 AM, Mojca Miklavec wrote:
>>
>> I see that mysql55 for example installs man pages to
>> $prefix/share/man/mysql55/man1/*.1.gz
>> where they are not really functional.
>>
>> Is that a proper place for these fil
Hi,
I see that mysql55 for example installs man pages to
$prefix/share/man/mysql55/man1/*.1.gz
where they are not really functional.
Is that a proper place for these files? / Is there any better place?
We are discussing where to best store man pages when multiple versions
of the same program
On Mon, Apr 7, 2014 at 10:20 AM, Mojca Miklavec wrote:
> I see that mysql55 for example installs man pages to
> $prefix/share/man/mysql55/man1/*.1.gz
> where they are not really functional.
>
> Is that a proper place for these files? / Is there any better place?
>
If you arrange for them to
On 2 Apr 2014, at 15:41, David Röthlisberger wrote:
> FYI the git mirror at git.macports.org isn't syncing with the svn
> repository since 11 March. There's a 9-day-old ticket with no activity
> at https://trac.macports.org/ticket/43058
This seems to be fixed now (the git mirror is synced up to t
On Mon, Apr 7, 2014 at 3:44 PM, Jeremy Lavergne wrote:
> The active_variants PortGroup can be used this way:
> active_variants $depspec $required $forbidden
>
> That forbidden section is likely what you’re after, inside a variant block.
Oh, sure, thank you for reminding me (of something that I sho
The active_variants PortGroup can be used this way:
active_variants $depspec $required $forbidden
That forbidden section is likely what you’re after, inside a variant block.
On Apr 7, 2014, at 9:24, Mojca Miklavec wrote:
> What is the most reasonable way to declare a conflict between "portA
> +
Hi,
What is the most reasonable way to declare a conflict between "portA
+pythonXY" and "portB +pythonXY"? The ports themeselves don't conflict
and different python variants don't conflict either (portA +python33
and portB +python34 works OK).
The problem is that both ports install files with the
Sounds kind of like the "sensible alternatives" approach that many
dpkg-based package managers take:
https://packages.debian.org/unstable/sensible-utils
On Mon, Apr 7, 2014 at 8:02 AM, Mojca Miklavec wrote:
> Hi,
>
> for Python ports it makes sense not to install "python" to $prefix/bin
> beca
Hi,
for Python ports it makes sense not to install "python" to $prefix/bin
because that would shadow the python which comes with the system.
What about if we currently ship a certain port that installs the
binary to $prefix/bin and would like to allow parallel installation of
a newer (experimenta
48 matches
Mail list logo
