Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2023-02-06T11:29:48Zhttps://gitlab.xiph.org/xiph/icecast-libigloo/-/issues/7./configure CFLAGS='-flto -O2' triggers lto-type-mismatch warnings between sr...2023-02-06T11:29:48ZPetr Pisar./configure CFLAGS='-flto -O2' triggers lto-type-mismatch warnings between src/igloo.c and src/ro.cWhen building with gcc-13.0.1 and link-time optimization is enabled (-flto), the compiler warns about mismatching function prototypes among compilation units:
~~~~
/bin/sh ./libtool --tag=CC --mode=link gcc -O2 -flto=auto -ffat-lto-...When building with gcc-13.0.1 and link-time optimization is enabled (-flto), the compiler warns about mismatching function prototypes among compilation units:
~~~~
/bin/sh ./libtool --tag=CC --mode=link gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=z13 -mtune=z14 -fasynchronous-unwind-tables -fstack-clash-protection -Wextra -pthread -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes -o libigloo.la -rpath /usr/lib64 src/igloo.lo src/error.lo src/rwlock.lo src/time.lo src/feature.lo src/list.lo src/digest.lo src/prng.lo src/cs.lo src/sp.lo src/ro.lo src/tap.lo src/uuid.lo -lm -lrhash -lpthread
libtool: link: gcc -shared -fPIC -DPIC src/.libs/igloo.o src/.libs/error.o src/.libs/rwlock.o src/.libs/time.o src/.libs/feature.o src/.libs/list.o src/.libs/digest.o src/.libs/prng.o src/.libs/cs.o src/.libs/sp.o src/.libs/ro.o src/.libs/tap.o src/.libs/uuid.o -lm -lrhash -lpthread -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -O2 -flto=auto -g -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=z13 -mtune=z14 -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes -pthread -Wl,-soname -Wl,libigloo.so.0 -o .libs/libigloo.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libigloo.so.0" && ln -s "libigloo.so.0.0.0" "libigloo.so.0")
libtool: link: (cd ".libs" && rm -f "libigloo.so" && ln -s "libigloo.so.0.0.0" "libigloo.so")
libtool: link: ( cd ".libs" && rm -f "libigloo.la" && ln -s "../libigloo.la" "libigloo.la" )
make[1]: Leaving directory '/builddir/build/BUILD/libigloo-0.9.2'
./include/igloo/ro.h:178:17: warning: type of 'igloo_ro_ref_raw' does not match original declaration [-Wlto-type-mismatch]
178 | igloo_error_t igloo_ro_ref_raw(igloo_ro_t self, igloo_ro_t *out, const igloo_ro_type_t *type);
| ^
src/ro.c:446:17: note: type mismatch in parameter 1
446 | igloo_error_t igloo_ro_ref_raw(igloo_ro_t self, igloo_ro_t *out, const igloo_ro_type_t *type)
| ^
src/ro.c:446:17: note: 'igloo_ro_ref_raw' was previously declared here
src/ro.c:446:17: note: code may be misoptimized unless '-fno-strict-aliasing' is used
./include/igloo/ro.h:183:17: warning: type of 'igloo_ro_weak_ref_replace_raw' does not match original declaration [-Wlto-type-mismatch]
183 | igloo_error_t igloo_ro_weak_ref_replace_raw(igloo_ro_t self, igloo_ro_t *out, const igloo_ro_type_t *type);
| ^
src/ro.c:658:17: note: type mismatch in parameter 1
658 | igloo_error_t igloo_ro_weak_ref_replace_raw(igloo_ro_t self, igloo_ro_t *out, const igloo_ro_type_t *type)
| ^
src/ro.c:658:17: note: 'igloo_ro_weak_ref_replace_raw' was previously declared here
src/ro.c:658:17: note: code may be misoptimized unless '-fno-strict-aliasing' is used
src/private.h:72:12: warning: type of 'igloo_ro_get_instance_unsafe' does not match original declaration [-Wlto-type-mismatch]
72 | igloo_ro_t igloo_ro_get_instance_unsafe(igloo_ro_t self, const igloo_ro_type_t *type);
| ^
src/ro.c:974:12: note: return value type mismatch
974 | igloo_ro_t igloo_ro_get_instance_unsafe(igloo_ro_t self, const igloo_ro_type_t *type)
| ^
src/ro.c:974:12: note: 'igloo_ro_get_instance_unsafe' was previously declared here
src/ro.c:974:12: note: code may be misoptimized unless '-fno-strict-aliasing' is used
./include/igloo/ro.h:189:17: warning: type of 'igloo_ro_stringify_raw' does not match original declaration [-Wlto-type-mismatch]
189 | igloo_error_t igloo_ro_stringify_raw(igloo_ro_t self, char **result, igloo_ro_sy_t flags, const igloo_ro_type_t *type);
| ^
src/ro.c:757:17: note: type mismatch in parameter 1
757 | igloo_error_t igloo_ro_stringify_raw(igloo_ro_t self, char **result, igloo_ro_sy_t flags, const igloo_ro_type_t *type)
| ^
src/ro.c:757:17: note: 'igloo_ro_stringify_raw' was previously declared here
src/ro.c:757:17: note: code may be misoptimized unless '-fno-strict-aliasing' is used
./include/igloo/ro.h:175:12: warning: type of 'igloo_RO_TO_TYPE_raw' does not match original declaration [-Wlto-type-mismatch]
175 | igloo_ro_t igloo_RO_TO_TYPE_raw(igloo_ro_t object, const igloo_ro_type_t *type) igloo_ATTR_F_HOT;
| ^
src/ro.c:250:17: note: return value type mismatch
250 | igloo_ro_t igloo_RO_TO_TYPE_raw(igloo_ro_t object, const igloo_ro_type_t *type)
| ^
src/ro.c:250:17: note: 'igloo_RO_TO_TYPE_raw' was previously declared here
src/ro.c:250:17: note: code may be misoptimized unless '-fno-strict-aliasing' is used
src/private.h:74:21: warning: type of 'igloo_instance_get_prng_state' does not match original declaration [-Wlto-type-mismatch]
74 | igloo_prng_state_t *igloo_instance_get_prng_state(igloo_ro_t self, size_t *instancelen);
| ^
src/igloo.c:314:21: note: type mismatch in parameter 1
314 | igloo_prng_state_t *igloo_instance_get_prng_state(igloo_ro_t self, size_t *instancelen)
| ^
src/igloo.c:314:21: note: 'igloo_instance_get_prng_state' was previously declared here
src/igloo.c:314:21: note: code may be misoptimized unless '-fno-strict-aliasing' is used
src/private.h:73:19: warning: type of 'igloo_instance_get_stringpool_state' does not match original declaration [-Wlto-type-mismatch]
73 | igloo_sp_state_t *igloo_instance_get_stringpool_state(igloo_ro_t self);
| ^
src/igloo.c:304:19: note: type mismatch in parameter 1
304 | igloo_sp_state_t *igloo_instance_get_stringpool_state(igloo_ro_t self)
| ^
src/igloo.c:304:19: note: 'igloo_instance_get_stringpool_state' was previously declared here
src/igloo.c:304:19: note: code may be misoptimized unless '-fno-strict-aliasing' is used
~~~~
While the printed lines are character by character equal, it is probably igloo_ro_t type which differ: include/igloo/types.h defines it as a union of igloo_RO_TYPE()s or as "void *" depending on igloo_ATTR_T_TRANSPARENT_UNION macro. Further, an union member "igloo_RO_TYPE(igloo_ro_stub_t)" expands to "subtype__igloo_ro_stub_t *". Hence different types. src/igloo.c and src/ro.c probably differ in a list of included header files. I agree that the GCC warning is not much helpful. The warning can be triggered with "./configure CFLAGS='-flto -O2'" command.
Problem is that GCC since -O2 optimization level assumes that pointers to different types cannot alias to the same memory and optimizes the code so. This can lead to undefined run-time execution. A brief introduction to strict aliasing can be found at <https://www.geeksforgeeks.org/strict-aliasing-rule-in-c-with-examples/>.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libigloo/-/issues/6tests/prng.c is GPL-2.0-only2024-02-08T08:07:49ZPetr Pisartests/prng.c is GPL-2.0-onlyI discovered that tests/prng.c file has a different license from other tests and code:
~~~~
* This program is distributed under the GNU General Public License, version 2.
* A copy of this license is included with this source.
~~~~
Is...I discovered that tests/prng.c file has a different license from other tests and code:
~~~~
* This program is distributed under the GNU General Public License, version 2.
* A copy of this license is included with this source.
~~~~
Is it a mistake, or a known feature? If it is expected, would it be possible to add a copy of GPL-2.0 license into the source archive? COPYING file quotes LGPL-2.0.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libigloo/-/issues/5Obselete Autoconf macros2023-02-05T13:39:25ZPetr PisarObselete Autoconf macrosWhen regenerating configure script with autoconf-2.71, I can see these warnings:
~~~~
configure.ac:71: warning: The macro `AC_HEADER_STDC' is obsolete.
configure.ac:71: You should run autoupdate.
./lib/autoconf/headers.m4:704: AC_HEADER...When regenerating configure script with autoconf-2.71, I can see these warnings:
~~~~
configure.ac:71: warning: The macro `AC_HEADER_STDC' is obsolete.
configure.ac:71: You should run autoupdate.
./lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from...
configure.ac:71: the top level
configure.ac:72: warning: The macro `AC_HEADER_TIME' is obsolete.
configure.ac:72: You should run autoupdate.
./lib/autoconf/headers.m4:743: AC_HEADER_TIME is expanded from...
configure.ac:72: the top level
configure.ac:118: warning: The macro `ACX_PTHREAD' is obsolete.
configure.ac:118: You should run autoupdate.
aclocal.m4:266: ACX_PTHREAD is expanded from...
configure.ac:118: the top level
~~~~~
From Autoconf documentation:
~~~~
-- Macro: AC_HEADER_STDC
This macro is obsolescent. Its sole effect is to make sure that
all the headers that are included by ‘AC_INCLUDES_DEFAULT’ (*note
Default Includes::), but not part of ISO C90, have been checked
for.
All hosted environments that are still of interest for portable
code provide all of the headers specified in ISO C90 (as amended in
1995).
-- Macro: AC_HEADER_TIME
This macro used to check whether it was possible to include
‘time.h’ and ‘sys/time.h’ in the same source file, defining
‘TIME_WITH_SYS_TIME’ if so.
Nowadays, it is equivalent to ‘AC_CHECK_HEADERS([sys/time.h])’,
although it does still define ‘TIME_WITH_SYS_TIME’ for
compatibility’s sake. ‘time.h’ is universally present, and the
systems on which ‘sys/time.h’ conflicted with ‘time.h’ are
obsolete.
~~~~
ACX_PTHREAD was renamed to AX_PTHREAD as can be found in ax_pthread.m4 of autoconf-archive-2022.09.03.Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-libigloo/-/issues/4Outdated FSF address2023-02-01T10:58:38ZPetr PisarOutdated FSF addressCOPYING file quotes a postal address of Free Software Foundation. That address is not valid anymore. Current one can be found at <https://www.gnu.org/licenses/old-licenses/lgpl-2.0.txt>. Please updates the license wording to provide an u...COPYING file quotes a postal address of Free Software Foundation. That address is not valid anymore. Current one can be found at <https://www.gnu.org/licenses/old-licenses/lgpl-2.0.txt>. Please updates the license wording to provide an up-to-date address to your users.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2459Missing documentation for the stats method2023-01-28T20:46:12ZJonas L.Missing documentation for the stats methodHi,
I am unsure if the custom stats method (`curl -X STATS http://icecast:8000`) is deprecated/maintained and if I should use it?
If this can be used in new project, I am looking for some documentation about it. Is there a place where t...Hi,
I am unsure if the custom stats method (`curl -X STATS http://icecast:8000`) is deprecated/maintained and if I should use it?
If this can be used in new project, I am looking for some documentation about it. Is there a place where this already exists?
Thankshttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2458IPv6 support?2023-01-03T15:46:45ZFabien SchenkelsIPv6 support?Hi,
It seems that Icecast does not work in IPv6?
I can't bind an IPv6 address, I get this error: `EROR connection/connection.c Could not create listener socket on port 8000 bind 2a0a:xxx`
```
<listen-socket>
<port>8000</port>
<bind...Hi,
It seems that Icecast does not work in IPv6?
I can't bind an IPv6 address, I get this error: `EROR connection/connection.c Could not create listener socket on port 8000 bind 2a0a:xxx`
```
<listen-socket>
<port>8000</port>
<bind-address>2a0a:xxxxx</bind-address>
</listen-socket>
```
thanks for your feedbackMarvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/opus-website/-/issues/1Broken link from FAQ to bug tracker (Trac)2022-12-23T03:37:51ZPhilippe CloutierBroken link from FAQ to bug tracker (Trac)[The _How do I report a bug?_ section of the _OpusFAQ_ wiki page](https://wiki.xiph.org/OpusFAQ#How_do_I_report_a_bug.3F) contains a "file a bug report" link pointing to https://trac.xiph.org/newticket?component=Opus which unfortunately ...[The _How do I report a bug?_ section of the _OpusFAQ_ wiki page](https://wiki.xiph.org/OpusFAQ#How_do_I_report_a_bug.3F) contains a "file a bug report" link pointing to https://trac.xiph.org/newticket?component=Opus which unfortunately appears broken. The error I get trying to access to access that page suggests the trac.xiph.org domain does not exist.https://gitlab.xiph.org/xiph/icecast-ices/-/issues/2325Git tag missing for 2.0.3 release2022-11-21T10:47:44ZtvogelGit tag missing for 2.0.3 releaseHi! It seems, there is no git tag for the 2.0.3 release, yet. Comparing the tar.bz2 contents, I think
git tag v2.0.3 58d89b5d135e07826f5777c6bf62645061dbae5c
should be the correct one. Would you mind to add that?Hi! It seems, there is no git tag for the 2.0.3 release, yet. Comparing the tar.bz2 contents, I think
git tag v2.0.3 58d89b5d135e07826f5777c6bf62645061dbae5c
should be the correct one. Would you mind to add that?Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2457add MPTCP support2023-04-06T12:41:42ZBjoern Jackeadd MPTCP supportMPTCP allows clients to switch from one network to another network without the TCP connection to break. So a client can be in a WIFI network and move to a LAN or a mobile data connection and the TCP connection stays alive. This is ideal ...MPTCP allows clients to switch from one network to another network without the TCP connection to break. So a client can be in a WIFI network and move to a LAN or a mobile data connection and the TCP connection stays alive. This is ideal for streaming applications and this would be perfect for Icecast. MPTCP v1 support was added to the Linux kernel in the early 5.x releases. Adding support for it for server applications is simple. MPTCP support is also transparent for non-MPTCP-aware devices.
All that being said, please add support for MPTCP to Icecast and have it enable it by default.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/opus/-/issues/2362Drop usage of fgrep in documentation script2023-04-20T22:20:07ZClaudio SaavedraDrop usage of fgrep in documentation scriptThis is deprecated and in Debian systems it's now printing a warning.
I am attaching a patch here, I can't fork the project, and please excuse me for not going through with that. For this small a patch I hope you don't mind.This is deprecated and in Debian systems it's now printing a warning.
I am attaching a patch here, I can't fork the project, and please excuse me for not going through with that. For this small a patch I hope you don't mind.https://gitlab.xiph.org/xiph/icecast-libigloo/-/issues/3Error by llvm MemorySanitizer2023-01-29T17:10:05ZPhilipp SchafftError by llvm MemorySanitizerCurrently the CI fails with a MemorySanitizer error when compiled with clang.
From IRC:
> based on the error message and 'quelle: internet' it seems that it's a brokeness in llvm.
> I *think* it is triggered by librhash trying to check ...Currently the CI fails with a MemorySanitizer error when compiled with clang.
From IRC:
> based on the error message and 'quelle: internet' it seems that it's a brokeness in llvm.
> I *think* it is triggered by librhash trying to check if it has optimised code it can load for the given platform.
> the problem with false positives however is that if you blindly ignore them maybe one day a true positive is around to hit you from behind.
I'm not sure if skipping that step is the right thing. However it clearly seems to be an option to me at this point.
Generally libigloo does a lot of low level memory management. Hence it's good to have those extra checks.https://gitlab.xiph.org/xiph/icecast-libigloo/-/issues/2needs_to_be_kept_alive() incorrectly calculates it's return value2022-09-26T11:55:12ZPhilipp Schafftneeds_to_be_kept_alive() incorrectly calculates it's return valueWith the fix in a3023baea11f701066145041594ebbf46b066666 the new inline function `needs_to_be_kept_alive(igloo_ro_stub_t)` was added to the ro-subsystem. It took the old check for the reference counter. However the counter is now updated...With the fix in a3023baea11f701066145041594ebbf46b066666 the new inline function `needs_to_be_kept_alive(igloo_ro_stub_t)` was added to the ro-subsystem. It took the old check for the reference counter. However the counter is now updated before the function is called (before it was updated later). Hence the check is no longer valid (off by one).
This will result in `needs_to_be_kept_alive(igloo_ro_stub_t)` to return false (and hence lead to freeing of the object) too early. This in turns allows for valid code to end up in a use-after-free situation.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/opus/-/issues/2361Building libopus for mac os x universal binary2022-09-17T17:20:30Zcbarrett69Building libopus for mac os x universal binaryCurrently, the active mac hardware includes both x86_64 and arm64 architecture. Apple supports universal binaries that include support for both of these architectures, such that the appropriate code is used at runtime. In order for an ...Currently, the active mac hardware includes both x86_64 and arm64 architecture. Apple supports universal binaries that include support for both of these architectures, such that the appropriate code is used at runtime. In order for an application to successfully support both, all dependent libraries must also be universal binaries. Libopus is a dependent library for my application.
My build machine is x86_64, but Apple includes the compilers for both architectures in recent versions of Xcode.
For most libs (libogg, libflac, ...) the following seems to work, but it does not work for libopus:
```
./configure CXXFLAGS="-arch x86_64 -arch arm64" CFLAGS="-arch x86_64 -arch arm64"
make -j8
sudo make install
```
result:
checking How to get X86 CPU Info... configure: error: no supported Get CPU Info method, please disable run-time CPU capabilities detection or intrinsics
Then I tried:
```
./configure --disable-rtcd CXXFLAGS="-arch x86_64 -arch arm64" CFLAGS="-arch x86_64 -arch arm64"
make -j8
```
result:
Undefined symbols for architecture arm64:
"_main", referenced from:
implicit entry/start for main executable
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2452status-json.xsl not working (Issue #55 on github)2022-11-09T14:05:17ZKlaus Kobaldstatus-json.xsl not working (Issue #55 on github)thanks for the answer:
> status-json.xsl is deprecated. What is not deprecated is all below /admin/ (the actual API). Plus for 2.5.x there is a new /admin/publicstats endpoint that is kind-of the successor of status-json.xsl.
>
> status...thanks for the answer:
> status-json.xsl is deprecated. What is not deprecated is all below /admin/ (the actual API). Plus for 2.5.x there is a new /admin/publicstats endpoint that is kind-of the successor of status-json.xsl.
>
> status-json.xsl is an optional part (meaning it is installed by default but operators sometimes choose to remove it). While being deprecated it is still provided at this point. If your installation lacks it it's most likely because someone removed it (which might or might not have a reason). You can however you reinstall it by copying the latest versions of status-json.xsl, and xml2json.xslt (both located in /web/).
I tried
localhost:8000/admin/publicstats
produces:
400 - Unrecognised command
I am using this docker container:
moul/icecast:latest
Is there a better ready container maybe?https://gitlab.xiph.org/xiph/icecast-server/-/issues/2451a potential bug of NPD2022-09-14T08:41:54Zash1852a potential bug of NPDHi, I found a potential null pointer dereference bug in the project source code of libshout, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the steps that gen...Hi, I found a potential null pointer dereference bug in the project source code of libshout, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the steps that generate the bug,the file path can be seen in the blue framed section.
![getvar](/uploads/8fc4ca569f4f83b6f01a8c2ea5e57342/getvar.jpg)
what i am confused about is, there are some code snippets can be found in project that checking if return value of httpp_getvar equal to null, maybe the context in which the code snippet is located can asserts that the return value cannot be equal to null? but I haven't found such code can assert this.
Although the code shown is for the latest but is still exist in current version.would you help to check if this bug is true?thank you for your patience and effort!Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/vorbis/-/issues/2347a potential bug of NPD2022-09-13T10:38:25Zash1852a potential bug of NPDHi, I found a potential null pointer dereference bug in the project source code of vorbis, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the steps that gener...Hi, I found a potential null pointer dereference bug in the project source code of vorbis, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the steps that generate the bug, the red arrows represent the control flow,the file path can be seen in the blue framed section.
![1662360760592](https://user-images.githubusercontent.com/87304478/188383134-07ef0506-a2c9-4a29-861a-b132c5c0d7f1.jpg)
Although the code shown is for version 1.3.6 but is still exist in current version
would you can help to check if this bug is true?thank you for your effort and patience!https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2336a potential NPD in source file src/proto_http.c2022-09-13T10:40:11Zash1852a potential NPD in source file src/proto_http.cHi, I found a potential null pointer dereference bug in the project source code of libshout, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the steps that gen...Hi, I found a potential null pointer dereference bug in the project source code of libshout, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the steps that generate the bug, the file path can be seen in the blue framed section.
![getvar](/uploads/d440a52b893294bb5844c94ffe3e2a93/getvar.jpg)
Although the code shown is for the latest but is still exist in current version.
What I'm confused about is, some empty judgment operation to return value of httpp_getvar can be found in some code snippets of the libshout project, so I'm not sure if the context of this snippet can assert that the call-statement won't return null, if so please give me some hints.thank you for checking if this bug is true.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/flac/-/issues/2Missing man pages with CMake build in 1.4.02022-09-22T16:45:38ZMatthias DienerMissing man pages with CMake build in 1.4.0Trying to run `make install` with the CMake build results in the following error:
```
Install the project...
-- Install configuration: "Release"
-- Installing: $PREFIX/share/FLAC/cmake/targets.cmake
-- Installing: $PREFIX/share/FLAC/cma...Trying to run `make install` with the CMake build results in the following error:
```
Install the project...
-- Install configuration: "Release"
-- Installing: $PREFIX/share/FLAC/cmake/targets.cmake
-- Installing: $PREFIX/share/FLAC/cmake/targets-release.cmake
-- Installing: $PREFIX/share/FLAC/cmake/flac-config.cmake
-- Installing: $PREFIX/share/FLAC/cmake/flac-config-version.cmake
-- Up-to-date: $PREFIX/share/FLAC/cmake/flac-config.cmake
-- Up-to-date: $PREFIX/share/FLAC/cmake/flac-config-version.cmake
-- Installing: $PREFIX/include/FLAC/all.h
-- Installing: $PREFIX/include/FLAC/assert.h
-- Installing: $PREFIX/include/FLAC/callback.h
-- Installing: $PREFIX/include/FLAC/export.h
-- Installing: $PREFIX/include/FLAC/format.h
-- Installing: $PREFIX/include/FLAC/metadata.h
-- Installing: $PREFIX/include/FLAC/ordinals.h
-- Installing: $PREFIX/include/FLAC/stream_decoder.h
-- Installing: $PREFIX/include/FLAC/stream_encoder.h
-- Installing: $PREFIX/include/FLAC++/all.h
-- Installing: $PREFIX/include/FLAC++/decoder.h
-- Installing: $PREFIX/include/FLAC++/encoder.h
-- Installing: $PREFIX/include/FLAC++/export.h
-- Installing: $PREFIX/include/FLAC++/metadata.h
CMake Error at cmake_install.cmake:107 (file):
file INSTALL cannot find
"/home/conda/feedstock_root/build_artifacts/libflac_1662749525203/work/man/flac.1":
No such file or directory.
```
See https://api.travis-ci.com/v3/job/582395654/log.txt for a full build log.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2450a potential bug of NPD2022-09-06T00:08:21Zash1852a potential bug of NPDHi, I found a potential null pointer dereference bug in the project source code of icecast-Server, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the steps th...Hi, I found a potential null pointer dereference bug in the project source code of icecast-Server, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the steps that generate the bug, the red arrows represent the control flow,the file path can be seen in the blue framed section.
![image](/uploads/92074055051bc53bda3046f7bc09838d/image.png)
Although the code shown is for the latest but is still exist in current version. (https://gitlab.xiph.org/xiph/icecast-server/-/blob/master/src/format_ogg.c#L452-L454)
would you can help to check if this bug is true?thank you for your effort and patience!Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/celt/-/issues/40.11.3: test suite is failing2024-01-22T12:01:11ZTomasz Kłoczko0.11.3: test suite is failing```console
+ /usr/bin/make -O -j48 V=1 VERBOSE=1 check
Making check in libcelt
/usr/bin/make check-TESTS
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/libcelt'
PASS: match-test.sh
make[3]: Leaving directory '/ho...```console
+ /usr/bin/make -O -j48 V=1 VERBOSE=1 check
Making check in libcelt
/usr/bin/make check-TESTS
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/libcelt'
PASS: match-test.sh
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/libcelt'
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/libcelt'
============================================================================
Testsuite summary for
============================================================================
# TOTAL: 1
# PASS: 1
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
============================================================================
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/libcelt'
Making check in tests
/usr/bin/make check-TESTS
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
PASS: type-test
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
PASS: laplace-test
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
PASS: mathops-test
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
PASS: dft-test
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
PASS: mdct-test
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
FAIL: tandem-test
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
PASS: ectest
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
PASS: cwrs32-test
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/celt-0.11.3/tests'
============================
: tests/test-suite.log
============================
# TOTAL: 8
# PASS: 7
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: tandem-test
=================
Error: celt_decode returned unknown error
Error: celt_decode returned unknown error
Error: celt_decode returned unknown error
Error: at 30 bytes_per_frame celt_decode returned unknown error
CELT codec tests. Random seed: 3273316686 (0FC4)
Testing asynchronous tandeming (48000Hz, 1ch, 960 samples, 30 - 320 bytes).
FAIL tandem-test (exit status: 1)
============================================================================
Testsuite summary for
============================================================================
# TOTAL: 8
# PASS: 7
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
============================================================================
See tests/test-suite.log
============================================================================
```
content of the tests/test-suite.log
```console
============================
: tests/test-suite.log
============================
# TOTAL: 8
# PASS: 7
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: tandem-test
=================
Error: celt_decode returned unknown error
Error: celt_decode returned unknown error
Error: celt_decode returned unknown error
Error: at 30 bytes_per_frame celt_decode returned unknown error
CELT codec tests. Random seed: 3273316686 (0FC4)
Testing asynchronous tandeming (48000Hz, 1ch, 960 samples, 30 - 320 bytes).
FAIL tandem-test (exit status: 1)
```