search for: 11886

Currently, there's a regression in llvm-config in both the 3.1 Release branch and trunk (http://llvm.org/bugs/show_bug.cgi?id=11886). The attached patch fixes that. It would be great if this could be reviewed and still integrated into 3.1. Thanks, Keno -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120512/e91ddc99/attachment.html> --...

...8 14:47:49 dhcpd: DHCPACK on 192.168.1.1 to 00:0c:29:6e:ac:93 via eth1 Mar 8 14:47:49 dhcpd: Client 0:c:29:6e:ac:93 requests 1:2:3:4:5:6:c:d:f:11:12:16:17:1c:28:29:2a:2b:32:33:36:3a:3b:3c:42:43:61:80:81:82:83:84:85:86:87 - PXEClient:Arch:00007:UNDI:003000 - no dhcp-client-id Mar 8 14:47:49 atftpd[11886]: Serving bootx64.efi to 192.168.1.1:1066 Mar 8 14:47:49 atftpd[11886]: Serving bootx64.efi to 192.168.1.1:1067 Mar 8 14:47:49 dhcpd: DHCPREQUEST for 192.168.1.1 (192.168.1.182) from 00:0c:29:6e:ac:93 via eth1 Mar 8 14:47:49 dhcpd: DHCPACK on 192.168.1.1 to 00:0c:29:6e:ac:93 via eth1 Mar 8 14:4...

...atftpd has better logging, and my files are > smaller than 92 MB, so I switched to atftpd for testing. Now I could > find that somehow after bootx64.efi is downloaded by client, the next > ldlinux.e64 has never been fetched by client: > ==================== > Mar 8 14:47:49 atftpd[11886]: Serving bootx64.efi to 192.168.1.1:1066 > Mar 8 14:47:49 atftpd[11886]: Serving bootx64.efi to 192.168.1.1:1067 > Mar 8 14:47:49 dhcpd: DHCPREQUEST for 192.168.1.1 (192.168.1.182) from > 00:0c:29:6e:ac:93 via eth1 > Mar 8 14:47:49 dhcpd: DHCPACK on 192.168.1.1 to 00:0c:29:6e:ac:93...

On 05/13/2012 02:46 AM, Keno Fischer wrote: > Currently, there's a regression in llvm-config in both the 3.1 Release > branch and trunk (http://llvm.org/bugs/show_bug.cgi?id=11886). The > attached patch fixes that. It would be great if this could be reviewed > and still integrated into 3.1. I'm giving this a bump as that PR is still listed as open and unassigned. Keno, I think that you should post your suggested fix there. Who wrote the new llvm-config? Could the...

...echo {}' On Tue, May 15, 2012 at 1:07 AM, Albert Graef <Dr.Graef at t-online.de> wrote: > On 05/13/2012 02:46 AM, Keno Fischer wrote: > > Currently, there's a regression in llvm-config in both the 3.1 Release > > branch and trunk (http://llvm.org/bugs/show_bug.cgi?id=11886). The > > attached patch fixes that. It would be great if this could be reviewed > > and still integrated into 3.1. > > I'm giving this a bump as that PR is still listed as open and > unassigned. Keno, I think that you should post your suggested fix there. > > Who wro...

...e, May 15, 2012 at 1:07 AM, Albert Graef <Dr.Graef at t-online.de> wrote: >> >> On 05/13/2012 02:46 AM, Keno Fischer wrote: >> > Currently, there's a regression in llvm-config in both the 3.1 Release >> > branch and trunk (http://llvm.org/bugs/show_bug.cgi?id=11886). The >> > attached patch fixes that. It would be great if this could be reviewed >> > and still integrated into 3.1. >> >> I'm giving this a bump as that PR is still listed as open and >> unassigned. Keno, I think that you should post your suggested fix ther...

On 2014?03?07? 23:05, Ady wrote: > I understand that these remarks might seem not the main issue, but I > tend to think that once you are successful while using only "default" > > values and in a minimalistic case, you could add complexity > (different paths, multiple firmwares, additional kernels, multiple > cfg files...). Ady, Thanks. I will follow your advice to

...ge repeated 4 times Nov 19 07:06:25 coyote klogd: usb 2-9: manual set_interface for iface 0, alt 0 Nov 19 07:06:26 coyote usbhid-ups[11879]: Startup successful Nov 19 07:06:26 coyote klogd: ohci_hcd 0000:00:02.0: urb ee0f3780 path 9 ep1in 93120000 cc 9 --> status -121 Nov 19 07:06:26 coyote upsd[11886]: listening on localhost port 3493 Nov 19 07:06:26 coyote upsd[11886]: listening on ::1 port 3493 Nov 19 07:06:26 coyote upsd[11886]: /var/state/ups is world readable Nov 19 07:06:26 coyote upsd[11886]: Connected to UPS [coyotes-ups]: usbhid-ups-coyotes-ups Nov 19 07:06:26 coyote upsd[11887]: Start...

On 05/12/2012 04:22 AM, Keno Fischer wrote: > in order to get ready for the upcoming LLVM 3.1 release, I checked out > the 3.1 Release branch. However, unlike with LLVM 3.0, `llvm-config > --libfiles` now also reports files that belong to targets that I did not > build (and that are thus not available). Is this expected? I can confirm this. I always build LLVM with configure

...(especially with kernel 2.2.14). This seems to be the same problem I am having. I am wondering if this problem has been resolved? Also, here is a directory listing of /usr/src/linux/fs/smbfs/*.c -rw-r--r-- 1 root root 7367 Mar 7 1999 cache.c -rw-r--r-- 1 root root 11886 May 8 1999 dir.c -rw-r--r-- 1 root root 9629 Apr 3 11:43 file.c -rw-r--r-- 1 root root 14535 Jun 13 1999 inode.c -rw-r--r-- 1 root root 1001 Dec 11 1997 ioctl.c -rw-r--r-- 1 root root 52693 Jan 4 11:12 proc.c -rw-r--r-- 1 root r...

Hello, in order to get ready for the upcoming LLVM 3.1 release, I checked out the 3.1 Release branch. However, unlike with LLVM 3.0, `llvm-config --libfiles` now also reports files that belong to targets that I did not build (and that are thus not available). Is this expected? Thanks, Keno -------------- next part -------------- An HTML attachment was scrubbed... URL:

....wav flac 1.0.3, Copyright (C) 2000,2001,2002 Josh Coalson flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. Type `flac' for details. options: -P- -b 4608 -M -l 8 -q 0 -r 3,3 -R 0 -V iits1792.wav: Verify OK, wrote 11886 bytes, ratio=0.643 iits2430.wav: Verify OK, wrote 9274 bytes, ratio=0.502 iits2430.wav: ERROR: mismatch in decoded data, verify FAILED! Please submit a bug report to http://sourceforge.net/bugs/?func=addbug&group_id=13478 Make sure to include an email contact in the com...

To all who have an AMD + Windows based PC: I have gotten a few similar bug reports about encoding errors with FLAC. The common features are: - Repeatedly encoding the same file with verify will have verify errors some of the time (looks like aroung 50%) and the verify errors will occur in different places each time. - This is happening on AMD PCs running Windows. More reports come from

Suse 10.1 AMD64 Xen3 New to Xen. The dom0 is up and running. I am trying to get my first domU working. My approach is to use precompiled images from jailtime.org. After some manual tinkering with the .cfg file the domU proceeds to boot but stalls with the following error. I cannot get past this - any ideas ? Brian Using config file "/etc/xen/vm/vm1". Started domain vm1 Bootdata ok