Re: CarbonHeaders obsolete: uninstall dependencies

On Jan 19, 2015, at 9:29 PM, Jeremy Huddleston Sequoia wrote: > On Tiger and later, you should use AvailabilityMacros.h as provided by the > SDK. > > On Leopard and later, you should use Availability.h as provided by the SDK Oh right, silly me. Otherwise changing deployment target and base SD

Re: /opt/local/macports/software

When MS Office singlehandedly uses up all the drive on those tiny drives, I cannot feel sorry that there's no room left for MacPorts--because there's already no room left for anything before MacPorts even enters the picture. On January 19, 2015 9:49:43 PM EST, Craig Treleaven wrote: >At 8:20 P

Re: /opt/local/macports/software

At 8:20 PM + 1/19/15, Chris Jones wrote: > On 19 Jan 2015, at 7:13 pm, Craig Treleaven wrote: > At 3:11 PM + 1/19/15, Chris Jones wrote: ... Does anyone else find it bizarre that, in 2015, we've got such an active thread about saving a few gigs of space? Nope. Saving disk spac

/opt/local/macports/software

Daniel J. Luke wrote: >> On Jan 19, 2015, at 6:34 AM, René J.V. Bertin wrote: >> What could be an option: >> - use xz instead of bzip2 to compact things a bit more > > this would probably be a small change (I think there's support for gzip and > zip already) - but changing your local archive typ

Re: CarbonHeaders obsolete: uninstall dependencies

> On Jan 19, 2015, at 17:22, Lawrence Velázquez wrote: > > On Jan 19, 2015, at 5:47 PM, René J.V. Bertin wrote: > >> I somehow missed this obsolescence... >> Why exactly have the CarbonHeaders gone obsolete > > Because ports should be using the headers provided by the host. > > https://trac.

Re: CarbonHeaders obsolete: uninstall dependencies

Hi René and Brandon, On 20/01/2015, at 12:23 PM, René J.V. Bertin wrote: > On Monday January 19 2015 18:09:46 Brandon Allbery wrote: >> On Mon, Jan 19, 2015 at 5:47 PM, René J.V. wrote: >> >>> AvailabilityMacros.h? I've made a number of patches to KDE4 that rely on >>> that header, and KDE uses

Re: /opt/local/macports/software

On Jan 19, 2015, at 7:31 PM, René J.V. Bertin wrote: > On Monday January 19 2015 19:05:40 Ryan Schmidt wrote: >> >>> IMHO the argument is stupid. If you **need** those gigs then buy them. I >>> just bought 1T at $0.0089 / gig !! >> >> Conserving disk space is a valid concern. Many Macs made in

Re: /opt/local/macports/software

On Jan 19, 2015, at 7:15 PM, René J.V. Bertin wrote: > On Monday January 19 2015 17:21:14 Ryan Schmidt wrote: > >> Spotlight would find items in the /opt/local/var/macports/software >> directory. So when you were trying to launch an application in >> /Applications/MacPorts, it might find the co

Re: /opt/local/macports/software

On Monday January 19 2015 19:05:40 Ryan Schmidt wrote: > > > IMHO the argument is stupid. If you **need** those gigs then buy them. I > > just bought 1T at $0.0089 / gig !! > > Conserving disk space is a valid concern. Many Macs made in the past few > years have an internal SSD and do not have

Re: CarbonHeaders obsolete: uninstall dependencies

On Jan 19, 2015, at 5:47 PM, René J.V. Bertin wrote: > I somehow missed this obsolescence... > Why exactly have the CarbonHeaders gone obsolete Because ports should be using the headers provided by the host. https://trac.macports.org/ticket/42500#comment:6 https://trac.macports.org/ticket/46521

Re: CarbonHeaders obsolete: uninstall dependencies

On Monday January 19 2015 18:09:46 Brandon Allbery wrote: > On Mon, Jan 19, 2015 at 5:47 PM, René J.V. wrote: > > > AvailabilityMacros.h? I've made a number of patches to KDE4 that rely on > > that header, and KDE uses Carbon itself. > > > One hopes not, since Carbon is gone post-10.6 except f

Re: /opt/local/macports/software

On Monday January 19 2015 17:21:14 Ryan Schmidt wrote: > Spotlight would find items in the /opt/local/var/macports/software directory. > So when you were trying to launch an application in /Applications/MacPorts, > it might find the copy in /opt/local/var/macports/software instead, which > migh

Re: /opt/local/macports/software

On Monday January 19 2015 18:38:52 Ryan Schmidt wrote: > >> Just to be clear: I do agree with this, and practice it myself. One of the > >> reasons MacPorts is not installed on my boot partition. > >> (heck, I'm old and pedantic enough to care about free space fragmentation > >> ...) > > > > Wh

Re: /opt/local/macports/software

On Jan 19, 2015, at 6:58 PM, James Linder wrote: > > IMHO the argument is stupid. If you **need** those gigs then buy them. I just > bought 1T at $0.0089 / gig !! Conserving disk space is a valid concern. Many Macs made in the past few years have an internal SSD and do not have internal space

Re: /opt/local/macports/software

> On 20 Jan 2015, at 4:00 am, macports-users-requ...@lists.macosforge.org wrote: > >> Le 19 janv. 2015 ? 10:54, Ryan Schmidt a ?crit : >>> So maybe we could reconsider the existence of this feature, or at least, >>> the fact that its mandatory. >> >> If I remember correctly, the code for the ol

Re: CarbonHeaders obsolete: uninstall dependencies

* Ryan Schmidt [150119 15:42]: <...> > Error: port uninstall failed: Registry error: libunwind-headers @3.5.0_0 not registered as installed > > ### > > > > Please advise ... > When you have multiple versions of a port installed, w

Re: /opt/local/macports/software

On Jan 19, 2015, at 6:30 PM, Brandon Allbery wrote: > On Mon, Jan 19, 2015 at 3:31 PM, René J.V. wrote: >> Just to be clear: I do agree with this, and practice it myself. One of the >> reasons MacPorts is not installed on my boot partition. >> (heck, I'm old and pedantic enough to care about free

Re: CarbonHeaders obsolete: uninstall dependencies

On Jan 19, 2015, at 6:08 PM, Tim Johnson wrote: > * Lawrence Velázquez [150119 13:53]: >> On Jan 19, 2015, at 5:30 PM, Tim Johnson wrote: >> >>> Since I have only entry - level knowledge of macports, and I don't >>> wish to do "damage" I'm must ask : >>> >>> Is this just a matter of running

Re: /opt/local/macports/software

On Mon, Jan 19, 2015 at 3:31 PM, René J.V. wrote: > Just to be clear: I do agree with this, and practice it myself. One of the > reasons MacPorts is not installed on my boot partition. > (heck, I'm old and pedantic enough to care about free space fragmentation > ...) Which is great until 10.9+

Re: /opt/local/macports/software

On Mon, Jan 19, 2015 at 5:21 PM, Ryan Schmidt wrote: > > > - use xz instead of bzip2 to compact things a bit more > > Whatever compression format is used needs to be supported without the use > of any port. OS X does not include support for dealing with xz files, which > is one reason why bz2 fil

Re: /opt/local/macports/software

On Mon, 19 Jan 2015, René J.V. Bertin wrote: > Just to be clear: I do agree with this, and practice it myself. One of > the reasons MacPorts is not installed on my boot partition. (heck, I'm > old and pedantic enough to care about free space fragmentation ...) I'm glad to know that I'm not the

Re: CarbonHeaders obsolete: uninstall dependencies

* Lawrence Velázquez [150119 13:53]: > On Jan 19, 2015, at 5:30 PM, Tim Johnson wrote: > > > Since I have only entry - level knowledge of macports, and I don't > > wish to do "damage" I'm must ask : > > > > Is this just a matter of running > > sudo port libunwind-headers ? > > and then > > s

Re: CarbonHeaders obsolete: uninstall dependencies

On Jan 19, 2015, at 4:30 PM, Tim Johnson wrote: > MacPorts base version 2.3.3 on OS X 10.7 > > When executing > sudo port upgrade outdated > I get the following message : > Error: CarbonHeaders is an obsolete port. Please uninstall it > When executing >

Re: /opt/local/macports/software

On Jan 19, 2015, at 9:49 AM, René J.V. Bertin wrote: >>> Similarly, is there a way to disable the storing of the source files in >>> …/distfiles? >> >> No [...] > > Are there side-effects to cleaning out that directory manually, other than > re-downloading when needed? It's largely fine. My h

Re: /opt/local/macports/software

On Jan 19, 2015, at 5:34 AM, René J.V. Bertin wrote: > On Monday January 19 2015 04:07:40 Ryan Schmidt wrote: > >> There are situations where MacPorts will advise you that an installation you >> requested cannot proceed until you deactivate (or uninstall) a particular >> port (the conflicts_bu

Re: Local repository

On 20 Jan 2015, at 00:11 , M. Daniel Becque wrote: > I created a local repository for a couple of port files and included them in > the database using the portindex command. If I remove a port from my local > repository, do I just run the portindex command again to remove it from the > port da

Local repository

I created a local repository for a couple of port files and included them in the database using the portindex command. If I remove a port from my local repository, do I just run the portindex command again to remove it from the port database? Thanks dan

Re: CarbonHeaders obsolete: uninstall dependencies

On Mon, Jan 19, 2015 at 5:47 PM, René J.V. wrote: > AvailabilityMacros.h? I've made a number of patches to KDE4 that rely on > that header, and KDE uses Carbon itself. One hopes not, since Carbon is gone post-10.6 except for backward compatibility for ancient apps. -- brandon s allbery kf8nh

Re: CarbonHeaders obsolete: uninstall dependencies

On Monday January 19 2015 13:30:24 Tim Johnson wrote: > MacPorts base version 2.3.3 on OS X 10.7 > > When executing > sudo port upgrade outdated > I get the following message : > Error: CarbonHeaders is an obsolete port. Please uninstall it > When execu

Re: CarbonHeaders obsolete: uninstall dependencies

On Jan 19, 2015, at 5:30 PM, Tim Johnson wrote: > Since I have only entry - level knowledge of macports, and I don't > wish to do "damage" I'm must ask : > > Is this just a matter of running > sudo port libunwind-headers ? > and then > sudo port uninstall CarbonHeaders ? Hi Tim, You probabl

CarbonHeaders obsolete: uninstall dependencies

MacPorts base version 2.3.3 on OS X 10.7 When executing sudo port upgrade outdated I get the following message : Error: CarbonHeaders is an obsolete port. Please uninstall it When executing sudo port uninstall CarbonHeaders I get the following message

Re: /opt/local/macports/software

I agree with *both* Daniel and René. On 20/01/2015, at 7:08 AM, René J.V. Bertin wrote: > On Monday January 19 2015 14:35:19 Daniel J. Luke wrote: > >> I actually prefer doing `port upgrade outdated` make sure things are working >> as I expect (and if not, quickly revert back with deactivate/act

Re: /opt/local/macports/software

> On Jan 19, 2015, at 4:43 PM, Clemens Lang wrote: > - On 19 Jan, 2015, at 22:20, Daniel J. Luke dl...@geeklair.net wrote: >> ... but you're right, cal fixed it and it's been released (I though the fix >> was >> sitting on trunk still, but it made Macports 2.3.0) > > I am currently not aware

Re: /opt/local/macports/software

- On 19 Jan, 2015, at 22:20, Daniel J. Luke dl...@geeklair.net wrote: > ... but you're right, cal fixed it and it's been released (I though the fix > was > sitting on trunk still, but it made Macports 2.3.0) I am currently not aware of any problems with /opt or /opt/local being a symlink e

Re: /opt/local/macports/software

> On Jan 19, 2015, at 4:14 PM, René J.V. Bertin wrote: >> One needs to set portdbpath in macports.conf to the 'real' path > > Oh? I haven't, and I also don't see why it'd be required. I was thinking of https://trac.macports.org/ticket/39850 > There has been a time where this kind of configurati

Re: /opt/local/macports/software

On Monday January 19 2015 15:58:08 Daniel J. Luke wrote: > it mostly works (port provides doesn't, for now), (echo, echo, e c h o :)) > One needs to set portdbpath in macports.conf to the 'real' path Oh? I haven't, and I also don't see why it'd be required. I think that for my 1st MacPorts ins

Re: /opt/local/macports/software

On Monday January 19 2015 15:25:17 Brandon Allbery wrote: > /opt/local itself can't be safely symlinked because various things break > when it's not a real directory. Certain parts of things underneath it very Like what? /opt/local has always been a symlink for me, and the only thing I'm aware o

Re: /opt/local/macports/software

> On Jan 19, 2015, at 3:08 PM, René J.V. Bertin wrote: > Me too, though I wouldn't mind an automatic option that leaves say the 2 > latest inactive versions, except for ports on an exclusion list. > > Dream on :) I would be willing to bet that something like that would be included in MacPorts

Re: /opt/local/macports/software

> On Jan 19, 2015, at 3:25 PM, Brandon Allbery wrote: > > On Mon, Jan 19, 2015 at 3:12 PM, René J.V. wrote: > > On the other hand, I solved it by copying most of /opt/local/var/macports > > onto an external USB drive and symlinking it back. Huge USB external drives > > are ridiculously cheap the

Re: /opt/local/macports/software

My solution for having extra storage on a macbook is one of these http://minidrive.bynifty.com It has given me an extra 64G (of slow storage, but immediately available) for a couple of years now. For $100US I am about to upgrade it to use a 128G micro SD. Mike (

Re: /opt/local/macports/software

> On 19 Jan 2015, at 20:13, Craig Treleaven wrote: > > If one has a too-small SSD, it seems more-than-a-little strange to complain > that building/installing a bunch of software packages consumes it. Get a > bigger drive. Or smaller expectations. Personally, when I bought my MacBook Air two

Re: /opt/local/macports/software

Hi, > On 19 Jan 2015, at 8:28 pm, René J.V. Bertin wrote: > > On Monday January 19 2015 20:20:06 Chris Jones wrote: > >>> If one has a too-small SSD, it seems more-than-a-little strange to complain >>> that building/installing a bunch of software packages consumes it. Get a >>> bigger drive.

Re: /opt/local/macports/software

On Monday January 19 2015 20:20:06 Chris Jones wrote: > Nope. Saving disk space when not required is always a good idea. Just to be clear: I do agree with this, and practice it myself. One of the reasons MacPorts is not installed on my boot partition. (heck, I'm old and pedantic enough to care a

Re: /opt/local/macports/software

On Monday January 19 2015 20:20:06 Chris Jones wrote: > > If one has a too-small SSD, it seems more-than-a-little strange to complain > > that building/installing a bunch of software packages consumes it. Get a > > bigger drive. Or smaller expectations. > > And how pray does one do that in a

Re: /opt/local/macports/software

On Mon, Jan 19, 2015 at 3:12 PM, René J.V. wrote: > > On the other hand, I solved it by copying most of /opt/local/var/macports > > onto an external USB drive and symlinking it back. Huge USB external > drives > > are ridiculously cheap these days. > > I'm pretty sure I tried that, and got slappe

Re: /opt/local/macports/software

Hi, > On 19 Jan 2015, at 7:13 pm, Craig Treleaven wrote: > > At 3:11 PM + 1/19/15, Chris Jones wrote: >> ... > > Does anyone else find it bizarre that, in 2015, we've got such an active > thread about saving a few gigs of space? Nope. Saving disk space when not required is always a good i

Re: /opt/local/macports/software

On Monday January 19 2015 14:52:25 Brandon Allbery wrote: > On the other hand, I solved it by copying most of /opt/local/var/macports > onto an external USB drive and symlinking it back. Huge USB external drives > are ridiculously cheap these days. I'm pretty sure I tried that, and got slapped on

Re: /opt/local/macports/software

> Le 19 janv. 2015 à 20:13, Craig Treleaven a écrit : > > At 3:11 PM + 1/19/15, Chris Jones wrote: >> ... > > Does anyone else find it bizarre that, in 2015, we've got such an > active thread about saving a few gigs of space? > > If one has a too-small SSD, it seems more-than-a-little str

Re: /opt/local/macports/software

On Monday January 19 2015 14:35:19 Daniel J. Luke wrote: > personally, I have had to restore machines in places where connectivity was > problematic before - and I size things so I have more than enough backup > capacity to just back up everything and save myself the potential headaches > (less

Re: /opt/local/macports/software

On Mon, Jan 19, 2015 at 2:13 PM, Craig Treleaven wrote: > Does anyone else find it bizarre that, in 2015, we've got such an active > thread about saving a few gigs of space? > > If one has a too-small SSD, it seems more-than-a-little strange to > complain that building/installing a bunch of softw

Re: /opt/local/macports/software

At 3:11 PM + 1/19/15, Chris Jones wrote: ... Does anyone else find it bizarre that, in 2015, we've got such an active thread about saving a few gigs of space? If one has a too-small SSD, it seems more-than-a-little strange to complain that building/installing a bunch of software package

Re: /opt/local/macports/software

> On Jan 19, 2015, at 10:49 AM, René J.V. Bertin wrote: > On Monday January 19 2015 09:34:51 Daniel J. Luke wrote: >> being able to let TimeMachine back up my macports $prefix is nice, I >> wouldn't want to not be able to do that because of a macports design >> decision. > > Of course - but all

Re: /opt/local/macports/software

- On 19 Jan, 2015, at 16:49, René J.V. Bertin rjvber...@gmail.com wrote: >> > Similarly, is there a way to disable the storing of the source files in >> > …/distfiles? >> >> No [...] > > Are there side-effects to cleaning out that directory manually, other than > re-downloading when needed?

Re: /opt/local/macports/software

On Monday January 19 2015 09:34:51 Daniel J. Luke wrote: > being able to let TimeMachine back up my macports $prefix is nice, I wouldn't > want to not be able to do that because of a macports design decision. Of course - but all of it? I exclude a good part of $prefix/var/macports, because it's

Re: /opt/local/macports/software

Clemens: > I disagree. I often use deactivation and activation, and I'd have to > re-download > the archive every time I did that, it would be a major hassle for me. I agree. Of course, your mileage may vary. That’s why I think it’d mayhap be worth investigating the possibility of having more t

Re: /opt/local/macports/software

But I admit it is not very useful nowadays. It should be optional, at least when the version installed is the default one, i.e. the binary can be re-downloaded verbatim from the server (not a bespoken version with various variants set). I disagree. I often use deactivation and activation, and

Re: /opt/local/macports/software

It is also correct that all other package systems you're familiar with never have to build locally from source. True, but I don't agree it completely negates the argument. Possibly if you can get away with always operating in binary mode then we could re-download missing archives from packag

Re: /opt/local/macports/software

- On 19 Jan, 2015, at 15:40, Vincent Habchi vi...@macports.org wrote: > But I admit it is not very useful nowadays. It should be optional, at least > when > the version installed is the default one, i.e. the binary can be re-downloaded > verbatim from the server (not a bespoken version with

Re: /opt/local/macports/software

On Mon, Jan 19, 2015 at 4:42 AM, Chris Jones wrote: > It is correct that all others I am familiar with do not require the user > to effectively have two copies (albeit one compressed) on their system, the > installed one and the original install media (whether that be tar, rpm, deb > or whatever)

Re: /opt/local/macports/software

Oops, not ‘bespoken’, ‘bespoke’. ‘it was well worth keeping a local copy RATHER than to trust a flaky remote server or a rickety connexion.’ Who said I needed a proofreader? :) V. ___ macports-users mailing list macports-users@lists.macosforge.org htt

Re: /opt/local/macports/software

Salut Akim ! Hi Ryan! > I'm talking about removing the copy kept in that directory at the > end of the process. I suppose this is a leftover from the time when Internet bandwidth was unreliable and expensive, and it was well worth keeping a local copy than to trust a flaky remote server or a ri

Re: /opt/local/macports/software

> On Jan 19, 2015, at 6:34 AM, René J.V. Bertin wrote: > What issues with SpotLight and/or Time Machine? the best way to figure that out would probably be to look through the macports-dev archives where the changes were discussed before they were implemented. Also note that the way our binary

Re: /opt/local/macports/software

Well, I'm a grownup and willing to take these chances. I don't play with activate/deactivate. I know of no other distros that "wastes" that kind of disk space for that. That some wish to use this feature, fine. But I need those gigs back. Removing these files will very likely break your up

Re: /opt/local/macports/software

Hi, - On 19 Jan, 2015, at 10:26, Akim Demaille a...@lrde.epita.fr wrote: > Well, I'm a grownup and willing to take these chances. I don't > play with activate/deactivate. I know of no other distros that > "wastes" that kind of disk space for that. That some wish to > use this feature, fine

Re: /opt/local/macports/software

> Le 19 janv. 2015 à 11:07, Ryan Schmidt a écrit : > > On Jan 19, 2015, at 3:59 AM, Akim Demaille wrote: >> You're talking implementation details, I'm talking feature. And the >> implementation is straightforward: rm -f /opt/local/macports/software/ >> when was activated. > > It's quite a lot

Re: /opt/local/macports/software

On Jan 19, 2015, at 3:59 AM, Akim Demaille wrote: > > Le 19 janv. 2015 à 10:54, Ryan Schmidt a écrit : >>> So maybe we could reconsider the existence of this feature, or at least, >>> the fact that its mandatory. >> >> If I remember correctly, the code for the old way with hard links was >> remo

Re: /opt/local/macports/software

> Le 19 janv. 2015 à 10:54, Ryan Schmidt a écrit : >> So maybe we could reconsider the existence of this feature, or at least, >> the fact that its mandatory. > > If I remember correctly, the code for the old way with hard links was removed > from MacPorts. There is no way to go back to that me

Re: /opt/local/macports/software

On Jan 19, 2015, at 3:42 AM, Akim Demaille wrote: > >> Le 19 janv. 2015 à 10:34, Ryan Schmidt a écrit : >> >> Please Reply All so that the discussion stays on the mailing list. > > Hmmm, I did. > >> Of note is that MacPorts used to not do this, or rather, using these >> archives used to be op

Re: /opt/local/macports/software

On 19/01/15 09:34, Ryan Schmidt wrote: Please Reply All so that the discussion stays on the mailing list. On Jan 19, 2015, at 3:26 AM, Akim Demaille wrote: Le 19 janv. 2015 à 09:27, Ryan Schmidt a écrit : Hi Ryan, If you mean /opt/local/var/macports/software, that's where the compressed

Re: /opt/local/macports/software

> Le 19 janv. 2015 à 10:34, Ryan Schmidt a écrit : > > Please Reply All so that the discussion stays on the mailing list. Hmmm, I did. > Of note is that MacPorts used to not do this, or rather, using these archives > used to be optional, and not the default. Previously, the default was that

Re: /opt/local/macports/software

Please Reply All so that the discussion stays on the mailing list. > On Jan 19, 2015, at 3:26 AM, Akim Demaille wrote: > >> Le 19 janv. 2015 à 09:27, Ryan Schmidt a écrit : > > Hi Ryan, > >> If you mean /opt/local/var/macports/software, that's where the compressed >> archives of all your insta

Re: /opt/local/macports/software

> Le 19 janv. 2015 à 09:27, Ryan Schmidt a écrit : Hi Ryan, > If you mean /opt/local/var/macports/software, that's where the compressed > archives of all your installed ports are stored. You are not meant to > interact with this directory manually. To remove an archive from this > directory,

Re: /opt/local/macports/software

On Jan 19, 2015, at 1:59 AM, Akim Demaille wrote: > My SSD is short, and this directory currently holds 4.7GB > of compressed tarballs on my machine. When I run short of > space, I remove it. But why do I have to do that in the > first place? There's autoclean in my config file, couldn't > the

/opt/local/macports/software

Hi, My SSD is short, and this directory currently holds 4.7GB of compressed tarballs on my machine. When I run short of space, I remove it. But why do I have to do that in the first place? There's autoclean in my config file, couldn't there be something equivalent to state "I don't want to keep