On 18/01/2018 18:12, Ryan Schmidt wrote:
> Could you report this to the developers of libff so they can fix it?
>
> https://github.com/scipr-lab/libff/issues
Done.
https://github.com/scipr-lab/libff/issues/15
--
Red to red, black to black, switch it on, but stand well back.
This is of course not MP related;
please kindly point me to the appropriate Apple forum.
Create a local file:
user@local$ echo local > /tmp/file
Prepare a file on a remote machine,
with the "same" name, but uppercase:
user@remote$ echo remote > /tmp/FILE
Now copy the remote fil
On 19 January 2018 at 11:23, Jan Stary wrote:
> This is of course not MP related;
> please kindly point me to the appropriate Apple forum.
>
> Create a local file:
>
> user@local$ echo local > /tmp/file
>
> Prepare a file on a remote machine,
> with the "same" name, but uppercase:
>
>
> > This is MacOS 10.13.2. Is this expected?
>
> Yes.
>
> If you want/need a different behaviour, you should reformat your hard
> drive to a case-sensitive file system.
Thanks. I always thought it was case sensitive on MacOS too.
Jan
> On Jan 19, 2018, at 05:23, Jan Stary wrote:
>
> This is of course not MP related;
> please kindly point me to the appropriate Apple forum.
>
> Create a local file:
>
> user@local$ echo local > /tmp/file
>
> Prepare a file on a remote machine,
> with the "same" name, but uppercase:
>
On Jan 19 06:48:37, rlha...@smart.net wrote:
> By default, macOS (like Windows with NTFS filesystem)
> is case-preserving but NOT case-sensitive.
> In other words, names that differ only by case
> refer to the same file.
That's exactly what I was missing. Thanks.
> For a case-preserving but case-
Hi,
What "exception"?
"FILE" is "FILE". "file" is "file".
Nothing to do with each other.
The point is third party applications (and perhaps even some Apple
stuff) is not well tested on anything other than the defaults. So its
far from impossible for there to be applications that internally
>
> The point is third party applications (and perhaps even some Apple stuff) is
> not well tested on anything other than the defaults. So its far from
> impossible for there to be applications that internally are not consistent
> with their naming.
I’ve been working for years on case-sensiti
On 19 Jan 2018, at 15:23, Vincent Habchi wrote:
> I’ve been working for years on case-sensitive HFS+/APFS file systems (coming
> from BSD Unix) and never encountered any problem. Only PyCharm needs an extra
> configuration line to be inserted. But that’s the only side effect I ever
> stumbled u
> On Jan 19, 2018, at 08:44, Jan Stary wrote:
>
> On Jan 19 06:48:37, rlha...@smart.net wrote:
>> By default, macOS (like Windows with NTFS filesystem)
>> is case-preserving but NOT case-sensitive.
>> In other words, names that differ only by case
>> refer to the same file.
>
> That's exactly
I’m trying to update MacPorts on some old computers running 10.6.8. I decided
to go with a fresh installation on a test machine, removing the existing
/opt/local, before hopefully do the same on the main server.
I successfully installed many of the packages my group use routinely, but with
sev
On Fri, Jan 19, 2018 at 03:23:11PM +0100, Vincent Habchi wrote:
> > The point is third party applications (and perhaps even some Apple
> > stuff) is not well tested on anything other than the defaults. So
> > its far from impossible for there to be applications that
> > internally are not consist
> On Jan 19, 2018, at 09:53, db wrote:
>
> On 19 Jan 2018, at 15:23, Vincent Habchi wrote:
>> I’ve been working for years on case-sensitive HFS+/APFS file systems (coming
>> from BSD Unix) and never encountered any problem. Only PyCharm needs an
>> extra configuration line to be inserted. Bu
Hi,
I think you cut from the list of responses the useful ones. Most
probably one of the ones you cut was showing that the connection was
rejected due to the use of an insecure SSL version, or similar.
Please post the complete log, compressed to save space.
cheers Chris
On 19/01/18 15:59, F
On 19 Jan 2018, at 17:09, "Richard L. Hamilton" wrote:
> At a mere guess, I'd say there'd be very little of that. Most of the code
> originated on Linux or one of the *BSD's; and most of them would default to
> case-sensitive filesystems, even if they had the option. So their code would
> be
Hi,
Here it is, but I wonder whether such a SSL version requirement is per-package,
because I had no problem in installing a large number of packages before
finding this issue.
Thanks for looking into it!
Franco
debug10.6.8.txt.gz
Description: GNU Zip compressed data
> On 19 Jan 2018, at
On 19 Jan 2018, at 8:44, Jan Stary wrote:
On Jan 19 06:48:37, rlha...@smart.net wrote:
[...]
but for backwards compatibility with macOS's pre-Unix ancestors,
Huh. What are those?
Not technically "pre-Unix" but rather "pre-MacOS X." MacOS X (i.e. 10.0)
was the first version derived from t
On 19 Jan 2018, at 11:09, Richard L. Hamilton wrote:
On Jan 19, 2018, at 09:53, db wrote:
[...]
But since this is MacPorts, I wonder if anyone has had problems
specifically with a port not working and crashing.
At a mere guess, I'd say there'd be very little of that. Most of the
code or
Hi,
So indeed the issue is
---> Attempting to fetch decorator-4.2.1.tar.gz from
https://files.pythonhosted.org/packages/source/d/decorator
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Spe
Hi,
On Fri, Jan 19, 2018 at 03:53:15PM +0100, db wrote:
> But since this is MacPorts, I wonder if anyone has had problems
> specifically with a port not working and crashing.
Remember that our buildbots use case-sensitive HFS, so we would usually
notice if a port fails to build due to case-sensi
On 2018-01-19, at 10:41 AM, Christopher Jones wrote:
> Dload Upload Total SpentLeft Speed
> 0 00 00 0 0 0 --:--:-- 0:00:01 --:--:--
> 0DEBUG: Fetching distfile failed: error:1407742E:SSL
> routines:SSL23_GET_SERVER_H
Hi Ken,
thanks, will look at that
Franco
> On 19 Jan 2018, at 19:52, Ken Cunningham
> wrote:
>
>
> On 2018-01-19, at 10:41 AM, Christopher Jones wrote:
>
>
>>Dload Upload Total SpentLeft Speed
>> 0 00 00 0 0 0 --:--:--
On 2018-01-19, at 11:55 AM, Franco Vaccari wrote:
> Hi Ken,
>
> thanks, will look at that
>
> Franco
FYI:
$ sudo port -d fetch py36-decorator
DEBUG: Changing to port directory:
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/python/py-decorator
DEBUG: OS darwin/10.8
On Jan 19, 2018, at 11:46, Franco Vaccari wrote:
> Here it is, but I wonder whether such a SSL version requirement is
> per-package, because I had no problem in installing a large number of
> packages before finding this issue.
The people who run the servers that distribute python-related file
On Jan 19, 2018, at 12:41, Clemens Lang wrote:
> On Fri, Jan 19, 2018 at 03:53:15PM +0100, db wrote:
>> But since this is MacPorts, I wonder if anyone has had problems
>> specifically with a port not working and crashing.
>
> Remember that our buildbots use case-sensitive HFS, so we would usuall
On Fri, 19 Jan 2018, Jan Stary wrote:
This is MacOS 10.13.2. Is this expected? I see it but I don't believe
it.
MacOS has a broken filesystem; case is preserved but not honoured i.e.
"file" is the same as "FILE" is the same as "FiLe" etc.
This plays merry hell with my RSYNC backups to/from
On Jan 19 14:18:00, jon...@hep.phy.cam.ac.uk wrote:
> The point is third party applications (and perhaps even some Apple stuff) is
> not well tested on anything other than the defaults. So its far from
> impossible for there to be applications that internally are not consistent
> with their naming.
On 2018-01-19, at 7:24 PM, Uli Wienands wrote:
> Maybe someone else can tell me what I may do differently? Zipped logfile is
> attached
>
> Thanks in advance,
>
> Uli
>
error:
:info:build Undefined symbols:
:info:build "_strnlen", referenced from:
:info:build _main in sldtoppm.o
:in
On 2018-01-19, at 9:33 PM, Ken Cunningham wrote:
>
> On 2018-01-19, at 7:24 PM, Uli Wienands wrote:
>
>> Maybe someone else can tell me what I may do differently? Zipped logfile is
>> attached
>>
>> Thanks in advance,
>>
>> Uli
>>
>
> error:
>
> :info:build Undefined symbols:
> :info:buil
On 2018-01-19, at 9:59 PM, Ken Cunningham wrote:
>>
>> error:
>>
>> :info:build Undefined symbols:
>> :info:build "_strnlen", referenced from:
>> :info:build _main in sldtoppm.o
>> :info:build ld: symbol(s) not found
>>
>
>
> Not clear - I just installed it without any issue, without
On 20 January 2018 at 04:24, Uli Wienands wrote:
> I am trying to install Octave on OS X 10.6 Snow Leopard.
>
> Running sudo port install octave the first time (after selfupdate) updates a
> bunch of already installed deps. It then chokes on installing something
> called netpbm.
>
> Futzing aroun
31 matches
Mail list logo
