Re: /opt/local/macports/software
Hi, On 20/01/15 02:49, Craig Treleaven wrote: At 8:20 PM + 1/19/15, Chris Jones wrote: On 19 Jan 2015, at 7:13 pm, Craig Treleaven ctrelea...@macports.org 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 idea. If I buy a sub-compact car, I can hardly complain that my skiis won't fit inside.I truly understand cost constraints and tradeoffs. However, if a compressed archive of MacPorts-installed packages is the tipping point for your system...I'd say you're running far too close to the edge. Its not a matter of being close to the edge. If you have a system with say a SSD 128 GB drive, I do not think it is then unreasonable for that user to ask why they have to lug around GBs of archives which, unless you regular use the activate/deactivate feature (and I still suspect the majority of users do not) is of rather limited benefit. Don't get me wrong, I also do understand why MP does this. I am just say IMO its a reasonable question to ask. 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 Mac Book with non-upgradable Solid state storage... Upgrade: http://eshop.macsales.com/shop/SSD/OWC Great, for those in the US .. Plus I don't think upgrading is available for all Macs with built in SSDs (might be wrong there, but I think so). Or the time-honoured fashion in the Apple world...trade up. I am not sure the 'spend you way out' is the right answer here. Chris ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: /opt/local/macports/software
On 20/01/15 02:37, Joshua Root wrote: Daniel J. Luke wrote: On Jan 19, 2015, at 6:34 AM, René J.V. Bertin rjvbertin at gmail.com 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 type means you won't get binary archives. This was true in the past, but no longer. Setting portarchivetype only affects the type of archives that are generated when building locally. Each archive site now has an associated archive type, which happens to be tbz2 for packages.macports.org and its mirrors. We do support building txz archives already, and they can happily coexist with downloaded tbz2 ones. The catch is that you have to have the xz port installed to install or activate any txz archives. So the default is not going to change unless/until Apple starts shipping xz with OS X. Or... MP starts shipping xz as a requirement, such as is done with TCL. If using xv saves more than it takes up (almost certainly the case) it is something to consider. Chris - Josh ___ 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: /opt/local/macports/software
On 20 Jan 2015, at 03:49, Craig Treleaven ctrelea...@macports.org wrote: Upgrade: http://eshop.macsales.com/shop/SSD/OWC I, for example, have a MacBook Air 6,2 with the PCIe SSD. No upgrade available. :( Vincent ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: /opt/local/macports/software
On Tue, Jan 20, 2015 at 9:12 AM, Akim Demaille a...@lrde.epita.fr wrote: Also, do people really use deactivate/activate offline? Yes. I do. (While I'm usually on a fast internet connection, sometimes the connection is just as limited and expensive (3G) as hard disk replacements for the first laptops with tiny SSDs. Or non-existent.) Mojca ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: /opt/local/macports/software
On Tue, Jan 20, 2015 at 3:12 AM, Akim Demaille a...@lrde.epita.fr wrote: Also, do people really use deactivate/activate offline? Yes, effectively; my local Internet connection is kinda crap at times. Also I use it with ports that can't be packaged for licensing reasons, or because of non-default variants (indeed, sometimes to quick-switch between variants). (We can't package non-default variants sanely because it would lead to a combinatorial explosion of dependencies with different variants.) -- 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: /opt/local/macports/software
Hi Ryan, Hi all, Le 19 janv. 2015 à 11:07, Ryan Schmidt ryandes...@macports.org 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/PORT when PORT was activated. It's quite a lot more than just that. You're asking for a way for the user to opt in to auto-removal of archives and opt out of the ability to use the deactivate feature. MacPorts currently relies on the deactivate feature during uninstallation, so there would be changes required there as well. I have a question: what exactly is in the archive? Why is that that deactivate does not archive what was installed on the disk? I mean, if the archives is exactly what is deployed, then it's pure duplication, including in an activate/deactivate scenario: one copy should be enough, be it deployed, or compressed, no? Maybe that would be less invasive, I don't know. Also, do people really use deactivate/activate offline? ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Using xz by default for compression
On 20 Jan 2015, at 12:21, Mojca Miklavec mo...@macports.org wrote: A slight disadvantage of xz is that many users still don't know how to decompress such files, but this argument doesn't apply here since port would do everything automatically for the user. I fully support Mojca’s proposal! Vincent ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Using xz by default for compression
(was: /opt/local/macports/software) I'm switching to the developers mailing list – I believe the discussion belongs there more than to the users' list. On Tue, Jan 20, 2015 at 10:46 AM, Chris Jones wrote: On 20/01/15 02:37, Joshua Root wrote: 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 type means you won't get binary archives. This was true in the past, but no longer. Setting portarchivetype only affects the type of archives that are generated when building locally. Each archive site now has an associated archive type, which happens to be tbz2 for packages.macports.org and its mirrors. We do support building txz archives already, and they can happily coexist with downloaded tbz2 ones. The catch is that you have to have the xz port installed to install or activate any txz archives. So the default is not going to change unless/until Apple starts shipping xz with OS X. Or... MP starts shipping xz as a requirement, such as is done with TCL. If using xv saves more than it takes up (almost certainly the case) it is something to consider. I would support the switch to xz. Yes, MacPorts could ship xz along with Tcl and ports could check for both tar.xz and tar.bz2 if tar.xz wasn't found. If we wanted to change the contents on the servers, the buildbots wouldn't have to rebuild everything. It's just a matter of writing a script that recurses through contents and first extract tar.bz2, then compresses into tar.xz, done. TeX Live started shipping xz archives and xz + xzdec binary. It can be build with no external dependencies and takes up a minimal amount of space: 350K xz.universal-darwin 361K xz.x86_64-darwin 153K xzdec.universal-darwin 162K xzdec.x86_64-darwin (universal-darwin: ppc + i386 built on 10.5, x86_64 built on 10.6; the binaries shipped by TL work on all machines from 10.5 on without any problems, but they could easily be built on Tiger) A slight disadvantage of xz is that many users still don't know how to decompress such files, but this argument doesn't apply here since port would do everything automatically for the user. Mojca ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: [Interest] Carbon obsolete
On Tuesday January 20 2015 12:42:09 Rutledge Shawn wrote: Sounds good to me. Now that we are dropping 10.6 support, it ought to be easier. Note that Carbon isn't required at all on 10.6, and native alternatives to Carbon functions have probably been available since well before that OS version. R ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: [Interest] Carbon obsolete
On Tuesday January 20 2015 12:42:09 Rutledge Shawn wrote: One would probably start by rounding up all uses of Carbon calls. And query the Qt devs to what extent they have a timeline for the migration. And one can only hope that a good part of the KDE4 functionality that relied on Carbon has been moved to Qt and will thus benefit automagically from Qt's severing of (from?) Carbon. Sounds good to me. Now that we are dropping 10.6 support, it ought to be easier. Patches welcome, as usual. ;-) Are you bouncing the ball back to us? Got a cheque book handy? :) R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: /opt/local/macports/software
Le 20 janv. 2015 à 13:20, René J.V. Bertin rjvber...@gmail.com a écrit : If you have a system with say a SSD 128 GB drive, I do not think it is then unreasonable for that user to ask why they have to lug around GBs of archives which, unless you regular use the activate/deactivate feature (and I still suspect the majority of users do not) is of rather limited benefit. It has already been pointed out that you can set up MP to put all of that on external storage, even a JetDrive or MiniDrive. The whole tree in which the software directory resides (var/macports) is used only be the port command, so as long as you don't use that you don't need to have var/macports online. Right. But that means that you have to have that drive at hand. The machine I'm using belongs to my company, and I'm traveling. Sometimes I'm far from my place, yet I want to upgrade. And I don't want to have to carry an additional external drive. So I agree it mitigates the problem, but it certainly does not address it. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: /opt/local/macports/software
On Jan 20, 2015, at 3:42 PM, Ryan Schmidt ryandes...@macports.org wrote: On Jan 20, 2015, at 2:12 AM, Akim Demaille wrote: 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/PORT when PORT was activated. It's quite a lot more than just that. You're asking for a way for the user to opt in to auto-removal of archives and opt out of the ability to use the deactivate feature. MacPorts currently relies on the deactivate feature during uninstallation, so there would be changes required there as well. I have a question: what exactly is in the archive? You can decompress it yourself to take a look: it contains all the files installed by the port, and also a copy of the Portfile itself and some other metadata. Why is that that deactivate does not archive what was installed on the disk? I mean, if the archives is exactly what is deployed, then it's pure duplication, including in an activate/deactivate scenario: one copy should be enough, be it deployed, or compressed, no? Maybe that would be less invasive, I don't know. Because nobody (at least not me) thought to program it that way. There is also a problem which occurs more often than it should, which is this: a user installs MacPorts in its default prefix, and installs some ports, and then installs a third-party software installer, which was itself built with MacPorts in its default prefix. Developers should not create installers of MacPorts-provided software with MacPorts in its default prefix (they should custom-configure MacPorts to a prefix unique to their software), but they do. Users should not install such misconfigured installers, but they do. And the consequence is that the files of some the user's installed ports are now overwritten with older versions, or versions built for the wrong architecture. Currently, a user can work around that by deactivating the port (i.e. deleting all the files the port installed), then reactivating the port (i.e. decompressing the archive which contains the correct versions of the files). This is a wonderful sanity check. Unsure? Deactivate/activate, certainty restored. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: /opt/local/macports/software
On Tuesday January 20 2015 17:42:27 Ryan Schmidt wrote: Why in fact deactivate and then activate anew? Isn't an untar of the appropriate tarball enough? Granted, in the case that the user has installed such a third-party installer, I actually recommend they completely uninstall MacPorts and all ports, then reinstall MacPorts and the desired ports, to be sure that no additional unwanted files are in /opt/local. Something related came up in another discussion I had today, which raised the question how hard it would be to write a walker that 1) identifies stray and/or trespassing files and 2) compares files with the copy in the software archive. Point 2) could actually be done by simply reactivating each port if there's no need to identify modified files. Point 1) is probably harder and certainly more resource intensive than it sounds, but it should beat a complete reinstall by more than a few lengths ... R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: /opt/local/macports/software
On Jan 20, 2015, at 2:12 AM, Akim Demaille wrote: 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/PORT when PORT was activated. It's quite a lot more than just that. You're asking for a way for the user to opt in to auto-removal of archives and opt out of the ability to use the deactivate feature. MacPorts currently relies on the deactivate feature during uninstallation, so there would be changes required there as well. I have a question: what exactly is in the archive? You can decompress it yourself to take a look: it contains all the files installed by the port, and also a copy of the Portfile itself and some other metadata. Why is that that deactivate does not archive what was installed on the disk? I mean, if the archives is exactly what is deployed, then it's pure duplication, including in an activate/deactivate scenario: one copy should be enough, be it deployed, or compressed, no? Maybe that would be less invasive, I don't know. Because nobody (at least not me) thought to program it that way. There is also a problem which occurs more often than it should, which is this: a user installs MacPorts in its default prefix, and installs some ports, and then installs a third-party software installer, which was itself built with MacPorts in its default prefix. Developers should not create installers of MacPorts-provided software with MacPorts in its default prefix (they should custom-configure MacPorts to a prefix unique to their software), but they do. Users should not install such misconfigured installers, but they do. And the consequence is that the files of some the user's installed ports are now overwritten with older versions, or versions built for the wrong architecture. Currently, a user can work around that by deactivating the port (i.e. deleting all the files the port installed), then reactivating the port (i.e. decompressing the archive which contains the correct versions of the files). If the archive isn't there, and is recreated by deactivating, then deactivating and reactivating does nothing useful, and additionally takes a lot more time than it does now. Granted, in the case that the user has installed such a third-party installer, I actually recommend they completely uninstall MacPorts and all ports, then reinstall MacPorts and the desired ports, to be sure that no additional unwanted files are in /opt/local. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: /opt/local/macports/software
On Jan 20, 2015, at 6:24 PM, René J.V. Bertin wrote: On Tuesday January 20 2015 17:42:27 Ryan Schmidt wrote: Why in fact deactivate and then activate anew? Isn't an untar of the appropriate tarball enough? That's true, but the MacPorts commant to untar the tarball is activate, and MacPorts will not allow you to activate a port that is already active, so you deactivate it first. If you prefer to figure out the command to untar the tarball and run that manually instead of using port commands, you can do that. It's never occurred to me before. I don't think the type of people who typically get into this situation are the ones who would want to do that. Granted, in the case that the user has installed such a third-party installer, I actually recommend they completely uninstall MacPorts and all ports, then reinstall MacPorts and the desired ports, to be sure that no additional unwanted files are in /opt/local. Something related came up in another discussion I had today, which raised the question how hard it would be to write a walker that 1) identifies stray and/or trespassing files I wrote a script to do that in 2009. The problem is that a normal proper MacPorts installation actually contains many many files that are not registered to a port. That includes all files provided by MacPorts base, cache files, log files, config files... and 2) compares files with the copy in the software archive. I haven't considered writing such a script. Sounds easy enough to do, but it would only be useful in situations where the user has corrupted their MacPorts-installed files, e.g. by running a badly-made third-party installer. I would rather focus effort on avoiding that situation ever happening in the first place. For example, whenever someone reports that this situation has occurred to them, we should attempt to discover which third-party installer they have used, then work with the developer of that third-party installer to fix it so that it no longer overwrites our files, and improving our documentation to explain to third-party developers how to create installers that avoid this problem. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
OT probably, help please
G’day The other day I reported that gnuplot had suddenly stopped working with term x11 but worked with term aqua. Maybe it was just slow ! I have an issue where the system has (suddenly) become very slow … iMac 27 top:cpu free 99 ish % system-monitor also shows cpu cores at 0% busy men free 8G df 50 ish % yosemite change mail from one entry to another: wheel turns for 10-20 seconds then all is normal including change topic (repeat previous selection). firefox:youtube watch a clip, midway stops playing and wheel turns for 5-10 seconds before resuming Thinking this may be a DNS issue I ran wireshark. wiresharks stops while wheel is turning! system-monitor shows no (just got the wheel for 5 secs, no response to usb-keyboard nothing interesting on system-monitor) sys-monitor (pause again!) ticks every 5 secs even during wheel turning. This seems unrelated to macports. Time machine is on an external USB disk and scheduled to run now (another pause checks:TM disk definitly NOT busy) So before I nuke this install, any ideas gratefully acceped James ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: OT probably, help please
On Jan 20, 2015, at 10:28 PM, James Linder j...@tigger.ws wrote: G’day The other day I reported that gnuplot had suddenly stopped working with term x11 but worked with term aqua. Maybe it was just slow ! I have an issue where the system has (suddenly) become very slow … iMac 27 top:cpu free 99 ish % system-monitor also shows cpu cores at 0% busy men free 8G df 50 ish % yosemite change mail from one entry to another: wheel turns for 10-20 seconds then all is normal including change topic (repeat previous selection). firefox:youtube watch a clip, midway stops playing and wheel turns for 5-10 seconds before resuming Thinking this may be a DNS issue I ran wireshark. wiresharks stops while wheel is turning! system-monitor shows no (just got the wheel for 5 secs, no response to usb-keyboard nothing interesting on system-monitor) sys-monitor (pause again!) ticks every 5 secs even during wheel turning. This seems unrelated to macports. Time machine is on an external USB disk and scheduled to run now (another pause checks:TM disk definitly NOT busy) So before I nuke this install, any ideas gratefully acceped James ___ Sounds like issues with Anti-malware virus programs. The ones that insert themselves into your tcp/ip data stream to examine all of your traffic so that you don't' download bad stuff. I had to shut off thtat processing in Sophos because it had gotten so bad (i.e. taking FOREVER to load any program that talked to the internet.) That was a sudden change in how Sophos was working. At first I thought it was simply because I had turned on the iCloud drive (which does impact things). But after a lot of trial and no-luck turned off the option in Sophos. Long ago I had tried Avast! and discovered that it's anti-malware was simply horrible in what it did to a Mac. T.T.F.N. William H. Magill # iMac11,3 Core i7 [2.93GHz - 8 GB 1067MHz] OS X 10.10.1 # Macmini6,1 Intel Core i5 [2.5 Ghz - 4GB 1600MHz] OS X 10.10.1 OSX Server (now dead) mag...@icloud.com mag...@mac.com whmag...@gmail.com ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: /opt/local/macports/software
On Tue, Jan 20, 2015 at 7:24 PM, René J.V. rjvber...@gmail.com wrote: Something related came up in another discussion I had today, which raised the question how hard it would be to write a walker that 1) identifies stray and/or trespassing files Config files are not part of a port/package, because if they were then any (often necessary) customization would be overwritten on port upgrade. (Binary package managers often handle this by flagging them for special handling... and still get it wrong often enough that I usually check manually after upgrades.) Likewise things like databases (whether things like mysql/mariadb/postgresql or support databases like scrollkeeper), the DocumentRoot of web servers, etc. In short, this isn't even remotely trivial. -- 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
