Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#2703 - Invalid regex in streamripper-1.61.5-1

Attached to Project: Arch Linux
Opened by j (archdaemon) - Wednesday, 04 May 2005, 21:52 GMT
Last edited by Dale Blount (dale) - Wednesday, 04 May 2005, 23:24 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Damir Perisa (damir.perisa)
Architecture not specified
Severity Medium
Priority Normal
Reported Version 0.7 Wombat
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

I installed streamripper and got this on running it:

:streamripper foo -r
Connecting...
Warning: malformed regular expression:
[[:space:]]*-?[[:space:]]*mp3pro$
Warning: malformed regular expression:
^[[:space:]]*([^-]*?)[[:space:]]*-[[:space:]]*(.*?)[[:space:]]*$
stream: foo
server name: bar
bitrate: 128
meta interval: 8192
relay port: 8000
[getting track name... ]
[ripping... ] foo [ 5.99M]

It proceeded to create giant single files for every stream, whether invoked directly or through the streamtuner front end when the expected behavior is to split into tracks.

I downloaded the source code of 1.61.8. The changelog indicates nothing relevant and compiling it produced the same results. However, recompiling with '--with-included-tre' fixed the problem. Apparently streamripper can use an included regex parsing library and the regexes it uses are tailored for that dialect and don't make the system parser happy. I think this is a bug with streamripper but I note it here to offer a possible fix for the package in the meantime and, if I can communicate with the streamripper dev without having to register for anything, I'll try pass this on to him.
This task depends upon

Closed by  Jan de Groot (JGC)
Tuesday, 31 May 2005, 16:17 GMT
Reason for closing:  Not a bug
Additional comments about closing:  This is not a bug in the package, but in the version of glibc that had been in testing for one day. Fixed already in glibc.
Comment by j (archdaemon) - Wednesday, 04 May 2005, 22:02 GMT
Oops. Did this backwards. Went to the sourceforge bug tracker for streamripper and found the bug - this is the problem and the workaround, but the dev says its fixed in 1.61.8. Except it's not. ;)
Comment by Damir Perisa (damir.perisa) - Thursday, 05 May 2005, 12:29 GMT
.8 will have the workaround inside
Comment by j (archdaemon) - Monday, 09 May 2005, 07:28 GMT
Thanks - working great. :)

After further consultation with the streamripper developer, it seems Arch's glibc doesn't support posix regex's? This doesn't seem right - should this be a bug in glibc (glibc-2.3.5-2) rather than streamripper?
Comment by j (archdaemon) - Monday, 09 May 2005, 08:03 GMT
Too damn many websites to keep up with. I did a search here and didn't turn up anything, but I did another search at the forums and it seems the glibc regex problem was known and fixed. Gotta go uncomment testing in pacman.conf again or something.

http://bbs.archlinux.org/viewtopic.php?t=11946&highlight=bugtracker

-- Yeah, I guess that's what it was. Just a busted glibc. Recompiling with the new one works fine - explicitly compiled '--without-included-tre' and ran it from the build directory and it works as expected.

Loading...