Paulo, yes, I know for Debian that it starts with
https://wiki.debian.org/DebianMentorsFaq, but I can't claim to have gone
through the process myself. My sense is that for Swift to be a first-class
citizen in the Debian or Ubuntu repos that someone at Apple should (not
must) sponsor it.
On Sun, S
I've been providing an apt-get repository for Xenial, Wily, and Trusty (see
http://dev.iachieved.it/iachievedit/swift-3-0-for-ubuntu-16-04-xenial-xerus/
as an example) and the name I chose was swift-3.0, similar to gcc-4.6,
gcc-4.8, clang-3.6, etc. In addition I decided not to break the packages
u
b.com/apple/swift/pull/3222
>
> 2016-06-26 7:42 GMT+09:00 Dmitri Gribenko via swift-dev <
> swift-dev@swift.org>:
>
>> + Michael, who has been working on CMake changes.
>>
>> On Sat, Jun 25, 2016 at 2:48 PM, Joseph Bell via swift-dev
>> wrote:
>> >
Michael, as I mentioned earlier I upgraded my systems to 3.4.3 and resumed
building Swift. Regarding flipping the switch, I'm assuming you mean
replacing
cmake_minimum_required(VERSION 2.8.12)
with 3.4.3 in all of the various CMakeLists.txt files?
Joe
On Wed, Jun 29, 2016 at 12:13 PM, Michael
s something to do with Cmake). I have been able to
> consistently build on 15.10 and 16.04.
>
> On Sat, Jun 25, 2016 at 5:42 PM, Dmitri Gribenko
> wrote:
>
>> + Michael, who has been working on CMake changes.
>>
>> On Sat, Jun 25, 2016 at 10:14 AM, Joseph Bell via
On Sat, Jun 25, 2016 at 10:14 AM, Joseph Bell via swift-dev
> wrote:
> > Confirmed that I can reproduce this on my system (x86_64 Ubuntu14.04) :
> > build 1585 failed
> > https://ci.swift.org/job/oss-swift-package-linux-ubuntu-14_04/1585/ with
> >
> > CMake Error a
Howdy,
I've opened https://bugs.swift.org/browse/SR-1908 against Thread (NSThread)
in Foundation. I noticed several weeks ago while working with it on a
Raspberry Pi 3 that Thread.start() eventually doesn't actually start a
thread. This was found a lot faster on the Pi 3 than on a largish x86
se
Howdy,
I noticed in a build today that the output of swift --version has changed.
Today's build:
swift --version
Swift version 3.0-dev
Target: x86_64-unknown-linux-gnu
Earlier this week:
swift --version
Swift version 3.0-dev (LLVM fc970689d4, Clang 460d629e85, Swift 1f2b5ee7fb)
Target: x86_64-un
Confirmed that I can reproduce this on my system (x86_64 Ubuntu14.04) :
build 1585 failed
https://ci.swift.org/job/oss-swift-package-linux-ubuntu-14_04/1585/ with
CMake Error at cmake/modules/SwiftSharedCMakeConfig.cmake:134 (include):
include could not find load file:
ClangTargets
Call Sta
Confirmed as well, pulled in Rintaro's fix and was able to turn around an
incremental ARM compile in 30 minutes. Thanks Rintaro!
On Wed, May 4, 2016 at 9:49 AM, Ryan Lovelett
wrote:
> Big help! Thank you Rintaro.
>
>
--
Joseph Bell
http://dev.iachieved.it/iachievedit/
@iachievedit
_
I understand a native ARM compile, much less an incremental ARM compile, is
low on the priority list, but https://bugs.swift.org/browse/SR-1287 ("INSTALL
cannot find readline.so") is hampering x86 incremental builds as well. I
was curious as to whether there were any Cmake experts that have time t
7:52 AM, Ryan Lovelett > wrote:
>
>> On Sun, Apr 24, 2016, at 05:44 PM, Joseph Bell via swift-dev wrote:
>>
>> Well, I thought the REPL issues had all been put to rest, but now I am
>> seeing this on Ubuntu 14.04 (15.10 I do not see it):
>>
>> ➜ package-swif
This error occurs before any downstream packaging (deb) and is failing the
build itself (on the test REPL, it can't even load). Will report back in a
bit.
Joe
On Mon, Apr 25, 2016 at 7:52 AM, Ryan Lovelett
wrote:
> On Sun, Apr 24, 2016, at 05:44 PM, Joseph Bell via swift-dev wrote:
&
Rob, this is a known build bug tracked by
https://bugs.swift.org/browse/SR-1287. I have only been able to reproduce
this by restarting a build after some previous failure. The workaround
(for me at least) is to delete the build directory and restart from the
beginning (not ideal to be sure).
Joe
Well, I thought the REPL issues had all been put to rest, but now I am
seeing this on Ubuntu 14.04 (15.10 I do not see it):
➜ package-swift-3.0 git:(swift-3.0) ✗ ./install/usr/bin/swift
==18928==ASan runtime does not come first in initial library list; you
should either link runtime to your appli
I can confirm that the moving the glib REPL test to XFail does allow a
cleanroom build to succeed on my server, as well confirm that import Glibc
in the REPL fails with the error reported at
https://bugs.swift.org/browse/SR-1109.
-Joe
On Fri, Apr 22, 2016 at 2:00 PM, Mishal Shah via swift-dev <
sw
Indeed, and SR-1109 is still causing the Create installable package step to
fail for 14.04 (
https://ci.swift.org/view/Packages/job/oss-swift-package-linux-ubuntu-14_04/1075/console#console-section-9).
The failure was always there (cannot import Glibc into the REPL) but has
now been exposed since p
I've noticed in Xcode there are a lot of fixits that tell you exactly what
to do to "fix it", and it will do it for you. However, this does not apply
to "does not conform to protocol" errors; I'm wondering if it is possible
for the fixit engine to add methods/properties such that, at a minimum, a
Hi all,
Has anyone looked further at getting the REPL working again on the master
branch builds? Or for that matter installed pexpect on the CI server to
properly fail the build?
Joe
On Fri, Apr 15, 2016 at 10:13 PM, Ryan Lovelett
wrote:
> Facepalm.
>
> On Fri, Apr 15, 2016, at 11:11 PM, Rya
bf4af832e154065bc0bcafffab2dacb839e
> > > 1a8be73f86884bda848cde22885bcd72a17660b2 Mstdlib
> > > :04 04 abf55068f67ee44e2bd52169aa8b988fb8aead28
> > > 41db0f8ddec3281f51c6798dd47c86675b7118b3 Mtools
> > >
> > > [1]
> > >
> https://github.com/apple/swift/commit/c6121
14, 2016 at 8:47 AM, Ryan Lovelett via swift-dev <
swift-dev@swift.org> wrote:
> On Thu, Apr 14, 2016, at 09:17 AM, Joseph Bell via swift-dev wrote:
>
> Howdy,
>
> I've mentioned this once before and didn't get any feedback; I thought I'd
> give it one more shot.
Howdy,
I've mentioned this once before and didn't get any feedback; I thought I'd
give it one more shot.
Has anyone out there tried building, from scratch, the Swift 3.0 package on
Ubuntu? The compile, link, packaging steps all complete successfully, but
then the repl/test-repl-glibc.py fails.
Accidentally (I believe) posted to swift-build-dev.
I do indeed see the error on 15.10 as well now with "missing required
module 'SwiftGblic'", for whatever reason the swift binary being built
cannot do a simple 'import Glibc' without this error coming out:
Welcome to Swift version 3.0-dev (LLVM
Interesting, I am still seeing the Ubuntu 14.04 failing on the integration
tests: repl/test-repl-glibc.py
Failure:
Welcome to Swift version 3.0-dev (LLVM 807b21219f, Clang fa83172882, Swift
9976eff891). Type :help for assistance.
1> import Glibc
error: repl.swift:1:8: error: missing required mo
In the spirit of providing a temporary solution to the request to
https://bugs.swift.org/browse/SR-116, I've been posting .deb packages for
Ubuntu 14.04 and 15.10 on an S3 repository.
The following commands will add the repository to allow installation of
swift-2.2:
wget -qO- http://dev.iachieved
Confirmed that as of the following revs the world builds and all tests
passing:
% swift swiftrevs.swift
swift:c264b1eda0d
llvm:3ebdbb2c7e5
clang:f66c5bb67b9
lldb:37fa5a942ff
cmark:5af77f3c1d7
llbuild:7fba6e6213e
swiftpm:ea137609d80
swift-corelibs-xctest:75d601cd8ca
swift-corelibs-foundation:576e6d
> My fault, I think that ea61c8a should fix it, but I haven’t tested it.
> Can you please let me know if there is still a problem?
>
> Thanks!
>
> -Chris
>
> On Jan 1, 2016, at 10:46 AM, Joseph Bell via swift-dev <
> swift-dev@swift.org> wrote:
>
> I've con
I've confirmed that the lldb failure is with a pristine build environment
as well:
lldb/source/Plugins/ExpressionParser/Swift/SwiftPersistentExpressionState.cpp:146:79:
error: no member named 'getBodyParamPatterns' in 'swift::FuncDecl'
llvm::MutableArrayRef lhs_patterns =
lhs_func_decl->ge
Good morning and Happy New Year.
All repos updated with ./swift/utils/update-checkout --all as of 10AM
Central, and getting a compile failure on:
lldb/source/Plugins/ExpressionParser/Swift/SwiftPersistentExpressionState.cpp:146:79:
error: no member named 'getBodyParamPatterns' in 'swift::FuncDecl
Dallas, see SR-40 https://bugs.swift.org/browse/SR-40 and
http://dev.iachieved.it/iachievedit/debian-packages-for-swift-on-arm/,
folks are definitely working on it.
On Tue, Dec 22, 2015 at 11:32 AM, Dallas Brown via swift-dev <
swift-dev@swift.org> wrote:
> I know there has been talk about gettin
gt; https://github.com/apple/swift/commit/d9802dd59b0e98063ea57aa51435424dc8d304c7
> .
>
> The buildbot_linux_1404 preset now works for me.
>
> Dmitri
>
> On Sat, Dec 19, 2015 at 4:10 PM, Joseph Bell via swift-dev <
> swift-dev@swift.org> wrote:
>
>> SIL/crashers/004-
7 of 7)
>>
>> and on OS X I have:
>>
>> Expected Passes: 7679
>> Expected Failures : 8
>> Unsupported Tests : 40
>> -- check-swift-all-macosx-x86_64 finished --
>> --- Finished tests for swift ---
>>
>> It's interestin
ugartype-getimplementationtype.sil
>> (7 of 7)
>>
>> and on OS X I have:
>>
>> Expected Passes: 7679
>> Expected Failures : 8
>> Unsupported Tests : 40
>> -- check-swift-all-macosx-x86_64 finished --
>> --- Finished tests for swift ---
gt; and on OS X I have:
>
> Expected Passes: 7679
> Expected Failures : 8
> Unsupported Tests : 40
> -- check-swift-all-macosx-x86_64 finished --
> --- Finished tests for swift ---
>
> It's interesting to note that I seem to have one more test on Linux than
> y
2357
> Expected Failures : 5
> Unsupported Tests : 35
> -- check-swift-macosx-x86_64 finished --
> --- Finished tests for swift ---
>
>
> Em sáb, 19 de dez de 2015 às 16:47, Joseph Bell via swift-dev <
> swift-dev@swift.org> escreveu:
>
Can anyone confirm or deny that this is a known issue at the moment? This
is with a fresh checkout as of this morning (Dec 19).
Testing Time: 261.00s
Failing Tests (1):
Swift :: SIL/crashers/004-swift-expr-getsourcerange.sil
Expected Passes: 69
36 matches
Mail list logo
