about distcc
Hello, Since I discovered that clang can act as a cross-compiler (generating foreign object, .o , files), I have a renewed interest in distcc. I'm doing rather large builds on a Linux box, and the distcc I have on there is capable of a so-called pump mode in which the precompile step is also delegated to the slaves, via a header file server. It also has lzo compression. From what I've seen, distcc in MacPorts doesn't support neither pump mode nor suppression, and it also doesn't support the --zeroconf option (present on Apple's distcc) which advertises the services via ZeroConf. Is there a reason for this? (I could also ask this way: why provide a port that's less functional than what the OS vendor provides already?) The zeroconf feature isn't very important to me, but the pump and (thus) compression features are, as they allow to delegate (parallelise) even more intensive tasks to the slaves. R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: about distcc
On Mar 25, 2014, at 03:16, René J.V. Bertin rjvber...@gmail.com wrote: Since I discovered that clang can act as a cross-compiler (generating foreign object, .o , files), I have a renewed interest in distcc. I'm doing rather large builds on a Linux box, and the distcc I have on there is capable of a so-called pump mode in which the precompile step is also delegated to the slaves, via a header file server. It also has lzo compression. From what I've seen, distcc in MacPorts doesn't support neither pump mode nor suppression, and it also doesn't support the --zeroconf option (present on Apple's distcc) which advertises the services via ZeroConf. Is there a reason for this? (I could also ask this way: why provide a port that's less functional than what the OS vendor provides already?) The zeroconf feature isn't very important to me, but the pump and (thus) compression features are, as they allow to delegate (parallelise) even more intensive tasks to the slaves. The distcc port has no maintainer; nobody is looking after its interests. If we need to make a change to the port, please file a ticket to let us know, ideally supplying a unified diff of the needed changes. The port currently doesn’t seem to be doing anything too unusual with the build, so if these features you’re mentioning are unusual features that need to be explicitly enabled, then you should show us how to do that. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: about distcc
On Mar 25, 2014, at 10:03, Ryan Schmidt wrote: The distcc port has no maintainer; nobody is looking after its interests. If we need to make a change to the port, please file a ticket to let us know, ideally supplying a unified diff of the needed changes. The port currently doesn’t seem to be doing anything too unusual with the build, so if these features you’re mentioning are unusual features that need to be explicitly enabled, then you should show us how to do that. OK, I'll have a look at this. R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: about distcc
On Mar 25, 2014, at 10:03, Ryan Schmidt wrote: The distcc port has no maintainer; nobody is looking after its interests. If we need to make a change to the port, please file a ticket to let us know, ideally supplying a unified diff of the needed changes. The port currently doesn’t seem to be doing anything too unusual with the build, so if these features you’re mentioning are unusual features that need to be explicitly enabled, then you should show us how to do that. Done : http://trac.macports.org/ticket/43071 ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: kmail cannot send email : reason identified (?)
On Tue, Mar 25, 2014 at 8:44 AM, Nicolas Pavillon pavillon.nico...@gmail.com wrote: How come Linux distributions can provide binary packages for kdepim? I am not sure about that. The thing is that most of openssl use from KDE is swept under the carpet by avoiding any standard linking (only linking at runtime is used), and most project are moving to Qt SSL module instead. Not that anything of it changes the license restrictions. For what it's worth, there *are* rare people in the Linux community who won't use KDE because they do not trust license conflicts like this; KDE has a history of them. From a practical standpoint, though, it's effectively legal until challenged --- and nobody seems to be willing to challenge it, so it's ignored. I think this actually has legal implications, insofar as those kinds of restrictions have to be enforced or challenged for them to stand and ignoring a known violation can lead a court to conclude that the restriction is not actually in effect; but talk to an IP lawyer about the details. And *don't* try to rely on it, because it's only real if it stands up in court; it's the sword of Damocles until then. Note also that MacPorts has some constraints that others may not: if someone *does* challenge it, Apple might as a provider of hardware and services for MacPorts be caught by the blowback. As I understand it, the connection is a bit closer than that of people providing hardware or hosting for, say, Debian (although not a whole *lot* closer) --- but sometimes these do have legal implications. So we need to be somewhat more careful about license conflicts, just in case. -- 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: MacPorts Statistics (was Re: usage numbers for macports vs. homebrew?)
ok. my 2 cents after quick reading this long thread - clearly, submission should be asked on install of macports, either opt-in or opt-out. I'm pretty sure It's a legal constraint in some places (like european union). w opt-in, there is a risk to have little people but it's probably cleaner. It would probaly be better if installer call port install mpstat itself else many people will just drop/forget it after. - really like the setup http://stats.macports.neverpanic.de/os_statistics after, there are some debate on the type of graph used. If the lib used allow it, maybe have a switch button to satisfy everyone ;-) the top25 of most popular port is good. a per category would be nice too and some would probably ask for top100/top500. - As a more rough view and not as complete/exact, I ask myself, why there is no statistics based on web server log as when we do port install, it will usually try to fetch a package on macports server. It's not much but it gives also an information on how popular a package is and there is no consent to make statistics on that. - for sure, stats on port requested would be really interesting - on gcc, it's the default compiler we are listing ? which should be xcode. as there are some ports which require clang or gcc in certain releases. I'm not sure it's relevant except if you trace it for each port. Thanks for the nice work. Julien ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
