Re: finding dependents of a shared library

Clemens Lang wrote: Hi, > The part outside of parentheses is correct, the part inside isn't. > rev-upgrade doesn't care whether the dep is provided by an active port, > it just makes sure the library is there and will load. Ok. Not sure if that changes anything for what I had in mind :) > Tcl

Re: gcc, AVX (and newer) intrinsics and binutils

Christopher Jones wrote: > provides a rock solid gcc build that works in all cases without any nasty > nuances (such as the library linkage changes you recently posted). I have now been able to build and run KDevelop 5.1.1, digiKam 5.5.0 and port:boost with my patched G++ Boost needs some

Re: gcc, AVX (and newer) intrinsics and binutils

Christopher Jones wrote: > My reading is there is, on average across the board, there is no clear > advantage/disadvantage to either gcc or clang That's exactly what I'm saying too. However, that's all on Linux where clang may not perform optimally (because using libstdc++) and where GCC can

Re: gcc, AVX (and newer) intrinsics and binutils

To answer my own question, partly: binutils doesn't install an assembler on Mac. Bummer, so it cannot provide the answer to the intrinsic instructions issue... I was a bit surprised to find out that the CCTools as is still based on GNU as, but an *old* version. R.

Re: gcc, AVX (and newer) intrinsics and binutils

Chris Jones wrote: > > > >> GCC vs. clang comparisons on sites like Phoronix suggest that GCC still has >> the upper hand compared even to clang 4.0 in computation-intensive tasks so >> it would make a lot of sense to get it to support the full instruction set. > > > Please provide links to

Re: "dev" ports (=/= "devel" ports!)

Jan Stary wrote: > Would you please give an example of such software > that needs to be made into a separate -dev port? Sorry, I missed your messages. The -dev port of a library (port:libfoo) would contain - header files - pkgconfig and/or cmake modules needed for dependent software to detect

Re: Using a different bugtracker [Was: Re: Poll: should Trac send email notifications when adding or replacing an attachment?]

On Friday November 04 2016 23:52:30 Joshua Root wrote: >We could really do without this kind of sarcastic, insinuated personal >attack. For the record, there was nothing personal intended in my remark; it was inspired by recent exchanges I've seen that involved more than just the 2 people

Re: Using a different bugtracker [Was: Re: Poll: should Trac send email notifications when adding or replacing an attachment?]

Lawrence Velázquez wrote: >>> Overall, can we just stop this discussion, please? We settled to stay > migrating is not worth it right now. At this point, we are kicking > a horse that is dead and buried and worm food, and it is wasting > everyone's time and energy. Enough. So is this the kind of

Re: Using a different bugtracker [Was: Re: Poll: should Trac send email notifications when adding or replacing an attachment?]

On Thursday November 03 2016 12:42:40 Rainer Müller wrote: > What do you want to discuss then? A bug tracker is for tracking, we will > not throw everything away that was reported. Not converting isn't the same as throwing away. > Overall, can we just stop this discussion, please? We settled to

Re: Using a different bugtracker [Was: Re: Poll: should Trac send email notifications when adding or replacing an attachment?]

On Thursday November 03 2016 11:30:50 Clemens Lang wrote: > We also looked into other bugtrackers, and there was no clear benefit over > Trac > to justify switching. It may just be an impression, but bugzilla comes across as more feature-rich to me. Conversion of existing tickets would be

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

Mojca Miklavec wrote: >> 1- Do you agree there is no need for (this many) notifications concerning >> changes to attachments (= you never missed it)? > > No. I have always been annoyed by the fact that some users (me > included) uploaded an attachment and then I had to tell everyone >

port info --{build,configure}.dir ?

Hi, Would a request to provide the build and/or configure directory variables as meta-info data be accepted? Evidently it's something that's relevant to port developer only (or almost, like info --patchfiles). R. ___ macports-dev mailing list

Re: querying the registry for reverse dependencies

On Tuesday November 01 2016 13:33:26 Brandon Allbery wrote: Hi, In hindsight it indeed seems unlikely that the registry would contain this kind of information. >I think that's a hack: save and nuke the port in question (manually), then >let rev-upgrade catch the broken dependents for you.

Re: querying the registry for reverse dependencies

Hi, A variant of my earlier question: is there a magic formula to query the registry which files (and/or ports) depend on a given binary file? IOW, an elegant alternative to something like %> sudo bzip2 -v foo %> sudo port -v rev-upgrade %> sudo bunzip2 foo.bz2 Thanks, R.

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 11:52:28 Rainer Müller wrote: >Just as with Subversion. Yeah, I wouldn't expect that the SVC type had any influence on this. > rsync -vt > rsync://rsync.macports.org/macports/release/ports/PortIndex_darwin_16_i386/PortIndex* > $ports Thanks for the suggestion, I

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: GitHub migration complete

Lawrence Velázquez wrote: ... > $ git gc --aggressive FWIW, while theoretically very space-efficient, git's .git directories tend to grow to considerable size for active repositories. I find it useful to run the attached script from time to time. It runs the garbage collector, but also

Re: querying the registry for installed files

On Friday October 28 2016 21:34:32 Vincent Habchi wrote: Hi, >> sqlite> WITH i AS (SELECT id FROM files WHERE path LIKE exp GROUP BY id) >> SELECT name FROM ports, i WHERE ports.id = i.id; This works great, and as expected *much* faster than any other method one could think of currently.

Re: git fetch fails because of gnutls_handshake

On Saturday October 29 2016 17:58:25 Chris Jones wrote: >But its true trac has never done this, so its not a recent change. Probably one of those things you start noticing again when enough other things change (another bug tracker I frequent also had a big overhaul).

Re: git fetch fails because of gnutls_handshake

On Saturday October 29 2016 16:44:29 Clemens Lang wrote: > I will veto this code for the reasons outlined in Trac. What made you think I was even considering wasting my own time to propose such a change? Does trac no longer auto-subscribe new participants?

Re: git fetch fails because of gnutls_handshake

On Saturday October 29 2016 09:57:35 Lawrence Velázquez wrote: >> I haven't yet found any indication that the port process might be using the >> OpenSLL library from port:openssl, or indeed any other related library. > >What OS are you running? Have you set DYLD_LIBRARY_PATH or something else?

Re: git fetch fails because of gnutls_handshake

On Saturday October 29 2016 15:32:19 Clemens Lang wrote: hi, >That's https://trac.macports.org/ticket/51516. Ah, thanks. >> What could this be due to? > >Your system libcurl is too old to talk modern SSL, or you have modified >your system libcurl to use a different library, or you have built

git fetch fails because of gnutls_handshake

Hi, I'm seeing this on one of my systems (haven't been able to try others yet): {{{ DEBUG: Executing org.macports.fetch (git) ---> git-2.10.1.tar.gz doesn't seem to exist in /opt/local/var/macports/distfiles/git ---> Attempting to fetch git-2.10.1.tar.gz from

Re: querying the registry for installed files

On Friday October 28 2016 21:22:41 Clemens Lang wrote: Hi, > Isn't this essentially what 'port provides' does? Only if you already know the full path to the file, and if you're only interested in the active port. What I have in mind is two-fold: - an alternative to spotlight's `mdfind -name`

querying the registry for installed files

Hi, I think the registry keeps track of all installed files, whether they belong to active or inactive ports, right? If so, is there a way to query the registry with a filename pattern, to obtain the full paths of known matching filesand the port(s) which provide them? Thanks, René

port:libcxx : use via DYLD_INSERT_LIBRARIES

Hi, I've built and been testing the libraries from port:libcxx 3.7.1 for a while now, on OS X 10.9.5 . I didn't take the completely adventurous approach; instead, I copied them into a new directory (/opt/lib) and wrote a little wrapper script that inserts them before loading any application.

Re: nested port upgrading and variants

On Thursday October 27 2016 14:55:59 Ryan Schmidt wrote: > > That's what I told Marko too, but we're not talking here about the initial > > installation. I think that when you already have opencv+qt5+opencv > > installed, an automatic upgrade to opencv should behave like `port upgrade > >

Re: nested port upgrading and variants

On Thursday October 27 2016 11:12:10 David Strubbe wrote: Hi David, >used for a dependency. That's all it does. The only way I know of that you >could make opencv get installed with +qt5 in this context is to do "port >install kf5-digikam-devel +qt5" (whether that is a meaningful variant for

Re: port:gpgme / Fwd: Review Request 129265: Port from KF5Gpgme to GpgME

On Thursday October 27 2016 12:05:33 Rainer Müller wrote: > Once again, our Trac is not hosted by GitHub. I know, but logging in does involve github as far as I can tell. I restarted my login session, so I have to log in again. R. ___ macports-dev

nested port upgrading and variants

Hi, Marko tells me he's been having issues with upgrading one of my KF5 ports that uses the active_variants portgroup to "depend" on variants of one of its dependencies. From our exchange: > > >> BUT that’s not all yet. Once also needs to select the +contrib variant, > > >> otherwise you have

port:gpgme / Fwd: Review Request 129265: Port from KF5Gpgme to GpgME

Hi, I'm not getting into trac (github being DDoS'ed again??), so I'm forwarding this info via the ML hoping Ryan will catch it. First, gpgme has been updated to 1.7.1 which apparently brings bug fixes we "definitely want". But more importantly, KDE is dropping the use of its own version of

Re: "Failed to open portfile from registry" while reinstalling because of configure.optflags

On Wednesday October 26 2016 18:50:33 Clemens Lang wrote: > On Wed, Oct 26, 2016 at 02:17:53AM +0200, René J.V. Bertin wrote: > > Yeah. There could be a check if the Portfile exists to catch the 1st > > possibility > > That would introduce a race condition, wouldn't it? Checking whether a > file

Re: "Failed to open portfile from registry" while reinstalling because of configure.optflags

Follow-up : I do NOT see the error (due to configure.optflags) when I do `port -n upgrade`. I think this suggests that `upgrade --force` does something recursive which is responsible for the substitution/dereferencing. R. ___ macports-dev mailing

Re: "Failed to open portfile from registry" while reinstalling because of configure.optflags

On Wednesday October 26 2016 00:25:14 Clemens Lang wrote: Hi, > The problem is that we don't see the difference. The code that procudes > the error is more or less > "source $filename" > which can fail either because the file isn't there, or because the code > in the file failed. Yeah. There

Re: "Failed to open portfile from registry" while reinstalling because of configure.optflags

On Tuesday October 25 2016 17:06:27 Ryan Schmidt wrote: Hi, > > As such, Portfiles or PortGroups that haven't been written carefully can > > trigger this warning from time to time. A common problem is checking for > > the presence of a file, or running a tool, and not catching the errors. > >

Re: port:qt5 and (proposed) port:qt5-kde cohabitation

On Sunday October 23 2016 17:43:56 Clemens Lang wrote: > top bar. If you think those should be larger, feel free to suggest a > patch to https://github.com/macports/trac.macports.org/. Well, I'm not a web coder, so I'd prefer to file request tickets somewhere. Also for the fact that nowadays I

Re: "Failed to open portfile from registry" while reinstalling because of configure.optflags

On Tuesday October 25 2016 08:34:31 Ryan Schmidt wrote: >I don't know the answers to your questions, but I wanted to mention that I >also have noticed the "Failed to open portfile from registry" error far more >often than seems normal to me. ("Never" would seem normal to me.) Yes, never would

"Failed to open portfile from registry" while reinstalling because of configure.optflags

Hi, I've been noticing "Failed to open portfile from registry" errors during certain operations like reinstalling (port -n upgrade --force). This turned out due in part to something I changed in one of my own portgroups, but after correcting that errors remained. I've finally traced them down

Re: QTKit & macOS Sierra

On Monday October 24 2016 09:54:56 Marko Käning wrote: Indirectly, yes. I get the impression port:opencv has been unmaintained for a while, so maybe you can update the official copy from mine? >I think I already let you know, that this did the job! :) > > > > >On 21 Oct 2016, at 01:54 , René

Re: port:qt5 and (proposed) port:qt5-kde cohabitation

On Sunday October 23 2016 18:20:06 Clemens Lang wrote: Hi, > > Thanks for the archive links. A quick scan suggests that my "shadow" > > tree I referred to will be a new working copy of the git repo, from > > where I'll filter things into the current svn tree. > > There will be no svn tree in a

Re: port:qt5 and (proposed) port:qt5-kde cohabitation

On Sunday October 23 2016 17:43:56 Clemens Lang wrote: Thanks for the archive links. A quick scan suggests that my "shadow" tree I referred to will be a new working copy of the git repo, from where I'll filter things into the current svn tree. Will the migration conserve the full history? >

Re: port:qt5 and (proposed) port:qt5-kde cohabitation

On Sunday October 23 2016 16:04:07 Clemens Lang wrote: > Yes, SVN is being retired completely. Have you not read the announcement > emails? Apparently not, were they sent on this ML? If so I must have applied too strict filters (basically "don't send list messages and don't filter copies sent

Re: port:qt5 and (proposed) port:qt5-kde cohabitation

On Sunday October 23 2016 02:21:02 Marko Käning wrote: >> I should have another look at exactly how the mainstream *Qmake5* PortGroup >> interacts with port:qt5-kde . > >Could you investigate this further in the meantime? Done. There are some differences in the way port:qt5 and port:qt5-kde

Re: port:qt5 and (proposed) port:qt5-kde cohabitation

On Sunday October 23 2016 02:08:23 Marko Käning wrote: Hi, >just like all those port files belonging to KDE 3 and 4? > >We’re not opposed to do the latter, but it will be somewhat messier! "We" being Marko and I, but being the main (as in most active) maintainer I have a strong preference for

Re: foo-snapshot / foo-diff convenience functions

On Thursday October 20 2016 15:38:42 Lawrence Velázquez wrote: > Better that than increasing the complexity of base and portfiles. Yeah, unless someone proposes to implement something in a portgroup. Then all of a sudden it becomes base functionality ... I won't be reinventing all kinds of

Re: foo-snapshot / foo-diff convenience functions

On Thursday October 20 2016 10:42:09 Lawrence Velázquez wrote: > It is already possible to create options that enable/disable portgroup > behavior after the portgroup is included. The python-1.0 and php-1.1 do Which increases the implementation complexity of the portgroup - each portgroup that

Re: foo-snapshot / foo-diff convenience functions

On Wednesday October 19 2016 21:44:04 Ryan Schmidt wrote: >No, that situation should not be common, nor indeed present at all. I'm not sure I agree. PortGroups are intended to take care of setting up things for the ports that use them (like declaring a dependency in such a way ports work with

trac down?

Hi, I cannot connect to trac but the main site works fine. Is there a problem with the server? R. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Fwd: [153647] trunk/dports/devel/dbusmenu-qt/Portfile

On Tuesday October 11 2016 22:53:33 Marko Käning wrote: Hi, > Hi René, > > what can you respond here? Well, the code is C++11 everywhere of course, it's the PortGroup that does Darwin-specific things. > Begin forwarded message: > > > From: Ryan Schmidt > >> +

Re: path normalisation in "base"

On Tuesday October 11 2016 16:33:26 Rainer Müller wrote: >I cannot reproduce these claims. 'port provides' works for symlinks as >expected. Note that file normalize does not resolve symlinks in the last >component. Actually, it was a question, and yes, after verification the answer is "no"

Re: path normalisation in "base"

On Tuesday October 11 2016 16:04:21 René J.V. Bertin wrote: >{{{ >proc macports::normalize { filename } { >set nprefix [file dirname [file normalize "${macports::prefix}/foo"]] >return [string map {${nprefix} ${macports::prefix}} [file normalize > $filename]] >} >}}} For some reason

Re: path normalisation in "base"

On Tuesday October 11 2016 09:21:09 Daniel J. Luke wrote: >one way to handle it could be: >+# don't normalize absolute paths See my previous message about why normalisation might be used here; completing a relative path is clearly another reason. I wonder a bit why `port provides`

Re: path normalisation in "base"

On Tuesday October 11 2016 09:07:05 Daniel J. Luke wrote: >https://lists.macosforge.org/pipermail/macports-dev/2014-May/026728.html >which I linked to the last time you brought this up. Funny (not so), I can't remember that at all... I used to have a similar configuration, but have since gone

path normalisation in "base"

Hi, I'd like to understand a bit better why the base layer does path normalisation in a number of places where its use isn't immediately obvious to me, like for instance the action_provides procedure in the port script. If that's not so broad of a question that it cannot be answered with a

Re: reasons for `port provides` not working?

On Monday October 10 2016 18:05:19 René J.V. Bertin wrote: >Is there a good reason why action_provides (in port) does a `file normalize`? Actually, doing that must make it impossible to trace which port installs a given symlink. While it can be interesting to know to whom the target belongs,

Re: reasons for `port provides` not working?

On Monday October 10 2016 17:29:18 Clemens Lang wrote: > > In fact, in absence of proof that my use of a symlinked $prefix explains > > everything I won't assume that that is the culprit. > > Well, let me lawyer you with your own mail from 2014 then: >

Re: reasons for `port provides` not working?

On Monday October 10 2016 15:30:57 Clemens Lang wrote: Hi, > IIRC the problem was that your installation mangled paths somehow, either by > making /opt/local a symlink or some other uncommon configuration. Yes (/opt/local is a symlink), but from what I read on here that is not *that* uncommon

reasons for `port provides` not working?

Hi, I've been bitten once too often by an oversight that I c/should have seen if `port provides` worked. It's not been working for me for a long time, and mostly I don't really miss it, but now I'd like to figure out if there's a way to get this feature online again. Without reinstalling from

Re: Of C++ (and other) runtimes

On Sunday October 09 2016 01:04:39 Jeremy Huddleston Sequoia wrote: >That being said, it's technically possible and they should be binary >compatible. Oh, and what about using DYLD_LIBRARY_PRELOAD? Not for systematic use, but shouldn't it be useful for testing purposes, or for debugging for

Re: Of C++ (and other) runtimes

On Sunday October 09 2016 01:04:39 Jeremy Huddleston Sequoia wrote: >My advice is to not mess with the base OS. There is a very good reason why I >force the user to use a variant and don't even give instructions on how to use >darwinup to install the libcxxabi and libcxx tarballs. > >That

Of C++ (and other) runtimes

On Friday October 07 2016 11:43:48 Lawrence Velázquez wrote: [was Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of using libstdc++] > it might be useful to refine this mechanism to allow something like > "configure.compiler.cxx macports-gcc-XYZ", which would add a direct >

Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of using libstdc++

On Friday October 07 2016 10:51:59 Lawrence Velázquez wrote: > Not to mention the fact that literally every single C++ port would have > to declare a library dependency on libgcc. Or not: if a compiler selection mechanism is used that picks a macports-gcc version that dependency would be added

Re: tcl question: defining dynamically named variables in a namespace

On Friday October 07 2016 14:25:11 David Bariod wrote: Hi, Yes, something like that could work, but it may be a bit less trivial than that. R. >It's been a long time I haven't done Tcl development, but from memory: > >namespace eval { > --> your code here <--- >} > >should do what you're

Re: tcl question: defining dynamically named variables in a namespace

sorry for the noise, it seems I can simply use namespace upvar kf5 ${name}_dep dep etc. Now, would it be possible and worth the trouble to put kf5.framework_dependency procedure itself into the dedicated namespace? R. ___ macports-dev mailing list

tcl question: defining dynamically named variables in a namespace

Hi, I have a procedure in a PortGroup that is used to define dependency variables for KF5, hiding the whole mechanism behind kf5-foo and kf5-foo-devel interchangeability from the casual port developer (and making it easy for myself too). Basically: {{{ proc kf5.framework_dependency {name

Re: port:qt5 and (proposed) port:qt5-kde cohabitation

On Thursday October 06 2016 23:19:38 Marko Käning wrote: Hi, > Currently the situation for port qt5-kde is as follows: > - 5 port groups would have to be updated (see comments 30-34 in [1]) That's a maximum, and this is the main point where we have to come to a consensus. I'll add that I

Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of using libstdc++

On Thursday October 06 2016 12:32:24 Brandon Allbery wrote: Hasn't this become easier at all? > now. At my previous job, when we ran into this we just lifted the whole > thing to glue multiple g++ releases to a common libstdc++ from Debian > (clang / libc++ wasn't an issue back then). Sounds

Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of using libstdc++

On Thursday October 06 2016 09:26:43 Ken Cunningham Webuse wrote: > 10.4 and 10.5 users who have PPC machines worth keeping might well have to > consider gcc cxx11options, if those systems are to have any path forward to > newer software. Wow ... have you also thought about my mom's old blue

Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of using libstdc++

On Thursday October 06 2016 16:48:44 Mojca Miklavec wrote: > This would probably mostly work fine if *all* ports were built with > g++ (= against the same version of mp-provided stdlibc++). I can > easily imagine problems when gcc is switched from, say, version 5 to > version 6, but let's ignore

Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of using libstdc++

On Thursday October 06 2016 06:33:56 Ken Cunningham Webuse wrote: > Some of the builds on these older machines can take hours and hours... > webkit2-gtk is not even to be mentioned. Didn't even think of that yet, but yes. The problem is of course that we *are* indeed talking about older

Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of using libstdc++

On Thursday October 06 2016 07:17:18 Ryan Schmidt wrote: > I don't understand... Those two paragraphs seem contradictory. You say it > works without libc++, and that forcing libc++ would cause the ports to fail > (on vanilla OS X < 10.9), but then you say it would help to use libc++. I guess

Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of using libstdc++

On Thursday October 06 2016 06:25:06 Ryan Schmidt wrote: > By including the portgroup, you are declaring that the port requires C++11. > Users using "vanilla" OS X versions prior to 10.9 who try to install such a > port will receive an error message with a link to the wiki page explaining >

Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of using libstdc++

On Thursday October 06 2016 04:35:02 Ryan Schmidt wrote: > If a port requires C++11 / libc++, include the cxx11 1.0 portgroup. I wonder if that shouldn't simply be done by the Qt5 PortGroup then ... I don't really follow what that portgroup does. Is there a risk of breaking anything when

dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of using libstdc++

Hi, I got the attached build failure notifications, which in both cases I think can be traced to the use of `-stdlib=libstdc++` : {{{ [ 84%] Building CXX object src/CMakeFiles/dbusmenu-qt5.dir/utils.cpp.o cd

Re: ${prefix} as a disk-image (was: #49559: nepomuk-core can't be installed on a case-sensitive system)

On Sunday October 02 2016 13:02:07 Lawrence Velázquez wrote: >something. Seems like it would be better to mount the image before >launchd does anything, if possible. That would require doing the mount the old-fashioned way. Not impossible, but I'd hate having to write an installer that modifies

Re: ${prefix} as a disk-image (was: #49559: nepomuk-core can't be installed on a case-sensitive system)

On Saturday October 01 2016 20:55:57 Lawrence Velázquez wrote: >So what happens when a port-installed Launch{Agent,Daemon} is loaded >before the one that mounts the entire MacPorts prefix? A priori they won't if their plists are symlinks into ${prefix}. Something similar happens when your

Re: ${prefix} as a disk-image (was: #49559: nepomuk-core can't be installed on a case-sensitive system)

On Saturday October 01 2016 23:13:25 Clemens Lang wrote: Hi, > People can already do that. People can also mount a different filesystem > at /opt/local. I just don't think that should be our default setup. I'm not saying it should be, this is just an idea for something that could be optional.

${prefix} as a disk-image (was: #49559: nepomuk-core can't be installed on a case-sensitive system)

On Friday September 30 2016 10:10:40 Lawrence Velázquez wrote: I coined this admittedly a bit wild idea the other day that all of ${prefix} could be hosted on a R/W dynamic disk image, aka a sparse image or sparse bundle. That would make it possible to install the more "unixy" ports to a

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

On Friday September 30 2016 03:48:09 Ryan Schmidt wrote: > > Still: https://bugs.kde.org/show_bug.cgi?id=369554 > > Thanks. Also see https://git.reviewboard.kde.org/r/127822/ for a prototype fix I started working on months ago... R. ___ macports-dev

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

On Friday September 30 2016 10:10:40 Lawrence Velázquez wrote: > So users would have to have this disk image mounted at all times, just > in case they ever want to use anything installed by MacPorts? Yes, but that can be completely transparent. The image can be mounted at an appropriate time

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

On Friday September 30 2016 03:48:09 Ryan Schmidt wrote: >> Still: https://bugs.kde.org/show_bug.cgi?id=369554 > >Thanks. Let's not hold our breath though. Addressing this issue properly will be very invasive: lots of dependent code will require patches. And even if the patching can be done

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

On Friday September 30 2016 02:53:22 Ryan Schmidt wrote: >I am not aware of Apple installing files whose names differ only by case; it >wouldn't make sense for them to do so, given that the default filesystem is >case-insensitive and can't accommodate that. If you believe they do install

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

On Thursday September 29 2016 18:21:15 Ryan Schmidt wrote: >> Ah, good news, because Qt5 and the KF5 frameworks have unfortunately >> standardised the behaviour of using capitalised letters in C++ header >> filenames. > >Someone needs to make it clear to them that this is not a good idea. Not

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

On Thursday September 29 2016 07:14:11 MacPorts wrote: >#49559: nepomuk-core can't be installed on a case-sensitive system Hi, > The new buildbot setup does not show this behavior, so I revbumped > nepomuk-core in r153339 so that all the packages are correctly rebuilt for > case-sensitive

Re: buildpath conf variable

On Monday September 26 2016 11:20:20 Brandon Allbery wrote: > > I can't guarantee this won't mess something up, but I think you can > > already delete the /opt/local/var/macports/build directory and replace it a > > symlink to another volume > Works fine. Did that on my MacBook Air. It seems to

Re: buildpath conf variable

On Monday September 26 2016 12:59:17 Ken Cunningham wrote: > At $0.50 (canadian) per GB, I put them in most of my systems -- even a 120GB > version in my Beige G3 running MacOS 9.2.2. Now that is something to see! The figure is the same here, except they're Euros. The 1Tb disk in my MBP came

Re: depends_build port:doxygen and +universal (or +docs)

On Monday September 26 2016 05:00:44 Ryan Schmidt wrote: > If you "sudo port install" some port that depends on doxygen, and you request > variants doxygen provides: > > * If doxygen is not installed, doxygen will be installed with the those > variant. > * If doxygen is already installed, it

Re: buildpath conf variable

On Monday September 26 2016 04:45:19 Ryan Schmidt wrote: > I can't guarantee this won't mess something up, but I think you can already > delete the /opt/local/var/macports/build directory and replace it a symlink > to another volume. That's what I'm preparing my system to test, but I seem to

buildpath conf variable

Hi, I know that more and more people (esp developers?) are using SSDs and that for them fragmentation starts hitting only when it's the free space that's really severely fragmented. I have no experience in that area, and do not currently have the budget to obtain that experience. Either way,

depends_build port:doxygen and +universal (or +docs)

Hi, Is there a way to stop certain variants from propagating to dependencies? I'd like to use `depends_build-append port:doxygen` for +docs variants, but - calling the variant +docs causes port:doxygen to install (or reinstalll!) with +docs, which adds lots of dependencies, and big ones at

Re: No Xcode 8 CLT for El Capitan

On Wednesday September 21 2016 16:02:48 Jack Howarth wrote: > Upstream qt development fixed this issue by changing the failing test > for xcrun to one for xcodebuild. ... > > René thus suggested the attached patch for qt5(-kde) as a workaround . Great minds think alike? :) R.

Re: codesigning, the macports user (and other users added by MacPorts) and diskspace (IconServicesAgent) [was Re: lldb ...]

On Monday September 19 2016 03:46:32 Jeremy Huddleston Sequoia wrote: > > TMPDIR points into /var/folders. > > Yes, and it looks like those do get cleared out on boot. > > Note, however, that this particular case relates to the cache dir, not tmp > (C, not T). Oh, right, but there are icon

Re: codesigning, the macports user (and other users added by MacPorts) and diskspace (IconServicesAgent) [was Re: lldb ...]

On Monday September 19 2016 02:08:12 Jeremy Huddleston Sequoia wrote: >> The icon cache sits in the user's $TMPDIR, and AFAIK that directory is >> emptied at boot. > >No. /tmp is emptied at boot, not /var/tmp and not /var/folders. Did that change after 10.9? I keep a Finder window open on

Re: codesigning, the macports user (and other users added by MacPorts) and diskspace (IconServicesAgent) [was Re: lldb ...]

On Sunday September 18 2016 19:23:01 Jeremy Huddleston Sequoia wrote: >>> Yes, of course it's possible. Don't. There's nothing special about the >>> UID in this case that has anything to do with what you're seeing. >> >> So what does make the difference? > >What is "the difference" that you

Re: codesigning, the macports user (and other users added by MacPorts) and diskspace (IconServicesAgent) [was Re: lldb ...]

On Sunday September 18 2016 17:24:55 Jeremy Huddleston Sequoia wrote: > That all looks as expected for someone on OS X 10.9. launchd2 in 10.10+ did > away with per-user launchd. All domains are managed by the same process. Still, why would a background user without even an interactive shell

codesigning, the macports user (and other users added by MacPorts) and diskspace (IconServicesAgent) [was Re: lldb ...]

Hi, This isn't actually about codesigning but something that may have come up because of my testing in that domain. I got a low disk space warning (for an unrelated reason) and hunting down the space eater I noticed this: {{{ %> id macports uid=502(macports) gid=503(macports)

privileged DBus helpers

Hi, I'd like to draw some attention on something I've been working on, summarised here: https://trac.macports.org/ticket/52257#comment:1 I'd love to find a better solution allowing helpers launched through the system dbus to find the (right) user's session bus, so feedback welcome! Thanks,

Re: [MacPorts] #51689: preserve_runtime_libraries convenience PortGroup

On Friday September 16 2016 16:06:54 Rainer Müller wrote: >Moving the discussion to macports-dev as this is about the >implementation, nothing users should care about. You're not entirely right: users can and should care about ease of updating. I posted to macports-users on purpose, to get the

Re: Fakeroot destrooting [Was: Re: lldb ...]

On Tuesday September 13 2016 01:39:41 Jeremy Huddleston Sequoia wrote: > That's just the nature of things. Yeah, life sucks and all that ... >Do you have 3rd party menu extras? IIRC, you're on 10.9, and 3rd party menu >extras run in SystemUIServer. I frequently got SystemUIServer crashes

  1   2   3   4   5   6   7   >