Ron <[email protected]> writes: > Hi Simon, > > On Fri, Dec 18, 2009 at 04:17:43PM +0100, Simon Josefsson wrote: >> Package: mingw32 >> Version: 4.2.1.dfsg-1 > > Wrong package. This is an issue in the runtime library, not the compiler. > #452977 is the bug you want, and it's already 'important'. So I'm going > to -done this one, just because there is already a fairly concise summary > there, and merging this would just duplicate that for anyone else trying > to come up to speed on the situation.
Oops! > But *shrug*. One of the main things I really need to know right now before > we can think about bringing in the new upstream, is whether or not the > licence issues that were raised for gcc 4.4 are an issue for this package > (since a 4.4 derivative is the next upstream release). Even after reading http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452977#59 I don't understand why you want to couple fixing this problem together with pulling an a new upstream version. The issues appears to me be two different matters. Gcc 4.4 is already in debian testing. Is there any bug tracking the license issue you refer to? We could make this bug block on that bug, if there is such a bug. I'm not sure I understand what the license concern would be, if gcc 4.4 was deemed OK for testing already. If there isn't a bug tracking the problem, it would be useful to file one so it is tracked. You wrote in #59: > That doesn't help all the other people who've indicated > they need things from the new upstream too. So, possible? > One simple patch? Sure. But the logical outcome of that > is I'll then get 20 more emails, from people asking, just > my one simple patch too... ? So where do I draw that line? Make it depend on the bug severity? If it is a wishlist patch, it's fine to delay it (assuming new versions are packaged within a reasonable time frame), but if it is a real bug that can be solved by patching the code (especially if doing so is using the same patch that upstream accepted) it is a disservice to users to not do it. Especially for a problem as severe as this one, and as easily solved like it is too. > I haven't really had a straight-faced answer on that from anyone yet, and > it would be nice to get one before I replace the existing toolchain, that's > currently working for quite a few people, with something they may not legally > be able to actually use. That's a separate issue to this bug, but one of > the things that is logically blocking it in practice right now. I don't think the issues need to logically depend on each other. /Simon -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
