similar to: The next release (pre-compiled windows and mac binaries)

On 09-07-13 23:00, Erik de Castro Lopo wrote: > That leaves the question of how these binaries are generated. I've > spoken to Ralph Giles (Xiph) and he'd like make sure we know the > exact provinance of all binaries hosted on the Xiph web site. Its > not that we don't trust anyone, its just that we want to know exactly > what went into it. I think that is a very good

Janne Hyv?rinen wrote: > > On 14.3.2013 9:37, Erik de Castro Lopo wrote: > > Janne Hyv?rinen wrote: > > > >> The patch was made from the published pre2 version. It missed the MinGW > >> changes that were applied to git version. > > Patch applied. Thanks. > > > > Erik > > Unfortunately with this commit the LRN's patch from commit

Hi all, In my latest commit I have updated all version strings and copyright dates. I am now going to do a little testing (and encourage anyone else to do the same) and hopefully release in the next day or so. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

Dear all. I would like to propose a possible way to make mget and mput behave more or less the same way, rather that just changing documentation. Please, bear in mind this is a poor attempt coming from a person with no C skills at all, so other than testing that only filtered files are transferred, I have not gone further. Hope at least to have been able not to corrupt any pointer, but I'm

Jaren Stangret wrote: > Testing the metadata-handling properties of flac-to-flac encoding... > case00a... Files case00a-expect.meta and out.meta differ > ERROR: metadata does not match expected case00a-expect.meta > make: *** [fullcheck] Error 1 Last night I did a git bisect on this issue and this error arose when I changed the version from "1.2.1" to "1.3.0pre1".

I have also run a `make fullcheck` on Mac OS X 10.8. Only one test fails: FLAC__TEST_LEVEL=1 FLAC__TEST_WITH_VALGRIND=no ./test_grabbag.sh ./test_grabbag.sh: line 39: 1N: value too great for base (error token is "1N") make[1]: *** [fullcheck] Error 1 make: *** [fullcheck] Error 2 The cause is that in test_grabbag.sh, line 39, it uses `date +%N` to get nanoseconds, which is unsupported

I'd also like to note that this is happening for me with current HEAD (619b43df36b725e11e12db768d558b1930a583b6). On Mon, Mar 18, 2013 at 11:25 PM, Jaren Stangret <sirjaren at gmail.com> wrote: > I've been trying to get the test suite cleaned up and even with the > original "untouched" test suite via flac 1.3.0pre2, I'm getting a test > suite failure. >

fullcheck target was removed from test/Makefile.am, but not from <root>/Makefile.am. So `make fullcheck' fails with the following message: ... *** No rule to make target `fullcheck'. Stop. ...

On 5/2/07, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > Well, I don't quite understand why AC_C_BIGENDIAN and the solution > you're proposing is likely to break other big endian machines (the ones > that don't have __BIG_ENDIAN__). Can you send a patch that addresses > that (i.e. still uses AC_C_BIGENDIAN when it works)? It is not that AC_C_BIGENDIAN

A new update. Same behaviour with 4.6.16. Exact issue as Bug 1249. Many thanks. Kind regards. El lun., 24 ago. 2020 a las 12:23, LPC DPG (<lpcdpg at gmail.com>) escribi?: > Dear folks. > > Was hoping it had to do with the release, but have also tested in 4.4.16 > and the issue is also there. I am aware a RHEL/CEntOS based upon 6 > distribution is not the most up to date

Dear Andrew. You are right, I should have taken a deeper look into the standard output during compilation. I did just assume source4 was the one for Samba4. Anyway, besides the source confusion (really, even if I had found the right one, following the code would have been out of my reach), I don't seem to find how that is related with the documentation issue, or the mput/mask/recurse

Erik de Castro Lopo wrote: > The fullcheck target was dumped because the extra tests in that target > were pulled into the regular 'make check' target. My point was that Makefile.am in the root folder still have fullcheck target. So it make sense either to remove it from this file: diff --git a/Makefile.am b/Makefile.am index ba09d1d..4b81e6e 100644 --- a/Makefile.am +++

Martijn van Beurden wrote: > Like I reported just before the release of 1.3.0 (mail of Fri, > 05 Apr 2013 08:25:10 +0200, to be specific), compiling on > Raspbian (Debian Wheezy, GCC 4.6) returns quite some warnings of > the type -Wcast-align. > > > CC lpc_intrin_sse2.lo > > CC lpc_intrin_sse41.lo > > CC md5.lo > > md5.c: In function

make fullcheck fails on my computer: flac cannot recognize --skip option that contains decimal point, e.g. "--skip=1.234". System locale uses comma as a separator, so strtod/atof expect comma, not point, and "make fullcheck" fails. Here's what I can see in FLAC source code: atof() function found in: file: src/share/grabbag/seektable.c function:

Dear fellows. Another piece of information. The issue reprduces on RHEL 7.7, Samba 4.9.1 [root at vnhprerhds01 ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.7 (Maipo) [root at vnhprerhds01 ~]# smbclient -V Version 4.9.1 [root at vnhprerhds01 ~]# smbclient -W "${d}" -U "${u}" "${s}" "${p}" Try "help" to get a list of

Hello, I found some code within the pool allocation project to identify parallelizable function calls. Unfortunately the functionality isn't part of the current release of poolalloc (in release 14 it was). My intention is to estimate the parallelization-potential of sequential applications concerning coarse-grained parallelism. Can you tell me... 1. Why are classes of pollalloc, like

On 5/3/07, Erik de Castro Lopo <mle+la@mega-nerd.com> wrote: > Peter Grayson wrote: > > Personally I think universal binaries are a bad idea. They have obviously served some purpose, but I tend to agree that the concept does not seem to scale well once outside the Apple microcosm. > For one of my projects, libsndfile, endian issues is not the only > think that breaks in

Hi, I was running make fullcheck when I found something weird. After editing the *expect.meta files , make fullcheck ran all tests and said "All tests passed", but the output included this (this is the last tests from test_metaflac.sh) > [...] > test case60: --remove --block-type=PICTURE... OK > test case61: --import-picture-from... OK > test case62:

Hi all, I've been notified of a CVE to be publish against FLAC early next week. I have a patch for it and have thoroughly tested it as well as had it verified by the Google Security Team member who found it. I've been asked not to publish that patch until Tuesday. Once I publis the patch, I like to release FLAC 1.3.1 immediately and would therefore like to make sure that all the

for recent code changes I find myself needing some workarounds for MSVC6: 1st, I need a fast way to swap bytes (for endianness) of a 32-bit int. I could not find a builtin like bswap; the closest thing I found was ntohl() which appears to be a function call and also requires linking with winsock2 (ws2_32.lib) to get it. 2nd, I need an equivalent for lround() (or round() is ok), which is not in