By popular request I'm taking this to the dev ML...
So I'm trying to convert my +libsymlinks convenience variant into a ditto
subport, qt4-mac-transitional (better name suggestions still welcome).
I'm stuck at the stage where I simply have
subport ${name}-transitional {
}
if { ${subport} eq
On Friday December 12 2014 12:08:28 Brandon Allbery wrote:
I have yet to figure out the rules here, but one thing I tripped over when
I was experimenting with subports is that this can be recursive. That is,
if you select the subport, then $name is the subport name and the subport
declaration
'evening!
I finally got around to finishing up (or almost) my draft version for a qt4-mac
port that can live alongside other (future) Qt port versions installed with the
same approach: see https://trac.macports.org/ticket/46238 .
Related submissions:
https://trac.macports.org/ticket/46239
On Tuesday December 16 2014 11:25:01 Ryan Schmidt wrote:
And a FreeBSD build is supported but would be considered experimental if
you read on the MacPorts
site.
Yes, MacPorts itself should be installable on non-OS X operating systems.
However, the collection of ports we have in
Hello,
Is there a way to use p1 patches with the patchfiles command?
Or, alternatively, is there a command to convert from p1 to p0 patches? Not
that I can't do it manually, but that quickly gets considerably more
error-prone than doing it in software...
Cheers,
René
On Wednesday December 17 2014 23:41:35 Marko Käning wrote:
Hi,
best is to prepare the diff in such a way that you don’t need to use stg like
---
patch.pre_args -p1
see https://guide.macports.org/#reference.phases.patch
Sh@@t, and I thought I'd already searched that page for an
On Sunday December 21 2014 17:48:00 Lawrence Velázquez wrote:
Let's keep it on the list.
Oops. It'd help if the list software set the proper return address... ;)
The port itself doesn't do anything. The compiler-rt build system uses $CC
and $LD to determine whether particular architectures
On Monday December 22 2014 21:05:39 Joshua Root wrote:
What's to monitor? Reply goes to the sender,
Most of my other lists make a reply go to the list, because that's what you
usually want (as also evidenced by the couple of keep this on the list I've
gotten)
Reply to List goes to
the list
On Sunday December 21 2014 21:03:14 Lawrence Velázquez wrote:
In the meantime, with these changes, xcodebuild and xcrun behave exactly
the way they would if Xcode where the selected tool chain.
The bootstrapped compiler is not functioning correctly with the detected OS X
SDK. Perhaps it
On Monday December 22 2014 12:43:46 Lawrence Velázquez wrote:
Well, invoking /usr/bin/clang directly will of course use the CLT version.
No. As I said, invoking /usr/bin/clang invokes the compiler in your active
tools directory.
We're saying the same thing (except that my statement was
On Monday December 22 2014 15:33:44 Lawrence Velázquez wrote:
Sorry, but no. Read the xcrun(1) man page. Despite its name (which you're
reading way too much into), it's intended to invoke the tools in the active
developer directory. It's intended to let developers switch between
toolchains
Hi,
I just noticed the following:
# port rev-upgrade
--- Scanning binaries for linking errors
Warning: Error parsing file /opt/local/bin/readcd: Error opening or reading file
Warning: Error parsing file /opt/local/sbin/rscsi: Error opening or reading file
Warning: Error parsing file
On Tuesday December 23 2014 13:33:16 Clemens Lang wrote:
Hi
IIRC, OS X no longer allows setuuid/setguuid, or only under some conditions.
Isn't that something that ought to be addressed in the post-destroot?
I'd vote for removing the offending flags if they cannot have their intended
Hello,
Attached is a draft for a port:libpgf portfile, basically following Gilles
Gaulier's instructions at
https://projects.kde.org/projects/extragear/graphics/digikam/digikam-software-compilation/repository/revisions/master/entry/README.MACOSX#L62
.
It's a prerequisite for digikam versions
On Wednesday December 24 2014 21:47:11 Ian Wadham wrote:
Without having really looked at the code, have you tried NOT doing that
(possibly after checking whether it has the required privileges)?
I did, but the KDE ReviewBoard jockeys pooh-poohed that. In the end I
modified
Well, yeah,
On Wednesday December 24 2014 01:39:23 René J.V. Bertin wrote:
Hello,
Attached is a draft for a port:libpgf portfile, basically following Gilles
Gaulier's instructions at
On Wednesday December 24 2014 15:07:40 Ryan Schmidt wrote:
Hi,
Any port install will first try to upgrade dependencies.
Yeah, that's what I also realised thinking about it some more (and then saw it
confirmed when `-n` had the intended effect).
Off the top of my head I don't see a problem
On Thursday December 25 2014 00:51:33 Mihai Moldovan wrote:
Actually, it is. Without running portindex first, the port will not be
recognized as outdated.
That's not my experience. I've routinely bumped version and revision numbers in
my local portfiles, without running portindex.
R.
Hello
and best for 2015!
I wonder, has anyone tried to use ninja instead of make for building ports? I
keep hearing it's orders of magnitudes faster, though that might be true mostly
for incremental builds.
Still, any performance gain could be of interest for larger ports, or even huge
ones
On Saturday January 24 2015 11:05:48 René J.V. Bertin wrote:
See #44414. I think the eventual goal is to remove the `quartz` variant and
enable that backend on OS X always. This will simplify the ports and, more
importantly, dependencies on them.
Hope we can find a solution that's
On Friday January 23 2015 11:48:49 René J.V. Bertin wrote:
I'll upload the current Portfile drafts to the existing infinality tickets on
trac
https://trac.macports.org/ticket/44148#comment:12
R
___
macports-dev mailing list
On Saturday February 07 2015 12:41:37 Jean-Baptiste Kempf wrote:
Good luck with that. My experience with that track is that they will just
close your ticket and tell you to piss off.
Where did we ever tell you to piss off? Who insulted you? When?
Matter of speaking and a personal
On Saturday February 07 2015 13:23:36 Jean-Baptiste Kempf wrote:
It's funny how VLC on Brew works fine and is used, notably by tomahawk
(pure Qt application) and we never ever had a problem with them.
Ah, but VLC used to work fine in MacPorts too, up to and including 2.1.5 . With
patches,
On Saturday February 07 2015 14:24:29 Jean-Baptiste Kempf wrote:
Oh, yes:
https://github.com/tomahawk-player/homebrew-tomahawk/blob/master/vlc.rb
So they actually apply patches that are specific to tomahawk, rather than
provide a VLC whatever they call it?
Are you really sure VLC git/2.2
On Saturday February 07 2015 16:48:46 Jean-Baptiste Kempf wrote:
Yes, it is at fault. Hacking our buildsystem, and then attacking us,
because of that, is wrong.
MacPorts' overall approach is not wrong, that's what I meant. It may seem
surprising to some that people might want to run FOSS
FYI: I've made some more changes to port:vlc, I'd appreciate if someone could
check them out.
They're required for port:phonon-backend-vlc (on which I'm working) to function.
Thanks,
R.
-- Forwarded Message --
Subject: Re: [MacPorts] #46748: update to port:vlc (Portfile,
On Sunday February 08 2015 12:00:20 Jean-Baptiste Kempf wrote:
Look, I'm sorry that you got a copy of a message that wasn't intended for
your eyes. That's all I will say about this.
It's a public mailing list, publicly archived, where you insult me.
So, after accusing us to insult you,
On Sunday February 08 2015 09:13:37 Jeremy Whiting wrote:
After reading man environ on both systems I've submitted a review request
that builds on both machines also https://git.reviewboard.kde.org/r/122481/
Saw that; looks good. And I see you figured out that _environ was just the way
the
On Sunday February 08 2015 22:09:29 VideoLAN's Jean-Baptiste Kempf wrote:
Moreover, you called me and insulted me personally on a public mailing-list.
No. I don't know if Jeremy called you (I doubt he'd waste money on an
international call to a cell) but I certainly didn't.
And no one insulted
On Thursday January 15 2015 19:25:38 Mojca Miklavec wrote:
So I'm still stuck with gcc-4.2-only at the moment.
I'm not asking for libc++ on PPC. I know that this might require quite
a bit of effort, but I would like to know if *any* slightly more
modern compiler could be built and used.
On Tuesday January 20 2015 10:35:54 Daniel J. Luke wrote:
it's generally considered rude to redirect private mail to a mailing list.
Different cultures, different considerations of what's rude.
It also didn't occur to you apparently that I may not have been able to test
things myself because
On Tuesday January 20 2015 14:22:23 Lawrence Velázquez wrote:
On Jan 20, 2015, at 7:08 AM, René J.V. Bertin rjvber...@gmail.com wrote:
Does `upgrade` work like `install` would if you have just done a manual
destroot?
`port destroot` does not actually install anything, so no.
Sorry,
On Tuesday January 20 2015 14:34:30 Lawrence Velázquez wrote:
`port upgrade --force` is basically a `port install` that's interrupted
between the install and activate phases by the deactivation of the old port.
Eh? Activating a newly installed version always deactivates the old port, if
Hi,
I'm reworking my freetype and fontconfig infinality variants. The freetype
+infinality variant will have a runtime dependency freetype-infinality, a
(sub)port that serves mostly to introduce the versioning information for the
Infinality patches, but also installs a few text files. It is
On Tuesday January 20 2015 15:38:17 Lawrence Velázquez wrote:
Eh? Activating a newly installed version always deactivates the old port,
if present, no?
I don't know, off the top of my head. Maybe.
Well, in any case *installing* a new version (which is what I should have
written)
On Wednesday January 21 2015 14:16:38 Lawrence Velázquez wrote:
The freetype +infinality variant will have a runtime dependency
freetype-infinality, a (sub)port that serves mostly to introduce the
versioning information for the Infinality patches, but also installs a few
text files.
On Wednesday January 21 2015 18:03:45 Lawrence Velázquez wrote:
Those patches evolve, and thus have a version number, which is simply a
date. If it were me, I'd put that version number into the revision, which
corresponds almost perfectly to the intended use of that variable.
No, it
On Monday January 19 2015 09:24:21 Daniel J. Luke wrote:
I know there's the -o option, but the times I tried it it's often given me
hard-to-describe side-effects.
maybe it would make sense to describe/debug/fix these side effects?
It would, if I could. I'd have to start using -o again,
Hi,
Since we're discussing the way MacPorts does its stuff internally ... :)
Is there or could we have an option to disable (or ask confirmation before) the
automatic port clean when a portfile has changed?
I know there's the -o option, but the times I tried it it's often given me
On Monday January 19 2015 16:55:13 Mihai Moldovan wrote:
Debian's default on powerpc is gcc 4.9.2:
What about Minix? FreeBSD? GNU HURD?
What about them?
Seriously, the FSF compiler won't cut it on OS X. Just as one example,
it can't produce fat binaries (i.e., binaries with multiple
On Monday January 19 2015 12:22:13 Brandon Allbery wrote:
On Mon, Jan 19, 2015 at 12:14 PM, Mojca Miklavec mo...@macports.org wrote:
Does one need the server edition of 10.5 to be able to install it in a
virtual machine?
Yes.
No. To have the right, yes. ;)
R.
On Monday January 19 2015 15:41:13 Lawrence Velázquez wrote:
What purpose does it serve to include target header paths while compiling?
Beats me too.
Well, not entirely. Qt has been moving away from a single monolithic build to
separate components, and indeed if you look at the Debian
On Friday January 16 2015 08:27:18 Craig Treleaven wrote:
IIUC, your post isn't related to Qt4/5 co-installability, but to how
Qt-specific versions of ports distinguish themselves.
https://trac.macports.org/ticket/46575
If I understand correctly, Charm will create subports ala:
qt5-charm
On Friday January 16 2015 14:52:35 Craig Treleaven wrote:
The replaced_by keyword (and obsolete PortGroup) support what you've
described:
https://guide.macports.org/#development.practices.rename-replace-port
Interesting.
Qt4 (or just bit rot) are going to push projects
Bit rot, in
On Friday January 16 2015 16:43:45 Lawrence Velázquez wrote:
To be equally blunt: the user is always right.
This is not our general attitude towards this matter.
And I rarely work on ports that I don't use or intend to use myself, so ... :)
We prefer users not be allowed to choose their
On Wednesday January 14 2015 13:06:01 Mojca Miklavec wrote:
There might be one, but that doesn't really help us to make the
package(s).
To be very honest, I seem to recall that the script kind of makes packaging
unnecessary because it downloads everything required without doing (too many)
On Wednesday January 14 2015 14:44:12 Jeremy Whiting wrote:
Jeremy Whiting has posted comments on this change.
Jeremy, could you summarise the changes please?
Change subject: QStandardPaths: Add XDG_CONFIG_DIRS and XDG_DATA_DIRS paths
on OSX.
On Tuesday January 20 2015 15:27:56 Lawrence Velázquez wrote:
I don't really understand where the state file comes into this. We are
talking about rebuilding and reinstalling a port that is already installed.
Indeed, but in my workflow that usually means incremental rebuilds.
% # whatever
On Tuesday January 20 2015 12:25:32 Michael Dickens wrote:
but that's ugly cumbersome. There has got to be a better way. Any
advice on a robust yet concise way to do this? Thanks! - MLD
Hi Michael,
I suppose you're not supporting any random swig version, so how about doing
what the python
FYI,
I just submitted standalone tickets for variants and patches included in my
qt4-mac concurrent ticket but not related to making Qt4 co-installable :
#46606: qt4-mac noexceptions variant
Ticket URL: https://trac.macports.org/ticket/46606
#46607: qt4-mac +KDE variant.
Ticket URL:
Hello,
The destroot step automatically removes empty directories from the destroot
before finishing. Does it also remove files that should never make it into an
installer tarball? If so, why is .DS_Store not on that list?
R.
___
macports-dev mailing
On Wednesday February 11 2015 14:39:10 Lawrence Velázquez wrote:
Does it also remove files that should never make it into an installer
tarball?
Not that I'm aware of. If for some unfathomable reason a build system
installs a .DS_Store, you should report that as a bug.
Actually, I ran
I'll be uploading a modified portdir to the usual trac ticket.
R.
-- Forwarded Message --
Subject: Re: [Interest] Fwd: Qt 5.4 build error on OS X 10.7
Date: Wednesday February 11 2015, 13:14:46
From: Thiago Macieira
To: inter...@qt-project.org
On Wednesday 11 February 2015
On Tuesday February 10 2015 10:49:40 Arno Hautala wrote:
list. There's no way to ensure they *won't* get a message.
Not by sending to the list, no. But there's always the option of sending to a
hand-picked selection of list members, if there's a reason to limit the
audience.
Censoring the
On Tuesday February 10 2015 17:10:37 Chris Jones wrote:
1) at least is solvable as you can configure your sudoers list to allow
your main user to run your port command (and that command only) through
sudoers without requiring a password.
I know that, but for some reason I've never managed
On Tuesday February 10 2015 12:30:07 Arno Hautala wrote:
Not by sending to the list, no. But there's always the option of sending to
a hand-picked selection of list members, if there's a reason to limit the
audience.
Also something that doesn't require having a public members list.
On Thursday February 12 2015 11:58:33 Jack Howarth wrote:
Jeremy,
So I take it that it is impossible to use MacPort's Xvfb without
abandoning the use of the Xquartz server in /opt/local/X11? That is
rather unfortunate as my experience in packaging over 500 cran modules
for fink was that at
On Thursday February 12 2015 12:33:53 Clemens Lang wrote:
You should be aware of the security implications of this change. For example,
sudo port edit vim gets you arbitrary code execution and arbitrary file
access as
root.
Exactly one of the reasons I don't like rendering sudo implicit,
On Thursday February 12 2015 11:28:15 Joshua Root wrote:
Even if you don't deliberately do anything between the fork and exec,
it's possible for things to happen because of signals and the like. This
is one reason why Apple recommends using posix_spawn.
Do you have a valid link to that? The one
On Thursday February 19 2015 11:58:46 Mojca Miklavec wrote:
That sometimes really annoys me. Is this additional piece of
information easy to print in advance or does it require dirty
hacks/lots of code?
I agree. It also happens that for (some reason) MacPorts decides to upgrade a
dependency
On Tuesday February 17 2015 13:17:49 Ian Wadham wrote:
Ian installed qt5-mac-devel in conjunction with the standard qt4-mac port.
No I didn't. I deactivated qt4-mac and all of its dependents I have installed.
I know, but I presumed that you had reactivated port:qt4-mac. I think that
ought to
Hello,
Is there any support in MacPorts for circular dependencies (as far as such a
thing is possible)?
I'm building the freetype +infinality version with harfbuzz support, which
depends on cairo, which ultimately depends on freetype. Would that make it
impossible to install that port variant
On Wednesday January 28 2015 18:27:35 Lawrence Velázquez wrote:
The libraries in XcodeDefault.xctoolchain aren't even versioned.
There's no need for that since only a single version is present at any given
time.
I never meant to argue that using a shared library inside Xcode would be a good
On Wednesday January 28 2015 15:23:04 Lawrence Velázquez wrote:
That directory looks like it's very much for Xcode's internal use only.
% ls -1 $(xcode-select -p)/Toolchains/XcodeDefault.xctoolchain/usr/lib
Really now, even if that's true for the other stuff in there, it shouldn't be
Hi,
I'm still polishing my proposed changes to the Qt ports, and am beginning to
wonder if I shouldn't replace the +KDE variant by a qt5-mac[-devel]-KDE
subport. At this point the +KDE variant isn't required, but it does have a
patch or 2 that are strongly suggested to improve the KDE4
On Monday January 26 2015 04:06:34 Ryan Schmidt wrote:
I forgot about that as well. But what compression algorithm does
hfscompression use, and why are you so sure it will save way more disk space
than xz? Have we tested that? Compressed disk images, for example,
originally used zlib
On Tuesday January 20 2015 13:20:03 René J.V. Bertin wrote:
To add another observation: the Qt 5.4 archive tarball shrinks by a bit over
26% when using xz instead of bzip2:
6591042 99M -rw-r--r-- 1 root admin 99M Jan 12 20:37
qt5-mac-devel-5.4.0_1+KDE.darwin_13.x86_64.tbz2
8507590 73M
On Monday January 26 2015 04:55:57 Ryan Schmidt wrote:
You're right, MacPorts doesn't have a good way to handle third-party patches
that are independently maintained and independently versioned. I've been
avoiding this ticket of yours, because I don't like such patches. The
developer of
Hi,
I've been trying to figure out why font rendering under X11 benefited much less
from the Infinality patches on my 10.9 install than on my 10.6 install. I think
I found it, in the end. Nothing to do with the OS version, of course.
When I re-activate pango@1.36.8_0+universal+x11 instead of
On Wednesday January 28 2015 09:21:46 Jeremy Huddleston Sequoia wrote:
What variants did you select when installing llvm-3.4 and clang-3.4? If you
installed with +assertions, that would certainly by why you see differences.
The standard variant for llvm, to have binary packages, and
Hi,
I'm using KDevelop a lot these days, and have thus been ogling the kdev-clang
plugin that brings llvm/clang integration to that IDE.
Ideally I'd build that against the Apple-provided toolchain, just to prevent
having to have multiple copies of the same version of the toolchain. There's
On Wednesday January 28 2015 10:56:32 Jeremy Huddleston Sequoia wrote:
Would it at least be possible to expand on that. In other words, why?
There are no shipped libraries for you to link against for the headers to be
worthwhile.
I see:
On Saturday January 10 2015 17:14:48 Lawrence Velázquez wrote:
Do you expect a command-line foreground job to spawn background jobs that
continue after the foreground job has finished? I sure don't. And such
behavior would give a false impression that port(1) is finished, when it
actually
MacPorts does not currently have any background processes; adding one would
be a major change.
This would also only be useful if there were something else MacPorts could be
doing at the same time in the foreground. I think it would be confusing to
add some sort of vacuum process that
Hi,
I see MacPorts provides a set of keywords to add or delete env. variables to or
from specific phases. Is there a (Tcl) command one can use to set or unset
variables at an appropriate point so it's defined (or missing) appropriately
for all subsequent steps?
If not, can one use
On Sunday January 11 2015 14:26:45 Michael Dickens wrote:
Hi Michael
This variable is designed just for the purpose you need for qt4-mac; it
would not be difficult to add to qt5-mac if it is not already in place.
There's probably a better way to do this, but using a simple variable is
quick
On Sunday January 11 2015 14:49:21 Michael Dickens wrote:
PortGroup (qt4; I assume qt5 too), you'll see an if statement:
{{{
if {![info exists building_qt4]} {
configure.env-append \
QTDIR=${qt_dir} \
QMAKE=${qt_qmake_cmd} \
QMAKESPEC=${qt_qmake_spec} \
On Sunday January 11 2015 18:01:06 Gustaf Neumann wrote:
Is there a (Tcl) command one can use to set or unset variables at an
appropriate point
set environment variable
set ::env(FOO) some value
unset environment variable
unset ::env(FOO)
Thanks :)
Is the namespace (?)
On Monday January 12 2015 09:30:08 Ian Wadham wrote:
In case anyone does not already know, QTDIR is an env variable
a developer can use when developing software based on Qt or
a development (test, non-standard) version of Qt.
I doubt the variable is still required nowadays (which is not to
On Monday January 12 2015 13:59:14 René J.V. Bertin wrote:
I do have Qt5.3.2 installed configured with the same install locations, and
indeed it would seem that at least the 1st error is due to the installed
header being included instead of one from the build tree.
Regarding that
On Monday January 12 2015 14:28:36 Clemens Lang wrote:
Hi,
I deleted your change; the instructions were consistent and correct before.
If they didn't work for you, just must have ran
cd $prefix
rather than
cd $prefix/var/macports/sources
as the how-to says.
Nope, I did the checkout in
On Monday January 12 2015 16:09:26 Clemens Lang wrote:
Nope, I did the checkout in
$prefix/var/macports/sources/svn.macports.org/trunk
using `svn co http://svn.macports.org/repository/macports/trunk; dports`
which
should be the same as the command the how-to gives.
That would check
On Friday January 09 2015 07:28:43 Bradley Giesbrecht wrote:
Is your local tree in sources.conf?
grep -v -E (^ *#|^$) /opt/local/etc/macports/sources.conf
Yes. It's my understanding that is required if you want it to be taken into
account ...
If you used svn instead of rsync port sync you
On Friday January 09 2015 10:33:56 Lawrence Velázquez wrote:
Unless I'm mistaken and it's the other way round, dragonegg is a gcc
front-end to llvm.
It's a GCC plugin that swaps out the backend.
Isn't that another or equivalent way of saying the same (or equivalent) thing?
To provide a
On Friday January 09 2015 13:11:08 Ryan Schmidt wrote:
I've committed this fix to the portgroup in r131321.
Great, glad to have been of help, if I knew this stood a chance for direct
inclusion I'd have attached a patch!
Note that you need to global options (like os.platform) to use them in a
On Friday January 09 2015 16:08:00 Lawrence Velázquez wrote:
It uses `git pull --rebase` or `git svn rebase`, depending on your setup.
Thus, uncommitted/unstashed local changes will cause the Git update to fail,
although `portindex` still runs and updates your indices.
There we go again :)
On Tuesday January 06 2015 13:23:36 Michael Dickens wrote:
Yes, I use Qt4 in my work as well as a bunch of other display
The one installed through MacPorts? That's what I meant; if you do, you'd
already have your test cases up and running ;)
technologies. We're working on transitioning to
On Tuesday January 06 2015 14:08:44 Bradley Giesbrecht wrote:
It is usually easier to get patch reviews if the changes are as few as
possible.
Heh, yes, I know I introduced a couple more variants, but they're actually
intended to speed up things.
I have macports installed in a vm building
On Tuesday January 06 2015 15:16:00 Jeremy Whiting wrote:
Hi Jeremy,
I have port:dbus 1.8.12, and it has
/opt/local/lib/dbus-1.0/include/dbus/dbus-arch-deps.h ...
Might I suggest that if you try to build Qt 5.4 against MacPorts dependencies,
you create an updated Portfile off `port dir
On Friday January 09 2015 12:18:16 Rainer Müller wrote:
Is that correct and if so, is there a way to override the definitions
on a global basis?
Port groups not found in the current ports tree are being looked up in
the ports tree marked with [default] in sources.conf.
That's not what
Correction:
This is not limited to the compiler blacklist portgroup, nor to Linux.
Exactly as I feared, my changes to the qt4, qt5 and kde4 portgroups need to be
copied to the portgroup directory in the default tree if they are to be visible
to all ports and not just to the ports in the local
Hi,
This has been bothering me for a while. Each time I open/reload a Portfile in
vim (my main editor for that kind of file), something is done that makes vim
consider the file edited immediately, while it also thinks there's nothing to
be undone.
I'm guessing it must be due to my own
On Monday January 12 2015 16:23:49 Clemens Lang wrote:
Wait, are you actually using `$prefix` verbatim in the sources.conf? You're
supposed
to replace that with your MacPorts prefix. I didn't even expect it to be
expanded,
and I'd actually say that's a bug.
Yes, indeed I was, seemed
On Monday January 12 2015 19:25:35 Marko Käning wrote:
Weird though, that for some odd reason I couldn’t find your post in the
list’s administrative interface anymore. It got somehow trashed… :(
Heh, the odd reason is that I considered it wasn't necessary to flood
everyone's inbox with a
Hello,
I just stumbled across yet another example of something going wrong with path
case in binary packages, for unclear reasons. A port I'm working on warned it
couldn't find a dependency, and after a bit of searching I saw I have
/opt/local/share/cmake/modules
/opt/local/share/cmake/Modules
On Tuesday February 10 2015 19:30:59 Ryan Schmidt wrote:
Hi Ryan,
I've also made additional changes to make it impossible for me to forget to
use sudo:
Could it be those are indeed quite necessary (i.e. you forgot to list the
changes)? ;)
You're talking about two different things.
You know,
On Tuesday February 10 2015 21:27:07 Craig Treleaven wrote:
PS Some forums can be set up to send you an email
when a sub-forum or topic is updated (after your
last visit). I don't know of any that allow you
to send an email that becomes a posting, however.
Anyone who ever reported a Google
Hi,
I noticed (= became annoyingly aware of the fact) that `port upgrade` does a
deactivate on the current port version before it even starts creating the
archive. Symptoms: while waiting for `port -nvk upgrade --force qt4-mac` to
finish, I got failure messages for starting kio_slave; that's
On Tuesday February 10 2015 10:05:30 Arno Hautala wrote:
Hi,
Just CC them. Most mail clients / list servers will consolidate the
duplicate message and even if it doesn't it's not the worst thing to
I realised later that I should have evoked knowledge of how many copies a
given person would
On Tuesday February 10 2015 16:41:19 Arno Hautala wrote:
If you're on BCC, Mailman wouldn't be able to do anything about it.
Evidently. Is it clever enough to take various ways of representing the To: or
CC: addressing into account? Basically, does it look at the pure email address,
or does
1 - 100 of 632 matches
Mail list logo
