pbzip2 isn't faster
While waiting minutes for clang-3.5 to install (compress) and then activate (decompress) a 600MB archive, I wondered why I was sitting here waiting for a single-threaded process to complete when I have a multi-core Mac. A quick search led to pbzip2, a parallel implementation of bzip2 which we’ve had in MacPorts for 10 years already. I wondered why we’re not having MacPorts use this instead. I installed it and tried it out. It correctly detected my 8 CPUs (4 real CPU cores, hyperthreaded), but decompression took just as long as it did with bzip2. CPU use never rose above 101% (of one core), even if I specified a number of cores manually. Memory usage never rose above 29MB, even if I manually specified a memory limit of 1GB, nor if I instructed the program to read the entire archive into memory first. Has anybody successfully achieved the promised parallel operation of pbzip2 on OS X? If so, I wonder if it depends on the OS X version or the compiler used. I’m on OS X 10.9.2 with Xcode 5.1’s Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn). ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: pbzip2 isn't faster
On Apr 04, 2014, at 10:19, Ryan Schmidt wrote: While waiting minutes for clang-3.5 to install (compress) and then activate (decompress) a 600MB archive, I wondered why I was sitting here waiting for a single-threaded process to complete when I have a multi-core Mac. Is that 600MB raw, or 600MB when compressed? ... Has anybody successfully achieved the promised parallel operation of pbzip2 on OS X? If so, I wonder if it depends on the OS X version or the compiler used. I’m on OS X 10.9.2 with Xcode 5.1’s Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn). The correct question to ask is for what cases pbzip2 is faster, if any ... A compressed file is essentially a 1D string that's not segmented like multimedia data (how common is it to use multiple threads to [de]compress audio?). I may be wrong, but for now I'm not at all amazed that parallelisation of uncompressing such data entails a lot of overhead, esp. if it also means letting the disk seek so many times more (have you tried to compare to [de]compress from one disk to another, or using an SSD?) Also, decompression tends to be so much cheaper than compressing that the parallel overhead will count even more. R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: pbzip2 isn't faster
On Apr 4, 2014, at 03:33, René J.V. Bertin wrote: On Apr 04, 2014, at 10:19, Ryan Schmidt wrote: While waiting minutes for clang-3.5 to install (compress) and then activate (decompress) a 600MB archive, I wondered why I was sitting here waiting for a single-threaded process to complete when I have a multi-core Mac. Is that 600MB raw, or 600MB when compressed? 610 MB compressed. clang is enormous. Has anybody successfully achieved the promised parallel operation of pbzip2 on OS X? If so, I wonder if it depends on the OS X version or the compiler used. I’m on OS X 10.9.2 with Xcode 5.1’s Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn). The correct question to ask is for what cases pbzip2 is faster, if any ... A compressed file is essentially a 1D string that's not segmented like multimedia data (how common is it to use multiple threads to [de]compress audio?). I may be wrong, but for now I'm not at all amazed that parallelisation of uncompressing such data entails a lot of overhead, esp. if it also means letting the disk seek so many times more The homepage says PBZIP2 is a parallel implementation of the bzip2 block-sorting file compressor that uses pthreads and achieves near-linear speedup on SMP machines. If this didn’t actually work, there would be no reason for the program to exist, but it has, for over a decade. (have you tried to compare to [de]compress from one disk to another, or using an SSD?) I am using an SSD. I have also tried decompressing to /dev/null, with no change in speed. Also, decompression tends to be so much cheaper than compressing that the parallel overhead will count even more. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
kdearwork build errors
Upgrading kdeartwork I got the following error for the kscreensaver target: /opt/local/include/QtGui/qlabel.h:45:10: fatal error: 'QtGui/qframe.h' file not found /opt/local/include/QtGui is a symlink to the header folder in the QtGui framework, and qframe.h is there. The problem is that /opt/local/include/QtGui is passed as a search path to the compiler, but not /opt/local/include . The kdeartwork port I have installed currently doesn't appear to include kscreensaver - which seems logical. Indeed, when I deactivate the module in CMakeCache.txt the build completes fine. How does one achieve this in the Portfile? It would require passing -DBUILD_kscreensaver:BOOL=OFF to cmake . R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
ktimetracker and akonadi's googlecontacts/googlecalendar
Hello, Any idea why ktimetracker and the Google contacts/calendar akonadi resources are missing from MacPorts? The latter are part of kdepim-runtime, the former of kdepim, both of which I have installed. Judging from the Portfile no parts/modules of said packages are deactivated, so why am I missing them? R ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: help! - Python, Tkinter and IDLE
I have attached a screen grab of the alert message which now appears when I try to run IDLE from OSX Python. The message box is itself frozen, and the OK button unresponsive. Eventually a shape the size of the IDLE window appears on screen as a blank white square, and I have to force quit, to quit the python launcher. In addition, this is the console message that appears in Terminal: Apples-iMac-4:scripts apple$ IDLE 11:20:00 Traceback (most recent call last): File string, line 1, in module File /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/idlelib/run.py, line 7, in module import threading File /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/threading.py, line 14, in module from time import time as _time, sleep as _sleep ImportError: cannot import name sleep The console message has identical content to a message that I am also currently investigating, and which had caused me to try to launch IDLE at this time. This problem relates to running Python scripts that have import commands to a particular 3rd party library, which were working, but now no longer work without generating the same console message. Other scripts seem to run OK on both OSX Python and the macported Python. I would say the problem is with the 3rd party library save that IDLE is not related to that library. This may or may not be a macport issue, but as you say, having both macported and OSX versions of Python may be causing a conflict. Please explain how I may follow your initial advise on removing manually-installed software it may help. Install py27-tkinter and IDLE installed by MacPorts python will work. (At least it opens for me when I did only that. I didn’t actually do anything in IDLE.) Lenore ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
p5.12-parse-recdescent fails to upgrade
I have a whole bunch of p5.12* ports installed, most all dependencies of things that ought to depend on a more recent version of perl by now. Is there a way to clean this up, without having to figure out the depending ports and reinstall those? BTW, the build failure is because /opt/local/var/macports/build/_Volumes_Debian_MacPorts_var_macports_sources_rsync.macports.org_release_ports_perl_p5-parse-recdescent/p5.12-parse-recdescent/work/destroot/opt/local/lib/perl5/vendor_perl/5.12.4 doesn't exist. (/opt/local is a symlink in my case ... and indeed I disabled port's sandboxing feature) R ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: help! - Python, Tkinter and IDLE
Yes I may try this, as I have resolved the problem. YEAY! Thanks, all. -A -Original Message- From: Lenore Horner lenorehor...@sbcglobal.net To: MacPorts Users macports-users@lists.macosforge.org Sent: Fri, 4 Apr 2014 11:52 Subject: Re: help! - Python, Tkinter and IDLE I have attached a screen grab of the alert message which now appears when I try to run IDLE from OSX Python. The message box is itself frozen, and the OK button unresponsive. Eventually a shape the size of the IDLE window appears on screen as a blank white square, and I have to force quit, to quit the python launcher. In addition, this is the console message that appears in Terminal: Apples-iMac-4:scripts apple$ IDLE 11:20:00 Traceback (most recent call last): File string, line 1, in module File /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/idlelib/run.py, line 7, in module import threading File /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/threading.py, line 14, in module from time import time as _time, sleep as _sleep ImportError: cannot import name sleep The console message has identical content to a message that I am also currently investigating, and which had caused me to try to launch IDLE at this time. This problem relates to running Python scripts that have import commands to a particular 3rd party library, which were working, but now no longer work without generating the same console message. Other scripts seem to run OK on both OSX Python and the macported Python. I would say the problem is with the 3rd party library save that IDLE is not related to that library. This may or may not be a macport issue, but as you say, having both macported and OSX versions of Python may be causing a conflict. Please explain how I may follow your initial advise on removing manually-installed software it may help. Install py27-tkinter and IDLE installed by MacPorts python will work. (At least it opens for me when I did only that. I didn’t actually do anything in IDLE.) Lenore ___ 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: pbzip2 isn't faster
I've definitely had success; the main thing to realize is that pbzip2 can only speed up decompression on a file created by pbzip2. (pbzip2 files are still valid bzip2 files.) Compression (at least for bzip2) is still slow relative to disk speeds, so parallelizing works very well. As bzip2 is a block compressor (900k chunks by default) it maps to a parallel process very nicely. Here's an example with a locally compiled (and therefore run through pbzip2 as that is how I have MP set) MacPorts archive. MacPro:software$ time pbzip2 -dc clang-3.4/clang-3.4-3.4_0+analyzer+python27.darwin_10.x86_64.tbz2 /dev/null real 0m12.084s user 0m45.713s sys 0m0.534s MacPro:software$ time bzip2 -dc clang-3.4/clang-3.4-3.4_0+analyzer+python27.darwin_10.x86_64.tbz2 /dev/null real 0m37.223s user 0m36.872s sys 0m0.343s MacPro:software$ uname -a Darwin host 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 Note the user time is up (no free lunch; there is some overhead) but real or wall time is down by a factor of 3. (I have a 4 core 2007 machine.) The software autodetects (by default) how many cores to use by default, but you can set with -pN. Do you see all cores being used during compression? -- Eric [re-sent to list with correct address] On Fri, Apr 4, 2014 at 4:49 AM, Ryan Schmidt ryandes...@macports.orgwrote: On Apr 4, 2014, at 03:33, René J.V. Bertin wrote: On Apr 04, 2014, at 10:19, Ryan Schmidt wrote: While waiting minutes for clang-3.5 to install (compress) and then activate (decompress) a 600MB archive, I wondered why I was sitting here waiting for a single-threaded process to complete when I have a multi-core Mac. Is that 600MB raw, or 600MB when compressed? 610 MB compressed. clang is enormous. Has anybody successfully achieved the promised parallel operation of pbzip2 on OS X? If so, I wonder if it depends on the OS X version or the compiler used. I'm on OS X 10.9.2 with Xcode 5.1's Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn). The correct question to ask is for what cases pbzip2 is faster, if any ... A compressed file is essentially a 1D string that's not segmented like multimedia data (how common is it to use multiple threads to [de]compress audio?). I may be wrong, but for now I'm not at all amazed that parallelisation of uncompressing such data entails a lot of overhead, esp. if it also means letting the disk seek so many times more The homepage says PBZIP2 is a parallel implementation of the bzip2 block-sorting file compressor that uses pthreads and achieves near-linear speedup on SMP machines. If this didn't actually work, there would be no reason for the program to exist, but it has, for over a decade. (have you tried to compare to [de]compress from one disk to another, or using an SSD?) I am using an SSD. I have also tried decompressing to /dev/null, with no change in speed. Also, decompression tends to be so much cheaper than compressing that the parallel overhead will count even more. ___ 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: p5.12-parse-recdescent fails to upgrade
On Fri, Apr 4, 2014 at 7:53 AM, René J.V. Bertin rjvber...@gmail.comwrote: I have a whole bunch of p5.12* ports installed, most all dependencies of things that ought to depend on a more recent version of perl by now. Is there a way to clean this up, without having to figure out the depending ports and reinstall those? port installed leaves or the port_cutleaves port may be helpful. -- 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: pbzip2 isn't faster
On Friday April 04 2014 08:35:19 Eric A. Borisch wrote: Here's an example with a locally compiled (and therefore run through pbzip2 as that is how I have MP set) MacPorts archive. Hmmm, how have you configured things? real 0m12.084s user 0m45.713s sys 0m0.534s real 0m37.223s user 0m36.872s sys 0m0.343s Note the user time is up (no free lunch; there is some overhead) but real or wall time is down by a factor of 3. (I have a 4 core 2007 machine.) Depends on how it's measured; it could also reflect the number of CPUs used (i.e. correspond to the CPU%, 300% if you're indeed using 3 cores with complete efficiency) :) R ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: pbzip2 isn't faster
On Fri, Apr 4, 2014 at 9:13 AM, René J.V. rjvber...@gmail.com wrote: On Friday April 04 2014 08:35:19 Eric A. Borisch wrote: Here's an example with a locally compiled (and therefore run through pbzip2 as that is how I have MP set) MacPorts archive. Hmmm, how have you configured things? I have a (manually installed, linked against system libs) pbzip2 in /usr/local/bin/pbzip2. I configure macports (on install) with './configure BZIP2=/usr/local/bin/pbzip2' real 0m12.084s user 0m45.713s sys 0m0.534s real 0m37.223s user 0m36.872s sys 0m0.343s Note the user time is up (no free lunch; there is some overhead) but real or wall time is down by a factor of 3. (I have a 4 core 2007 machine.) Depends on how it's measured; it could also reflect the number of CPUs used (i.e. correspond to the CPU%, 300% if you're indeed using 3 cores with complete efficiency) :) R I failed to include the fact for you that the CPUs were pegged. Granted, I have some background tasks, but pbzip2 was 380%+ in activity monitor. It doesn't scale completely linearly -- as you can see on pbzip2's web page -- but 3x is nothing to shake a stick at. - Eric ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: ktimetracker and akonadi's googlecontacts/googlecalendar
On Apr 04, 2014, at 12:25, René J.V. Bertin wrote:
Hello,
Any idea why ktimetracker and the Google contacts/calendar akonadi resources
are missing from MacPorts? The latter are part of kdepim-runtime, the former
of kdepim, both of which I have installed. Judging from the Portfile no
parts/modules of said packages are deactivated, so why am I missing them?
R
For ktimetracker: the stock CMakeLists.txt file calls for it only for X11 Qt
... because it can do (optional) idle timing based on the X11 screen saver
extension. I think XQuartz supports that, but for now I'm just building it
without idle tracking.
patch-CMakeLists.diff
Description: Binary data
- modified patch for kdepim4
patch-ktimetracker-ktimetrackerutility.diff
Description: Binary data
- patch for ktimetrackerutility.cpp
This builds, but the app fails while loading its ktimetrackerpart, in
{{{
// now that the Part is loaded, we cast it to a Part to get our hands
on it
//NOTE: Use the dynamic_cast below. Without it, KPluginLoader will use
a qobject_cast
// that fails, because ktimetrackerpart is defined twice, once in
ktimetracker's binary
// and another one in the plugin. The build system should be fixed.
//m_part = factory-createktimetrackerpart( this );
m_part = dynamic_castktimetrackerpart*(
factory-createKParts::ReadWritePart( this ) );
}}}
This is beyond me ...
For the google contacts and calendar resources, this is required:
# Libkgapi2
find_package(LibKGAPI2 1.9.81 QUIET CONFIG)
set_package_properties(LibKGAPI2 PROPERTIES DESCRIPTION KDE-based library for
accessing various Google services URL https://projects.kde.org/libkgapi; TYPE
OPTIONAL PURPOSE LibKGAPI is required to build Akonadi resources to access
Google Contacts, Calendars and Tasks)
I'm going to try and install that, and report back.
R.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: pbzip2 isn't faster
As already said, the original bzipped file needs to have been created with
pbzip2 in order for the unzipping to see any improvement.
On 4 Apr 2014, at 05:08 pm, René J.V. Bertin rjvber...@gmail.com wrote:
On Apr 04, 2014, at 17:26, Eric A. Borisch wrote:
I must confirm Ryan's observation:
1.784_portia_936# time bzip2 -dc
/opt/local/var//macports/software/clang-3.4/clang-3.4-3.4_0+analyzer+python27.darwin_10.x86_64.tbz2
/dev/null
39.516 user_cpu 0.198 kernel_cpu 0:39.75 total_time 99.8%CPU {0W 0X 0D 0K 0M
0F 0R 0I 0O 0r 0s 0k 2w 0c}
# time bzip2 -dc
/opt/local/var//macports/software/clang-3.4/clang-3.4-3.4_0+analyzer+python27.darwin_10.x86_64.tbz2
/dev/null
39.191 user_cpu 0.176 kernel_cpu 0:39.36 total_time 100.0%CPU {0W 0X 0D 0K 0M
0F 0R 2I 0O 0r 0s 0k 2w 0c}
# time pbzip2 -dc
/opt/local/var//macports/software/clang-3.4/clang-3.4-3.4_0+analyzer+python27.darwin_10.x86_64.tbz2
/dev/null
41.739 user_cpu 0.132 kernel_cpu 0:41.62 total_time 100.5%CPU {0W 0X 0D 0K 0M
0F 0R 0I 0O 0r 0s 0k 2w 0c}
# time pbzip2 -dc
/opt/local/var//macports/software/clang-3.4/clang-3.4-3.4_0+analyzer+python27.darwin_10.x86_64.tbz2
/dev/null
41.942 user_cpu 0.124 kernel_cpu 0:41.80 total_time 100.6%CPU {0W 0X 0D 0K 0M
0F 0R 0I 0O 0r 0s 0k 1w 0c}
6# time pbzip2 -v -dc
/opt/local/var//macports/software/clang-3.4/clang-3.4-3.4_0+analyzer+python27.darwin_10.x86_64.tbz2
/dev/null
Parallel BZIP2 v1.1.8 - by: Jeff Gilchrist [http://compression.ca]
[Jun. 10, 2012] (uses libbzip2 by Julian Seward)
Major contributions: Yavor Nikolov nikolov.javor+pbz...@gmail.com
# CPUs: 4
Maximum Memory: 100 MB
Ignore Trailing Garbage: off
---
File #: 1 of 1
Input Name:
/opt/local/var//macports/software/clang-3.4/clang-3.4-3.4_0+analyzer+python27.darwin_10.x86_64.tbz2
Output Name: stdout
BWT Block Size: 900k
Input Size: 272168185 bytes
Decompressing data...
Output Size: 1218385920 bytes
---
Wall Clock: 40.797562 seconds
40.935 user_cpu 0.131 kernel_cpu 0:40.80 total_time 100.6%CPU {0W 0X 0D 0K 0M
0F 0R 0I 0O 0r 0s 0k 1w 0c}
# time pbzip2 -v -rdc
/opt/local/var//macports/software/clang-3.4/clang-3.4-3.4_0+analyzer+python27.darwin_10.x86_64.tbz2
/dev/null
Parallel BZIP2 v1.1.8 - by: Jeff Gilchrist [http://compression.ca]
[Jun. 10, 2012] (uses libbzip2 by Julian Seward)
Major contributions: Yavor Nikolov nikolov.javor+pbz...@gmail.com
# CPUs: 4
Maximum Memory: 100 MB
Ignore Trailing Garbage: off
---
File #: 1 of 1
Input Name:
/opt/local/var//macports/software/clang-3.4/clang-3.4-3.4_0+analyzer+python27.darwin_10.x86_64.tbz2
Output Name: stdout
BWT Block Size: 900k
Input Size: 272168185 bytes
*Warning* Max memory limit increased to 816 MB to support 4 CPUs
Decompressing data...
Output Size: 1218385920 bytes
---
Wall Clock: 39.034284 seconds
39.174 user_cpu 0.125 kernel_cpu 0:39.03 total_time 100.6%CPU {0W 0X 0D 0K 0M
0F 0R 0I 1O 0r 0s 0k 1w 0c}
R
___
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: of the kcookiejar and akonadi's googlecontacts/googlecalendar
On Apr 04, 2014, at 18:28, René J.V. Bertin wrote: For the google contacts and calendar resources, this is required: # Libkgapi2 find_package(LibKGAPI2 1.9.81 QUIET CONFIG) set_package_properties(LibKGAPI2 PROPERTIES DESCRIPTION KDE-based library for accessing various Google services URL https://projects.kde.org/libkgapi; TYPE OPTIONAL PURPOSE LibKGAPI is required to build Akonadi resources to access Google Contacts, Calendars and Tasks) I'm going to try and install that, and report back. Ok, after installing libkgapi 2.0.2, the google_contacts and google_calendar resources do build, and appear as options when creating a new akonadi service/resource. However, they're currently useless for me, as even after starting kded4 manually, I get Apr 4 19:32:53 portia [0x0-0xff5ff5].org.kded.kded4[63890]: kded(63890) Kded::loadModule: Could not load library kded_kcookiejar . [ Cannot load library /Volumes/Debian/MacPorts/lib/kde4/kded_kcookiejar.so: (dlopen(/Volumes/Debian/MacPorts/lib/kde4/kded_kcookiejar.so, 5): no suitable image found. Did find: /Volumes/Debian/MacPorts/lib/kde4/kded_kcookiejar.so: open() failed with errno=24) ] errno 24 is too many open files and indeed: lsof | fgrep kded4 | wc -l 2690 =8-| (on my Linux box with a KDE session that's been open for a few days, I'm at 326 for the same command) Question is, is this the only reason the cookiejar doesn't work? R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: pbzip2 isn't faster
On Apr 4, 2014, at 08:35, Eric A. Borisch wrote: I've definitely had success; the main thing to realize is that pbzip2 can only speed up decompression on a file created by pbzip2. (pbzip2 files are still valid bzip2 files.) Thanks! That was the information I was missing. I’ve sent a message to the developer to add this information to their web page, since knowing that could have saved me some time. Do you see all cores being used during compression? I had not yet tried compression, but I have now, and both compression and decompression work fine and use all my CPU cores. Compressing the 2.8GB clang-3.5 tarball down to a 610MB bz2 file took bzip2 365 seconds, but took pbzip2 only 102 seconds. Excellent. Decompressing the resulting file (and throwing the result away) with bzip2 took 83 seconds, while decompressing with pbzip2 took only 19 seconds. On Apr 4, 2014, at 10:26, Eric A. Borisch ebori...@macports.org wrote: I have a (manually installed, linked against system libs) pbzip2 in /usr/local/bin/pbzip2. I configure macports (on install) with './configure BZIP2=/usr/local/bin/pbzip2’ This is precisely what I was interested in. Have you been using this configuration for long? Any problems? I set up something similar, but with pbzip2 installed from MacPorts, and I did have pbzip2 crash once. I’ll have to try it for longer and see how reliable it is. Obviously the problem with using pbzip2 from MacPorts is that everything would break if pbzip2 were ever deactivated, including if it were ever upgraded. Since the MacPorts build system now accommodates adding third-party software into the build, if pbzip2 works reliably, it might be nice to include it with MacPorts and use it at least for compression and decompression of the archives, if not also for bzip2 distfiles and patchfiles. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
