search for: breakages

Normally the FreeBSD Project tries very hard to avoid ABI breakage in "Stable Branches". However occasionally the fix for a bug can not be implemented without ABI breakage, and it is decided that the fix warrants the impact of the ABI breakage. We have one of those situations coming along for RELENG_7 (what will become FreeBSD 7.1). The ABI breakage should only impact kernel modules

On Wed, Jun 05, 2013 at 10:08:37AM -0500, Anthony Liguori wrote: > "Michael S. Tsirkin" <mst at redhat.com> writes: > > > On Wed, Jun 05, 2013 at 07:59:33AM -0500, Anthony Liguori wrote: > >> "Michael S. Tsirkin" <mst at redhat.com> writes: > >> > >> > On Tue, Jun 04, 2013 at 03:01:50PM +0930, Rusty Russell wrote: >

On Wed, Jun 05, 2013 at 10:08:37AM -0500, Anthony Liguori wrote: > "Michael S. Tsirkin" <mst at redhat.com> writes: > > > On Wed, Jun 05, 2013 at 07:59:33AM -0500, Anthony Liguori wrote: > >> "Michael S. Tsirkin" <mst at redhat.com> writes: > >> > >> > On Tue, Jun 04, 2013 at 03:01:50PM +0930, Rusty Russell wrote: >

On Wed, Jun 05, 2013 at 07:59:33AM -0500, Anthony Liguori wrote: > "Michael S. Tsirkin" <mst at redhat.com> writes: > > > On Tue, Jun 04, 2013 at 03:01:50PM +0930, Rusty Russell wrote: > > You mean make BAR0 an MMIO BAR? > > Yes, it would break current windows guests. > > Further, as long as we use same address to notify all queues, > > we would

On Wed, Jun 05, 2013 at 07:59:33AM -0500, Anthony Liguori wrote: > "Michael S. Tsirkin" <mst at redhat.com> writes: > > > On Tue, Jun 04, 2013 at 03:01:50PM +0930, Rusty Russell wrote: > > You mean make BAR0 an MMIO BAR? > > Yes, it would break current windows guests. > > Further, as long as we use same address to notify all queues, > > we would

----- Original Message ----- > From: "Hal Finkel via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Richard Pennington" <rich at pennware.com> > Cc: llvm-dev at lists.llvm.org > Sent: Wednesday, September 7, 2016 7:37:50 AM > Subject: Re: [llvm-dev] [PowerPC] Recent branch too far breakage > > Hi Rich, > > It is hard to tell, but there

In our implementation, the NIS server is ActiveDirectory with ServicesForUnix 3.0 :) > -----Original Message----- > From: Daniel Eischen [mailto:eischen@vigrid.com] > Sent: Monday, July 14, 2003 2:13 PM > To: Robin P. Blanchard > Cc: John De Boskey; current@freebsd.org; Jacques A. Vidrine > Subject: RE: Help diagnosing NIS breakage ? > > > On Mon, 14 Jul 2003,

hello, klibc/include/signal.h include asm/signal.h which prefixes the __sighandler_t definition with a __user annotation. __user not being defined previously leads to a compilation breakage. It's the only occurrence for now, so the following dirty work-around works here : add a "#define __user" at klibc/include/signal.h head. regards, -- christophe varoqui

All, The following patch fixes the build breakage on FreeBSD/powerpc: Index: lib/Target/PowerPC/PPCJITInfo.cpp =================================================================== --- lib/Target/PowerPC/PPCJITInfo.cpp (revision 51432) +++ lib/Target/PowerPC/PPCJITInfo.cpp (working copy) @@ -72,7 +72,7 @@ extern "C" void PPC64CompilationCallback(); #if (defined(__POWERPC__) ||

I'm using a recent revision of TOT (280704) to build clang/LLVM for PowerPC64 little endian. I'm getting an assembler error when building PPCInstPrinter.cpp: The error is: /tmp/PPCInstPrinter-84c835.s: Assembler messages: /tmp/PPCInstPrinter-84c835.s:7671: Error: operand out of range (0x0000000000008004 is not between 0xffffffffffff8000 and 0x0000000000007ffc) The offending line is

Ben Goodrich alerted me to some breakage coming from read.dcf() meaning you can no longer install or upgrade R packages. ChenLiang Xu was eagle-eyed and related this to gzfile() and he and Johannes Fichting confirmed that a downgrade to zlib1g from testing fixes things. Ben already filed a Debian bug report, you can see the gory details at http://bugs.debian.org/562755 and we are in contact

Hi all, I know this issue has been discussed over and over again, but I'd like to voice my opinion while 3.0 is still fairly early-ish in the pipeline. So the issue is... API breakage. I understand and agree with the rationale why, namely faster development. But this principle should mean that for each breakage, the dude who makes the breakage should accompany the final commit (or something

On Thu, Apr 12, 2018 at 6:29 PM, Josh Soref <jsoref at gmail.com> wrote: > Randall S. Becker <rsbecker at nexbridge.com> wrote: > >> >> -REGRESSTMP = "$(PWD)/regress" >> +REGRESSTMP = `pwd` >> >> tests interop-tests t-exec unit: regress-prep regress-binaries $(TARGETS) >> > > It looks like the problem is that pwd is in

Hi, The GStreamer flac plugin broke due to libflac 1.1.0 and libflac 1.1.1 not being ABI/API compatible. Skimming through the archives I see that this breakage was intentional. I think it is quite common understanding that when you have a stable release of something you don't break your API, you only add to it. If you want to break the API that should be done by going to a new major number,

On Jul 13, 2011, at 8:09 AM, Jay Foad wrote: > On 13 July 2011 15:47, fly language <flylanguage at gmail.com> wrote: >> I don't really buy the manpower argument. Updating the release doc when >> breaking the frigging API is the Right Thing To Do and shouldn't take that >> long, when done when the change is fresh in memory. > > I regularly make small

There are three sets of changes that would benefit stable/7. Namely, there are 1. Improvements for the UFS unmount or rw->ro remount, that perform suspension during the operation. The changes depend on the the suspension mechanism path, that introduced the suspension owner, and added new VFS OP into the mount method table. This might also fix the hangs with gjournal or

Anyone else having an issue with route-generation in specs breaking as of Rails trunk r6062? When I run my specs at r6061, they all pass, and in 6062 I get a trace like this every time my controller generates a route: TypeError in ''Requesting /artists/1 using PUT should redirect to the artist'' can''t convert Fixnum into String (eval):19:in `artist_url''

3.0.0pre2: non-recursive remote listing breakage Looks like pre1's fix broke something else. I noticed this when listing module/directory contents on servers known to be running versions 2.5.7 & 2.6.3. Not having (full) access to them, I replicated the errors using 2 machines on my home lan. # the machines lithium.elements.lan: the client. rsync 3.0.0pre2 for all tests.

Hi all, One of my commit broke the PowerPC builder, so I reverted it. The issue could be reproduced only for big-endian, little-endian ppc64 built ok. How can I fix it? I have no access to any PowerPC box to get to the bottom of issue. All the other tests are ok. Commit: https://github.com/llvm/llvm-project/commit/9c20156de39b377190d7a91783d61877b303fe35, svn revision: 359870. Reproduced

I have just pushed out SYSLINUX 3.10-pre9. Please test it out, especially everyone who has been working with me on various systems trying to get them to work, or have had recent breakage. -hpa