Re: Poll: should Trac send email notifications when adding or replacing an attachment?

Ralph Seichter wrote: > Have you tried using Sieve or your MUA's filter options to get rid of > e-mails you personally don't consider of interest? Notifications are a No, as I said I'd rather not. Filtering these notifications means filtering on email content, and with the number of MUA's I'm

Re: Poll: should Trac send email notifications when adding or replacing an attachment?

On Thursday November 03 2016 12:46:18 Rainer Müller wrote: > By now I received more mails from you with complaints about this than > actual "duplicate" Trac notifications for attachment replacements... You're welcome to filter out my emails, but you certainly won't receive any notifications

Re: GitHub migration complete

On Thursday November 03 2016 11:35:43 Clemens Lang wrote: > It's something we all have to deal with. Presumably, we will all learn over > time. Presumably. Question is, who has to learn what, and how reasonable is it to require that of them when the general consensus usually is that "users

Re: GitHub migration complete

A question that came up due to another ticket: last time I checked, github's issue tracker wasn't available for the ports repo. I presume that's on purpose, but why? Even if "we already have a bug tracker", why would it make life harder and not easier at least for some things? I must admit

Re: 10.6.8 and ffmpeg

Mojca Miklavec wrote: > I'm pretty sure one can make it build without 10.7 SDK, it will just > take quite a bit of work to do so. Perhaps you know if there is an > elegant way to actually patch the code in a way that would be > acceptable for upstream in case we manage to find a sufficient set of

Poll: should Trac send email notifications when adding or replacing an attachment?

Hi, This is a poll about MacPorts's bug reporting engine, Trac. If you don't (plan to) use that thing, just delete this message. Trac never sent notifications when you added or deleted (replaced) an attachment, but a recent introduced that as a new feature. I find this mostly useless and even

Re: GitHub migration complete

On Monday October 31 2016 10:00:05 Ryan Schmidt wrote: > This issue only affects the very small percentage of the MacPorts user > population (including developers and maintainers) that clones the git > repository. Most users will use the rsync server, on which we do generate > portindexes for

Re: GitHub migration complete

On Monday October 31 2016 10:49:55 Clemens Lang wrote: Hi, >Just as with Subversion, the answer is no. Remember that the PortIndex >is specific to the macOS version you are running, so a server-generated Ah, of course. I didn't actually know this but indeed port versions could be specific to

Re: 10.6.8 and ffmpeg

David Evans wrote: > However, sdl/sdl2 provides the only audio/video outdev that we support in > MacPorts which means that if you have to have one or the other. Without an > outdev, ffplay will not be configured/built and you'll have no direct way to > play audio/video with ffmpeg. It's been

Re: GitHub migration complete

Clemens Lang wrote: > If your question is not yet answered, ask on the mailing lists so it can > be added. I may have overlooked this, but does github have any provisions that would allow the PortIndex files to be generated on the server and served with the actual repo contents? That would

Re: soreEyes (and where are my System 7 ports?)

On Tuesday September 27 2016 04:12:13 Ryan Schmidt wrote: > > People receiving messages from the ticket system already know what MacPorts > is. Which means the footer isn't necessary at all ;) ___ macports-users mailing list

Re: soreEyes (and where are my System 7 ports?)

On Tuesday September 27 2016 04:00:26 Ryan Schmidt wrote: >Yes it would. I've changed it in the Trac footer. I expect there are many >places in the guide and wiki where this needs to be changed, but the >documentation needs a major overhaul anyway. Might I suggest adding the small nuance that

Re: soreEyes (and where are my System 7 ports?)

On Tuesday September 27 2016 03:31:51 Ryan Schmidt wrote: >The official word from Apple is that it is called "Mac OS" before 10.0, "Mac >OS X" from 10.0 to 10.7, "OS X" from 10.7 to 10.11, "macOS" from 10.12 >onwards, and "the Mac operating system" when not specifying a version. Whether >we

soreEyes (and where are my System 7 ports?)

Hi, I just caught something from the corner of my eye which put me in rant mode: > MacPorts > Ports system for macOS Am I the only one who gets sore eyes because of Apple's latest name change for their OS? It's one thing seeing camelToe (...) case being used for

Remote ssh+X11 connections and DBus

Hi, Drawing some attention to some recent enhancements I've submitted to MacPorts' port:dbus (https://trac.macports.org/ticket/52257#comment:3) in hope of rallying some beta-testers. I think many users who regularly work on a remote Mac using X11 for displaying probably noticed that

Re: Qt 5.x and OS X 10.6

On Tuesday September 20 2016 10:02:59 Ken Cunningham wrote: >I tried 10.7 first, but 5.4.2 would not install due to this message. Ergo >moved up the chain to the next machine I had in line. > >>> Symbol not found: _NSPreferredScrollerStyleDidChangeNotification That's a Qt bug you should report

Re: Qt 5.x and OS X 10.6

On Tuesday September 20 2016 08:35:18 Ken Cunningham wrote: Hi Ken, > Thought I'd report progress. Short answer - it's not working so far. > > Installed Qt 5.4.2 on a 10.11 machine into the /opt/local/libexec/qt > directory, then tarballed it and installed it onto a 10.6 machine in the same >

Re: [MacPorts] #51689: preserve_runtime_libraries convenience PortGroup

MacPorts wrote on 20160915::23:53:47 re: "Re: [MacPorts] #51689: preserve_runtime_libraries convenience PortGroup" >Changes (by ryandesign@…): > > * status: new => closed > * resolution: => wontfix > We've already solved this problem: whenever a port is updated in such a > way that one of

Re: Qt 5.x and OS X 10.6

On Wednesday September 14 2016 13:30:34 Ken Cunningham wrote: Hi Ken, > > I was reading your old posts on this topic from last year...and perhaps you > have this as figured out as it's going to get. > > For options regarding qt5 on 10.6, it looks like qt5-mac revision 127528 was > the last

Re: Qt 5.6 LTS vs. 5.7 - should MacPorts provide both and how?

On Saturday September 03 2016 11:53:04 Ryan Schmidt wrote: >In this hypothetical scenario, yes, that's true. I have no knowledge of what >those features might be That should be easier to answer than the other questions raised: each Qt release always comes with a description of the new

Re: Qt 5.6 LTS vs. 5.7 - should MacPorts provide both and how?

On Saturday September 03 2016 10:57:24 Ryan Schmidt wrote: >You mustn't change the version in a variant, because MacPorts decides when a >port is outdated based on what's in the portindex, and the portindex only >includes one entry for each port, and the version recorded in the portindex >for

Re: Qt 5.6 LTS vs. 5.7 - should MacPorts provide both and how?

On Saturday September 03 2016 08:31:21 Ryan Schmidt wrote: >I am inclined to say we don't need to keep 5.6 after upgrading the ports to >5.7. Shouldn't that depend at least in part on what Qt have in mind with that so-called LTS version? If the intention is to are freeer to evolve the 5.7+

Qt 5.6 LTS vs. 5.7 - should MacPorts provide both and how?

Hi, You may be aware that Qt have designated v5.6 a long-term support version that will be maintained in parallel to 5.7 (already released) and (probably) beyond. I still have to look at the exact implications, but this could well put us in a situation where we will need to provide a 5.6 port

Re: [KDE/Mac] another round of KF5 test-building please

On Thursday July 07 2016 14:29:15 Kurt Hindenburg wrote: Hello Kurt, I was under the impression I'd already replied to this mail of yours, but cannot find any trace of that, so here goes again. >Hi, first off, I want to thank you for doing all this work getting KF5 to work >on Mac OS X.

Re: [Alexpux/MINGW-packages] qt5: add new functions better fit MSYS2 needs (#1640)

On Saturday August 20 2016 10:16:41 David Faure wrote: > OK, you're probably right about OSX, but on Windows the shared data dir > allows > to do this, without the need for a XDG mode on Windows. Possibly, I must admit that I haven't looked at exactly what MSYS2's needs are here. It does seem

Re: [Alexpux/MINGW-packages] qt5: add new functions better fit MSYS2 needs (#1640)

On Friday August 19 2016 12:10:54 David Faure wrote: > The discussions at the last Randa meeting, with the people involved in > porting > KDE applications (e.g. kate/kdevelop/etc.) to OSX and Windows, convinced me > that a XDG mode for QSP on OSX and Windows is unnecessary. I am pretty much

Re: [KDE/Mac] another round of KF5 test-building please

On Thursday July 07 2016 14:29:15 Kurt Hindenburg wrote: Hi Kurt, > Hi, first off, I want to thank you for doing all this work getting KF5 to > work on Mac OS X. You're welcome! > I managed to install KF5-Frameworks and Konsole (my main reason). I hope KF5 Konsole hasn't been disappointing

Re: [KDE/Mac] another round of KF5 test-building please

On Thursday July 07 2016 14:29:15 Kurt Hindenburg wrote: Hi Kurt, THanks for the feedback. I'm currently on a bit of a vacation so I won't be able to look into this for a while. When I get back I'll be updating to frameworks 5.24.0 and will get back to you when that's taken care of. Cheers,

another round of KF5 test-building please

Hello (esp. Marko), Would someone please have (or find) the time to run a test build of my KF5-Frameworks port, preferably before I start the upgrade process to 5.23.x and PREFERABLY with the stock cmake PortGroup? Reason I'm asking is that it no longer uses the +qspXDG variant to link in the

Re: gcc-6

On Thursday May 19 2016 10:09:05 Ryan Schmidt wrote: >The description I provided in quotation marks above is what the path:-based >dependency feature is intended to do. What you perceive is not a bug because >the feature was not intended to do what you describe. I've never condoned that kind

Re: gcc-6

On Thursday May 19 2016 09:39:58 Ryan Schmidt wrote: >That's not what path:-style dependencies are for, and they don't work like >that. A "path:foo:bar" dependency means "if the file at path foo does not >exist, install the port bar, which shall provide the file at path foo". It >will not

Re: gcc-6

On Thursday May 19 2016 09:13:11 Ryan Schmidt wrote: >We can't use variants for reasons already explained. > >You talked about using path:-style dependencies, which one only does if there >are multiple ports that can provide a file. I don't agree: they could also be used in the context of a

Re: gcc-6

On Tuesday May 17 2016 13:20:22 Clemens Lang wrote: hi, >Have you checked with upstream? Maybe the only thing missing is a patch that >provides a -stdlib option with a couple of defaults? Not yet, but if it were so simple you'd think that patch would have been added already. It's not like the

Re: gcc-6

On Tuesday May 17 2016 12:01:15 Clemens Lang wrote: Hi, >There is a way to call g++ so that it uses libc++. That's not the same level of Good to know, but if there's still a risk of having to jump through all kinds of hoops I think I'll hold off :) >integration you get with clang++

gcc-6

Hi, I'm seeing what seem to be rave reviews about GCC 6, and also that there's a port for it. I guess the situation with libstdc++ vs. libc++ hasn't changed, or has someone managed to get GCC to use libc++ (like clang uses libstdc++ on Linux)? R.

Re: de/activate and Time Machine

On Thursday April 28 2016 08:38:35 Daniel J. Luke wrote: > > IIRC there is some metadata that you can set to exclude a file from backup (a > little googling says it's probably > com.apple.metadata:com_apple_backup_excludeItem) I think the safest way to set or unset this is via the TM

Re: de/activate and Time Machine

On Wednesday April 27 2016 23:10:20 Brandon Allbery wrote: >I was apparently headed into a brainfog when I wrote that.. recovered today Heh, why do I seem to relate ... :) >backup, found that there were port components not under /opt/local missing >(notably the symlinks into launchd's

Re: de/activate and Time Machine

On Tuesday April 26 2016 13:06:20 Brandon Allbery wrote: >I think you can rely on that for maybe 95% of things, but the remaining >5%... I've had to help people fix things afterward. Do you remember what kind of issue? I'm curious to know under what conditions "base" cares whether supposedly

Re: de/activate and Time Machine

On Tuesday April 26 2016 09:28:09 Brandon Allbery wrote: >The registry's a bit of a risk, since it will be logically inconsistent if >you aren't backing up the whole install. If I needed to worry about this, Is that really a problem? IIRC I've already had restored files that had "mysteriously"

de/activate and Time Machine

Hi, I'm probably not the only one who noticed: after deactivating and reactivating a large port like Qt5, the next Time Machine backup announces (or at least claims) to have much more to backup that one would expect (over 1.5Gb in case for Qt5). That suggests that the backup engine looks at

Re: port [m]dmg and PackageMaker

On Tuesday April 12 2016 14:43:22 Jeremy Lavergne wrote: > PackageMaker should be available on the Apple developer site. Are you sure? https://developer.apple.com/downloads/?name=packagemaker returns 0 hits for me and the latest "Auxiliary Tools" that still contain PackageMaker are from July

Re: port [m]dmg and PackageMaker

On Tuesday April 12 2016 09:34:06 Ryan Schmidt wrote: > The MacPorts release process depends on the "port pkg" and "port dmg" > commands: > > https://trac.macports.org/browser/trunk/base/portmgr/ReleaseProcess > > So it worked for us when we released MacPorts 2.3.4. Did you create

port [m]dmg and PackageMaker

Hi, I just tried `port dmg` for the first time in my live, and was greeted by errors about PackageMaker not being found. I still have an old copy but that no longer works. Is this feature still being maintained? From what I see one now needs to use a combination of pkgbuild and

Re: Audacity build question. for Ticket #47189

On Saturday February 27 2016 12:53:37 Robert Chalmers wrote: >I don’t mean to mis-lead anyone. The issues I”m talking about are part of >Audacity 2.1.2. Things like not being able to drag-highlight-scroll right in >editing a track, and drag+highlight-dcroll left+edit only works sometimes. You

IOUnserialize error and fix?

Hi, I just had one of these episodes where my system.log receives heavy pollution like this: Feb 15 21:14:09 Portia.local kdevelop.bin[32590]: FIXME: IOUnserialize has detected a string that is not valid UTF-8, "+_»". Feb 15 21:14:39 --- last message repeated 341 times --- Feb 15 21:14:39

Re: KDE Printing Question ... and KDE3

On Tuesday January 12 2016 00:12:45 Jeremy Lavergne wrote: >MacPorts has a copy of the sources; while it may build, I cannot make >any claims of it runs. At this point, and with John's subsequent input, >I aim to simply remove the software. Ah, right, that was it. I remembered setting out to

Re: KDE Printing Question ... and KDE3

On Tuesday January 12 2016 16:45:40 Pierre Henri CHAUDOUARD wrote: > I am a big fan of KDE3 for X11 that I use on my old computer (OS X Lion)! I > have not tried to install it on my new computer (El Capitan) since there is > little hope that it will work (as far I understand). I can only say:

Re: app-bundle vs. regular/"BSD utility" executables : what differences are there still?

On Tuesday January 05 2016 10:29:41 Jeremy Huddleston Sequoia wrote: >It's possible for a standalone executable to have an Info.plist. It is >embedded in the executable in an __info_plist section. This can be done by >the CREATE_INFOPLIST_SECTION_IN_BINARY Xcode build setting or by creating

Re: app-bundle vs. regular/"BSD utility" executables : what differences are there still?

On Tuesday January 05 2016 10:29:41 Jeremy Huddleston Sequoia wrote: Thanks! > There are really two main difference between the two cases: > 1) The app bundles have an inherent main bundle (ie: [NSBundle mainBundle]). But CFBundleGetMainBundle() does return something equivalent for

app-bundle vs. regular/"BSD utility" executables : what differences are there still?

Hi, This is a rather technical question that in itself is only indirectly related to MacPorts: What are the current differences in terms of what applications can or cannot do if they're built as traditional executable files ("BSD Utilities" in Apple speak) vs. as/in an app bundle? >From what

telepathy ports?

Hello, I see that MacPorts has ports for the telepathy IM framework, but not the KDE clients. I think I see only port:empathy that provides a user client that uses those libraries; are there any other clients "out there" that would make sense given the usual suspects in terms of OS X IM

xdg-open vs. open and hunspell dicts

Hi, Going over KF5 code to adapt to OS X/MacPorts, I came across invocations of xdg-open . That's the XDG (Freedesktop standard) equivalent to our own open command, and it's part of port:xdg-utils . It's not dysfunctional on OS X (it just opened a few documents in the epiphany browser for me;

Re: about XDG_RUNTIME_DIR

Rainer Müller wrote: Ah, this is the message to which Clemens appeared to be replying. Missed it somehow... > Adding environment variables is complicated and involves interruption by > the required logout/reboot. If possible, we should avoid it and patch > the default settings for libraries and

Re: about XDG_RUNTIME_DIR

On Monday November 23 2015 19:51:06 Clemens Lang wrote: Hi, > Note that $TMPDIR on OS X is already user-specific. You should not need to use > a subdirectory below it. Yeah, I know, but it still is cleaner. It's also clearly a rather common practice to store related things in a common

about XDG_RUNTIME_DIR

Hi, I'd like to reach as many users and developers as possible, hence I'm asking here: Freedesktop/XDG-compliant applications may use a user-specific location for runtime "stuff" like sockets. On Linux, this location usually is something like /run/user/uid. It is typically defined globally

Fwd: [MacPorts] #49721: (potentially) dangerous bug in Qt5

Hi, A small FYI-style note of warning for people who use Qt5 for their own development (or to install applications) other than through existing MacPorts ports. The issue I ran into was possible only because of a specific set of conditions that may have existed only on my own computer, but I

Re: openssl vs. libressl

On Friday November 13 2015 16:06:43 Jeremy Huddleston Sequoia wrote: >You mean it is up to the developer that is a client of that Qt API, not the >user. We should be protecting our users from developers that don't know >better. I think that's going beyond MacPorts goals. For once I agree with

Re: openssl vs. libressl

On Friday November 13 2015 10:45:32 Dominik Reichardt wrote: > from www.libressl.org: > > "LibreSSL is a version of the TLS/crypto stack forked from OpenSSL in 2014, > with goals of modernizing the codebase, improving security, and applying best > practice development processes.” > > so, no

Re: openssl vs. libressl

On Thursday November 12 2015 15:56:58 Jeremy Huddleston Sequoia wrote: If LibreSSL should become the default, the best compromise in this particular case might yet be to provide a variant that allows Qt to build with the shipped OpenSSL version rather than against the "system" (MacPorts)

Re: openssl vs. libressl

On Friday November 13 2015 09:20:11 Jeremy Huddleston Sequoia wrote: > They *force* the use of the insecure SSLv2 transport (which was broken years > ago and replace with SSLv3, which itself was broken). Where, how? > Qt probably doesn't use SSLv2 itself or else that warning would have had a >

Re: openssl vs. libressl

On Friday November 13 2015 11:30:59 Jeremy Huddleston Sequoia wrote: > I don't understand what you mean here. These methods *force* the use of > SSLv2 even if secure alternatives are available: > > qt.network.ssl: QSslSocket: cannot resolve SSLv2_client_method > qt.network.ssl: QSslSocket:

Re: openssl vs. libressl

On Friday November 13 2015 12:52:07 Dominik Reichardt wrote: > Yes! You must have missed Ryan's post in this thread when he remarked just > that (same license, same restrictions), one or two days ago. Guess so. This only strengthens my conviction that if anything and for the time being, it's

Re: openssl vs. libressl

On Thursday November 12 2015 08:45:19 Jeremy Huddleston Sequoia wrote: > See this ticket for details about Qt5 + Libressl: > > https://github.com/libressl-portable/openbsd/issues/33 And an official statement from a highly visible Qt dev: "Our current position is "our code is written for

Re: openssl vs. libressl

On Thursday November 12 2015 08:45:19 Jeremy Huddleston Sequoia wrote: > https://github.com/libressl-portable/openbsd/issues/33 Easy fix, but that still leaves me with 3 runtime errors: qt.network.ssl: QSslSocket: cannot resolve SSL_set_psk_client_callback qt.network.ssl: QSslSocket: cannot

Re: openssl vs. libressl

On Thursday November 12 2015 04:42:25 Ryan Schmidt wrote: >Just tested it. rev-upgrade works fine. And I just tested building Qt 5 with port:libressl active instead of port:openssl, and got this error:

Re: openssl vs. libressl

On Tuesday November 10 2015 18:55:51 Jeremy Huddleston Sequoia wrote: >Actually, this won't solve the problem. The entire problem here is that >OpenSSL and Libressl are note compatible. Projects need to be recompiled to >use one or the other. The only way to do this in a way that doesn't

Re: openssl vs. libressl

On Wednesday November 11 2015 05:27:49 Ryan Schmidt wrote: >If we don't want to switch to libressl as a default, then I don't know why >libressl is in MacPorts. To provide choice. Apart from the fact that the ssl ports can't be swapped without rebuilding all dependents, the only thing that

Re: openssl vs. libressl

On Wednesday November 11 2015 08:14:59 Bradley Giesbrecht wrote: > > On Nov 11, 2015, at 4:15 AM, René J.V. Bertin wrote: > I believe most openssl dependent ports are not binary distributable due to > the openssl license. There is indeed some kind of restriction, but

poll: expected return string of ApplicationsLocation from Qt's QStandardPaths

Hi, I just had a close shave with losing my whole /Applications directory which ultimately was caused by the fact that Qt5 provides a QStandardPaths class, which returns "/Applications" for both the readable and writable versions of "ApplicationsLocation". The application using that return

Re: openssl vs. libressl

On Wednesday November 11 2015 06:27:29 Ryan Schmidt wrote: >Providing choice is not a primary goal of MacPorts. Providing software that >works is. >It seems libressl is the default ssl library in OpenBSD since one year. I think that's hardly long enough in an OS that's hardly a mainstream OS

Re: poll: expected return string of ApplicationsLocation from Qt's QStandardPaths

On Wednesday November 11 2015 18:08:47 René J.V. Bertin wrote: For completeness, here's the list of all locations returned by QStandardPaths; standard and writable, regular and testing mode, native and XDG-compliant mode. I'd appreciate extra pairs of eyes checking for inconsistencies, errors

Re: openssl vs. libressl

On Tuesday November 10 2015 09:27:27 Brandon Allbery wrote: > As quoted from Rainer Müller: > > See both the official statement and a blog post from a Gentoo developer > > explaining the problem: Right ... exactly the same posts I found myself. I was looking for a link to gentoo.org or

Re: openssl vs. libressl

On Tuesday November 10 2015 02:17:06 Ryan Schmidt wrote: >> This is the same solution we've used elsewhere in MacPorts (eg: >> ffmpeg-devel). > >That's not the same situation. If a user had been using glib2 and then later >needed to switch to glib2-devel for some reason, everything should still

Re: openssl vs. libressl

On Tuesday November 10 2015 09:21:19 Daniel J. Luke wrote: >Other ports would all depend on ‘mp-ssl-lib’ and not directly only openssl or >libressl. > >It’s not a perfect solution, but may be nicer than adding +openssl/+libressl >to every possible port. Hmmm, I should have thought of that.

Re: openssl vs. libressl

On Tuesday November 10 2015 04:46:50 Ryan Schmidt wrote: > > No, but if the ABIs are indeed not compatible there is no other solution, > > is there? > > What has currently be done with libressl in MacPorts is a bug, not a solution. ?? Why? It leaves the educated user with a choice regardless

Re: openssl vs. libressl

On Monday November 09 2015 15:27:54 Ryan Schmidt wrote: > > Interesting. I think it was FreeBSD that tried to do that (both API and > > ABI) and failed at both, and said rebuild stuff for one or the other. > > Apparently they were the ones who made the mistake, and it actually works > > if

Re: openssl vs. libressl

On Monday November 09 2015 15:05:26 Ryan Schmidt wrote: > In r139229 Jeremy made libressl a drop-in replacement for openssl. If a > rebuild is needed to make things work, then this Yes, but at least on Linux libressl installs libraries with different numbers (libssl.so.35 vs libssl.so.1.0.0).

Re: openssl vs. libressl

On Monday November 09 2015 16:11:54 Jeremy Huddleston Sequoia wrote: hi, > > Now what if you do > > > > %> ln -s libssl.35.dylib libssl.1.0.0.dylib ? > > > > (assuming that libressl indeed installs libssl.35.dylib) > > > > If that works, it can be handled with a very simple post-destroot

openssl vs. libressl

Hi, I understand that libressl aims to be API-compatible with openssl so that it can act as a drop-in replacement. How far does that go, far enough that one can symlink the libssl and libcrypto runtimes from the one port to the shared libraries of the other, without having to rebuild

Re: ncurses5 vs. ncurses6

On Thursday November 05 2015 06:37:04 Brandon Allbery wrote: [sorry, should have gone to the list immediately] > If it's using terminfo level stuff only and doesn't share it around (e.g. > most uses of readline, which doesn't expose any curses/terminfo > interfaces), it should work fine if it

ncurses5 vs. ncurses6

Hi, Out of pure curiosity, does anyone know what happens when an application links to ncurses6 and one of its dependencies to a (runtime) library from ncurses5? R. ___ macports-users mailing list macports-users@lists.macosforge.org

Re: pet project : LnxPorts

On Thursday October 08 2015 07:16:51 Alejandro Imass wrote: > Perhaps it's a good time to evaluate a switch to PCBSD and ditch the Linux > ;-) I think you were not the only one suggesting this. I've been trying to check out PC-BSD in a VM for a while (Virtual Box), but I keep getting a pop-up

Re: about MacPorts principles, conventions (and dogmata :)) re: install layouts and Qt

On Tuesday October 06 2015 17:29:02 René J.V. Bertin wrote: >On Tuesday October 06 2015 07:47:03 Bradley Giesbrecht wrote: >> > On Oct 6, 2015, at 3:20 AM, René J.V. Bertin wrote: > >> We have: >> man porthier Just saw this in a log of a build against the "nouveau" qt4-mac

Re: about MacPorts principles, conventions (and dogmata :)) re: install layouts and Qt

On Tuesday October 13 2015 11:32:58 Aljaž Srebrnič wrote: > > Oh, so *that's* why wireshark can’t find QtCore... That's only partly true. The main reason may simply be that it doesn't use the Qt4 Portgroup like it should. It's a pity that there's nothing in base to print a warning (or raise

(sudden) failure linking kleopatra (from KDE4 KDE PIM)

Hi, I'm rebuilding a recent git checkout of KDE PIM 4.14, one I already had running since a couple of weeks (sept. 24th, partial rebuild on Oct 8th). I'm getting a build failure on kleopatra: Undefined symbols for architecture x86_64: "std::__1::basic_string

Re: (sudden) failure linking kleopatra (from KDE4 KDE PIM)

On Sunday October 11 2015 22:28:31 René J.V. Bertin wrote: Okay http://stackoverflow.com/questions/27680418/clang-trouble-using-bind-or-mem-fn-with-stringc-str-and-transform I think I'm beginning to understand a bit better what's going on here. Some time after the earlier successful

Re: about fragmentation (of free disk space)

On Saturday October 10 2015 14:45:43 Daniel J. Luke wrote: > random access time for a SSD is 1-3 orders of magnitude less than for a > rotational drive. > > As with anything, you need to measure ‘real world use’ to be certain, but > it’s probably not an issue for SSDs at all. I'm not

about fragmentation (of free disk space)

Hey Anyone on here who is knowledgeable about disk (free space) fragmentation (not just opinionated ;)) ? HFS+ is supposed to contain algorithms that limit file fragmentation, but without a background process that moves files (or file blocks), it cannot prevent free space fragmentation, just

Re: pet project : LnxPorts

On Thursday October 08 2015 07:16:51 Alejandro Imass wrote: > Perhaps it's a good time to evaluate a switch to PCBSD and ditch the Linux > ;-) Why? I've already checked the temp of those waters. I know MacPorts comes from BSD originally, but I cannot say I felt right at home at once on PC-BSD

Re: pet project : LnxPorts

On Thursday October 08 2015 09:22:19 Alejandro Imass wrote: > Also, why no use Gentoo or other existing ports-based Linux variants ? I don't need to have a front-row seat for everything. In fact, I much prefer a stable OS with LTS, one that I can work done on/with, rather than one on which I

port not installed according to registry, yet depends_lib didn't "react"?

Hey, Something weird just happened. I had triggered an incremental rebuild (build and destroot) of a KDE4 port that depends on port:libical via depends_lib. The build system uses cmake, which detected that a re-configure was in order: - cmake failed to detect libibcal - upon verification,

Re: pet project : LnxPorts

On Thursday October 08 2015 17:44:37 Clemens Lang wrote: > See, that's where you're wrong. MacPorts actively tries to NOT be a build > system, > but a package manager. That's why we focus on getting things done the right > way > and ensuring the tuple (os, port, variants) always behaves the

Re: port not installed according to registry, yet depends_lib didn't "react"?

On Thursday October 08 2015 12:03:32 Brandon Allbery wrote: > On Thu, Oct 8, 2015 at 11:55 AM, René J.V. wrote: > > > I *really* that my update to 2.3.4 yesterday (from source) didn't cause > > ports to be dropped from the registry! I meant the registry of installed ports,

Re: port not installed according to registry, yet depends_lib didn't "react"?

On Thursday October 08 2015 12:04:18 Ryan Schmidt wrote: > I know I've encountered situations where a port failed to build because one > of its dependencies was inactive. I'm sure I had forcibly deactivated it at > some prior time for some forgotten reason. I don't know why MacPorts wouldn't >

Re: pet project : LnxPorts

On Wednesday October 07 2015 20:36:24 Sven Kolja Heinemann wrote: > ... I don't see why anyone would install something like this on a Linux > distribution ... That's fine, but I think you haven't read my full message, it should explain why I'm using MP to install certain things. MP is not

pet project : LnxPorts

Morning! OK now, don't get me wrong, this is not an announcement that I'll be forking off MacPorts to begin a fully supported Linux variant! :) However, if anyone on here is like me (a developer's not to say hacker's mindset, and swinging back and forth between the OS X and Linux household

Re: about MacPorts principles, conventions (and dogmata :)) re: install layouts and Qt

On Tuesday October 06 2015 07:47:03 Bradley Giesbrecht wrote: > > On Oct 6, 2015, at 3:20 AM, René J.V. Bertin wrote: > We have: > man porthier Thanks, that's a start. I think "hierarchy applied to" leaves it to the imagination of the reader to what extent ports are

about MacPorts principles, conventions (and dogmata :)) re: install layouts and Qt

Hi, I've begun to wonder about any guidelines, principles, conventions etc. concerning where ports are supposed to install their various components. I've been meaning to ask about this; it's probably more of a macports-dev question, but one that I think will get more attention here. My

Re: : "no version information available"

Fernando Rodriguez wrote: Hi Thanks for the tips, and sorry it took me a while to come back to this. >> It means that the libxml2.so that you linked against had versioned symbols > but >> the one that's getting loaded doesn't. > > Actually it may be some other library that libxml.so linked

: "no version information available"

Hi, I know MacPorts isn't actually supported on Linux, but certain ports do build without modification. I make very light use of that (and am even trying if I can reuse my efforts on Qt5 ports), but have been running into an interesting warning lately: /opt/local/bin/cmake:

  1   2   3   4   5   >