search for: new_lines

greened at obbligato.org (David A. Greene) writes: > For now, I think if I tweak the way I do the build to always build > without pointing to llvm-gcc first, build and test LLVM then build > llvm-gcc and re-build LLVM, it should work. It will take much longer, > though. :( I updated the bug explaining what I'm seeing. I think the correct fix is to use absolute paths to tools

greened at obbligato.org (David A. Greene) writes: > greened at obbligato.org (David A. Greene) writes: > >> For now, I think if I tweak the way I do the build to always build >> without pointing to llvm-gcc first, build and test LLVM then build >> llvm-gcc and re-build LLVM, it should work. It will take much longer, >> though. :( > > I updated the bug

Jason Kim <jasonwkim at google.com> writes: >>> There is definitely something to this.  If I take a random failing >>> testcase and run the test in isolation in the shell, it works.  So >>> what, if anything, does lit/FileCheck/etc. do that might run >>> interference if there is another copy of lit/FileCheck/etc. running >>> at the same time? I

...0, then the PurchaseOrder should never be created. The problem is, I am not aware of the rails way of doing it :) I started directing towards doing custom validation before after_create with this code: class PurchaseOrder < ActiveRecord::Base has_many :purchase_order_lines attr_accessor :new_lines def lines=(_lines) @new_lines ||= [] _lines.each do |_line_params| puts _line_params.inspect @new_lines << PurchaseOrderLine.new(_line_params) end end after_create :store_lines def store_lines new_lines.each do |line| line.purchase_order = self...

Hello, If I rename a directory full of files, or a bunch of files, and I use Rsync to update the directory tree, Rsync will upload all these files again and delete the old ones. This is suboptimal since all the data is already there. Rsync should be able to check for renamed files by scanning for files with the same MD5 hashes, checksums, or delta signatures (is that what you called them?).

https://bugzilla.netfilter.org/show_bug.cgi?id=1301 Bug ID: 1301 Summary: Feature Request - "add set", "add element" - automatically import element members from a file Product: nftables Version: unspecified Hardware: x86_64 OS: All Status: NEW Severity: enhancement

This is something I've been working on: Reworking inspection so it's not a big mess of ad hoc C code, but instead uses a well-defined domain-specific language to describe how we inspect guests. The best introduction to this is the manual page, which I include below (it's also included in patch 2/3). Rich. ---------------------------------------------------------------------- NAME

Previously posted: https://www.redhat.com/archives/libguestfs/2015-December/msg00038.html Inspection now really succeeds on a small number of simple guests. To test it out: $ ./run guestfish -v -x -a /tmp/centos-6.img ><fs> run ><fs> debug sh "guestfs-inspection --verbose" Rich.

This is a more working version. Inspection (partially) succeeds on a real guest this time :-) You can test it out on a real guest (in this case, a CentOS disk image located at /tmp/centos-6.img) by doing: $ ./run guestfish -v -x -a /tmp/centos-6.img ><fs> run ><fs> debug sh "guestfs-inspection --verbose" which will print lots of debugging, and at the end the

For background on this change, see: https://rwmj.wordpress.com/2015/12/06/inspection-now-with-added-prolog/ v2 was previously posted here: https://www.redhat.com/archives/libguestfs/2015-December/msg00038.html To test this patch series on a real guest, you can do: $ ./run guestfish -v -x -a /var/tmp/centos-6.img ><fs> run ><fs> debug sh "guestfs-inspection