Re: pet project : LnxPorts

[Dave Horsfall]

On Thu, 8 Oct 2015, Alejandro Imass wrote:

> Perhaps it's a good time to evaluate a switch to PCBSD and ditch the 
> Linux ;-)

Anything that ditches Linux is fine by me :-)  I'm a bit of a BSD snob, 
after all...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: GIMP latest version

[Dominik Reichardt]

Hi,


14 is a higher number than 2, so 2.8.14 is newer than 2.8.2 - You will 
encounter this kind of numbering a lot with software. 

Take care

Dom

> On 08.10.2015, at 22:38, Eneko Gotzon  wrote:
> 
> Hi Byte Masters.
> 
> The download page of the GIMP states that there is a 2.8.2 version for OS X 
> , but both MacPorts and the available disk 
> images only offer the 2.8.14 one. Please, why?
> 
> (Sorry about this kind of questions and) thank you.
> 
> -- 
> Eneko Gotzon Ares
> enekogot...@gmail.com 
> 

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

Re: GIMP latest version

[Marius Schamschula]

Eneko,

The .dmg package for Gimp 2.8.2 is rather out of date. The MacPorts version 
2.8.14 corresponds to currently available source code.

Also note: you will want to install Gimp-app as well (this adds the OS X icon, 
etc.)

On Oct 8, 2015, at 3:38 PM, Eneko Gotzon  wrote:

> Hi Byte Masters.
> 
> The download page of the GIMP states that there is a 2.8.2 version for OS X, 
> but both MacPorts and the available disk images only offer the 2.8.14 one. 
> Please, why?
> 
> (Sorry about this kind of questions and) thank you.
> 
> -- 
> Eneko Gotzon Ares
> enekogot...@gmail.com
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users

Marius
--
Marius Schamschula




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

GIMP latest version

[Eneko Gotzon]

Hi Byte Masters.

The download page of the GIMP states that there is a 2.8.2 version for OS X
, but both MacPorts and the available disk
images only offer the 2.8.14 one. Please, why?

(Sorry about this kind of questions and) thank you.

-- 
Eneko Gotzon Ares
enekogot...@gmail.com
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: port not installed according to registry, yet depends_lib didn't "react"?

[Ryan Schmidt]

On Oct 8, 2015, at 1:09 PM, René J.V. Bertin wrote:

> On Thursday October 08 2015 12:04:18 Ryan Schmidt wrote:
> 
>> I know I've encountered situations where a port failed to build because one 
>> of its dependencies was inactive. I'm sure I had forcibly deactivated it at 
>> some prior time for some forgotten reason. I don't know why MacPorts 
>> wouldn't have reactivated it, but it didn't.
> 
> Maybe that has (had) to do with the fact that you can install the newer 
> version of a port, reactivate an older version, and not get bugged by port 
> outdated about it?

I can't say.


>> Maybe that kind of thing is what happened to you. The solution is to 
>> reactivate the port.
> 
> Doubtful: `port installed libical` claimed the port wasn't installed. That 
> shouldn't happen after deactivating a port.

Ok, then I don't know what happened in your situation.


>>> Ouch, that's what you get from depending on "internal" software and not on 
>>> something stable provided by the host :)
>>> I sure hope they're working to fix what they broke!
>> 
>> I have no idea what you're referring to here.
> 
> Which part? The fact that portindex apparently uses a python module shipped 
> through MacPorts, and that can be broken by someone who upgrades the module a 
> bit overzealously?

That does not occur.


>>> Fixing a broken portindex through a port update will be tricky, if the 
>>> breakage is serious enough, btw.
>> 
>> I again have no idea what you're talking about.
> 
> How are you going to get `port outdated` to consider the fact a port has been 
> updated if portindex is too broken to generate a valid port index?

The portindex command is not broken. It just failed to produce a complete 
index, because one of the ports being indexed was invalid.


> Anyway, I understand now that it probably wasn't the portindex command that 
> was broken (on every uptodate MacPorts install), but the port index wasn't 
> rebuilt properly because of a syntax error in a Portfile.

That's correct.


> I was under the impression that syntax errors were caught and excluded only 
> the affected ports from the index? I'm pretty sure that's how it use(d) to 
> work under 2.3.3 and before, in any case.

That's how it seems to me too, on users systems. But that's not apparently the 
way that it is done on the web server.


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

Re: port not installed according to registry, yet depends_lib didn't "react"?

[René J . V . Bertin]

On Thursday October 08 2015 12:04:18 Ryan Schmidt wrote:

> I know I've encountered situations where a port failed to build because one 
> of its dependencies was inactive. I'm sure I had forcibly deactivated it at 
> some prior time for some forgotten reason. I don't know why MacPorts wouldn't 
> have reactivated it, but it didn't.

Maybe that has (had) to do with the fact that you can install the newer version 
of a port, reactivate an older version, and not get bugged by port outdated 
about it?

> Maybe that kind of thing is what happened to you. The solution is to 
> reactivate the port.

Doubtful: `port installed libical` claimed the port wasn't installed. That 
shouldn't happen after deactivating a port.

> > Ouch, that's what you get from depending on "internal" software and not on 
> > something stable provided by the host :)
> > I sure hope they're working to fix what they broke!
> 
> I have no idea what you're referring to here.

Which part? The fact that portindex apparently uses a python module shipped 
through MacPorts, and that can be broken by someone who upgrades the module a 
bit overzealously?

> > Fixing a broken portindex through a port update will be tricky, if the 
> > breakage is serious enough, btw.
> 
> I again have no idea what you're talking about.

How are you going to get `port outdated` to consider the fact a port has been 
updated if portindex is too broken to generate a valid port index?

Anyway, I understand now that it probably wasn't the portindex command that was 
broken (on every uptodate MacPorts install), but the port index wasn't rebuilt 
properly because of a syntax error in a Portfile.

I was under the impression that syntax errors were caught and excluded only the 
affected ports from the index? I'm pretty sure that's how it use(d) to work 
under 2.3.3 and before, in any case.

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

Re: port not installed according to registry, yet depends_lib didn't "react"?

[Ryan Schmidt]

> On Oct 8, 2015, at 11:36 AM, René J.V. Bertin  wrote:
> 
> On Thursday October 08 2015 12:03:32 Brandon Allbery wrote:
>> On Thu, Oct 8, 2015 at 11:55 AM, René J.V.  wrote:
>> 
>>> I *really* that my update to 2.3.4 yesterday (from source) didn't cause
>>> ports to be dropped from the registry!
> 
> I meant the registry of installed ports, the much more complex one to restore.

I know I've encountered situations where a port failed to build because one of 
its dependencies was inactive. I'm sure I had forcibly deactivated it at some 
prior time for some forgotten reason. I don't know why MacPorts wouldn't have 
reactivated it, but it didn't. Maybe that kind of thing is what happened to 
you. The solution is to reactivate the port.



>> An update to a python module port broke portindex. I believe they're
>> working on getting it fixed.
> 
> Ouch, that's what you get from depending on "internal" software and not on 
> something stable provided by the host :)
> I sure hope they're working to fix what they broke!

I have no idea what you're referring to here.


> Portindex is for indexing the available ports in a ports tree;

yes


> is it also used to maintain the (sqlite) reqistry of what ports are actually 
> installed?

it doesn't seem likely


> Fixing a broken portindex through a port update will be tricky, if the 
> breakage is serious enough, btw.

I again have no idea what you're talking about.


> What module and update were that? I have only updated base, but not done the 
> usual selfupdate/upgrade outdated (since a long time, actually), so I should 
> have noticed this before if it's not a recent update.

https://trac.macports.org/ticket/49180

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

Re: port not installed according to registry, yet depends_lib didn't "react"?

[Brandon Allbery]

On Thu, Oct 8, 2015 at 12:36 PM, René J.V.  wrote:

> Ouch, that's what you get from depending on "internal" software and not on
> something stable provided by the host :)
> I sure hope they're working to fix what they broke!
>

The problem with Tcl is you can't just read a Portfile, you have to *run*
it. Certain classes of bugs can derail the train. :(

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: port not installed according to registry, yet depends_lib didn't "react"?

[René J . V . Bertin]

On Thursday October 08 2015 12:03:32 Brandon Allbery wrote:
> On Thu, Oct 8, 2015 at 11:55 AM, René J.V.  wrote:
> 
> > I *really* that my update to 2.3.4 yesterday (from source) didn't cause
> > ports to be dropped from the registry!

I meant the registry of installed ports, the much more complex one to restore.

> An update to a python module port broke portindex. I believe they're
> working on getting it fixed.

Ouch, that's what you get from depending on "internal" software and not on 
something stable provided by the host :)
I sure hope they're working to fix what they broke!

Portindex is for indexing the available ports in a ports tree; is it also used 
to maintain the (sqlite) reqistry of what ports are actually installed? Fixing 
a broken portindex through a port update will be tricky, if the breakage is 
serious enough, btw.

What module and update were that? I have only updated base, but not done the 
usual selfupdate/upgrade outdated (since a long time, actually), so I should 
have noticed this before if it's not a recent update.

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

Re: port not installed according to registry, yet depends_lib didn't "react"?

[Ryan Schmidt]

On Oct 8, 2015, at 11:03 AM, Brandon Allbery wrote:

> On Thu, Oct 8, 2015 at 11:55 AM, René J.V. wrote:
>> I *really* that my update to 2.3.4 yesterday (from source) didn't cause 
>> ports to be dropped from the registry!
> 
> An update to a python module port broke portindex. I believe they're working 
> on getting it fixed.

That was fixed. Not sure if it relates to what René reported.

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

Re: pet project : LnxPorts

[René J . V . Bertin]

On Thursday October 08 2015 17:44:37 Clemens Lang wrote:

> See, that's where you're wrong. MacPorts actively tries to NOT be a build 
> system,
> but a package manager. That's why we focus on getting things done the right 
> way
> and ensuring the tuple (os, port, variants) always behaves the same and builds
> the same way.

We may not agree on the term, but it *is* a system that also allows to build 
(and install) a variety of packages/source projects with a unified syntax. 

> Regarding your Linux endeavours… maybe Linuxbrew would fulfill your needs? I

Never heard of it before, but if it's like HomeBrew on OS X it'll probably 
fulfil my needs just like that whatever-you-call-it :)
Or if it's like Gentoo Prefix and pkgsrc, it just won't work on Debian and 
Ubuntu.

> don't see the manpower needed to support MacPorts on Linux appear anytime
> soon.

I think I've been clear enough that I'm not asking for that, on the contrary.

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

Re: pet project : LnxPorts

[Jeff Singleton]

Cal

You are misinterpreting what Rene is saying. He is not trying to garner
support for a Linux based Ports system, he is just sharing - after all he
did state 'pet project' in the title and also states very clearly that  "...
 this is not an announcement that I'll be forking off MacPorts to begin a
fully supported Linux variant! :)"

I personally disagree with blindly installing a pre-built package from any
type of package managing system. Simply because in my experience I do not
trust a package I do not build myself.

Several things bring me to this opinion...different hardware types, whether
specific variants are used, and yes, even the skill level of the person
building the package...because simply knowing how to run
configure/make/make install may not be enough to properly build a package
that can be distributed.

I prefer compiling myself...most newer systems can do this a lot quicker
now, and with proper patching done I have run into very little
issues...with most issues being trivial to fix myself.

Just my $0.02


On Thu, Oct 8, 2015 at 10:44 AM, Clemens Lang  wrote:

>
>
> - On 8 Oct, 2015, at 16:57, René J.V. Bertin rjvber...@gmail.com
> wrote:
>
> > For me, MacPorts is just an additional distribution system (and more of
> a build
> > system) for certain things that I would otherwise build "by hand".
>
> See, that's where you're wrong. MacPorts actively tries to NOT be a build
> system,
> but a package manager. That's why we focus on getting things done the
> right way
> and ensuring the tuple (os, port, variants) always behaves the same and
> builds
> the same way. Please note that this tuple does not include "already
> installed
> dependencies" or "stuff that's already in /usr/lib or /usr/local".
>
>
> > That's also why I've made some changes to relax the principle of
> building as
> > much as possible against libraries provided by MacPorts (into the
> opposite
> > principle, in fact).
>
> That's not the idea that most MacPorts developers currently have. It may
> suit
> your expectations, but you're on your own.
>
>
> Regarding your Linux endeavours… maybe Linuxbrew would fulfill your needs?
> I
> don't see the manpower needed to support MacPorts on Linux appear anytime
> soon.
>
> --
> Clemens Lang
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
>
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: pet project : LnxPorts

[Jeff Singleton]

Gentoo currently has 1240 orphaned packages and there only exists a very
small group of active proxy maintainers.

So I would not use Gentoo as any alternative...which pains me to say
because I used to love Gentoo.

On Thu, Oct 8, 2015 at 8:22 AM, Alejandro Imass  wrote:

>
>
> On Wed, Oct 7, 2015 at 1:59 PM, René J.V.  wrote:
>
>> Morning!
>>
>> OK now, don't get me wrong, this is not an announcement that I'll be
>> forking off MacPorts to begin a fully supported Linux variant! :)
>>
>
> Also, why no use Gentoo or other existing ports-based Linux variants ?
>
> To me anything that uses "ports" is kind-of BSD by definition (or BSD
> wannabe) so why not use the real thing to begin with! Being able to install
> from binary and/or from fine-tuned source compile is priceless in my book.
> Which of course can be done with most Linux variants (and pretty elegantly
> if done correctly) it is never as elegant as a true ports system.
>
> Anyway, just my 0.02 here. I am no expert in software distribution systems
> by any means, but IMHO OS X and BSD seem a much better coupling than OS X
> and Linux. Also, PCSBD is pretty cool:
> http://blog.pcbsd.org/2015/05/pc-bsd-10-1-2-an-interview-with-kris-moore/
>
> Best,
> Alejandro Imass
>
>
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
>
>
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: port not installed according to registry, yet depends_lib didn't "react"?

[Brandon Allbery]

On Thu, Oct 8, 2015 at 11:55 AM, René J.V.  wrote:

> I *really* that my update to 2.3.4 yesterday (from source) didn't cause
> ports to be dropped from the registry!


An update to a python module port broke portindex. I believe they're
working on getting it fixed.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

port not installed according to registry, yet depends_lib didn't "react"?

[René J . V . Bertin]

Hey,

Something weird just happened. I had triggered an incremental rebuild (build 
and destroot) of a KDE4 port that depends on port:libical via depends_lib. The 
build system uses cmake, which detected that a re-configure was in order:

- cmake failed to detect libibcal
- upon verification, `port installed libical` confirmed this
- `port build` had *not* attempted to install the missing dependency (or if it 
did I missed it and it also had not updated the registry). It completed 
successfully from what I could see; I didn't use -p. (For the code, libical is 
an optional dependency.)
- I did have an image in var/macports/software/libical
- installing (a new version of) libical showed that (most) all files were still 
present under ${prefix}

I *really* that my update to 2.3.4 yesterday (from source) didn't cause ports 
to be dropped from the registry!

Apart from that, what could explain that no attempt to install the missing port 
was made OR that I didn't get an error?
Sadly the build log had already been overwritten when I realised I might have 
run into a bug.

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

Re: pet project : LnxPorts

[Clemens Lang]

- On 8 Oct, 2015, at 16:57, René J.V. Bertin rjvber...@gmail.com wrote:

> For me, MacPorts is just an additional distribution system (and more of a 
> build
> system) for certain things that I would otherwise build "by hand".

See, that's where you're wrong. MacPorts actively tries to NOT be a build 
system,
but a package manager. That's why we focus on getting things done the right way
and ensuring the tuple (os, port, variants) always behaves the same and builds
the same way. Please note that this tuple does not include "already installed
dependencies" or "stuff that's already in /usr/lib or /usr/local".


> That's also why I've made some changes to relax the principle of building as
> much as possible against libraries provided by MacPorts (into the opposite
> principle, in fact).

That's not the idea that most MacPorts developers currently have. It may suit
your expectations, but you're on your own.


Regarding your Linux endeavours… maybe Linuxbrew would fulfill your needs? I
don't see the manpower needed to support MacPorts on Linux appear anytime
soon.

-- 
Clemens Lang
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: pet project : LnxPorts

[René J . V . Bertin]

On Thursday October 08 2015 09:22:19 Alejandro Imass wrote:

> Also, why no use Gentoo or other existing ports-based Linux variants ?

I don't need to have a front-row seat for everything. In fact, I much prefer a 
stable OS with LTS, one that I can work done on/with, rather than one on which 
I have to spend my time keeping it up to date. Coolness is really the last and 
least of my concerns, as opposed to "doesn't get in the way" and "you forget 
it's there".

Building Qt5 on the netbook in question takes between 12 and 24 hours 
(depending on how often I have to interrupt the process in order to be able to 
do other things, or how often it hangs because its 8Gb RAM isn't enough). You 
can imagine what the overhead of running something like Gentoo would mean.

For me, MacPorts is just an additional distribution system (and more of a build 
system) for certain things that I would otherwise build "by hand". That's also 
why I've made some changes to relax the principle of building as much as 
possible against libraries provided by MacPorts (into the opposite principle, 
in fact).

R.

> and Linux. Also, PCSBD is pretty cool:
> http://blog.pcbsd.org/2015/05/pc-bsd-10-1-2-an-interview-with-kris-moore/


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

Re: Rebuild old version of port?

[Ryan Schmidt]

On Oct 8, 2015, at 8:34 AM, Adam Dershowitz wrote:

> On Oct 8, 2015, at 8:57 AM, Ryan Schmidt wrote:
> 
>> On Oct 7, 2015, at 9:53 AM, Adam Dershowitz wrote:
>> 
>>> Is there a way that I can rebuild and reactivate an older version of a  
>>> port?  I know about this link:  
>>> https://trac.macports.org/wiki/howto/InstallingOlderPort  but the problem I 
>>> have is a little bit different.
>>> I have the old versions still on my computer, including the source (these 
>>> were ports that build from source), and they are for a port that is not 
>>> hosted on macports.  
>>> The problem is that one of the dependents changed, so if I just activate 
>>> the old version it fails.  So, what I want is essentially to “activate from 
>>> source” or “rebuild @version)” since I already have the source and the port 
>>> for the old version.  
>>> I can just activate the old version because there is the issue of a bad 
>>> link, so it needs to be rebuilt.  
>>> I tried: 
>>> sudo port install myport @myoldversion but it tried to rebuild the new 
>>> version, which is not what I want.  
>>> I also tried just giving the source flag:
>>> sudo port activate -s myport @myoldversion but then it just activated the 
>>> old version.  
>>> 
>>> I actually had no intention of yet upgrading this port, but when I upgraded 
>>> one of the dependents , macports found that the port was now broken, and 
>>> proceeded to download the new version of the port before rebuilding.  But, 
>>> that new version is actually broken (for a completely unrelated reason).  
>>> So, now I can’t use the new version of the port, and I want to go back to 
>>> the old version, but I can just activate it, because of the dependent 
>>> issue.  So, I want to just have macports rebuild the old version from 
>>> source.  
>> 
>> I don't know what to tell you. I don't completely understand your issue. 
>> InstallingOlderPort explains how to install an older version of a port. 
>> "sudo port install" does not support an "@version" modifier.
>> 
>> Maybe it would help if you told us what version of what port you're trying 
>> to build, and, since you said it's not hosted on MacPorts, where it's 
>> hosted, or where you got it.
>> 
> 
> Sure.  Sorry that my description was not detailed enough.
> I have openmodelica-devel installed, and it was working fine.  And, I have 
> often done upgrades with no problem.  
> Some install details are here:  https://openmodelica.org/download/download-mac
> And, they keep the source code here:  
> http://build.openmodelica.org/apt/pool/contrib/
> 
> Yesterday I upgraded qt4-mac.  That caused macports to determine that a few 
> ports were broken (since qt4-mac seems to have changed the location of some 
> files) and to cause them to rebuild.  One that it tried to rebuild was 
> openmodelica-devel.  The problem is that I was not using the most recent 
> version.  They upgrade every few hours typically, as this is develop code.  
> Some recent change that they made has caused the recent versions not to build 
> correctly.  The developers are aware of that, and it will get fixed 
> eventually.  
> So, I just wanted to keep using the version I had from a few days ago.  The 
> problem is that macports saw the broken install of openmodelica-devel was not 
> the newest so downloaded the new source and tried to build it, and failed due 
> to the bug mentioned earlier.  Now the problem is that if I activate the 
> older version (a few days old) it activates, but doesn’t run (because it 
> linked against the old location of qt4-mac libraries).  
> So, my current situation is I have old versions installed but not activated.  
> And, I can’t get old ones to work, and I can’t build a new version, since 
> there is a bug that is yet to be fixed in openmodelica.  
> So, would like to do is to rebuild an old version from the source that was 
> downloaded when I last did a successful upgrade and build.  Since that build 
> worked, and left the source stored in macports, it seems like there should be 
> a way to reactivate that version, but let it use the source and rebuild it, 
> instead of just doing the typical activate from the binaries that macports 
> build and saved.
> 
> Does that make more sense?  

Ok, so you have 2 options.

1. Downgrade qt4-mac to the version before the change in filesystem layout, and 
then you can activate your already-installed older version of 
openmodelica-devel and it will work. of course, you'll break all the ports that 
require the new qt4-mac layout, and if you want to continue using them, would 
have to downgrade them to pre-layout-change versions as well.

2. (probably the better option) Follow the InstallingOlderPort instructions, 
except where it tells you to look in the MacPorts Subversion repository's log 
to find which revision of the port to use, you'll instead be consulting the log 
of whatever revision control system the Open Modelica developers use for their 
ports, and you'll get the old version o

Re: Rebuild old version of port?

[Adam Dershowitz]

> On Oct 8, 2015, at 8:57 AM, Ryan Schmidt  wrote:
> 
> 
> On Oct 7, 2015, at 9:53 AM, Adam Dershowitz wrote:
> 
>> Is there a way that I can rebuild and reactivate an older version of a  
>> port?  I know about this link:  
>> https://trac.macports.org/wiki/howto/InstallingOlderPort  but the problem I 
>> have is a little bit different.
>> I have the old versions still on my computer, including the source (these 
>> were ports that build from source), and they are for a port that is not 
>> hosted on macports.  
>> The problem is that one of the dependents changed, so if I just activate the 
>> old version it fails.  So, what I want is essentially to “activate from 
>> source” or “rebuild @version)” since I already have the source and the port 
>> for the old version.  
>> I can just activate the old version because there is the issue of a bad 
>> link, so it needs to be rebuilt.  
>> I tried: 
>> sudo port install myport @myoldversion but it tried to rebuild the new 
>> version, which is not what I want.  
>> I also tried just giving the source flag:
>> sudo port activate -s myport @myoldversion but then it just activated the 
>> old version.  
>> 
>> I actually had no intention of yet upgrading this port, but when I upgraded 
>> one of the dependents , macports found that the port was now broken, and 
>> proceeded to download the new version of the port before rebuilding.  But, 
>> that new version is actually broken (for a completely unrelated reason).  
>> So, now I can’t use the new version of the port, and I want to go back to 
>> the old version, but I can just activate it, because of the dependent issue. 
>>  So, I want to just have macports rebuild the old version from source.  
> 
> I don't know what to tell you. I don't completely understand your issue. 
> InstallingOlderPort explains how to install an older version of a port. "sudo 
> port install" does not support an "@version" modifier.
> 
> Maybe it would help if you told us what version of what port you're trying to 
> build, and, since you said it's not hosted on MacPorts, where it's hosted, or 
> where you got it.
> 

Sure.  Sorry that my description was not detailed enough.
I have openmodelica-devel installed, and it was working fine.  And, I have 
often done upgrades with no problem.  
Some install details are here:  https://openmodelica.org/download/download-mac 

And, they keep the source code here:  
http://build.openmodelica.org/apt/pool/contrib/ 


Yesterday I upgraded qt4-mac.  That caused macports to determine that a few 
ports were broken (since qt4-mac seems to have changed the location of some 
files) and to cause them to rebuild.  One that it tried to rebuild was 
openmodelica-devel.  The problem is that I was not using the most recent 
version.  They upgrade every few hours typically, as this is develop code.  
Some recent change that they made has caused the recent versions not to build 
correctly.  The developers are aware of that, and it will get fixed eventually. 
 
So, I just wanted to keep using the version I had from a few days ago.  The 
problem is that macports saw the broken install of openmodelica-devel was not 
the newest so downloaded the new source and tried to build it, and failed due 
to the bug mentioned earlier.  Now the problem is that if I activate the older 
version (a few days old) it activates, but doesn’t run (because it linked 
against the old location of qt4-mac libraries).  
So, my current situation is I have old versions installed but not activated.  
And, I can’t get old ones to work, and I can’t build a new version, since there 
is a bug that is yet to be fixed in openmodelica.  
So, would like to do is to rebuild an old version from the source that was 
downloaded when I last did a successful upgrade and build.  Since that build 
worked, and left the source stored in macports, it seems like there should be a 
way to reactivate that version, but let it use the source and rebuild it, 
instead of just doing the typical activate from the binaries that macports 
build and saved.

Does that make more sense?  

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

Re: pet project : LnxPorts

[Eneko Gotzon]

On Wed, Oct 7, 2015 at 8:36 PM, Sven Kolja Heinemann 
wrote:

> MacPorts exists to make OS X a complete BSD distribution
>

That seems to be a wonderful aim… Thank you!

-- 
Eneko Gotzon Ares
enekogot...@gmail.com
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: pet project : LnxPorts

[Alejandro Imass]

On Wed, Oct 7, 2015 at 1:59 PM, René J.V.  wrote:

> Morning!
>
> OK now, don't get me wrong, this is not an announcement that I'll be
> forking off MacPorts to begin a fully supported Linux variant! :)
>

Also, why no use Gentoo or other existing ports-based Linux variants ?

To me anything that uses "ports" is kind-of BSD by definition (or BSD
wannabe) so why not use the real thing to begin with! Being able to install
from binary and/or from fine-tuned source compile is priceless in my book.
Which of course can be done with most Linux variants (and pretty elegantly
if done correctly) it is never as elegant as a true ports system.

Anyway, just my 0.02 here. I am no expert in software distribution systems
by any means, but IMHO OS X and BSD seem a much better coupling than OS X
and Linux. Also, PCSBD is pretty cool:
http://blog.pcbsd.org/2015/05/pc-bsd-10-1-2-an-interview-with-kris-moore/

Best,
Alejandro Imass
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: pet project : LnxPorts

[Alejandro Imass]

On Thu, Oct 8, 2015 at 7:33 AM, René J.V.  wrote:

> On Thursday October 08 2015 07:16:51 Alejandro Imass wrote:
>
> > Perhaps it's a good time to evaluate a switch to PCBSD and ditch the
> Linux
> > ;-)
>
> Why?
>
> I've already checked the temp of those waters. I know MacPorts comes from
> BSD originally, but I cannot say I felt right at home at once on PC-BSD in
> that aspect. Maybe MacPorts has been on a divergent evolutionary path from
> its BSD ancestor ...
>
> There's also the question of hardware support, and software that exists
> for Linux but not BSD. I like the fact PC-BSD uses ZFS (so does my Linux
> box :)) but I'm not convinced about its choice as an OS for a generic
> desktop/workstation instead for server purposes.
>
> R.
>

Hardware support I don't believe is an issue, IMHO anyway, unless you have
very exotic hw.  You can run PCBSD on UFS too, but I think BSD will be more
compatible in general with your Mac, because OS X also derived mainly from
FBSD.

It just makes sense to me that if you use Mac and MacPorts any BSD variant
should be more attractive than a Linux one. Ubuntu and all it's derivatives
have become extremely bloated, but I guess it all dependes on your use
case. E.g. for a household user perhaps Linux is a better choice but if you
are developer or more technical user perhaps PCBSD is a better alternative.

I particularly dislike the way Debian derivatives _heavily_ modify original
software and I don't like their Perl Policy. I prefer the BSD-way where
original software is kept very closely to the original source. At the
beginning I thought dpkg was cool, but over time I prefer the ports way,
where software is only minimally modified and ported. Moreover, the binary
package managers in FBSD have been getting better and better over time and
are compatible with ports, something that I don't know of any Linux capable
of (i.e. you can interchangeably install something via ports or binary
package and to they system it's the same thing).

Best,
Alejandro Imass
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Rebuild old version of port?

[Ryan Schmidt]

On Oct 7, 2015, at 9:53 AM, Adam Dershowitz wrote:

> Is there a way that I can rebuild and reactivate an older version of a  port? 
>  I know about this link:  
> https://trac.macports.org/wiki/howto/InstallingOlderPort  but the problem I 
> have is a little bit different.
> I have the old versions still on my computer, including the source (these 
> were ports that build from source), and they are for a port that is not 
> hosted on macports.  
> The problem is that one of the dependents changed, so if I just activate the 
> old version it fails.  So, what I want is essentially to “activate from 
> source” or “rebuild @version)” since I already have the source and the port 
> for the old version.  
> I can just activate the old version because there is the issue of a bad link, 
> so it needs to be rebuilt.  
> I tried: 
> sudo port install myport @myoldversion but it tried to rebuild the new 
> version, which is not what I want.  
> I also tried just giving the source flag:
> sudo port activate -s myport @myoldversion but then it just activated the old 
> version.  
> 
> I actually had no intention of yet upgrading this port, but when I upgraded 
> one of the dependents , macports found that the port was now broken, and 
> proceeded to download the new version of the port before rebuilding.  But, 
> that new version is actually broken (for a completely unrelated reason).  So, 
> now I can’t use the new version of the port, and I want to go back to the old 
> version, but I can just activate it, because of the dependent issue.  So, I 
> want to just have macports rebuild the old version from source.  

I don't know what to tell you. I don't completely understand your issue. 
InstallingOlderPort explains how to install an older version of a port. "sudo 
port install" does not support an "@version" modifier.

Maybe it would help if you told us what version of what port you're trying to 
build, and, since you said it's not hosted on MacPorts, where it's hosted, or 
where you got it.

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

Re: pet project : LnxPorts

[René J . V . Bertin]

On Thursday October 08 2015 07:16:51 Alejandro Imass wrote:

> Perhaps it's a good time to evaluate a switch to PCBSD and ditch the Linux
> ;-)

Why?

I've already checked the temp of those waters. I know MacPorts comes from BSD 
originally, but I cannot say I felt right at home at once on PC-BSD in that 
aspect. Maybe MacPorts has been on a divergent evolutionary path from its BSD 
ancestor ...

There's also the question of hardware support, and software that exists for 
Linux but not BSD. I like the fact PC-BSD uses ZFS (so does my Linux box :)) 
but I'm not convinced about its choice as an OS for a generic 
desktop/workstation instead for server purposes.

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

Re: pet project : LnxPorts

[Alejandro Imass]

On Wed, Oct 7, 2015 at 1:59 PM, René J.V.  wrote:

> Morning!
>
> OK now, don't get me wrong, this is not an announcement that I'll be
> forking off MacPorts to begin a fully supported Linux variant! :)
>
> However, if anyone on here is like me (a developer's not to say hacker's
> mindset, and swinging back and forth between the OS X and Linux household
> members), they might see the use for being able to install select ports
> through a familiar and well-tested package/distribution system without
> interfering with the host.
>


Perhaps it's a good time to evaluate a switch to PCBSD and ditch the Linux
;-)

Cheers,
Alejandro Imass
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Incompatible library version

[Michel Perez]

Indeed, cleaning .bash_profile file fixed this issue.
The bug has been reported to matlab.
Hat’s off to the macport-users team !
Michel Perez
> On 08 Oct 2015, at 10:36, Bachsau  wrote:
> 
> Michel Perez wrote on 08.10.2015 09:21:
>> Will I have to choose between matlab and macport?
> 
> Try removing it from the MATLAB script yourself and see if it still runs.
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users

*
Michel Perez
Université de Lyon - INSA de Lyon
MATEIS - UMR CNRS 5510
25 avenue Capelle
69 621 Villeurbanne Cedex
Tel.: +33 4 72 43 80 63
Fax.: +33 4 72 43 85 39
Mel.: michel.pe...@insa-lyon.fr
Web: http://michel.perez.net.free.fr
*

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

Re: Incompatible library version

[Bachsau]

Michel Perez wrote on 08.10.2015 09:21:

Will I have to choose between matlab and macport?


Try removing it from the MATLAB script yourself and see if it still runs.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Incompatible library version

[Chris Jones]

Do not set DYLD_LIBRARY_PATH, doing so is a bad idea. If MatLab requires 
this (is it really needed ??, I am quite surprised this is done into 
internals inside an application in /Applications), report this as a bug 
against MatLab...


On 08/10/15 08:21, Michel Perez wrote:

Jeremy,
Indeed, the DYLD_LIBRARY_PATH is set… by MATLAB !
mperez$ set | grep DYLD
DYLD_LIBRARY_PATH=/Applications/MATLAB_R2015a.app/bin/maci64:/Applications/MATLAB_R2015a.app/sys/os/maci64:/usr/local/qwt-6.0.1/lib:
Will I have to choose between matlab and macport?
What should I do?
Michel

On 08 Oct 2015, at 07:45, Jeremy Sequoia mailto:jerem...@apple.com>> wrote:

Yep, it looks like you probably have DYLD_INSERT_LIBRARIES or
DYLD_LIBRARY_PATH set.  Don't do that ;).

To confirm, run 'set | grep DYLD'

Check your shell init scripts.

Sent from my iPhone...

On Oct 7, 2015, at 22:12, Michel Perez mailto:michel.pe...@insa-lyon.fr>> wrote:


Thanks Jeremy for your reply
The output of otool command is:

mperez$ otool -L /opt/local/lib/libtiff.5.dylib
/opt/local/lib/libtiff.5.dylib:
/opt/local/lib/libtiff.5.dylib (compatibility version 8.0.0, current
version 8.4.0)
/opt/local/lib/liblzma.5.dylib (compatibility version 8.0.0, current
version 8.1.0)
/opt/local/lib/libjpeg.9.dylib (compatibility version 11.0.0, current
version 11.0.0)
/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current
version 1.2.8)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1213.0.0)

I do not know if I shot myself in the foot, but it hurts: not a
single macport program works !
Thanks again,
Michel

On 08 Oct 2015, at 01:28, Jeremy Huddleston Sequoia
mailto:jerem...@apple.com>> wrote:

It looks like you either have an outdated version of libtiff or are
using DYLD_INSERT_LIBRARIES to shoot yourself in the foot.

What's the output of 'otool -L /opt/local/lib/libtiff.5.dylib'?

--Jeremy


On Oct 7, 2015, at 07:06, Michel Perez mailto:michel.pe...@insa-lyon.fr>> wrote:

Hello,

I got the Incompatible library version error whatever the software
I lauch.
I tried to reinstall macport but still get the following error:

dyld: Library not loaded: /opt/local/lib/libtiff.5.dylib
 Referenced from:
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_xrc-3.0.dylib
 Reason: Incompatible library version:
libwx_osx_cocoau_xrc-3.0.dylib requires version 8.0.0 or later, but
libtiff.5.dylib provides version 6.0.0
Trace/BPT trap: 5

Thanks for your help

*
Michel Perez
Université de Lyon - INSA de Lyon
MATEIS - UMR CNRS 5510
25 avenue Capelle
69 621 Villeurbanne Cedex
Tel.: +33 4 72 43 80 63
Fax.: +33 4 72 43 85 39
Mel.: michel.pe...@insa-lyon.fr 
Web: http://michel.perez.net.free.fr 
*

___
macports-users mailing list
macports-users@lists.macosforge.org

https://lists.macosforge.org/mailman/listinfo/macports-users




*
Michel Perez
Université de Lyon - INSA de Lyon
MATEIS - UMR CNRS 5510
25 avenue Capelle
69 621 Villeurbanne Cedex
Tel.: +33 4 72 43 80 63
Fax.: +33 4 72 43 85 39
Mel.: michel.pe...@insa-lyon.fr 
Web: http://michel.perez.net.free.fr 
*



*
Michel Perez
Université de Lyon - INSA de Lyon
MATEIS - UMR CNRS 5510
25 avenue Capelle
69 621 Villeurbanne Cedex
Tel.: +33 4 72 43 80 63
Fax.: +33 4 72 43 85 39
Mel.: michel.pe...@insa-lyon.fr 
Web: http://michel.perez.net.free.fr
*



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


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

Re: Incompatible library version

[Jeremy Huddleston Sequoia]

Contact Matlab.  There's no reason that they should require you setting 
DYLD_LIBRARY_PATH globally.  Was this done by an installer?  If so, shame on 
them big time.  Or was this done by you following some bad advise from some 
website?  If so, can you point me to that website, so I can help point them in 
the right direction?

Thanks,
Jeremy

> On Oct 8, 2015, at 00:21, Michel Perez  wrote:
> 
> Jeremy,
> Indeed, the DYLD_LIBRARY_PATH is set… by MATLAB !
> mperez$ set | grep DYLD
> DYLD_LIBRARY_PATH=/Applications/MATLAB_R2015a.app/bin/maci64:/Applications/MATLAB_R2015a.app/sys/os/maci64:/usr/local/qwt-6.0.1/lib:
> Will I have to choose between matlab and macport?
> What should I do?
> Michel
>> On 08 Oct 2015, at 07:45, Jeremy Sequoia  wrote:
>> 
>> Yep, it looks like you probably have DYLD_INSERT_LIBRARIES or 
>> DYLD_LIBRARY_PATH set.  Don't do that ;).  
>> 
>> To confirm, run 'set | grep DYLD'
>> 
>> Check your shell init scripts.
>> 
>> Sent from my iPhone...
>> 
>> On Oct 7, 2015, at 22:12, Michel Perez  wrote:
>> 
>>> Thanks Jeremy for your reply
>>> The output of otool command is:
>>> 
>>> mperez$ otool -L /opt/local/lib/libtiff.5.dylib
>>> /opt/local/lib/libtiff.5.dylib:
>>> /opt/local/lib/libtiff.5.dylib (compatibility version 8.0.0, current 
>>> version 8.4.0)
>>> /opt/local/lib/liblzma.5.dylib (compatibility version 8.0.0, current 
>>> version 8.1.0)
>>> /opt/local/lib/libjpeg.9.dylib (compatibility version 11.0.0, current 
>>> version 11.0.0)
>>> /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current 
>>> version 1.2.8)
>>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
>>> version 1213.0.0)
>>> 
>>> I do not know if I shot myself in the foot, but it hurts: not a single 
>>> macport program works !
>>> Thanks again,
>>> Michel
 On 08 Oct 2015, at 01:28, Jeremy Huddleston Sequoia  
 wrote:
 
 It looks like you either have an outdated version of libtiff or are using 
 DYLD_INSERT_LIBRARIES to shoot yourself in the foot.
 
 What's the output of 'otool -L /opt/local/lib/libtiff.5.dylib'?
 
 --Jeremy
 
> On Oct 7, 2015, at 07:06, Michel Perez  wrote:
> 
> Hello,
> 
> I got the Incompatible library version error whatever the software I 
> lauch.
> I tried to reinstall macport but still get the following error:
> 
> dyld: Library not loaded: /opt/local/lib/libtiff.5.dylib
>  Referenced from: 
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_xrc-3.0.dylib
>  Reason: Incompatible library version: libwx_osx_cocoau_xrc-3.0.dylib 
> requires version 8.0.0 or later, but libtiff.5.dylib provides version 
> 6.0.0
> Trace/BPT trap: 5
> 
> Thanks for your help
> 
> *
> Michel Perez
> Université de Lyon - INSA de Lyon
> MATEIS - UMR CNRS 5510
> 25 avenue Capelle
> 69 621 Villeurbanne Cedex
> Tel.: +33 4 72 43 80 63
> Fax.: +33 4 72 43 85 39
> Mel.: michel.pe...@insa-lyon.fr
> Web: http://michel.perez.net.free.fr
> *
> 
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
 
>>> 
>>> *
>>> Michel Perez
>>> Université de Lyon - INSA de Lyon
>>> MATEIS - UMR CNRS 5510
>>> 25 avenue Capelle
>>> 69 621 Villeurbanne Cedex
>>> Tel.: +33 4 72 43 80 63
>>> Fax.: +33 4 72 43 85 39
>>> Mel.: michel.pe...@insa-lyon.fr
>>> Web: http://michel.perez.net.free.fr
>>> *
>>> 
> 
> *
> Michel Perez
> Université de Lyon - INSA de Lyon
> MATEIS - UMR CNRS 5510
> 25 avenue Capelle
> 69 621 Villeurbanne Cedex
> Tel.: +33 4 72 43 80 63
> Fax.: +33 4 72 43 85 39
> Mel.: michel.pe...@insa-lyon.fr
> Web: http://michel.perez.net.free.fr
> *
> 
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users



smime.p7s
Description: S/MIME cryptographic signature
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Incompatible library version

[Michel Perez]

Jeremy,
Indeed, the DYLD_LIBRARY_PATH is set… by MATLAB !
mperez$ set | grep DYLD
DYLD_LIBRARY_PATH=/Applications/MATLAB_R2015a.app/bin/maci64:/Applications/MATLAB_R2015a.app/sys/os/maci64:/usr/local/qwt-6.0.1/lib:
Will I have to choose between matlab and macport?
What should I do?
Michel
> On 08 Oct 2015, at 07:45, Jeremy Sequoia  wrote:
> 
> Yep, it looks like you probably have DYLD_INSERT_LIBRARIES or 
> DYLD_LIBRARY_PATH set.  Don't do that ;).  
> 
> To confirm, run 'set | grep DYLD'
> 
> Check your shell init scripts.
> 
> Sent from my iPhone...
> 
> On Oct 7, 2015, at 22:12, Michel Perez  > wrote:
> 
>> Thanks Jeremy for your reply
>> The output of otool command is:
>> 
>> mperez$ otool -L /opt/local/lib/libtiff.5.dylib
>> /opt/local/lib/libtiff.5.dylib:
>>  /opt/local/lib/libtiff.5.dylib (compatibility version 8.0.0, current 
>> version 8.4.0)
>>  /opt/local/lib/liblzma.5.dylib (compatibility version 8.0.0, current 
>> version 8.1.0)
>>  /opt/local/lib/libjpeg.9.dylib (compatibility version 11.0.0, current 
>> version 11.0.0)
>>  /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current 
>> version 1.2.8)
>>  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
>> version 1213.0.0)
>> 
>> I do not know if I shot myself in the foot, but it hurts: not a single 
>> macport program works !
>> Thanks again,
>> Michel
>>> On 08 Oct 2015, at 01:28, Jeremy Huddleston Sequoia >> > wrote:
>>> 
>>> It looks like you either have an outdated version of libtiff or are using 
>>> DYLD_INSERT_LIBRARIES to shoot yourself in the foot.
>>> 
>>> What's the output of 'otool -L /opt/local/lib/libtiff.5.dylib'?
>>> 
>>> --Jeremy
>>> 
 On Oct 7, 2015, at 07:06, Michel Perez >>> > wrote:
 
 Hello,
 
 I got the Incompatible library version error whatever the software I lauch.
 I tried to reinstall macport but still get the following error:
 
 dyld: Library not loaded: /opt/local/lib/libtiff.5.dylib
  Referenced from: 
 /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_xrc-3.0.dylib
  Reason: Incompatible library version: libwx_osx_cocoau_xrc-3.0.dylib 
 requires version 8.0.0 or later, but libtiff.5.dylib provides version 6.0.0
 Trace/BPT trap: 5
 
 Thanks for your help
 
 *
 Michel Perez
 Université de Lyon - INSA de Lyon
 MATEIS - UMR CNRS 5510
 25 avenue Capelle
 69 621 Villeurbanne Cedex
 Tel.: +33 4 72 43 80 63
 Fax.: +33 4 72 43 85 39
 Mel.: michel.pe...@insa-lyon.fr 
 Web: http://michel.perez.net.free.fr 
 *
 
 ___
 macports-users mailing list
 macports-users@lists.macosforge.org 
 
 https://lists.macosforge.org/mailman/listinfo/macports-users 
 
>>> 
>> 
>> *
>> Michel Perez
>> Université de Lyon - INSA de Lyon
>> MATEIS - UMR CNRS 5510
>> 25 avenue Capelle
>> 69 621 Villeurbanne Cedex
>> Tel.: +33 4 72 43 80 63
>> Fax.: +33 4 72 43 85 39
>> Mel.: michel.pe...@insa-lyon.fr 
>> Web: http://michel.perez.net.free.fr 
>> *
>> 

*
Michel Perez
Université de Lyon - INSA de Lyon
MATEIS - UMR CNRS 5510
25 avenue Capelle
69 621 Villeurbanne Cedex
Tel.: +33 4 72 43 80 63
Fax.: +33 4 72 43 85 39
Mel.: michel.pe...@insa-lyon.fr
Web: http://michel.perez.net.free.fr
*

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