similar to: How to actually get patches accepted? ATTN maintainers

On Tue, Apr 04, 2017 at 11:12:11AM +0200, Michal Ruprich via rsync wrote: > There are huge differences between source files in the version 3.0.9 > released as a tar.gz and source files in git. I would assume that the > released version would correspond to the version in git but with 3.0.9 > it is not like that. In 3.1.0 the released and git versions are more or > less the same. How

There are huge differences between source files in the version 3.0.9 released as a tar.gz and source files in git. I would assume that the released version would correspond to the version in git but with 3.0.9 it is not like that. In 3.1.0 the released and git versions are more or less the same. So my question is, from what source files was the 3.0.9 version created? Thank you. Regards, Michal

(please CC me, I'm not on the klibc list, and I didn't get HPA's response to my post). On Fri, Dec 27, 2013 at 12:24:34AM +0000, Thorsten Glaser wrote: > H. Peter Anvin dixit: > >You should be using the output of "make headers_install" to build klibc. That makes easy cross-building a pain in the arse, and if that's the case, why do you even have variables

On Thu, Dec 26, 2013 at 08:31:48PM -0800, H. Peter Anvin wrote: > > In the end, demanding that I use a copy of the installed kernel headers, > > when I'm passing a specific kernel source to the klibc build and that > > kernel source is most probably not the same as the kernel that's running > > seems like a bad idea. I want to build against a known kernel source,

On Thu, Dec 26, 2013 at 09:04:26PM -0800, H. Peter Anvin wrote: > > in the kernel dir: > > emake headers_install INSTALL_HDR_PATH="${WORKDIR}"/linux-headers/ > You are overriding INSTALL_HDR_PATH... I want it to use that copy in $WORKDIR/linux-headers/ .... There is no way to specify that, it's NOT KLIBCKERNELSRC. > > in the klibc dir: > > emake V=1

I have released rsync version 3.3.0. This is a bug fix release, with the increased version bump being a delayed reaction to some of the recent larger changes that have happened. To see a summary of all the recent changes, visit this link: https://rsync.samba.org/ftp/rsync/NEWS#3.3.0 You can download the source tar file and its signature from here:

I have released rsync version 3.3.0. This is a bug fix release, with the increased version bump being a delayed reaction to some of the recent larger changes that have happened. To see a summary of all the recent changes, visit this link: https://rsync.samba.org/ftp/rsync/NEWS#3.3.0 You can download the source tar file and its signature from here:

TO everyone who is making use of unicode_hacks! I have made irreversible changes to the plugin so that the routings are no longer overloaded. To call the character-bound routines, you need to use the "chars" or "u" accessors, as outlined in the docs http://julik.nl/code/unicode-hacks/index.html and in this blog post by Thijs:

The Wiki page has been SSL-only for a few days to a week or so. [perhaps this is by design, I don't know - but it is different than it was a week or more ago.] But the link to it from the main samba.org page is wrong and the suggested link doesn't get you to the wiki either. [It goes to CIFS.ORG.] Most of us can find our way - but it probably needs addressing sometime soon. -Greg

Ivo, Your patch number 16347 uses _fseeki64 when _WIN32 is defined. Unfortunately, MinGW (or at least the Linux -> Win32 cross compiler I'm using) defines _WIN32 but isn't aware of _fseeki64. I have therefore modified your solution a little and commited it as rev 15376. The code now looks like this: #ifdef __MINGW32__ return fseeko64(f,off,whence); #elif defined

Acts as tree users: please review ticket http://dev.rubyonrails.org/ticket/10843 and add comment with +1 -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to

http://pkgs.fedoraproject.org/gitweb/?p=libguestfs.git;a=blob;f=0001-Workaround-for-usrmove-in-Fedora.patch;hb=HEAD I have added this patch (not upstream) ^^ This is a workaround for a rather misguided feature called 'usrmove' which was just dumped without notice into Rawhide, 3 days before the F17 branch, while everyone was away at FOSDEM. I still haven't got libguestfs to build

On Tue, May 28, Richard W.M. Jones wrote: > > There's a denial of service attack possible from guests on any program > that does inspection (eg. virt-inspector, many other virt-* tools, > virt-v2v, OpenStack). > > The attack causes the host process to crash because of a double free. > It's probably not exploitable (definitely not on Fedora because of the >

On Fri, May 31, 2013 at 01:03:24AM +0200, Olaf Hering wrote: > #2 0x00007ffff7b7936c in guestfs___safe_strdup (g=0x65da50, str=0x0) at alloc.c:96 > #3 0x00007ffff7b8b65e in parse_suse_release (filename=<optimized out>, fs=<optimized out>, g=<optimized out>) at inspect-fs-unix.c:343 This is a different problem: lines = guestfs_head_n (g, 10, filename); if (lines ==

This should fix it I think. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/

This issue has been assigned CVE-2013-2124. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#)

Now that the NVPTX back-end has been integrated into ToT and already surpasses the PTX back-end in terms of functionality, I plan to remove the PTX back-end from the LLVM tree soon. The only change that users will need to be aware of are the address space mapping (please see lib/Target/NVPTX/NVPTX.h for the new mappings). The old intrinsics will remain valid for the new NVPTX back-end. What I

I am ready, regarding to, http://bb.pgr.jp/ On Wed, May 25, 2016 at 5:54 AM Chris Bieneman <beanz at apple.com> wrote: > Meant to send this yesterday, but I want to remind everyone that we’re > going to be raising the CMake minimum version to 3.4.3 next week. > > If you maintain bots please ensure that your bots are updated by end of > day 5/29 so that we can move on 5/30

Kind of spawns an interesting side topic though..... I recommend SpamHaus.org for a good blacklist.... Easy to integrate into most mail servers and you can't beat free... Cheers, Wiley -----Original Message----- From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Matt Sent: Thursday, June 09, 2005 10:40 AM To: Asterisk Users Mailing

A fix to supermin is required if you want to use supermin and/or libguestfs with Linux kernel >= 4.13. It does not affect the recently released kernel 4.12. Supermin incorrectly created symlinks in the appliance filesystem, and although this works with earlier kernels a recent change breaks these (incorrect) filesystems. The symptoms you will see are described in this bug report: