similar to: [LLVMdev] Release: Two Weeks 'Til 3.0 Branch

Displaying 20 results from an estimated 6000 matches similar to: "[LLVMdev] Release: Two Weeks 'Til 3.0 Branch"

2011 Oct 06
1
[LLVMdev] [cfe-dev] Release: Two Weeks 'Til 3.0 Branch
On Fri, Sep 30, 2011 at 04:45:33PM -0700, Bill Wendling wrote: > As of today, there are two weeks left until we branch for the 3.0 > release. Please get your changes in as soon as possible so that they > are well-tested before the branch. And please keep on top of any failures you see. > > Now would be a good time to look through the bugzilla database to see > if there are any
2011 Oct 07
0
[LLVMdev] [cfe-dev] Release: Two Weeks 'Til 3.0 Branch
On Oct 6, 2011, at 2:35 PM, Joerg Sonnenberger wrote: > On Fri, Sep 30, 2011 at 04:45:33PM -0700, Bill Wendling wrote: >> As of today, there are two weeks left until we branch for the 3.0 >> release. Please get your changes in as soon as possible so that they >> are well-tested before the branch. And please keep on top of any failures you see. >> >> Now would be
2011 Oct 07
0
[LLVMdev] [cfe-dev] Release: Two Weeks 'Til 3.0 Branch
>>>>> Duncan Sands <baldrick at free.fr> writes: > If we had a larger set of volunteers that could help qualify releases AND > buildbots to continuously test the new release criteria, then we are willing > to expand this criteria. We haven't had a lot of volunteers step up in this > area though. Just to note, BoostPro has already expressed a willing to run
2011 Oct 08
0
[LLVMdev] [cfe-dev] Release: Two Weeks 'Til 3.0 Branch
>>>>> Tanya Lattner <lattner at apple.com> writes: > I do not know the history here, but I do not see a problem with you setting > up a buildbot. Did someone specifically object? I think it was simply that no one responded. > However, buildbots do require that someone is actively watching them and > helping if breakage occurs (ie. developers may not have access
2011 Oct 07
3
[LLVMdev] [cfe-dev] Release: Two Weeks 'Til 3.0 Branch
> If we had a larger set of volunteers that could help qualify releases AND buildbots to continuously test the new release criteria, then we are willing to expand this criteria. We haven't had a lot of volunteers step up in this area though. I don't much like the idea of doing a release with so many buildbots down... Ciao, Duncan.
2011 Oct 07
2
[LLVMdev] [cfe-dev] Release: Two Weeks 'Til 3.0 Branch
On Oct 7, 2011, at 1:29 AM, John Wiegley wrote: >>>>>> Duncan Sands <baldrick at free.fr> writes: > >> If we had a larger set of volunteers that could help qualify releases AND >> buildbots to continuously test the new release criteria, then we are willing >> to expand this criteria. We haven't had a lot of volunteers step up in this >> area
2013 Dec 13
0
[LLVMdev] [cfe-dev] LLVM 3.4 Branch Freeze
On 12/13/13 01:58 PM, Bill Wendling wrote: > That’s a long laundry list of bugs there. It would be great to have them fixed, but the reality of the situation is that they won’t be fixed for weeks or more, if at all. And with Christmas coming up, it makes things even worse. There are a few days before Phase III starts to have some progress on them. But if they don’t make it, then we’ll have to
2013 Dec 13
3
[LLVMdev] [cfe-dev] LLVM 3.4 Branch Freeze
That’s a long laundry list of bugs there. It would be great to have them fixed, but the reality of the situation is that they won’t be fixed for weeks or more, if at all. And with Christmas coming up, it makes things even worse. There are a few days before Phase III starts to have some progress on them. But if they don’t make it, then we’ll have to release without them. -bw On Dec 12, 2013, at
2013 Dec 13
3
[LLVMdev] [cfe-dev] LLVM 3.4 Branch Freeze
The usual procedure is to make time-based releases. So - "release trunk and make sure it's stable enough" plus - fix any outstanding regressions. There is some text wrt this: http://llvm.org/docs/HowToReleaseLLVM.html#release-qualification-criteria On Fri, Dec 13, 2013 at 11:08 AM, "C. Bergström" <cbergstrom at pathscale.com> wrote: > On 12/13/13 01:58 PM, Bill
2010 Apr 20
1
[LLVMdev] 2.7 Pre-Release2 Available!
The 2.7 pre-release2 is available for testing: http://llvm.org/pre-releases/2.7/pre-release2/ Please complete all testing by April 23rd EOD. We are shortening this testing period a bit to get the release out soon since its been delayed so far. The release team has done our qualifications and we think its of high quality and ready to go. As this is the last pre-release, we only accept fixes for
2011 Oct 14
1
[LLVMdev] LLC ARM Backend maintainer
On Oct 13, 2011, at 10:33 AM, Raja Venkateswaran wrote: > I think we need a group of maintainers rather than a single maintainer given the spectrum of ARM targets/ISAs/platforms required to support and the amount of people/system resources required. I & my team plan to actively participate in the bug-fixing process during the release cycle. If we can divide the bugs among the maintainers
2013 Feb 03
1
Ports and WITH_LIBCPLUSPLUS
Hello, I wanted to try the new c++ stuff, ie clang-3.2, libc++ and libcxxrt, so I used poudriere to build a jail setup for that ( WITH_LIBCPLUSPLUS=yes in src.conf, CXXFLAGS+=-stdlib=libc++ and libsupc++.so.1 libcxxrt.so.1 in libmap.conf ), and started to build my normal set of packages ( see desktop.list ). Please note that I also have WITH_NEW_XORG=yes and WITH_KMS=yes, as well as using the
2009 May 03
2
how to find out dependencies
At install I had Gnome and Not KDE. doing rpm -qa | grep qt results in qt-3.3.6-23.el5 qt4-4.2.1-1 How can I find out what package loaded the qt4 and qt? Thanks, Jerry
2008 Aug 20
1
qt3.3 is default in environment, I want it to be qt4
At the current time, the environment is using qt3 values, as in $ env | grep QT QTDIR=/usr/lib/qt-3.3 QTINC=/usr/lib/qt-3.3/include QTLIB=/usr/lib/qt-3.3/lib $ env | grep PATH PATH=/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/lib/ccache:/usr/local/bin:/bin:/usr/bin:/home/pauljohn/bin I also have QT4 installed, and I want programs to find those libraries and include files instead of these ones.
2011 Feb 17
1
vanilla kernel configuration :: xconfig --> qt errors
Hi! It seems that i made some changes that make xconfig to not work .. the problem is that not matter what QTDIR i select i receive the same errors that start with : adrian at sevcenco: linux-2.6.37 $ make O=/home/adrian/kernel/kernel_out xconfig GEN /home/adrian/kernel/kernel_out/Makefile HOSTCXX scripts/kconfig/qconf.o /usr/lib64/qt4/include/Qt3Support/q3toolbar.h:45: error:
2007 Nov 07
2
Installing skype in CentOS 5
Having just upgraded my system from CentOS 4.4 to 5.0, I'm a bit disappointed that I still can't install skype from the skype repo using yum - when I try yum install skype, I end up with: libsigc++20-2.0.17-1.el5. 100% |=========================| 217 kB 00:13 ---> Package libsigc++20.i386 0:2.0.17-1.el5.rf set to be updated --> Running transaction check --> Processing
2013 Dec 13
0
[LLVMdev] [cfe-dev] LLVM 3.4 Branch Freeze
----- Original Message ----- > From: "Anton Korobeynikov" <anton at korobeynikov.info> > To: "C. Bergström" <cbergstrom at pathscale.com> > Cc: "cfe-dev at cs.uiuc.edu Developers" <cfe-dev at cs.uiuc.edu>, "Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, December 13, 2013 3:24:38 AM > Subject: Re: [LLVMdev]
2006 Dec 31
3
KWD not building problem solved
It looks like you just assumed too much. kde-config has a specific include dir query. I am now hitting some dbus problems, but it does not seem to be related. -------------- next part -------------- A non-text attachment was scrubbed... Name: kdefix.patch.bz2 Type: application/x-bzip Size: 604 bytes Desc: not available Url :
2017 Jul 19
3
[5.0.0 Release] The release branch is open; trunk is now 6.0.0
Dear everyone, The release branch was recently created from trunk at r308441 and the trunk version was subsequently incremented to 6.0.0. Release blockers are tracked by https://bugs.llvm.org/show_bug.cgi?id=33849 Please mark any bugs, old or new, that you think need to be fixed before the release as blocking that. Please help out with the release by notifying me of any bugs, commits, or other
2005 Feb 21
2
[LLVMdev] Patch to make gccld link native .so's, -rpath, -soname, and various assorted fixes
Hello, I have a patch that: 1. Allows gccld to link shared libraries natively.. 2. Passes along -rpath and -soname to the native linker... 3. Fixes a bug where the bytecode files were kept around after native linking... 4. Removes a now unnecessary warning for native linking... The result is that we are >' '< close to having Qt4 both compile *and* link with the LLVM toolchain.