gcc-mp-4.8 -march=native fails
Dear all, When I attempt to compile a C program using -march=native I receive a bunch of errors about nonexistent instructions in temporary assembler files. This does not happen without that command. Does anyone have any bright ideas for how to fix this? Has anyone else had this problem and been able to fix it? Sincerely, Watson Ladd ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gcc-mp-4.8 -march=native fails
Le 18 mars 2014 à 07:06, Watson Ladd watsonbl...@gmail.com a écrit : Dear all, When I attempt to compile a C program using -march=native I receive a bunch of errors about nonexistent instructions in temporary assembler files. This does not happen without that command. Does anyone have any bright ideas for how to fix this? Has anyone else had this problem and been able to fix it? You can’t compile with -march=native using gcc. All gcc compilers rely on Apple provided old ‘as’, which is frozen at the last GPL v2 revision (Apple decided to chuck all v3 GPL’d code). This version is so hoary that it does not support neither AVX nor newer extensions. As a result, if you use -march=native with a reasonably modern hardware, GCC will pass AVX instructions to Apple ‘as’ which rejects them as unknown. If you want to use the -march=native switch, use Clang instead (LLVM-AS handles new extensions correctly). Vincent ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: clang memory usage vs. gcc (and OS X 10.8, 10.9, ...)
Hi On Tuesday March 18 2014 08:54:04 James Linder wrote: Somewhat OT so would you mind mailing me directly (unless of interest here) I think it is (for any developer ...) So … what did you do and how? I don't have the exact URLs at hand, but there is a description out there on how to get VMWare or Parallels to accept SL non-server. Basically, there has to be a file identifying the system as SL Server. The file can be removed after booting, and a pre-shutdown script puts it back. Or something like that. Removing it is less important now that there are hardly ASUs left, otherwise you'd get the SL Server updates. So what I did was - clone my boot disk to a dmg with Carbon Copy Cloner (CCC), skipping the largest things I wanted to skip to keep the image small. - convert that dmg to R/W so that I could apply the hacks to turn SL into SL Server at boot - convert that new dmg to a VM image using VirtualBox's VBoxManage tool. I think I went with a .vdi - It is likely that I first created a guest in VirtualBox. But since it has no OS X guest additions, I got a copy of Parallels (VMWare requires 10.7+) and imported the VM in there. That was about all. Takes some time and you need quite a bit of disk space to jungle with, but it worked out fine. The only quirk is that my guest sees 4GB of RAM instead of the 2.5GB I gave it, but maybe that's because the host runs 10.6.8 ... Getting 10.9 into that VM was easy. I cloned my boot disk to an external, and updated that disk to 10.9. Once that was more or less settled (10.9.1 started making a local TimeMachine copy without asking or giving feedback, which of course took ages), I started the 10.6 VM. Parallels has this nice feature that it can mount external devices to the guest when you connect them, so I got my 10.9 boot disk on the VM's desktop. I'd given it a new harddisk before, so all I had to do was start CCC and clone the external 10.9 disk onto the new VM image, and then set to boot the guest off that. A bit surprisingly that just worked -- and I can even clone the VM back onto the external. And that gives us a very easy way to prepare OS X VM images ... I get that Don't Steal OS X kext or whatever it is when I boot the VM, but I consider that I own enough SL licenses to run 2 copies on Apple hardware to be fine legally ... and 10.9 can be run in a VM without the Server version hack. Before I forget: Paragon Software have a tool for making VM images off an existing set-up. I haven't tried it yet, though. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gcc-mp-4.8 -march=native fails
On Tuesday March 18 2014 09:43:57 Vincent Habchi wrote: If you want to use the -march=native switch, use Clang instead (LLVM-AS handles new extensions correctly). Or use -march=native -no-avx , or simply -march=core2 if you insist on having AVX. Note that when your code isn't optimised for using SIMD instructions you'll likely see very little benefit from using the full instruction set. In fact, in the testing I did I got better floating point performance using gcc 4.7 with -march=core2 than with clang 3.3 with -march=native . I *think* clang still doesn't have a (good) auto-vectorisation engine, while gcc's has become quite impressive IMHO. -march=core2 will also give a binary that will execute on just about any Mac since 2010 or so. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gcc-mp-4.8 -march=native fails
Salut René, Le 18 mars 2014 à 10:44, René J.V. Bertin rjvber...@gmail.com a écrit : On Tuesday March 18 2014 09:43:57 Vincent Habchi wrote: If you want to use the -march=native switch, use Clang instead (LLVM-AS handles new extensions correctly). Or use -march=native -no-avx , or simply -march=core2 if you insist on having AVX. -march=core2 precisely avoids AVX (AVX was introduced on the next ‘tock’, Nehalem). You can still get SSE4.2 with -msse4.2 with the old Apple ‘as’ though. Note that when your code isn't optimised for using SIMD instructions you'll likely see very little benefit from using the full instruction set. In fact, in the testing I did I got better floating point performance using gcc 4.7 with -march=core2 than with clang 3.3 with -march=native . I *think* clang still doesn't have a (good) auto-vectorisation engine, while gcc's has become quite impressive IMHO. That’s not what the latest Phoronix tests seemed to point out (but with clang 3.4). http://www.phoronix.com/scan.php?page=articleitem=llvm34_gcc49_compilersnum=1 Bonne journée ! Vincent ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gcc-mp-4.8 -march=native fails
That’s not what the latest Phoronix tests seemed to point out (but with clang 3.4). http://www.phoronix.com/scan.php?page=articleitem=llvm34_gcc49_compilersnum=1 I agree. Clang and GCC are pretty much neck and neck these days, as far as my tests go. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
Hi I’ve given Homebrew a quick try in a VM and it doesn’t seem that different in functionality. (Except that I do wish we had something like Homebrew-cask.) So, other than the coolness factor (which I guess comes partly from being “the new thing”, and partly from using Github for all development and distribution), what else is there? Try to keep it factual and based on your own experiences using/administering both, please. I can comment on where I think homebrew is lacking based on when I recently tried it, if that helps: - homebrew's uninstall will remove packages that still have dependents without warning you, leaving broken packages - It will not automatically detect such broken packages (like MacPorts does with rev-upgrade). Instead, you'll have to manually figure out which packages are broken and rebuild them. - homebrew doesn't try as hard as MacPorts to make builds reproducible. If you install vim, it'll use the first python available. When that's system python it uses that, if it's homebrew python it'll use that (and if its MacPorts python, well you get the idea) - homebrew doesn't have privilege separation and sandboxing like MacPorts does (they make a case that sudo is bad, so they can't use any of those, making their setup arguable less secure than ours). And those were just the ones I didn't even have to start thinking about, I'm sure there's more. -- Clemens Lang ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gcc-mp-4.8 -march=native fails
On Tuesday March 18 2014 10:31:44 you wrote: That’s not what the latest Phoronix tests seemed to point out (but with clang 3.4). http://www.phoronix.com/scan.php?page=articleitem=llvm34_gcc49_compilersnum=1 I agree. Clang and GCC are pretty much neck and neck these days, as far as my tests go. Seems like I'll have to run my own tests then, sometime soon. A bit OT, but is clang the reason libeigen doesn't currently build on OS X 10.9? ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gcc-mp-4.8 -march=native fails
On 18/03/14 11:14, Vincent Habchi wrote: Le 18 mars 2014 à 12:01, René J.V. Bertin rjvber...@gmail.com a écrit : A bit OT, but is clang the reason libeigen doesn't currently build on OS X 10.9? Er… I think eigen3 was building fine with clang, except the BLAS part which requires a Fortran compiler. ... and for fortran support, it is fine to mix gfortran from any gcc compiler, with clang, as there are no issues with mixing c++ runtimes (as obviously fortran doesn't need this). Chris V. ___ 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
eigen
On Mar 18, 2014, at 12:14, Vincent Habchi wrote: Le 18 mars 2014 à 12:01, René J.V. Bertin rjvber...@gmail.com a écrit : A bit OT, but is clang the reason libeigen doesn't currently build on OS X 10.9? Er… I think eigen3 was building fine with clang, except the BLAS part which requires a Fortran compiler. In fact, I'm more interested in eigen 2, required by Calligra ... R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gcc-mp-4.8 -march=native fails
Le 18 mars 2014 à 12:28, Chris Jones jon...@hep.phy.cam.ac.uk a écrit : ... and for fortran support, it is fine to mix gfortran from any gcc compiler, with clang, as there are no issues with mixing c++ runtimes (as obviously fortran doesn't need this). That’s fortunate, because otherwise we’d have a hard time with Atlas… ;) V. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: glib user_data_dir set to /opt/local/share
On Mar 18, 2014, at 00:30, Jonathan Koren wrote: I’m on Mavricks with MacPorts 2.2.1 I recently upgraded the meld port (@1.8.4), and now when ever I try to run it, it blows up with an OSError. (OSError: [Errno 13] Permission denied: '/opt/local/share/meld/recent-NbPmhP.meldcmp’ ) Looking into it, it appears that the problem is that meld wants to write a tempfile to the user_data_dir specified by glib. (See line 53 in /opt/local/lib/meld/meld/recent.py ) I don’t believe user_data_dir is set correctly. This call is intended to get a directory for user-specific data, not a system-wide directory. (See https://developer.gnome.org/glib/2.37/glib-Miscellaneous-Utility-Functions.html#g-get-user-data-dir). I’m not sure which glib meld is using, but I’ve got glib1 @1.2.10 and glib2 @2.38.2 According to “port rdeps meld|grep glib”, it’s using glib2. 0) Is anyone else seeing this? I suspect this is happening for all ports that rely on glib. 1) This needs to be fixed. And I suspect the fix needs to be in the underlying glib port 2) Does anyone know a work around, beyond setting /opt/local/share to be world writeable? This is the first I’ve heard of the problem. If we need to change something in the glib2 port, please let me know what. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
Marketing. Ease of use. Davor Cubranic cubra...@stat.ubc.ca wrote: On Mar 12, 2014, at 2:12 PM, Art McGee amc...@gmail.com wrote: The problem is that the presentation of the case for supporting MacPorts was confusing and unconvincing, so usage statistics are not going to help in that matter. I’ve been wondering why Homebrew has such huge momentum and mindshare these days. In random places on the web I’ve seen people imply that it’s better/more reliable than Macports. (The only concrete example was terribly outdated, about TexLive version about four years ago.) I’ve given Homebrew a quick try in a VM and it doesn’t seem that different in functionality. (Except that I do wish we had something like Homebrew-cask.) So, other than the coolness factor (which I guess comes partly from being “the new thing”, and partly from using Github for all development and distribution), what else is there? Try to keep it factual and based on your own experiences using/administering both, please. Davor ___ 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: usage numbers for macports vs. homebrew?
On Mar 17, 2014, at 22:42, Davor Cubranic wrote: I’ve given Homebrew a quick try in a VM and it doesn’t seem that different in functionality. (Except that I do wish we had something like Homebrew-cask.) For those of us not familiar with Homebrew: what is this feature? what does it do? ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
On Tue, Mar 18, 2014 at 8:28 AM, Ryan Schmidt ryandes...@macports.orgwrote: On Mar 17, 2014, at 22:42, Davor Cubranic wrote: I've given Homebrew a quick try in a VM and it doesn't seem that different in functionality. (Except that I do wish we had something like Homebrew-cask.) For those of us not familiar with Homebrew: what is this feature? what does it do? They basically have a separate repository for stuff that comes in binary form on DMGs and/or in .pkg/.mpkg installers. They even allow for installing MacPorts this way: https://lists.macosforge.org/pipermail/macports-users/2013-December/034213.html ___ 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: usage numbers for macports vs. homebrew?
On Mar 18, 2014, at 1:28pm, Ryan Schmidt-24 wrote: I’ve given Homebrew a quick try in a VM and it doesn’t seem that different in functionality. (Except that I do wish we had something like Homebrew-cask.) For those of us not familiar with Homebrew: what is this feature? what does it do? Homebrew provides two types of binary packages: Bottles and Casks. Bottles are built automatically by a Test Bot which monitors all the incoming Pull Requests: if a formula includes bottling instructions, the tarballs are uploaded to SourceForge and downloaded automatically on install. Casks are not part of the main HomeBrew project and you must “tap” and install them manually: their recipes are very simple and allow to install comfortably the official installers from the Terminal. In case of a .dmg, for instance, its contents is un/mounted and linked into your local ~/Applications folder. In the case of a .pkg file, its bill-of-materials is analysed and you can uninstall its contents at once: this is a useful feature that Apple’s own 'pkgutil —unlink' doesn’t offer anymore. Guido — https://github.com/gui-dos/Guigna ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
database?
Just curious. What's the story about the absence of the ports database for a couple of days it seems? Thanks. Comer ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: database?
Apple infrastructure is moving things around, and putting them back together. On Mar 18, 2014, at 13:14, Comer Duncan comer.dun...@gmail.com wrote: Just curious. What's the story about the absence of the ports database for a couple of days it seems? ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
On Tue, Mar 18, 2014 at 6:42 AM, Clemens Lang c...@macports.org wrote: - homebrew doesn't try as hard as MacPorts to make builds reproducible. If you install vim, it'll use the first python available. When that's system python it uses that, if it's homebrew python it'll use that (and if its MacPorts python, well you get the idea) I'm pretty sure they consider this a strength. I already have Python! Why is MacPorts trying to install a new version!? - homebrew doesn't have privilege separation and sandboxing like MacPorts does (they make a case that sudo is bad, so they can't use any of those, making their setup arguable less secure than ours). I'm always conflicted on this one. On the one hand, most users are probably the primary user on their machine, so installing to /usr/local without privledges is probably not the worst thing in the world. On the other, security is a chain of links and this is definitely one that has been weakened. It would not be the worst thing in the world to eliminate the need for root in MacPorts. I know there have been changes in the past related to this, and I'm not sure what the current state of things is. I think for the most part, you can install an un-privledged MacPorts to a non-default location. Overall, I feel like HomeBrew came around when MacPorts was established to the point where enough people were using it that there were plenty of complaints about one feature or another and HomeBrew was able to capitalize on that. GitHub was the new exciting place to be as well. It's unfortunate that a direct attack on MacPorts was the best way to attract a userbase, but I have to feel it helped them more than hurt. (The slogan and a port that installed from SVN head in order to stay up to date were the things that turned me off when I gave it a chance.) -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
On Mar 18, 2014, at 1:36 PM, Arno Hautala a...@alum.wpi.edu wrote: On Tue, Mar 18, 2014 at 6:42 AM, Clemens Lang c...@macports.org wrote: - homebrew doesn't try as hard as MacPorts to make builds reproducible. If you install vim, it'll use the first python available. When that's system python it uses that, if it's homebrew python it'll use that (and if its MacPorts python, well you get the idea) I'm pretty sure they consider this a strength. I already have Python! Why is MacPorts trying to install a new version!? in fact, the reason I /first/ started using MacPorts (which had a different name at that time ;-) ), was because it would use the system provided perl/python/other stuff. Of course, time and experience proved that things work better without having to scramble and fix things any time Apple issues an update the changes things (or is broken in some way). Overall, I feel like HomeBrew came around when MacPorts was established to the point where enough people were using it that there were plenty of complaints about one feature or another and HomeBrew was able to capitalize on that. GitHub was the new exciting place to be as well. GitHub plus not having to learn/use tcl seem to be the major features that pull people/create interest from what I've seen (but I haven't looked in on it in a while). -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
On Tue, Mar 18, 2014 at 1:36 PM, Arno Hautala a...@alum.wpi.edu wrote: On Tue, Mar 18, 2014 at 6:42 AM, Clemens Lang c...@macports.org wrote: - homebrew doesn't try as hard as MacPorts to make builds reproducible. If you install vim, it'll use the first python available. When that's system python it uses that, if it's homebrew python it'll use that (and if its MacPorts python, well you get the idea) I'm pretty sure they consider this a strength. I already have Python! Why is MacPorts trying to install a new version!? They *used* to consider that a feature, and are still slowly changing things over; they've learned the hard way why nobody else works that way. -- 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: usage numbers for macports vs. homebrew?
homebrew will or will appear to get a user to their desired state of “I just need X installed” faster than MacPorts. Their users simply don’t care about what MacPorts does: it isn’t that homebrew has a feature, it’s that homebrew won’t seem to get in the way. On Mar 18, 2014, at 13:36, Arno Hautala a...@alum.wpi.edu wrote: - homebrew doesn't try as hard as MacPorts to make builds reproducible. If you install vim, it'll use the first python available. When that's system python it uses that, if it's homebrew python it'll use that (and if its MacPorts python, well you get the idea) I'm pretty sure they consider this a strength. I already have Python! Why is MacPorts trying to install a new version!? ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
Hi, I'm pretty sure they consider this a strength. I already have Python! Why is MacPorts trying to install a new version!? Certainly, but it leads to situations such as https://github.com/Valloric/YouCompleteMe/issues/8. They might not have to deal with python because they're not managing it, but others then have to do it for them. - homebrew doesn't have privilege separation and sandboxing like MacPorts does (they make a case that sudo is bad, so they can't use any of those, making their setup arguable less secure than ours). I'm always conflicted on this one. On the one hand, most users are probably the primary user on their machine, so installing to /usr/local without privledges is probably not the worst thing in the world. On the other, security is a chain of links and this is definitely one that has been weakened. This isn't necessarily about writing to /usr/local without privileges, but about using an unprivileged user. In homebrew, a build system can put stuff in your $HOME, read your files, etc. In MacPorts (unless you configure a non-root installation), none of these are possible. Making /usr/local writable for a user is a bad choice on a multi-user system, though, because /usr/local/bin is in the default PATH of every user -- an exploit running as that user can create /usr/local/bin/sudo and the next time a (possibly different!) user runs sudo and types his password, that security problem has turned into a root exploit. Homebrew could create a brew user and require all operations to be run as sudo -u brew brew ..., but there is your sudo again... It would not be the worst thing in the world to eliminate the need for root in MacPorts. I know there have been changes in the past related to this, and I'm not sure what the current state of things is. I think for the most part, you can install an un-privledged MacPorts to a non-default location. You can do that, you can even install an un-privileged MacPorts to /opt/local, I'm just saying that's not necessarily a good idea, especially not if multiple users have /opt/local/bin in their PATH. There is a reason why other package management systems on Linux/BSD/etc. require root privileges, and I don't thing we should just ignore those reasons. We could however still reduce the number of commands we run as root, e.g. by using something similar to fakeroot. -- Clemens Lang ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
Hi, homebrew will or will appear to get a user to their desired state of “I just need X installed” faster than MacPorts. Their users simply don’t care about what MacPorts does: it isn’t that homebrew has a feature, it’s that homebrew won’t seem to get in the way. Sure, I'd consider that to be the difference between package management and build automation. I agree that MacPorts should try hard(er) to get out of the way of a user, though. -- Clemens Lang ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
/usr/include/MacPorts.h
Not much to do with MacPorts (I hope), but I stumbled across a /usr/include/MacTypes.h file today on my 10.9.2 VM, dated March 17th around 09h (=AM). I noticed it because of clashes in the Boolean typedef with the X11 headers that I never had, at least not before I installed Xcode 5.1 . My VM wasn't running at the time in question. Any idea why that file ended up in /usr/include instead of remaining put deep inside one of Apple's frameworks? R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: /usr/include/MacPorts.h
On Tue, Mar 18, 2014 at 2:10 PM, René J.V. Bertin rjvber...@gmail.comwrote: Not much to do with MacPorts (I hope), but I stumbled across a /usr/include/MacTypes.h file today on my 10.9.2 VM, dated March 17th around 09h (=AM). I noticed it because of clashes in the Boolean typedef with the X11 headers that I never had, at least not before I installed Xcode 5.1 . My VM wasn't running at the time in question. Any idea why that file ended up in /usr/include instead of remaining put deep inside one of Apple's frameworks? pyanfar:10002 Z$ pkgutil --file-info /usr/include/MacTypes.h volume: / path: /usr/include/MacTypes.h pkgid: com.apple.pkg.DevSDK pkg-version: 10.8.0.0.1.1306847324 install-time: 1390449425 uid: 0 gid: 0 mode: 644 -- 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: usage numbers for macports vs. homebrew?
On Mar 18, 2014, at 3:01 PM, Ryan Schmidt ryandes...@macports.org wrote: On Mar 18, 2014, at 12:54, Daniel J. Luke dl...@geeklair.net wrote: GitHub plus not having to learn/use tcl seem to be the major features that pull people/create interest from what I've seen (but I haven't looked in on it in a while). …right, instead of you have to learn/use ruby. Six of one… 'ruby' has been pretty hot for a while and 'tcl' (and perl, and php) is considered lame. (note that I'm not saying I personally agree with that assessment). -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
On Mar 18, 2014, at 12:54, Daniel J. Luke dl...@geeklair.net wrote: GitHub plus not having to learn/use tcl seem to be the major features that pull people/create interest from what I've seen (but I haven't looked in on it in a while). …right, instead of you have to learn/use ruby. Six of one… ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
They seemed to acquire a lot of traction on the basis of marketing; specifically: - Truthiness (an assortment of “advantages” that turned out not to be, claims that ignored technical accuracy and nuance, and claims quite simply rooted in ignorance), and - Outright negative advertising (“MacPorts driving you to drink?”) It’s a new brand of open-source that I don’t really recognize and can’t say I like; it detracts from the community’s ability to collaborate productivity, and undermines the objective, rational honesty that should be at the core of any engineering endeavor. I don’t really know how to raise the level of discourse; it’s far more expensive to counter to truthiness and negativity than it is to generate it in the first place. Nowadays, people who have never even used MacPorts will repeat verbatim the negative advertising propagated by Homebrew. I find the whole thing distasteful. -landonf On Mar 18, 2014, at 8:25 AM, Jeremy Lavergne jer...@lavergne.gotdns.org wrote: Marketing. Ease of use. Davor Cubranic cubra...@stat.ubc.ca wrote: On Mar 12, 2014, at 2:12 PM, Art McGee amc...@gmail.com wrote: The problem is that the presentation of the case for supporting MacPorts was confusing and unconvincing, so usage statistics are not going to help in that matter. I’ve been wondering why Homebrew has such huge momentum and mindshare these days. In random places on the web I’ve seen people imply that it’s better/more reliable than Macports. (The only concrete example was terribly outdated, about TexLive version about four years ago.) I’ve given Homebrew a quick try in a VM and it doesn’t seem that different in functionality. (Except that I do wish we had something like Homebrew-cask.) So, other than the coolness factor (which I guess comes partly from being “the new thing”, and partly from using Github for all development and distribution), what else is there? Try to keep it factual and based on your own experiences using/administering both, please. Davor ___ 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 ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
On Tue, Mar 18, 2014 at 2:27 PM, Landon Fuller land...@macports.org wrote: They seemed to acquire a *lot* of traction on the basis of marketing; specifically: - Truthiness (an assortment of advantages that turned out not to be, claims that ignored technical accuracy and nuance, and claims quite simply rooted in ignorance), and - Outright negative advertising (MacPorts driving you to drink?) It's a new brand of open-source that I don't really recognize and can't say I like; it detracts from the community's ability to collaborate productivity, and undermines the objective, rational honesty that should be at the core of any engineering endeavor. I don't really know how to raise the level of discourse; it's far more expensive to counter to truthiness and negativity than it is to generate it in the first place. Nowadays, people who have never even used MacPorts will repeat verbatim the negative advertising propagated by Homebrew. I find the whole thing distasteful. -landonf +1 to the sentiment. However, perhaps we should take a page from their book. Look at the homebrew homepage (http://brew.sh/) * It would be nice a similar minimalist, here is what macports does for you landing page. * A one line copy-and-paste install option to get a new user going would be nice, too. It could check for and prompt the user for XCode, etc before actually installing. I assume this is what theirs does. * A simple 'port create url' that would create a typical Portfile (configure / make / make install) in a auto-generated local location (and properly setup sources.conf) and then open the new portfile in Editor (perhaps with some helpful comments on things that might need tweaking) A fair and concise comparison of the approaches a would be nice to have somewhere beyond this mailing list. Alternative, a 'homebrew porting layer' (use homebrew formula in MP with minimal / no modification) might help, but I don't imagine anyone is looking to take on that amount of work. I also don't think we've done enough to publicize the phenomenal impact the build bots have on a typical install scenario -- and to emphasize the you need to use the defaults if you want binary package usage. Just my 2c. I do with they'd drop their slogan.. Alternatively, childish we could counter with '(Hungover on|Bad batch of) Homebrew?' /childish - Eric ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
On Mar 18, 2014, at 3:57 PM, Eric A. Borisch ebori...@macports.org wrote: However, perhaps we should take a page from their book. Look at the homebrew homepage (http://brew.sh/) * It would be nice a similar minimalist, here is what macports does for you landing page. * A one line copy-and-paste install option to get a new user going would be nice, too. It could check for and prompt the user for XCode, etc before actually installing. I assume this is what theirs does. * A simple 'port create url' that would create a typical Portfile (configure / make / make install) in a auto-generated local location (and properly setup sources.conf) and then open the new portfile in Editor (perhaps with some helpful comments on things that might need tweaking) I personally think this is a great idea. Not that I am in a position to enact such an idea :-) I also don't think we've done enough to publicize the phenomenal impact the build bots have on a typical install scenario -- and to emphasize the you need to use the defaults if you want binary package usage. Agreed. -landonf___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
NRPE wrapper is loaded but not NRPE itself
Hi, We use MacPorts to install the NRPE client on most of our OS X boxes, but I have a couple of boxes that have a weird behaviour. After a reboot, the nrpe.wrapper is loaded: # ps auxwww | grep nrpe root 556 0.0 0.0 2467372 1208 ?? Rs4:31PM 0:00.01 /opt/local/bin/daemondo --label=nrpe --start-cmd /opt/local/etc/LaunchDaemons/org.macports.nrpe/nrpe.wrapper start ; --stop-cmd /opt/local/etc/LaunchDaemons/org.macports.nrpe/nrpe.wrapper stop ; --restart-cmd /opt/local/etc/LaunchDaemons/org.macports.nrpe/nrpe.wrapper restart ; --pid=none But NRPE itself is not. I have to do port unload nrpe; port load nrpe to get it to start. It only happens on a couple of workstations, the others are fine. Both running OS X 10.8.5 and MacPorts 2.2.0. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
On Mar 18, 2014, at 12:57 PM, Eric A. Borisch ebori...@macports.org wrote: However, perhaps we should take a page from their book. Look at the homebrew homepage (http://brew.sh/) * It would be nice a similar minimalist, here is what macports does for you landing page. * A one line copy-and-paste install option to get a new user going would be nice, too. It could check for and prompt the user for XCode, etc before actually installing. I assume this is what theirs does. * A simple 'port create url' that would create a typical Portfile (configure / make / make install) in a auto-generated local location (and properly setup sources.conf) and then open the new portfile in Editor (perhaps with some helpful comments on things that might need tweaking) I’m with Landon: I like this idea too. I think a lot of the perception of MacPorts comes from a dated page design and poor functionality in the website, coupled with an overly verbose and less-than-useful sequence of messages during port operations. Some of the work that Clemens has done with progress meters, etc, has taken us a few steps forward. For the website, I think the following would help: * Updated design, colors, etc. * More integrated web app with better access to ports, etc. And for the port client, the following: * More use of ANSI colors in the log messages (used to distinguish the start of each port, etc., and maybe with different colors for different phases)… all tunable, of course, for those who don’t like color. * A careful review of what we emit, and when (we don’t clearly distinguish when a port was loaded from a build-bot vs built by hand, unless you know what to look for), etc. * Spinning ANSI indicators during loading operations, etc, where we can. We could do this in loading, activation, etc. The hardest time would likely be in building and configuring, where we don’t have any hooks back from the build. Yeah, in the end it’s all just glitz and glitter, unfortunately, but it does lead to perception… I do with they'd drop their slogan.. Alternatively, childish we could counter with '(Hungover on|Bad batch of) Homebrew?' /childish I reiterate what somebody else said (maybe Landon) that their approach to this really seems to go against open source and open philosophy and spirit. It’s downright mean-spirited. Rather than make me want to collaborate with them, it just makes me pissed off, especially as they’re so wrong. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
* More use of ANSI colors in the log messages (used to distinguish the start of each port, etc., and maybe with different colors for different phases)… all tunable, of course, for those who don’t like color. We should also take a look at `port search', which can currently produce enormous amounts of output. Rather than printing more than, say, 10 lines, we should just print the port names in columns like homebrew does. * A careful review of what we emit, and when (we don’t clearly distinguish when a port was loaded from a build-bot vs built by hand, unless you know what to look for), etc. Agreed. We should also remove some of the clean messages that might be unexpected (when the thing that really gets cleaned is the port loaded from the registry, i.e. when uninstalling). * Spinning ANSI indicators during loading operations, etc, where we can. We could do this in loading, activation, etc. The hardest time would likely be in building and configuring, where we don’t have any hooks back from the build. What you probably haven't seen because most servers to HTTP/1.1: The progress bar actually comes in a progress indicator variant aswell that can be used for that. Activation is certainly on my todo list of things to display a progress bar for. For configure/build/etc I was thinking about writing simple parsers for the formats emitted by some build systems that give progress info (e.g., cmake, ninja). We might even try to estimate progress using the number of lines printed and a web-based database of the number of lines generated during build/configure/destroot of a port. It might be erratic, but it would still give *some* indication of the duration of the build. Also, we really need to work on the dependency calculation stuff to print a plan of action before starting and print progress information (building port x of y) while building. Yeah, in the end it’s all just glitz and glitter, unfortunately, but it does lead to perception… Yeah, apparently people call that being user-friendly. Well, if that's the case, let's do that. -- Clemens Lang ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
On Mar 18, 2014, at 16:35, Clemens Lang wrote: * A careful review of what we emit, and when (we don’t clearly distinguish when a port was loaded from a build-bot vs built by hand, unless you know what to look for), etc. Agreed. We should also remove some of the clean messages that might be unexpected (when the thing that really gets cleaned is the port loaded from the registry, i.e. when uninstalling). I thought I had filed a ticket for that already but I can’t find it now. I also found it confusing that sometimes (on some of my systems, but not on others; I don’t know why) each port install results in four “Cleaning” messages. * Spinning ANSI indicators during loading operations, etc, where we can. We could do this in loading, activation, etc. The hardest time would likely be in building and configuring, where we don’t have any hooks back from the build. What you probably haven't seen because most servers to HTTP/1.1: The progress bar actually comes in a progress indicator variant aswell that can be used for that. Activation is certainly on my todo list of things to display a progress bar for. Good idea. For configure/build/etc I was thinking about writing simple parsers for the formats emitted by some build systems that give progress info (e.g., cmake, ninja). Yes. I worried it might be confusing to have progress indicators for some builds but not others, due only (invisible to the user) to the particular build system being used. But your next idea could overcome that: We might even try to estimate progress using the number of lines printed and a web-based database of the number of lines generated during build/configure/destroot of a port. It might be erratic, but it would still give *some* indication of the duration of the build. Also, consider the OS X startup progress bar, back when OS X had one: originally it was very accurate, but by Tiger it had been changed to just advance at a more or less constant rate regardless what was happening; the boot process frequently would complete before the progress bar had gotten to the end. Just some indication that something is happening is useful to the user, even if it’s not completely accurate. muniversal builds can also be used to inform a progress bar. Also, we really need to work on the dependency calculation stuff to print a plan of action before starting and print progress information (building port x of y) while building. That would be nice too. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
On 2014-03-18 22:09, James Berry wrote: For the website, I think the following would help: * Updated design, colors, etc. That has always been the plan, but it just needs someone to do it. I think the last update on the website design dates back to 2007... I would even replace the website with the Trac wiki front page altogether, also getting rid of one of the duplicated installation instructions on website/wiki/guide. However, some users seem to like the port search the current website provides (which is broken right now since the server migration). * More integrated web app with better access to ports, etc. Which could also be integrated with the upcoming statistics gathering in the next MacPorts release. Rainer ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
On 18 Mar 2014, at 23:06 , Rainer Müller rai...@macports.org wrote: also getting rid of one of the duplicated installation instructions on website/wiki/guide. Well, that’s another big endeavour, because we finally should find a way to condense the information from all three sources + man pages into ONE online-resource. * More integrated web app with better access to ports, etc. Which could also be integrated with the upcoming statistics gathering in the next MacPorts release. Well, the statistics gathering is something I would also like to see (awaiting the new release impatiently), but it’s a little worrisome, because it has a touch of NSA activity! :-( ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
Pretty sure It’s opt-in. So it’s the antithesis of NSA :-p On Mar 18, 2014, at 18:12, mk-macpo...@techno.ms wrote: Well, the statistics gathering is something I would also like to see (awaiting the new release impatiently), but it’s a little worrisome, because it has a touch of NSA activity! :-( ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
On 18 Mar 2014, at 23:15 , Jeremy Lavergne jer...@lavergne.gotdns.org wrote: Pretty sure It’s opt-in. So it’s the antithesis of NSA :-p I am aware of that, of course. ;-) ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
On Tue, Mar 18, 2014 at 5:35 PM, Clemens Lang c...@macports.org wrote: * More use of ANSI colors in the log messages (used to distinguish the start of each port, etc., and maybe with different colors for different phases)... all tunable, of course, for those who don't like color. We should also take a look at `port search', which can currently produce enormous amounts of output. Rather than printing more than, say, 10 lines, we should just print the port names in columns like homebrew does. No! Homebrew's search functionality is my biggest problem with it. The columns you mentioned make it hard to read because it makes it harder to see how they are sorted. The alphabetization seems to be in order by column at first, but then at some random row the alphabetical order will switch over to the next column over, instead of continuing down that same column, with no marker to show where it happened, so you really have to be paying attention to find where something is in a screen of search output from Homebrew. Also I find it useful that MacPorts prints the port descriptions when doing `port search`; to get equivalent functionality in Homebrew, you have to tap the brew-desc repo https://github.com/telemachus/homebrew-desc, and even then you have to run the `brew desc` command separately to get the descriptions, and plus you have to constantly update `brew-desc` as well, because the descriptions are not maintained in the main repository. Besides it is already possible to trim down the output of `port search`: you can just use the `-q` flag. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
Hi, No! Homebrew's search functionality is my biggest problem with it. The columns you mentioned make it hard to read because it makes it harder to see how they are sorted. The alphabetization seems to be in order by column at first, but then at some random row the alphabetical order will switch over to the next column over, instead of continuing down that same column, with no marker to show where it happened, so you really have to be paying attention to find where something is in a screen of search output from Homebrew. Nobody said we'd have to write a weird implementation. Also I find it useful that MacPorts prints the port descriptions when doing `port search` And I'm all for keeping that if there are less than, say 10 search results. When there are more than 10 results, we could print the names only along with instructions on how to get full results, should a user really want to read through all the descriptions (how often do you open the second page on Google again?). I also think the output could be improved to waste less space and use color. For more than 10 results, I think port -q search git | while read a; read b; read c; do printf %-28s %-28s %-28s\n $a $b $c; done | grep -iE --color '^|git' is a pretty good shot at what I'd like to see (optimized to 80 columns terminal and this specific query). For less than 10 results, the following looks nice to my eyes: $ port search git portversion description --- --- babl-devel 0.1.11-20140305 Babl is a library for dynamically handling pixel formats and managing conversions between them. This is the development version based on a recent snapshot of upstream redgit/red master. bitcoin 0.8.6client user interface for a peer-to-peer diredgit/redal currency (yes, we also print useless matches like these) etc. This might help, but given the amount of information we display (name, version, categories, description) it might not work very well either. I'd rather remove some of the information by default and improve the search results by matching for names first (and if no port names match, print a message and automatically search descriptions). If you don't think that's a good idea take a look at the results of `port search git'. Besides it is already possible to trim down the output of `port search`: you can just use the `-q` flag. I never said we should remove this way to print the results. I was just suggesting to switch the default to be more useful to the casual user (i.e. the one who doesn't know about port -q search). -- Clemens Lang ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
On Tue, Mar 18, 2014 at 5:43 PM, Ryan Schmidt ryandes...@macports.org wrote: Also, consider the OS X startup progress bar, back when OS X had one: originally it was very accurate, but by Tiger it had been changed to just advance at a more or less constant rate regardless what was happening; the boot process frequently would complete before the progress bar had gotten to the end. Just some indication that something is happening is useful to the user, even if it’s not completely accurate. I thought I remembered hearing that it worked by timing the previous boot and using that to calculate the current boot progress. That's fairly similar to the line counting idea. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
On Tue, Mar 18, 2014 at 7:48 PM, Clemens Lang c...@macports.org wrote: For less than 10 results, the following looks nice to my eyes: gt; port search git portversion description --- --- babl-devel 0.1.11-20140305 Babl is a library for dynamically handling pixel formats and managing conversions between them. This is the development version based on a recent snapshot of upstream redgit/red master. bitcoin 0.8.6client user interface for a peer-to-peer diredgit/redal currency (yes, we also print useless matches like these) etc. How about: babl-devel 0.1.11-20140305 Babl is a library for dynamically handling pixel formats and ... bitcoin 0.8.6client user interface for a peer-to-peer diredgit/redal currency ... -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
Yeah, I think tcl is one of the things that confounds people the most. Not really learned that much anymore. I learned it long ago for CAD tools from IBM. But really, both Homebrew and Macports are domain specific languages from the port writers perspective. You've got to learn it anyway. People in my CS department lab would go to Homebrew first and then come ask me how to install MacPorts since we have much better package selection. For instance: If I type brew search tex, it recommends installing MacTex instead of a from-source install. LAME. Mark --Mark ___ Mark E. Anderson e...@emer.net On Tue, Mar 18, 2014 at 3:04 PM, Daniel J. Luke dl...@geeklair.net wrote: On Mar 18, 2014, at 3:01 PM, Ryan Schmidt ryandes...@macports.org wrote: On Mar 18, 2014, at 12:54, Daniel J. Luke dl...@geeklair.net wrote: GitHub plus not having to learn/use tcl seem to be the major features that pull people/create interest from what I've seen (but I haven't looked in on it in a while). ...right, instead of you have to learn/use ruby. Six of one... 'ruby' has been pretty hot for a while and 'tcl' (and perl, and php) is considered lame. (note that I'm not saying I personally agree with that assessment). -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ 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: usage numbers for macports vs. homebrew?
On Tue, Mar 18, 2014 at 3:27 PM, Landon Fuller land...@macports.org wrote: MacPorts driving you to drink? I hate that. Turned me off the whole project. --Mark ___ Mark E. Anderson e...@emer.net ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
At 12:48 AM +0100 3/19/14, Clemens Lang wrote: [...] And I'm all for keeping that if there are less than, say 10 search results. When there are more than 10 results, ... Much of the time, the volume of search results is inflated due to perl, python and php subports. (Eg, search for 'sqlite'.) The problem is worse (for new users) as the results are sorted strictly in alphabetical order--you may not realize that py*-apsw, py*-spatialite and py*-sqlite are repeated for py24, py25, py26 and py27. It would be no small improvement to suppress the 'duplicates'. Let the user find out which versions are supported when they ask for detailed information about the port. Craig ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
At 11:06 PM +0100 3/18/14, Rainer Müller wrote: [...] I would even replace the website with the Trac wiki front page altogether, also getting rid of one of the duplicated installation instructions on website/wiki/guide. I understand that the next release of MacPorts will check for a correct installation of (1)XCode, (2)it's Command Line Tools and (3)that it's license has been accepted, right? This will be _huge_ step forward--folks now expect instant gratification. Download an installer .dmg and BAM--done. Our 'extra steps', seem to trip up at least half our new users. A specific problem with http://www.macports.org/install.php is that we give generic guidance for installing XCode and the Command Line Tools while the process is rather different for specific versions. Just as we have different .pkg installers for Mavericks, Mountain Lion and Lion, we should have specific corresponding instructions for the remaining steps (with screen shots). Craig ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
On Tuesday, March 18, 2014, Clemens Lang c...@macports.org wrote: Also, we really need to work on the dependency calculation stuff to print a plan of action before starting and print progress information (building port x of y) while building. I wrote a little script for myself that goes and queries packages.macports.org and determines if a port will be built or use a package; it spits out a dot graph of dependencies colored by which is going to happen. Useful for giving a broad stroke view of how long an operation will take. I would think something similar would be nice to see when starting an operation... - Eric ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
On Tue, Mar 18, 2014 at 9:39 PM, Craig Treleaven ctrelea...@cogeco.cawrote: Our 'extra steps', seem to trip up at least half our new users. Another big one would be handling major OS upgrades more cleanly. I think the two issues are that MacPorts detects certain configurations upon install and generally all ports need to be rebuilt. Making MacPorts detect the OS upgrade, re-detecting and reconfiguring as necessary, and then handling the rebuild would solve a lot. Plus, it'd be nice if the buildbot was setup on the new OS prior to release. It's a pain that MacPorts doesn't support the latest OS until a few days / weeks after it's out. -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
On Tue, Mar 18, 2014 at 9:56 PM, Eric A. Borisch ebori...@macports.orgwrote: I wrote a little script for myself that goes and queries packages.macports.org and determines if a port will be built or use a package; it spits out a dot graph of dependencies colored by which is going to happen. I'd love to see that. Is the script available? -- arno s hautala/-| a...@alum.wpi.edu pgp b2c9d448 ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
On Mar 18, 2014, at 19:02, Arno Hautala a...@alum.wpi.edu wrote: Another big one would be handling major OS upgrades more cleanly. I think the two issues are that MacPorts detects certain configurations upon install and generally all ports need to be rebuilt. Making MacPorts detect the OS upgrade, re-detecting and reconfiguring as necessary, and then handling the rebuild would solve a lot. One of the things that would make even a manual rebuild much more convenient is if MacPorts allowed a port to be “requested” even if it is not installed. (I think I recall that the Debian package manager works in a way like this.) Then the upgrade process would be closer to uninstall * install requested This would also be useful in cases like this where a port is broken (can't be fetched/built/installed); I would like to be able to have a port requested-but-not-installed as a reminder to install it when it is no longer broken. OS upgrades are one of the ways ports end up broken, too. (If this feature were to exist, it should also remember what variants were requested; I don't know whether the requested-state information currently includes this but I would assume not.) -- Kevin Reid http://switchb.org/kpreid/ ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
This mostly already exists: it’s currently only for packages that are installed. port echo requested port setrequested … Presently, to get your between-installs behavior, you’d dump the output of echo requested to a file then read it back in. Hilariously, our Migration page (!!! this is something that should go away !!!) breaks even this! There’s the tiny after-the-fact note you notice once you’ve lost all the information that “oh, I could have done requested instead of everything. On Mar 18, 2014, at 23:11, Kevin Reid kpr...@switchb.org wrote: One of the things that would make even a manual rebuild much more convenient is if MacPorts allowed a port to be “requested” even if it is not installed. (I think I recall that the Debian package manager works in a way like this.) Then the upgrade process would be closer to uninstall * install requested This would also be useful in cases like this where a port is broken (can't be fetched/built/installed); I would like to be able to have a port requested-but-not-installed as a reminder to install it when it is no longer broken. OS upgrades are one of the ways ports end up broken, too. (If this feature were to exist, it should also remember what variants were requested; I don't know whether the requested-state information currently includes this but I would assume not.) ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
