Apparently the URL to use is now:
https://files.pythonhosted.org/packages/source/p/prompt_toolkit/
and that scheme should work for the foreseeable future. (The pypi.io
version will just redirect to the above.)
- Josh
On 2016-5-14 13:33 , Ivan Larionov wrote:
I just run into this issue.
Can
I just run into this issue.
Can confirm that change like this works:
-master_siteshttps://pypi.python.org/packages/source/p/prompt_toolkit/
+master_siteshttps://pypi.io/packages/source/p/prompt_toolkit/
Has anyone updated pypi master_sites?
--
With best regards, Ivan Larionov.
On 13/05/2016 20:29, Xu Xin wrote:
On Fri, May 13, 2016 at 10:30 AM, Joshua Root wrote:
On 2016-5-14 00:10 , Vincent Habchi wrote:
Hi there,
why does tk +quartz -x11 depend on libX11? I commented out that line in
the Portfile and it compiled fine.
Leaving that (dangling) dependency alive mea
On Fri, May 13, 2016 at 10:30 AM, Joshua Root wrote:
> On 2016-5-14 00:10 , Vincent Habchi wrote:
>>
>> Hi there,
>>
>> why does tk +quartz -x11 depend on libX11? I commented out that line in
>> the Portfile and it compiled fine.
>> Leaving that (dangling) dependency alive means installing a lot o
> On May 12, 2016, at 12:57, David Evans wrote:
>
> On 5/12/16 2:53 AM, MacPorts wrote:
>> #51287: Inkscape crashes on startup if enchant is installed with +applespell
>> ---+--
>> Reporter: jo.vanoost@… | Owner: devans@…
>> Type:
On Friday May 13 2016 10:52:58 Brandon Allbery wrote:
> Oh, they changed that finally. I admit I hadn't looked at it on 10.11 (I
> only recently upgraded the Mac from 10.9). It doesn't even mention ppc any
> more.
Apparently you also didn't look at it on 10.9 because that's what I'm still
using m
Tk definitely needs X11 headers. You may be picking them up elsewhere on your
system.
> On May 13, 2016, at 10:40 AM, Vincent Habchi wrote:
>
> Hi Josh!
>
>> On 13 mai 2016, at 16:30, Joshua Root wrote:
>>
>> As the comment in the quartz variant in the portfile says:
>> # tk.h still includ
Oh, they changed that finally. I admit I hadn't looked at it on 10.11 (I
only recently upgraded the Mac from 10.9). It doesn't even mention ppc any
more.
Maybe Apple's getting the idea that the main thing they'd accomplished was
to confuse developers.
On Fri, May 13, 2016 at 10:46 AM, René J.V.
On Friday May 13 2016 10:11:50 Brandon Allbery wrote:
> Remember that OS X goes to great lengths to hide 32 vs. 64 bit
> distinctions; 32 bit OS X kernels were perfectly capable of running 64 bit
> binaries on 64-bit CPUs, at least on Intel. So some of this comes down to
True.
> "Apple so decre
On Fri, May 13, 2016 at 10:40 AM, Vincent Habchi wrote:
> Yep, but I commented the line below, and it compiled fine. So this comment
> must somehow be outdated.
I'd only trust that if you built it in trace mode.
--
brandon s allbery kf8nh sine nomine associates
a
Hi Josh!
> On 13 mai 2016, at 16:30, Joshua Root wrote:
>
> As the comment in the quartz variant in the portfile says:
> # tk.h still includes and uses types from X11/Xlib.h
Yep, but I commented the line below, and it compiled fine. So this comment must
somehow be outdated.
V.
__
On 2016-5-14 00:10 , Vincent Habchi wrote:
Hi there,
why does tk +quartz -x11 depend on libX11? I commented out that line in the
Portfile and it compiled fine.
Leaving that (dangling) dependency alive means installing a lot of cruft.
As the comment in the quartz variant in the portfile says:
On Fri, May 13, 2016 at 4:07 AM, René J.V. wrote:
> I'm curious though, what ports rely on i386 meaning "Intel, 32 or 64 bit"
> rather than "Intel, 32 bit", directly in their Portfile rather than
> indirectly through "base"? I find that confusing and it often makes me
> pause when I see the term
Hi there,
why does tk +quartz -x11 depend on libX11? I commented out that line in the
Portfile and it compiled fine.
Leaving that (dangling) dependency alive means installing a lot of cruft.
Cheers!
Vincent
___
macports-dev mailing list
macports-dev@l
On Friday May 13 2016 13:16:00 Niels Dettenbach wrote:
> Just my two cents: You may take a look at the pkgsrc project which is by self
> explanation possibly that what you are looking for. I'm not sure how far
> MacOS is still provided directly but if there are peoples want that -
> adaption to
On Friday May 13 2016 05:59:15 Ryan Schmidt wrote:
> Most MacPorts users (in fact, all but you, I would expect) will never use
> MacPorts on Linux, so any issues reported that are specific to Linux would
> likely go unfixed.
Likely. But I've posted about my little project before, and am inclined
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am 13. Mai 2016 12:52:03 MESZ, schrieb "René J.V. Bertin" :
>> There are other package managers that can be used to install software
>on Linux.
>
>I've been finding it very useful to use the same ports to install the
>same software on my various syst
On May 13, 2016, at 5:52 AM, René J.V. Bertin wrote:
> On Friday May 13 2016 05:00:21 Ryan Schmidt wrote:
>
>> I'm not giving that any thought. MacPorts is about installing software on OS
>> X.
>
> You mean it really should be renamed to OSXPorts? ^^
The "Mac" in MacPorts indicates that it w
Am 13.05.16 um 12:52 schrieb René J.V. Bertin:
Doesn't Tcl have the equivalent of sizeof(void*) or sizeof(size_t)?
see
puts $::tcl_platform(wordSize)
puts $::tcl_platform(pointerSize)
puts $::tcl_platform(machine)
-g
___
macports-dev mailing
On Friday May 13 2016 05:00:21 Ryan Schmidt wrote:
> I'm not giving that any thought. MacPorts is about installing software on OS
> X.
You mean it really should be renamed to OSXPorts? ^^
> MacPorts developers and maintainers do not have expertise about installing
> software on Linux.
I hav
> On May 13, 2016, at 4:49 AM, René J.V. Bertin wrote:
>
> On Friday May 13 2016 04:23:24 Ryan Schmidt wrote:
>
>> I think we've established that os_arch should only be i386 or powerpc.
>
> Side-ways related: do we have an idea (or can we have an estimate) how many
> PPC Macs are still in use
Hiya,
Any update on the git ssl certificate issues when trying to close
repositories?
I'm aware it affects ports for git-flow and ansible.
https://trac.macports.org/ticket/49539
https://trac.macports.org/ticket/50467
https://trac.macports.org/ticket/50469
I suspect it's affects more ports and p
On Friday May 13 2016 04:23:24 Ryan Schmidt wrote:
>I think we've established that os_arch should only be i386 or powerpc.
Side-ways related: do we have an idea (or can we have an estimate) how many PPC
Macs are still in use but running Linux in order to have a more up-to-date OS?
Supposing tha
On May 13, 2016, at 4:18 AM, René J.V. Bertin wrote:
> On Friday May 13 2016 03:54:26 Ryan Schmidt wrote:
>
>>> If build_arch is not set then os.arch is used as a fallback. No doubt we
>>> don't detect an appropriate default for build_arch on Linux.
>>
>> Yes I see in get_canonical_archs in sr
On Friday May 13 2016 03:54:26 Ryan Schmidt wrote:
>> If build_arch is not set then os.arch is used as a fallback. No doubt we
>> don't detect an appropriate default for build_arch on Linux.
>
>Yes I see in get_canonical_archs in src/port1.0/portutil.tcl where it uses
>os.arch if build_arch is e
On Friday May 13 2016 03:27:54 Ryan Schmidt wrote:
>> and it's probably a good idea to leave that style in
>> place even after the release version of the dependency is produced. It's
>> probably not because llvm 3.8.1 goes stable that there will be no 3.8.1+i
>> that
>> could be tested as a -d
On May 13, 2016, at 3:48 AM, Joshua Root wrote:
> On 2016-5-13 18:13 , Ryan Schmidt wrote:
>>
>> On May 13, 2016, at 3:07 AM, René J.V. Bertin wrote:
>>
>>> On Friday May 13 2016 15:21:53 Joshua Root wrote:
>>>
>> Side-ways related: why is os_arch reset to i386 from x86_64 on line 636?
>>
On May 13, 2016, at 3:45 AM, René J.V. Bertin wrote:
> On Friday May 13 2016 03:13:19 Ryan Schmidt wrote:
>
>> os_arch is the way ports and probably MacPorts base differentiates an Intel
>> computer from a PowerPC computer. It is not a mechanism to determine the
>> bitness; if you need to dete
On 2016-5-13 18:13 , Ryan Schmidt wrote:
On May 13, 2016, at 3:07 AM, René J.V. Bertin wrote:
On Friday May 13 2016 15:21:53 Joshua Root wrote:
Side-ways related: why is os_arch reset to i386 from x86_64 on line 636? >From
what I've seen that causes packages to be labelled and registered as
On Friday May 13 2016 03:13:19 Ryan Schmidt wrote:
>os_arch is the way ports and probably MacPorts base differentiates an Intel
>computer from a PowerPC computer. It is not a mechanism to determine the
>bitness; if you need to determine bitness, use other methods, such as
>build_arch and univer
> On May 12, 2016, at 3:51 AM, René J. V. Bertin wrote:
>
> Ryan Schmidt wrote:
>
>
>>> is released as a stable version it should be renamed to llvm-3.9. The
>>> ports llvm-3.9 and llvm-3.9-devel are still drop-in replacements.
>>
>> This makes it much more difficult on developers when the ti
On May 13, 2016, at 3:07 AM, René J.V. Bertin wrote:
> On Friday May 13 2016 15:21:53 Joshua Root wrote:
>
Side-ways related: why is os_arch reset to i386 from x86_64 on line 636?
>From what I've seen that causes packages to be labelled and registered as
i386 (i.e. 32bit) when b
On Friday May 13 2016 15:21:53 Joshua Root wrote:
>>> Side-ways related: why is os_arch reset to i386 from x86_64 on line 636?
>>> >From what I've seen that causes packages to be labelled and registered as
>>> i386 (i.e. 32bit) when built on 64bit linux.
>>
>> In MacPorts, os_arch is i386 on all
33 matches
Mail list logo
