Activity for Michael Ablassmeier
-
Michael Ablassmeier created ticket #22
Segfaults on wrong parameters
-
segfaults with -I option
-
hi brad, the package is now split into libdi5, libdi-devel and di itself. While di declares a dependency to libdi, which is automatically done by the debian build scripts. Im importing the new releases frequently to the debian salsa git, and usually i skip uploads where i see that there are no relevant changes (so, if i see only macos related cmake changes, i skip versions) On Sat, Feb 15, 2025 at 10:49:21PM -0000, Brad Lanam wrote: And I had a question. I do not fully understand the debian install...
-
hi Brad, the new version has been uploaded, its now splitted into the binary, library and according -dev package. As the source introduces new packages it needs to pass acceptance of the debian FTP team again. Usually this takes some time. bye, - michael On Fri, Feb 07, 2025 at 02:32:37PM -0000, Brad Lanam wrote: I'm just finishing off some changes that allow cmake to be run directly without the makefile. That will make various maintainers happy. I don't know of any bugs. I just ran tests for version...
-
hi Brad, On Thu, Feb 06, 2025 at 10:15:07PM -0000, Brad Lanam wrote: The makefile might be running the mkconfig install (and build!) rather than the cmake install if cmake isn't in the path. That could be why your installation is working. Because there was definitely an issue with the destination directory when using the cmake install. The libtirpc package should be a dependency (for NFS quotas). pkgconfig is also needed (if not already there) in order to pick up libtirpc, gmp, libtommath. I have...
-
.. cores if invalid arguments are passed: di --versio Segmentation fault (core dumped)
-
Core dumps on some parameters
-
hi, On Thu, Feb 06, 2025 at 08:15:22PM -0000, Brad Lanam wrote: I put a check into the CMakeLists.txt file so that the RPATH can be easily overridden via make or via the environment. make -e PREFIX=somewhere CMAKE_SKIP_RPATH=TRUE CMAKE_SKIP_RPATH=TRUE make -e PREFIX=somewhere thanks, i think that will help. On a side note, it seems that the install target doesnt honor DESTDIR/PREFIX for all files if using the regular makefile targets. The locale files wont be installed into the right path: cmake...
-
NM, works with 5.0.1
-
thanks, i think that will help. On a side note, it seems that the install target doesnt honor DESTDIR/PREFIX for all files if using the regular makefile targets. The locale files wont be installed into the right path: cmake --install build -- Install configuration: "" -- Installing: /srv/build/di-5.0.0/debian/di/usr/lib/x86_64-linux-gnu/libdi.so.5.0.0 -- Installing: /srv/build/di-5.0.0/debian/di/usr/lib/x86_64-linux-gnu/libdi.so.5 -- Installing: /srv/build/di-5.0.0/debian/di/usr/lib/x86_64-linux-gnu/libdi.so...
-
hi, yes, i caught the beta release in-between. Ive just imported 5x. Im stil thinking about a right solution for the RPATH issue. If i attempt to set this option, i think i need to also set al the other options like SOVERSION etc, overriding the complete cmake call in debian/rules. Thats not my preferred soluation as i would have to touch the rules file for each version released. Otherwise i could just use the makefile.. Mabye passing this option via the Makefile would make sense? Otherwise if possible,...
-
hi, yes, i caught the beta release in-between. Ive just imported 5x. Im stil thinking about a right solution for the RPATH issue. If i attempt to set this option, i think i need to also set al the other options like SOVERSION etc, overriding the complete cmake call. Otherwise i could just use the makefile.. Mabye passing this option via the Makefile would make sense? Otherwise if possible, using environment variables, but not sure if cmake supports that (never used cmake until now ;))
-
hi, thanks for the quick reply. The RPATH issue is fixed by setting mentioned environment variable. As a side note, the manpage shields some groff errors: LC_ALL=C.UTF-8 MANROFFSEQ='' MANWIDTH=80 \ man --warnings -E UTF-8 -l -Tutf8 -Z /usr/share/man/man3/libdi.3.gz >/dev/null troff:<standard input>:69: warning: cannot select font 'D' troff:<standard input>:77: warning: cannot select font 'D'
-
Debian Packages for 5.x
-
W: di: groff-message 51: warning: macro 'com.apple.TimeMachine.'.' not defined [usr/share/man/man1/di.1.gz:1
-
Fails to build with GCC 14
-
hi Brad, On Wed, Jul 03, 2024 at 12:55:47PM -0000, Brad Lanam wrote: Can you update to version 4.53 and test again? The check for a library function has been updated for modern compilers. wow, that was fast. Yes, i totally overlooked that theres a new version available, ill work on getting it into debian, thanks, - michael
-
hi brad, thanks for the fast reply, ill work on getting 4.53 into debian!
-
Fails to build with gcc 14
-
hi, the Problem is that the said stream redirects http to https, but streamripper is not https capable so attempts the redirect on port 80 again and is thus stuck in and endless loop. It can be seen from the debug output in gcs.txt: Redirecting: https://icecast.bkwsu.eu/radio-eyesee.mp3 ***** URL = https://icecast.bkwsu.eu/radio-eyesee.mp3 ***** http_sc_connect(): calling http_parse_url http_parse_url: https://icecast.bkwsu.eu/radio-eyesee.mp3 Branch 2 (icecast.bkwsu.eu/radio-eyesee.mp3) http_sc_connect():...
-
hi, the Problem is that the said stream redirects http to https, but streamripper is not https capable so attempts the redirect on port 80 again and is thus stuck in and endless loop. One workaround may be to create a transparent socks proxy via socat or alike that handles https traffic transparently. Streamripper doesnt support https at all, and since the project is unmaintained i dont think this fact will change any time soon. I think a proper way would be to port lib/http.c to CURL.
1
