Bug#663916: New phonetisaurus package available
* Giulio Paci giuliop...@gmail.com, 2012-10-21, 15:04: What does --fst_field_separator exactly do? In my experiments it did not affect phonetisaurus-align in any way. Unfortunately I do not know most of the options of this program. I asked upstream about this option. Upstream replied that these flags are automatically added by openfst: http://www.openfst.org/twiki/bin/view/FST/FstAdvancedUsage#Command_Line_Flags Some of them affect the behaviour of functions that are not used by phonetisaurus-align. However he does not know how to hide those inherited options (and I do not know as well) without rewriting all the flags parsing code. Do you know how to hide them? No idea, sorry. Is it mandatory to identify possibly useless flags and to hide them? I understand that removing/hiding unneeded option might be infeasible, but I would expect that these no-ops are documented as such in the manual page (or alternative: that they are not documented in the manpage at at all). There are some warnings in the build log: | /usr/bin/make -C src CFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall CXXFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security CPPFLAGS=-D_FORTIFY_SOURCE=2 LDFLAGS=-fPIE -pie -Wl,-z,relro -Wl,-z,now THIRD_PARTIES_INCLUDE=-I3rdparty/utfcpp -k clean | make[1]: Entering directory `/build/phonetisaurus-DN3moq/phonetisaurus-0.6/src' | rm ../phonetisaurus-g2p ../phonetisaurus-align ../phonetisaurus-arpa2fst *.o | rm: cannot remove `../phonetisaurus-g2p': No such file or directory | rm: cannot remove `../phonetisaurus-align': No such file or directory | rm: cannot remove `../phonetisaurus-arpa2fst': No such file or directory | rm: cannot remove `*.o': No such file or directory | make[1]: *** [clean] Error 1 | make[1]: Leaving directory `/build/phonetisaurus-DN3moq/phonetisaurus-0.6/src' | make: [makefile-clean] Error 2 (ignored) The above indicates two problem: 1) Upstream make clean is not idempotent: it fails it there's nothing to clean. Replacing rm with rm -f should fix this issue. 2) cdbs doesn't ignore errors from make clean. This was reported in #441020 over 5 years ago. (Sigh...) There's a warning about debian/copyright_hints not being up-to-date. There's also a few dozens of compiler warnings. Is upstream aware of them? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121022154809.ga8...@jwilk.net
Bug#691014: marked as done (RFS: swftools/0.9.2+ds1-3 [RC])
Your message dated Mon, 22 Oct 2012 22:38:14 +0200 with message-id 5085aeb6.2080...@camlann.de and subject line Re: Bug#691014: RFS: swftools/0.9.2+ds1-3 [RC] has caused the Debian Bug report #691014, regarding RFS: swftools/0.9.2+ds1-3 [RC] to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 691014: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691014 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package swftools * Package name: swftools Version : 0.9.2+ds1-3 It builds those binary packages: swftools - Collection of utilities for SWF file manipulation/creation swftools-dbg - Collection of utilities for SWF file manipulation/creation (debug To access further information about this package, please visit the following URL: http://mentors.debian.net/package/swftools Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/s/swftools/swftools_0.9.2+ds1-3.dsc Changes since the last upload: * Added debug package. * Added fix for segfault on i386. (Closes: 690237) * Build with default debian hardening flags. This new version fixes an RC bug, which prevents the package libjs-swfupload from build on i386. -- MfG, Christian Welzel GPG-Key: 4096R/5117E119 2011-09-19 Fingerprint: 3688 337C 0D3E 3725 94EC E401 8D52 CDE9 5117 E119 ---End Message--- ---BeginMessage--- The package was uploaded. -- MfG, Christian Welzel GPG-Key: pub 4096R/5117E119 2011-09-19 Fingerprint: 3688 337C 0D3E 3725 94EC E401 8D52 CDE9 5117 E119---End Message---
Bug#663916: New phonetisaurus package available
Il 22/10/2012 17:48, Jakub Wilk ha scritto: * Giulio Paci giuliop...@gmail.com, 2012-10-21, 15:04: Is it mandatory to identify possibly useless flags and to hide them? I understand that removing/hiding unneeded option might be infeasible, but I would expect that these no-ops are documented as such in the manual page (or alternative: that they are not documented in the manpage at at all). Removed those flags from the manpages. 1) Upstream make clean is not idempotent: it fails it there's nothing to clean. Replacing rm with rm -f should fix this issue. Fixed by using $(RM). There's a warning about debian/copyright_hints not being up-to-date. Fixed. There's also a few dozens of compiler warnings. Is upstream aware of them? I just sent an email about them, along with a patch removing most of them. I left untouched those warnings that I was not sure how to solve properly. I am waiting upstream to solve them. Bests, Giulio. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5085c0d2@gmail.com
Bug#663916: New phonetisaurus package available
Errata corrige. Il 22/10/2012 23:55, Giulio Paci ha scritto: Il 22/10/2012 17:48, Jakub Wilk ha scritto: * Giulio Paci giuliop...@gmail.com, 2012-10-21, 15:04: Is it mandatory to identify possibly useless flags and to hide them? I understand that removing/hiding unneeded option might be infeasible, but I would expect that these no-ops are documented as such in the manual page (or alternative: that they are not documented in the manpage at at all). Removed those flags from the manpages. 1) Upstream make clean is not idempotent: it fails it there's nothing to clean. Replacing rm with rm -f should fix this issue. Fixed by using $(RM). 2) cdbs doesn't ignore errors from make clean. This was reported in #441020 over 5 years ago. (Sigh...) I just read the bug report. Actually cdbs ignores errors in make clean. So the problem here seems to be that building should fail on make clean, but it was working anyway. Right? There's a warning about debian/copyright_hints not being up-to-date. Fixed. I re-created the problem by adding the new patch. Now it is fixed (again). There's also a few dozens of compiler warnings. Is upstream aware of them? I just sent an email about them, along with a patch removing most of them. I left untouched those warnings that I was not sure how to solve properly. I am waiting upstream to solve them. The patch header was broken, I fixed it. Bests, Giulio. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5085c7ad.8030...@gmail.com
Bug#663916: New phonetisaurus package available
* Giulio Paci giuliop...@gmail.com, 2012-10-23, 00:24: 2) cdbs doesn't ignore errors from make clean. This was reported in #441020 over 5 years ago. (Sigh...) I just read the bug report. Actually cdbs ignores errors in make clean. So the problem here seems to be that building should fail on make clean, but it was working anyway. Right? D'oh! I meant s/doesn't/shouldn't/. So yes, you are right. Sorry for the confusion. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2012103716.ga3...@jwilk.net
Lots of problems with upstream, please help!
Hello, I hope this is the right mailing list. I've been a Debian user for over 10 years, but due to schoolwork and work i haven't been very involved in Debian. Mostly I have submitted patches to upstream or helping upstream debug rather than helping Debian specifically. For a long time, I always end up with a dozen or so of my own custom packages which I derive from official debian source packages with an extra tiny bugfix patch or two I've thrown in on top and recompiled. Sounds pretty selfish, I know. With Wheezy coming out, I'm trying to help any way I can but I'm having some problems. Technically they are all problems with upstream and they're all for different software. I really don't know how to deal with them to help Debian. 1. As a big regression from Squeeze, I had to blacklist an HP platform driver from loading into the kernel in order for my wireless to work well. I filed a debian bug report about it and the debian maintainers helped me collect all the information I needed and submit it to upstream. I did all that, it's been 3 weeks, and the upstream kernel platform devs seem to have completely ignored it, although linux-wireless confirmed the platform driver is doing something very strange. So I don't know what to do. Maybe I just need to wait longer? 2. About 8 months ago, an upstream developer wrote a patch to enable a feature in upstream software. Upstream didn't review the patch so it never officially made it into upstream software. Requests to review the patch by me and others are getting completely ignored upstream. The upstream dev that made the patch looks to have disappeared. Upstream seems reluctant to accept, reluctant to reject and reluctant to review, so it stays in limbo. Without upstream's proper review / approval of the patch, in addition to the fact that the patch essentially enables a feature, it's probably unlikely to ever make it into Wheezy, right? I filed a bug report saying that the feature didn't work as the feature is listed in the software as being available, but it's not actually enabled in the code. I'd imagine an NMU for enabling this feature in Wheezy would be inappropriate and the proper Debian thing to do would be to just write a different patch to remove the feature so the user doesn't see it in the software? Although, that's pretty much the exact opposite of what I'm doing on my PC so I really don't have much motivation to do that. 3. A couple months ago, an upstream developer wrote a patch to fix what I consider to be a serious bug that makes a lot of apps unusable under normal (aka user customized) conditions. Upstream reviewed and approved the patch but the patch is written for KDE 4.9. 1. I tried applying the patch to KDE 4.8. 4 in Wheezy which ended up as a spectacular failure during compile. I asked upstream to back port the patch to kde 4.8. 4 in Debian and they said that they do not control the release of Debian and that KDE 4.8.5 is available. I'm almost certain the patch upstream wrote isn't going to work with 4.8.5 either, but I haven't tried it as I don't want to be that far away from Debian's packages. There is a work-around that's very easy to do, but it's not obvious, and it saps performance from my PC. I'm certain some Debian users running KDE will eventually run into this very annoying problem and have to Google and enable the work around. I will likely end up backporting the patch myself for my own personal needs if the workaround annoys me enough some day, which it probably will eventually... I worry that if I backport this patch, it might be a little ugly and probably not suitable for Debian anyway, although I really haven't looked at backporting the patch yet. 4. There appears to be a regression in some streaming libraries. When I'm running wheezy and I replace some audio streaming libraries in Wheezy with the ones from Squeeze, it fixes the same problem in several different audio players in Wheezy. What's very strange is that some other audio players don't have the problem at all in Wheezy with both the older and newer libs. I want to say that it's all the audio streaming libraries fault, but at the same time it appears that the recommended way for audio players to interface with these audio streaming libraries may have changed. It's so very complicated and I'm having a lot of trouble debugging since it's not crashing ( I wish!) and only periodically throwing out a warning or two in the background. I haven't yet contacted the audio streaming libraries because I'm trying to understand how the recommended way to interface with the streaming libraries has changed and it's very complicated. I guess I should be contacting the audio streaming devs for help/advice? Or maybe investigating the audio players to make sure they're doing the recommended things when they play audio? Or both? I wish I could just point and say it's broken as I usually do when I have problems, but it's only partially broken under very
Re: Lots of problems with upstream, please help!
On Tue, Oct 23, 2012 at 12:38 PM, David Smith wrote: With Wheezy coming out, I'm trying to help any way I can but I'm having some problems. It is probably too late to fix anything for wheezy unless it meets the release team's freeze criteria: http://release.debian.org/testing/freeze_policy.html Technically they are all problems with upstream and they're all for different software. I really don't know how to deal with them to help Debian. In future you might want include more specific information, like links to bugs you have filed etc. http://www.catb.org/esr/faqs/smart-questions.html 1. As a big regression from Squeeze, I had to blacklist an HP platform driver from loading into the kernel in order for my wireless to work well. I filed a debian bug report about it and the debian maintainers helped me collect all the information I needed and submit it to upstream. I did all that, it's been 3 weeks, and the upstream kernel platform devs seem to have completely ignored it, although linux-wireless confirmed the platform driver is doing something very strange. So I don't know what to do. Maybe I just need to wait longer? Your options are: Wait until someone with the appropriate skills is motivated to do something. Find a way to motivate someone with the appropriate skills to do something. Switch to some different hardware that doesn't have the issue. Learn the appropriate skills to fix this issue yourself and send the patch to the Linux maintainers. 2. About 8 months ago, an upstream developer wrote a patch to enable a feature in upstream software. Upstream didn't review the patch so it never officially made it into upstream software. Requests to review the patch by me and others are getting completely ignored upstream. The upstream dev that made the patch looks to have disappeared. Upstream seems reluctant to accept, reluctant to reject and reluctant to review, so it stays in limbo. Without upstream's proper review / approval of the patch, in addition to the fact that the patch essentially enables a feature, it's probably unlikely to ever make it into Wheezy, right? I filed a bug report saying that the feature didn't work as the feature is listed in the software as being available, but it's not actually enabled in the code. I'd imagine an NMU for enabling this feature in Wheezy would be inappropriate and the proper Debian thing to do would be to just write a different patch to remove the feature so the user doesn't see it in the software? Although, that's pretty much the exact opposite of what I'm doing on my PC so I really don't have much motivation to do that. Your description of this issue isn't very clear but it sounds like something that doesn't fit the freeze criteria: http://release.debian.org/testing/freeze_policy.html Sounds like someone needs to take over development of this project (zero idea if that is possible since you didn't mention any specifics). 3. A couple months ago, an upstream developer wrote a patch to fix what I consider to be a serious bug that makes a lot of apps unusable under normal (aka user customized) conditions. Upstream reviewed and approved the patch but the patch is written for KDE 4.9. 1. I tried applying the patch to KDE 4.8. 4 in Wheezy which ended up as a spectacular failure during compile. I asked upstream to back port the patch to kde 4.8. 4 in Debian and they said that they do not control the release of Debian and that KDE 4.8.5 is available. I'm almost certain the patch upstream wrote isn't going to work with 4.8.5 either, but I haven't tried it as I don't want to be that far away from Debian's packages. There is a work-around that's very easy to do, but it's not obvious, and it saps performance from my PC. I'm certain some Debian users running KDE will eventually run into this very annoying problem and have to Google and enable the work around. I will likely end up backporting the patch myself for my own personal needs if the workaround annoys me enough some day, which it probably will eventually... I worry that if I backport this patch, it might be a little ugly and probably not suitable for Debian anyway, although I really haven't looked at backporting the patch yet. If it meets the freeze criteria (zero idea there since you didn't mention specifics) and you are willing to backport the patch, I guess the Debian KDE team would be happy to upload it, especially if you are interested in joining the team. 4. There appears to be a regression in some streaming libraries. When I'm running wheezy and I replace some audio streaming libraries in Wheezy with the ones from Squeeze, it fixes the same problem in several different audio players in Wheezy. What's very strange is that some other audio players don't have the problem at all in Wheezy with both the older and newer libs. I want to say that it's all the audio streaming libraries fault, but at the same time it appears that the
