similar to: Bugs listed in Debian BTS

Here is a list of current open bugs in debian bts, some of these bugs are probably fixed but I do not know how to test for them properly (like UTF-8) and others may not be important enough to hold up 1.0. bugs.debian.org/(bug num) libao 130816 - WAV device doesn't print error when device is full 150220 - Doesn't open OSS devices with O_NONBLOCK all the time vorbis-tools 128521 -

Anyone who wants to see what bugs might not have made it into xiph bugzilla may want to look at the urls below. Be sure to check the bugs marked as fixed in NMU since they may have patches that aren't in cvs yet. I'll try to be around to help verify the bugs are fixed before release tomorrow/monday. Thanks, Chris Cheney http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libao

Below is a diff to vcut.c and its vcut.1 manpage, which - rewrites the manpage in the mdoc(7) markup as offered in my previous message, and while there: - drops the [] around cutpoint as it is _not_ optional - adds the [] around [+] as it _is_ optional - drops the argument name difference between "cutpoint" and "cuttime" - adds the usage sentence about "." output

Jim Grosbach wrote: > That does raise a clarifying question here. Is the code you’re interested in > using Intel or AT&T syntax? > > Also note that the question isn’t whether we should support the btr/bts > instructions. We absolutely must (and do). The question is whether we are > properly handling the un-suffixed mnemonic form of the assembly syntax. > > Perhaps you

Also, please elaborate on why this is a good change. Because gas accepts it isn’t sufficient reason in and of itself. -Jim On Jul 10, 2013, at 1:18 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Jul 10, 2013 at 12:29 PM, Ramkumar Ramachandra > <artagnon at gmail.com> wrote: >> The instructions btr and bts are perfectly valid, and have existed since

Eli Friedman wrote: > The reason it's the right thing to do is that the mem/imm forms of > btsw and btsl have exactly the same semantics. The Intel documentation implies that this is the case: > If the bit base operand specifies a memory location, it represents the address of the byte in memory that contains the bit base (bit 0 of the specified byte) of the bit string (see Figure

http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/arch/x86/include/asm/bitops.h#L68 Here is one example that I found. Are the inline assembly arguments ambiguous in size? -Jevin Sent from my mobile device. Typos are par for the course. On Jul 10, 2013, at 5:47 PM, Jim Grosbach <grosbach at apple.com> wrote: On Jul 10, 2013, at 2:30 PM, Eric Christopher <echristo at

On Wed, Jul 10, 2013 at 12:29 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > The instructions btr and bts are perfectly valid, and have existed since > Intel 386. GNU as supports them fine. Unfortunately, LLVM does not > support them, and barfs with: > > error: ambiguous instructions require an explicit suffix > > Fix this problem by disambiguating it

Hi, this patch passes the orginal cpuid bits for X86_FEATURE_DTES64 (64-bit DS Area) and X86_FEATURE_DSCPL (CPL Qualified Debug Store) to the guest when the BTS feature is switched on. I forgot this when I did this BTS emulation. Thanks. Dietmar. Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> diff -r a6b81234b189 xen/arch/x86/hvm/vmx/vpmu_core2.c ---

Anyone on this list have extensive experience with BTS? http://deancollinsblog.blogspot.com/2009/03/open-bts.html Please email me, particularly if you have experience in deploying over multiple cells covering large geographical areas (200k's sq). Regards, Dean Collins Cognation Inc dean at cognation.net <mailto:dean at cognation.net> +1-212-203-4357 New York

On Wed, Jul 10, 2013 at 2:08 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > Jim Grosbach wrote: >> To say that another way, is the assembler correctly diagnosing a previously >> unnoticed problem in the project source code, or is the assembler not >> behaving correctly according the the documented Intel assembly mnemonics? > > Where are the authoritative

Jim Grosbach wrote: > To say that another way, is the assembler correctly diagnosing a previously > unnoticed problem in the project source code, or is the assembler not > behaving correctly according the the documented Intel assembly mnemonics? Where are the authoritative instruction set pages? If such a thing were readily available, why are there gaps in the current implementation? A

Hi. After upgrading my Debian (installed a brand new Wheezy 64bits a few months ago), I decided to reinstall Civ4, and its amazing sequel BTS. Both applications finally installed (I had a problem with .net...), but now something is teribly wrong : Civ4 starts and plays just fine, but BTS, after starting, crashes when I clic "Play". The error message is the following : Unhandled

Jim Grosbach wrote: > Also, please elaborate on why this is a good change. Because gas accepts it > isn’t sufficient reason in and of itself. That they're valid instructions isn't sufficient reason? Should I additionally say that linux.git uses them? I wrote: > The instructions btr and bts are perfectly valid, and have existed since > Intel 386.

Hi, I happened to notice that linux.git uses plenty of btr and bts instructions (not btrl, btrw, btsl, btsw). For examples, see arch/x86/include/asm/bitops.h. LLVM barfs on these due to ambiguity, while GNU as is fine with them. Surely, there must be architectures where the w/l variant is unavailable? LLVM must support those architectures, no? Thanks.

On Jul 10, 2013, at 1:44 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > Jim Grosbach wrote: >> Also, please elaborate on why this is a good change. Because gas accepts it >> isn’t sufficient reason in and of itself. > > That they're valid instructions isn't sufficient reason? Should I > additionally say that linux.git uses them? > Is the

On Wed, Jul 10, 2013 at 11:12 AM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > Hi, > > I happened to notice that linux.git uses plenty of btr and bts > instructions (not btrl, btrw, btsl, btsw). For examples, see > arch/x86/include/asm/bitops.h. LLVM barfs on these due to ambiguity, > while GNU as is fine with them. Surely, there must be architectures > where

On Jul 17, 2013 7:41 AM, "Joerg Sonnenberger" <joerg at britannica.bec.de> wrote: > > On Wed, Jul 17, 2013 at 11:54:21AM +0530, Ramkumar Ramachandra wrote: > > Jim Grosbach wrote: > > > No. The above rule is absolutely the wrong thing to do, as has been > > > previously noted. > > > > I don't give a shit about whether you think it is

On Jul 10, 2013, at 2:30 PM, Eric Christopher <echristo at gmail.com> wrote: > On Wed, Jul 10, 2013 at 2:08 PM, Ramkumar Ramachandra > <artagnon at gmail.com> wrote: >> Jim Grosbach wrote: >>> To say that another way, is the assembler correctly diagnosing a previously >>> unnoticed problem in the project source code, or is the assembler not >>>

For anyone interesting in some meta-programming ideas, I''ve written up a short explanation about the Class Creation feature of Dr Nic''s Magic Models. I know most forum posts start with "How do I..." but thought it might be interesting reading for the ppl who answer the forum posts that start with "How do I..." :)