search for: blobdiff

....xiph.org/?p=flac.git;a=summary Specifically I pulled out much of the "#ifdef _MSC_VER" printf stuff in this commit: https://git.xiph.org/?p=flac.git;a=commit;h=ce8a75134cace056f6c436d54b57bad1a1d93797 For example (damn thats a horrible URL): https://git.xiph.org/?p=flac.git;a=blobdiff;f=examples/c/decode/file/main.c;h=e5138b4f9a08f0cf3e9a26c8ab68ac76d161785d;hp=32b555947d5c576693dbb6a9ee13a0a67582d96a;hb=ce8a75134cace056f6c436d54b57bad1a1d93797;hpb=8bbbf56403808ff75126cd0840a936aedbc4113b Since your patch seems pretty similar to what I have already commited, I wouldn't be s...

...hed and build a 2.6.29-xen-r4 kernel which has been posted on this list a few weeks ago. I''m using this kernel after a lot of testing productive. D/L here: http://www.schwarz-mode.de/files/xen-newer-stuff/ Original patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;f=net/socket.c;h=6d47165590473daa4990bf69b0435d5c49b41302;hp=791d71a36a93dfec5166fe05e2e0cb394cfa904b;hb=e694958388c50148389b0e9b9e9e8945cf0f1b98;hpb=a3620f7545344f932873bf98fbdf416b49409c8e I''ll build a 2.6.18.8-xen from xensource repo also, but as I''m currently running most mac...

>From Martin's isolinux.bin.20170324, I (kind of) understand the first 3 bytes: 33 ED 90 Then, the next "90"s are probably originiated from the "nop"s in: http://repo.or.cz/syslinux.git/blobdiff/c210e571f61eeb898fadbb6f47d4a2c8 2e5bfbfd..2c3a24e5f4b807ec31595227afa59a818c060ca9:/mbr/isohdpfx.S So, why the original isohybrid image from Debian and many other isohybrid images have mostly (but not all) "00s" in place of the "90s"? (Considering that these images are gene...

...ecifically I pulled out much of the "#ifdef _MSC_VER" printf stuff > in this commit: > > https://git.xiph.org/?p=flac.git;a=commit;h=ce8a75134cace056f6c436d54b57bad1a1d93797 > > For example (damn thats a horrible URL): > > https://git.xiph.org/?p=flac.git;a=blobdiff;f=examples/c/decode/file/main.c;h=e5138b4f9a08f0cf3e9a26c8ab68ac76d161785d;hp=32b555947d5c576693dbb6a9ee13a0a67582d96a;hb=ce8a75134cace056f6c436d54b57bad1a1d93797;hpb=8bbbf56403808ff75126cd0840a936aedbc4113b > > Since your patch seems pretty similar to what I have already commited, > I wo...

...uch of the "#ifdef _MSC_VER" printf stuff >> in this commit: >> >> https://git.xiph.org/?p=flac.git;a=commit;h=ce8a75134cace056f6c436d54b57bad1a1d93797 >> >> For example (damn thats a horrible URL): >> >> https://git.xiph.org/?p=flac.git;a=blobdiff;f=examples/c/decode/file/main.c;h=e5138b4f9a08f0cf3e9a26c8ab68ac76d161785d;hp=32b555947d5c576693dbb6a9ee13a0a67582d96a;hb=ce8a75134cace056f6c436d54b57bad1a1d93797;hpb=8bbbf56403808ff75126cd0840a936aedbc4113b >> >> Since your patch seems pretty similar to what I have already commited, &g...

Brian Willoughby wrote: > It makes sense to have the option to return non-zero when the > "compression" fails to "compress." As Erik pointed out, a script > could use the return code to decide to delete the larger FLAC output > file and keep the original input file since it is smaller (and > equally lossless). > > However, I agree that it is

Hi, Compile fails in these two files src/lib-ssl-iostream/iostream-openssl-context.c src/login-common/ssl-proxy-openssl.c due to missing SSL_OP_SINGLE_ECDH_USE In these there is only #if !defined(OPENSSL_NO_ECDH) when all the other places it always compares also SSL version #if !defined(OPENSSL_NO_ECDH) && OPENSSL_VERSION_NUMBER >= 0x10002000L Tomppa

...ed WRMSR 0000000000000079 from 0x0000000000000000 to 0xffffc900089cc030. I found a similar thread with a patch referenced and applied & rebuilt the kernel. No change. http://lists.xen.org/archives/html/xen-devel/2012-03/msg00320.html http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=blobdiff;f=drivers/char/mem.c;h=a1be5259aabbc4d3cfa9022bbc9655c382555103;hp=8fc04b4f311f72c802a1df13af7108e3082a1b3f;hb=0cfd8ac8e702db147a9a664212f597f627b3f7e9;hpb=02f8c6aee8df3cdc935e9bdd4f2d020306035dbe I also looked at the DRM documentation - I think the kernel and Xen version''s that I'...

...Is there a reason for this? IMHO the VA => ptr conversion should also take into account non-page aligned addresses, hence the offset (except for NULL value of course). Cheers, [1] http://mail-index.netbsd.org/port-xen/2013/10/16/msg008088.html [2] http://xenbits.xen.org/gitweb/?p=xen.git;a=blobdiff;f=tools/libxc/xc_dom.h;h=ad6fdd49e2b07704c07a0629bf8da59bfdb5fef2;hp=316c5cbefca4f791255bb43f5dcf4085d42d5869;hb=b5a869209998fedadfe205d37addbd50a802998b;hpb=53bfcf585b09eb4ac2240f89d1ade77421cd2451 -- Jean-Yves Migeon jym@

On 2/1/2012 18:52, Erik de Castro Lopo wrote: > JonY wrote: > >> Alright, here's a quick fix, although it is more ugly than I remembered. >> >> Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h >> where available, and falls back to I64 on MSVC and then ll for others, >> all format warnings suppressed. > > JonY, > > Sorry

Hi, Gene Cumm wrote: > it seems the stack format got > set, changed, then mostly reverted back, with this code being the last > piece missing from 2009. The commit to isohdpfx.S of 2009-05-31 looks incomplete. The sequence of the stack pointers was swapped, but the sequence of stack pushes was not.

...it is in the CentOS project?s best interest if users always use the fastest mirror when downloading, but I claim that it is a bug to mark any plugin as Requires, particularly when upstream does not. [1]: https://lists.centos.org/pipermail/centos/2016-June/159933.html [2]: https://git.centos.org/blobdiff/rpms!yum/f1c1b9820b3d295cf5b44fa7fc8ff3673ec6d391/SPECS!yum.spec

http://bugs.freedesktop.org/show_bug.cgi?id=16231 Summary: Xv tearing after upgrade to Fedora 9 Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

...f2() { } int main() { f1(); } clang -fuse-ld=bfd -ffunction-sections -Wl,--gc-sections -g a.c -o a.bfd llvm-dwarfdump -debug-ranges a.bfd => R_X86_64_64 relocations in .debug_ranges are resolved to 1, ignoring the addend (Behavior introduced in https://sourceware.org/git/?p=binutils-gdb.git;a=blobdiff;f=bfd/ChangeLog;h=8fbaed21fa2c8238459acb637545583f3cfbbfdf;hp=18a3a67be3a5980998c4461b5a739e54f3551b17;hb=e4067dbb2a3368dbf908b39c5435c84d51abc9f3;hpb=c0621d88b096cc046adf6ed484baea9ba5bfe721) The comments below are also insightful. I need to ponder more (and need to read the DWARF v4 and v5 specs...

Hi, I had posted the following issue a few days ago in Xen-users but I haven''t received any answer yet. So I decided to re-post it here in hope for some solution. Here''s the original post: Xen wiki states that using linux 3.0 and above as dom0 works with all graphics cards. I could install the fglrx graphics driver on my desktop machine with a discrete graphics card (Radeon

...sections -g a.c -o a.bfd > > llvm-dwarfdump -debug-ranges a.bfd > > => > > R_X86_64_64 relocations in .debug_ranges are resolved to 1, ignoring the > > addend > > > > (Behavior introduced in > > https://sourceware.org/git/?p=binutils- > > gdb.git;a=blobdiff;f=bfd*ChangeLog;h=8fbaed21fa2c8238459acb637545583f3cfbb > > fdf;hp=18a3a67be3a5980998c4461b5a739e54f3551b17;hb=e4067dbb2a3368dbf908b39 > > c5435c84d51abc9f3;hpb=c0621d88b096cc046adf6ed484baea9ba5bfe721) > > > > The comments below are also insightful. I need to ponder more (a...

...; > > > > > > > (Behavior introduced in > > > > https://urldefense.com/v3/__https://sourceware.org/git/?p=binutils- > > __;!!JmoZiZGBv3RvKRSx!tvZHOB67bddZqG6U17Cj0X1rfKGW72rrjmKKFQNBxBlQvgdukM5e > > 3DkTDxuwRVwsyw$ > > > > > > gdb.git;a=blobdiff;f=bfd*ChangeLog;h=8fbaed21fa2c8238459acb637545583f3cfbb > > > > > > fdf;hp=18a3a67be3a5980998c4461b5a739e54f3551b17;hb=e4067dbb2a3368dbf908b39 > > > > c5435c84d51abc9f3;hpb=c0621d88b096cc046adf6ed484baea9ba5bfe721) > > > > > > > > The comments b...

...r introduced in > >> > > > https://urldefense.com/v3/__https://sourceware.org/git/?p=binutils- > >> > __;!!JmoZiZGBv3RvKRSx!tvZHOB67bddZqG6U17Cj0X1rfKGW72rrjmKKFQNBxBlQvgdukM5e > >> > 3DkTDxuwRVwsyw$ > >> > > > > >> > gdb.git;a=blobdiff;f=bfd*ChangeLog;h=8fbaed21fa2c8238459acb637545583f3cfbb > >> > > > > >> > fdf;hp=18a3a67be3a5980998c4461b5a739e54f3551b17;hb=e4067dbb2a3368dbf908b39 > >> > > > c5435c84d51abc9f3;hpb=c0621d88b096cc046adf6ed484baea9ba5bfe721) > >> > > &gt...

...gt; > https://urldefense.com/v3/__https://sourceware.org/git/?p=binutils- > >> >> > __;!!JmoZiZGBv3RvKRSx!tvZHOB67bddZqG6U17Cj0X1rfKGW72rrjmKKFQNBxBlQvgdukM5e > >> >> > 3DkTDxuwRVwsyw$ > >> >> > > > > >> >> > gdb.git;a=blobdiff;f=bfd*ChangeLog;h=8fbaed21fa2c8238459acb637545583f3cfbb > >> >> > > > > >> >> > fdf;hp=18a3a67be3a5980998c4461b5a739e54f3551b17;hb=e4067dbb2a3368dbf908b39 > >> >> > > > c5435c84d51abc9f3;hpb=c0621d88b096cc046adf6ed484baea9ba5bfe721)...

As has been mentioned elsewhere, Sony generally fixes up references from debug info to stripped functions (of any length) using -1, because that's a less-likely-to-be-real address than 0x0 or 0x1. (0x0 is a typical base address for shared libraries, I'd think using it has the potential to mislead various consumers.) For .debug_ranges we use -2, because both a 0/0 pair and a -1/-1 pair